One in three of our security advisories was already under attack

One in three of our security advisories was already under attack

Between 22 September and 28 October 2026 we published 198 security advisories. When we went back through them, 64 described a flaw or a compromise that attackers were already using at the time we wrote about it, or by the time we last updated the item. That is roughly one in three. Six more described a public proof of concept with no confirmed attacks yet. The remaining 128 said nothing about exploitation either way.

That count is the starting point for this piece. We wanted to know what our own advisories, read together, say about the questions a security or IT team has to answer every week: which patches cannot wait, how much warning the US Known Exploited Vulnerabilities catalog actually gives, and whether a high CVSS score is a good stand-in for urgency. The answers are not what a severity-sorted patch queue would suggest.

How we counted

The set is every item in our security advisories category from 22 September, when the category opened, to 28 October 2026: 198 items. Each was written from a vendor advisory, a national CERT, a project's release notes, a CVE record or a researcher's own report, and each lists its sources.

For every item we recorded, from the item's own text only: the vendor and the class of product; whether the text says the flaw is exploited in the wild, has a public proof of concept, or says neither; whether it states a listing in CISA's Known Exploited Vulnerabilities (KEV) catalog, and the dates; the highest CVSS score it states; and whether it carries one of our red verification notes. Where an item gave both the vendor's fix date and the KEV date, we worked out the gap in days. A script did the mechanical extraction, and the exploitation status of every item was read and judged by hand. About 60 rows were checked line by line against the item.

Some limits matter:

• "Exploited" here is broad. It includes seven supply-chain compromises that are not CVE flaws at all, such as poisoned package releases and swapped build artefacts, because for a buyer the effect is the same: attackers were already in. It also counts two vendor statements that a flaw "may have been exploited".
• The set is what we chose to cover. We pick advisories a business buyer should act on, so consumer products are under-represented and enterprise and edge products over-represented. This is not a sample of all CVEs.
• Some items cover the same flaw. A KEV listing often gets its own item after the vendor's advisory, and a few CVEs appear in two or three items. The counts below are of items, not distinct CVEs.
• Exploitation status is as stated. "None stated" means our item did not say; it does not mean the flaw is safe.

None of our own products, and no company connected to us, appears in the data.

Where the attacks were

The 64 exploited items are not spread evenly. By class of product:

Product class	Items	Exploited	Share exploited
Network and edge devices	30	16	53%
Enterprise applications (ERP, CRM, collaboration)	36	11	31%
Server and web software	25	10	40%
Developer tools and CI	18	5	28%
Virtualisation, backup and storage	11	4	36%
Security products	11	4	36%
Operating systems and kernels	8	4	50%
AI tooling	11	3	27%
Identity and access	4	2	50%
Open-source libraries and packages	21	1	5%
Browsers	4	0	0%
Other, including industrial	19	4	21%

Network and edge devices, the firewalls, VPN gateways, SD-WAN orchestrators and identity appliances that sit on the internet by design, were the largest single source of exploited flaws and had the highest exploited share. Cisco's ISE authentication bypass, with a CVSS score of 10, went into KEV on the same day as the advisory. Arista's VeloCloud Orchestrator had one flaw exploited in September and another listed in KEV one day after its October advisory. SonicWall's SMA1000 flaw went from a pre-authentication advisory to observed exploitation attempts in three days.

The libraries row is the mirror image. Open-source libraries and packages account for 21 items but only one exploited flaw, and four of the six public proofs of concept. A library flaw has to be reached through an application before it can be exploited, so researchers publish proof-of-concept code long before anyone finds a target worth attacking. That does not make library flaws safe to ignore, but it does mean the urgency usually sits with the products that embed them.

The supply-chain cases deserve their own mention because no patch prevents them. The LiteLLM releases published on PyPI, Docker Hub and GHCR, and the OVHcloud CLI binaries swapped for a credential stealer, were live for about two hours and about 94 minutes respectively. Anyone who installed during those windows had to rotate credentials, not just upgrade. In the same week, stolen GitHub tokens were used to dump Actions secrets across hundreds of accounts.

How much warning KEV gives

Thirty-five items state a KEV listing. That is fewer than the 64 exploited items, which matters in itself: a little under half of the attacks we reported were not, or not yet, in the catalog when we wrote about them. Some were supply-chain incidents that KEV does not list. Others had exploitation reported by a vendor, a CERT or a threat intelligence firm before CISA acted. Dolibarr's file-read flaw is an example: reported exploited by Italy's national cyber agency and by a commercial exploitation catalogue, and not in KEV when we checked.

For 23 items we have both the vendor's fix date and the KEV date. The gap between them was:

• 0 days in 7 items. The vendor's advisory and the KEV listing came the same day, usually because the vendor itself reported active exploitation.
• 1 to 5 days in 6 items.
• 6 to 30 days in 2 items.
• More than 30 days in 8 items.

The median gap is five days. Two things follow. For more than half of these flaws, the KEV listing arrived within a working week of the patch, so a team that waits for KEV before acting on an edge device has, at best, a few days' head start on its peers and often none. And for the other end of the range, KEV is a record of what is already happening, not an early warning. WSO2's API Manager flaw was listed about 144 days after its patch. A Zyxel switch flaw fixed in June went in after 97 days. Nextcloud's built-in code server flaw was exploited before it was disclosed, fixed on 11 September and listed 42 days later.

