Here’s the part that surprises people: a security update doesn’t just fix a hole — it announces one. Every security release ships with an advisory describing roughly what was vulnerable. From that moment, the race is on: sites that apply the patch close the door; sites that don’t are now running a documented, publicly known vulnerability.

“Nobody would bother hacking us” isn’t how it works

Attacks on small websites aren’t personal and aren’t manual. They’re automated scanners sweeping the whole internet for specific unpatched versions, around the clock. Your site isn’t targeted because it’s valuable — it’s a doorknob being tried because trying every doorknob is free. Drupal’s 2018 “Drupalgeddon 2” release made the timeline famous: mass exploitation of unpatched sites began within weeks of the advisory, against sites of every size and obscurity. The pattern hasn’t changed since; only the speed has.

That’s why “the site still works fine” tells you nothing. A vulnerable site works fine right up until it doesn’t — and a quietly compromised one often keeps working fine afterward, serving spam or mining credentials while looking perfectly normal from the front.

What good patching looks like

Three tiers of urgency. Critical security releases: applied within days — Drupal helpfully pre-announces its security windows (Wednesdays), so a maintainer can literally have the calendar marked. Routine security releases: within the month. Everything else: on a steady monthly rhythm, tested on staging first.

And underneath it all, the one nobody sees: PHP itself. Each PHP version gets security coverage for roughly three years, then goes end-of-life; a site on an EOL PHP has an unpatched foundation no CMS update can compensate for.

If you don’t know when your site was last patched — or your platform stopped receiving patches entirely — that’s the first question worth answering, and it takes a maintainer about ten minutes to check.