Drupal Vulnerability Statistics: 2026 Data and Security Trends

Drupal vulnerability statistics in 2026 tell a more nuanced story than a single CVE count can show. Drupal’s official records separate vulnerabilities in Drupal core from security advisories affecting community-contributed modules and projects, while third-party CVE databases apply different inclusion rules. In 2026, Drupal published 12 core security advisories, most rated Moderately Critical, while contributed-project advisories continued to account for most of the ecosystem’s disclosed security issues. This report separates those datasets and tracks severity, vulnerability type, exploitation, Drupalgeddon incidents, market exposure, and supported versions.

Drupal Vulnerability Statistics: Key Findings for 2026

The most useful Drupal security numbers are not one all-time CVE total. They distinguish Drupal core, contributed projects, known exploitation, current severity, and the population of websites potentially exposed.

What Counts as a Drupal Vulnerability?

The phrase “Drupal vulnerability” can refer to several different populations of security issues. Understanding those populations is necessary before comparing statistics.

This distinction matters because Drupal is itself a CVE Numbering Authority, or CNA. Its current policy says CVEs are generally assigned to Drupal core and contributed projects that qualify for a security advisory and have more than 10,000 reported installs, although CVEs can also be issued in other cases.

That means:

Drupal security advisory
        ≠
Drupal CVE
        ≠
Drupal core vulnerability
        ≠
Contributed-module vulnerability
        ≠
Third-party database record

Why Do Drupal Vulnerability Counts Differ Between Databases?

This is the most important methodological issue in Drupal vulnerability statistics.

Different security databases currently give very different 2026 numbers because they define “Drupal” differently. Some count only CVEs mapped directly to Drupal core. Others include contributed modules, older Drupal 7 projects, dependency records, or multiple product names associated with the Drupal vendor.

None of those figures should automatically be described as “the number of Drupal vulnerabilities.” The correct wording has to include the dataset.

For example:

“Drupal published 12 core security advisories in 2026” is a precise statement.

But:

“Drupal has 12 vulnerabilities in 2026” is ambiguous because it excludes the contributed-project ecosystem and may not match CVE databases.

How Many Drupal Security Advisories Are Published Each Year?

Drupal’s official Security Team maintains one of the strongest datasets for historical comparison because it uses the same broad distinction between core and contributed projects across many years.

The long-term pattern is clear: contributed-project advisories greatly outnumber Drupal core advisories.

Drupal’s published annual series runs back to 2005. Summing that official table through its current 2026 year-to-date row gives 1,927 security advisories: 171 for core and 1,756 for contributed projects. On that specific dataset, contributed projects account for about 91.1% of all listed advisories.

Drupal Core vs Contributed-Module Vulnerabilities

Contributed projects consistently create a much larger disclosure population than Drupal core.

This does not prove Drupal core is “safe” or contributed modules are inherently insecure. Drupal core and the contributed ecosystem are very different software populations. There are many more contributed projects, they are maintained by different teams, and their installation bases vary widely.

The operational lesson is simpler: a fully patched Drupal core does not tell you whether every installed module is secure or supported.

Drupal Core Vulnerabilities by Severity in 2026

Drupal does not use CVSS as its primary advisory severity system. The Drupal Security Team scores advisories from 0 to 25 using a system based on NIST’s Common Misuse Scoring System.

The current bands are:

• 0–4: Not Critical
• 5–9: Less Critical
• 10–14: Moderately Critical
• 15–19: Critical
• 20–25: Highly Critical

Among the 12 Drupal core advisories published in 2026:

So the most common Drupal core severity in 2026 is Moderately Critical, not Critical or Highly Critical.

That also demonstrates why a handful of famous incidents can distort Drupal’s reputation. The exceptional vulnerabilities receive the headlines, while most ordinary core advisories sit in the middle of Drupal’s risk scale.

Drupal Core Vulnerabilities by Type in 2026

The official 2026 core advisory titles also provide a clean current-year view of vulnerability classes.

