Most Drupal site owners I talk to handle Drupal security updates the same way. These are the fixes the Drupal Security Team publishes for core and contributed modules. A developer sees the security advisory. A ticket goes into the next sprint. The patch goes live a few days later, sometimes two weeks later.
For years that was enough. Not anymore.
The reason is simple: AI. A language model can read a security patch and write a working attack based on it. In May 2026 it took researchers 51 minutes.
On Drupal Slack I saw an even shorter version: “it takes less than 10 minutes to create an exploit from any SA.”
I take that seriously. In this article I show what changed and how to prepare for every security release. I also explain why I think security updates are no longer a developer task. They are a job for a support team with a contract.
In this article:
- What changed in Drupal security between 2018 and 2026?
- Why is a security advisory now an exploit recipe?
- What do faster exploits mean for your Drupal site?
- How to prepare for every Drupal security update?
- Why are Drupal security updates a support job, not a developer task?
- My recommendation
What changed in Drupal security between 2018 and 2026?
Two critical Drupal core vulnerabilities show it best. Eight years and one tool separate them: AI.
In March 2018 Drupal published SA-CORE-2018-002, known as Drupalgeddon 2. Public exploit code took about two weeks to appear. Hosting companies had time to add protection. Site owners had time to plan the update.
In May 2026 Drupal published SA-CORE-2026-004. It was an SQL injection in core, CVE-2026-9082. Researchers at Miggo Security described how they built an exploit for it. From spotting the patch to a working exploit took 51 minutes. They used Claude and spent less than 10 dollars on tokens. A human still had to nudge the model at one point.
Two days later Drupal updated the advisory: “exploit attempts are now being detected in the wild.” CISA added the flaw to its Known Exploited Vulnerabilities catalog. Imperva counted more than 15,000 attack attempts. They hit almost 6,000 Drupal sites in 65 countries.
Two weeks in 2018. 51 minutes in 2026. That is the whole story.
The Drupal Security Team sees the same thing. In PSA-2026-10-12, about a critical core release, it wrote that “exploits might be developed within hours or days.” It also asked site owners to reserve time for updates on release day.
Read also: Guide to avoiding Drupal security problems: best practices and proactive measures
Why is a security advisory now an exploit recipe?
Every security release ships the fix. The fix is a code diff. The diff shows which function was vulnerable. It also shows which input it did not check.
Before AI, turning a diff into an attack took a skilled person and days of work. Now a model reads the diff and finds the vulnerable path. It writes the request and tests it on a fresh Drupal install. A human fixes a few mistakes along the way. The skill barrier is gone. The cost is lower than a lunch.
Attackers do not pick targets by hand either. They scan the internet for Drupal sites, check the version and fire. That is why Imperva saw thousands of attempts within days.
So the question is no longer “will anyone bother to attack us?”. The question is “how many hours after the release will our patch be live?”.
What do faster exploits mean for your Drupal site?
I see three consequences.
The release window is your deadline. Drupal core security releases come out on Wednesdays, in an announced window. If your update goes live on Thursday, your site stays open for a full day. Scanners are already running by then.
You cannot patch an unsupported version. Only supported Drupal branches get security fixes. In October 2026 those were 11.4.x, 11.3.x and 10.6.x. Drupal 10.5, 11.2 and older versions are end-of-life and get no fixes. Is your site on one of them? Then no support contract will help you on release day. First you need a Drupal version upgrade to a supported branch.
Core is only half the job. On 9 October 2026 the Security Team published 26 contrib advisories in one day. One of them was highly critical. Every contributed module on your site is a possible way in. Someone has to read those advisories, check which apply to you and update.
Drupal Steward gives some protection. The Security Team says it plainly, though: not against all exploits. A web application firewall buys you hours. It does not replace the patch.
Read also: How to upgrade Drupal 8, 9 or 10 to Drupal 11
How to prepare for every Drupal security update?
Most of this work happens before release day, not during it. This is what I would do if I owned a Drupal site:
- Stay on a supported branch. Check your version now, not on release day. If you are on an unsupported version, plan the upgrade right away.
- Keep up with the latest patch release. The Security Team asks for this before every critical release. Thanks to it, a security update is a one-line change. Not a fight with Composer dependencies.
- Keep staging in line with production. Same PHP version, same database, same modules. Run your tests regularly, so you know what “green” looks like.
- Decide who deploys and who approves. By name, with a backup person. Core releases usually land in the European afternoon and evening. Often after your team has gone home.
- Prepare a rollback. A database backup and a tagged release you can return to in minutes.
- Watch the logs after deployment. Look for unusual requests, new admin users and PHP files in the files directory.
- Do not forget contrib. Module advisories come out every week, not only with core releases.
None of this is hard. All of it needs time, access and someone who knows the project. That is the real problem.
We cover the update process in more detail in Drupal update: how to properly take care of it?. If you do not know the state of your site, start with a Drupal security audit.
Why are Drupal security updates a support job, not a developer task?
A ticket in the next sprint worked when an exploit took two weeks. It does not work when it takes 51 minutes.
Do the math. An attacker needs under an hour. If your update process takes three days, you lose every time. You win only if the patch is live within hours of the release. Every time, without a meeting.
Your developers can run Composer. Skills are not the issue. Capacity and ownership are:
- Someone watches the Drupal security calendar and the advisory feed every week.
- Someone keeps staging healthy, so a patch can be tested in minutes.
- Someone has hours reserved on release day, not a full sprint backlog.
- Someone takes responsibility when the update breaks a module at 20:00.
I often see the opposite. The previous agency “will take a look.” Or the one person who knows the site is on holiday. We describe more of these situations in 10 common Drupal maintenance problems and how to avoid them.
You need a team that owns the site. Not a ticket that waits for one.
My recommendation
Treat Drupal security updates as a service with a contract, not as a backlog task. That means reserved hours, a named team and an agreed response time.
This is what our Drupal support is built for. You get a monthly package of guaranteed hours and a team that knows your project. You also get a clear process for critical release days.
What it means in practice:
- Security update monitoring. We follow core and contrib advisories. We tell you which ones apply to your site before you ask.
- Reserved capacity. The hours are planned in advance. A security release does not compete with your sprint.
- SLA for incidents. Guaranteed response time for critical issues, from one hour in the Enterprise package.
- Environments and process. Staging and dev environments, Jira Service Desk and Slack. Estimates before work starts and a monthly report of hours used.
- No long lock-in. Three months minimum, then monthly notice.
Not sure whether you need support or a dedicated team? We compare both in Development team vs support: what web development service to choose?.
Want someone to own the security of your Drupal site?
This is how we work with Exide Group, for example. We took over their site, built on an early version of Drupal 8, where installing security patches without regressions was hard. We cleaned up the code and introduced Composer, test environments and Continuous Integration. Since then we have kept the site updated and kept developing it. See the details in the Exide Group case study.
We have worked with Drupal and PHP for more than 15 years. We are ISO 27001:2022 certified. That helps when your security team or procurement starts asking questions.
The next critical release will come. Talk to us about Drupal support and make security updates somebody’s job.
