Drupal security advisories and patch windows

How Drupal security advisories reach your patch calendar

If you own a regulated Drupal site, the question an auditor or board will ask is simple: how do you know a known vulnerability has been patched within your internal deadline? The answer starts with the Drupal Security Team, which resolves reported vulnerabilities in Drupal core and in contributed projects, publishes security advisories with CVE identifiers and risk scores, and ships fixes in security release windows on the third Wednesday of the month. Those advisories are the input to your process. Your team needs a written patch process once the site holds regulated data, once more than one person can change it, or once a missed update would be hard to explain to a regulator. That process should map each advisory's risk score and affected project to a deadline, name who approves an emergency update, and record when each change reached production.

The cadence is predictable, but the workload is not. Bugfix releases arrive on the first Wednesday of each month and security releases on the third, so a standing review on those dates catches most advisories. Contributed modules are the harder part: an advisory can cover a module your site uses even when core is current, and you need an inventory of installed projects and versions to match against it. Confirm with the Security Team's published policies how advisories for your specific core and contributed projects are announced, and subscribe your team to those channels so the clock starts when you learn of an issue, not when someone next checks the site.

This page covers how to respond to advisories, which release cadence to plan around, the configuration choices that shape your update calendar, how to set up the process, and the limits you should confirm before relying on it. Two limits matter early. Drupal 7 security support ended on January 5, 2025, so a Drupal 7 site cannot follow this calendar without an extended support arrangement, and Drupal 10 reaches end of life on December 9, 2026, which will change your deadlines if you have not upgraded. Confirm your current major version and PHP runtime against the Drupal core release schedule before you set any deadline.

How Drupal security advisory risk scores shape response

A Drupal security advisory gives a team several fields to read before it decides anything. The four cards below cover the parts that drive triage, and they explain why the risk score alone should never set the patch date.

The CVE identifier

Each advisory that the Drupal Security Team publishes carries a CVE identifier, which is the number your scanners, ticketing system and auditors use to track the issue. Record the identifier in your change ticket so that the patch, the test evidence and the closure note all point to the same reference. If your vulnerability scanner reports a CVE for Drupal, match it to the advisory before you assume the finding is a false positive or a duplicate.

The risk score and urgency

The advisory lists a risk score that signals how urgent the fix is in general terms. Confirm the scale and its meaning on the advisory itself, because the scale is not repeated here and should be checked against the current Drupal.org wording. Treat the score as the first input to triage, and record who set the deadline and why.

Core or contributed project

Each advisory states whether it affects Drupal core or a contributed project. Core issues apply to every site on the affected version, while contributed issues only matter if your site has that module installed and enabled. Build an inventory from your Composer lock file so you can answer the question in minutes rather than hours during a window.

Affected versions and fixed release

The advisory names the affected versions and the release that fixes them. Compare those versions with your running code, including custom modules and any sites that have fallen behind on a minor release. Note any site that cannot reach the fixed release on the current major version, and confirm whether an upgrade path or a supported extended provider applies.

Which patch cadence fits your team and deadline

This table compares three ways to schedule Drupal core and contributed updates against the published release dates. Read each row against your internal patch deadline, which should be written in terms of the first Wednesday bugfix window and the third Wednesday security window. The main takeaway is that a monthly-only cadence leaves security fixes waiting up to a month unless an out-of-cycle path exists.

