Cisco FMC unauthenticated Java deserialisation RCE: CVE-2026-20131

CVSS 10.0, no authentication, code execution as root, and 36 days of use as a zero-day by a ransomware crew. Breaking the firewall management hub hands over every policy and log with it.

Overview

Field Detail
CVE CVE-2026-20131
CVSS 10.0 (Critical)
CWE CWE-502 deserialisation of untrusted data
Product Cisco Secure Firewall Management Center (FMC)
Flaw type Unsafe deserialisation of a Java byte stream
Fixed in FMC 7.0.6.1+, 7.2.2.1+, 7.3.1.1+
Disclosed 2026-03-04
Exploited in the wild Yes, as a zero-day with a 36-day window

FMC is the management hub for enterprise firewalls, centralising policy, events and traffic rules for every device. More than 100,000 instances are exposed to the internet.

The flaw itself, unsafe deserialisation of a user-supplied Java byte stream, sounds like an old problem. What makes it miserable is the combination: no authentication, a maximum score, and arbitrary Java code executed as root.

How it was found

The discovery was retrospective. Amazon threat intelligence noticed anomalous activity from the Interlock ransomware group on its MadPot monitoring platform, and further analysis showed the group had been attacking FMC devices since 26 January 2026 using a then-undisclosed zero-day. The researchers reconstructed the full chain from traffic and payloads before passing the intelligence to Cisco.

Cisco validated it and published an advisory on 4 March. CISA added it to the Known Exploited Vulnerabilities catalogue and ordered US federal agencies to remediate by 22 March 2026, only 18 days from disclosure, a deadline that speaks for itself.

Reproduction

Everything below is for authorised security testing, on your own lab instance (FMC evaluation images come from Cisco).

Step one: identify the target. Confirm FMC from the 443 response: the page or headers carry Cisco, Firepower or FMC markers, and an /api/ endpoint returning 401 or 403 still shows a management interface.

Step two: build the payload. Use ysoserial against a gadget chain present in the FMC classpath, CommonsCollections5 in the reported case:

java -jar ysoserial-all.jar CommonsCollections5 \
  "bash -c {echo,<base64 command>}|{base64,-d}|bash" > payload.bin

Step three: send it. POST the byte stream to a web management endpoint such as /api/fmc_platform/v1/auth/generatetoken with Content-Type: application/x-java-serialized-object. Deserialisation on the server runs the object construction logic named inside.

Step four: post-exploitation. With root in hand, attackers typically download and execute a malicious ELF binary and establish persistence with a reverse shell or webshell, which is what was observed in the Interlock chain.

Fix

Upgrade FMC to a fixed release: 7.0.6.1+, 7.2.2.1+ or 7.3.1.1+.

If that is not immediate, take the management interface off the internet, allow only trusted networks and authorised administrators, and tighten policy on the network device:

access-list 1 deny any
access-group 1 in interface mgmt

For detection, review FMC management and audit logs for anomalous deserialisation requests, unexpected Java process creation and suspicious outbound connections, and check for unauthorised configuration changes, odd file writes and unexpected scheduled tasks. On confirmed compromise, isolate the device for full forensics and rotate every credential associated with it.

Verdict

A maximum score, no authentication and a 36-day zero-day window add up to an ideal target. The lesson worth keeping is that firewall management is the gatekeeper of enterprise security while the gatekeeper’s own security has long been a low priority. Once it falls, an attacker rewrites policy, bypasses every control and moves laterally at will.

The second lesson comes from how this was found. Had a third-party threat intelligence team not spotted the activity first, the zero-day window would only have grown. Proactive monitoring earned its keep here in a measurable way.

← Back to all posts

Comments

…