SolarWinds patches a hard-coded key that opened remote code execution on Access Rights Manager
On September 17, 2026, SolarWinds shipped a fix for CVE-2026-28326, an unauthenticated remote code execution flaw in Access Rights Manager caused by a hard-coded static key. Apply 2026.2.1 immediately and audit your access-governance tooling for embedded secrets.
September 17, 2026. SolarWinds publishes an advisory for CVE-2026-28326, a flaw in its Access Rights Manager (ARM) product rated 8.8 on the CVSS scale. September 19. The issue is covered publicly, with no evidence of exploitation so far. September 20. Version 2026.2.1 is the only build worth running. Why it matters: the vulnerability comes down to a hard-coded static key, and it leads to unauthenticated remote code execution — inside a tool whose entire job is to control who can reach what.
One key that opens every door
The heart of the problem fits in a single sentence from the advisory: the issue “stems from a hard-coded static key.” Access Rights Manager ships with a static key baked into its code. A static key is not a secret; it is a value that is identical across every installation, distributed with the binary, and therefore known to anyone who has ever extracted, disassembled, or simply downloaded the product.
The consequence is mechanical. If that key protects an authentication token, an encrypted channel, or the validation of a payload, an attacker who knows it can forge whatever is needed to impersonate a legitimate component. SolarWinds is unambiguous about the result: unauthenticated remote code execution. No account, no password, no user interaction is required — just network reach to the service and knowledge of a key that is public by construction, since it is identical everywhere.
The irony writes itself. Access Rights Manager is an access governance product: it exists to provision, audit, and revoke rights across servers, files, and directories. That such a tool is itself pierced by a universal key — the exact opposite of access control — turns a technical flaw into an audit-committee talking point: the vendor selling privilege management was shipping, inside its binary, the equivalent of a master key.
What 2026.2.1 actually fixes
The advisory is short and specific. The flaw affects all versions of Access Rights Manager 2026.2 and earlier. The fix ships in 2026.2.1, the only remediated release. SolarWinds credits researcher Kai Huang, of the Armadin firm, for the discovery and report. The vendor notes it is not aware of any in-the-wild exploitation as of the advisory date — a reassuring detail that changes nothing about the urgency: a fix for unauthenticated remote code execution is not scheduled, it is applied.
The 8.8 CVSS score puts the flaw at high severity, just below the 9.0 threshold reserved for disasters. The attack vector is network, the attack complexity is low, and no privileges or interaction are required. In practice, any ARM instance reachable over a network — including the internal network, where governance tools are often exposed without filtering — is a target.
Two points deserve a CISO’s attention beyond the patch itself. First, the nature of the cause: a hard-coded key is not an isolated mistake but a class of defect that secret scanners and code review are supposed to catch before release. Second, the product’s position: ARM often runs with elevated privileges because it must read directories and push rights. Remote code execution in that context does not just yield a shell — it potentially hands over the entire identity chain.
A vendor under pressure on the identity layer
The flaw does not land in a vacuum. Roughly two months earlier, SolarWinds fixed a critical Web Help Desk flaw — CVE-2026-28323, rated 9.8 — a SAML authentication bypass triggered when SAML 2.0 authentication was enabled. The same bulletin addressed a denial-of-service flaw (CVE-2026-28299, 8.2) that could crash the server through memory exhaustion.
The pattern is revealing. In both cases the defect sits in the authentication layer or the identity layer — SAML on one side, a static key on the other — rather than in some peripheral business function. For a vendor whose portfolio is historically associated with infrastructure and identity management, repeated flaws in that layer are more embarrassing than an ordinary monthly patch: they call into question the robustness of the vendor’s own internal authentication mechanisms.
For a CISO, the read is twofold. This is not about singling out one vendor; it is about recognizing a systemic risk. Access- and identity-management tools concentrate the broadest privileges in the enterprise, which makes them the targets where an authentication flaw causes the most damage. A governance product should never embed a static secret; if it does, that is a signal to segment and monitor it as a critical asset, not treat it as utility software.
How to catch this class of flaw in your own estate
The good news is that this defect class is detectable before the vendor announces it, given the right tooling.
- Scan for embedded secrets. Tools like TruffleHog, gitleaks, and the scanners built into CI platforms detect keys, passwords, and suspicious static strings in repositories, images, and binaries. A static key shares a secret’s signature: a long, random value that is identical from one build to the next.
- Inventory your governance tooling. List ARM, your PAM, your IAM, and any component that manipulates privileges. Record its version, its network exposure, and its privilege level. An unapplied patch on such a tool carries a disproportionate cost.
- Segment the identity surface. These tools should be reachable only from a dedicated administration network, never from the user network and certainly never from the internet.
- Watch for exploitation signals. Code execution on a governance tool leaves traces: abnormal outbound connections, account creation, privilege elevation. The tool’s own access log is the first source to wire into detection.
The broader lesson extends well beyond SolarWinds. A hard-coded key leading to unauthenticated RCE is a scenario found in network appliances, connected devices, and security appliances — anywhere a vendor chose the convenience of an embedded secret over the rigor of per-instance provisioning.
Verdict
If you run SolarWinds Access Rights Manager, apply 2026.2.1 now, and treat any instance on 2026.2 or earlier as compromised by design until it is patched — the fix is all the more urgent because an attack built on a publicly known key is trivial to reproduce. If you do not run it, keep the general rule: any product that holds privileges deserves strict segmentation and priority patch monitoring, because that is where an authentication flaw costs the most. If you maintain software in-house, add embedded-secret detection to your CI pipeline and treat every hit as an incident: a static key that survives code review is a master key waiting to be found.