Drupal Cuts Minor-Release Security Support to Eight Months Amid Funding Strain

Maintainers responsible for Drupal core security will reduce the security-support period for standard minor releases from 12 months to eight months beginning in 2027. The Drupal Security Team and core release managers announced the decision as rising vulnerability reports and limited maintenance funding increased pressure on the project's security-release process.

According to PSA-2026-11-02, the official public service announcement, the revised schedule is expected to reduce backporting work for Drupal core security advisories by approximately 30%. Major versions will continue to receive at least four years of security support.

The decision does not indicate that Drupal has suddenly become less secure. Instead, it changes the project's maintenance commitments to site owners. Drupal will support older minor branches for a shorter period as the work of reviewing, backporting, testing and publishing security fixes becomes increasingly demanding.

The announcement explicitly connects the change to the volume of security reports and the Security Team's current funding levels. It warns that delays in preparing fixes could give malicious actors using large language models more time to develop attacks.

Drupal Reduces the Security Support Window for Minor Releases

Under the revised model, a standard Drupal core minor release will receive six months of bug-fix support followed by two months of security-only support. Because Drupal normally publishes minor releases approximately every six months, organizations will have a shorter period to move away from an older version after its successor arrives.

Previously, the preceding minor release generally remained covered by security fixes for about six months after a newer version was published. Beginning in 2027, that overlap will fall to approximately two months.

The final minor release in a major-version series remains an exception. It will receive six months of bug-fix support followed by six months of security support.

The announced transition dates are as follows:

Drupal 11.5 and Drupal 12.0 are scheduled for the week of 7 December 2026, while Drupal 11.6 and Drupal 12.1 are scheduled for June 2027. The change substantially reduces the security-support overlap between successive minor releases.

For Drupal agencies, enterprise platform teams, universities, governments and managed hosting providers, this places greater importance on predictable upgrade schedules.

An organization requiring several weeks for regression testing, accessibility review, compliance approval, customer sign-off and production deployment could use much of the remaining security-support window completing its normal release process.

Rising Security Reports Add Pressure to Drupal Maintenance

The policy change follows an extraordinary increase in security-advisory volume during 2026.

Between June and October 2026, Drupal published 256 security advisories covering Drupal core and contributed projects. That exceeded the 250 advisories published during the preceding 30 months combined. October alone accounted for 106 advisories, including 39 published on 28 October 2026.

The figures were reported by the Drupal Association in its 29 October 2026 report on the Drupal AI Security Initiative. They describe security activity across the Drupal ecosystem and should not be interpreted as 256 vulnerabilities in Drupal core alone.

The Association attributes the surge primarily to changes in the economics of vulnerability discovery. Its assessment is that AI-assisted analysis has made previously undetected weaknesses in mature core and contributed code cheaper and faster to identify, rather than indicating a sudden deterioration in Drupal's underlying security.

Although the advisory figures establish a substantial increase in published reports, they do not independently establish precisely how much of that growth was caused by AI-assisted tools.

The Association reported that 134 different people had been credited as security-advisory reporters since 1 June 2026, compared with 68 during all of 2025. The increase created additional work for those responsible for validating reports, reviewing fixes and coordinating disclosures.

Identifying a potential vulnerability is only the beginning of the process. Producing a reliable security update can require determining whether an issue is exploitable, identifying affected versions, preparing and reviewing patches, adapting changes to supported branches, updating dependencies, running tests and coordinating publication.

According to the Association, work initially accumulated around reviewing fixes before shifting toward intake and classification, where maintainers must establish whether incoming reports are valid, new and actionable.

The eight-month support policy addresses one component of this workload: the number of older core branches for which fixes must be maintained. Fewer supported branches mean fewer backports, fewer configurations to test and fewer release artifacts to prepare.

The projected 30% reduction in core security backporting is an estimate of the expected benefit, not a reduction that has already been measured following implementation.

Dependency management provides another reason for the change. Drupal says the revised policy aligns more closely with Symfony, one of its principal upstream dependencies. Standard Symfony releases, unlike long-term-support releases, receive eight months of maintenance.

