Critical vulnerabilities: What 117 environments reveal

In an October 2026 analysis of 117 PDQ customer environments, we found a median of 264 open critical CVEs per environment, including a median of 34 critical CVEs flagged as weaponized (meaning an exploit code is available). 

But the differences between environments were significant. While the bottom 10% had 42 or fewer open critical vulnerabilities, the top 10% had 845 or more. (Severity based on CVSS.) 

The findings highlight a challenge for IT teams: Vulnerability backlogs can vary dramatically, and knowing how many critical vulnerabilities exist is only part of the equation. 

A critical vulnerability count isn't a patching plan. Understanding exploit activity, affected devices, and business risk is what helps IT teams decide where to focus remediation efforts. 

How many open critical vulnerabilities did we find? 

The median was 264 open critical CVEs per environment, with the middle half of sampled environments falling between 107 and 426. The distribution varied considerably: the bottom 10% had 42 or fewer, while the top 10% had 845 or more. 

Here’s the full snapshot. Both columns report counts per environment. 

Source: PDQ customer-environment data summary, October 14, 2026. Each column summarizes its own distribution. The two medians do not necessarily describe the same environment. 

We’re leading with the median because unusually high counts have less influence on it than on the mean. That distinction is especially noticeable in the weaponized category, where the mean of 114 is substantially higher than the median of 34. 

The difference between environments is striking. At the lower end of the distribution, 10% had 42 or fewer open critical CVEs. At the upper end, 10% had at least 845. That's a substantial variation in vulnerability backlogs, underscoring why raw vulnerability counts aren't enough to evaluate an organization's security posture or remediation performance. 

These numbers also are not a leaderboard. An environment below the median is not automatically secure, and an environment above it is not automatically poorly managed. The counts alone do not account for differences in device fleets, software inventories, asset exposure, or remediation history. 

How many critical CVEs were flagged as weaponized? 

The median was 34 open critical CVEs flagged as weaponized per environment, with the middle half ranging from 11 to 126. Here, “weaponized” refers to the classification in the source data, not a finding that any sampled customer environment had been compromised. 

When using an exploit-related classification to prioritize work, check the evidence behind the label. Public proof-of-concept availability and observed exploitation are different findings. CERT/CC’s Stakeholder-Specific Vulnerability Categorization framework treats public proof of concept and evidence of attacker activity as separate exploitation states.

Public exploit code does not, by itself, establish that attackers are using it against organizations. Likewise, evidence that a vulnerability has been exploited somewhere does not establish that it has been exploited in your environment.

But the absence of known exploitation evidence is not a guarantee of safety, either. Exploitation status describes current knowledge, not a prediction that a vulnerability will remain unexploited.

An exploit-related flag is another prioritization input, not permission to ignore everything without one. 

How should sysadmins prioritize critical vulnerabilities? 

Prioritize vulnerabilities by combining severity with exploit evidence, asset exposure, business impact, and available mitigations. A critical rating establishes part of the picture; the affected systems and the conditions required for exploitation help determine what needs attention first.

For a backlog like the ones in this sample, that means moving from a count to a decision: 

1. Check the exploitation evidence. Cross-reference findings with CISA’s Known Exploited Vulnerabilities catalog and relevant vendor advisories. Keep public exploit availability separate from evidence of real-world exploitation. CISA recommends using its catalog as an input to vulnerability prioritization.

2. Identify the affected systems and their importance. Determine which assets are exposed, what access an attacker would need, and what successful exploitation could affect. Consider business-critical services and existing protections rather than ranking findings solely by severity or device count.

3. Select and deploy the remediation. Connect each priority finding to the applicable vendor fix or mitigation and the devices that need it. Test the proposed change, then deploy it to the affected systems.

4. Verify the result. Confirm that the required update or change reached the affected systems, then check for remaining findings and deployment failures. Verification is part of patch management, not an optional reporting step; NIST includes verifying installation in its definition of the process.

This workflow should not stop at the critical filter. Our analysis covers critical CVEs, but that scope is not a recommendation to ignore other severity levels. CISA’s guidance explicitly advises tracking and prioritizing vulnerabilities beyond those in its known-exploited catalog.

For this sample, the median of 264 open critical CVEs captures the scale of the backlog. The median of 34 flagged as weaponized adds another dimension. The useful next step is not to pick one number and disregard the other. It is to connect the findings to the systems, evidence, and remediation decisions behind them. 

The count tells you how much needs attention. Context helps determine what gets attention first. 

How PDQ helps teams remediate vulnerabilities 

Finding a vulnerability is only useful if your team can do something about it. PDQ automatically scans managed devices for known vulnerabilities, shows which devices are affected, and helps teams prioritize what needs attention. From the same console, IT teams can review remediation steps and deploy updates to affected devices, with suggested patches available for select vulnerabilities. That means less time sorting through findings and more time fixing the issues that put your environment at risk. 

Mitigate vulnerabilities with PDQ in a few steps: 

1. Scan your devices. PDQ automatically scans managed devices for known vulnerabilities. You can also manually start a scan from the Vulnerabilities page. 

2. Prioritize the risks. Review detected vulnerabilities and affected devices to decide which issues need attention first. Review the PDQ Risk score to determine impact in your environment. 

3. Review the recommended fix. Open a vulnerability to see remediation details, such as the software or operating system version needed. Most vulnerabilities will include a premade package developed by our packaging team.

4. Deploy to affected devices. From the vulnerability page, the software page, or the device information page, select a remediation package or use the suggested update when available, then deploy it to the devices that need it. 

5. Verify the results. After the deployment, a vulnerability scan is automatically triggered. Review the results to verify the deployment. 

How was this critical vulnerability snapshot compiled? 

The snapshot covers a random sample of 117 PDQ customer environments with vulnerability data as of October 14, 2026. It summarizes the per-environment counts of open critical CVEs and the subset flagged as weaponized, retaining the classifications used in the source data. 

These are counts, not rates adjusted for the number of devices in each environment. They describe the sampled customer environments, not a universal benchmark for all organizations. 

This point-in-time snapshot does not show whether backlogs are growing, how long vulnerabilities have remained open, or how quickly teams remediate them. It also does not establish that any sampled environment was compromised.