Drupal 7 reached end-of-life on January 5, 2025, meaning every site still running it has had no Security Team coverage for over eighteen months — yet Drupal remains one of the most common CMS targets precisely because a single core advisory can affect over a million sites at once. That was the case with CVE-2018-7600, "Drupalgeddon2," disclosed March 28, 2018: an unauthenticated remote-code-execution flaw in the Form API's AJAX handling, affecting Drupal 7.x before 7.58 and 8.x before 8.5.1, that attackers were mass-exploiting within days of the patch shipping. It followed CVE-2014-3704, "Drupageddon," an anonymous SQL-injection-to-RCE chain in Drupal 7's database abstraction layer so severe that the Drupal Security Team publicly advised treating any site left unpatched for more than seven hours after disclosure as compromised. Those two incidents are the reason Drupal hardening can't be a one-time install checklist — it has to be an ongoing discipline across three areas: which contributed modules you trust, how tightly you scope roles and permissions, and how fast you apply security releases. This post lays out a concrete checklist for all three, current as of the actively supported 10.x and 11.x branches in 2026.
Why does contributed-module vetting matter more than core patching?
Contributed-module vetting matters because Drupal.org's security guarantee doesn't automatically extend to every module in the ecosystem — only projects that have opted into and passed review for the "covered" security advisory policy receive Security Team advisories at all. Sandbox and uncovered projects carry no SLA: a vulnerability in one may never get a published advisory, patched release, or public disclosure timeline. Before installing any contributed module, check its project page for the security-coverage flag, recent commit activity, the maintainer's response history on the issue queue, and open security-labeled issues. A module with thousands of active installs but no commits in two years is a worse bet than a smaller module with an engaged maintainer, regardless of download counts. Because modern Drupal core and most contributed modules are distributed and resolved via Composer, this vetting should happen at the composer.json dependency level, not just through the UI's "Install new module" screen — Composer scripts and post-install hooks run with the same privileges as any other dependency install, so an unvetted module is a supply-chain entry point, not just a feature toggle.
What does least-privilege access control look like in Drupal specifically?
Least-privilege access control in Drupal means treating the built-in roles and permissions system as a real attack-surface boundary, not a convenience layer. Drupal ships with "Authenticated user" and "Anonymous user" roles by default, and it's common for sites to accumulate permissions on these base roles over years of ad hoc configuration — every permission granted to "Authenticated user" applies to every logged-in account, including low-trust ones like newsletter subscribers. The checklist item: audit admin/people/permissions for any permission beyond the bare minimum assigned to default roles, especially "Administer permissions," "Use PHP for settings" (removed as a core option in modern Drupal but still present via contributed modules), and any content-editing permission scoped broader than needed. Pair this with per-node or per-field access control modules only when core's role-based system genuinely can't express the requirement, since every additional access-control module widens the permission-evaluation surface an attacker can probe. Enable and review Drupal's built-in permission-change logging so a role escalation shows up in an audit trail, not just in production behavior.
How fast should a Drupal security release actually get applied?
A Drupal security release should get applied on the same day it's published when it's rated "highly critical" or affects an unauthenticated attack path — the Drupageddon and Drupalgeddon2 incidents both showed mass automated exploitation beginning within hours to days of disclosure, not weeks. The Drupal Security Team publishes core advisories on a predictable Wednesday release-window schedule, plus separate contributed-module advisories on an as-needed basis, and issues Public Service Announcements (PSAs) giving advance notice before a scheduled critical release — for example, ahead of a highly critical core release in May 2026. The checklist item here is procedural: subscribe to both the core security advisory RSS/mailing list and the contributed-module advisory feed, not just one, since a site's actual attack surface is usually dominated by contrib modules rather than core. Maintain a documented emergency-patch runbook — who has deploy authority, how staging is bypassed for a same-day critical fix, and how the change gets retroactively reviewed — so the decision to skip normal change-control isn't improvised during an active PSA.
Which Drupal branches are actually still receiving security coverage?
As of the 11.4.0 release on July 1, 2026, the branches receiving Security Team coverage are 11.4.x, 11.3.x, and 10.6.x — that release window ended security support for 11.2.x and 10.5.x. Drupal 10 as a whole is scheduled to reach end-of-life on December 9, 2026, after which it will join Drupal 7 outside of Security Team support entirely. Per Drupal's published security advisory policy, only actively supported minor branches within a supported major version get advisories — running an older minor that has been superseded means missing patches even while nominally "on Drupal 10" or "on Drupal 11." The checklist item: confirm not just the major version but the exact minor version against the current supported-branches list before assuming a site is covered, and build the Drupal 10-to-11 migration into a 2026 roadmap now rather than after EOL, given how long the Drupal 7 EOL migration took across the ecosystem in practice.
How Safeguard Helps
Because modern Drupal core and contributed modules are managed through Composer, Safeguard's SCA engine treats a Drupal codebase the same way it treats any other Composer-based PHP project: it resolves the full dependency graph from composer.json and composer.lock, including transitive dependencies pulled in by contributed modules, and matches every resolved package and version against known CVE and GHSA advisories. That gives a Drupal team one queryable inventory to check against a newly disclosed core or contributed-module advisory — including the kind of unauthenticated RCE class that made Drupalgeddon2 so dangerous — instead of manually cross-referencing the security advisory feed against every module in use. Reachability and license findings flow through the same unified findings model as Safeguard's other engines, so a vulnerable transitive dependency pulled in by a contributed module gets triaged with the same severity scale and audit trail as any other supply-chain risk across the stack.