Cisco's exploited email gateway flaw: three days to patch, and patching starts the investigation

Zero days to the catalogue, three days to the deadline

Cisco published its advisory for CVE-2026-76461 at 16:00 GMT on Monday 14 September 2026. CISA added the flaw to its Known Exploited Vulnerabilities catalogue the same day and set a due date of Thursday 17 September. That is zero days from disclosure to the catalogue and three days from the catalogue to the deadline, which falls today. The last actively exploited AsyncOS flaw, CVE-2025-20393, was added on 17 December 2025 with a due date of 24 December: seven days, under the directive CISA has since replaced.

The flaw is an SQL injection in the email parsing of Cisco AsyncOS Software for Cisco Secure Email Gateway. Cisco says an unauthenticated, remote attacker can exploit it by sending a crafted email containing malicious SQL statements through an affected device, and that a successful exploit leads to command execution with root privileges on the underlying operating system. It affects physical and virtual appliances "regardless of device configuration". There is no workaround.

Here is what that date does not establish. It is a compliance deadline for US federal civilian agencies, not a measure of how long you have. It does not say when exploitation began: Cisco says only that its security team became aware of it in September 2026, which puts that awareness no more than 13 days before the advisory. It names no attacker, gives no victim count, and says nothing about whether a gateway patched on time was already compromised.

The catalogue entry itself says patching is not the whole job. CVE-2026-76461 is one of 55 entries, out of 1,713 in the catalogue version CISA published on 16 September, that carry CISA's forensic triage flag. Agencies must fix the flaw and check whether the device was compromised. For a box that reads every inbound message and holds directory and cloud mail credentials, that second job is the one that decides how the week ends.

Checking the claims against the record

Coverage summarised the advisory as confirming active in-the-wild root exploitation with a CVSS score of 9.8. We read the advisory in full, in HTML and in its machine-readable CSAF form, alongside the NVD record and the KEV entry. Most of that summary holds. Two parts need more care: who scored it, and what "root exploitation" means on the record.

Claims tested against Cisco advisory cisco-sa-esa-inj-2bLVGmhX (version 1.0), the NVD API record and the CISA KEV JSON, read 17 September 2026

Claim	What the primary record says	Verdict
Exploited in the wild	Cisco PSIRT became aware of active exploitation in September 2026. Cisco contacted Secure Email Cloud customers whose devices showed malicious activity.	Confirmed by the vendor
Root exploitation	A successful exploit gives command execution as root. Cisco does not say which observed attacks reached root or what attackers then did.	Capability stated; observed outcomes not stated
CVSS 9.8	Cisco assigned 9.8 (network, low complexity, no privileges, no user interaction) as the CVE numbering authority. NVD lists it as a Secondary score and has added no score of its own.	Correct, but it is Cisco's score
CISA rated it	CISA's authorised data publisher added SSVC values, not CVSS: exploitation active, automatable yes, technical impact total.	CISA input is SSVC, not CVSS
No workaround	Cisco: there are no workarounds that address this vulnerability.	Confirmed
How it was found	This advisory: during the resolution of a Cisco TAC support case. The same-day hardening advisory: its vulnerabilities were found during internal testing, one of them actively exploited.	Two Cisco wordings, not reconciled

The NVD record, marked Analyzed, carries CPE ranges that match Cisco's fixed releases: AsyncOS before 15.5.5-014, 16.0 before 16.0.4-302, and 16.5 before 16.5.0-780, running on C195, C395 and C695 hardware or C100V, C300V and C600V virtual appliances. Cisco's CSAF file lists 24 affected builds from 13.0.0-392 to 16.0.4-016, under bug ID CSCwu56234. The CSAF lists no 16.5 build as affected, although the fixed-release table gives 16.5.0-780 as the first fix for the 16.5 train; if you run an earlier 16.5 build, treat it as affected.

The payload arrives as mail, so the perimeter advice misses it

