CISA adds actively exploited Cisco Secure Email Gateway SQL injection to KEV catalog

CISA has added CVE-2026-76461, a pre-authentication SQL injection affecting Cisco Secure Email Gateway, to its Known Exploited Vulnerabilities (KEV) catalog, confirming that the flaw is being exploited in the wild. According to a dev.to write-up drawing on CISA and Cisco advisories, the catalog entry was made on September 14, 2026, and US federal agencies have until September 17, 2026 to remediate. CISA also marked the vulnerability as one requiring forensic investigation, and Cisco stated it became aware of the active exploitation in September 2026.

Pre-authentication injection that ends in root access

The vulnerability carries a CVSS v3.1 score of 9.8 and requires neither credentials nor user interaction. The attack flow, as described by Cisco, is unusually direct: an unauthenticated external attacker sends a crafted email containing malicious SQL statements to the appliance. Inadequate validation during email parsing allows the injection to succeed, and successful exploitation results in arbitrary command execution with root privileges on the underlying operating system.

Because the trigger is simply the reception of a message, the attack takes place during normal mail processing. Deployment type is irrelevant: physical and virtual gateways running vulnerable versions of AsyncOS are affected regardless of which features are enabled.

Fixed versions and no workarounds

Cisco's initial fixed releases are 15.5.5-014 for AsyncOS 15.5 and earlier, 16.0.4-302 for version 16.0, and 16.5.0-780 for version 16.5. Cisco strongly recommends upgrading to 16.5.0-780, which requires an appliance reboot.

There are no workarounds. Restricting access to the management interface or separating mail and management networks are defense-in-depth measures only and do not substitute for applying the update. Administrators should also be aware that patching does not remediate an existing compromise: if intrusion is suspected, Cisco advises preserving evidence and following its recovery procedures for the specific deployment type.

On the hosting side, Cisco says all instances of Cisco Secure Email Cloud have already been updated to 16.5.0-780. Customers contacted by Cisco about a potential compromise should rotate credentials, keys and certificates according to the guidance provided.

Hunting for signs of exploitation

Cisco identifies mail_logs as the primary investigation target. Administrators should search for suspicious SQL statements, such as the case-insensitive pattern COPY.*TO PROGRAM, and in clustered deployments check every member appliance. Two caveats apply: the search is not exhaustive, and a match by itself does not confirm that command execution actually occurred.

Correlation is the next step. Matching records' timestamps and message IDs can be cross-referenced against appliance activity and external network or firewall logs, where Cisco suggests looking for unexpected uploads from affected appliances to external IP addresses, or downloads from malicious ones. Because the exploit occurs before authentication, the absence of administrator login records does not prove the absence of compromise. Cloud customers without CLI access cannot verify these artifacts independently and should rely on Cisco notifications and support.

Why it matters

Email security gateways occupy a paradoxical position: they must accept untrusted input from anyone on the internet, which makes a flaw that converts a single inbound message into root-level OS command execution about as severe as perimeter vulnerabilities get. The KEV listing signals confirmed real-world exploitation, so the September 17 deadline is a binding operational requirement only for US federal agencies, but every organization running an affected gateway faces the same exposure. Root access to a mail gateway plausibly opens the door to harvesting email data, credentials and configuration, or using the appliance as a pivot point into the internal network — post-exploitation details that Cisco and CISA have not publicly disclosed for specific incidents, but which follow directly from the access level involved. For teams that cannot patch immediately, checking mail_logs for the known indicators is the most practical interim step.