CVE-2026-20131: The 36-Day Invisible Breach Inside Cisco Firewalls

Your firewall is supposed to be the wall between your network and attackers. The system that manages that firewall — the control panel where your security team sets the rules — is supposed to be even more locked down. Nobody gets in without credentials. Nobody changes policies without authorisation.

On January 26, 2026, the Interlock ransomware group didn't break into Cisco firewalls.

They logged into the system that controls them — without a password, without an account, and without triggering a single alert.

Amazon's security team discovered the exploitation while running a network of decoy systems designed to attract attackers. They watched Interlock operate inside compromised Cisco firewalls for over a month before the vulnerability was publicly known. The patch arrived on March 4, 2026. By then, the attackers had already been inside some networks for five weeks.

This wasn't a firewall bypass.

This was control over the system that decides what the firewall allows.

Root Cause — Why the Control Panel Had an Unlocked Back Door

Cisco's Firewall Management Center is the dashboard where network security teams manage all their Cisco firewalls from one place. Add a rule to block a threat. Update a policy. Review traffic logs. It's the command centre for the entire network's defences.

To do its job, the FMC's web interface constantly receives and processes data. When you interact with a management system, information travels back and forth between your browser and the server — packaged up, sent across the network, unpacked and acted upon at the other end.

The vulnerability is in how FMC unpacks that data. The software uses a standard format called Java serialisation — the same "notepad passed back and forth" mechanism we covered in the SharePoint RCE post. FMC receives a package of data and rebuilds it into live objects it can act on. The problem: it does this before checking who sent the package.

An attacker sends a specially crafted package to the FMC management interface. FMC opens and processes it — running the instructions inside — before ever asking "who are you?" or "are you allowed to be here?" By the time any authentication check would happen, the attacker's code is already running as the most powerful user on the system: root.

Root access means complete control. Not just over the management interface — over every firewall that management interface controls. An attacker with root on the FMC can rewrite firewall rules, disable security alerts, remove logging so their activity disappears from records, and use the management server as a launching point to reach every other system on the network.

Attack Surface — Who Is Exposed

Any organisation running Cisco Secure Firewall Management Center on its own servers — not using Cisco's cloud-hosted version — is directly vulnerable. This includes universities, hospitals, government agencies, banks, and manufacturing companies. Interlock has specifically targeted all of these sectors.

The risk multiplies because of what FMC controls. Most enterprise security tools protect one layer — an endpoint, a server, a network segment. FMC is the single system that manages the rules for all firewall devices in an organisation. Compromising it doesn't give attackers access to one thing. It gives them the keys to disable, bypass, or manipulate every network security control in the building.

This is the shift happening in 2026.

Attackers are no longer targeting endpoints first. They are targeting the systems that manage security itself — because one compromise there scales across the entire organisation.

Amazon's CISO described it directly: attackers who compromise the FMC gain the ability to "blind" defenders before deploying ransomware. They turn off logging. They modify rules to allow their own traffic. They ensure that when the ransomware payload arrives, the security tools that should alert on it have already been quietly disabled.

Exploit Chain — 36 Days Nobody Noticed

How Amazon found it

Amazon runs MadPot — a global network of decoy servers that look like real corporate infrastructure and log everything that attacks them. On January 26, 2026, MadPot recorded unusual HTTP requests hitting its simulated Cisco FMC instances — Java code execution attempts with embedded URLs designed to confirm exploitation and deliver follow-up payloads.

Amazon's researchers simulated a successful compromise, which tricked Interlock's infrastructure into automatically sending its follow-up malware payload — revealing the complete attack chain before the vulnerability was even publicly known.

Think of it as a three-step kill chain:

1. Enter silently through the management interface — root access, no credentials, no alert.
2. Blind defenders by modifying firewall rules and disabling logs — the security team loses visibility.
3. Deploy ransomware into a network that can no longer see the attack coming.

Here's how that plays out in practice — at a hospital network running FMC on-premises with the management interface exposed to the internet for remote administration.

Day 0 — Attacker sends one crafted request to the FMC interface. No login. Root access granted.

Day 1 — Firewall rules modified to allow outbound traffic to attacker's server. Logging partially disabled. No alerts.

Day 3 — Using FMC's own visibility tools, attacker maps every internal system — patient records, billing, backups — and which firewall rules protect them.

Day 5 — Web shell deployed on FMC. Even if the vulnerability is patched tomorrow, the attacker still has access.

Day 10 — Firewall rules quietly adjusted to allow traffic between previously isolated network segments. Lateral movement begins.

Day 15 — Security alerts disabled. Endpoint protections bypassed using trusted network paths now controlled by the attacker.

Day 20 — Ransomware deployed simultaneously across all reachable systems. Firewall policies were already modified to let it spread without resistance.

