What actually happens when a Drupal security update gets skipped

Skipping a security update is rarely a deliberate decision. It's usually a deferral. The notification arrives, it gets noted, and it sits in the backlog alongside everything else that needs doing. There's no immediate consequence. The site carries on as normal. Nobody calls to report a problem.

This is what makes missed security updates genuinely tricky. The risk doesn't announce itself. It accumulates quietly until it doesn't.

Here's what actually happens in the gap between a security update being released and a site applying it.

Step one: the vulnerability becomes public knowledge

When Drupal publishes a security advisory — an official announcement that a vulnerability has been found and a fix is available — it publishes full details. The version affected, the nature of the flaw, the severity rating. Everything needed for a site owner to know they need to act is also everything needed for an attacker to know where to look.

This is an unavoidable trade-off. The only way to tell people to update their sites is to tell them what the problem is. But that same information is public, searchable, and widely read by people with no interest in helping you patch your site.

Step two: automated scanners get to work

The internet runs on automated tools. Within hours of a Drupal security advisory being published, scanning tools start probing websites across the internet, looking for the version numbers that indicate an unpatched installation.

Your site doesn't need to be specifically targeted. These tools don't work that way. They sweep broad ranges of IP addresses and domains, checking version signatures and known vulnerable endpoints. If your site is publicly accessible — which it is — and running an unpatched version, it will appear in those results.

You won't know this is happening. There's no visible sign of it. It looks like ordinary web traffic.

Step three: exploits get developed and shared

Once a vulnerability is public, security researchers and attackers alike start working out exactly how to exploit it. For straightforward vulnerabilities, working proof-of-concept exploits — essentially ready-to-use attack tools — can be published within 24 to 48 hours.

These aren't hidden in obscure corners of the internet. They circulate in security communities and forums. A person with modest technical skills and a list of unpatched sites has everything they need.

The gap between "advisory published" and "working exploit available" has shortened considerably over the past decade. The assumption that you have a week or two to get to it is not well-founded.

Step four: the update gets harder, not easier

There's a secondary effect that rarely gets mentioned. The longer you leave a security update, the more likely it is that applying it becomes complicated.

Drupal releases are cumulative. If you skip one update, the next one builds on it. After several skipped updates, you may find yourself looking at a jump across multiple versions rather than a single straightforward update. Each skipped update adds a small amount of technical debt — compatibility considerations, testing requirements, potential conflicts with other software on the site.

This is the paradox of deferral. Applying updates promptly is low-friction. Applying them after six months of skipping is real work.

What about contrib modules?

Most conversations about Drupal security updates focus on Drupal core — the main Drupal software itself. But the same situation applies to contrib modules — the add-ons and extra features your site uses on top of Drupal, such as contact forms, media libraries, e-commerce tools, or editorial workflows.

Contrib modules have their own security advisories. They're tracked separately. A site with 30 contrib modules installed has 30 potential sources of security vulnerabilities, each with their own release schedule.

Core updates tend to be noticed. Contrib module updates are easier to miss, which is part of why they're also a common point of exploitation.

The bit that actually resolves this

The underlying problem is that security updates compete for attention with everything else. That competition is reasonable — everything on your to-do list feels more urgent than an advisory about software most people never directly interact with.

The practical resolution is removing the competition. Security updates applied as a recurring, dedicated task — rather than something that gets fitted in when there's time — is the difference between staying current and drifting behind.

That's what Nodely does. We track advisories for Drupal core and for the contrib modules on your site, test updates before deploying them, and apply them within days of release. No backlog. No "we'll get to it." Just a site that stays current.