Drupal security is one of the few parts of the open source CMS world where the published process is better than the platform’s reputation. The Drupal Security Team runs a fixed disclosure schedule, scores every advisory on a documented numerical scale, and coordinates fixes across core and tens of thousands of contributed projects.

The record in the field is worse than that process deserves. Drupal sites do get compromised, and the cause is almost never that nobody knew. The advisory was published, on time, on a Wednesday. The patch reached production the following week. That gap is the subject of this article, and hardening, firewalls and file permissions all exist to make it survivable or to shorten it.

Your risk is set by how fast you patch, not by which modules you happen to run. Core advisories land in a monthly Wednesday window and contributed project advisories every Wednesday, each scored from 0 to 25 on a published scale. Highly critical core flaws have been exploited within hours of disclosure: after the 2014 SQL injection advisory the official guidance was to treat any site not patched inside seven hours as already compromised. A site that cannot deploy a core patch within a working day carries nearly all of the risk that exists.

How the Drupal Security Advisory Process Actually Works

Most people running a Drupal site have never read the process documents, which is a shame: they tell you exactly how much warning you get, in what form, and on which days.

The release windows

The security team publishes on a calendar. Contributed project advisories go out every Wednesday. Core has a bug fix and feature release window on the first Wednesday of the month and a security release window on the third, as set out in the security release timing documentation. A window is not a promise that anything will ship; it exists so administrators know which days to watch.

Occasionally there is advance notice. Before a highly critical core release the team may publish a public service announcement, usually on the Monday. PSA-2026-05-18 did that for the release of 20 May 2026, naming a window of 17:00 to 21:00 UTC and telling owners to update to the latest patch release on their branch first, so upgrade problems surfaced early. Two days is the most warning you will get.

Core advisories and contributed project advisories

These are two systems with different guarantees. Core advisories cover the supported minor branches, two at a time, the most recent and the one before it. In practice the core release schedule means 11.4.x and 11.3.x, with 10.6.x still covered while Drupal 10 runs to end of life on 9 December 2026. As of early September 2026 the current releases are 11.4.5, 11.3.16 and 10.6.15. Drupal 12.0.0 and 11.5.0 are due in the week of 7 December 2026, at which point support for 11.3.x and 10.6.x ends.

Contributed coverage is opt in and conditional. Advisories are only issued for stable releases in supported major branches of projects whose maintainers applied for and were granted coverage, under the security advisory process and permissions policy. A module on an alpha, beta or release candidate version sits outside the system, as does one whose maintainer never opted in. Neither fact is visible from the admin interface while the site runs normally.

The volume is the real workload. On Wednesday 26 August 2026 the team published ten contributed project advisories in one day, all moderately critical. A site running sixty modules will be named several times a year, and that stream costs more over time than the core emergencies.

The risk score, and why it is not CVSS

Every advisory carries a number out of 25. The scale is based on the NIST Common Misuse Scoring System, NISTIR 7864, and is documented on the security risk levels page. Six metrics feed it: access complexity, authentication required, confidentiality impact, integrity impact, whether a known exploit exists, and target distribution. The bands run not critical at 0 to 4, less critical at 5 to 9, moderately critical at 10 to 14, critical at 15 to 19 and highly critical at 20 to 25.

Because target distribution is part of the score, a flaw that only bites an uncommon configuration lands lower than it would under CVSS. SA-CORE-2026-005 of 17 June 2026, a PHP object injection issue tracked as CVE-2026-55803, scored 18 and was rated critical rather than highly critical for exactly that reason.

When a Contributed Module Becomes Unsupported

The security team cannot force a volunteer maintainer to fix anything. When a maintainer stops responding, the documented procedure is to mark the project unsupported after repeated attempts at contact. The project page then warns site owners to choose an actively maintained alternative, or to pay somebody to fix the bug so the module can be republished.

That advice is correct and expensive, because by the time a module is marked unsupported it is usually load bearing, and replacing it means data migration, template changes and a full regression test. The cheap moment to act is the release before abandonment, when the maintainer has gone quiet but nothing has broken, and almost nobody looks then.

Drupal 7 Is End of Life, and Extended Support Is Not the Same as Secure

