Your Drupal Security Is Running on Volunteer Hours, and They Can't Keep Up

PSA-2026-11-02 says the team is facing a "tsunami" of reports, "more work than the Drupal Security Team, especially with its current levels of funding, can sustain." Its remedy is shorter overlap between supported versions, which it says cuts backport work for core security advisories by 30%. It states the cost itself:

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.

Your patch latency now depends on the capacity of a volunteer team.

The load

From the Association's report, 256 Advisories in Five Months:

Source: Drupal Association, 256 Advisories in Five Months.

	Baseline	June to October 2026
Advisories per month	8.3	51
Credited reporters	68 (all of 2025)	134
Core advisories per year	15 (record before 2026, per xjm)	16 by October

39 advisories landed on 28 October alone. SA-CORE-2026-004, a highly critical SQL injection that affects only PostgreSQL sites, was published on 20 May. By 22 May the Security Team had raised its risk score because exploit attempts were being detected, and CISA added it to its known-exploited list. Menetray reports that a security company, which he doesn't name, used an AI model to build an exploit from the public patch in 51 minutes.

The Association says the surge reflects cheaper discovery, not a change in Drupal's attack surface. Its own conclusion: "Finding vulnerabilities is no longer the slow step." The work now piles up in reviewing fixes, in intake, and in shipping releases, all of which take people.

The people

The Security Team describes itself as "an all-volunteer group." About thirty volunteers sit on it, covering what the Association calls "security coverage across thousands of projects."

The extra capacity came from an outside grant. Alpha-Omega's grant subsidises part of the time of a small fractional team that took part in 223 of the 256 advisories, and the Association states: "The Security Team could not have handled this volume without the grant." The project still cut the schedule with the grant in place. A grant is a donation, not a structure.

The release step is thinner still. Sponsors fund core release management. xjm, a core release manager funded since 2013, has had 8 funded hours a week since May 2026, down from 40 in 2022. She writes that funding for core stability and security is at its lowest since 2012, and that two organisations that each sponsored a release manager for a decade stopped in 2022 and 2026. The 11.4, 11.5 and 12.0 timelines have all slipped.

The Association's 2025 audit shows little room to backfill: reserves of 2.3 months against a board minimum of three, and donated services covering nearly half of the Drupal.org bill. The Association calls itself a going concern that is not in danger of insolvency.

This is the point. A security process that stays up only while some person or company keeps choosing to pay for it is a goodwill dependency, and you would not accept that from a vendor. xjm's sponsor page lists hourly rates and a Patreon. Part of your enterprise's patch pipeline sits downstream of that page, and your risk register probably has no line for it.

The AI they restrict

Drupal's leadership sells AI. Dries Buytaert's 2026 roadmap lists page generation and background agents. Drupal's own AI module was one of the 39 projects patched on 28 October for cross-site scripting (SA-CONTRIB-2026-272).

Contribution to core is far more restrictive. For drupal.org prose such as comments and issue posts, core/AGENTS.md tells a model to begin "by telling the operator to rewrite the result in their own words before publishing," and caps output at 180 words. The contribution policy says "Saying 'the AI wrote it' is grounds for immediately closing the contribution." It is not a ban on AI tools, and it requires disclosure. The issue queue spent the year on proposals to go further:

Issue	Comments	Status
#3574093 Ban slop issue summaries and comments	197	Postponed
#3580761 Ban LLM code contributions from Drupal core	26	Active

Issue #3580761 on drupal.org: a proposal, still open, not policy.

The reviewers have a real complaint. In comment #52 core committer catch listed examples of what he called vibe-coded contributions: a 5,000-line merge request that drew five core committers before the work restarted from scratch, a 4,500-line one that took longwave 121 review comments, and a Fibers bug report that he asked the reporter to confirm was not AI-found. It closed as "cannot reproduce" with no reply. The author of the AGENTS.md proposal concedes that "people are afraid of mentioning their LLM use, defeating the policy."

The same people sit on both sides. catch, longwave, alexpott, larowlan and xjm are core maintainers and Security Team members.

The security side does use AI. The Association's report describes a Triagebot that suggests classifications and flags roughly 20% of new reports as probable duplicates, and AI-assisted CVE classification with human review. What I can't find is any public plan to automate the mechanical work of backporting a reviewed fix to older branches, running the tests and checking the result. The PSA's answer to the flood is to support fewer branches, and it doesn't mention automation. Whether the project's wariness about AI explains that is my inference. The record shows the outcome: machine-speed discovery, a volunteer-and-grant response, and a shorter support window for you.

What to do with this

Treat Drupal security the way you would treat any dependency whose maintainers have told you in writing that they are running out of capacity.

• Put April 2027, August 2027 and February 2028 in the calendar. Those are the dates the supported minors lose security coverage, two months after their successors ship.
• Leave Drupal 10 before 9 December 2026. Drupal 12 arrives that week and requires PHP 8.5.
• Apply Critical and Highly critical advisories the day they publish. Automate detection with composer audit in CI.
• Write the dependency into your risk register: platform security depends on volunteers and a handful of sponsored hours.
• Price the exit.

Exit

Leaving Drupal has always been the hard part. The Migrate API is built to move content in, and Drupal has no built-in full-site export. One article spreads across a dozen tables, Layout Builder stores serialized PHP objects, and body fields carry Drupal-only embed tokens.

I built unDrupal for that. It's an MIT-licensed set of markdown skills that teach Claude Code, Cursor, Copilot or pi how to audit a Drupal 7 to 11 site and pull out content, paragraphs, menus, aliases, redirects and media, with SQL, Drush and JSON:API scripts and target mappings for Astro, Next.js, WordPress, Strapi, Payload and others.

Kevin P. Davison used it to move an end-of-life Drupal 7 site to static Astro: about 330 pages with the same URLs and content and a matched design, in two days and eight hours of his attention, for under $100 in tokens. A person accepted each of the agent's 36 decisions. Lighthouse put the live Drupal 7 homepage at 28 and the sampled static pages at 82 to 90 on mobile, and npm audit reports zero vulnerabilities. He is clear about the limits: the site was small, it needed a human at every gate, and it was still a demo awaiting acceptance.

Security you can't name an owner for is a risk you haven't priced. Price it, then decide where your site should live.