Tiffany Farriss reports that Drupal published 256 security advisories from June through October 2026, exceeding the 250 published during the previous 30 months. Her October 29 account describes how paid fixing, review and infrastructure work helped the volunteer Security Team handle that volume.
Evidence status: a first-party program report about discovery and remediation throughput. Advisory counts measure published security work. They cannot establish a corresponding increase in compromised sites, or prove that AI found every reported issue.
Farriss is the Drupal Association’s interim CEO and helps coordinate the initiative. Alpha-Omega funded the fractional team; the account also credits donated AI tooling and partner programs. It is an interested participant’s assessment of how that funding worked.
Finding a bug is only the beginning
The report credits funded-team participation in 223 of the 256 advisories, covering core and contributed projects. That includes coordination and review, not just discovering vulnerabilities or writing patches.
Farriss says the bottleneck moved from finding issues to reviewing fixes, then to deciding whether incoming reports were valid, new and assigned correctly. Work accumulated before release deadlines. Drupal is trying an early-week review pass and seeking more release-management capacity.
The operational implication is concrete: fund the path from report to shipped release, including duplicate checks, reproduction, review and coordination. Increasing scanner output without those roles can simply lengthen the queue.
The source’s claim that discovery economics have permanently changed is broader than its published measurements. Its advisory history documents Drupal’s workload; it does not quantify every ecosystem’s security outcomes.
Limit automation to a small, reviewable action
Drupal’s Triagebot posts one message per new report, suggesting a classification and likely duplicates. The account says it does nothing else. Since mid-August it has handled hundreds of reports, flagging roughly 20% as probable duplicates.
That figure is a suggestion rate, not a measured duplicate-detection accuracy. Drupal also uses AI-assisted weakness classification for vulnerability records, with mandatory human verification of each entry.
Its next phase proposes moving triage suggestions into GitLab under the same one-action rule. That is planned work, distinct from the Slack workflow already described.
The report also says Opengrep’s PHP parser silently skipped valid PHP 8 code in about 350 files across 176 contributed projects and all supported core branches. Drupal says the upstream fix merged September 1. Scanner coverage needs verification alongside findings; an empty report can conceal skipped input.
Site owners still need the actual advisory and a deployed fix
The program cites SA-CORE-2026-014, released October 14, as a concrete result. The full advisory identifies CVE-2026-108097, a remote-code-execution flaw in Field UI, Drupal’s field-configuration interface.
The advisory says core alone does not directly expose an exploit path. Contributed modules or custom code can expose the vulnerable functionality, with at least one known path requiring no authentication. Its exploitation rating is Theoretical; this is not a claim of observed attacks.
For the supported stable branches named there, the listed fixes are:
- Drupal 10.6.x: 10.6.19.
- Drupal 11.3.x: 11.3.19.
- Drupal 11.4.x: 11.4.10.
Use a supported release containing the fix. The advisory also lists an affected pre-release range ending before 12.0.0-beta2; that boundary is not a recommendation to move a production site onto a beta.
Drupal documents uninstalling Field UI as a temporary mitigation while updating. Check the enabled modules and deployed branch against the full advisory. A program’s published fix count cannot confirm that an individual site has installed those fixes.
Caveat: this is Drupal’s account of its own funded workflow, without an independent control group or a measured reduction in real-world compromises.