XSS is therefore the most frequent vulnerability label in Drupal core’s 2026 advisory set, appearing in four of the 12 advisories.

That should not be interpreted as evidence that XSS is automatically the biggest Drupal risk. Frequency and impact are different measurements. The only Highly Critical core advisory of 2026 is an SQL injection vulnerability, CVE-2026-9082.

Which Drupal Vulnerabilities Are Known to Be Exploited?

Severity tells you how damaging a vulnerability could be. CISA’s Known Exploited Vulnerabilities catalog answers a different question: whether there is evidence attackers have actually exploited the vulnerability in the wild.

Major Drupal core CVEs represented in CISA KEV include:

This is a small subset of the vulnerabilities disclosed over Drupal’s history, which illustrates why raw vulnerability counts and real-world exploitation should be analyzed separately.

How Fast Are Major Drupal Vulnerabilities Exploited?

There is no defensible universal statistic saying that every Drupal vulnerability is exploited within a fixed number of hours. Real incidents have produced very different timelines.

The better measurement is the observed disclosure-to-exploitation timeline for individual high-impact vulnerabilities.

The Biggest Drupal Vulnerabilities in History

Drupal’s security reputation is heavily influenced by a small number of unusually severe vulnerabilities. The best-known incidents are commonly grouped under the “Drupalgeddon” name.

Drupalgeddon — CVE-2014-3704

The original Drupalgeddon was an unauthenticated SQL injection vulnerability affecting Drupal 7. Its significance is less about a modern CVSS score and more about the exploitation timeline. Drupal’s own post-incident guidance said systematic attacks started so quickly that websites not patched within seven hours of the announcement should be considered likely compromised.

That remains one of the clearest historical examples of why internet-facing CMS vulnerabilities can create extremely short patch windows.

Drupalgeddon2 — CVE-2018-7600

CVE-2018-7600 was an unauthenticated remote code execution vulnerability disclosed in March 2018. It affected Drupal 6, Drupal 7, and Drupal 8 and became one of Drupal’s most widely exploited vulnerabilities.

Drupal later warned that automated attacks were underway and increased its risk score to 24/25. CISA now lists CVE-2018-7600 in the Known Exploited Vulnerabilities catalog and marks it as associated with ransomware campaigns.

Drupalgeddon3 — CVE-2018-7602

CVE-2018-7602 followed only weeks after Drupalgeddon2. It was another remote code execution vulnerability involving multiple Drupal subsystems. CISA also lists this flaw as known exploited and associated with ransomware campaigns.

CVE-2026-9082: Drupal’s Major 2026 Vulnerability

CVE-2026-9082 is the standout Drupal core vulnerability of 2026.

Disclosed on May 20 as SA-CORE-2026-004, it affects Drupal’s database abstraction layer on websites using PostgreSQL. An anonymous attacker can send specially crafted requests that result in SQL injection, potentially leading to information disclosure, privilege escalation, remote code execution, or other attacks.

The vulnerability was initially announced at 20/25 — Highly Critical while the exploit status was theoretical.

That changed rapidly.

May 20, 2026
Drupal publishes SA-CORE-2026-004
Risk score: 20/25
Exploit status: Theoretical

        ↓

May 22, 2026
Exploit attempts detected in the wild

        ↓

Drupal updates risk score
23/25 — Highly Critical
E:Exploit

        ↓

CVE-2026-9082 added to CISA KEV

The current official Drupal risk score is therefore 23/25, not the original 20/25.

This is also a useful example of why security statistics need retrieval dates. A vulnerability’s exploitation status, EPSS score, vendor risk rating, and KEV status can change after initial publication.

How Widely Is Drupal Used in 2026?

Drupal has a relatively small share of the total web but a stronger presence among high-traffic websites.

W3Techs reported on September 12, 2026 that Drupal is used by:

• 0.6% of all websites
• 0.9% of websites with a known CMS
• 3.6% of top-1-million sites whose CMS is known
• 6.1% of top-100,000 sites whose CMS is known
• 6.7% of top-10,000 sites whose CMS is known

