Anyone who maintains a content management system knows the weekly ritual: a plugin advisory arrives, somebody groans, and a decision gets made on instinct. VulnerabilityOps asks you to replace instinct with a small set of numbers. Below are eight data points, each with what it measures, what it tells a site team, and the mistake it helps you avoid. They come from public reports and from the reference entry cited near the end, and I have kept the interpretation cautious wherever the evidence is thin.
1. 48,244 new CVEs in 2025
Annual CVE output climbed from 18,375 records (2020) to 48,244 (2025). By the end of June 2026 the new year had already logged 35,872. For a CMS owner, the implication is that the advisory feed will not slow down to match your release cycle. A site with a core, a theme and twenty extensions sits in the path of that growth. Plan for a steady intake rather than an occasional burst.
2. Roughly one in ten fixed per month
A 2019 study covering about 300 organisations found that a typical one remediated around 10 percent of its open flaws in a month, while top performers cleared about two and a half times as many. Reading it carefully: the study does not say 10 percent is acceptable, only that it is common. The practical takeaway is that the order of work matters because the capacity is bounded.
3. Five days to exploit
Mandiant’s analysis of 2023 found that exploited flaws were attacked, on average, five days after disclosure, once outliers were removed, against 63 days in 2018 and 2019. Seventy percent of that year’s exploited flaws were zero-days. If your patch routine for internet-facing extensions is “next maintenance window, usually a month away”, this number says the window may close before you arrive.
4. 31 percent initial access, 26 percent remediation
The 2026 Verizon report names exploitation of vulnerabilities as the top initial-access vector at 31 percent. It also reports that organisations fully remediated only 26 percent of entries on the government’s known-exploited list during 2025, down from 38 percent in 2024, with a median of 43 days. Two readings are possible: either attackers are getting faster or defenders are getting slower. Either way, the known-exploited list is where to start.
5. 1,748 listed entries
As of mid-October 2026 the known-exploited catalogue held 1,748 entries, and the agency behind it aims to update within 24 hours of a decision. That is a short enough list to match against your extension inventory every morning, which is a task for a ten-line script rather than a team. The agency adds its own caveat: an old flaw sitting on the list is not automatic evidence of present-day attacks.
6. The 90th percentile, near 0.04
According to the Atlas material on the exploit prediction score, covering the same share of risk as a Critical-equivalent effort requires roughly the 90th percentile of the score, about 0.04, and a “High and above” policy implies covering roughly the top 48 percent, down to about 0.008. For a site owner, this means you can sort plugin updates by probability and focus on a short, meaningful slice. Do not multiply it by a severity score; the publisher calls that “score laundering”.
7. 57,074 deferred, 7,563 waiting
Since mid-April 2026, the national vulnerability database fully enriches only prioritised entries. On 17 October 2026 its tally showed 57,074 records marked deferred and a further 7,563 queued for enrichment. That affects tooling: if your scanner relies on enrichment fields to map a CMS plugin version to an advisory, some matches will be missing. Cross-check with the plugin vendor’s own notice, and treat “no data” as unknown rather than safe.
8. Saturation: arrivals divided by verified closures
This one you compute yourself. For each priority tier, divide the count of new findings by the count of verified fixes in the same month. The Atlas worked example gives one tier 180 arrivals against 190 closures (0.95) and another 600 against 520 (about 1.15). Anything above one means the queue grows, however busy the team looks. A backlog of 1,300 items at a rate of 600 closures per month takes about 2.2 months to drain, which already overshoots a 60-day deadline.
What the Atlas says about reading these together
None of the eight numbers is a verdict on its own. The Ops Atlas page on VulnerabilityOps bundles most of them under a single flow view: tier, owner queue, verified closure, then metrics such as saturation, coverage and recurrence. It is explicit that the term is emerging and that evidence for any single metric is uneven.
Putting the numbers in order of use
It helps to sort the eight figures by the decision each one supports, because a number that does not change a decision is trivia. The first, second and third justify why you need a triage policy at all. The fourth and fifth tell you which list to check each morning. The sixth shapes your tie-breaking rule. The seventh warns you about gaps in your tooling. Only the eighth is yours alone, and it is the one that will tell your own manager whether the programme is working.
For a small agency managing client sites, a practical split looks like this. Daily, a script compares the extension inventory against the exploited list and raises a ticket for matches. Weekly, someone reviews open items per site and confirms that each has an owner. Monthly, one person calculates saturation, credentialed coverage and recurrence, and brings three lines to a short meeting: what grew, what shrank, what is stuck. Recurrence deserves a note: if the same flaw reappears within 90 days, the earlier closure was probably wrong, or a deployment script restored an old version.
Finally, keep a separate counter for exceptions. A deadline that is quietly extended is a debt, and the Atlas lists exception debt among its flow metrics for good reason. A site with a handful of well-documented exceptions is healthy; one with dozens of undated ones has simply moved the problem.
Turning the numbers into a weekly routine for a CMS site
- Export your core, theme and extension versions each week as an inventory.
- Match that inventory with the known-exploited list every day.
- Mark which sites and admin panels are public, since exposure sets the deadline.
- Assign each finding a named person and a date.
- Close findings only after a logged-in scan or a version check on the live server.
- Record arrivals and verified closures, and compute the ratio monthly.
Step five deserves emphasis because it is where CMS teams slip. Updating a plugin in staging is not the same as updating it in production, and a cached copy of an old admin script can keep the risk alive. Verification means looking at the live site.
Caveats on the evidence
Be careful with comparisons across the reports above: they use different samples, definitions and years. The five-day figure excludes outliers, the 26 percent figure applies only to listed flaws, and the study of capacity predates the surge in volume. What they support together is a direction, not a precise forecast: intake is rising, attackers are quick, and most teams close fewer items than arrive.
If you are planning a site rebuild, it helps to build these checks in from the start. Our step-by-step piece on planning a business website before any code is written is a good moment to decide who will own updates, and the overview of which pages every company site needs doubles as a rough map of what must be inventoried and kept patched.