Drupal 7 reached end of life on 5 January 2025, confirmed in PSA-2025-01-06. After that date the security team stopped providing support and advisories for Drupal 7 core and for its contributed modules and themes. The announcement was explicit that Drupal 7 security issues may now be disclosed publicly without coordination, and that zero days may occur.

There is a commercial extended support market. The Drupal Association certified vendors, including HeroDevs and Tag1 Consulting, under an Extended Security Support Provider Program, and they do produce patches. That is better than nothing, but it is not the same as being supported. The vendor patches core and a defined set of modules it has chosen to cover, on its own timetable, for customers who pay. The rest of the ecosystem your site depends on is out of scope.

An unsupported CMS is also hard to defend in a supplier assurance questionnaire or to an insurer after an incident. Our guide to Drupal migration costs, options and deadlines sets out what the exit costs.

The Historical Pattern: Drupalgeddon and What Followed

Three incidents shaped how the community thinks about patching speed. Each was an injection or remote code execution flaw in core, and each saw mass automated exploitation within hours or days.

The seven hour window of October 2014

The original Drupalgeddon was SA-CORE-2014-005, published on 15 October 2014. CVE-2014-3704 was a SQL injection flaw in the Drupal 7 database abstraction layer, exploitable by anonymous users, scoring the full 25 out of 25. Every Drupal 7 site below 7.32 was affected.

The follow up made it a landmark. PSA-2014-003 told owners that automated attacks had begun compromising unpatched sites within hours of the announcement, and that they should assume any site not patched by 23:00 UTC that day, seven hours after publication, had been compromised. Not might have been. Had been. It warned that attackers may have taken all the data and installed backdoors, which is what turns a patching problem into an incident response problem.

Drupalgeddon 2 and 3

SA-CORE-2018-002, published on 28 March 2018, was CVE-2018-7600: a remote code execution flaw across multiple subsystems in Drupal 7 and Drupal 8, scored 24 out of 25. It affected Drupal 7.0 through 7.57 and the 8.x branches up to 8.5.0, and public exploits followed within about a fortnight.

Four weeks later SA-CORE-2018-004 landed on 25 April 2018. CVE-2018-7602 was another remote code execution issue in related code, scored 20 out of 25, and the advisory stated it was already being exploited in the wild. The interval is the lesson: sites that patched in March and then stopped paying attention were exposed again in April.

May 2026, and what has not changed

The pattern is not history. SA-CORE-2026-004 was published on 20 May 2026: CVE-2026-9082, a SQL injection flaw affecting sites on PostgreSQL, scored highly critical at 23 out of 25, covering every branch from 8.9 up to 11.3.9. On 22 May at 04:30 UTC the advisory was amended to record exploit attempts detected in the wild, under 48 hours from publication to observed attacks.

None of that criticises the security team. They gave two days of notice, shipped inside the announced window, and updated the advisory when the picture changed. The failure mode sits on the operator side: no rehearsed route from an advisory to a patched production site.

Where Drupal Security Actually Fails in Practice

Core gets the headlines and is the least of it. In the sites we audit the finding that matters is rarely an unpatched core release, because core updates appear in the admin interface and somebody notices. The exposure sits elsewhere.

The module inventory nobody has

A typical mid sized Drupal site runs between forty and eighty contributed modules, each a separate maintainer with a separate cadence. The question almost nobody can answer on demand is which of them still have an active maintainer, which are covered by the advisory policy, and which have had no commit in two years. That list takes an afternoon to produce.

The custom module nobody owns

The most common serious finding is a custom module written by a contractor who has left. It usually does something integration shaped: a CRM feed, a bespoke form handler, a payment callback. It was written against an older API, has no tests, and nobody on the team can say what it validates. Custom code sits outside the advisory system by definition: no Wednesday email will tell you it contains a SQL injection, and the status report will show everything as up to date. It needs the review discipline of any other software development work.

The stack underneath Drupal

Drupal is PHP, and PHP versions reach end of life on their own schedule. A site can be fully patched at the CMS level and still run on a PHP version that stopped receiving security fixes a year ago, because hosting was never part of the maintenance conversation. The guidance on file permissions and ownership rests on the principle that the web server must not be able to write the files it executes, yet many sites run with a writable code directory because it simplified a deployment script.

How a Drupal Site Should Actually Be Patched

