A security advisory is an official announcement that a vulnerability has been found in a piece of software and a fix is now available. For Drupal, these come from the Drupal Security Team — a group of volunteers who review reported vulnerabilities, work with developers to produce patches, and then publish the details publicly so site owners know to act.
You may have seen these arrive by email with subject lines like "Drupal core — Moderately critical — Security update available." They land in inboxes, get forwarded to developers, and somewhere between the next sprint planning session and a client deadline, they quietly stop feeling urgent.
The problem is the window between an advisory going public and the first exploitation attempts is often measured in hours, not days. Understanding what actually happens when an advisory is published makes it much easier to understand why acting quickly matters.
Where security advisories come from
Most vulnerabilities are reported privately — by a developer, a security researcher, or someone who found something unexpected while testing a site. They report it quietly to the Drupal Security Team rather than announcing it publicly. The Security Team then reviews the report, confirms whether it's a real issue, assesses how serious it is, and works with the relevant developer to build a fix.
All of this happens behind closed doors. Nobody outside that group knows the vulnerability exists until the advisory is published. When the fix is ready, the advisory and the patch go out together — usually on a Wednesday.
That coordinated release is one of the things that makes Drupal's security process relatively well-run. Site owners get the patch at the same moment the vulnerability becomes public knowledge. But that moment is the same for everyone — including people looking for sites to exploit.
The moment an advisory is published, the race begins. Security researchers start studying the patch to understand what was fixed. Attackers do the same. Automated tools start scanning the internet for sites running the unpatched version. This is not a theoretical concern — it happens within hours of publication.
What the severity ratings mean for you
Each advisory includes a severity rating: Critical, Highly critical, Moderately critical, Less critical, or Not critical. These reflect how easy the vulnerability is to exploit, what an attacker could do with it, and whether they need any special access first.
"Critical" means an attacker could potentially take over your site without needing any kind of login or prior access. These are rare, but when they happen they're serious — for every Drupal site on the internet at once.
"Moderately critical" is more common. It often means the attacker needs some level of access first — a user account, for example. On many Drupal sites, registering a user account is not difficult. "Moderately critical" is not something you can comfortably ignore.
The honest answer is that the severity label tells you how urgently to act, not whether to act. All security advisories eventually get addressed if you're maintaining a site properly.
Drupal core and contrib modules — both matter
Security advisories cover two distinct areas of your site.
The first is Drupal core — the main Drupal software that everything else runs on. These advisories tend to get the most attention because they potentially affect every Drupal site on the internet.
The second is contrib modules — the add-ons and extra features your site uses on top of Drupal itself. These might be things like a contact form tool, a newsletter integration, an image gallery, or an e-commerce component. Each one is maintained separately and can have its own security vulnerabilities.
A site running 40 contrib modules has 40 potential sources of security updates. Most sites don't have someone systematically tracking all of them. This is where security gaps tend to accumulate quietly.
What "acting quickly" actually means
A site that applies a security update within 24–48 hours of an advisory is in a meaningfully different position to one that gets to it three weeks later. The longer the gap, the more developed and widely distributed the exploits become, and the more likely automated scanners have already flagged your site as a target.
The failure mode is almost never deliberate — it's process. The advisory arrives. Someone logs it. It goes into a ticket queue. It competes with everything else. Three weeks pass and nobody has done anything wrong exactly, but the window has closed.
The practical answer is treating security updates as a dedicated, recurring task rather than something that competes with other work. That might mean a developer who checks for advisories weekly. It might mean a service that monitors for you and deploys updates as they arrive.
If you're not sure which advisories currently apply to your site — or how many contrib modules you're running — that's worth finding out before someone else does. We'll run a free security check and show you where things stand.
One situation where there is no patch
Everything above assumes a patch exists. For Drupal 7 — which reached end of life in January 2025, meaning it no longer receives security updates — that's no longer true. When a vulnerability is found in Drupal 7 code, no advisory is published and no patch is released. The vulnerability simply exists, publicly, indefinitely.
This is a different situation to being behind on updates. There is no update to apply. The only resolution is migrating to a supported version of Drupal.
If your site is still running Drupal 7, the question isn't whether it's at risk. It is. The question is what migration looks like and when it makes sense to do it.