Cisco published an advisory on September 14 for CVE-2026-76461, a SQL injection in the email parsing of AsyncOS on Cisco Secure Email Gateway. The score is 9.8. An unauthenticated remote attacker sends a crafted email through the appliance and runs commands as root on the operating system underneath.1 Cisco says its PSIRT became aware of active exploitation in September 2026, and it has published no details of the attacks and no attribution.2

CISA added the flaw to the Known Exploited Vulnerabilities catalog the same day, with a September 17 deadline for federal agencies. That is three days.3 The affected set is every Secure Email Gateway, physical or virtual, in any configuration. Secure Email and Web Manager and Secure Web Appliance are not affected.12

I do not run this appliance. The reason to write about it is the shape of the problem, which belongs to anyone running a mail gateway.

No workaround, and a window measured in days

A mail gateway parses untrusted input on every message, by design, and it sits in front of the mail flow rather than beside it. That combination puts it in a different patch category from the workstation bug you schedule for this month or next. Cisco lists no workaround: the fix is an upgrade, to 15.5.5-0141, 16.0.4-3021, or 16.5.0-780, with a recommendation to move to 16.5.0-780.1

Staging one is the hard part. You want production mail flowing through a gateway to test it, and production mail is the one stream you cannot reroute to a test box without weakening the test to the point of uselessness. Cisco’s guidance for a suspected compromise on a virtual appliance is to deploy a fresh instance, rebuild the configuration, and renew credentials and cryptographic material, which is a rebuild rather than a rollback.1

The indicators and their limit

Cisco’s indicator is a mail log search, on each device in a cluster:

grep -i "COPY.*TO PROGRAM" mail_logs

The advisory also says why that is not enough. Exploitation lands with root, and a root-level actor can remove or hide the evidence, so a clean grep does not clear the appliance. Cisco’s own instruction is to cross-check network and firewall logs outside the device, looking for unexpected uploads from the appliance to external addresses, or downloads from malicious ones.1

That instruction is where the interesting problem sits. You are checking the integrity of a device by reading logs the device produces, and the device is the thing you no longer trust. The independent check is the second log source, the firewall, and it is only independent if the attacker never had a path to it. If the same actor reached the firewall or the log store, the corroboration is worth less than it looks. Before trusting a clean result, ask where the logs go, who can write to them, and whether that path was reachable from the compromised appliance.

A class of asset that keeps coming back

This is the second Cisco Secure Email Gateway entry in the KEV catalog in about a year. The first, CVE-2025-20393, was exploited from late 2025 by China-linked threat actors.2 Who is behind the current exploitation is not public.2 In the same batch as this advisory, Cisco patched four other critical bugs affecting Secure Email Gateway and Secure Email and Web Manager regardless of configuration, and said it has no evidence those four are exploited.3

The pattern is the asset, not the vendor. An internet-facing appliance that accepts mail from anyone, terminates into an operating system with root available, and runs firmware a year behind is a target that stays worth attacking. Cisco’s hardening list says as much: no internet access to the appliance’s management side, mail and management split onto separate interfaces, and a firewall in front that allows only known hosts to reach management, with two layers recommended so end users never touch the outer DMZ.1 Shadowserver tracks more than 400 internet-exposed Secure Email Gateway appliances, and that count says nothing about how many of them sit on old firmware.3

What transfers

The appliance in this advisory is Cisco’s, and the lesson is not. Patch windows on a mail gateway run in days, because the input never stops arriving. An indicator from the device is a starting point rather than a verdict, because the exploit ran as root and root can clean up after itself. And segmentation is a precondition for trusting anything you read off the box, not a hardening item to reach later.


  1. Cisco. (2026, September 14). Cisco Secure Email Gateway SQL Injection Vulnerability (Cisco Security Advisory cisco-sa-esa-inj-2bLVGmhX). https://sec.cloudapps.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-esa-inj-2bLVGmhX ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎

  2. Kovacs, E. (2026, September 15). Root RCE Zero-Day in Cisco Secure Email Gateway Under Active Exploitation. SecurityWeek. https://www.securityweek.com/root-rce-zero-day-in-cisco-secure-email-gateway-under-active-exploitation/ ↩︎ ↩︎ ↩︎ ↩︎

  3. Gatlan, S. (2026, September 15). Cisco patches Secure Email Gateway zero-day exploited in attacks. BleepingComputer. https://www.bleepingcomputer.com/news/security/new-cisco-secure-email-zero-day-exploited-to-execute-commands-as-root/ ↩︎ ↩︎ ↩︎