TL;DR
- 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.
⚠️ Root access means your own logs are suspect — 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_logs
Any 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.
Order of operations for this week — 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
Originally published on RedEye Threat Intelligence.
Top comments (0)