Option	When it fits	What it requires from staff	Main trade-off
Monthly bugfix window only	Low-exposure internal sites with no public write access and a patch deadline measured in weeks, not days	A recurring monthly change slot on the first Wednesday, release notes review, and a test pass before production	Security releases on the third Wednesday wait for the next monthly slot, so exposure can run for several weeks
Security releases on the third Wednesday as they land	Public or member-facing sites where internal deadlines are measured from the third Wednesday	Staff on call that week, a tested staging copy ready to receive the update, and a documented rollback step	Most frequent change load; each release needs regression checks even when only contributed modules change
Hybrid: monthly cadence with out-of-cycle changes for critical advisories	Regulated sites that need a fixed monthly rhythm but must act quickly on critical or highly critical advisories	Written criteria for what counts as out-of-cycle, a named approver, a pre-approved emergency change path, and advisory monitoring	Needs clear risk-level rules and discipline; without them, emergency changes become routine and test coverage slips
Hybrid with fixed internal deadline from the third Wednesday	Sites with a written deadline such as a set number of days after each security release (confirm the period with your policy owner)	Calendar entries for both Wednesdays, an advisory subscription, and evidence of when each advisory was received and applied	Deadline is only as strong as the test and approval steps behind it; assessors will look for timestamps
Extended support or delayed upgrade (Drupal 7 only)	Sites still on Drupal 7 that cannot migrate yet and have a contracted extended support provider	Contract with a listed extended security support provider, a migration plan, and compensating controls for the gap	Security fixes depend on the provider's release timing rather than the core schedule, which must be confirmed in writing

Why Drupal 7 and Drupal 10 dates change the patch plan

Version status decides what a patch window can actually fix. Drupal 7 security support ended on January 5, 2025, so a Drupal 7 site no longer receives core security releases from the Drupal Security Team. Its patch plan is one of two things: a contract with a provider in the Drupal Association's Extended Security Support Provider Program, which lists HeroDevs and Tag1 Consulting as certified vendors, or a migration to a supported version. Confirm the provider's coverage, the vulnerabilities it addresses, and how fixes reach your environment before you assume an advisory will be handled. Migration is not an update. Drupal 6 and 7 sites are rebuilt in a new site with the Migrate modules or Drush, and themes must be rebuilt, so that work needs its own schedule and budget line.

Drupal 10 has a fixed end date that falls inside the planning horizon. According to the Drupal core release schedule, Drupal 10 reaches end of life on December 9, 2026, and Drupal 12 is scheduled for the week of December 7, 2026. A patch plan written today should therefore include a dated decision about the move to Drupal 11 or Drupal 12, with the upgrade work scheduled ahead of that date. Use the Drupal core release schedule as the reference for every date in your calendar, and recheck it at each quarterly planning cycle, since release dates can move.

PHP minimums can block a core patch before any code changes. Drupal 10 requires PHP 8.1 or later, Drupal 11 requires PHP 8.3 or later, and Drupal 12 requires PHP 8.5 or later, according to the Drupal.org PHP requirements page. A site still on an older PHP runtime may be unable to take a security release that depends on a newer core version, so the PHP version belongs in the same inventory as the Drupal version. Check the runtime on every web node, including containers and build images, and treat a PHP upgrade as a prerequisite that needs its own test cycle and rollback plan.

Patch plans for Drupal 11, Drupal 10 and Drupal 7 sites

Drupal 11 is the current major version, so it receives core and contributed security releases on the regular cycle. The core release schedule sets bugfix releases on the first Wednesday of each month and security releases on the third Wednesday. Your immediate control is a standing process that reads advisories as they are published and applies the update inside your internal patch deadline. The main decision is how much of that window your team can staff, and whether critical advisories get a faster path than routine ones.

Monitor both core and contributed projects: Subscribe to the Drupal Security Team advisories and track every contributed module in your composer.lock file, not only core.
Set deadlines by risk level: Agree in writing which advisory risk levels must be deployed within days and which can wait for the next scheduled release.
Test on a staging copy first: Run updates against a recent copy of production, including drush updatedb and your automated tests, before the production window.
Keep a rollback path: Confirm database and file backups are taken immediately before each deployment and that a restore has been tested.
Check PHP and dependencies: Drupal 11 requires PHP 8.3 or later, so confirm your runtime supports it before any core update.

Confirm with your hosting or support provider which team owns the production change and how quickly they can deploy outside the normal window.

How to build an update process that meets internal deadlines

