Patch What’s Being Exploited, Not What Scores Highest: Vulnerability Prioritisation for Australian Organisations
Most organisations still run their patch queue the way they did ten years ago: sort by CVSS score, work from the top, report the percentage closed within SLA. The data from the first half of 2026 shows why that model is now failing in both directions. It spends effort on vulnerabilities nobody will ever exploit, and it’s too slow for the ones that matter.
This article looks at what the latest exploitation data actually says and how to build a prioritisation model around evidence rather than severity. It also covers the part that usually gets lost when people argue for “risk-based patching”: the routine cadence still has to get faster.
The queue problem
VulnCheck’s State of Exploitation report for the first half of 2026 puts numbers on something most vulnerability management teams already feel.
CVE volume is growing much faster than exploitation. CVE publications rose 45% compared with the previous six months. Known exploited vulnerabilities (KEVs) rose 10%. The ratio of newly exploited vulnerabilities to newly published CVEs has fallen from 2.7% in the second half of 2023 to 1.4% in the first half of 2026.
Early exploitation is flat in absolute terms. Roughly 200 CVEs went from publication to confirmed exploitation within 31 days, in line with 2024 (196) and 2025 (194). The pile is getting bigger; the dangerous part of it isn’t growing at the same rate.
But what does get exploited is getting there faster. The median time from CVE publication to confirmed exploitation fell from 120 days in 2025 to 80 days. And 23.43% of the vulnerabilities confirmed as exploited showed evidence of exploitation on or before the day the CVE was published. That’s down from 28.93% in 2025, but it’s still close to one in four.
Put those together and the problem with a severity-sorted queue is clear. A queue that grows 45% every six months fills with high-scoring vulnerabilities that will never be used against anyone, while the ones that are being used move through faster than a monthly cycle can catch them.
Reading the data honestly
Before building anything on these numbers, three caveats.
VulnCheck is a vendor. It sells vulnerability intelligence, and the report draws on its own KEV catalogue and its own network of vulnerable honeypots (“canaries”). That doesn’t make the data wrong, but the report also argues for the kind of product VulnCheck sells. Read it the way you’d read any vendor research: useful, not neutral.
VulnCheck’s KEV list is broader than CISA’s. It counts any credible public evidence of exploitation, not just what the US Cybersecurity and Infrastructure Security Agency has confirmed. That breadth is actually one of the more useful findings: of the 61 vulnerabilities VulnCheck saw exploited against its own canaries in the half, only 12 had been added to CISA’s KEV catalogue. If CISA KEV is your only exploitation signal, you’re working from a narrow, lagging view.
Part of the content management system (CMS) trend is an artefact. CMS platforms accounted for a third of all newly exploited vulnerabilities, a higher share than VulnCheck has seen before. But the report itself notes that the jump in exploited CVEs since 2024 lines up with WordPress security firms (Patchstack, Wordfence, WPScan) scaling up CVE assignment for plugins. More WordPress plugin bugs are getting CVE numbers than before. Some of the apparent surge is better counting, not purely a change in attacker behaviour.
None of that undermines the central point. It just means the numbers are a direction, not a precise measurement.
Why severity isn’t likelihood
CVSS measures how bad a vulnerability would be if exploited. It says nothing about whether anyone will exploit it. A 9.8 in a library nobody can reach from the network and a 7.5 in an internet-facing VPN appliance under active attack are scored in the wrong order for almost every organisation.
The signals that actually predict risk sit in three places:
Exploitation evidence. Whether there’s credible evidence the vulnerability is being used. CISA KEV is the best known source, but given the gap described above, it should be one input rather than the only one. VulnCheck publishes its KEV catalogue free to the community, and vendor advisories, ASD alerts and threat intelligence feeds all add coverage.
Exposure. Whether the vulnerable system can be reached by an attacker. An internet-facing system with a public exploit is a different problem from the same vulnerability on an isolated internal server.
Privilege. What an attacker gets if the exploit works. A vulnerability in a domain controller, an identity provider, an endpoint management platform or a security tool hands over far more than one in a desktop application.
EPSS, the Exploit Prediction Scoring System, is useful for ordering work where there’s no exploitation evidence yet. It estimates the probability that a vulnerability will be exploited in the next 30 days. CVSS still has a role, but it’s a tiebreaker inside a priority band, not the thing that sets the band.
A two-speed model
The practical model has two lanes. Most organisations already have something like this in policy. Where they fall down is in how each lane is triggered and how fast the slower lane actually moves.
The fast lane: evidence-triggered
A vulnerability goes into the fast lane when any of these is true:
There’s credible evidence it’s being exploited, from any source you trust, not just CISA KEV.
It’s internet-facing and either a working exploit exists or the vendor rates it critical. This is the trigger the Essential Eight already uses for online services, covered below.
It sits in a high-privilege platform and there’s exploitation evidence, even if the system is internal. Security tools and device management platforms are the obvious examples, and the data shows they’re being targeted fast.
The fast lane’s target is measured in hours to a couple of days, not weeks. If a patch isn’t available or can’t be deployed in that window, the lane still has to produce an action: isolate, restrict access, apply a vendor mitigation, or take the service offline.
The baseline lane: everything else, faster than you think
This is where most “risk-based patching” arguments go wrong. They describe the fast lane in detail and then imply the rest can wait. It can’t, for two reasons.
The baseline catches what the signals miss. Close to a quarter of exploited vulnerabilities in the first half of 2026 were being exploited on or before the day their CVE was published. For those, there’s no KEV entry, no EPSS score and no advisory to trigger the fast lane in time. The only defence is already being current. A shorter routine patching cycle shrinks the window for everything you don’t yet know is dangerous.
The baseline is the emergency process. When an emergency patch is needed, it travels through the same pipeline as every routine one: the same asset inventory, deployment tooling, testing approach, change process and rollback plan. If routine patching is a manual monthly effort that regularly slips, a 48-hour emergency patch becomes a scramble that depends on a few people working late. If routine patching runs frequently and mostly automatically, the emergency patch is the same motion done sooner.
In other words, you get fast at emergency patching by being fast at routine patching. The organisations that handle a critical edge device advisory well are rarely the ones that only patch that kind of device under pressure.
Within the baseline lane, use EPSS and exposure to order the work, and CVSS to break ties. But measure the lane by how quickly it moves, not just by what percentage of findings it closes.
What should jump the queue
The first-half 2026 data points to four categories that deserve fast-lane treatment by default.
Edge devices. Firewalls, VPN gateways and remote access appliances remain heavily targeted. VulnCheck lists new exploited vulnerabilities across most major vendors in the half, including Cisco, Palo Alto, Check Point, F5, Juniper, Fortinet, SonicWall and Ubiquiti. They’re internet-facing by design and they sit at the boundary of everything else. CISA issued a directive this year specifically on removing end-of-support edge devices, and the same logic applies here: a device that no longer receives patches can’t be in any patching lane.
Content management systems. One third of new KEVs, even allowing for the counting caveat above. For most organisations, the public website is the most exposed asset they run and often the least closely managed. The plugin ecosystem is the main problem.
Security tools and device management platforms. VulnCheck found these among the fastest-exploited categories, alongside developer tools and common desktop applications, and attributes it to how widely they’re deployed and how much access they hold. Endpoint management platforms, SIEMs and security agents run with high privilege across the whole estate. That’s what makes them useful, and it’s what makes a vulnerability in them so valuable to an attacker. The consolidation trend makes this sharper: the more of your security stack runs on one vendor’s platform, the more one vulnerability can reach. (I covered that risk in more depth in Platformisation and the Ghost of Symantec, and it’s worth weighing when you choose an EDR.)
AI products. A newer category, but one to put on the list now. VulnCheck identified 28 exploited vulnerabilities in AI products during the half, including model-building tools, AI gateways, agents and workflow automation, and saw exploitation of 10 of them against its own canaries. In attacks on LangFlow, attackers gained initial access, harvested credentials (likely API keys for AI services), deployed cryptominers and attempted lateral movement. Many of these tools are open source, quickly deployed by individual teams, and connected to sensitive data and credentials. Treat them as the high-privilege, often internet-facing systems they are, and make sure they’re in your asset inventory in the first place.
The Australian picture
The July CMS campaign
On 9 July 2026, ASD’s Australian Cyber Security Centre issued an alert about a large-scale global exploitation campaign against content management systems and plugins, with many small and medium-sized Australian businesses affected. Attackers scanned for vulnerable CMS software and plugins at scale and deployed webshells for persistent access.
Two details matter for prioritisation. First, the vulnerabilities used in the campaign were public, known vulnerabilities with patches available. Nothing in it required a zero-day. Second, ASD and its Five Eyes counterparts have linked this kind of campaign to AI shortening the time between a vulnerability being disclosed and being exploited.
That second point is worth reading carefully next to the VulnCheck data. VulnCheck found that vulnerabilities attributed to AI-assisted discovery are so far being exploited at roughly the background rate: 14 out of 1,061. Both observations can be true. The practical threat today isn’t a wave of AI-discovered zero-days. It’s attackers weaponising known, already-patchable vulnerabilities faster and at greater scale. That’s precisely the risk a faster baseline cadence addresses.
ASD’s mitigation advice beyond patching is worth adopting regardless of the platform you run:
Remove what you don’t use. Unused plugins, themes and CMS components are attack surface with no business value.
Make web directories read-only where possible, so a successful exploit can’t easily write a webshell to disk.
Watch for unexpected child processes spawned by the web server, a common sign of webshell activity.
Segment internet-facing web servers from internal systems, so a compromised website doesn’t become a route into the rest of the network.
If a third party runs your website, send them the advisory and ask what they’ve done about it. Outsourcing the website doesn’t outsource the risk.
Essential Eight timeframes
For most Australian organisations, the Essential Eight maturity model is still the reference point for patching timeframes, and it already builds in the two-lane idea.
Online services must be patched within 48 hours when the vendor rates a vulnerability critical or a working exploit exists, and within two weeks otherwise, at every maturity level.
Commonly targeted applications (office suites, web browsers and their extensions, email clients, PDF software and security products) move from one month at Maturity Level One to two weeks at Level Two, and to 48 hours at Level Three where the vulnerability is critical or exploited.
Other applications have a one-month timeframe at the higher maturity levels. At Level Three, drivers and firmware also come under the 48-hour rule when vulnerabilities are critical or exploited.
Two observations from a practitioner’s point of view. First, the Essential Eight’s fast-lane trigger includes “the vendor rates it critical”, which is a severity signal, not just an exploitation signal. For internet-facing services, that belt-and-braces approach is reasonable: exposure plus severity is a meaningful combination even without confirmed exploitation. Second, notice that security products sit in the commonly targeted category. The 2026 exploitation data supports that placement.
ASD is moving from the Essential Eight to its new Essentials series. If you’re planning around these timeframes, check them against the current guidance as the transition progresses. I covered what’s changing in The ASD Essentials Series, and the Essential Eight explainer covers the model as it stands.
For comparison, CISA’s Binding Operational Directive 26-04 now directs US federal agencies to prioritise remediation based on risk, and to patch within as little as three days where there’s evidence of exploitation, automatability, high technical impact or public exposure. Different regulator, same direction: the fast lane is getting faster.
What to change on Monday
Widen your exploitation signal. If CISA KEV is your only source of exploitation evidence, add at least one more, such as VulnCheck’s free KEV catalogue, plus ASD alerts and your vendors’ own advisories.
Tag exposure in your asset inventory. You can’t use exposure to prioritise if you can’t tell which assets are internet-facing. That includes the website, the edge devices, and the AI tools a team spun up last quarter.
Treat security and management platforms as crown jewels. EDR, SIEM, endpoint management and identity platforms should sit in the fast lane by default when exploitation evidence appears, regardless of whether they’re internet-facing.
Measure cycle time, not just compliance. Track the median number of days from patch release to deployment for routine updates, by asset category. A team that closes 95% of findings within SLA but takes 25 days on average to deploy a routine patch has a slow baseline, whatever the compliance report says.
Shorten the routine cycle. Every step you automate in routine patching is a step you don’t have to perform by hand in an emergency. The goal isn’t heroics on the critical advisory. It’s making the critical advisory an ordinary Tuesday.
Decide the fast-lane fallback in advance. For each high-risk category, agree before the incident what happens if a patch can’t be applied within 48 hours: who can authorise isolation, a vendor mitigation, or taking a service offline. That decision is far harder to make at 11pm.
This article contains no affiliate links. Data on exploitation trends is drawn from VulnCheck’s State of Exploitation 1H-2026 report (July 2026) and ASD’s Australian Cyber Security Centre alert of 9 July 2026. Essential Eight timeframes reflect the maturity model current at the time of writing.