A mail gateway exists to accept messages from strangers on the internet and parse them. Cisco locates this flaw in that parsing: insufficient validation lets SQL carried in a crafted message run against the appliance's database, and from there run operating system commands as root. The attacker needs no account, no access to the administration interface and no particular feature switched on. They need the gateway to receive their email, which is what it is for.

The one indicator Cisco publishes is a search of the gateway's mail_logs for SQL of the form COPY ... TO PROGRAM. In PostgreSQL, COPY with PROGRAM runs a command through the shell on the database server, and is allowed only to database superusers or specially privileged roles. Inference: the indicator suggests the appliance uses an embedded PostgreSQL database and that attackers used this feature to turn injected SQL into shell commands. Cisco does not name the database engine and does not explain how command execution reaches root.

Compare the December 2025 AsyncOS campaign, CVE-2025-20393. That flaw sat in the Spam Quarantine web feature. Cisco said it was exploitable only where Spam Quarantine was enabled, which is not the default, and reachable from the internet, and that its deployment guides do not require that exposure. A customer who followed the guides was out of scope. CVE-2026-76461 has no such precondition: Cisco says it applies regardless of device configuration.

BleepingComputer reports that Shadowserver tracks over 400 internet-exposed Secure Email Gateway appliances. We have not verified that figure, and it cannot be the whole population at risk, because internal relays and cloud-hosted devices would not appear the same way in a scan.

Which releases fix it, and the 16.0 trap

Cisco published a second advisory in the same hour: the Secure Email Gateway and Secure Email and Web Manager Security Hardening Release. Read the two fixed-release tables side by side and the choice of upgrade target stops being a detail.

First fixed releases for Cisco Secure Email Gateway, from Cisco advisories cisco-sa-esa-inj-2bLVGmhX and cisco-sa-hardening-esa-dfCrfXkm, both published 14 September 2026

Release train	Fixes CVE-2026-76461	Fixes the five hardening CVEs
15.5 and earlier	15.5.5-014	15.5.5-014
16.0	16.0.4-302	No 16.0 fix: Cisco says migrate to a fixed release
16.5	16.5.0-780	16.5.0-780

Cisco footnotes both the 15.5 and 16.0 rows of the exploited-flaw table with a strong recommendation to migrate to 16.5.0-780. The hardening advisory explains why that matters. It covers five CVEs, each standing for a whole class of weakness rather than a single bug: path traversal (CVE-2026-76440), improper access control (CVE-2026-76441), improper control of a resource through its lifetime (CVE-2026-20353) and improper neutralisation, which covers command and SQL injection (CVE-2026-76443), each scored 9.8 by Cisco, plus an input-quantity validation class (CVE-2026-76442) at 7.5.

So a 16.0 gateway moved to 16.0.4-302 is fixed for the exploited flaw and still carries four CVEs that Cisco scores at up to 9.8, because the 16.0 train has no fix for them. Cisco says it knows of no public announcement or malicious use of those five beyond the one exploited flaw it cross-references. That is a reason for a planned move to 16.5 this month, not a reason to stop at 16.0.4-302.

One more line in Cisco's CSAF file is worth pausing on. Build 16.0.4-016, the first fixed release for last winter's CVE-2025-20393, appears in the list of builds affected by CVE-2026-76461. Last season's emergency patch level is this season's vulnerable version.

Two points on method, not motive. First, Cisco assigned one CVE per weakness class and says each score "represents the maximum potential severity" of the worst bug in that class; it does not say how many bugs each CVE covers, so counting CVEs undercounts the fixes. Second, Cisco attributes the hardening findings to internal testing that used "frontier AI models", and presents the release as proactive quality work. That framing may be fair, and it also suits a vendor announcing an exploited zero-day on the same afternoon. Neither point changes what to install. Secure Email and Web Manager is covered by the hardening CVEs (first fixes 15.5.5-006 and 16.5.0-429, with no 16.0 fix) but Cisco says it is not affected by CVE-2026-76461.

Cisco's own hosted fleet was in scope

