Five Drupal modules just got marked “unsupported” — the contrib abandonment tax
On 22 July the Drupal security team published ten contrib advisories, and five of them came with the same grim instruction: there is no fix, uninstall the module. Not "update to the patched version." Uninstall. That word — "unsupported" — is the politest phrase in Drupal for "the maintainer went quiet and you're on your own now." It's worth understanding exactly what it means, because every one of us is running some module that's one silent maintainer away from that banner.
The batch
Ten advisories, SA-CONTRIB-2026-080 through -089: six Critical, four Moderately Critical. Five got fixed releases. The other five were marked Unsupported:
- PanKM — SA-CONTRIB-2026-083
- Commerce Elavon — SA-CONTRIB-2026-084
- Email Login OTP — SA-CONTRIB-2026-085
- Lunr exposed filters — SA-CONTRIB-2026-086
- Development Environment — SA-CONTRIB-2026-089
Every one reads the same on its advisory page: risk "Critical, 16/25," affected versions "All versions," solution "If you use this project, you should uninstall it."
The detail nobody explains: that "Critical" is a policy default
Here's a nuance I only understood after reading the security team's own procedure. When a module gets marked unsupported, the team assigns a standardised Critical score regardless of the actual severity — because the maintainer never responded, so nobody finished assessing how bad the bug really is. The "16/25 Critical" isn't necessarily a confirmed critical exploit. It's the team saying: we found something, we couldn't get it fixed or fully triaged, assume the worst and pull it out. That's the responsible default, but it means "Critical" here reads slightly differently than on a normal advisory.
What actually happens when a project is marked unsupported: the team issues the advisory, sets the project to "Unsupported / No further development," removes all the maintainers, and flags every release as insecure. The coverage shield disappears. Your options are the ones on every one of those pages — switch to a maintained alternative, or step up and take over maintainership yourself so it can be fixed and re-published.
Why this keeps happening
It's structural, not exceptional. Drupal's security-advisory coverage is opt-in, and only stable releases of covered projects get the shield. A module is covered because a maintainer opted in and is responsive. The moment that person loses interest, changes jobs, or burns out, a perfectly working module can slide out of coverage — the code didn't change, the human did. (I won't quote a number for how many contrib modules are abandoned; I couldn't find a credible one, and inventing a statistic would be exactly the kind of thing this blog tries not to do.) And this wasn't a one-off week: there'd been another unsupported batch on 8 July. It's a steady drip.
Your composer.json is a list of promises other people made in their spare time. Most of them are kept. You just can't tell which ones aren't until the banner appears.
The audit I actually run
This nudged me to do the housekeeping I always mean to. A practical order:
composer audit— flags known advisories across your whole dependency tree, Drupal and PHP libraries alike.drush pm:security(andpm:security-php) — checks your installed packages against the Drupal advisories feed and hands you the Composer commands to remediate; it exits non-zero if anything's insecure, so it drops straight into CI.- The
drupal-composer/drupal-security-advisoriesmetapackage — require it, and Composer will refuse to install a known-insecure version in the first place. - The manual bit the tools miss: for each contrib module, open its drupal.org page and look for the coverage shield and the maintenance status. "Unsupported," "No further development," "Seeking co-maintainers," a last release two years ago — those are the tells. The automated tools catch known advisories; they don't catch a module that's simply been quietly abandoned before anyone filed one.
None of this is glamorous and all of it is the job. Self-hosting a Drupal site means you're the one who notices when a dependency goes dark — nobody sends you a letter. Ten minutes with composer audit and a skim of your module list is cheaper than finding out the hard way that the OTP module guarding your logins hasn't had a maintainer since spring.