Drupal security updates, in plain English

How Drupal security updates work

What is a security update?

A Drupal site is three kinds of software. There is Drupal itself, which developers call core. There are the add on modules that give the site its features: the form builder, the search, the login with Microsoft, the page that pulls your members from the CRM. And there is the theme, which is the design: the templates, the styles and the small scripts that make the site look the way it does. All three get security updates. Software has holes. Most are harmless. Some let a stranger do something they should not be able to do, like read a page meant for members, change the text on your homepage, or run their own code on your server.

When someone finds a hole like that, they report it privately to Drupal. The module's maintainers write a fix. On a Wednesday the fixed version is released, together with a notice that says what the hole was, how bad it is, which versions are affected and which version fixes it. The notice is called a security advisory. Applying the fixed version to your site is the update.

Core updates are the ones to watch most closely. A hole in a module affects the sites that use the module. A hole in core affects every Drupal site in the world at once, which is why the two worst incidents below were both core. Themes are the quietest of the three, a handful of advisories a year, but a theme can run scripts in a visitor's browser, so a hole in one is not nothing.

The important word is apply. Drupal does not update itself. Your hosting company keeps the server running and, with a few managed Drupal hosts excepted, does not touch your modules. Someone has to do it, and that someone has to know the advisory exists.

Who publishes them?

The Drupal security team. It is a group of volunteers from the Drupal community, many of them developers at agencies and hosting companies, who give part of their week to this. They receive the private reports, work with maintainers on the fixes, decide the rating, and publish the advisories on drupal.org on Wednesdays. Core fixes are usually announced a week ahead, on the third Wednesday of the month, so developers can plan. Fixes for modules and themes arrive without warning, on any Wednesday.

Core is always covered. Not every module or theme is. A maintainer has to opt in to security coverage, and drupal.org marks the ones that have. When a maintainer stops responding to the team, the project is marked unsupported in an advisory of its own. No fix is coming for those, and the advice is to remove the module or take over maintaining it. The cards on this site say "no fix is coming" when that happens.

Why do they matter?

Because the advisory is public. The moment it is published, anyone can read what the hole is and which sites are likely to have it. Drupal sites are easy to identify from outside, and so is the list of modules a site uses. People write automated tools that look for sites with the hole and try the door.

The two worst Drupal holes show how fast this moves. In October 2014 a hole in Drupal 7 core was being used within hours of the advisory, and the security team later said that any site not patched within about seven hours should be treated as compromised. In March 2018 another core hole was being used against sites around the world within a few weeks, mostly to install software that mined cryptocurrency on other people's servers. Most weeks are far quieter than that. Applying updates promptly is what keeps the quiet weeks quiet.

For UK organisations there is a formal version of this. Cyber Essentials requires high and critical security fixes to be applied within 14 days of release, and software that is no longer supported to be upgraded, removed or isolated. Funders and partners have started asking for the certificate.

What do the ratings mean?

Every advisory carries a rating decided by the security team from a short checklist: how hard the hole is to use, whether the attacker needs a login and what kind, whether they could read data, whether they could change it, whether it has been seen in use, and how many sites are likely to be affected. The answers add up to a score, and the score gives one of five ratings.

• Highly criticalAn outsider could take over the site, usually without logging in. Fix today.
• CriticalSerious damage is possible. Cyber Essentials expects a fix within 14 days. Do it this week.
• Moderately criticalReal but limited, often needing a login or an unusual setup. Include in your next routine update, within the month.
• Less critical and not criticalMinor, or hard to use. Fix with the next routine update.

These pages use the same colours everywhere: red for the top two, amber for the middle, green for the bottom two.

Does every advisory apply to my site?

No. A core advisory applies to every Drupal site, so when one appears it is for you. Most weeks there isn't one, and most of the module and theme advisories are for things your site does not use. Of the ones that are for modules you do use, some only apply in a particular configuration, which each card spells out under "does it apply to you". The question you cannot skip is which modules your site runs. If nobody can tell you, that is the first thing to fix, and it takes a developer about ten minutes.

What should I do?

Do this now

• Find out who applies updates to your site, and whether anyone actually is. An agency that built the site years ago may assume you have someone else.
• Ask them which version of Drupal the site is on, which modules and theme it uses, and when updates were last applied.
• If the site is on Drupal 10, note that it stops receiving security fixes on 9 December 2026.

Do this when you can

• Agree a routine: critical fixes within 14 days, everything else monthly. Write it down somewhere both of you can see it.
• Check the week's issue on a Thursday. If there is a core release, or a module or theme you use is rated critical or above, forward the "tell your developer" line.
• If you hold Cyber Essentials, keep the dates. The assessor will ask.

Where to go for more

• The advisories themselves, written for developers: drupal.org/security.
• Drupal's own definition of the ratings: security risk levels defined.
• Cyber Essentials requirements: NCSC.
• What the Drupal 10 end of life means for your site: 9 December 2026.

The facts on every card on this site come from the advisory. The plain English is mine, with help from a language model, and I read each card before it is published.