SQL injection exploited in Cisco Secure Email Gateway

On 14 September 2026 at 16:00 UTC, Cisco published two security advisories for its email gateway. The first carries a single CVE (1), CVE-2026-76461: a SQL (2) injection in the email parsing logic of AsyncOS software, allowing a remote attacker with no account to execute commands as root on the underlying operating system. The CVSS (3) 3.1 base score is 9.8.

The attack fits in one message. The attacker sends a crafted email carrying SQL statements, the parsing logic does not validate that content sufficiently, and the statements are executed. There is no authentication and no interaction from a recipient. The vulnerability affects Cisco Secure Email Gateway, physical and virtual alike, regardless of device configuration. The vendor publishes no workaround.

The US agency CISA (4) added the CVE to its KEV (5) catalogue of actively exploited vulnerabilities the same day. Since 10 June 2026 that catalogue has been tied to directive BOD (6) 26-04, which replaced the fixed-deadline model in force since 2021 with graduated timelines based on how publicly exposed the asset is and what an attacker gains from the flaw. The shortest timelines run to three days.

Cisco assigns the flaw to CWE (8)-89, SQL injection, and links it to bug ID CSCwu56234. The published cause is insufficient validation of data in the email parsing logic. Statements carried by the message are interpreted by the engine instead of being handled as plain data.

The missing link

The advisory does not describe how execution of a SQL statement becomes execution of a system command. The only element published on that point is the search pattern provided for detection, which targets the COPY ... TO PROGRAM construct. That construct lets a SQL engine pass a command to the host system and collect its output.

Published in the same minute, the second advisory announces hardening releases resulting from an internal security review. It carries five CVEs, four scored 9.8 and one 7.5. It covers Secure Email Gateway and, this time, Secure Email and Web Manager, a product the first advisory declares unaffected.

The method is explicit in the advisory: to help customers patch and to streamline disclosure, Cisco grouped the flaws by weakness class and assigned one CVE identifier per group. The score shown is not the group’s score, it is the score of the most impactful flaw inside it.

That is the point that outlives this product. Counting CVEs then stops measuring a number of flaws. One identifier may cover a single flaw or twenty, with no way to tell the difference from outside, and the highest score in the group applies to the whole by default. Dashboards that count CVEs per product, vulnerability debt metrics and vendor-to-vendor comparisons no longer measure the same thing depending on whether the vendor groups its disclosures.

The advisory also states where these flaws came from: internal testing, conducted with existing processes and with frontier AI models. The mention is brief and the vendor says no more, neither about the tooling used nor about what each method contributed.

The two advisories publish separate release tables. Read side by side, they do not say the same thing.

The practical consequence is direct. An organisation that applies release 16.0.4-3021 fixes the exploited injection and stays exposed to the five classes of the second advisory, four of which are scored 9.8. Only release 16.5.0-780 addresses both, which matches the migration the vendor recommends. For Secure Email and Web Manager, the matching release is 16.5.0-429.

The two advisories also diverge on the 15.5 branch, one publishing 15.5.5-0141 and the other 15.5.5-014. The vendor does not resolve that discrepancy. It has no effect for anyone moving straight to the 16.5 branch.

To confirm an exploitation attempt, Cisco points to the mail logs and to suspicious SQL statements that may appear there. If the gateway belongs to a cluster, the logs of every member must be reviewed. The search runs from the command line interface, against the mail_logs file:

grep -i "COPY.*TO PROGRAM" mail_logs

Any entry in the output may indicate malicious activity. The vendor sets the limit of that search itself: exploitation grants root access, so evidence and indicators may have been removed or hidden by the attacker.

No technical IOC (9) has been published to date, by Cisco or by CISA. No actor is named. No public exploit code is referenced, which does not reduce the urgency since the vendor confirms exploitation.

The managed service case

