CISA set a March 22 deadline for Cisco FMC flaw Interlock exploited as a zero-day
CVE-2026-20131 (CVSS 10) in Cisco Secure Firewall Management Center was exploited by Interlock ransomware from January 26. CISA set a March 22 patch deadline.

On 19 March 2026 CISA added CVE-2026-20131 to its Known Exploited Vulnerabilities catalog and gave US federal civilian agencies until Sunday, 22 March to patch or disconnect Cisco Secure Firewall Management Center (FMC). The flaw is an unauthenticated Java deserialization bug that gives root on the box that controls your firewall policy. Amazon's threat intelligence team found the Interlock ransomware group exploiting it more than five weeks before Cisco published a fix.
What happened
Cisco published advisory cisco-sa-fmc-rce-NKhnULJh on 4 March 2026. It describes a critical remote code execution bug in the FMC web management interface, scored CVSS 10.0 and classed as CWE-502 (deserialization of untrusted data). An unauthenticated attacker can send a crafted serialized Java object to the interface and run arbitrary Java code as root. Cisco says no workaround exists.
On 18 March, Amazon's security blog reported that its MadPot honeypot network had recorded Interlock exploiting the bug since 26 January 2026. A misconfigured attacker staging server also exposed the group's toolkit. Cisco updated its advisory to say PSIRT was aware of exploitation attempts. CISA listed the CVE in KEV on 19 March, marked it as known to be used in ransomware, and set the three-day deadline that Binding Operational Directive 22-01 imposes on federal civilian agencies.
According to Amazon, the exploit was an HTTP request to a specific FMC path carrying Java code and two embedded URLs: one served configuration, the other received a file upload confirming success. After that confirmation Interlock pulled down a Linux ELF binary. The post-exploitation kit included:
- A PowerShell reconnaissance script that staged system, browser and RDP data per host on a network share.
- JavaScript and Java remote access trojans using encrypted WebSocket C2, with SOCKS5 proxying.
- A fileless Java backdoor that registered a
ServletRequestListenerto act as an in-memory webshell. - Bash scripts that set up HAProxy relays and wiped logs every five minutes.
- Legitimate tools such as ConnectWise ScreenConnect, Volatility and Certify (for abusing Active Directory Certificate Services).
Who is affected
- Organizations running on-premises Cisco Secure Firewall Management Center Software without the fixed release. Cisco says the bug applies regardless of device configuration. Use the Cisco Software Checker to find the first fixed release for your train.
- Cisco Security Cloud Control (SCC) Firewall Management was also affected, but Cisco patched the SaaS service itself. Customers don't need to do anything.
- Cisco says Secure Firewall ASA and Secure Firewall Threat Defense (FTD) software are not affected. The risk sits in the management plane, not the firewalls it manages.
- Federal civilian agencies are legally bound by the deadline. Everyone else should treat KEV as a priority list.
What it means for developers and engineering teams
Java deserialization bugs are old news. They keep turning up in enterprise appliances because management consoles accept serialized objects over HTTP and trust them before authenticating the caller. Once ObjectInputStream.readObject() runs on attacker-controlled bytes, any gadget chain on the classpath can be turned into code execution. If you build Java services, this is the lesson: never deserialize native Java objects from an untrusted channel. Use a data format such as JSON with a strict schema, or at minimum an allow-list ObjectInputFilter (JEP 290).
The in-memory webshell is a second lesson. A ServletRequestListener registered at runtime leaves nothing on disk, so file-integrity monitoring won't catch it. It disappears on restart, which is one reason to rebuild suspect appliances rather than only patch them.
The bigger architectural point is about management planes. FMC holds policy for every managed firewall, so root on FMC lets an attacker rewrite who can reach what. Many teams lock down production ingress carefully and then leave the admin console reachable from broad internal ranges, or even from the internet. Cisco notes that keeping the management interface off the public internet reduces the attack surface. That holds for any control plane: Kubernetes API servers, CI servers, hypervisor consoles and firewall managers.
What to do now
- Patch FMC to the fixed release that the Cisco Software Checker names for your version. There is no workaround.
- Restrict the management interface to a dedicated admin network or jump host. It should never be reachable from the internet.
- Hunt for compromise back to 26 January 2026, not only since the patch date. Look for unexpected outbound connections from FMC, new or changed firewall rules, unknown processes, and traffic to TCP port 45588, which Amazon lists as an Interlock beacon port.
- Check the IOCs in Amazon's post: exploit source IPs, JA3/JA4 fingerprints, C2 domains, and Certify hashes.
- Audit ScreenConnect and other remote-access tools. Remove any instance you can't account for.
- If you find signs of exploitation, rebuild FMC from known-good media and rotate every credential and key it stored, including firewall admin, LDAP bind and API credentials.
- For your own Java code, grep for
ObjectInputStream,XMLDecoderand permissive Jackson polymorphic typing (enableDefaultTyping) on request paths.
Related on TechLogHub
Sources
- Cisco Security Advisory: Secure Firewall Management Center Software RCE (cisco-sa-fmc-rce-NKhnULJh)
- AWS Security Blog: Amazon threat intelligence identifies Interlock ransomware campaign targeting enterprise firewalls
- BleepingComputer: CISA orders feds to patch max severity Cisco flaw by Sunday
- Help Net Security: Cisco FMC flaw was exploited by Interlock weeks before patch
- Horizon3.ai: CVE-2026-20131 overview


