Cisco Secure Email Gateway CVE-2026-76519: root file write from a single email, exploited

The device that inspects every inbound message for malware can now be rooted by one of those messages. Cisco disclosed CVE-2026-76519 today, October 14, 2026: an unauthenticated, remote attacker can write arbitrary files — and run commands as root — on a Cisco Secure Email Gateway simply by sending an email with a crafted attachment. CISA added it to the Known Exploited Vulnerabilities catalog the same day, with a federal remediation deadline of October 17. There is no workaround.

Developing story — first published 22:42 CEST (20:42 UTC), October 14, 2026. Updated as the vendor and CISA publish more.

At a glance

CVE	CVE-2026-76519
Product / affected versions	Cisco Secure Email Gateway (physical and virtual) with AMP File Reputation enabled and assigned to a mail policy, running Content Scanner Tools earlier than 25.3.0.5525
Fixed in	AsyncOS 15.5.5-014; AsyncOS 16.5.0-780; AsyncOS 16.0 — migrate to a fixed release · or Content Scanner Tools 25.3.0.5525 and later (applies without a software upgrade or restart) · released 2026-10-14
CVSS	9.8 Critical · CVSS 3.1 · scored by Cisco PSIRT · CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H · NVD status Undergoing Analysis
Exploited in the wild	Yes · Cisco PSIRT became aware of active exploitation in October 2026; CISA SSVC records exploitation=active, automatable=yes, technical impact=total
CISA KEV	Added 2026-10-14; federal due date 2026-10-17 (BOD 26-04, forensic triage required)
Public PoC	None public as of 2026-10-14 — the Cisco advisory lists no proof-of-concept and CISA does not assert public exploit code
Official advisory	Cisco advisory cisco-sa-esa-afw-zqYJkjxp

What happened

The flaw lives in the Advanced Malware Protection (AMP) feature — specifically the File Reputation service that evaluates attachments before they reach a mailbox. Cisco describes the root cause as improper handling of email attachments: the component that processes a file as part of a reputation lookup does not correctly sanitise a path, and the attacker controls where the write lands. CISA catalogs it as a relative path traversal; Cisco classifies it as CWE-23 and labels the bug an arbitrary file write. Both descriptions point at the same primitive: an attacker-controlled attachment steers a write to an attacker-chosen path on the appliance's operating system, and because the mail pipeline runs privileged, the write happens as root.

The chain is as short as it gets. No credentials (PR:N), no user interaction (UI:N), network-reachable by design (AV:N) — the gateway's whole job is to accept mail from the internet. The attacker sends a message; the gateway scans the attachment; the scan writes a file the attacker specified. From a write-as-root primitive to command execution is a well-trodden step: drop a script into a path that is executed, overwrite a binary or a cron entry, or plant a web shell in a served directory. Cisco states exploitation can result in command execution with root privileges. That is why CISA's automated SSVC assessment reads exploitation=active, automatable=yes, technical impact=total — the worst row on every axis.

This is the second Secure Email Gateway bug CISA has added to KEV in a month, after the SQL-injection-to-RCE flaw CVE-2026-76461 in mid-September. The perimeter mail appliance is under sustained attention, and for good reason: it sees every inbound message, holds decryption and routing configuration, and sits in a trusted zone most segmentation diagrams draw with a thick green line.

Who is exposed, and how to check

You are exposed if all of these are true:

• You run a Cisco Secure Email Gateway, physical or virtual.
• File Reputation (the AMP feature) is enabled and assigned to at least one mail policy.
• The device's Content Scanner Tools version is earlier than 25.3.0.5525.

Check the running Content Scanner Tools version in the web UI under the AMP / File Reputation and File Analysis settings, or from the CLI. Cisco's advisory gives a vulnerable example string of 25.2.0.5427.15.5.001 — anything below 25.3.0.5525 is affected. If File Reputation is not enabled or not bound to a policy, the vulnerable code path is not reached, but treat that as a configuration fact to verify, not assume: a single mail policy with the feature on is enough.

Secure Email and Web Manager and the Secure Web Appliance are not affected.

Remediation

Treat this as a patch race, not a maintenance window. The vulnerability is exploited, automatable, and leads to root — and the federal KEV deadline is October 17, 2026, three days from disclosure.

1. Am I affected? Confirm the Content Scanner Tools version (below 25.3.0.5525 = vulnerable) and whether File Reputation is enabled and assigned to a mail policy. Record both for every gateway in the fleet before you start patching — you will need the exposure inventory for the forensic-triage obligation below.

