{"id":2919,"date":"2026-09-15T02:55:18","date_gmt":"2026-09-15T09:55:18","guid":{"rendered":"https:\/\/www.cycognito.com\/blog\/?p=2919"},"modified":"2026-09-15T02:55:20","modified_gmt":"2026-09-15T09:55:20","slug":"emerging-threat-cve-2026-76461-cisco-secure-email-gateway-root-rce-via-email-parsing","status":"publish","type":"post","link":"https:\/\/www.cycognito.com\/blog\/emerging-threat-cve-2026-76461-cisco-secure-email-gateway-root-rce-via-email-parsing\/","title":{"rendered":"Emerging Threat: (CVE-2026-76461) Cisco Secure Email Gateway Root RCE via Email Parsing"},"content":{"rendered":"\n
\"\"
Sample of assets impacted by Cisco Secure Email Gateway RCE vulnerability, identified by the CyCognito Platform<\/em><\/figcaption><\/figure>\n\n\n\n

What is CVE-2026-76461?<\/h2>\n\n\n\n

CVE-2026-76461 is a SQL injection vulnerability in the email parsing logic of Cisco AsyncOS Software for Cisco Secure Email Gateway, caused by insufficient validation of message content before it reaches a database query. An attacker who sends a crafted email message containing SQL statements can have those statements executed by the appliance as it processes the message.<\/p>\n\n\n\n

The vulnerability carries a CVSS v3.1 base score of 9.8 (Critical). Exploitation is pre-authentication and requires no user interaction. The attacker does not need credentials, a session, or access to the management interface. Sending mail to an address the appliance handles is sufficient.<\/p>\n\n\n\n

Successful exploitation results in arbitrary command execution on the underlying operating system with root privileges. That level of access permits installation of persistence mechanisms, credential theft from the appliance, inspection of mail in transit, and lateral movement into connected infrastructure.<\/p>\n\n\n\n

Cisco’s Product Security Incident Response Team reported awareness of exploitation in the wild in September 2026, and the vulnerability was added to CISA’s Known Exploited Vulnerabilities catalog with a remediation deadline of September 17, 2026, for federal civilian agencies.<\/p>\n\n\n\n

What assets are affected by CVE-2026-76461?<\/h2>\n\n\n\n

The vulnerability affects Cisco AsyncOS Software for Cisco Secure Email Gateway in releases 15.5 and earlier, release 16.0, and release 16.5. Both physical appliances and virtual deployments are affected, and reporting indicates the issue is not dependent on a specific feature configuration. Cisco Secure Email and Web Manager and Cisco Secure Web Appliance are reported as unaffected.<\/p>\n\n\n\n

In practice, an affected asset is a mail gateway sitting at the perimeter, accepting SMTP from the public internet by design. These devices are the first hop for inbound mail, which is what makes the attack path so short: the same traffic the appliance exists to process is the traffic that carries the payload. There is no exposed management console to find and no login to bypass.<\/p>\n\n\n\n

Mail gateways also tend to be long-lived infrastructure. They are provisioned once, wired into MX records and downstream mail routing, and left alone because upgrading them interrupts mail flow for the entire organization. Clustered deployments compound this, since a cluster presents several individually addressable appliances and a patch cycle has to cover all of them. The result is a class of asset that is permanently internet-facing, rarely touched, and frequently absent from the inventories that drive patching priority.<\/p>\n\n\n\n

What does our data show about exposure patterns?<\/h2>\n\n\n\n
\"\"<\/figure>\n\n\n\n

Exposure in this set is led by Information Technology at 28.7% of observed assets, with Financials contributing 23.2% and Industrials 17.1%. These assets were predominantly identified by service fingerprint rather than by confirmed version detection, so they represent infrastructure observed running the affected software and potentially exposed, not confirmed vulnerable instances.<\/p>\n\n\n\n

The concentration in Information Technology reflects what that sector runs rather than how carefully it runs it. Systems integrators, managed service providers, and outsourcing firms operate mail infrastructure on behalf of client organizations, which multiplies the number of gateways a single company maintains and spreads them across regions, acquisitions, and inherited client estates. Financials show a similar pattern for different reasons: regulated messaging retention, strict inbound filtering requirements, and a low tolerance for mail outages all push toward dedicated appliance hardware that stays in place across upgrade cycles.<\/p>\n\n\n\n

Across sectors, the pattern points at a structural problem rather than a patching failure. Mail gateways are perimeter devices whose entire function is to accept untrusted input, yet they are commonly classified as infrastructure rather than as an attack surface, which leaves them outside the scanning cadence applied to web applications and VPN endpoints. <\/p>\n\n\n\n

Geographic distribution in this set spans both regional appliances serving individual country operations and centralized clusters handling mail for multiple markets, which means an accurate picture of exposure requires visibility into an organization’s full external footprint rather than its primary region.<\/p>\n\n\n\n

Are fixes available?<\/h2>\n\n\n\n

Yes. Cisco has released fixed AsyncOS builds for all affected release trains. Reporting identifies the fixed releases as 15.5.5-0141 for the 15.5 and earlier train, 16.0.4-3021 for release 16.0, and 16.5.0-780 for release 16.5, with migration to 16.5.0-780 recommended where the platform supports it.<\/p>\n\n\n\n

There are no workarounds. Cisco has stated that no configuration change addresses the vulnerability, which means patching is the only remediation. Interim network controls such as restricting management access or segmenting interfaces reduce follow-on movement but do not block the initial exploitation path, because that path runs through normal inbound mail.<\/p>\n\n\n\n

Because this vulnerability is under active exploitation and grants root access, patching alone does not close the incident. An appliance that was reachable and unpatched during the exploitation window should be treated as potentially compromised until proven otherwise. Defenders should confirm exact fixed build numbers directly with Cisco against their specific platform and release train rather than relying on secondary reporting, and should engage Cisco TAC where compromise is suspected.<\/p>\n\n\n\n

Are there any other recommended actions to take?<\/h2>\n\n\n\n

Recommended actions alongside patching:<\/p>\n\n\n\n