This sequence turns Drupal advisories into a repeatable routine: know what you run, know who acts on each advisory, test changes on a faithful copy, and keep evidence that each patch met your deadline. It works whether your team or a partner carries out the work.

Inventory core and contributed projects
List every Drupal core version, contributed module, theme and library in each environment, with its exact version and where it is installed. Include Composer-managed packages and any custom code that depends on a contributed project. Check that the inventory matches the running production codebase, not only the repository, by comparing the deployed Composer lock file or the status report output. The step is done when every production project has a named version in one list that the owner has signed off.
Subscribe to advisories for each project
Subscribe the security mailing list and the Drupal Security Team advisory feed to a shared team alias, not a single person's inbox, so coverage survives staff changes. Add a subscription or watch for each contributed project in the inventory. Confirm that a test message reaches every recipient in the alias. The step is done when a named mailbox receives advisories for every project on the list and the subscriptions are recorded in the same inventory.
Assign triage owners and risk deadlines
Name one triage owner for each site and one backup, and write down the deadline your organization requires for each risk level the Drupal Security Team publishes. Decide who can approve an emergency change outside the normal calendar and who informs business owners. Ask your internal risk or compliance lead to confirm the deadlines in writing, since they come from your policy rather than from Drupal.org. The step is done when the deadline table and the owner roster are approved and stored with the runbook.
Set up staging and automated tests
Build a staging copy that uses the same Drupal version, PHP version, web server, database engine and contributed module set as production, and load a recent sanitized copy of the database and files. Add automated tests for the paths your business depends on, such as login, content publishing, forms and key integrations, and run them after each update. Confirm that staging matches production by comparing the inventory from the first step and the configuration export hash. The step is done when staging passes the test suite on the current release and matches production.
Define the monthly and third-Wednesday calendar
Build a change calendar around the Drupal core schedule: bugfix releases arrive on the first Wednesday of each month, and security releases arrive on the third Wednesday. Reserve change windows after each of those dates, and agree which changes wait for the regular window and which trigger an emergency path. Share the calendar with business owners and change advisory staff so approvals are not requested under pressure. The step is done when the calendar, freeze periods and emergency criteria are published and approved.
Rehearse deployment and rollback
Run the full update on staging using the same steps you will use in production: put the site in maintenance mode if your process requires it, apply the code update through your build pipeline, run database updates, clear caches and run the tests. Then rehearse the rollback by restoring the pre-update database backup and the previous code artifact on a copy and verifying the site returns. Record the elapsed steps and any manual actions so the production runbook reflects what really happened. The step is done when a rollback has been completed successfully on a copy and the runbook is updated.
Deploy to production and record evidence
Apply the rehearsed change in the next approved window, take a fresh backup immediately beforehand, and run the automated tests and a smoke check after the deployment. Record the advisory identifier, the affected project and version, the risk level, the deadline, the change ticket, the backup reference, the deployment time and the test results. Keep the record with the inventory so an auditor can trace an advisory to a patched version. The step is done when the record lists the advisory identifier, the production version now running and the date the deadline was met.

Limits to confirm before you commit to a patch deadline

A patch deadline is only as good as the path to deploying a release. The cards below cover the constraints in your own environment that decide whether a security release can land inside your window. This page does not give a patch-time guarantee, because release timing and your change process are outside the Drupal Security Team's control and your own.

Your deadline against the release windows

Security releases come out on the third Wednesday of the month, so a deadline that falls shortly after a release may leave little room for testing and deployment. Map your internal deadline against the release calendar and the change freeze dates you already observe. Ask whether an out-of-cycle release is permitted for critical issues and who approves an emergency change. Write down the step that takes longest in your process, because that step usually sets the real minimum time.

Custom code that must change

A core update can break custom modules or themes that depend on APIs changed or deprecated in the new release. Check whether your custom code has been tested against the target core version and whether contributed modules have released compatible versions. If any dependency is blocked, a security fix may wait for a code change first. Confirm who owns that code and how much work a compatibility fix takes.

