The Ratio That Matters
WordPress has accumulated 18,005 CVEs in the National Vulnerability Database. Four are rated critical. Twenty-three are rated high-severity. The number continues to grow. What does not continue to grow is the rate of official releases. In the last twelve months, WordPress shipped zero major releases. The project's GitHub repository shows 21,204 stars and approximately 1,679 commits per year — a respectable level of activity for maintenance, but not for a platform that serves as the foundation for a significant portion of detected websites.
The arithmetic is straightforward. When vulnerability discovery outpaces feature development, a project has transitioned from building to defending. WordPress is not evolving. It is being excavated.
What the Comparison Reveals
Hugo, the static site generator, has zero CVEs. Not zero critical CVEs — zero CVEs of any kind, ever. FastAPI has 39 total CVEs across its entire history. Next.js has 92 CVEs but also logged 5,870 commits in the past year, reflecting a project that ships features alongside security fixes. The ratio of vulnerabilities to development velocity tells you whether a project is growing or eroding.
WordPress's 18,005 CVEs do not mean 18,005 active exploits. Many are in plugins and themes, not WordPress core. Many have been patched. But the aggregate number represents something that matters to organizations evaluating total cost of ownership: the surface area of historical risk. Every CVE is a disclosure, a patch cycle, a decision point for system administrators. At 18,005, those decision points have become a permanent operational burden.
The Operational Cost
For organizations running WordPress, the cost is not the CVEs themselves. It is the process around them. Each vulnerability requires assessment: does it affect our configuration? Is the patch compatible with our plugins? Can we deploy during business hours? For a platform with 18,005 historical CVEs, this process is not occasional — it is continuous. Security teams monitoring WordPress installations are not protecting a website. They are operating a vulnerability management program.
The question for budget owners is not whether WordPress can be secured. With sufficient investment in WAFs, plugin auditing, patch management, and security monitoring, any platform can be hardened. The question is whether that investment makes sense when alternatives exist that require a fraction of the security overhead. Hugo's zero CVEs are not a marketing claim. They are a line item that does not appear in the security budget.
WordPress remains functional. Millions of sites run on it without incident. But functionality and security cost are different metrics. A platform that accumulates vulnerabilities faster than it ships features has shifted the cost of ownership from development to defense. That shift is visible in the data, and it compounds annually.