That alignment reduces situations in which Drupal promises security coverage for a minor branch beyond the ordinary maintenance period of upstream components included in it.

Security Release Preparation Remains a Separate Challenge

Security maintenance does not end when a vulnerability has been fixed. A patch protects production websites only after an installable release has been tested, packaged and published.

The Drupal Association has identified release capacity as another significant constraint, noting that core release management requires additional people and funding.

Public maintainer discussions demonstrate the complexity involved. The November 2025 core security-release window required 39 separate changesets and continued beyond its scheduled publication window. Maintainers have also documented difficulties involving merge conflicts, release tagging, test pipelines and packaging.

Drupal has historically prepared security releases from previous release tags rather than directly from current development branches. Although this approach limits unrelated changes in security updates, it can increase the work needed to reconcile patches with code that has subsequently changed.

Release managers are considering improvements involving automated release preparation, more reliable tagging and the ability to complete more packaging work privately before fixes become publicly visible. These changes remain proposals rather than completed improvements.

The DropTimes reported on these release-workflow constraints on 3 November 2026, examining the technical difficulties and funding pressures affecting security-release preparation.

The newly announced support policy has a direct relationship to those problems. Maintaining fewer security-supported branches can reduce release-preparation work even before the proposed workflow improvements are implemented.

The importance of coordinating fixes across several branches was illustrated on 20 May 2026, when Drupal published SA-CORE-2026-004, a highly critical SQL-injection advisory affecting websites using PostgreSQL.

The vulnerability could be exploited by anonymous users. Drupal subsequently increased its risk rating on 22 May 2026 after detecting exploitation attempts in the wild.

The coordinated releases also included security updates for Symfony and Twig affecting installations beyond those exposed to the PostgreSQL-specific vulnerability.

The incident illustrates how a single core security issue can require updates across several branches alongside upstream dependency changes. Each resulting release needs appropriate verification before site owners can deploy it confidently.

Reducing the number of concurrently supported minor branches lowers that multiplication of work. At the same time, it requires site operators to complete their upgrades more quickly to retain security coverage.

Drupal Security Depends on Volunteers and Targeted Funding

Drupal's Security Team is an all-volunteer group. For more than two decades, the project has relied on contributors whose security work is supported through employers, individual sponsorship arrangements and personal time.

During 2026, the volunteer model received additional capacity through the Drupal Association's Security Engineer in Residence initiative, funded by Alpha-Omega.

The grant supports a fractional team working alongside Security Team volunteers on vulnerability remediation, review, infrastructure and coordination.

According to the Drupal Association, members of the funded team participated in 223 of the 256 security advisories published between June and October 2026. That represents approximately 87% of the total across Drupal core and contributed projects.

The Association stated that the Security Team could not have handled the increased reporting volume without the grant.

This finding is particularly significant. Drupal experienced an unprecedented advisory surge while externally funded contributors were already providing additional capacity. Even with that support, the project concluded that its existing security-maintenance commitments needed to be reduced.

Core release management faces a separate funding challenge.

Drupal core release manager Jess Myrbo, known as xjm, reported on 28 October 2026 that funding for Drupal core stability and security was at its lowest level since 2012. In her blog post, Do you like having secure Drupal sites? Help fund xjm., syndicated through Planet Drupal, she said funding for core release management was below half the level available during the 2013–2023 period.

According to Jess, two organizations that had each sponsored a Drupal core release manager for approximately a decade ended those commitments in 2022 and 2026, respectively.

Her own funded release-management time fell from 40 hours per week in 2022 to eight hours per week beginning in May 2026.

Jess said another potential sponsorship might restore seven hours, but she would still need an additional 12–16 funded hours per week to approach a sustainable workload.

These figures describe Jess's funded working time and her account of release-management sponsorship. They do not constitute an independent assessment of all labor contributed to Drupal core release management.

Jess also reported that planned release timelines for Drupal 11.4, 11.5 and 12.0 had slipped. The Drupal core release schedule confirms the revised dates, although the available public information does not establish how much of each delay resulted specifically from funding constraints.

Drupal Association Finances Add to Sustainability Concerns

The Drupal Association's finances add another dimension to the sustainability discussion, although its organizational budget should not be conflated with Security Team capacity or individual release-manager sponsorships.