Hosting and PHP version support

Your hosting platform must run a PHP version the target Drupal release supports. Drupal 10 requires PHP 8.1 or later and Drupal 11 requires PHP 8.3 or later. If your servers run an older PHP version, a core upgrade may require a platform upgrade first. Confirm the PHP version, the web server and database versions, and whether your managed hosting provider controls those upgrades.

Contracted extended support or firewall coverage

If a site runs a Drupal version past security support, an extended support provider or a web application firewall may be the only interim protection. Confirm in writing which advisories the contract covers, how fast the provider publishes fixes, and whether virtual patches apply only to specific vulnerability classes. Check whether the contract includes your contributed modules or only core. Coverage that does not match your site's modules leaves gaps.

Test coverage for regressions

A patch deadline assumes you can confirm the update did not break checkout, login, forms or content workflows. Review whether you have automated tests for critical paths, a staging copy with production-like data and a documented smoke test list. Without these, the verification step may take longer than the deployment itself. Decide in advance who signs off and what counts as a passing release.

Advisories that touch code you do not run

Not every advisory affects your site. Before starting an emergency change, check whether the vulnerable project, version and feature are actually installed and enabled. A disabled module may still need removal, but it may not need an urgent deployment. Keep an inventory of installed projects and their versions so the triage decision can be made quickly and recorded for audit.

What teams ask before outsourcing Drupal patching

What does outsourcing Drupal patching cost, and what drives the price up?

No price applies until the scope is written, and DeployOpen does not publish a price list. The fee follows from the work you buy: the number of Drupal sites, how much custom code you run, how many contributed modules are installed, how deep each test cycle goes, and where the sites are hosted. Each advisory you need handled adds review and testing time, so a site with many contributed modules will usually cost more to keep current than a small site with few. Ask for the cost split between one-time setup (inventory, a baseline test, the process build) and the recurring monthly or per-window work, and ask what happens to the fee when a critical advisory lands outside the normal window.

How long does a Drupal security response take?

The response time depends on the advisory and on the test scope you require, so no single duration applies. Drupal core and contributed projects publish advisories with risk scores, and the Drupal Security Team uses the third Wednesday of the month for security releases, so that day is the anchor for your schedule. A low-risk fix to one contributed module can move through a staging test quickly, while a core release touching many subsystems needs a broader regression pass. Ask the provider to state how long each risk level takes from advisory to production in your environment, and confirm which of your internal approvals must happen inside that window.

What must our team provide before a partner can patch our site?

A partner needs working access and clear decision rights before the first window. In practice that means:

Administrative access to the code repository, the staging environment and the hosting platform, with credentials held in your own secrets store
A staging copy that resembles production in configuration, data shape and enabled modules
Named business owners for each site who can accept a test result and approve release
A standing approval path for emergency patches, including who can sign off outside working hours

Ask the provider to confirm each item in writing, because missing approvals are the most common reason a window is missed.

Can an internal team run Drupal patching without an outside partner?

Yes, a capable internal team can run the process alone if it has the skills and time to do it reliably. The work is repeatable: monitor advisories, assess affected code, apply updates in a Composer-based build, test on staging, and release on schedule. What usually gets harder is the workload during a cluster of advisories, and the coverage needed for critical releases that arrive out of hours. Decide whether your team can meet your internal patch deadlines on its own, including a named backup for each step. A partner is most useful when your own capacity cannot absorb peak weeks.

Which patching tasks are one-time and which recur?

Setup is one-time, and monitoring and release work recur. One-time items include building the inventory of Drupal core, contributed modules and themes, setting a baseline test suite, documenting the approval path, and making the build and release process repeatable. Recurring items include watching advisories, reviewing each security release against your installed code, applying updates in every Wednesday window, retesting, and keeping an audit trail of what changed and when. Ask whether the quote separates these two groups, because a low setup fee with an open-ended recurring fee changes the total cost of ownership.

