The short answer#
Drupal is a well-engineered content management system maintained by people who take security more seriously than most of their competitors. It is also, in 2026, a platform whose security releases are funded for eight hours a week, whose volunteer security team has publicly stated it cannot sustain the current pace, and on which nearly half of all installations run a version that receives no security fixes at all.
Both halves of that sentence are true. The second one is the one you have to plan around.
If the question is "has Drupal been breached through a flaw in Drupal", the answer is yes, repeatedly, and the most famous cases are in the federal catalogue. If the question is "is Drupal less secure than the alternatives", the honest answer is that the evidence does not support a ranking. CISA's catalogue holds more WordPress entries than Drupal ones. If the question is "can I rely on Drupal being patched quickly in 2027", the answer is now an explicit no, in Drupal's own words, and that is new. 1
Capacity: the part that changed#
Until 2026 you could argue about Drupal's security posture using code. That argument is over, because the project published the constraint itself.
this has created more work than the Drupal Security Team, especially with its current levels of funding, can sustain. For site owners, this introduces risks that security fixes will take longer to release, which gives more time for malicious actors armed with LLMs to find attacks.
Three things are happening in that paragraph at once. A workload has exceeded a team. The remedy chosen is to reduce the service level rather than increase the funding. And the consequence is stated plainly: slower fixes, faster attackers.
The numbers behind it are not ambiguous. Advisories went from an 8.3-per-month baseline to 28 in June, 74 in September and 106 in October 2026; 39 landed on a single day. Credited reporters went from 68 in all of 2025 to 134 in five months. The last fifty entries in the contributed-project feed cover eight calendar days. 2 3
The team absorbing this is an all-volunteer group of roughly thirty people, several of whom also hold core commit rights. Eighty-seven per cent of the advisories in the last five months involved staff paid by a grant from Alpha-Omega and a sovereign-tech programme. That money arrives as a project grant, not as a line in Drupal's operating budget. Drupal's own summary: the team "could not have handled this volume without the grant." 2
we argue A security function funded by donation is a security function that can be defunded by a change of programme priorities at a foundation you have never heard of. A resilience model would not have that shape, and Drupal's own staff know it.
The estate: the part that is not Drupal's fault#
From here it is your problem, or the site owner's.
W3Techs counts Drupal on 0.6% of all websites. Of those, 28.8% are on Drupal 7, which reached end of life in January 2025. Another 19.5% are on Drupal 9, 8, 6, 5 and 4, all unsupported. That is 48.3% of the Drupal web running on code that will never receive another security patch from the project. 4
The October core vulnerability turned that statistic into a live exposure count. When SA-CORE-2026-014 shipped, 151,442 of the 531,499 sites reporting a core version (28.5%) were on branches the advisory listed as affected with no fix available. By December 2026 another 41.7% sit on 10.6.x and 11.3.x, whose security coverage expires in the same month. 5
Two honest caveats, because they matter: the usage snapshot predates the fixes, and the advisory notes the flaw is not directly exploitable with core alone. "Affected with no fix" is a category in a security advisory, not proof of reachability. We are not going to pretend otherwise. The number is damning enough as it stands.
Exploitation: what actually happened#
Drupal has five entries in CISA's Known Exploited Vulnerabilities catalogue. Two of them (CVE-2018-7600 and CVE-2018-7602, the Drupalgeddon2 family) are flagged as known to be used in ransomware campaigns. Both are from 2018. Both still appear in scanning traffic. 6
2026 added a faster case. In May, a critical SQL injection affecting PostgreSQL sites (SA-CORE-2026-004, risk 23/25) was patched on 20 May; exploit attempts were detected within 48 hours and CISA added it to the catalogue on 22 May. Reporting credits a security firm with building a working exploit from the public patch, using a model, in 51 minutes. 7
Then look at the timeline. In 2014, Drupal's own advisory told administrators to assume their site was compromised if it had not been patched within seven hours of the announcement. In 2026 the pre-announcement for the October core RCE warned that exploits might be developed "within hours or days", and then said fixes would take longer to produce. 8 1
Layers you do not control#
Drupal's own incident recap of the October PHP vulnerabilities (CVE-2026-109618 and CVE-2026-109619, CVSS 9.2, affecting PHP 8.2 through 8.5) contains the sentence that should end any argument about whether a CMS can be "secure" on its own: Drupal Steward, the vendor WAF whose rules are written by the security team, "does not—and cannot—protect against underlying engine-level vulnerabilities in the PHP runtime itself." 9
Drupal is describing a ceiling, not confessing a fault. The reassurance still has a hole in it: "we're on the latest Drupal and we buy the WAF" covers a documented subset of the risk, and the vendor says so on its own site.
What this means for you#
If you are choosing a platform this quarter, this site is not going to tell you Drupal is uniquely dangerous. It will tell you the maintenance burden is real, the security function is underfunded, and the failure mode is an unpatched site rather than a broken one, which is why it goes unnoticed until it is expensive.
If you are staying on Drupal, four things are now measurable rather than rhetorical: which supported branch you are on and when its security coverage ends; how many of your contributed modules are covered by the advisory policy; your mean time from critical advisory to production patch; and whether your agency is funding any of the maintenance it depends on. 10
If you are the person who signs the invoice: the project has published what it needs. Eight hours a week is the entire security release pipeline, not a rounding error.
The counter-case#
Drupal's security process is better than most. Coordinated disclosure, same-day CVE assignment, published risk scores out of 25, pre-announcements for critical fixes, and a twenty-year track record including two events severe enough to get their own nickname. We put that on its own page, because a case that cannot survive the strongest version of the other side is not a case.
It changes nothing about the arithmetic above. It is the reason the arithmetic is credible: this is a project that ran out of funded hours, not one that stopped caring.