Drupal Core Maintainers Seek Security Release Changes Amid Funding Shortfall

Core release managers are proposing changes to how Drupal prepares and publishes security updates after documenting difficulties with testing, tagging and packaging releases. A public GitLab proposal reports that the November 2025 security-release window required 39 separate changesets and that the releases were not available until after 23:00 UTC, beyond the scheduled window. The proposal identifies several parts of the existing workflow that make security releases time-consuming and difficult to coordinate.

The proposals have gained significance as Drupal handles a substantial increase in vulnerability disclosures. The Drupal Association reported on 29 October 2026 that Drupal had published 256 security advisories between June and October, including 106 in October. Although AI-assisted tools have accelerated the discovery of vulnerabilities, preparing a reliable update still requires human review, testing and release coordination. The increased activity places additional demands on a process that maintainers say already requires considerable manual work.

The GitLab proposal illustrates how that workload can grow across supported Drupal versions. It calculates that a hypothetical security-release window involving six advisories across seven maintained branches could require up to 86 changesets. An accompanying upstream dependency update could increase the total to 94. These are estimates of potential preparation work rather than measured backlogs, but they illustrate the number of changes release managers may need to review, test, commit and include in releases.

One difficulty comes from Drupal's longstanding practice of preparing core security releases from the previous release tag rather than the latest commits on a release branch. The policy was introduced in 2011 to minimise unrelated changes included in security updates. However, it requires maintainers to stage security fixes separately across supported branches and reconcile changes that may already exist in their development histories. Dependency updates, test corrections and differences between branch tips and release tags can introduce additional merge conflicts.

Drupal core release manager Jess Myrbo, known as xjm, described those problems in a 19 October comment on a Drupal core policy issue. Jess identified merge conflicts and test pipelines as two of the most difficult parts of the current process. She said conflicts involving dependency updates, lockfiles and release tags had contributed to regressions in previous security releases. She also explained that testing pipelines do not reliably exercise the exact code assembled from an earlier release tag, creating uncertainty when preparing security fixes for publication.

The policy discussion was opened on 14 July by Nathaniel Catchpole, another Drupal core release manager. It proposes tagging security releases directly from release branches instead of previous tags, potentially reducing the need for additional staging and merging. The discussion has also considered restricting backports between regular patch releases and security-release windows to keep changes manageable. Contributors have raised concerns about introducing unrelated changes into security releases, which site operators generally expect to contain minimal disruption. The proposal reached the Reviewed & tested by the community stage on 20 October, but its adoption has not been confirmed.

The broader GitLab proposal identifies problems beyond branching. According to the document, the existing core security-tagging script lacks automated test coverage and does not handle merge conflicts reliably. Release managers must also coordinate freezes on core commits, because new changes can interfere with staged security updates or occupy the packaging queue. The proposal states that a disrupted freeze can require the release to be staged again, adding further preparation work.

Packaging presents a separate concern. The proposal says Drupal core releases cannot currently be packaged privately, leaving some security-related commits visible in public source code for approximately 1.5–2.5 hours before all installable releases become available. It recommends preparing the parts of release packaging that can be completed privately, automating more of the tagging process and allowing final packaging jobs to run in parallel. Greater control over packaging priorities is also proposed. These changes are intended to make publication more predictable, but the document does not establish that they have been implemented.

The proposed improvements concern release preparation rather than the completed migration of confidential security issues to GitLab. As The DropTimes reported in July, Drupal.org had already transferred its confidential security-issue workflow to GitLab, introducing automated testing for security merge requests and improvements to advisory preparation. The newer proposals address what happens after fixes are prepared, particularly how core releases are staged, tagged, packaged and published across supported versions.

Funding adds another constraint. In a 28 October 2026 blog post, Jess reported that her funded release-management time had fallen from 40 hours per week in 2022 to eight hours per week since May 2026. She also stated that funding for core release management overall was below half its levels during 2013–2023. According to Jess, the planned release timelines for Drupal 11.4, 11.5 and 12.0 have slipped substantially, although her account does not establish how much of each delay was attributable to reduced funding.

Jess said a prospective sponsor might fund another seven hours of her work each week, bringing her total to 15 hours. She indicated that a further 12–16 funded hours would still be necessary to approach current requirements. That additional sponsorship had not been confirmed when she published her account. The funding concern follows recent changes to Drupal's contribution-credit system that extend sponsorship recognition to more maintenance and security roles. Those changes recognise ongoing contributions but do not themselves establish additional funded working hours.

The Drupal Association has separately acknowledged the pressure on security-review capacity. In its 29 October initiative report, the Association said its Alpha-Omega-funded Security Engineer in Residence team had participated in 223 of the 256 advisories published during the five-month period. It described how the review workload initially accumulated around fixes before shifting towards intake and report validation. The report identifies release capacity as a further constraint and points to the proposals opened by core maintainers. Its participation figures document activity by the funded team but do not measure the time required to move a validated vulnerability through to an installable update.

The public records establish specific workflow limitations and a decline in funded release-management capacity, but they do not quantify how many security releases have been delayed because of either factor. Drupal continues to publish security updates, while maintainers are considering changes intended to reduce release preparation work without compromising update reliability. Whether the proposed improvements can be implemented and supported with sufficient maintainer time remains an open question as advisory activity increases.