TL;DR - SolarWinds published an advisory on 17 September 2026 for CVE-2026-28326, a CVSS 8.8 unauthenticated remote code execution flaw in Access Rights Manager (ARM) that stems from a hard-coded static key in the shipped product. All versions up to and including ARM 2026.2 are affected; the fix is ARM 2026.2.1. The same patch cycle closed a CVSS 9.8 SAML bypass (CVE-2026-28323) and a CVSS 8.2 memory-exhaustion denial of service (CVE-2026-28299) in Web Help Desk, plus 16 flaws in Serv-U. SolarWinds says it has no evidence of exploitation in the wild for the ARM flaw. Treat it as a same-week patch anyway, because ARM typically sits in a management VLAN with a domain-privileged service account behind it. What you need to do: patch ARM to 2026.2.1 and Web Help Desk to 2026.2.1 in the same window, then audit what can reach the ARM service port.
Hard-coded keys are the most irritating class of finding in this job. The fix is trivial, the exposure is total, and the whole thing was shipped by the vendor rather than introduced by you. There is no configuration mistake to point at, no hardening step you skipped, no patch you were late on. The secret is in the product. Anyone who can reach the port has it.
I have spent enough time on discovery calls for management-plane tooling to know the shape of the conversation that follows. Someone asks whether the tool is exposed to the internet, the answer is no, and the room relaxes. The next question is what the tool can reach, and the room stops relaxing.
By the numbers
| Metric | Detail |
|---|---|
| CVE | CVE-2026-28326 |
| CVSS score | 8.8 (high) |
| Product | SolarWinds Access Rights Manager (ARM) |
| Root cause | Hard-coded static key in the shipped product |
| Impact | Unauthenticated remote code execution |
| Affected versions | All versions 2026.2 and prior |
| Fixed in | ARM 2026.2.1 |
| Advisory date | 17 September 2026 |
| Reporter | Kai Huang, Armadin |
| Known exploitation | None reported by the vendor |
| Same-cycle fixes | WHD CVE-2026-28323 (CVSS 9.8), WHD CVE-2026-28299 (CVSS 8.2), 16 Serv-U flaws |
What the ARM flaw actually is
The SolarWinds advisory is short and specific. Access Rights Manager was reported to be affected by an unauthenticated remote code execution vulnerability, and the issue stems from a hard-coded static key. That is the whole root cause in one sentence.
The distinction between authenticated and unauthenticated matters more here than the CVSS number does. An authenticated flaw requires the attacker to already hold a valid credential, which means they already passed whatever gate sits in front of the application. An unauthenticated flaw requires nothing beyond network reachability. The request does not have to belong to anyone. They need a route to the service.
CVSS 8.8 is a high score, not a critical one, and it is worth understanding why the calculator lands there rather than at 9.8. The score reflects the impact on confidentiality, integrity and availability alongside the attack vector, complexity and required privileges. An unauthenticated network-reachable flaw that yields code execution as the application's service identity lands high. It does not land at critical unless the impact assumptions push it there.
That scoring nuance is exactly where people misread the risk.
The score is a property of the vulnerability in isolation. The risk is a property of the vulnerability in your estate.
Those two numbers are frequently far apart, and for access-management tooling they are usually far apart in the direction that hurts.
SolarWinds credited Kai Huang of Armadin for discovering and reporting the flaw. The vendor makes no mention of exploitation in the wild, and as of the advisory there is no CISA KEV entry. That is the good news, and it should not change your sequencing. Hard-coded credential flaws tend to attract attempts quickly once a write-up exists, because the exploit primitive is a static value that does not need to be reverse engineered from a binary diff.
Why a hard-coded key is worse than it sounds
There is a reasonable instinct that says a hard-coded key is a medium finding. The key is fixed, so it must be an encryption key for stored data, and stored-data encryption breaks are usually a low-severity information disclosure because the attacker still needs local access to the files.
That instinct does not survive contact with how these bugs actually work. A static key in a service product is typically used to sign, encrypt, or authenticate something in the request path. If the application accepts a request that carries a token or payload protected by that key, and the key is identical in every deployment, then the application is effectively validating requests against a secret the attacker also holds. The signature check passes. The request is accepted. The code path that follows runs with the service's privileges.
That is why this specific flavour of finding keeps producing remote code execution rather than information disclosure. The key sits in the trust boundary, not next to the data.
The second reason it is worse than it sounds is the diffusion problem. Every affected deployment shares the same secret, so a single extraction works everywhere. There is no per-tenant key to rotate, no customer-specific material to keep private. One published value, every instance.
The third reason is disclosure half-life. A static key cannot be rotated by the customer. There is no config file to change, no key vault to update. The only remediation is a vendor patch that removes the static value, which means every affected deployment stays exposed until the vendor ships and you install. There is no interim hardening step you can take that actually removes the exposure, which is unusual for a high-severity finding.
The rest of the SolarWinds week
The ARM flaw landed in a patch cycle that shipped three separate problems across three products, and the two WHD items deserve a look because one of them scores higher than ARM does.
Web Help Desk CVE-2026-28323, CVSS 9.8. A SAML authentication bypass when the SAML 2.0 authentication method is enabled. A CVSS 9.8 authentication bypass on a helpdesk platform is the more dangerous of the two in most estates, because helpdesk systems hold ticket data, frequently integrate with identity systems, and are often reachable by a wider population than a rights-management console is. If SAML is enabled on your WHD instance, that configuration is now a direct path around authentication.
Web Help Desk CVE-2026-28299, CVSS 8.2. A denial of service caused by insufficient memory handling that can crash the WHD server. Denial of service reads as the least interesting of the three until you remember that the helpdesk is the system your staff use to report problems. Crashing it during an incident removes your intake path.
Both are resolved in WHD 2026.2.1. The affected Web Help Desk versions and the Serv-U details are in the SolarWinds trust centre advisories rather than in the news write-ups, and they are worth reading directly rather than relying on a summary.
Serv-U. SolarWinds released fixes for 16 flaws spanning CVE-2026-28302, CVE-2026-28304 through CVE-2026-28317, and CVE-2026-28321. The impacts listed include privilege escalation, remote code execution, and the creation of administrator accounts. Serv-U is a file transfer product, and file transfer servers are a favourite target precisely because they sit close to data stores and often bridge network segments by design.
Where ARM actually sits in your estate
This is the part of the post that matters more than the CVE.
Access Rights Manager does what the name says. It reads permissions across Active Directory, file servers, SharePoint, Exchange and other systems so you can answer questions about who can reach what. To do that job it needs broad read access, and in practice it needs a service account with substantial rights across the directory and the file systems it audits. It also has to be reachable from the systems it queries, and its console has to be reachable by the administrators who use it.
That combination produces a specific exposure shape:
- The ARM server usually lives in a management network segment. Management segments are frequently less monitored than production segments, because the assumption is that only trusted tooling lives there. That assumption is doing a lot of work in a lot of estates.
- The service account behind ARM is usually privileged across the directory. It is not a read-only account in the narrow sense. It reads broadly, and broad read access across a directory is a reconnaissance goldmine even without write rights.
- The console is often reachable from a jump host or VPN pool rather than from a single admin workstation. Lateral movement inside that pool puts an attacker one hop from the console.
- The tool is frequently a single instance. Nothing sits in front of it to absorb a compromise, and there is no second deployment to compare against. One server, one blast radius.
An unauthenticated RCE in that position is not a vulnerability in a peripheral system. It is a foothold on the platform that tells the attacker exactly where the valuable permissions are.
What to do this week
- Inventory first, patch second. List every SolarWinds product in the estate with its version. ARM, WHD and Serv-U are the three in this cycle, and the answer for a lot of ANZ SMBs is "one of these, inherited, and nobody is certain which version". Get the version from the product's own about screen rather than from memory or the original deployment document.
- Patch ARM to 2026.2.1 and WHD to 2026.2.1. These are vendor-published fixed versions, not workarounds. Because the ARM root cause is a static key in the shipped product, there is no configuration change that removes the exposure. The patch is the remediation.
- Establish reachability before you establish severity. From a host outside the ARM server's own segment, test whether you can open a connection to the ARM service. If the answer is yes from anywhere other than the admin jump host, that is a finding in its own right and it should be raised separately from the CVE.
- Check who the ARM service account is, and what it can reach. Write it down. If the account has domain-wide read or any write delegated beyond its own scope, note that as the blast radius and take it to whoever owns the risk register. You are not necessarily going to reduce those rights today, but the number should be visible to someone other than you.
- Assume nothing about the WHD SAML configuration. If SAML 2.0 authentication is enabled, CVE-2026-28323 is an authentication bypass. Check whether it is enabled, and if it is, treat WHD as the higher-priority patch of the two despite the lower product profile.
- Search for the indicators after patching. No exploitation is reported, so this is a precaution rather than an incident response. Look for unexpected local accounts, unfamiliar scheduled tasks, new administrative group memberships, and configuration changes around the ARM and WHD services in the window since the advisory. If you have centralised logging and the retention to cover it, review authentication to the ARM console.
- Confirm your backup and rollback position before you touch the ARM server. Rights-management databases are not the sort of thing you want to rebuild from scratch on a Friday afternoon. Take the snapshot, confirm the vendor's upgrade path from your current version, and schedule the work.
Frequently asked questions
Is the SolarWinds ARM flaw being exploited in the wild? SolarWinds makes no mention of exploitation in the wild in its advisory, and there is no CISA KEV entry at the time of writing. That can change quickly once exploit details circulate. The absence of reported exploitation is not a reason to extend your patch window.
What is a hard-coded key vulnerability in plain terms? The product ships with a fixed secret value built into it, identical in every deployment. If that value is used to authenticate or validate requests, an attacker who knows the value can construct requests the application accepts. Because it is in the product rather than your configuration, you cannot rotate it, and the only fix is a vendor patch.
Does CVE-2026-28326 require authentication to exploit? No. The unauthenticated classification is the whole point of the finding. An attacker needs network reachability to the ARM service and nothing else. Credentials are not part of the picture at all.
What version fixes it? ARM 2026.2.1. All versions up to and including ARM 2026.2 are affected.
Should I patch WHD before ARM? If SAML 2.0 authentication is enabled on your Web Help Desk instance, yes. CVE-2026-28323 is a CVSS 9.8 authentication bypass in that configuration. Patch both in the same window if you can, and if you have to sequence, sequence by which one is reachable by more people.
We do not use any SolarWinds products. Does this affect us? Not directly. It does affect you indirectly if one of your MSP clients runs ARM, because your client's management plane is a route into your client's directory. Ask the question in your next service review.
Where do I get the fixed versions? From the SolarWinds customer portal. The trust centre advisories carry the version numbers and the affected ranges.
My Take
The thing that sticks with me about this cycle is not the hard-coded key. It is that the highest-scoring flaw in the batch, the CVSS 9.8 SAML bypass, is in the product nobody in the room mentions when you ask what the SolarWinds estate looks like.
Access Rights Manager is the product people remember, because rights management is conceptually alarming and it sits near identity. Web Help Desk is the product people forget, because a helpdesk feels like a workflow tool rather than a security surface. It holds ticket histories that frequently contain credentials people pasted in, it integrates with identity providers, and it is exposed to a much wider population of users than an admin console is. An authentication bypass there is not a footnote to the ARM finding. In a lot of estates it is the more urgent of the two.
The hard-coded key is the cleaner story and it is the one that will get written up everywhere. If you only action one thing from this week, action the one with the higher score, and check whether SAML is even enabled before you decide which that is.
There is a broader pattern here that I expect to keep writing about. The management plane has been the soft target for a while, and the reason is structural rather than careless. These tools need broad access to do their job, they are trusted by definition, and they are rarely put through the same exposure review as the systems they manage. The tool that audits permissions is not usually the tool that gets the penetration test. That is the gap, and it is not closed by patching.
Further reading
- SolarWinds Trust Center: CVE-2026-28326 advisory for Access Rights Manager
- SolarWinds: ARM 2026.2.1 release notes
- SolarWinds Trust Center: CVE-2026-28323 advisory for Web Help Desk (the same release closes CVE-2026-28299)
- The Hacker News: SolarWinds Patches ARM Hard-Coded Key Flaw Enabling Unauthenticated RCE (17 September 2026)
- CISA: Known Exploited Vulnerabilities catalog
- SecureInSeconds: PaperCut NG/MF zero-day - the print server checklist for MSPs
- SecureInSeconds: Metabase zero-day - what to do in your first week and your second
Mathew Clark / Founder, SecureInSeconds / Currently: of the view that a management VLAN is a security boundary only for as long as somebody treats it like one
