Cisco's rack-server controller sat below the OS — CVE-2026-20200 turns a "download my SSH key" button into root, with a public PoC already out

Cisco Integrated Management Controller (IMC) is the out-of-band console welded to every UCS rack server — the thing you reach when the operating system on top of it is unresponsive, unbootable, or doesn't exist yet. It can reflash firmware, flip SecureBoot, and power-cycle the box from a network port that's supposed to be reachable only by the people who run the data center. On August 5, 2026, Cisco disclosed that a low-privilege, already-authenticated IMC user could turn a routine convenience feature into a root shell on that console — no exploit chain, no privilege escalation bug needed, just one unsanitized parameter.

The feature that leaks into root

The bug lives in a feature nobody thinks twice about: registering an SSH public key for IMC access. Cisco's web UI offers three ways to supply that key — paste it, upload a file, or have the controller fetch it itself from a remote FTP or HTTP server. That third option is where it breaks. Per the researcher who found it, Christoph Peil of NSIDE ATTACK LOGIC, requesting a remote key download runs a backend script along these lines:

/etc/scripts/download_ssh_keys.sh http 123.123.123.123 /tmp/example.ssh.pub

That script hands its parameters straight to curl. Cisco's own advisory calls the flaw "improper validation of user-supplied input"; NSIDE's writeup is more specific — the user-controlled parameters aren't fully filtered before curl sees them, so an attacker can smuggle in extra curl arguments rather than just a hostname. curl is a genuinely powerful primitive once you control its full argument list: it can write files, read files, and — through its config-file and library-loading options — get all the way to running arbitrary commands. The part that makes this a full server takeover instead of a curl sandbox escape: "both the script and curl run with root privileges," per NSIDE.

Two severity scores for the same bug

Cisco's CVSS 3.1 vector scores this 8.8 (Scope: Unchanged). NSIDE's own advisory, NSIDE-SA-2026-003, rates the same flaw higher — its blog post cites 9.8. The likely driver of the gap is scope: Cisco's vector treats the vulnerable component and the impact as staying within the same authority boundary, while NSIDE's framing (a management-plane bug reaching into BIOS/SecureBoot, a fundamentally different trust layer) leans toward a scope change. Neither number is wrong on its own terms — they're answering slightly different questions about what "the vulnerable component" is.

What's actually affected

CVE-2026-20200 is one of two CVEs in the same advisory (cisco-sa-cimc-arg-inject-upSHdMfU); the other, CVE-2026-20288, requires admin privileges and scores 6.5. Both share the argument-injection root cause. CVE-2026-20200 specifically needs only a low-privilege IMC account, which is what makes it the more dangerous of the pair.

No workaround — and a public PoC toolkit already exists

Cisco's advisory is blunt: "there are no workarounds that address these vulnerabilities." There's no config flag to flip that closes the argument-injection path while leaving the SSH-key feature usable. The only fix is the firmware upgrade. Meanwhile, days after Cisco's fix shipped, Peil published CIMCown — a Python/Go toolkit on the NSIDE ATTACK LOGIC GitHub org — that operationalizes the bug. It requires valid IMC credentials and a target host, then offers:

• test — connect and pull /etc/passwd, to confirm the primitive works
• download — retrieve arbitrary files from the target, e.g. /etc/shadow
• upload — push files to the device, such as a socat binary
• build — compile a Go-based reverse shell payload for the operator's own IP
• shell — deploy and trigger that reverse shell against the target

Why the EPSS score looks low for an 8.8 with a public PoC

CVE-2026-20200 carries an EPSS score of 0.84% (54.5th percentile) — unremarkable next to its CVSS. That's not EPSS mis-scoring the bug; it's a legitimate reflection of the PR:L requirement. Unlike an unauthenticated pre-auth RCE, this flaw needs a valid IMC login before the argument injection ever fires, which cuts down the realistic population of opportunistic attackers even with a public tool in hand. The honest read: EPSS is telling you exploitation is comparatively unlikely at internet scale, not that the consequence is small if it does happen. For a management controller with BIOS-level reach, low likelihood and severe consequence can both be true at once — that's exactly the profile that argues for patching on the advisory's own severity rating rather than waiting on EPSS to catch up.

What to do now

1. Identify every standalone UCS C-Series (M5–M8), S-Series, and appliance built on that hardware that exposes the IMC web UI — including ones you inherited pre-integrated inside another Cisco product.
2. Patch to the fixed IMC release for your platform from the table above. There is no partial mitigation short of the firmware update.
3. If you can't patch immediately, disable the IMC web interface entirely — Peil's own recommendation, and the closest thing to a workaround that exists.
4. Restrict network reachability to IMC/BMC interfaces to a dedicated out-of-band management network — never expose them to a general internal network, let alone the public internet.
5. Audit which accounts hold IMC login credentials at all; PR:L is the only barrier this bug has, so credential hygiene on the controller itself is now a meaningful control.

Scores and exploitation status current as of 2026-08-10