SolarWinds Access Rights Manager Flaw Shows Why Hard-Coded Keys Become Authentication Infrastructure

CVE-2026-28326 turns a hard-coded static key in SolarWinds Access Rights Manager into an authentication-boundary problem: SolarWinds says ARM 2026.2 and earlier are affected, the flaw is rated CVSS 8.8, and ARM 2026.2.1 is the fixed release. The public record does not establish active exploitation, so this observation focuses on the architecture of the flaw and the remediation evidence rather than inventing an attack campaign. SolarWinds advisory

What changed on September 17

SolarWinds published its advisory for CVE-2026-28326 on September 17, 2026. The company describes an unauthenticated remote code execution vulnerability in Access Rights Manager and attributes the issue to a hard-coded static key.

The affected range is:

• Access Rights Manager 2026.2;
• and all previous versions.

The fixed release is Access Rights Manager 2026.2.1. SolarWinds rates the vulnerability 8.8 High and credits Kai Huang of Armadin with the report.

A Canadian national CERT issued a separate advisory on September 18, confirming the affected product and pointing administrators toward the vendor remediation.

Why the hard-coded key matters

A hard-coded secret is different from an ordinary leaked credential.

A leaked credential can often be revoked, rotated or disabled. A secret embedded in a product binary or otherwise distributed as a fixed part of the software can instead become a shared trust anchor across installations.

The conceptual difference is:

normal deployment
    unique secret
        |
        v
   one installation

hard-coded product key
    fixed secret
        |
   +----+----+----+
   |    |    |    |
  A    B    C    D
installations

If the same secret participates in authentication or integrity checks across deployments, compromise or recovery of that secret is not equivalent to resetting one customer's password. The product itself has to change.

The public advisory does not disclose the full exploitation sequence, so the diagram above describes the security-design implication of a static key rather than a claimed step-by-step attack path.

The CVSS vector contains an important detail

SolarWinds lists this vector:

CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H

The AV:A component means the published scoring model treats the attack vector as adjacent network, not arbitrary internet access. At the same time, the vendor summary uses the term “unauthenticated remote code execution.” Those descriptions should not be collapsed into “internet-exploitable from anywhere.”

The safer interpretation is that the vulnerability can be reached remotely without credentials or user interaction under the network-position assumptions encoded by the CVSS vector. The public advisory does not provide enough technical detail to claim a broader exposure path.

That distinction matters for prioritization. Network reachability should be assessed from the actual ARM deployment rather than inferred from the word “remote.”

Why Access Rights Manager raises the stakes

Access Rights Manager is not an ordinary desktop application. It sits in an administrative identity and permissions workflow and can interact with directory and access-management infrastructure.

That makes a remote-code-execution condition in the product more consequential than the same primitive in a low-privilege utility.

The useful question for operators is therefore not only:

“Is ARM installed?”

It is:

“What trust and administrative paths does this ARM installation have?”

Inventory should include:

1. ARM version;
2. network exposure;
3. management interfaces reachable from adjacent networks;
4. service-account privileges;
5. connections to directory services;
6. administrative credentials or tokens accessible to the product;
7. and whether the server sits inside a privileged management segment.

The fix is a software trust-anchor change

SolarWinds lists ARM 2026.2.1 as the fixed software release. That is important because a vulnerability rooted in a hard-coded key is not the kind of problem that should be treated as a local credential reset.

The remediation sequence is therefore:

identify ARM deployment
        |
        v
verify version
        |
        +---- 2026.2 or earlier ----> upgrade
        |
        +---- 2026.2.1+ -----------> fixed release

Administrators should use the vendor's current release documentation rather than relying on copied package names or unofficial mirrors.

What the public evidence does not say

Several tempting conclusions are not supported by the public record available for this run.

There is no confirmed active-exploitation claim in the SolarWinds advisory. Independent reporting also does not establish a known campaign. The Canadian advisory confirms the vulnerability but does not turn it into a confirmed exploited-in-the-wild incident.

There is no public vendor exploit walkthrough. The advisory describes the vulnerability at a high level and does not publish a reproduction chain. This article therefore does not invent one.

The CVSS score is not a probability of exploitation. An 8.8 score describes severity under the CVSS model; it does not mean exploitation is occurring or that every deployment has the same exposure.

How this fits the Observatory's security coverage

Digital Observatory's GitLab CVE-2026-85706 forensic analysis covers a different failure mode: an internet-facing repository service with a path-confinement and authentication problem followed by forensic validation.

The Cisco ISE identity-plane vulnerability covers another administrative boundary, where authentication controls around an identity-management API became the critical security layer.

CVE-2026-28326 adds a lower-level lesson: cryptographic or authentication material embedded into an enterprise product can itself become part of the product's attack surface.

The distinction is useful:

GitLab      → request/path boundary
Cisco ISE   → identity/API boundary
SolarWinds  → product trust-anchor boundary

These are different failure modes even though all can end in privileged execution.

Why this is meaningfully new for Digital Observatory

The Observatory already tracks exploited vulnerabilities, identity systems and software supply-chain incidents. It did not have a recent observation centered on hard-coded cryptographic material as a product-wide trust dependency.

The new evidence is also recent enough to matter operationally: the vendor advisory was published September 17 and the Canadian national CERT issued its advisory September 18.

The main observation is not “SolarWinds is insecure.” It is narrower: when a product ships a static secret that participates in a security boundary, the remediation unit can become the product release itself rather than a customer-specific credential rotation.

Limitations and uncertainty

The vendor has not publicly disclosed enough technical detail to reconstruct the exact RCE chain from the advisory alone. The article therefore distinguishes the reported vulnerability from inferred architectural consequences.

The CVSS AV:A value also means administrators should not assume the flaw is universally reachable over the public internet. Exposure depends on the actual placement and network controls of the ARM deployment.

Finally, no active exploitation is claimed here. That status can change as researchers publish additional technical details, so defenders should monitor the vendor advisory and relevant national vulnerability feeds after upgrading.

Sources and further reading

• SolarWinds — CVE-2026-28326 advisory
• SolarWinds — Access Rights Manager release documentation
• Canadian Centre for Cyber Security — AV26-941
• The Hacker News — SolarWinds ARM vulnerability

Related Digital Observatory coverage: GitLab CVE-2026-85706 forensic response, Cisco ISE identity-plane vulnerability, and CISA VINCE-NT vulnerability disclosure coordination.