Cisco states that it has already upgraded every appliance in the Cisco Secure Email Cloud service to release 16.5.0-780, that it has run an investigation across that estate, and that it has directly contacted customers where malicious activity was detected. Those customers are advised to renew credentials and any cryptographic material installed on the appliance, and to restrict access to it. Administrators without command line access cannot check the indicators described above themselves. No contact from the vendor is not a clean bill of health: only customers where indicators were identified were contacted.

Both advisories come from the vendor. The KEV listing comes from the agency. The level of evidence is high on the facts, lower on the technical chain, which the vendor does not publish.

On an affected estate

• Identify the AsyncOS branch in service on every gateway, including virtual instances and cluster members, then target release 16.5.0-780. It is the only one that addresses both advisories.
• Do not stop at release 16.0.4-3021, which fixes the exploited injection and leaves the five classes of the second advisory open.
• Handle Secure Email and Web Manager under the second advisory, at release 16.5.0-429. That product is not affected by the injection, it is affected by the hardening set.
• Run the retrospective search before concluding, first against logs exported off the appliance. A negative result from the gateway itself proves nothing.
• Where compromise is suspected on a virtual instance, the vendor recommends preserving forensic material before any other action, deploying a new instance on a fixed release, rebuilding the configuration, then renewing credentials and cryptographic material. On a physical appliance, it points to its support organisation.
• Book the reboot into a change window: the upgrade restarts the appliance, and therefore interrupts the mail flow.
• Apply the hardening measures the vendor restates: no internet access to the management interface, mail and management functions separated onto distinct interfaces, logging sent to an external server and retained long enough to support an investigation.

What this case says about counting

The exploited vulnerability is a classic case, properly documented and quickly added to the catalogue of exploited vulnerabilities. What deserves to be kept has more to do with the second advisory.

A CVE identifier used to designate one vulnerability. It now designates, at this vendor and for this disclosure, a class of weaknesses whose contents are not enumerated. The approach has its logic on the operator’s side, where what is wanted is a fix rather than a catalogue. It has a cost on the analysis side: nothing allows an outsider to count the flaws, track how they evolve over time, or compare two products on that basis.

The mention of frontier AI models in finding these flaws calls for the same caution. It says nothing about the actual yield of the method, nor about what it finds and fails to find. It does suggest that the volume of vulnerabilities published by vendors is likely to rise, and that grouping by class may be the answer to that volume rather than the cause of the question.

1. CVE (1): Common Vulnerabilities and Exposures, the unique public identifier of a vulnerability.
2. SQL (2): Structured Query Language, the query language of relational databases.
3. CVSS (3): Common Vulnerability Scoring System, the standard framework for rating the severity of a vulnerability.
4. CISA (4): Cybersecurity and Infrastructure Security Agency, the US cybersecurity agency.
5. KEV (5): Known Exploited Vulnerabilities, CISA’s catalogue of vulnerabilities with confirmed exploitation.
6. BOD (6): Binding Operational Directive, a directive binding on US federal civilian agencies.
7. SMTP (7): Simple Mail Transfer Protocol, the protocol that carries electronic mail.
8. CWE (8): Common Weakness Enumeration, the classification of software weakness types.
9. IOC (9): Indicator of Compromise, a technical marker of an attacker’s presence.

1. Cisco, security advisory cisco-sa-esa-inj-2bLVGmhX, Cisco Secure Email Gateway SQL Injection Vulnerability, 14 September 2026. sec.cloudapps.cisco.com
2. Cisco, security advisory cisco-sa-hardening-esa-dfCrfXkm, security hardening release of September 2026, 14 September 2026. sec.cloudapps.cisco.com
3. CISA, one vulnerability added to the KEV catalogue, 14 September 2026. cisa.gov
4. CISA, directive BOD 26-04, Prioritizing Security Updates Based on Risk, 10 June 2026. cisa.gov
5. CVE Program, record for CVE-2026-76461, accessed 15 September 2026. cve.org