The answer is dull, which is why it goes unimplemented. No tooling removes the need for a rehearsed route from advisory to production, and building it once costs less than the first emergency.

The Composer workflow

Everything from Drupal 8 onwards is a Composer project. Update the core packages with their dependencies, then apply database updates and rebuild the cache:

1composer update "drupal/core-*" --with-all-dependencies
2drush updatedb
3drush cache:rebuild

Drush can be swapped for update.php. Check the status report before and after. The important part is not the commands but that they run somewhere other than production first.

Staging that is actually a copy

A staging environment helps only if it mirrors production: the same module set, the same PHP version, a recent sanitised database. A stale staging site produces a green result that means nothing, which is worse than no staging at all because it manufactures confidence.

The sequence is to pull production down to staging, apply the update, run database updates, walk the pages and forms that make the site commercially useful, then deploy. With a working pipeline that is 45 to 90 minutes. Without one it is a day and a half.

Automation, and its limits

Automated dependency updates help most with the contributed module stream, the high volume, low severity end. A bot opening one pull request per module update, with tests running against each, turns a monthly manual sweep into a review queue. Core is moving the same way: the Automatic Updates work is built on the Package Manager module, which ships in core but is still experimental.

The realistic time budget

A maintained Drupal site costs roughly half a day a month in routine module updates, plus one to three hours for each core security release that applies. Add contingency for the one or two highly critical releases a year that must be done the same evening. That is the number most in house teams never budgeted, which is why the work slips.

Hardening Beyond Patching

Hardening does not replace patching. It reduces how many published vulnerabilities are exploitable on your installation, and buys time when a patch cannot go out immediately. The Drupal specific items are cheap and permanent.

Trusted hosts and the file system

Set trusted host patterns. Drupal uses Symfony’s trusted host mechanism, configured through the trusted_host_patterns setting in settings.php as regular expressions matching the domains your site answers on. Requests with any other Host header are rejected with a 400. Without it an attacker can poison password reset links and cached absolute URLs using a forged header.

Use the private file system for anything that should not be publicly readable, and make sure PHP cannot execute inside the public files directory. Drupal ships an .htaccess file that blocks execution under Apache, but nginx has no equivalent drop in file and the rule must be written into the server configuration by hand. Sites that moved from Apache to nginx years ago frequently lost that protection silently.

Then apply the ownership model: directories at 750, code files at 640, the files directory writable by the web server and nothing else, and settings.php readable only by its owner.

Permissions, admin routes and the review pass

Restrict the administrative routes. There is no reason for the login and admin paths on a site whose editors work from three offices to be reachable from the whole internet, and an IP allow list or an authenticating proxy removes a class of credential attack.

Then audit the permission grid. It grows with every module installed, and the finding is nearly always the same shape: an editor role that can administer text filters, or a role that can execute arbitrary PHP. Either converts a stolen editor password into remote code execution, so a phishing email becomes a server compromise.

Run the Security Review module before arguing about anything else. It automates the checks that are tedious by hand: file system permissions, unsafe text formats, PHP or JavaScript in content, error reporting exposure, upload extensions, failed logins, dangerous permissions and trusted host configuration. Version 3.1.3, released in January 2026, supports Drupal 10.3 and above alongside Drupal 11.

What a firewall buys you and what it does not

A web application firewall is a virtual patch, and that is how the Drupal Association positions Drupal Steward, the paid service it runs with the security team. It applies network level mitigation for certain highly critical core vulnerabilities, protecting a site during the gap between advisory and deployment. Published pricing is under 20 US dollars a month for a site serving a million HTTP requests, and under 100 US dollars above ten million.

The limits are stated by the project itself: not every issue can be mitigated this way, and the mechanism only covers vulnerabilities exploited through a request to the web server. A firewall does nothing about a compromised administrator password, a malicious module update or a flaw in your own code. Treat it as insurance for the patching window, not a reason to widen it, which is the view we take in our WordPress security hardening checklist.

What a Compromise Costs and What Recovery Looks Like

Recovery from a Drupal compromise is not a patch. Once an attacker has achieved code execution the working assumption is that files were written, credentials were taken and a persistence mechanism was installed, which is what the security team told Drupal 7 owners in 2014. Cleaning a compromised site in place is guesswork dressed as remediation.