Cisco Secure Email Cloud is Cisco running Secure Email Gateway and Secure Email and Web Manager devices on a customer's behalf. The advisory says Cisco conducted a threat intelligence investigation across those devices, directly contacted customers whose devices showed indicators of possible compromise, is engaged in remediation and recovery operations, and has already upgraded every Cloud device to 16.5.0-780. It also says Cloud administrators without CLI access may not be able to check the indicators themselves, and recommends that contacted customers renew credentials and cryptographic material installed on the appliance.

In December 2025 Cisco said all Secure Email Cloud devices were unaffected by CVE-2025-20393. This time the hosted service was not only affected; on Cisco's own wording, some of its devices showed malicious activity.

For a Cloud customer this cuts both ways. The fix arrived without you lifting a finger. So did the reboot, before you could collect anything, and the only party that can see the device is Cisco. Inference: not being contacted is not proof of a clean device, because Cisco's published indicator is described as non-exhaustive and Cisco itself warns that root access lets attackers remove evidence. The advisory does not say how many Cloud customers were contacted, over what dates activity was seen, or what the attackers touched.

What a rooted mail gateway holds

Cisco's recovery advice tells customers to renew "credentials and any cryptographic materials that are installed on the appliance" but does not list them. Its user guides do, feature by feature. What sits on a given gateway depends on how it was configured, which is exactly why a rotation list has to be built from your configuration rather than from the advisory.

What a Secure Email Gateway may hold, from Cisco AsyncOS user guides (15.0 and 16.0); the third column is our inference

Held on or passing through the gateway	Documented purpose	Why it matters beyond the box
Every inbound message	Parsing, filtering, quarantine and delivery	Mail can be read, altered or dropped while the gateway is controlled; its verdicts for that period cannot be trusted
LDAP bind username and passphrase	Recipient acceptance, routing, masquerading, group policy, SMTP authentication, admin and quarantine logins	A directory account that works elsewhere on the network, with whatever rights it was given
Microsoft 365 app client secret, or certificate and private key (if mailbox auto remediation is set up)	Graph application permissions: Mail.Read, Mail.ReadWrite, Mail.Send, Directory.Read.All	Mailbox read, delete and send-as across the tenant, usable away from the gateway until rotated
On-premises Exchange impersonation account (if configured)	Remediating messages in Exchange mailboxes	Access to mailboxes under an account granted impersonation rights
DKIM private signing keys	Signing outbound mail for your domains	Mail that passes DKIM as your domain, sent from infrastructure you do not run
Certificates and other keys installed on the appliance	TLS for mail and interfaces	Scope depends on where else those keys are trusted

The Microsoft 365 row deserves first attention where it applies. Cisco's AsyncOS 16.0 guide to remediating messages in mailboxes has administrators register the gateway as an Azure application with application permissions, including Mail.Send, which the guide describes as "Send mail as any user", and store either a client secret or a certificate's private key on the gateway. Inference: a secret lifted from a rooted gateway is not bound to the gateway. It works from anywhere until someone rotates it, and patching the gateway does nothing to it. Check your own tenant's app registration, because permissions may differ by release.

The LDAP guide shows the gateway authenticating to the directory with a full distinguished name and passphrase stored in its server profile, and using those queries for mail routing, SMTP authentication and administrator logins. The email authentication guide says plainly that a DKIM signing key is the private key stored on the email gateway.

Patching ends the exposure, not the incident

Cisco's upgrade instructions end the same way for the web interface and the CLI: after the upgrade completes, the device reboots. Whatever lived only in memory is then gone. CISA's forensic triage guidance, which this KEV entry invokes, orders the work the other way round. Evidence collection comes before patching, with the instruction not to alter or remediate systems before collecting artefacts where possible, and a warning that "premature containment can destroy vital evidence". CISA's own target times put scoping in the first two hours, evidence and patching inside 24, analysis by 48 and an escalation decision by 72. CISA stresses those times are recommendations; the requirement is an adequate triage.