2. Patch — exact fixed versions (verbatim from the Cisco advisory).

AsyncOS branch	First fixed release
15.5	15.5.5-014
16.0	Migrate to a fixed release
16.5	16.5.0-780 (Cisco recommends earlier releases move here)

The faster lever: update Content Scanner Tools to 25.3.0.5525 or later, which Cisco says applies without a software upgrade or restart. That is the control that closes the hole in minutes rather than a maintenance window — do it first, then schedule the AsyncOS upgrade for anything still on an unsupported train.

3. Can't patch instantly? There is no workaround. Cisco is explicit that none exists. The only honest interim move is to disable File Reputation on affected mail policies if you can tolerate the detection loss, or to pull internet-facing gateways behind a holding MTA — both are stopgaps that trade function for exposure, not fixes. The Content Scanner Tools update is quick enough that this should be a bridge of minutes.

4. Hunt for compromise. Cisco has published no indicators of compromise, and no public PoC exists yet, so do not chase invented file paths. Hunt on behaviour instead, against the KEV forensic-triage requirement:

• Review mail logs for inbound messages with attachments processed by File Reputation around and before your patch time — the delivery vector is a message, so the ingestion record is your timeline anchor (ATT&CK T1190, exploit public-facing application).
• Look for files, cron entries, or binaries on the appliance that changed outside a known upgrade, and for processes or outbound connections the gateway has no business making — a mail relay that suddenly beacons is the tell (T1505.003 web shell, T1053 scheduled task/job, T1071 application-layer C2).
• Because the write runs as root, assume the device's own logs can be edited by a successful attacker. Corroborate from off-box telemetry — upstream mail logs, NetFlow, and the network's view of what the appliance sent — not from the appliance alone.

5. Eradicate and verify. If you find evidence of a write, a patched appliance is not a clean appliance: rebuild or restore from a known-good image, rotate every credential and key the gateway held (LDAP/AD bind accounts, SMTP auth, API tokens, certificates), and confirm the Content Scanner Tools / AsyncOS version is fixed after the rebuild. Then re-test that the file-write primitive is actually gone — a version string in a config is a claim, not proof the code path is closed on your build.

What is not known yet

• Who is exploiting it, and how. Cisco confirms active exploitation but has published no campaign details, no attribution, and no IOCs. Treat the lack of IOCs as "none released," not "none exist."
• The NVD enrichment. NVD still lists the record as Undergoing Analysis; the 9.8 score is Cisco's own (secondary source). An NVD-assigned vector and CWE confirmation may follow.
• Public exploit code. None is public as of this writing. Given automatable=yes and a root-write primitive, assume that window is short.
• Scope of the write primitive. Cisco states command execution as root is possible; the exact technique from file write to code execution is not detailed in the advisory.

What this means operationally

A three-day federal deadline on a mass-deployed appliance is a sequencing problem before it is a patching problem: which gateways are internet-facing, which have File Reputation bound to a live policy, which can take the no-restart Content Scanner update now versus a scheduled AsyncOS upgrade. Zero Hunt's AI Remediation Advisor is built for exactly that ordering — it ranks findings by real exploitability (CISA KEV first, then what the campaign proved reachable in your environment, then CVSS and EPSS), hands back the exact fixed version per branch with rollout and rollback notes, names the compensating control when a vendor fix lags, and then re-verifies the fix with the same proof that demonstrated the issue. On a KEV entry that carries a forensic-triage obligation, every finding, scan, and remediation is signed at write time (Ed25519, hash-chained) so the evidence you hand an auditor or regulator is defensible rather than reconstructed.

And once a mail gateway has been written to as root, its own logs stop being trustworthy — the attacker can edit them. The honest witness is the network. Zero Hunt's AI Traffic Analysis runs a deep-learning model with four parallel inference heads on the appliance GPU, at multi-gigabit wire speed, watching for the thing a rooted relay does that it never did before: beacon to an ASN it has never contacted, open an outbound session a mail gateway has no reason to open, move laterally from a trusted zone. That signal exists while it is happening, not in the next morning's SIEM digest — which is the difference between a patched bug and a missed breach. If you want to confirm the write primitive is actually closed on your build rather than trusting a version label, that is a question an automated penetration test answers by trying it, under human-in-the-loop control, on your own appliance — an autonomous AI red team running on-premise on private models, black-box by default, with every action gated and signed.