The denominator in that last number matters. It does not mean 6.7% of every website in the global top 10,000 uses Drupal. It means 6.7% of top-10,000 websites whose CMS W3Techs identifies use Drupal.

For cross-platform context, see ScanTitan’s CMS Vulnerability Statistics research rather than comparing raw Drupal, WordPress, and Joomla CVE counts without accounting for different ecosystems and counting methods.

Which Drupal Versions Are Still Supported?

Drupal support status changes as new minor and major branches are released, so this is another statistic that must be dated.

As of September 2026, the Drupal core security release window covers:

Drupal 11.4.0 ended security support for 11.2.x and 10.5.x. Drupal 10 itself is scheduled to reach end of life in December 2026 when Drupal 12 is released.

If you do not know which branch your site runs, first check your Drupal version before using a vulnerability statistic to judge whether the site is actually exposed.

What Do Drupal Vulnerability Statistics Actually Tell Us?

The data supports several conclusions, but it does not support simplistic claims such as “Drupal is secure because it has fewer CVEs” or “Drupal is insecure because it has many contributed-module advisories.”

The statistics describe the ecosystem, not your installation. A site scanner is what turns ecosystem data into a list of findings you can act on.

The strongest findings are:

• Drupal core produces relatively few advisories each year compared with the contributed-project ecosystem.
• Contributed-project advisories dominate Drupal’s official historical security-advisory dataset.
• Most Drupal core advisories in 2026 are Moderately Critical.
• XSS is the most frequent vulnerability label among 2026 core advisories.
• A small number of severe vulnerabilities account for much of Drupal’s exploitation history.
• Confirmed exploitation can change the priority of a vulnerability very quickly, as CVE-2026-9082 demonstrated.
• End-of-life software creates a different risk from a supported branch because regular security fixes are no longer provided.

What the statistics do not tell you is whether a particular Drupal website is secure.

A real site can also contain:

• vulnerable contributed modules
• unsupported modules
• custom modules and themes
• misconfigured permissions
• exposed services
• outdated PHP or server dependencies
• weak authentication or access controls

For that broader question, see our analysis of whether Drupal is secure.

What Should Drupal Site Owners Do With These Statistics?

The practical lesson is not to panic every time the annual vulnerability count rises. The better response is to identify which disclosures apply to your actual stack and prioritize those with meaningful exploitability or exposure.

For Drupal administrators:

• stay on a currently supported Drupal branch
• inventory every contributed module and theme
• remove unsupported or unnecessary projects
• monitor Drupal Security Team advisories
• prioritize confirmed exploited vulnerabilities and high-impact anonymous attack paths
• verify remediation after patching

A continuous process is more useful than checking vulnerability statistics once per year. Our guide to continuous vulnerability scanning explains how to monitor changing exposure, while our guide to prioritizing vulnerability remediation covers how to move beyond severity scores alone.

Methodology and Sources

This report was updated in September 2026 and deliberately keeps several Drupal security datasets separate.

The methodology is:

• Official Drupal security advisories are the primary source for Drupal core advisory counts, advisory titles, Drupal risk ratings, and vulnerability classifications.
• Drupal Security Team’s annual track record is used for historical core-versus-contributed advisory counts.
• Drupal’s CVE assignment policy is used to explain why security-advisory counts and CVE counts can differ.
• CISA KEV is used to identify vulnerabilities with confirmed exploitation.
• W3Techs is used for current Drupal usage and CMS market-share context.
• Third-party vulnerability databases are used to show how database scope affects reported totals, not as substitutes for Drupal’s own advisory data.

Calculated percentages, including the 2026 severity distribution and contributed-project share, are derived from the published source counts. The 2026 Drupal Security Team track-record row is a year-to-date snapshot rather than a full-year figure, and contributed-project advisories have continued to be published since that snapshot.

Frequently Asked Questions