Cisco Secure Email Gateway CVE-2026-76461: Patch to 16.5.0-780 — A Single Email Grants Root

An unauthenticated attacker can run commands as root on a Cisco Secure Email Gateway by sending it a single crafted email. This is CVE-2026-76461.

The email parsing logic validates input insufficiently, so SQL statements embedded in a message are executed. Nobody has to open the message.

And it is already being used in attacks. Cisco's own advisory states that in September 2026 its PSIRT became aware of active exploitation.

There are no workarounds, so install a fixed release. With one caveat: an appliance that has already been compromised is not restored by the upgrade. Cisco publishes separate recovery steps per deployment type, covered further down.

Do this now

• ✓Check whether this is yours. It affects Cisco Secure Email Gateway, both physical and virtual, and Cisco states plainly that it applies regardless of device configuration. No configuration avoids it.
• ✓Cisco also names what is not affected. It has confirmed that Secure Email and Web Manager and Secure Web Appliance are not vulnerable to this issue, even though they sit in the same product family.
• ✓Upgrade AsyncOS. First fixed releases by train: 15.5 and earlier → 15.5.5-014, 16.0 → 16.0.4-302, 16.5 → 16.5.0-780. Cisco adds that it strongly recommends migrating to 16.5.0-780.
• ✓How to upgrade. In the web interface, System Administration > System Upgrade > Upgrade Options > Download and Install, then pick a release. From the CLI, run `upgrade` and enter `DOWNLOADINSTALL`. The device reboots afterwards.
• ✓This is a mail-receiving appliance, so it ranks first. The attack needs no credentials and its entry point is receiving a message, so treat any internet-facing device as reachable.

Where this score comes from: the 9.8 is Cisco's own assessment as the CNA, on CVSS v3.1 (vector `CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H`).

As of 15 September 2026, NVD still lists the record as "Undergoing Analysis" and NIST has published no score of its own. The 9.8 shown on NVD is Cisco's figure. The weakness is CWE-89 (SQL injection) and Cisco's bug ID is CSCwu56234.

The vendor says exploitation is confirmed

The urgency here comes from the exploitation record rather than the score. Cisco's advisory reads:

From Cisco Security Advisory cisco-sa-esa-inj-2bLVGmhX

  Exploitation and Public Announcements
  In September 2026, the Cisco PSIRT became aware of active
  exploitation of this vulnerability.

  Source
  This vulnerability was found during the resolution of a Cisco TAC
  support case.

Those two sentences are all Cisco publishes about the discovery. What kind of case it was, and how discovery relates to the exploitation, are not stated — so there is no need to fill that in. The fact to take away is simply that the vendor has confirmed exploitation.

CISA added the CVE to its Known Exploited Vulnerabilities catalog on 14 September 2026 and set a remediation deadline of 17 September 2026 for US federal civilian agencies. That deadline binds those agencies rather than anyone else, but it indicates how fast this is being treated.

There is no workaround

Cisco's advisory states under Workarounds: "There are no workarounds that address this vulnerability."

So no configuration change or rule is offered as a way to buy time. The temptation to improvise something before the upgrade window is understandable, but a mitigation the vendor has not published carries no guarantee of working and can break legitimate mail delivery. Treat the upgrade as the priority.

Checking whether you were hit (the official procedure)

Cisco publishes indicators of compromise as well. Review the mail_logs for suspicious SQL statements, and if the device is part of a cluster, review the logs on each device in it.

The example given in the Cisco advisory (described as non-exhaustive)

  cisco-esa> grep -i "COPY.*TO PROGRAM" [IronPort Text Mail Logs Log name - Default: mail_logs]

  The presence of any entry in the output may indicate malicious activity.

Do not stop there, though. In the same section Cisco is explicit about the limits of on-device evidence once root is involved.

