Cisco published two separate Cisco Integrated Management Controller advisories on April 1, 2026. Together they cover an unauthenticated auth bypass and multiple authenticated command injection and remote code execution flaws in the IMC web interface.
For operators, the useful detail is not the CVE count. It is the blast radius. Cisco says the affected surface includes UCS C-Series, UCS E-Series, UCS S-Series, 5000 Series ENCS, Catalyst 8300 Series Edge uCPE, and several security and telemetry appliances that expose the IMC UI.
There are no workarounds for either advisory. If you manage one of these platforms, this is a patch-first event.
What changed
| Advisory | Attack precondition | Impact | Fix status |
|---|---|---|---|
| IMC authentication bypass | Unauthenticated, remote | Bypass auth and gain Admin access | Software update only |
| IMC command injection and RCE | Authenticated, remote | Execute commands or code as root | Software update only |
The authentication bypass advisory is CVE-2026-20093. Cisco says a crafted HTTP request against the change-password flow can let a remote unauthenticated attacker bypass authentication, alter user passwords, and reach the system as Admin.
The command injection and RCE advisory covers CVE-2026-20094, CVE-2026-20095, CVE-2026-20096, and CVE-2026-20097. Cisco splits them into two practical buckets:
- CVE-2026-20094 affects an authenticated attacker with read-only privileges and can lead to root-level command execution
- CVE-2026-20095 through CVE-2026-20097 require authenticated admin-level access and can also lead to root-level code execution
That distinction matters less than it would on paper. If the management plane is exposed and the IMC is vulnerable, the attacker can cross from web UI access to full host control.
Who should treat this as urgent
The first responders are the teams that expose IMC on internet-reachable or broadly reachable management networks.
That includes:
- data center teams running UCS C-Series racks in standalone mode
- edge teams using 5000 Series ENCS or Catalyst 8300 Series Edge uCPE
- security teams operating Secure Firewall Management Center, Secure Endpoint Private Cloud, or Secure Malware Analytics appliances that use the affected IMC base
- platform teams with UCS E-Series or S-Series hardware in production
If you only own the underlying server and not the appliance wrapper, you still need to check the appliance guidance. Cisco notes that some appliances based on UCS C-Series hardware need platform-specific remediation, not just a straightforward IMC upgrade.
Fix matrix
The safest operational question is: what release do I need to get to?
| Platform | First fixed release |
|---|---|
| 5000 Series ENCS | NFVIS 4.15.5 |
| Catalyst 8300 Series Edge uCPE | NFVIS 4.18.3 |
| UCS C-Series M5 Rack Server | IMC 4.3(2.260007) |
| UCS C-Series M6 Rack Server | IMC 4.3(6.260017) or 6.0(2.260044) |
| UCS E-Series M3 | IMC 3.2.17 |
| UCS E-Series M6 | IMC 4.15.3 |
| UCS S-Series Storage Server | IMC 4.3(6.260017) |
Two details stand out here.
First, some platforms need a migration instead of a direct minor upgrade. Cisco explicitly calls out releases where the path is "migrate to a fixed release."
Second, several appliance families have separate remediation steps. Cisco lists special handling for Cisco Telemetry Broker, IEC6400 Edge Compute Appliances, Secure Endpoint Private Cloud, Secure Firewall Management Center, Secure Malware Analytics, and Secure Network Analytics appliances.
If you run any of those, use the appliance-specific remediation path in the advisory instead of assuming the generic IMC release table is enough.
Why this is operationally serious
This is the kind of bug class that tends to get underestimated because the vulnerable component sounds like "management software."
IMC is not a cosmetic admin panel. It is the control surface for hardware-level operations, and Cisco's own advisories show how far an attacker can get once that surface is exposed:
- unauthenticated access in the auth bypass case
- authenticated but low-privilege access in one command injection case
- authenticated admin access in the others
- root-level command execution as the end state
That combination creates a bad failure mode for fleet operators. A single exposed management interface can turn into full host compromise, and the fix requires firmware or platform upgrades, not just a config change.
A practical response sequence
If you are responsible for these systems, I would handle this in three passes.
- Inventory every platform that exposes Cisco IMC, including appliances that are built on UCS C-Series hardware.
- Map each system to the exact Cisco release family and fixed version in the advisory.
- Patch the exposed or internet-adjacent systems first, then work inward to isolated management domains.
That order matters because the vulnerability is in the management plane. The highest-risk systems are the ones you can reach without crossing several other trust boundaries.
What to watch for during rollout
The main risk is not just downtime. It is upgrade complexity.
Some fleets will be able to take a direct IMC upgrade. Others will need a firmware auto-upgrade path, a host upgrade utility, or a vendor-specific appliance procedure. That means the real work is usually coordination, not just clicking "update."
Before you start, verify:
- the exact hardware family
- the current IMC or NFVIS version
- whether the platform exposes the IMC UI directly
- whether the appliance has a special remediation path
If you do not have those four answers, you do not yet know your exposure.
Final note
This is a good example of why infrastructure security still starts with inventory. The vulnerability is severe, but the remediation path depends on the platform family, the release train, and in some cases the appliance wrapper on top of Cisco IMC.
Patch the exposed systems first, follow the vendor-specific upgrade path, and treat management interfaces as production attack surface.