CVE issue stats for the first 6 months of the year, by vendor, sorted by quantity:

   2308 "vendor": "Linux",
   1752 "vendor": "Google",
   1308 "vendor": "n/a",
    843 "vendor": "Microsoft",
    495 "vendor": "OpenClaw",
    445 "vendor": "Oracle Corporation",
    395 "vendor": "Adobe",
    340 "vendor": "Red Hat",
    310 "vendor": "Apache Software Foundation",
    284 "vendor": "Apple",

I gotta change my talk where I say “we are #2” as that’s not the case by far anymore. Hopefully the other vendors get their act together and start properly reporting all CVEs to the system, not just the ones that they feel like submitting…

And the numbers for OpenClaw is quite impressive, nice to see someone take responsibility there :)

@gregkh The gigantic codebases of #Linux #Google and #Microsoft will obviously have lots of security issues. But a project as new as #OpenClaw having the same order of magnitude of CVE's is honestly scary. They really invented CVEmaxxing over there.

@samuel "CVEmaxxing", if you don't mind, I'm going to steal that for my next talk!

And the Google/Microsoft codebases are for _different_ products from those vendors, not just a single codebase, so you can't really compare them that way at all. Look at the product if you wish to compare for products. For products, our numbers are way way higher because most commercial vendors do not report all CVEs, only the "high" ones.

@gregkh be my guest, I don't think I invented that word but having it in a talk would be fun!

I guess #CVEmaxxing is a thing now.

For “products” (which makes the vendor issue where a CNA issues for multiple software products go away), the numbers are a bit different:

   2309 "product": "Linux",
   1584 "product": "Chrome",
    888 "product": "n/a",
    497 "product": "OpenClaw",
    284 "product": "Windows 10 Version 1607",
    255 "product": "Firefox",
    153 "product": "Android",
    141 "product": "AVideo",
    136 "product": "Red Hat Enterprise Linux 10",
    124 "product": "iOS and iPadOS",

Again, remember, vendors like Apple, Microsoft, and others only report the ones they determine to be “high” to CVE, while open source, as we can not dictate use of our code, have to report everything as we don’t know how it is used by others (i.e. severity is hard, if not impossible, to properly judge.)

Again, gotta give props to OpenClaw for properly documenting all of their issues, I wish more vendors would learn from them…

@gregkh No Wordpress? Colour me surprised.

@christopherkunz Yeah, looks like wordpress has given up in reporting anything in 2026, probably due to their "issues" at the moment...

@christopherkunz Nope, I was wrong, wordpress is properly splitting the cves out to call out the vendor of the plugin affected, and not use them as the vendor. Which I guess is the proper thing to do overall.

All of this is in easily searchable json for anyone to look at if you want to do your own queries, just download it from https://github.com/CVEProject/cvelistV5.git

@gregkh I'm running an instance of OpenCVE(.io) locally, which is kind of nice for a quick GUI based overview. It supports basic search syntax, product grouping and all of the fancy vulnrichment acronyms (EPSS, SSVC, CPE). It has a shortfall with this specific use case though: I can't tell OpenCVE to _only_ show me Wordpress core vulns that don't have a second product/vendor attached. Trying to find out if this is a bug or a feature.

@christopherkunz just filter on the issuing CNA. For wordpress I think it is 'wordfence' as they issue most/many of the wordpress plugin CVEs, or look at the urls in the records, as they show 'wordpress' somewhere as part of the path/domain.

@gregkh @christopherkunz

Patch stack and that other company I forget the name of look kinda overwhelmed at the moment. But there’s a few sites that track leaderboards for bug bounty on Wordpress plugins. Some people are animals pushing out a metric shit tonne of vulns with assigned cves every month on patch stack VDP.

@samuel @gregkh if we go by that measure, OpenClaw has 382k lines of code, 10x less than the Linux kernel, but only 5x fewer CVEs.