In its 2025 Audit and Financial Overview, published on 4 August 2026, the Association reported an operating shortfall of approximately $451,000 in 2025, following a larger restated shortfall for 2024.

Unrestricted reserves had declined to approximately $960,000, equivalent to 2.3 months of operating expenses. That was below the board's three-month minimum.

The Association emphasized that it remained a going concern and was not at risk of insolvency.

Infrastructure costs present another challenge. According to the Association, spending on Drupal.org services, including GitLab, Composer endpoints, continuous integration, authentication and content delivery infrastructure, increased from $1.3 million in 2022 to $2.1 million in 2025.

Donated and in-kind services exceeded $1 million in 2025 and accounted for approximately 48% of Drupal.org infrastructure spending.

The Association acknowledged that Drupal.org lacks a durable direct funding mechanism despite its role as essential infrastructure for organizations using Drupal.

These financial figures do not establish that Drupal's security process is approaching failure. The available evidence also demonstrates resilience: Drupal continued publishing advisories during the surge, expanded funded triage and remediation capacity, introduced core hardening improvements and began developing changes to its release workflow.

The structural concern is more specific. Several security-critical functions serving a widely deployed open-source platform depend on volunteer labor, temporary grants, corporate sponsorship and donated infrastructure.

Those arrangements can change when individual organizations revise their funding priorities, even while demand for maintenance work continues to increase.

Drupal's AI Security Challenge Extends Beyond Vulnerability Discovery

The increased pace of vulnerability discovery has also brought greater attention to Drupal's approach to artificial intelligence within its contribution and maintenance processes.

Drupal's policy on the use of AI when contributing does not prohibit AI-assisted contributions. Instead, it requires contributors to understand their submissions, verify generated code and dependencies, disclose significant AI assistance and respond meaningfully to maintainer feedback.

The policy addresses an imbalance: code or text that can be generated in minutes may take considerably longer for a maintainer to review, test and correct.

At the same time, Drupal's security operation is using AI-assisted tools for selected tasks.

The Drupal Association reports that Triagebot suggests classifications and flags possible duplicate vulnerability reports for human verification. Since mid-August 2026, the tool has identified approximately 20% of incoming reports as probable duplicates.

AI-assisted tooling also proposes weakness classifications for Common Vulnerabilities and Exposures records, with human review required before those classifications are accepted.

The distinction is therefore not whether Drupal should use AI. It is where automation can reduce maintenance work without creating additional risks or transferring even more effort to human reviewers.

The published evidence does not establish that Drupal's cautious approach to AI-generated contributions is responsible for its security-release bottleneck.

A narrower conclusion is supported: vulnerability discovery has accelerated, while the processes needed to validate, fix and publish updates still depend on human expertise and release infrastructure that have not scaled at the same rate.

What the Shorter Security Window Means for Drupal 11 and Drupal 12

The revised policy does not require organizations to perform a major-version upgrade every eight months.

Drupal 11 remains supported until December 2028, while Drupal 12 is scheduled to receive support until December 2030. The change concerns how quickly organizations must move between minor releases within those major versions.

Under the previous model, a site could remain on the preceding minor release for approximately six months after its successor arrived and continue receiving security fixes. Under the revised model, that period will fall to approximately two months.

This matters particularly for websites that remain on older minor releases while resolving compatibility issues involving contributed modules, custom code, integrations or infrastructure.

For enterprises with extensive testing requirements, regulated deployment processes or complex Composer dependencies, the release of a new Drupal minor version will become the start of a more immediate security deadline.

After the security-only period expires, the older minor version will fall outside Drupal's promised security coverage.

The transition also coincides with significant platform changes. Drupal 10 will reach end of life on 9 December 2026, the same week that Drupal 12 and Drupal 11.5 are scheduled for release.

According to Drupal's Drupal 12 platform requirements announcement, Drupal 12 will require PHP 8.5. Drupal 11.4 continues to support PHP 8.3 and PHP 8.4.

Some organizations evaluating Drupal 12 will therefore need to consider a PHP runtime upgrade alongside the major CMS migration.

