We are halfway through 2026, and the vulnerability data is not pointing to one dramatic new category.
It is pointing to something more familiar.
Everyday software, operating systems, browsers, web applications, open source components, remote access tools, and network-edge systems continue to produce the risk that matters.
That may sound boring. It is also the point.
Most businesses do not get hurt because they missed a futuristic attack nobody could understand. They get hurt because ordinary software had an ordinary flaw, the system was exposed, the patch was delayed, or nobody had a clear owner for the risk.
This is a midpoint snapshot based on vulnerability data reviewed on July 1, 2026. CVE records change over time as vendors, researchers, and vulnerability databases enrich or correct them, so the exact counts may shift. The pattern is what matters.
What a CVE Means in Plain English
A CVE is a public tracking number for a known software vulnerability.
It is not the same as proof that attackers are using the issue. It is not a patch by itself. It is not always a perfect measure of risk.
A CVE is a starting point. It helps vendors, security teams, MSPs, auditors, and business leaders talk about the same weakness without guessing which issue they mean.
A practical vulnerability program needs more than CVE counts. It needs to know:
- Is the affected software in our environment?
- Is it exposed to the internet?
- Is it used on critical systems?
- Is there public exploit activity or exploit code?
- Is it in CISA KEV?
- Is the patch available?
- Was the patch actually installed and verified?
That last question matters. Patch deployment and patch verification are not the same thing.
The Big 2026 Midpoint Numbers
As of July 1, the dataset showed:
| Metric | Count |
|---|---|
| CVEs published so far in 2026 | 37,211 |
| Critical CVEs | 4,807 |
| High CVEs | 15,425 |
| Medium CVEs | 14,035 |
| Low CVEs | 943 |
| Unknown severity | 1,982 |
| CVEs scored 9.0 or higher | 5,333 |
| CVEs scored 7.0 or higher | 20,232 |
| CVEs with exploit-reference signals | 16,525 |
| Published-in-2026 CVEs in CISA KEV | 85 |
| Total CISA KEV additions made in 2026 | 146 |
The first lesson is simple: volume is not slowing down.
The second lesson is more useful: raw volume is not a priority list.
If your business sees 37,211 CVEs and tries to treat them all the same, the program will fail. The point is not to chase every advisory with equal urgency. The point is to find the subset that intersects with your real environment, real exposure, and real business impact.
The Monthly Pattern
June was the highest full month so far.
| Month | CVEs Published |
|---|---|
| January | 5,143 |
| February | 4,798 |
| March | 6,229 |
| April | 5,913 |
| May | 7,036 |
| June | 7,508 |
| July 1 partial | 584 |
The July number is only a one-day partial count, so it should not be compared to a full month.
One other note: the modified-record count spiked hard in June in the local data. I would not use that as a public headline. That kind of spike can reflect enrichment, rescoring, or backfill activity rather than a clean signal that defenders should interpret as “June was uniquely dangerous.”
Published CVEs are a cleaner public signal for this kind of midpoint read.
The Boring Stuff Is Still the Risk
The strongest theme is that 2026 is still very much a web application and common software year.
Top weakness trends included:
| Weakness | Count |
|---|---|
| Cross-site scripting | 3,854 |
| SQL injection | 2,156 |
| Missing authorization | 1,879 |
| Path traversal | 1,309 |
| Use-after-free | 1,225 |
| Improper access control | 1,044 |
| Out-of-bounds write | 1,027 |
| OS command injection | 1,007 |
| Code injection | 952 |
| Server-side request forgery | 851 |
Grouped another way, the pattern is just as clear:
| Weakness Group | Count |
|---|---|
| Auth and access control | 4,984 |
| Memory safety | 4,945 |
| Browser and web input issues | 4,464 |
| Code execution class bugs | 2,375 |
| SQL injection | 2,157 |
| Path traversal | 1,386 |
| Server-side request forgery | 851 |
| Deserialization | 583 |
These are not exotic problems.
XSS, SQL injection, authorization flaws, path traversal, command injection, SSRF, use-after-free, and out-of-bounds writes are old classes. They keep showing up because modern systems are large, layered, fast-moving, and full of reused components.
For SMBs, the important lesson is not “learn every CWE.” The lesson is simpler:
If your business runs web apps, customer portals, vendor-hosted platforms, plugins, browser-based tools, APIs, or open source components, vulnerability management is not optional background noise. It is part of running the business.
Platform Risk Is Broad
The top vendor and product clusters also tell a useful story.
Vendor clusters included:
- Linux: 2,940 CVEs
- Microsoft: 2,075
- Google: 1,491
- Apple: 1,434
- Oracle, Adobe, Apache, IBM, and Mozilla also showed strongly
Product clusters included:
- Linux kernel
- Windows
- macOS
- Chrome
- Android
- Firefox
- iPhone and iPadOS
- Thunderbird
- GitLab
- ImageMagick
- Mattermost
This matters because many businesses still think of patching as a server task.
Servers matter, but they are not the whole picture.
Browsers matter. Phones matter. Email clients matter. Developer tools matter. SaaS and self-hosted collaboration platforms matter. Image processing libraries matter. Open source projects matter. Network-edge systems matter.
A patching program that only watches servers will miss a large part of the real attack surface.
Exploitability Is Not Rare
The dataset showed 16,525 published 2026 CVEs with exploit-reference signals.
That does not mean all 16,525 are being actively exploited in the wild. It does not mean every one of them should become an emergency.
It does mean defenders should stop treating CVEs as theoretical paperwork.
Public exploit references, proof-of-concept code, exploit discussions, scanner checks, and offensive tooling can turn a vulnerability from a line item into something much more urgent. Attackers do not need every vulnerability to be exploitable. They need one that works in your environment.
This is why vulnerability management should not stop at severity.
A CVSS 9.8 on software you do not run is not your immediate problem. A lower-scored vulnerability on an internet-facing system with exploit code and weak monitoring might be much more urgent.
KEV Is the Priority Filter, Not the Whole Universe
CISA’s Known Exploited Vulnerabilities catalog is one of the best places to start.
So far in 2026, 85 published-in-2026 CVEs were in KEV. There were also 146 total KEV additions during 2026, including older CVEs added this year.
That distinction matters.
Attackers do not care what year the CVE was published. If an older vulnerability still works, it is useful to them.
For defenders, KEV should be treated as a “drop everything and check this” list. It is not the only list that matters.
EPSS, the Exploit Prediction Scoring System, helps estimate how likely a vulnerability is to be exploited. It is not perfect, but it is useful when combined with exposure, asset importance, and whether exploit references exist.
A practical priority model should include:
- CISA KEV
- EPSS likelihood
- Whether exploit references exist
- Internet exposure
- Asset criticality
- Business impact
- Whether compensating controls exist
- Whether the patch has been verified
This gives a business a way to focus without pretending the vulnerability universe is small.
What SMBs Should Patch First
Most small and mid-sized businesses do not need a massive vulnerability management platform on day one. They need a clear order of operations.
Start here:
- Patch anything in CISA KEV that exists in your environment.
- Prioritize internet-facing systems, especially VPNs, firewalls, remote access tools, web servers, identity systems, and email systems.
- Patch browsers, operating systems, and productivity software quickly.
- Review high EPSS vulnerabilities and anything with public exploit references.
- Fix exposed web application issues such as authentication bypass, SQL injection, XSS, SSRF, command injection, and path traversal.
- Make sure unsupported software is removed or isolated.
- Verify that patches actually installed.
- Keep an inventory so you know what applies to you.
The inventory part is not glamorous, but it is where many programs break.
If nobody knows which systems exist, which software is installed, who owns it, and whether it is exposed, then patching becomes guesswork.
The SMB Takeaway
The 2026 vulnerability landscape is not saying “panic.”
It is saying something more practical:
- Know what you run.
- Watch KEV first.
- Use EPSS and exploit references to sort the rest.
- Patch exposed systems quickly.
- Do not ignore browsers, endpoints, phones, developer tools, and open source components.
- Treat web application security as a normal business issue.
- Verify that fixes actually happened.
The boring stuff is still the risk.
That is not bad news. It means many of the right moves are understandable: inventory, prioritize, patch, verify, and repeat.
The businesses that do this consistently are in a much better position than the businesses waiting for a perfect tool, a perfect dashboard, or a perfect time to start.