Security
Middleware is not authorization
Four NestJS advisories in seven months, all one bug: the matcher and the handler disagreed about the request. The check belongs where the data is read.
One Wednesday
On 2 September 2026 the Drupal security team published sixteen advisories for contributed projects across fourteen projects. Five were rated critical. A week earlier, on 26 August, four more had gone out.
Read the list and a pattern appears immediately. Jsonapi Role Access — critical, access bypass. Calculate Working Days — critical, access bypass. Email Verification / SMS Verification / OTP Verification — two separate critical advisories, one access bypass and one cross-site scripting. Then Monobank payment API, Media Library Importer, Mailer Plus Log, Islandora, Advanced Search, AI translate — access bypass, all of them. The August batch adds LDAP / Active Directory Integration for information disclosure and Entity PDF for access bypass.
Access bypass is not one bug that keeps recurring. It is what a module gets wrong when it adds a route and forgets that Drupal will not guess who is allowed to reach it.
Where the risk actually sits
Drupal core is among the better-audited PHP codebases in existence. It has a funded security team, a disclosure process, and a release cadence that warns you in advance. Almost nothing on the list above is core.
The site you are responsible for is not core. It is core plus twenty to sixty contributed modules, chosen over several years by people who have since left, each one adding routes, permissions, form handlers and sometimes a REST endpoint. That is the actual attack surface, and its median module has one maintainer doing it in their spare time.
This is not an argument against contrib. Drupal without contrib is not a proposition. It is an argument for knowing what you installed.
The audit, in an afternoon
List what you have and why. For each module, one line: what it does, and which feature breaks if it goes. Anything you cannot write that line for is a candidate for removal — and a module removed is a module that will never have a vulnerability again.
Check coverage, not just versions. A module can be current and unsupported at the same time. composer show drupal/* gives you versions; https://www.drupal.org/project/<name> tells you whether the security team still covers it and when it was last released. An abandoned module with no open advisory is not safe, it is unwatched.
Uninstall properly. Disabling a Drupal module leaves its code on disk and its routes potentially reachable. Uninstall it, then remove it with composer remove, then confirm the directory is gone.
Watch the modules that touch permissions. Anything with access, role, api, auth, verification or sso in the name is doing the thing the September list shows is most often done wrong. These deserve a closer look than a carousel.
Subscribe to the contrib feed specifically. Core and contrib are separate advisory feeds; watching only core means watching the part that rarely fails:
https://www.drupal.org/security/contrib/rss.xmlThe uncomfortable part
Contrib advisories arrive in batches of sixteen, which makes them feel like noise, and most of them will not apply to you. That is exactly why they get skimmed — and why the one that does apply gets skimmed too.
The fix is not more diligence. It is a shorter list. Every module you remove is one you no longer have to read a Wednesday advisory batch for, forever.