If you glanced at the first-half vulnerability statistics for 2026 without context, you might reach for a panic button. The Linux kernel topped the global CVE (Common Vulnerabilities and Exposures) disclosure charts for the first six months of the year, logging a staggering 2,308 reported vulnerabilities — nearly 600 more than its nearest competitor, Google’s software portfolio at 1,752. Microsoft came in fourth at 843, Oracle posted 445, and Adobe rounded out the top eight with 395 entries.
On the surface, that sounds like a disaster for one of the world’s most widely deployed software foundations. In practice, it’s a story about transparency — and why counting CVEs without context tells you almost nothing useful about actual security.
Greg Kroah-Hartman Makes His Case
The data comes from Greg Kroah-Hartman himself, the longtime Linux kernel maintainer who posted the first-half statistics to his account on social.kernel.org. He didn’t bury the numbers or spin them defensively. He shared them directly, and then offered the missing context that most headlines will skip.
“I gotta change my talk where I say ‘we are #2’ as that’s not the case by far anymore,” he wrote, noting that Linux now leads all comers by a comfortable margin. He followed that observation with a pointed remark: he hopes other vendors “get their act together” and start properly reporting all CVEs to the system, rather than selectively disclosing only the issues they internally classify as significant.
That last sentence is the key. Kroah-Hartman’s argument is not that Linux is more secure than everyone else. It’s that Linux is more honest than everyone else — and that the CVE count is a direct reflection of that honesty.
What the Numbers Actually Mean
Since the Linux kernel project became its own CVE Numbering Authority, it has adopted a policy that security professionals sometimes call “bug is a bug.” If a patch fixes something that produces unexpected or unwanted behavior — even something that might appear trivial in most deployment contexts — the kernel project assigns a CVE to it. The philosophy is that they cannot know exactly how the kernel is being used downstream, so they report everything and let administrators and distributors decide what matters in their specific environment.
Commercial vendors, by contrast, typically filter before they publish. Microsoft, Oracle, and Adobe each maintain internal triage processes that classify vulnerabilities by severity and business impact. Only the issues that cross a certain threshold get formally reported to CVE databases. That approach makes their totals look lower, but it does not mean fewer bugs are being found or fixed. It means fewer are being disclosed publicly.
The result is a statistical distortion. When you compare Linux’s 2,308 disclosures against Microsoft’s 843, you are not comparing equal datasets. You are comparing a project that reports almost everything against a company that reports a curated subset. The comparison is apples to corporate press releases.
The Scale Factor Matters Too
Even setting aside disclosure policy differences, the Linux kernel’s deployment scale is unlike any other software project on the planet. Linux runs on billions of devices across an almost incomprehensible range of environments: web servers handling trillions of requests per day, Android smartphones carried by roughly three billion people, embedded systems inside factory equipment, medical devices, automotive control units, and the cloud infrastructure that underlies most of the global internet.
A vulnerability that poses no real-world risk in a typical enterprise server environment might be critical on an industrial controller or a medical IoT device. Because the kernel project cannot predict every use case, the responsible approach is to document and report every fix — even the ones that seem minor — so that whoever is running Linux in a specialized context can make informed decisions about what needs immediate attention.
This is not unique to Linux. Open-source projects generally face this challenge more acutely than commercial software because their code is used in ways the original developers never anticipated. But Linux, at its scale, faces the challenge more sharply than almost any other project.
The Product-Level Data Is Even More Telling
Kroah-Hartman also shared a breakdown by individual product rather than by vendor, anticipating the obvious objection that Google and Microsoft each cover vast portfolios of software. In the product-level view, Linux still led with 2,309 CVEs. Google’s Chrome browser followed at 1,584, well ahead of OpenClaw at 497, Windows 10 Version 1607 at 284, Firefox at 255, Android at 153, and iOS and iPadOS at 124.
Worth noting: Windows 10 Version 1607, an operating system release from 2016 still widely used in enterprise and specialized deployments, shows up individually in the top ten with 284 CVEs. That’s a meaningful figure, and it surfaces only because product-level disaggregation separates it from the broader Microsoft umbrella.
What This Means for Security Teams
For enterprise IT teams and security operations centers, the practical takeaway is to stop using raw CVE counts as a proxy for software safety and start looking at what those counts represent. A vendor with a low CVE total is not necessarily shipping safer software. They may simply be less forthcoming about what they find.
When evaluating a platform’s security posture, the more useful questions are: How quickly does the project respond to reported vulnerabilities? How often are patches backported to stable versions? Does the project maintain a public record of every fix, or only the ones that clear an internal severity bar? Does the disclosure process give administrators enough information to assess real-world risk?
By all of those measures, the Linux kernel’s record is strong. Patches reach stable trees quickly, detailed commit messages explain exactly what each fix addresses, and the project’s embrace of comprehensive CVE reporting gives the security community a complete picture of what has been identified and remediated.
The Bigger Conversation
Kroah-Hartman’s post is, at one level, a call to action for the industry. The CVE system only works well if the data going into it is complete and consistent. When large commercial vendors cherry-pick which vulnerabilities to report, they degrade the usefulness of a database that security researchers, administrators, and automated tooling rely on to track software risk across the ecosystem.
Linux, with its open development model and its insistence on reporting essentially everything, is demonstrating what responsible disclosure looks like at scale. The number at the top of the chart might look alarming in isolation. In context, it looks like exactly what security transparency is supposed to produce.
The CVE Project maintains a public, searchable repository of all CVE records — the cvelistV5 dataset on GitHub — that anyone can query by vendor, product, numbering authority, or other fields. For those who want to dig into the methodology rather than just the headlines, the data is there.
Linux leading the charts is not a warning sign. It’s a benchmark.
