decrypted · 21 september 2026 · ransomware and cybercrime · vulnerabilities and patching · uk policy and law

SolarWinds fixes a hard-coded key in its access rights tool

On Thursday SolarWinds published a fix for a flaw in Access Rights Manager, its product for managing access rights across a company's systems. The flaw is a hard-coded static key, and it lets an unauthenticated attacker run code remotely. SolarWinds does not mention any exploitation, and I will not claim any. But a secret baked into software is one of the oldest design mistakes there is, and this one sits in a tool whose entire job is knowing where your permissions live.

What SolarWinds has said

The advisory covers CVE-2026-28326, scored 8.8 (High) on the CVSS scale. It affects Access Rights Manager 2026.2 and every earlier release, and is fixed in 2026.2.1. The weakness is classed as CWE-321, use of a hard-coded cryptographic key. SolarWinds credited Kai Huang of Armadin with reporting it. The Hacker News, which covered it on Saturday, notes that the advisory says nothing about attacks in the wild.

SolarWinds has not published how the key is used, so I will not guess at the exact route to code execution. What matters is the shape of the mistake.

One key for every door

Imagine a hotel chain that cuts a single master key, builds it into the lock design, and ships identical locks to every branch. Nobody needs to pick anything. Anyone who gets hold of one lock, or its drawings, holds the key to all the others.

A hard-coded key works the same way. It is the same secret inside every installation, so it stays secret only until someone takes one copy of the software apart. After that it belongs to whoever looked. The customer has no obvious way to change it, which is presumably why SolarWinds' fix is a new version rather than a setting.

What a defender can do

In my reading, an attack like this involves no login, so there is no run of failed passwords to alert on. What you can control is knowing where the product is and who can reach it.

As the name suggests, Access Rights Manager is built to manage access rights, so my inference is that a server running it is well connected to the systems whose permissions it tracks. That makes it a poor place to be surprised.

Find every installation, including forgotten test ones, and upgrade to 2026.2.1.
Until that is done, limit network access to the server to the administrators and collectors that genuinely need it.
If you cannot patch promptly, ask SolarWinds directly what the exposure looks like.

The Secure by Design lesson

The NCSC's Software Security Code of Practice implementation guidance is blunt: "You should avoid hard-coded credentials in your software." It also asks vendors to identify every credential that would cause harm in the wrong hands, naming passwords, certificates and API keys. The Code, produced by DSIT and the NCSC, is voluntary.

The design decision that prevents this flaw is dull. Generate a unique secret when each installation is set up, or keep it in a proper secret store, instead of compiling one into the product. The cost is some engineering work for the vendor, once. The cost of skipping it is paid by every customer at the same moment, the day someone extracts the key.

For UK buyers, that turns into a procurement question rather than a technical one. Ask suppliers, especially those whose tools hold privileged access to your directories, to show how they meet the Code and how their product handles keys. A vendor that cannot answer in a paragraph has told you something useful. Buying software that manages access to everything else means your control over your own systems depends on decisions made in someone else's build process. You are entitled to ask to see them.

Also this week

ShinyHunters takes on Clop. The extortion group ShinyHunters defaced the data leak site of the Clop ransomware gang, reportedly through an unauthenticated file upload flaw in Grav CMS. BleepingComputer confirmed the defacement and the message left on the site. ShinyHunters also claims it took source code, logs and the private keys for Clop's Tor service, and says it will try to extort Clop; BleepingComputer has not verified those claims, and neither can I. If you are a victim already listed on that site, nothing reported so far suggests your data has been deleted. Leak sites are how victims learn what has been published about them, so this is a good week to check what is listed against your name and your suppliers'.

Children, age checks and two legal routes. On 17 September the European Commission proposed the EU KIDS Act: no accounts under 13, limited parent-controlled accounts for 13 and 14, and fines of up to 6% of global annual revenue. It also wants privacy-preserving age checks, using an open-source EU tool expected by year-end. The UK is not bound by this and is taking its own route. The government announced an under-16 ban in June, to be made through regulations under the Children's Wellbeing and Schools Act 2026, with protections expected in spring 2027. Ofcom's study on age assurance is due by October 2026. Privacy advocates cited by the IAPP worry about how well age checks work and what they do to data protection. The design question is the same on both sides: a check that collects identity data creates a new store of it.

Sources

If you want a second opinion on how your suppliers handle secrets and privileged access, get in touch.