Drupal 11 remains a supported alternative through December 2028, although the appropriate upgrade path depends on each website's dependencies, hosting environment and development requirements.

Drupal Agencies and Site Owners Face Tighter Upgrade Timelines

The revised policy has implications beyond installing individual security patches.

Organizations will need to account for Drupal's June and December minor-release cycle when scheduling development, testing and deployment.

Testing during beta and release-candidate periods, where practical, can help identify compatibility problems before a stable release becomes available.

Site owners will also need to distinguish between a current minor release that receives bug fixes, an older minor receiving only security fixes and a minor version that has reached the end of security support.

Dependency auditing and vulnerability scanning remain essential, but they cannot replace version-lifecycle tracking. A minor branch that no longer receives security fixes cannot be treated as supported simply because no new advisory has been issued against it.

For Drupal service providers, the changes may also affect maintenance agreements and service-level commitments.

Contracts based on quarterly upgrade cycles, lengthy customer approval processes or delayed production deployments may provide less flexibility when the previous minor release has only two months of security coverage remaining after its successor arrives.

These are potential contractual and operational consequences of Drupal's revised lifecycle rather than new requirements formally imposed by the project.

The Bigger Question Is How Drupal Funds Security Maintenance

The eight-month support window is a practical engineering response to a documented workload problem.

Maintaining fewer branches reduces backporting requirements and allows release managers and security contributors to concentrate on a smaller number of updates. It also brings Drupal closer to the standard maintenance lifecycle of an important upstream dependency.

From the project's perspective, a shorter security-support commitment that can be delivered reliably may be preferable to a longer commitment that increasingly strains the people responsible for fulfilling it.

That does not make the change insignificant.

Drupal is responding to a sharp increase in vulnerability-discovery activity partly by requiring its users to move between minor releases more quickly. The project reduces maintenance work on older branches, while agencies, hosting providers and site owners take on more responsibility for meeting the updated timetable. Large organizations may have dedicated teams and automated deployment systems to manage that transition. Smaller agencies, nonprofits, educational institutions and public-sector organizations may have less flexibility.

The policy is also difficult to separate from the wider funding picture.

Drupal's Security Team remains volunteer-based. A grant-funded team participated in 87% of advisories published during the five-month surge. A senior release manager reports that her funded working hours have fallen substantially. The Drupal Association has separately reported reserves below its board minimum and an infrastructure funding model substantially dependent on donated services.

These figures concern different responsibilities and funding arrangements. They should not be treated as evidence of a single financial shortfall. Together, however, they describe an ecosystem in which essential security and release functions rely heavily on external support.

That dependence deserves attention from the commercial organizations that benefit from Drupal.

Agencies, hosting providers and enterprise users depend on coordinated vulnerability disclosure, security backports, release management, package infrastructure, testing systems and reliable update distribution. Yet much of the work supporting those functions is financed indirectly through grants, sponsored contributors, Association revenue or donated services.

A sustainable response will therefore require more than shortening support windows or making individual release tasks more efficient.

Maintainers are already pursuing process improvements, automation and more manageable security-maintenance commitments. The unresolved question is whether organizations that rely economically on Drupal will help fund sufficient long-term capacity to support those improvements.

The 3 November 2026 report by The DropTimes documented pressure on Drupal's security-release workflow. The newly confirmed eight-month policy adds a distinct consequence: the workload problem now changes the upgrade timetable for Drupal operators.

For site owners, the practical message is that the release calendar must become part of security planning. A Drupal minor release that is supported today can fall outside promised security coverage just two months after its successor arrives.

Organizations that still treat minor-version upgrades as discretionary maintenance will need to reconsider that approach before the new schedule takes effect.

For the wider Drupal community, the question is more difficult.

The project has demonstrated that AI-assisted vulnerability discovery can grow much faster than the human processes responsible for validating and resolving reports. It has also shown that targeted funding can increase response capacity, while temporary grants and reduced sponsorship commitments do not automatically create durable maintenance resources.

The eight-month policy is therefore more than a release-calendar adjustment. It is one of the clearest public signals yet that the economics of maintaining Drupal are being reshaped by the economics of discovering vulnerabilities.