Cisco's advice then splits by form factor. For a virtual appliance where exploitation is suspected, Cisco says to record forensic information first, because deploying a new instance destroys configuration and logs; then deploy a new virtual machine on a fixed release, rebuild the configuration, renew credentials and cryptographic material, and keep monitoring. For a physical appliance, Cisco says to contact TAC and enable remote access so Cisco can investigate. It publishes no rebuild or rotation steps for physical boxes. Inference: the credentials on a physical gateway are exposed in exactly the same way, so rotate them regardless of form factor.

The contrast with December is instructive. For CVE-2025-20393, Cisco said the fix "clears the persistence mechanisms" identified in that campaign. The 2026 advisory makes no such claim for the upgrade and does not say whether persistence has been seen. It also does not say whether "rebuild the product configuration" may mean importing a configuration file saved from the suspect device. Inference: a file exported after compromise can carry changes an attacker made, such as extra accounts or altered mail routes, so rebuild from a known-good record or review the file line by line.

grep -i "COPY.*TO PROGRAM" mail_logs

Cisco's second instruction on detection matters more than the grep. Because an attacker with root "may" remove or hide evidence, Cisco tells administrators to cross-check network and firewall logs held outside the device, looking for unexpected uploads from the gateway to external addresses and downloads from malicious ones. That is the evidence an intruder on the gateway cannot edit.

What an incident lead needs to know, against what Cisco's advisory, the KEV entry and CISA's guidance state, as of 17 September 2026

Question	Stated	Not stated
When did exploitation start?	Cisco became aware of active exploitation in September 2026	Earliest known attack; date of the TAC case that surfaced it
Who is behind it?	Nothing from Cisco or CISA; Rapid7 reported no attribution on 15 September	Actor, campaign, any Cisco Talos analysis
How do I check a gateway?	Search mail_logs for COPY ... TO PROGRAM; cross-check external network and firewall logs	Network indicators, file hashes, persistence artefacts
Does the upgrade remove an implant?	Not addressed	Whether persistence has been observed at all
What must be rotated?	Credentials and cryptographic material installed on the appliance (virtual appliances; contacted Cloud customers)	A list; any rotation advice for physical appliances
How many victims?	Cloud customers with malicious activity were contacted	Counts, sectors, regions, on-premises victims

What CISA's three days measure

BOD 26-04, issued on 10 June 2026, revoked BOD 22-01 and BOD 19-02. KEV due dates now come from a decision table: is the asset publicly exposed, is the flaw in the KEV, can an adversary automate the exploit, and does it give partial or total control. CISA's implementation guidance says that a publicly exposed, automatable, total-impact KEV entry gets a three-day deadline. CISA's data publisher recorded exactly those values for CVE-2026-76461: exploitation active, automatable yes, technical impact total. Where the table adds forensic triage, agencies must remediate within three days and triage the asset to assess whether it is compromised.

We counted the effect across the catalogue. Of the 96 entries whose required action cites BOD 26-04, the first added on 11 June 2026, 73 carry a three-day window and 23 a 14-day window. All 55 entries flagged for forensic triage are three-day entries. Of the 26 additions so far this September, 18 are three-day and 17 of those require forensic triage.

Keep the method separate from the judgement. Three days is CISA's stated risk tolerance for US federal civilian systems, set by a formula; it is not a finding that three days is enough to investigate a mail gateway, and CISA's own step timings are targets. UK organisations are not bound by it at all. The logic is still worth borrowing: a mail gateway is publicly exposed by definition, so any exploited flaw in it that gives total control belongs in your fastest lane, with an investigation attached.

What to do, in order

The question that exposes the gap

The deadline asks one question: have you patched? It is the easy one. The question that tells you whether this is over is harder: if the gateway was rooted before the upgrade, which credentials and keys did it hold, and has every one of them been rotated and checked for use elsewhere? And for anyone on Secure Email Cloud: what did Cisco see on our devices before it upgraded them, and will it give us that evidence?

Key facts