Day 21 — Hospital systems offline. Patient records inaccessible. Operations down.

This is how a single unauthenticated HTTP request becomes full operational shutdown — not by brute force, but by controlling the system that controls security.

This is why the 36-day window matters. Every network that ran unpatched FMC between January 26 and March 4 should assume it was at minimum probed by Interlock's automated scanning — and that some were fully compromised weeks before anyone knew the vulnerability existed.

MITRE ATT&CK Mapping

Indicators of Compromise (IOCs)

# CVE-2026-20131 Cisco FMC — Detection Indicators

# Exploitation indicators — network level
Alert: Unusual POST requests to FMC web interface (port 443)
  containing large serialized Java objects in the request body
Alert: Outbound HTTP PUT request from FMC server to unknown external IP
  immediately following inbound POST to management interface
  (this is the "confirmation beacon" Interlock uses to verify exploitation)
Alert: FMC initiating outbound connections to download ELF binaries
  from external infrastructure — post-exploitation payload delivery

# Post-compromise indicators — on FMC server
Alert: Unexpected processes spawned by FMC web service with root privileges
Alert: New files created in web-accessible FMC directories
  — especially memory-resident web shells with randomised filenames
Alert: Log files modified, truncated, or deleted on FMC server
Alert: FMC configuration changes — policy modifications, rule additions,
  logging disabled — outside of authorised change windows

# Firewall policy tampering indicators
Alert: Firewall rules changed to permit previously blocked traffic
  — especially inbound from unknown external IPs
Alert: Logging disabled on any managed firewall device
  outside of a known maintenance window
Alert: New administrative accounts created in FMC outside normal provisioning

# Version verification
Safe FMC versions: 7.0.9 / 7.2.11 / 7.4.6 / 7.6.5 / 7.7.12 / 10.0.1
Alert: Any FMC instance running a version below these thresholds
  — treat as potentially compromised if internet-accessible since January 26

# Interlock ransomware indicators
Alert: Unusual PowerShell activity or memory-resident process execution
  on systems managed by a potentially compromised FMC
Alert: Mass outbound connections from multiple endpoints simultaneously
  — consistent with ransomware pre-encryption reconnaissance

SOC Alert Priorities

Priority 1 — Patch every FMC instance to a safe version immediately. No workaround exists. If your FMC cannot be patched right now, take its management interface offline or restrict all access to trusted internal IPs only. An internet-facing unpatched FMC should be treated as already compromised.

Priority 2 — If your FMC was internet-accessible between January 26 and March 4, assume it was probed. Run a full forensic review of FMC logs for that period. Look for unusual POST requests, outbound connections to unknown IPs, and any configuration changes that weren't authorised. The 36-day window is your investigation scope.

Priority 3 — Audit all firewall policies managed by your FMC for unauthorised changes. Interlock's playbook includes quietly modifying rules to allow their traffic and disabling logging before deploying ransomware. Any rule change you cannot account for in the last two months needs investigation.

Priority 4 — Check FMC for memory-resident web shells and unexpected processes. Interlock uses persistence mechanisms specifically designed to survive reboots. A patch removes the initial exploit path but does not remove a web shell that was already installed. If you were compromised before patching, the back door may still be there.

Priority 5 — This vulnerability has scope change — a compromised FMC compromises every device it manages. Your investigation scope is not just the FMC server. Every firewall under its management, and every network segment those firewalls protect, should be treated as potentially accessible to the attacker.

The pattern here connects directly to what we covered in the SharePoint RCE post — attackers going after the management plane, the control systems, rather than individual endpoints. When you own the system that manages security, you can disable security:

→ SharePoint CVE-2026-20963: Unauthenticated RCE Confirmed by CISA — Patch Now or Disconnect

And the 36-day zero-day window mirrors the pattern from the Stryker attack — attackers operating silently inside systems long before defenders knew they were there:

→ The Stryker Cyberattack: How Iran-Linked Hackers Turned a Medical Giant's Own Tools Against It

The ZyberWalls Perspective

Thirty-six days. That is how long Interlock operated inside Cisco firewalls before the rest of the world knew the door was open. Ransomware groups are now finding and weaponising zero-days routinely — ahead of the vendors who built the software.

What MadPot revealed is not just about this vulnerability. It confirms a pattern: the tools you trust most are the highest-value targets. Compromising a security tool gives access to everything that tool protects. The FMC management interface should never face the public internet. Administrative access needs a VPN and multi-factor authentication. Logs need to be monitored in real time — because when an attacker disables alerts, you need something else watching.

The 36-day window was not a failure of patching.

It was a failure of visibility.

Attackers were not hiding particularly well — they were operating in a place most organisations never monitor: the system that controls their security.

In 2026, the most dangerous attacks don't break your defences.

They become your defences.