Out-of-band management systems are standard equipment in modern data centers. They allow administrators to manage servers even when the actual operating system has long since stopped responding – from a reboot through firmware updates all the way to a complete re-installation. Every manufacturer relies on their own ecosystem here: HP on „HP Integrated Lights-Out“ (HP iLO), Dell on „integrated Dell Remote Access Controller“ (iDRAC), and Cisco on the “Cisco Integrated Management Controller” (Cisco IMC). The latter is used on the widely deployed Cisco UCS C-Series rack servers and S-Series storage servers.

These systems are especially attractive from an attacker’s perspective: whoever controls the management controller effectively sits „below” the operating system. The IMC can update the BIOS, configure SecureBoot, and thereby interact directly with the operating systems running on the server. In that sense, an operating system for the operating system. If an attacker gets in here, they effectively control the server and all the systems running on it.

And it was in exactly such an important component during an security assessment where we found a critical vulnerability that enables a complete system takeover as the root user. This security flaw also enabled us to glimpse behind the curtain of the otherwise very closed Cisco IMC ecosystem, at the operating-system level.

Note

The vulnerability was discovered over the course of a commissioned assessment and reported to Cisco as part of a responsible disclosure. Cisco has confirmed the flaw and provided a patch. NSIDE has also compiled the advisory NSIDE-SA-2026-003 on this.

Attacks on other people’s systems without explicit permission are illegal and must not be carried out!

Where the flaw lies: the detour via an SSH key

The Cisco IMC web application offers users a convenient feature: they can register their public SSH key for access in various ways. The key can be pasted directly, uploaded as a file, or even downloaded from another server – for example via FTP or HTTP.

And it is precisely this last, convenient, variant that is the pitfall. If you instruct the web application to fetch an SSH key from a remote server, the backend runs a script in the background with the parameters from the API call passed to it. Simplified, the script call looks like this:

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

This script takes the parameters and passes them to curl to actually download the file. At first glance this sounds harmless – but it isn’t.

A download turns into code execution

The problem with this solution: due to a lack of sanitation, the user-controlled parameters are not fully filtered before they are passed on to curl. This makes it possible to smuggle additional curl arguments into the call. This is referred to as an argument injection – the attacker influences not only what is downloaded, but how curl is invoked.

One thing, some of you may not even be aware of: curl is more powerful than one would credit a pure „download tool“. Whoever controls the invocation arguments can use it not only to download files, but also to write and read files on the target system. And it goes even further: via loaded libraries, the whole thing can be driven all the way to executing one’s own commands. What was the inconspicuous „please fetch me this SSH key” thus turns into arbitrary reading and writing of files – including code execution.

The absolutely decisive point here: both the script and curl run with root privileges. Full control over the curl command therefore does not mean some limited execution, but a complete takeover of the management controller’s operating system as an absolute super-user.  To make the attack easier and reproducible, NSIDE has published the tool CIMCown on Github.

How critical is this?

The vulnerability is rated with a CVSS score of 9.8. In practice this means: an attacker does need valid credentials, but low-privileged accounts – e.g. read-only users – are already sufficient. The flaw is exploitable over the network, leads to a change of scope, and results in the complete loss of confidentiality, integrity, and availability.

One should be clear about what a compromise of the IMC means: the controller sits in a position where it can influence the BIOS and SecureBoot and interact with the operating system above it. An attacker who gains root here can thereby nest themselves deeply and persistently in the system – far below what classic protective measures such as EDR solutions at the operating-system level can even see. The trust anchor of the entire server hardware is thus compromised.

Countermeasures

The most important measure is to promptly update to the latest version, in which the vulnerability is closed. If an update is not possible at short notice, we recommend completely disabling the web interface (web UI) in order to block the affected attack path.

Beyond that, the following applies to management controllers as well as the Cisco IMC in general: such interfaces should never be exposed openly to the internal and especially a public network. A strictly segmented, separate management network, restrictive access controls, and a clean rights-and-roles concept significantly reduce the attack surface – and ensure that a single vulnerability does not immediately endanger the entire data center. Nevertheless, it is no substitute for an update!

Conclusion

This vulnerability shows once again how a convenient feature can turn into a serious security risk. An in itself sensible option to load SSH keys via HTTP becomes, through insufficiently filtered parameters, a complete system takeover as root. The actual mistake here is a classic: user input that flows unchecked into a system call.

Out-of-band management is a powerful tool – but it is precisely this power that makes the systems behind it a worthwhile target. Anyone who operates them should secure and regularly review them with the same seriousness as the productive systems themselves.

NSIDE can support you on this topic with the following services:

  • Penetration tests of the external and internal infrastructure
  • Security analysis of management interfaces and out-of-band systems
  • Review of network segmentation and hardening of management networks
  • Passive and active OSINT analyses

If you have questions or need support in reviewing your infrastructure, do not hesitate to contact us.

The vulnerability was discovered by Christoph Peil (NSIDE ATTACK LOGIC GmbH) and published under CVE-2026-20200.