The PHP2Shell case shows the tight end. Honeypots saw a first attempt on 17 October, four days before PHP's fixed releases on 21 October. CISA added both CVEs on 26 October with a federal deadline three days later, and on 28 October it added a Linux kernel flaw that can be chained with them to plant webshells as root. The attack was under way before the patch existed.

Old flaws come back too. The PAN-OS GlobalProtect flaw used by two ransomware groups in October was fixed and listed in KEV on the same day in May. Five months on, the devices being hit were the ones that had never been patched.

What CVSS does and does not tell you

Of the 198 items, 106 state a CVSS score. Sixty-nine of those are 9.0 or higher, 30 are between 7.0 and 8.9, and seven are between 4.0 and 6.9. None is below 4.

If scores predicted attacks, the exploited items would cluster at the top. They do not, much:

Highest stated CVSS	Items	Exploited	Share	In KEV
9.0 or higher	69	27	39%	18
7.0 to 8.9	30	10	33%	5
Below 7.0	7	1	14%	1
No score stated	92	26	28%	11

Critical scores do carry somewhat more exploitation, but the difference between a 9.8 and an 8.1 is small next to the difference between an internet-facing appliance and a library. And 26 exploited items, two fifths of the total, came with no score at all. They include the seven supply-chain compromises, which carry no score by nature, and advisories from vendors that rate on their own scale.

The low end makes the point sharply. The one exploited item in the set with a score below 7 is a Fortinet command-line path traversal flaw rated 6.0, which went into KEV in October. Just after our counting window closed, CISA also listed a VMware ESX logging flaw rated 2.7 by Broadcom, which lets a malicious administrator act without leaving a record, three months after its patch. Neither is severe on its own; both are useful to someone who already has a foothold.

Scores also disagree. In our own items, Microsoft's SharePoint flaw CVE-2026-65660 appears as a 6.5 in one report and an 8.8 in another, because the vendor revised its rating. WSO2's flaw is a 10 in one source and a 9.8 for single-tenant deployments in another. Only 43 items state which CVSS version a score uses, and version 3.1 and 4.0 scores for the same flaw can differ. A patch queue sorted by score alone inherits all of that noise.

How fast attacks followed disclosure

The fastest cases in the set were measured in hours. Probing of WordPress 7.1.2's path traversal flaw began less than five hours after release, with a public proof of concept the same day. Several edge-device flaws were exploited before disclosure, which is why seven items show the vendor's fix and the KEV listing on the same day.

The exploited share also moved week to week. In our first week, 14 of 18 items were about attacks already under way. In the four full weeks that followed, the weekly count of exploited items held between 9 and 14 while the total number of advisories rose to 50 in the week of 19 October, so the exploited share fell as we covered more routine patch releases. A team reading only the exploited items would have had about a dozen a week to act on.

What our red notes tell you

Of the 198 items, 107 carry a red verification note, which we add when an item rests on a single source or when something material could not be confirmed. By source, the share was 57% for items built on a vendor advisory, 55% for national CERTs, 53% for researcher and press reports, 41% for project release notes and one of four for items built on a CVE record.

The vendor figure may look surprising, but it is the expected pattern. A vendor's advisory is the authoritative source for fixed versions and is usually the only one on the day; independent confirmation, from a CERT, a second researcher or a KEV listing, tends to come later. Twenty-six of the 64 exploited items carried a red note when we last updated them, usually because exploitation was reported by one party only.

Reading 198 items together also showed us where our own items need tightening. In a handful, an early "no exploitation reported" sentence sits above a later update reporting a KEV listing, as in the Brotli decoder flaw and GitLab's CVSS 10 regex flaw. Both statements were true when written, but a reader who stops at the first paragraph gets the wrong answer, so the latest update in an advisory is the one to rely on.

What to take from it for patching

For a business deciding what to patch first, the count suggests a few rules that are specific to how attacks actually landed in these six weeks:

• Patch internet-facing devices on the day, regardless of score. Half of the edge-device advisories we published involved exploitation, and the KEV listing often came the same day. Firewalls, VPN gateways, SD-WAN orchestrators and identity appliances belong in a separate, faster queue.
• Treat KEV as a floor, not a trigger. A little under half of the exploited items were not in KEV when we reported them. Vendor statements of active exploitation, and national CERT alerts, are earlier signals.
• Use CVSS to break ties, not to set the order. A 9.8 in a library that your products do not expose can wait behind a 7.5 on your VPN.
• Have a plan for compromised releases. Supply-chain incidents need credential rotation and build provenance checks, not an upgrade. If your teams pull packages and binaries automatically, pinning and short windows of exposure are what limit the damage.
• Go back for the old ones. The ransomware campaign against a May PAN-OS flaw is a reminder that unpatched edge devices stay targets for months.

Our network security category lists 6 products. Six weeks is a short window, and the counts above describe what we reported, not every vulnerability disclosed in the period; the pattern to watch is whether edge devices keep their lead as the set grows.