- What: Cisco confirmed active exploitation of CVE-2026-76461, a CVSS 9.8 SQL injection in the email parsing logic of AsyncOS for Secure Email Gateway that yields root command execution from a single crafted message.
Cisco Secure Email Gateway is running attacker code as root at an unknown number of organizations. CVE-2026-76461 carries a CVSS score of 9.8, requires no authentication, and is triggered by a single crafted email message sent to the appliance. Cisco confirmed active exploitation in a September 15, 2026 advisory, and CISA added the bug to the Known Exploited Vulnerabilities catalog with a Federal Civilian Executive Branch patch deadline of September 17, 2026. There is no workaround. The only fix is the upgrade.
One email, root on the appliance
The flaw sits in the email parsing logic. Message content reaches a SQL statement without sufficient validation, so an unauthenticated remote attacker can inject arbitrary SQL. On this platform that is not an information disclosure problem, it is command execution. The database context has enough privilege to reach the underlying operating system, which is why Cisco's published indicator of compromise is the string COPY ... TO PROGRAM in the mail logs. That is the Postgres primitive for piping query output into a shell command, and it is the bridge from injected SQL to a root shell.
The delivery path is what makes this urgent. The attacker needs no credential, no user click, and no existing foothold. They need your MX record. Any gateway that accepts mail from the internet, which is the entire purpose of the product, is reachable. Cisco says physical and virtual appliances are both affected regardless of device configuration, so there is no hardening posture that takes you out of scope.
Cisco warns that after successful exploitation, evidence and indicators may be removed or hidden by the threat actor. A clean mail_logs grep is not proof you were missed. Treat the appliance's telemetry as attacker controlled and pivot to records it cannot reach: perimeter firewall, netflow, DNS resolver logs, and the egress proxy.
Affected builds and the fixed versions
- AsyncOS 15.5 and earlier: fixed in 15.5.5-0141
- AsyncOS 16.0: fixed in 16.0.4-302
- AsyncOS 16.5: fixed in 16.5.0-780
- Not affected: Cisco Secure Email and Web Manager, Cisco Secure Web Appliance
- Cloud tenants: Cisco says it directly contacted Secure Email Cloud customers where malicious activity was detected, so silence from Cisco is not the same as an all clear
Hunt now, on every cluster node
Run Cisco's grep against the IronPort text mail logs. If the gateway is clustered, run it on every member, because the injected statement lands on whichever node accepted the message and a per-node review is the only way to cover the set.
grep -i "COPY.*TO PROGRAM" mail_logsAny output at all is a finding. From there, work outward into logs the appliance does not control. Cisco specifically recommends cross-checking network and firewall records for unexpected uploads initiated by the gateway to external IP addresses and downloads from known malicious addresses. In practice that means outbound sessions on ports other than 25, 587 and 443, connections during hours when the appliance normally sits idle, and any new destination the device has never talked to before.
The federal deadline is the smallest part of this
The September 17, 2026 KEV date binds FCEB agencies, but exploitation does not check who owns the box. Think about what an email gateway holds. It sits in the DMZ with inbound port 25 open to the world, it terminates TLS on every message, it usually carries an LDAP bind account for recipient validation, and it processes a copy of all inbound mail. Root there is mail interception, directory credentials, and a stable pivot into the internal network in one step. That combination puts this above routine patch cadence.
Second front: credential waves against Fortinet VPNs
Days before the Cisco advisory, Arctic Wolf reported large-scale credential attacks on internet-facing Fortinet VPN appliances. Two sustained waves ran from August 26 through August 28, 2026 across multiple U.S. customer environments and generated tens of millions of authentication failures. Researcher Kyle Siddall noted the usernames were organization specific: employee names, corporate email addresses, affiliate identities, and common administrative accounts tied to the targeted organizations. That is targeted identity selection against previously collected or enumerated data, not generic spraying. In one case a successful VPN authentication from 158.94.211[.]14 was followed by malicious activity inside the environment.
The two stories share a shape. Both target the appliance at the boundary, both are reachable without a foothold, and both reward the same two controls: know exactly what your edge devices run, and watch what they talk to.
Patch Secure Email Gateway first, because it is unauthenticated and under active exploitation. Then run the mail_logs hunt on every cluster node. Then pull 30 days of egress records for the gateway IPs from the firewall rather than from the box. Fortinet work is enforcement: MFA on every VPN account, lockout thresholds, and a block on 158.94.211[.]14.
If that grep returns anything
- Assume root. Rebuild the appliance from vendor media instead of patching in place
- Rotate everything the gateway held: LDAP bind accounts, SMTP relay credentials, API keys, admin passwords, and certificates
- Preserve firewall, netflow and DNS records for the gateway IPs before retention ages them out
- Review mail flow rules, content filters and forwarding entries for anything added since late August
- Scope the data exposure question early, because this device saw the full body of every inbound message
Fix It Yourself
Everything above is what happened. This is what to run. The check commands change nothing.
Check whether you are exposed
ESA CLI: log in, then run 'version' and compare the build to 15.5.5-0141, 16.0.4-302 or 16.5.0-780
ssh [email protected]ESA CLI on every cluster node: Cisco's IoC sweep for the command execution primitive in the mail logs
grep -i "COPY.*TO PROGRAM" mail_logsFrom a log collector, count outbound destinations for the gateway IP in firewall logs (replace 203.0.113.10 with your gateway address)
grep -F "203.0.113.10" /var/log/firewall/*.log | awk '{print $NF}' | sort | uniq -c | sort -rn | head -20Close it
ESA CLI: list available images and install the fixed build (15.5.5-0141, 16.0.4-302 or 16.5.0-780) during a maintenance window
upgradeESA CLI after patching: review and rotate local appliance accounts, since root access exposed every stored credential
userconfigNo Cisco workaround exists. If patching slips, print (do not apply) a perimeter rule limiting inbound SMTP to your MX provider ranges, review it, then apply on the firewall
echo 'iptables -A INPUT -p tcp --dport 25 ! -s 198.51.100.0/24 -j DROP'Prompts for the agent you already run
You run Cisco Secure Email Gateway and want to know if you are exposed before touching anything
After confirming a mail_logs hit and you need to scope the blast radius
What to alert on
The primary observable is Cisco's own: the IronPort Text Mail Logs (default log name mail_logs) on each Secure Email Gateway node, matched case-insensitively on the pattern COPY followed by TO PROGRAM within a logged SQL statement. Ship mail_logs off the appliance by syslog or log push and alert on that pattern at the SIEM, not on the box, because root-level access lets the actor edit local logs. Pair it with a second, tamper-resistant signal: in firewall or netflow records, alert on any outbound flow whose source is a Secure Email Gateway management or data interface IP and whose destination port is not 25, 587, 443 or your defined update and DNS destinations, and on any first-seen external destination for those source IPs. On the DNS resolver, alert on queries from the gateway IPs to domains outside your allow list of Cisco update and reputation services. For the parallel Fortinet activity, alert in FortiGate VPN authentication events on a sustained failure rate per source IP over a rolling hour and on any successful authentication from 158.94.211[.]14.
Questions about your exposure?
RedEye Security provides assessments for organizations that need to understand their real risk.
Talk to us