According to The Hacker News's coverage of the disclosure, CVE-2026-28326 stems from a static cryptographic key embedded directly in Access Rights Manager's code, present identically across every version 2026.2 and earlier. Security researcher Kai Huang of Armadin is credited with finding it; SolarWinds' own Trust Center advisory, published 17 September, confirms the flaw allows unauthenticated remote code execution and has been fixed in ARM 2026.2.1. SolarWinds says it has no evidence of exploitation in the wild. That's a genuinely different starting position from most of the vulnerabilities that end up in this newsletter, and it's worth taking at face value - but it doesn't change what the underlying design flaw is, or how long it's plausible it's been sitting there unnoticed.
Why a hard-coded key is worse than an ordinary bug
Most remote code execution flaws are logic errors: a missing check, a bad deserialisation path, something a patch removes and a rebuild replaces. A hard-coded key is a design decision, and it doesn't behave like a normal bug once it's out. Every installation of the affected ARM versions ships with the same secret, which means one person extracting that key from one copy of the software - through decompilation, a leaked build, or simply buying a licence - has the key for every other customer's deployment too, not just their own. There's no way for an individual customer to rotate their way out of exposure, because the key was never customer-specific in the first place; the only fix is the vendor patch itself.
ARM isn't just another app - it's the thing that decides who else has access
Access Rights Manager exists to answer a specific question for large organisations: who has permission to what, across Active Directory, Exchange, file servers and beyond, and whether any of those permissions have drifted from what was actually approved. That makes it a management-plane tool in the fullest sense - compromising it doesn't just hand an attacker one system, it hands them visibility into, and potentially control over, the permission structure of everything ARM was deployed to govern. An unauthenticated RCE in a tool with that job description is the same category of risk as the hardcoded-account bug CISA added to its exploited list in Cisco Secure Firewall Management Center back in August, or the authentication bypass N-able has now patched four times in five weeks in N-central: the product whose entire value proposition is administrative oversight becomes, if it's compromised, the fastest route to compromising everything it oversees.
This isn't SolarWinds' first admin-tooling scare this year
ARM's disclosure lands eight months after SolarWinds shipped emergency fixes for a CVSS 9.8 SAML authentication bypass in Web Help Desk, reported by The Hacker News in January, and a batch of sixteen separate vulnerabilities patched in Serv-U across the same year - flaws spanning privilege escalation, remote code execution and unauthorised admin account creation. None of these three products share code, but they share a customer base: IT and security teams who bought SolarWinds specifically to centralise administrative control, six years after Sunburst made "trust in this vendor's software supply chain" the industry's most expensive lesson of the decade. A hard-coded key in the newest of the three doesn't reopen that old wound directly, but it's a reminder that the lesson was about process and architecture, not about one specific incident that's now safely in the past.
- Patch every Access Rights Manager instance to 2026.2.1 now - this is unauthenticated RCE in a tool that typically holds domain admin equivalent visibility, regardless of whether exploitation has been confirmed yet.
- Don't let "no evidence of exploitation" set your patch timeline - a hard-coded key that's been shippable since at least version 2026.2 could have been extracted by anyone who bought or leaked a copy of the software at any point since.
- Review whether your ARM deployment is reachable from anywhere it doesn't strictly need to be; unauthenticated RCE against an internet-facing instance is a materially worse exposure than the same flaw on a segmented internal network.
- Ask every vendor whose product manages access, identity or permissions elsewhere in your estate - not just SolarWinds - whether any of their cryptographic material is shared across customers rather than generated per deployment.
- When evaluating administrative and management-plane tooling going forward, ask the vendor directly how secrets are generated and scoped - a supplier that can't answer clearly is telling you something about how the product was built.
Tools built to manage everyone else's access deserve more scrutiny than the systems they govern, not less - and a shared key baked into the product is exactly the kind of design flaw that scrutiny is meant to catch before it ships. If you'd like help auditing where administrative tooling sits in your own attack surface, email sales@halfteck.com.