• ✓Logs on the device may have been removed. Cisco writes that with this level of access, evidence of exploitation and indicators of compromise may be removed or hidden by the threat actors. A clean log is not proof you were spared.
• ✓Cross-check logs from outside the device. This is what Cisco strongly recommends: review network logs and firewall logs outside the affected device, looking for unexpected uploads from it to external IP addresses, or downloads from malicious ones.
• ✓On Cisco Secure Email Cloud without CLI access, you may not be able to run this check at all, as Cisco notes. In that case the grep above does not apply to you — see the Cloud entry in the next section.

Recovery depends on how the appliance is deployed

This is the part that is separate from patching. Cisco's Recommendations section splits the guidance three ways — on-premises physical, on-premises virtual, and Cloud. "We upgraded, so we are fine" does not hold if compromise is suspected.

• ▸On-premises physical appliances. If exploitation is suspected, Cisco recommends contacting the Cisco Technical Assistance Center (TAC) for support, and asks that remote access be enabled on the affected appliances so the investigation can move faster.
• ▸On-premises virtual appliances. If exploitation is suspected, Cisco strongly recommends five steps. 1. Preserve forensic information per your own incident handling policies — Cisco flags as important that you record it before going any further, because deploying a new instance destroys the configurations and logs. 2. Deploy a new virtual machine running one of the fixed releases. 3. Rebuild the product configuration. 4. Renew credentials and any cryptographic materials installed on the appliance. 5. Keep monitoring the system for anomalous behaviour. If restoring the appliance is not possible, contact Cisco TAC.
• ▸If exploitation is not suspected on a virtual appliance running an affected release, Cisco strongly recommends simply upgrading to a fixed release. That sentence sits inside the advisory's "On-Premises Virtual Devices" section — it is not written as a general rule covering every deployment.
• ▸Cisco Secure Email Cloud. Cisco says it ran a threat intelligence investigation across Cloud devices, directly contacted the owners of devices where indicators of possible compromise were identified, is engaged in remediation and recovery, and has deployed mitigations within its own management. It also states that all Cisco Secure Email Cloud devices have already been upgraded to Release 16.5.0-780. Customers who were contacted are strongly advised to renew credentials and any cryptographic materials that are installed on the appliance, when possible — Cisco's own wording, scope limiters included. Cisco adds a second recommendation in the same section: restrict access to the appliance and implement robust access control mechanisms — credential renewal alone is not the whole instruction. Cisco does not say that silence means safety — not being contacted is not evidence that a device was uncompromised.

Cisco separately lists longer-term hardening measures: block internet access to the appliance (and if it is required, restrict it to known, trusted hosts on documented ports and protocols), separate mail and management functions onto different network interfaces, place the appliances behind a filtering device and restrict management traffic, send logs to an external server and retain them long enough for post-event investigation, and disable HTTP for the main administrator portal. Worth revisiting alongside this upgrade.

Affected and fixed, in summary

• ▸Affected: Cisco Secure Email Gateway, physical and virtual, regardless of configuration
• ▸Not affected: Secure Email and Web Manager, Secure Web Appliance (confirmed by Cisco)
• ▸Fixed in AsyncOS: 15.5 and earlier → 15.5.5-014 / 16.0 → 16.0.4-302 / 16.5 → 16.5.0-780 (Cisco recommends moving to 16.5.0-780)
• ▸Published: 14 September 2026, 16:00 GMT (advisory cisco-sa-esa-inj-2bLVGmhX, Version 1.0 Final)
• ▸KEV: added 14 September 2026 / due: 17 September 2026 (US federal civilian agencies)
• ▸Workarounds: none — a fixed release must be installed
• ▸If compromise is suspected: separate recovery steps apply per deployment — physical, contact TAC; virtual, preserve forensics then rebuild on a new VM and renew credentials and cryptographic materials; Cloud, customers Cisco contacted should renew credentials and any cryptographic materials installed on the appliance, when possible, and also restrict appliance access with robust access control