Advisories in Five Months: Results from the Drupal AI Security Initiative

farrisson When the Drupal Association launched the Drupal AI Security Initiative with Alpha-Omega this past June, our goal was to test whether a fractional, funded team, pairing fixers, reviewers, and infrastructure engineering alongside our volunteer Security Team, could protect maintainers from an incoming wave of AI-assisted vulnerability reports.

Five months later, that anticipated wave is fully visible in the public data.

From June through October 2026, Drupal published 256 security advisories. That five-month total exceeds the 250 advisories published across the previous 30 months combined. Baseline volume climbed from an average of 8 advisories per month in early 2026 to 28 in June, 74 in September, and 106 in October. The eight highest-volume publication days in our records since 2018 all landed within the last five months, peaking at 39 advisories on October 28. The data marks the completion of our initial Clarity phase. It demonstrates why the economics of vulnerability discovery have permanently shifted and proves that funding the complete review workflow is the only reason our volunteer process kept publishing without buckling.

Monthly Drupal security advisories published from December 2023 to October 2026. The surge beginning in June 2026 reflects an increase in automated discovery velocity and disclosure throughput supported by the SEIR grant, not a shift in Drupal's codebase security.

Why Advisory Volume Surged: The Changing Economics of Discovery #

The surge in Drupal security advisories is driven by a fundamental shift in the economics of vulnerability discovery, not a change in Drupal’s underlying attack surface. The vulnerabilities surfacing in 2026 are primarily latent bugs in mature core and contributed code that AI-assisted analysis has made cheap, fast, and automatable to identify across projects simultaneously. Since 1 June, 134 different people have been credited as reporters on Drupal advisories. In all of 2025, 68 people were.

The volume of advisories and CVEs Drupal has experienced between June and October is not an isolated event. Telemetry shared across the Alpha-Omega cohort and confirmed in our discussions with global edge security teams reveals that this massive, simultaneous surge in automated vulnerability disclosures is playing out across every major open-source ecosystem.

Most of these reports came from volunteers and outside researchers, many of them using AI tools. Every advisory represents a real issue that was found, fixed, reviewed, and disclosed responsibly. That is the system working. The question the Clarity phase set out to answer was whether it could keep working at this pace.

About the SEIR Grant #

The grant came at exactly the right time. The Drupal Association received it from Alpha-Omega on May 19, 2026, and the funded team started work in early June. That same month, advisory volume began to rise: 28 advisories in June, against an average of 8.3 a month from December 2023 through May 2026. The Security Team could not have handled this volume without the grant.

The grant subsidizes part of the time for a fractional team. Drew Webber (@mcdruid) is the Fixer: he finds issues, writes patches, and builds tooling. Greg Knaddison (@greggles) and Michael Hess (@mlhess) are the Reviewers: they triage reports and review fixes. Neil Drumm (@drumm) covers Drupal.org infrastructure. Tim Lehnen (@hestenet) and I coordinate the program for the Drupal Association. The team works alongside the volunteer Drupal Security Team, which has kept up its usual work throughout.

In July, we reported 10 resolved security issues in the first six weeks, against a commitment of 8 for the whole grant. The credits on published advisories show where the funded time has gone since then:

| Advisories Crediting Team as Reporter/Fixer | 43 (inc.SA-CORE-2026-014 ) | 1 | Hands-on remediation on critical issues | Without the SEIR program, the SEIR team members would not have been able to adapt and scale to the increased volume as they have.

Phase 1 Lessons: Discovery Is Cheap, Intake Is the Bottleneck #

• Finding vulnerabilities is no longer the slow step. AI-assisted analysis made discovery cheap, so the work piled up later in the process: first in reviewing fixes, then in intake, where someone has to decide whether a new report is valid, whether it is new, and who should handle it.
• Our own process showed strain. The busiest publication days were preceded by review work piling up against the release deadline. A process that depends on a push at the deadline does not scale, so we are trying changes as ordinary as a standing early-week review pass.
• The SEIR cohort connected Drupal to partners. Through the cohort, Drupal joinedPatch the Planet , run by Trail of Bits and OpenAI. A Trail of Bits report against one contributed module led toSA-CORE-2026-014 , a critical fix in Drupal core released on October 14.
• Shared scanning tools can miss code silently. Opengrep's PHP parser skipped valid PHP 8 code without reporting an error, in about 350 files across 176 contributed projects and every supported branch of core. We reported it, and the fix was merged upstream on September 1, so every Opengrep user gets it.
• Drupal adds depth to the SEIR cohort. Other ecosystems in the cohort bring reach and volume. Drupal brings a large, long-lived codebase with security coverage across thousands of projects, which tests shared tools hard. When those tests find a problem, as with Opengrep, the fix goes upstream to everyone.
• Some bugs follow systemic patterns best addressed architecturally. Six hardening changes went into Drupal core through the public issue queue, including three that neutralize known gadget chains used in PHP object injection attacks (seeIssue #3524971 andrelated core hardening commits ).
• AI tools for maintainers with guardrails. Triagebot posts one message per new report, with a suggested classification and any likely duplicates, and does nothing else. AI-assisted tooling also proposes weakness classifications for Drupal's CVE records, with mandatory human verification on every entry. Since mid-August 2026, Triagebot has triaged hundreds of new reports into the Security Team's Slack channel, flagging roughly 20% as probable duplicates.
• Release capacity is the next constraint. A security fix reaches sites only when a release ships. Core maintainers have opened proposals tochange the security release process . It’s clear that core release management needs more resources (funding, people) as well.

Phase 2 (Attention): Hardening GitLab Intake and Release Pipelines #

Attention focuses on intake, in two directions:

1. Triage: we are extending Triagebot from Slack notifications to the GitLab API, so classification and duplicate detection happen where reports are filed, under the same one-action rule.
2. Reporting: with the Security Team and maintainers, we are writing a working standard for what a useful AI-assisted security report must contain.

Alongside that, core maintainers have opened proposals to make security releases faster and more predictable.

Upcoming Deep Dives: Upstream Fixes, Tooling, and Standards #

Over the next few weeks, we will publish a short posts about:

• How a report from Trail of Bits, through the Patch the Planet program, became the critical core fix SA-CORE-2026-014
• How we identified a silent parser bug in Opengrep, patched it upstream, and landed six systemic hardening changes in Drupal core
• The tools engineered for Security Team intake, and what we suggest to open-source projects evaluating automated AI scanning

Thanks #

Thank you to Alpha-Omega, the Open Source Security Foundation (OpenSSF), and the Linux Foundation for the grant, and for access to AI tooling from Anthropic. Thank you to Trail of Bits and OpenAI for Patch the Planet; to the Open Source Technology Improvement Fund (OSTIF) and the PHP Foundation for tooling and protocols we now use daily; and to the SEIR cohort across a dozen ecosystems, including Ruby, Rust, Node.js, Python, Perl, Erlang, FreeBSD, and Eclipse, for comparing notes every week.

Most of all, thank you to the volunteers on the Drupal Security Team, who have protected Drupal sites for more than 20 years and kept doing so through the busiest five months in our records.