Patching Is Not Remediation: We Measured How Often the Patch Is Already Too Late

On 14 September 2026, Cisco published an advisory for CVE-2026-76461, a SQL injection flaw in the email parsing of AsyncOS, the software behind Cisco Secure Email Gateway. It scores 9.8 out of 10. It needs no credentials, no administrative access and no user interaction: a crafted message arriving through the gateway can end in command execution as root on the appliance. There is no workaround. The remedy is a fixed release.

The same day, CISA added it to the Known Exploited Vulnerabilities catalogue, which is the federal government saying it is being used against real targets right now. Federal agencies were given until 17 September 2026 to fix it, 3 days.

Every write-up of this, ours included, ends up recommending the same first step: install the patch. That advice is correct and it is also the least interesting thing to say, because it quietly assumes something nobody checks. It assumes there was a period during which you could have patched and been safe.

So we measured whether that period exists. Not for this vulnerability, for all of them.

The window, measured

Two public records make the question answerable. The CVE record for a vulnerability has a publication timestamp: the moment the world could first know the flaw exists. CISA's catalogue has a listing date for each entry: the moment the government said it is already being exploited. Subtract one from the other and you have the warning you actually got.

We did that for the entire catalogue, 1713 entries as of version 2026.09.16, and counted the 846 of them listed from 2023 onwards.

Read the bold row again. For one entry in five, the day the vulnerability became public knowledge is the day it was already being used. There was no window. A team with a flawless patching process, alerting on vendor advisories, with change control that can ship an emergency release in an afternoon, would have been exposed for exactly as long as everyone else: the whole time before anyone knew.

24 entries go further and were listed as exploited before the CVE record was public at all. And this year, 228 entries in, 2026 is running at 17.5% same day with a median gap of 15 days. Cisco alone accounts for 17 of this year's entries, second only to Microsoft with 38.

The median of 18.5 days is not the comforting half of this either. It is the number that describes the vulnerabilities you heard about before they were weaponised, and 18.5 days is shorter than most quarterly maintenance windows, shorter than a lot of change advisory board cycles, and considerably shorter than the time it takes a mid-sized company to get approval to reboot a mail gateway.

What this measurement is not

The limits matter more than the headline, so here they are.

• A listing date is not an exploitation date. CISA lists a vulnerability after it has confirmed exploitation, which is always after the exploitation started. Every gap here is therefore generous to the defender. The real warning was shorter than what we measured, never longer.
• The catalogue is a floor, not a census. It holds what CISA has confirmed and chosen to publish. Exploitation nobody caught is not in it.
• 2023 is the floor for a reason. The catalogue opened in late 2021 seeded with a backlog, so the early cohorts are old vulnerabilities being filed years after the fact: a median age at listing of 446 days for the 311 entries added in 2021 and 1436 days for the 555 added in 2022. Including them would measure an archiving project rather than a race, so they are excluded from every figure above and shown here only as the reason.
• A CVE record is a proxy for public knowledge. It usually lands with the vendor advisory but not always to the hour, so treat single-day precision as approximate. It is the distribution that carries the argument, not any one row.

Method, in one sentence, so anyone can reproduce it: join the CISA KEV catalogue to the MITRE CVE Services API on the CVE id, subtract the record publication date from the listing date, and count. Nothing was scanned, probed or connected to, and no organisation is named. Figures on this page were generated on 17 September 2026 from catalogue version 2026.09.16.

Which changes what the word remediation means

If a meaningful share of serious vulnerabilities are in use before you could possibly have known about them, then applying the patch is not the end of the work. It is the start of a different question: was anyone already inside before the patch landed?

For CVE-2026-76461 that question is not theoretical. The flaw gives command execution as root, and CISA listed it as exploited the day it was disclosed, which means some appliances were compromised before their owners had a fixed release to install. Patching such a box upgrades the software. It does not evict anybody who got there first, and it does not undo what they took.

An email gateway is the worst box on the network to lose

Every internet-facing appliance is a bad thing to lose. A mail gateway is worse than most, and it is worth being concrete about why, because the instinct is to treat it as a filter rather than as a system holding secrets:

• It holds directory credentials. Gateways bind to LDAP or Active Directory to resolve recipients and enforce policy. That bind account is a foothold in the directory, and it is frequently older and more privileged than anyone remembers.
• It holds sending credentials. Relay accounts, provider API keys, and the reputation attached to them. That is the single most monetisable thing on the machine, which is why credential-hunting campaigns go looking for exactly these files, as we found on our own infrastructure in a measurement of the background attack traffic.
• It holds TLS private keys for the hostnames it serves, and the certificates behind them.
• It sees the mail. Not headers, the messages: invoices, contracts, password resets, board papers, everything the organisation sends and receives, in plaintext, by design.
• It is trusted by the things behind it. Mail infrastructure sits in a position most firewalls were configured to trust, and lateral movement from a trusted relay is not an exotic technique.

What remediation actually involves

The order matters, and the first item is the one most often skipped because it is uncomfortable.

1. Decide whether you are patching or responding. If the vulnerability was exploited before you patched, and you cannot rule out that your device was reached, you are running an incident, not a maintenance task. The two have different budgets and different people.
2. Look outside the appliance first. Root on a device means the device's own logs are editable by the intruder. The evidence that can be trusted is the evidence stored elsewhere: firewall and flow records, DNS resolver logs, proxy logs, mail records held by whatever sits in front of or behind the gateway. Start there, not with the box's own report of its health.
3. Treat every secret the box could read as public. Directory bind accounts, relay and API credentials, admin passwords, private keys and certificates. Rotate them on the assumption they are already copied, because rotation after a compromise is not a precaution, it is the remediation.
4. Prefer rebuilding to cleaning. On a virtual appliance a clean instance from a fixed image, with configuration re-applied, is faster and far more trustworthy than trying to prove a rooted system is now empty. You cannot prove that from inside the system.
5. Check every node, not the one you logged into. Clustered appliances are individually reachable and individually compromisable.
6. Get management interfaces off the internet. The data path has to be exposed. The administration of it does not, and that is true of every appliance you own, not just this one.

For this particular vulnerability, the operational facts are short: the fixed branches are published in Cisco's advisory (confirm the exact release string for the branch you run against the advisory itself rather than any article, this one included, because the secondary coverage does not agree with itself), and public write-ups report that mail log entries matching COPY ... TO PROGRAM are worth hunting for as a sign of command execution. Neither is a substitute for deciding, first, whether you are in the maintenance case or the incident case.

The defences that do not depend on being fast

The uncomfortable conclusion of the measurement is that speed has a ceiling. You can shorten your patch cycle from thirty days to three and still lose to the one entry in five that was in use before disclosure. What actually helps is the set of controls that keep working while you are unaware:

• Credentials with short lives. A stolen secret is only worth what remains of its validity. Rotation on a schedule turns theft into a deadline for the attacker.
• Egress control. Most post-exploitation needs to reach outward. An appliance that can only talk to the handful of destinations it actually needs is a far worse prize than one with open outbound access.
• Telemetry stored off the device. If the only record of what a box did lives on the box, then root on that box means there is no record. This is the cheapest control on the list and the one most often missing.
• Segmentation that assumes the appliance falls. The question to design against is not whether the gateway can be compromised, it is what an attacker reaches from it.
• Backups an attacker cannot reach from the compromised network. The expensive version of these incidents is always the one where the intruder found the credentials to the backups.

144 of the 846 entries since 2023 are recorded in the catalogue as having known ransomware campaign use, which is 17%. CISA's median deadline for fixing a listed vulnerability is 21 days from listing. Those two numbers together are a reasonable description of the pace this is happening at.

If you run any of this

The specific advice for Cisco Secure Email Gateway is to go to the vendor advisory, install the fixed release for your branch as an emergency change, and then decide honestly whether you can rule out having been reached first. If you cannot, the credential rotation is not optional.

The general advice is the part that outlives this CVE. Write down which internet-facing appliances you own and who owns each one, because the boxes at the edge are usually the ones with no named owner and no patch cadence. Make sure their logs are shipped somewhere they cannot be edited from the device. Rotate the credentials they hold on a schedule rather than after an incident. And when the next advisory lands, treat the phrase “patch immediately” as the first step of the work rather than the whole of it, because one time in five the attackers started before the advisory did.

Sources and method: vulnerability details from Cisco's security advisory for CVE-2026-76461 and from CISA's Known Exploited Vulnerabilities catalogue. The measurement joins that catalogue (version 2026.09.16, released 16 September 2026, 1713 entries) to the MITRE CVE Services API on the CVE identifier and compares the catalogue listing date with the CVE record publication date. Entries listed before 2023 are excluded as catalogue backfill, for the reason given above. Figures generated on 17 September 2026. Nothing was scanned, probed or connected to, and no organisation is named as vulnerable or compromised.