Yesterday afternoon I opened drupal.org/security, like every Wednesday, and started scrolling. And kept scrolling. Thirty-nine security advisories for contributed modules, from SA-CONTRIB-2026-254 to 292, all dated October 28.
The first one on the list was enough to ruin a quiet dinner: Commerce Core, Highly critical, 21 out of 25, with the little footnote that it's already being exploited. Below it came three advisories for Commerce Stripe, Single Content Sync with remote code execution, CAPTCHA, Field Permissions, S3 File System, OpenID Connect... and eight for the AI module itself, and yes, the irony isn't lost on me. To top it off, three projects flagged straight up as unsupported, which is the polite way of saying "uninstall it".
The funny thing is it didn't surprise me. The Wednesday before, there had been 34. Two weeks earlier, core had its own remote code execution in Field UI. And in between, PHP shipped emergency patches for PHP2Shell. A couple of years ago, a week like that would have been the talk of every agency Slack. Now it's just another Wednesday.
These numbers aren't a bad streak anymore
Look, numbers can be misleading, but these don't leave much wiggle room. Between 2019 and 2024, contributed modules ranged from 38 to 96 advisories a year. In 2025 there were 126. In 2026, as of October 28, we're at around 290, and there are still nine weeks left in the year.
Core tells a similar story on a different scale. We're at 16 advisories this year, double what we had in 2024 and in 2025. And these aren't filler advisories: in May there was a Highly critical SQL injection for sites running PostgreSQL that started getting attacked within days and ended up in CISA's catalog of known exploited vulnerabilities.
If you look at it month by month, the change even has a date. Up until May, contrib was running at between 3 and 12 advisories a month. Since June it hasn't dropped below 25. September closed with 72, including a single day with more than twenty advisories just for Webform, and October is already past a hundred and it isn't over yet.
It's not that Drupal got worse
The code in those modules didn't break this summer. Those bugs had been sitting there for months, some of them for years. What's changed is how cheap it is to find them.
In May the Drupal Association got funding from Alpha-Omega, the Linux Foundation project, to set up an AI-assisted security initiative. Six weeks in, they were already talking about more than ten published advisories and more than thirty issues filed. And they said something I think is the most honest part of the whole thing: the bottleneck is no longer finding bugs, it's having people to validate and fix them.
Drupal isn't the exception either, not by a long shot. In the Linux kernel, maintainers have gone from getting two or three reports a week to five or ten a day, and recent releases are hitting around 1,500 CVEs each, most of them found with AI tools. Back in May, Linus Torvalds went as far as saying the kernel security list had become almost unmanageable. And PHP2Shell, last week's PHP thing, was a bug that had been in the engine for over a decade and came to light with help from AI.
So the pattern repeats across the whole stack. When it's not PHP, it's Drupal, and when it's not Drupal, it's the kernel of the server everything else runs on.
The other side has AI too
If this were just "more bugs get found and fixed", it'd almost be good news. The thing is, the same tool the security team uses to find a flaw is available to anyone who wants to exploit it.
With the core SQL injection back in May, a security company ran the experiment of taking the public patch and leaning on an AI model to build an exploit. It took them 51 minutes. PHP2Shell was even worse: Amazon spotted exploitation attempts on its honeypots on October 17, four days before there was a patch, and the details ended up leaking ahead of schedule, to the point that PHP had to move its release forward. And yesterday's Commerce advisory went out already saying there was active exploitation.
Every security advisory is a patch and a map at the same time. It tells you what to update, and it tells someone else exactly where to look. There used to be a window of days, sometimes weeks, between an advisory coming out and something that actually worked showing up. That window has pretty much disappeared.
After Drupalgeddon, back in 2014, the security team went as far as saying that any site not patched within seven hours should be assumed compromised. At the time, a lot of people thought that was an exaggeration. Today it sounds almost generous to me.
What worries me most isn't core
We've got core fairly under control. It's the first thing everyone updates, and it's almost always a composer update with no surprises. What worries me is everything around it.
I worry about the modules that got installed four years ago for one specific feature and that nobody has looked at since. Yesterday three projects lost support: there's a known flaw, nobody's going to fix it, and the only way out is to remove them. I worry about Stage File Proxy, which got a critical advisory and is a module meant for development, but which I've found enabled in production more times than I'd like. And I worry about fixes that don't quite fix things, like Media Alias Display, which got a second advisory yesterday because the previous week's patch didn't properly close the vulnerability.
And then there's the part that isn't even Drupal. The PHP on the server, the kernel, the container's base image. PHP2Shell affected any PHP website, whatever Drupal version it was running. According to the figures going around that week, almost three out of four services that exposed their PHP version were on 8.1 or older, versions that no longer get official patches. At that point it doesn't matter how tidy your composer.lock is.
So what do I do about it?
First off, accept that this isn't going to slow down any time soon. Treating maintenance as "a monthly check-up" doesn't make sense anymore when something lands every Wednesday and, every now and then, something big drops on a Tuesday or a Thursday.
What works for me on my projects is making sure I don't have to remember to check. A composer audit in the pipeline, a scheduled drush pm:security that flags anything pending, and Update Status emails turned on, even if that feels a bit old school. None of this is new or fancy. What's new is that it's no longer optional.
Finding out is the easy part, of course. The hard part is daring to update quickly. And here's the catch: hardly anyone updates late out of laziness. They update late because they don't trust that nothing will break. If you don't have a staging environment and tests that give you some peace of mind, every patch is a gamble, and people naturally put off gambles. To me, that's what really separates a site that can keep up with this pace from one that can't.
My rule for Critical and Highly critical advisories is to apply them the same day. If for whatever reason that's not possible, the advisory itself usually includes a mitigation, like uninstalling a module or disabling a specific option, and that gets done right away. Waiting until Monday to see what happens isn't a strategy anymore.
It also helps to have a smaller surface. Every contributed module is one more front to watch, so if something is enabled and not being used, or does what core already handles today, it goes. That was always good practice, but now you can see it on the calendar. Same goes for the server: automatic OS security updates, a supported PHP version, and rebuilding images whenever a patch comes out.
The last part is more of a conversation with clients than a technical thing. A site that gets critical patches the same day costs more than one that gets reviewed every quarter, and you have to explain it that way, without being dramatic, but without selling it as something that takes five minutes either.
The new normal
Some people think that in a year or two, once AI has swept through most of the old bugs, software will be a lot more robust and the volume will go down.
But AI doesn't just find bugs, it also writes a huge amount of new code, and the fact that eight of yesterday's advisories were for the AI module says something about how fast everything is being built. I might be wrong, for the record, but I have a hard time seeing the Wednesday list go back to 2023 numbers.
What I am sure of is that maintaining a Drupal site is no longer about updating when it suits you. It's about updating when the patch is out. Next Wednesday I'll open drupal.org/security at the same time again, and I'm not expecting a short list.