The defensible approach is to rebuild the codebase from version control onto a new host, restore only content and uploaded files after inspection, rotate every credential the site held, and preserve the compromised disk image rather than deleting it. That last step is the one people skip under pressure, and it is the only evidence of what happened.

The commercial cost is rarely the rebuild. It is the downtime, the forensic work, the customer communication and the regulatory process. A rebuild under incident conditions is typically 5,000 to 20,000 pounds of engineering, usually the smallest line in the total.

UK data protection obligations

If personal data was or may have been accessed, the UK GDPR clock starts when you become aware, not when you finish investigating. The ICO breach guidance requires a notifiable breach to be reported without undue delay and no later than 72 hours after becoming aware of it, and if you take longer you must give reasons. Where the breach is likely to result in a high risk to the rights and freedoms of individuals, you must also inform those individuals without undue delay.

The ICO is clear that an incomplete picture is not a reason to miss the deadline: report what you know and follow up. Failing to notify when required can attract a fine of up to 8.7 million pounds or 2 per cent of global turnover.

That clock is why the forensic question matters. A site with no logs and no record of which version was running cannot say what data was accessed, so it ends up reporting the worst case. That is the argument for a website security audit before an incident rather than after one.

What a Drupal Security Retainer Should Include

A retainer that only promises to apply updates is not worth buying, because applying updates is the easy half. What you are paying for is the response path on the day a highly critical advisory lands, and the deliverable that proves it works is a rehearsal.

The scope worth paying for covers monitoring the advisory feeds for your exact module set, a monthly patch cycle with staging, testing and a rollback plan, an agreed out of hours response window for highly critical core releases, a quarterly review of abandoned modules with replacements costed, PHP and platform version tracking, and an annual configuration review.

In the UK, monitoring only arrangements sit at roughly 250 to 450 pounds a month. A retainer including staging, testing and deployment for a mid sized site is more like 600 to 1,500 pounds a month, scaling with the number of modules and the volume of custom code, because both decide how much regression testing each cycle needs. Against agency day rates of 600 to 900 pounds, the top of that band buys about two engineer days. Our note on Drupal developer rates and vetting has the numbers.

Closing the Window

Drupal gives you more warning and more structure than almost any comparable platform. The advisories run to a schedule and the highly critical releases arrive with two days of notice. None of that helps a site that takes a fortnight to deploy a one line patch.

Mecanik handles Drupal patching and hardening as part of our website security audit and ongoing software development work. The first engagement is usually an inventory rather than a fix, because most sites cannot say which of their modules are still supported. If you are weighing up the platform itself, our 2026 guide to Drupal web development covers that.

Frequently Asked Questions

How often does Drupal release security updates? Contributed project advisories are published every Wednesday, and Drupal core has a security release window on the third Wednesday of each month, although a window does not guarantee a release. Highly critical core releases are usually preceded by a public service announcement about two days beforehand, naming the date and time window.

What does a Drupal security risk score of 20 out of 25 mean? Drupal scores every advisory from 0 to 25 using a system based on the NIST Common Misuse Scoring System, combining access complexity, authentication required, confidentiality and integrity impact, whether a known exploit exists, and how many sites are affected. Anything scoring 20 to 25 is highly critical, which means patch that day.

Is Drupal 7 still safe to run in 2026? No. Drupal 7 reached end of life on 5 January 2025 and the Drupal Security Team no longer issues advisories for its core, contributed modules or themes, so flaws can be disclosed publicly with no coordinated fix. Commercial extended support covers a defined set of code on the vendor’s terms, which helps during a migration but is not the same as being supported.

How quickly do attackers exploit a Drupal vulnerability? Within hours, in the worst cases. After the October 2014 SQL injection advisory the Drupal Security Team told owners to assume any site not patched within seven hours had already been compromised. In May 2026, exploit attempts against a highly critical core SQL injection were detected in the wild less than two days after publication.

Does a web application firewall make Drupal patching unnecessary? No. A firewall such as Drupal Steward provides a virtual patch for certain highly critical core flaws exploited through a web request, which buys time during the deployment window. It cannot help with a stolen administrator password, a compromised module or a flaw in your own code, so it reduces the risk of the gap rather than closing it.