An appliance build number can hide a second verification step. Cisco’s latest Secure Email Gateway guidance makes that check explicit for an already exploited vulnerability.
CHANGED — CVE-2026-76461 / cisco-sa-esa-inj-2bLVGmhX. Original disclosure: September 14, 2026. Revision 1.2: November 3, 2026, 17:05 UTC. Last verified: November 3, 2026. The revision changes the fixed-release guidance; exploitation was already known.
What changed
Cisco says it revised the fix inside 15.5.5-014 on October 31. On that build, run retroscannerstatus and require Cisco Retro Remediation Engine 4.0.2 or later. A matching appliance build alone is insufficient. Cisco recommends migrating releases below 16.5 to 16.5.0-780, which fixes this issue independently of the engine version.
Check applicability and remediation
Vendor: Critical, CVSS 3.1 9.8. Crafted email can cause unauthenticated root command execution. Physical and virtual Secure Email Gateway appliances are affected regardless of configuration; management-interface restrictions do not eliminate the email-processing path. Secure Email and Web Manager and Secure Web Appliance are excluded.
| AsyncOS release family | First fixed release / verification |
|---|---|
| 15.5 and earlier | 15.5.5-014 plus Retro Remediation Engine 4.0.2 or later |
| 16.0 | 16.0.4-302 |
| 16.5 | 16.5.0-780; independent of engine version |
These are Cisco’s release-family targets; complete per-build lower bounds are not enumerated. No workaround is available. Upgrade through the appliance’s System Upgrade workflow or CLI; a reboot follows. Cisco reports its Secure Email Cloud devices already upgraded to 16.5.0-780.
Exploitation and incident response
Cisco confirms active exploitation known since September. CISA KEV lists this CVE from September 14, with a September 17, 2026 federal deadline, not a new customer deadline. The full catalog checked today is dated October 30. KEV also flags forensic triage.
Review every cluster member’s mail_logs for suspicious SQL, and correlate independent firewall/network logs: root access can erase local evidence. If virtual appliances may be compromised, preserve forensics before rebuilding on fixed software, reconstruct configuration, renew credentials and cryptographic material, and monitor. Stolen inter-node SSH keys can expose peers; Cisco directs recovery across a cluster containing a compromised member. For suspected physical-appliance compromise, follow Cisco TAC guidance. Cloud customers contacted by Cisco should follow its recovery and credential-renewal instructions; an upgrade alone does not establish recovery.
Suggested MSP priority: urgent where applicable
- Inventory: validate deployments, exact builds, engine version, mail reachability and cluster peers across managed environments. No customer use is assumed.
- Contain and investigate: restrict unnecessary untrusted access and separate management from mail traffic; preserve evidence and use the matching vendor recovery path if compromise is suspected. Access controls are not a complete fix.
- Remediate: schedule the supported upgrade and reboot, preferably Cisco’s recommended 16.5.0-780 migration; verify the engine separately if retaining 15.5.5-014.
- Verify: recheck running versions, peer recovery and renewed trust material where required, then test mail flow, management and logging.
Official sources
- Cisco advisory, fixed software, recovery guidance and revision history
- CISA official full KEV catalog data
This targeted review retains the watch’s existing source-access and validation gaps; it does not establish an all-clear.