New CVEs published in 2026 (as of last week): 67,000+ (Source: CISA white paper, cited by CyberScoop (September 28, 2026))
A 'Growth Era' running into its limits
CISA published a white paper on Wednesday laying out how it intends to fix long-standing data quality problems in the Common Vulnerabilities and Exposures (CVE) program, the federal government's central catalog for tracking software flaws across the industry. The paper arrives a year after the program's operating contract nearly lapsed before a last-minute renewal, and as the number of new vulnerability records keeps climbing. Chris Butera, CISA's acting executive assistant director for cybersecurity, described the shift as moving the 25-year-old program from what CISA calls a 'Growth Era' into a 'Quality Era,' according to CyberScoop's reporting on the document.
Why the data behind vulnerability counts matters to budget holders
Most executives never touch a CVE record directly, but the program feeds the vulnerability scanners, software bill-of-materials tools, and vendor risk questionnaires that inform patch schedules, procurement decisions, and cyber insurance underwriting. When CVE records are incomplete or inconsistent, security teams absorb the gap manually. Brian Fox, Sonatype's co-founder and chief technology officer, told CyberScoop that inconsistent records push extra manual work onto the tools, developers, and organizations trying to figure out whether they are exposed and what to do about it. He added that CISA's 'Quality Era' framing earns its name only once it shows measurable improvement in the records themselves and in the decisions organizations make using them.
Tom Alrich, who leads the OWASP PURL Expansion Working Group, said the white paper leaves out what he considers the program's most consequential structural gap: a growing share of new CVE records lack a standardized, machine-readable product identifier — the kind of tag that lets automated systems tie a vulnerability to a specific product and version running inside an environment. Without that identifier, matching a CVE to an organization's actual asset inventory still tends to fall back on manual, name-based lookups — the kind of manual burden the white paper's stated quality goals are meant to reduce.
Volume is not spread evenly across ecosystems
The scale CISA is managing is real: NIST's database recorded a 263% jump in CVE submissions between 2020 and 2025, and CISA counts more than 67,000 new CVE records published in 2026 alone. But that growth doesn't land uniformly. In WebPulse's CVE profiles, drawn from NIST NVD data and refreshed September 26, 2026, Joomla carries 50 new CVE records in the trailing 12 months, while Eleventy and Remix — both in active use — carry none in the same period. That gap doesn't mean one platform is safer than the other; it reflects differences in codebase size, maintainer disclosure practices, and how actively each project's vulnerabilities get reported at all. That gap illustrates why raw CVE counts alone are a poor risk signal on their own — a related concern to the record-quality issues CISA's white paper focuses on, though the paper itself targets the CVE program's internal governance and data infrastructure, not how outside readers interpret volume differences across projects.
What to ask your team
Budget holders don't need to referee CISA's governance debate, but the underlying question applies directly to any vulnerability management program: ask whether your tooling matches CVEs to your software inventory using machine-readable identifiers, such as PURL or CPE, rather than manual name matching. Ask how many CVE records affecting your stack currently lack severity scoring or vendor confirmation, and how those unscored records get triaged in the meantime. And ask whether patch prioritization in your organization distinguishes between raw CVE counts and CISA's Known Exploited Vulnerabilities listing status, since the two measures frequently diverge and only one reflects active exploitation.
Produced by the WebPulse Newsroom with AI assistance from the original reporting credited below, and checked against that source by our editorial review. How we use AI.
Original reporting: CyberScoop.
