Drupal Website Security Checklist for 2026

In May 2026, Drupal's security team published a pre-announcement warning that a highly critical release was coming in two days. They said working exploits could appear within hours. They were right. Within 24 hours of the advisory going live, security firm Imperva had logged more than 15,000 attack attempts against nearly 6,000 Drupal sites across 65 countries.

That's the backdrop for talking about Drupal security in 2026. This isn't a theoretical threat landscape anymore. The checklist below is built around what actually happened this year — real advisories, real exploit patterns, real things to check on your site today.

First: Are You on a Supported Version?

This is the one thing that determines whether everything else on this checklist matters. If your site is running an end-of-life version of Drupal, every vulnerability that gets disclosed — including all nine from 2026 — stays permanently open, because no patches will ever come for it.

Here's where things stand right now:

• Drupal 7 reached end-of-life on January 5, 2025. No security patches.

• Drupal 8 reached end-of-life on November 17, 2021. No security patches.

• Drupal 9 reached end-of-life on November 1, 2023. No security patches.

• Drupal 10 reaches end-of-life on December 9, 2026. That's less than 6 months away.

• Drupal 11.2.x and 11.3.x are fully supported and actively patched.

If you're on any of the first four, the rest of this checklist is secondary to getting off that version.

5 Security Checks Worth Doing Right Now

1. Apply the May and June 2026 Patches

Drupal released a Highly Critical patch on May 20, 2026 — a SQL injection vulnerability (SA-CORE-2026-004) in the database abstraction API that could be exploited without any login required. It only affects PostgreSQL databases, but it was severe enough that CISA issued an emergency directive to U.S. federal agencies to patch within days.

Then on June 17, 2026, Drupal published four more core advisories in a single batch, covering PHP object injection, gadget chains, cache poisoning, and improper validation in JSON:API image uploads. All five are patched in Drupal 10.5.12, 10.6.11, 11.2.14, and 11.3.12. If you haven't updated since before June 17, you're running behind.

2. Review JSON:API Write Access

The June 17 PHP object injection advisory (SA-CORE-2026-005) requires a site to have JSON:API write access enabled to be exploitable — because JSON:API is read-only by default. The question is whether your site has write access enabled and whether that was intentional.

Check /admin/config/services/jsonapi. If read-only isn't enabled and you don't have a specific reason for write access, switch it now. Also worth reviewing which roles have permission to write via JSON:API — that's at /admin/people/permissions.

3. Audit Your Installed Modules

Two things happened with contrib modules in 2026 that are worth checking. First, the June advisory batch flagged three specific modules with PHP object injection risks: Formatter Field (before 2.0.0), Flag Attendance Field (before 8.x-1.2), and Plotly.js Graphing (before 3.0.2). If any of those are installed on your site, update them.

Second, and more broadly: Drupal.org marked the Brute Force Attack Protection module as unsupported in June 2026 — meaning no fix was coming, and the recommendation was simply to uninstall it. A module specifically built to protect against attacks became the risk. That's a useful reminder to periodically check what's actually running on your site and whether each module is still actively maintained.

4. Check oEmbed Configuration

SA-CORE-2026-008 flagged a server-side request forgery risk in the Media module's oEmbed URL discovery. If your site uses URL discovery for oEmbed embeds — rather than the providers.json whitelist — an attacker could potentially trick Drupal into making requests to arbitrary URLs. The fix is adding trusted host patterns to your settings.php file. If you only use oEmbed via providers.json, you're not exposed to this one.

5. Enable Two-Factor Authentication for Admin Accounts

Several 2026 advisories assume an authenticated attacker — someone who already has some level of access to your site. That makes admin account security more relevant than it might seem. Strong passwords matter less than you'd think when credentials get phished or reused from another breach. Two-factor authentication via the TFA module is a straightforward way to close that gap for admin and editor accounts.

The Part Nobody Talks About

The sites that get compromised are usually not running some obscure, unpatched zero-day. They're running a version someone updated eighteen months ago and hasn't touched since. Or they're on an end-of-life branch that nobody got around to migrating because it kept getting deprioritized.

The checklist above is useful. But the real security posture of a Drupal site comes down to one question: is there an actual process for staying current, or is security something that gets addressed reactively — after something breaks? Those are two very different situations, and the technical steps above only matter in the first one.

2026 Core Advisories — Quick Reference (For Developers)

Get your free security fix → drupalify.com/contact

Sources: Drupal.org security advisories SA-CORE-2026-001 through SA-CORE-2026-009; PSA-2026-05-18 (Drupal.org); TheDropTimes, “Eight Drupal Security Advisories” (June 17, 2026); Imperva threat intelligence on SA-CORE-2026-004.