At A Glance
- New series tracking current network-exploitable CVEs and actively exploited KEVs
- 738 new network-exploitable CVEs published between July 31–August 13, 2026
- 162 cleared our severity bar (CVSS 8.6+), 101 rated 9.0 or higher
- Featured KEV: CVE-2026-72898, an unauthenticated SQL injection in Metabase
- The common thread: reachable services turn known flaws into breaches
Every day, countless new vulnerabilities get published, and a smaller set of already-known vulnerabilities gets actively exploited. Security teams call the first group CVEs (Common Vulnerabilities and Exposures). The ones criminals are using right now are KEVs: Known Exploited Vulnerabilities. Both categories matter, but for different reasons. CVEs tell you what could go wrong; KEVs tell you what already is wrong.
This is the first post in a new series where we’ll track both. Every edition will share the volume of new network-exploitable CVEs disclosed, call out the handful that matter most, recap the headlines where a known vulnerability was actually exploited and caused real damage, and keep a running tally so the trend line becomes visible over time.
Almost every one of these stories shares the same root cause: a service was reachable on a network an attacker could touch, and a flaw in that service turned “reachable” into “compromised.” That’s the defining weakness of perimeter-based networking, and it’s exactly what this edition’s numbers show.
Vulnerabilities by the Numbers
For the two weeks of July 31–August 13, 2026, 738 new network-exploitable CVEs were published. 162 of them cleared our severity bar for this list (CVSS 8.6 and above), including 101 rated 9.0 or higher. Running tally for the series: 162 critical/high-severity network CVEs tracked in Edition 1.
A few worth knowing about:
- CVE-2026-63508 (10.0, CRITICAL): a missing-authentication flaw in Microsoft Planetary Computer Pro that lets an unauthenticated attacker elevate privileges over the network. A perfect 10 with zero authentication required is about as bad as it gets.
- CVE-2026-50515 (9.9, CRITICAL): insecure deserialization in Azure Service Bus allowing remote code execution by an already-authorized attacker.
- CVE-2026-70332 (9.6, CRITICAL): a new SSRF flaw in Microsoft Office SharePoint, landing in the middle of an active exploitation wave. SharePoint has now had four separate vulnerabilities exploited in the past month, with attackers stealing machine keys to maintain persistent access even after patching.
- CVE-2026-53984 (9.1, CRITICAL): an unauthenticated database-wipe vulnerability in Ground Station, reachable by any network peer with no credentials at all.
Every one of these shares the same prerequisite: an attacker had to reach the vulnerable service in the first place. Take that away, and the CVSS score stops mattering as much.
No Password Required: This Edition’s Worst KEV
On August 11, 2026, CISA added CVE-2026-72898 to its Known Exploited Vulnerabilities catalog: a critical, unauthenticated SQL injection in Metabase’s password-reset endpoint, rated a perfect CVSS 10.0. Metabase confirmed active exploitation, including a breach that exposed Slack access tokens at one affected company. An attacker who can simply reach the vulnerable endpoint needs no password at all. They inject SQL directly into the application database, seize administrative control, and from there pull the credentials Metabase holds for every connected data warehouse.
Notice what’s underneath that attack chain. Metabase is an internal analytics tool by design. It was never supposed to be reachable from the open internet at all, and once it was, one flaw was all it took to hand over the keys to every database it touched.
How Identity-First Reachability Closes This Gap
Identity-First Reachability™ breaks that chain at the source. Nothing is reachable, by anyone or anything, without a verified identity and an explicit policy allowing that specific connection. If NetFoundry’s Identity-First Reachability model had been in front of the exposed Metabase instance, this wouldn’t have been a headline. The vulnerable endpoint would never have been network-visible to an attacker in the first place, patched or not. That’s the shift NetFoundry is built around: stop asking “was it patched in time” and start asking “was it ever reachable to begin with.”
Don’t Be the Next Reachability Watch Headline
If there’s one takeaway from this edition, it’s that patching alone isn’t a strategy. Attackers only need one exploitable path in, and 738 new CVEs in two weeks is more than any team can patch its way out of in real time. If NetFoundry’s Identity-First Reachability model had been in front of the exposed Metabase instance, this wouldn’t have been a headline. The vulnerable endpoint would never have been network-visible to an attacker in the first place, patched or not. That’s the shift NetFoundry is built around: stop asking “was it patched in time” and start asking “was it ever reachable to begin with.” No open ports for a scanner to find, no lateral path once one server’s compromised, no race against the next CVSS 10.0.
See how Identity-First Reachability makes your services invisible to attackers before a CVE ever becomes a KEV.
Frequently Asked Questions
What’s the difference between a CVE and a KEV?
A CVE (Common Vulnerabilities and Exposures) is any publicly disclosed security flaw, whether or not it’s ever been used in an attack. A KEV (Known Exploited Vulnerability) is one CISA has confirmed is being actively exploited in the real world. Every KEV started as a CVE, but only a small fraction of CVEs ever become KEVs.
Why do so many of these vulnerabilities involve remote management or perimeter-facing services?
Because those services are, by design, reachable from the network. That’s what makes them useful, and it’s also what makes them attractive targets. Attackers don’t need to break encryption or guess passwords if a flaw lets them skip authentication entirely on a service they can already reach.
How does identity-first reachability prevent this class of attack?
Identity-first reachability is a security model where every connection requires a verified identity and explicit policy before a service becomes visible on the network at all, rather than relying on implicit trust once someone’s inside the perimeter. At NetFoundry, we call this Identity-First Reachability™: it means a vulnerable service is never visible to an attacker who hasn’t already been authorized to reach it, regardless of whether a patch exists yet.