What should we ask for in a written quote for Drupal patching?

Ask for a quote that ties each price to a written scope. Request the following:

The exact list of sites, Drupal versions and contributed modules covered
The advisory risk levels and response steps included, and which are excluded
The test depth for each release, and who signs off the result
Whether emergency out-of-window work is included or billed separately
The support hours, reporting format and the process if a Drupal version reaches end of life
Responsibilities for hosting, backups and rollback

For an engagement with a known schedule, check the Drupal core release schedule so the quote reflects real end-of-life dates.

What happens if our site runs a Drupal version that is no longer supported?

An unsupported version cannot be fixed by routine patching, so the plan must include a migration or a paid extended support route. Drupal 7 security support ended on January 5, 2025, and the Drupal Association's extended security support program lists certified vendors for sites that cannot migrate yet. Drupal 10 reaches end of life on December 9, 2026. Ask the provider to show, for each site, the end-of-life date, the migration or upgrade work needed, and how patch windows will continue until that work is finished. Confirm whether the quote covers that transition or whether it is a separate project.

Security controls to run alongside patching

A patch window only closes exposure once the update reaches production, and the days between an advisory and deployment carry most of the risk. The four controls below reduce that exposure, and each one should have a named owner who checks it on every security release.

Web application firewall and virtual patching

A web application firewall can block requests that match known exploit patterns while your team tests the update, and some providers offer virtual patching for specific advisories. The paid Drupal Steward service buys time for highly critical core vulnerabilities, but it does not replace updates, so confirm with the vendor which advisories it covers, how long each virtual patch stays in place and what your team must still deploy.

Contributed module maintenance review

Before each security window, check the maintenance status, install counts and advisory history of every contributed module, because a project without an active maintainer may publish an advisory with no fixed release to deploy. Flag unsupported projects early so the team can choose a replacement or plan an upgrade path while there is time to build and test it.

Patch evidence retention

Keep a dated record for each security release that names the advisory, the affected modules, the version deployed, the environments it reached and the person who approved the change. Advisories from the Drupal Security Team carry CVE identifiers and risk scores, so store the advisory identifier with every change ticket to make the record searchable during an internal review or external assessment.

Secrets kept out of configuration

Database passwords, API keys and encryption keys should sit outside the site's exported configuration, in environment variables or external storage, where the Key module is one common approach on Drupal. Check each deployment for credentials in configuration exports before the update goes live, because an update that leaves secrets in version control keeps the exposure in place after the patch is applied.

How DeployOpen works on this

DeployOpen plans, implements, hardens, documents and supports self-hosted Drupal inside your own infrastructure, including the update process that answers Drupal security advisories. Engagements are fixed-scope, with the scope, deliverables and timelines agreed in writing before work starts.

How we scope

Inventory Drupal core, contributed modules and custom code, with each project's advisory coverage and maintenance status recorded.
Agree the Drupal version path, PHP version and hosting constraints before any patch process is designed.
Write down internal patch deadlines by risk level, with named approvers for out-of-cycle and emergency releases.

How we build

Build a staging environment that mirrors production so security releases are tested before they reach live sites.
Set up a runbook that maps the first Wednesday bugfix window and the third Wednesday security window to your change calendar.
Configure Composer-based updates, database backups and rollback steps so each patch can be reversed if it fails.

How we hand over

Document the advisory intake process, who reviews each advisory, and the decision record kept for every patch.
Provide a checklist for public service announcements on critical releases, including the steps to take outside the normal window.
Train your platform and security staff to run the patch cycle, check results and escalate issues without DeployOpen.

How we support

Ongoing support, upgrades and continuous testing are available as retainers, scoped in writing separately from the build.
Confirm with your team which patch steps DeployOpen performs, which your staff performs, and who signs off each release.
Review the patch process after each major Drupal release or change in your hosting, so the runbook stays accurate.