VulnCheck's Series B Backs Exploit Evidence, Not Another CVE Score

VulnCheck announced a $25 million Series B led by Sorenson Capital on 17 February 2026, bringing total funding to $45 million. The company also reported 557% enterprise ARR growth, 306% growth in government business, and more than 13,000 users. Those commercial figures are company-provided.

The product thesis is easier to test. Security teams already have more CVEs and severity scores than they can act on. VulnCheck tries to identify the smaller set with evidence of real exploitation and deliver that context through data feeds and APIs.

VulnCheck's January State of Exploitation report counted 884 known-exploited vulnerabilities in 2025 and said 28.96% were first exploited on or before their CVE disclosure date. It also identified 118 distinct sources that were first to report at least one exploited vulnerability. These are VulnCheck's own research results, but they support a precise customer problem: evidence appears across many sources and often arrives before ordinary patch workflows are ready.

A week after the round, the company's Exploit Intelligence Report made the filtering argument even sharper. VulnCheck said only about 1% of 2025 CVEs were observed exploited in the wild. If the methodology holds for a customer's environment, the value is not another risk number. It is reducing the set that deserves immediate investigation.

VulnCheck's July update for the first half of 2026 moved in two directions. It counted 495 known-exploited vulnerabilities in six months. The share exploited on or before CVE publication fell to 23.43%, from about 29% for 2025, while the median time from publication to known exploitation shortened from 120 days to 80. Fewer flaws were exploited at disclosure, but the window between publication and exploitation shrank. The second finding is the one that matters for patch queues.

An exploit-intelligence provider does not need to own exposure management, SIEM, ticketing, or remediation. Its data can influence each system through an API. That makes update latency, source provenance, identifiers, history, and licensing terms part of the product's competitive quality.

The changelog deserves as much attention as the research blog. Schema changes, new endpoints, bulk data, and integration behavior show whether research can be operationalized without analysts manually translating every finding.

A rival can differentiate through faster discovery, stronger provenance, asset context, remediation workflow, or broader integration. Database size alone is a weak answer because buyers care whether the intelligence changes what gets patched first.

Teams evaluating the claims should replay dated incidents: when did each provider surface exploitation, what evidence did it show, how many false positives followed, and could the signal reach the tools that owned remediation?

VulnCheck's public evidence supports a focused thesis: exploitation is rare relative to disclosure volume, early activity is common enough to matter, and the source trail is fragmented.

The next proof is whether customers consistently make better, faster remediation decisions with the feed. That outcome matters more than adding another vulnerability count to the market.