Cisco published advisory cisco-sa-esa-afw-zqYJkjxp Wednesday at 16:00 GMT for CVE-2026-76519, a critical arbitrary file write in the Advanced Malware Protection (AMP) feature of Secure Email Gateway, scored CVSS 9.8 (AV:N/AC:L/PR:N/UI:N). The gateway mishandles email attachments when the file reputation service is enabled. An unauthenticated remote attacker sends mail with a crafted attachment through the box, and a successful exploit writes arbitrary files and runs commands as root on the underlying OS. Cisco PSIRT says it became aware of active exploitation in October 2026. Cisco found the bug in its own internal scanning. Victim count: Undisclosed. Actor: Undisclosed.
Who is exposed. Physical and virtual Secure Email Gateways on a vulnerable AsyncOS release, but only when both conditions hold: (1) File Reputation, part of AMP, is enabled and assigned to a mail policy, and (2) Content Scanner Tools is earlier than 25.3.0.5525. Cisco says Secure Email and Web Manager and Secure Web Appliance are not affected. That second condition is the unusual part. The bug lives in the scanner package, so the fix ships two ways.
The fix. Content Scanner Tools 25.3.0.5525 or later fixes it on all licensed and supported AsyncOS releases with no software upgrade and no restart. Boxes with automatic scanner updates enabled pick it up on their own; everyone else runs contentscannerupdate at the CLI, or turns on Security Services > Service Updates > Automatic Updates. The full AsyncOS fixes are 15.5.5-014 for 15.5 and 16.5.0-780 for 16.5. There is no fixed 16.0 build: Cisco says migrate, and it strongly recommends anything below 16.5 move to 16.5.0-780. Those are the same builds Cisco listed in its September 14 hardening release, so a gateway that went to 16.5.0-780 last month is already covered (per Cisco and The Hacker News). A gateway sitting on 16.0.4-302, the build that fixed September’s SQL injection, is not.
How it fits with September. On Sep 14 Cisco disclosed CVE-2026-76461, an email-parsing SQL injection to root that hit every configuration and landed on CISA KEV the same day. The same day it shipped a hardening release that grouped internally found SEG and Secure Email and Web Manager bugs into umbrella CVEs by weakness class. Cisco updated that hardening advisory Wednesday: two of the grouped bugs are now known exploited, this file write (in the path traversal class, CVE-2026-76440) and the September SQL injection. Under the disclosure model Cisco adopted in June, a bug fixed inside a hardening group gets its own CVE once it is known to be exploited, which is how a September fix became an October 0-day advisory (per The Hacker News). Cisco has not linked the two campaigns. The Hacker News counts this as the third root-level SEG flaw Cisco has confirmed exploited since December, after the UAT-9686 spam quarantine zero-day CVE-2025-20393.
KEV status. CVE-2026-76519 was not in CISA’s Known Exploited Vulnerabilities catalog when we checked Wednesday afternoon (catalog version 2026.10.13). For now Cisco is the one confirming in-the-wild use. There is no federal due date yet, and we’ll update if CISA adds it.
Cloud customers. Cisco says it already deployed the fixed scanner across Secure Email Cloud, investigated those devices, and directly contacted customers where it found indicators of possible compromise. Cloud admins may not have the CLI access to run the log check themselves. If you got that call, Cisco wants credentials and any cryptographic material on the appliance renewed.
What we’d do this afternoon. Open Mail Policies > Incoming Mail Policies > Advanced Malware Protection (and the Outgoing side) and check whether Enable File Reputation is ticked on any policy. Run contentscannerstatus on every gateway and every cluster member. Anything below 25.3.0.5525 gets contentscannerupdate now, then check again, because “auto-update is on” is not the same as “the update applied.” If you’re on 16.0 because you stopped at 16.0.4-302 after the SQLi, plan the move to 16.5.0-780; the scanner version is the only thing protecting that box today. Then hunt: grep "System Security" system_logs returns one of three lines, suspected compromise, scan did not complete, or no indicator found. The first two go to TAC. A clean result doesn’t settle it, since root can wipe its own tracks, so pull firewall and netflow from outside the appliance and look for uploads from the gateway to external IPs or downloads from addresses you don’t recognize. On a compromised virtual appliance, take forensics first (upgrading destroys the logs), rebuild on a fixed release without importing the old config, and rotate credentials and keys. Cluster members share SSH keys, so one bad node means rebuilding the whole cluster.