The Death of "Patch First": Exploiting and Mitigating Drupal CVE-2026-9082 under 60 Minutes

Thank you!

You're subscribed!

Oops! Something went wrong while submitting the form.

On May 20, 2026, Drupal pushed the patch for CVE-2026-9082, a pre-announced Entity Query SQL injection vulnerability in its core. Under an hour later, using Claude and less than $10 in tokens, we had a working exploit running against an unpatched Drupal instance.

Drupal pre-announced this CVE more than 48 hours in advance and asked every operator to reserve time during the Wednesday release window so they could patch the moment a fix shipped. That ask is the vendor saying out loud what this exploit demonstrates empirically: any meaningful patch lag, even waiting for the next maintenance window, is now too much exposure to accept.

Drupal powers public-facing properties at organizations including Tesla, NASA, Pfizer, the European Commission, UNICEF, Princeton, and Oxford. A defaced or hijacked Drupal site is not the same failure mode as a data breach but for those brands it is still a public trust event measured in news cycles.

SQL injection in a modern enterprise CMS core is unusual. The class was the canonical web vulnerability of the early 2000s, and mature platforms have steadily engineered it out through ORMs, parameterized queries, and static analysis. CVE-2026-9082 is a reminder that the class is not extinct; it just got rare.

This post answers three questions: what Drupal actually disclosed, what we proved can be done in under an hour, and what defenders should do before the next PSA of this shape arrives.

The Exploit Process

We set Claude to monitor the supported branches on the evening of May 20 and went to dinner with the team. When we came back, the patch had landed, Claude had identified the critical commit, set up a vulnerable Drupal instance in a Docker container, and constructed a working SQL-injection oracle that demonstrated the vulnerability.

The exploit was not a one-shot; some nudging from a human researcher was required to overcome a syntactic obstacle in the injection path. Total time from patch publication to working exploit: less than an hour. The total cost in Claude tokens was under $10.

Here is what we did, step by step.

1. Monitor for the patch release.

We asked Claude Code to monitor the supported Drupal branches that were scheduled to be patched during the May 20 release window, then went to dinner with the team. When we came back, Claude had detected the patch landing in the public release feed and surfaced the relevant change. The pre-announcement made the listening job trivial: the time window was already known, so Claude only needed to watch the right branches and flag the moment a new commit arrived.

Image 1: The monitor sits idle for 64 minutes, then fires the moment six Drupal branches receive new tags simultaneously. Claude narrows the diff to three files and forty-seven lines and surfaces SA-CORE-2026-004 (Drupal Core Entity Query SQLi) as the security commit.

2. Identify the patched commit.

With the release window narrowed down, isolating the commit that contained the security fix was straightforward. We reviewed the changes published inside the window and converged quickly on a single commit, which on inspection was an obvious critical-severity fix in the Drupal core. The pre-announcement had effectively done half the analytical work for us.

*Image 2: The git logs across all six newly-tagged releases share one common commit. Same author list, same files touched, including both end-of-life backports. SA-CORE-2026-004 is the patch.*

3. Set up a vulnerable Drupal instance.

Drupal is open-source and runs on PHP, which makes it easy to stand up in a Docker container. We used Claude to provision the latest pre-patch version of Drupal locally, so we could reproduce the vulnerable state and later confirm that the official patch closed it.

4. Generate the exploit and verify the patch.

This step was not a single-shot prompt. The vulnerability called for a boolean-based SQL injection oracle, and Claude needed nudging to get past specific syntactic obstacles in the injection path.

However, this is where the speed becomes interesting: Even with a syntactic hurdle, five failed payloads, a manual reasoning step reading the leaked SQL out of the 500 response body, and two refinements, the entire exploit generation process took minutes.

Once the oracle worked against the unpatched instance, we applied the official patch with git and confirmed that the same exploit no longer succeeded against the patched instance.

Image 3: The exploit was not one-shot. Five failed payloads, a reasoning step reading the leaked SQL out of the 500 response body, and two refinements later, the CASE-inside-LOWER payload produced a working boolean-blind oracle.

The exploit's behavior, before and after the patch, gave us a clean empirical demonstration of both the vulnerability and the patch's effectiveness.

Image 4: End-to-end in one terminal. Drupal 11.3.9 stood up in Docker, the SQL-injection oracle extracting the admin bcrypt hash from the unpatched instance, then the same query returning nothing once Drupal 11.3.10 is checked out. The patch closes the exploitable path.

Timeline

May 20, 5:12 UTC: The patch is detected

May 20, 6:03 UTC: Miggo has a functional exploit to full SQL injection and RCE

May 21, 05:25 UTC: First GitHub PoC (lysophavin18/cve-2026-9082)

May 21, 11:42 UTC: Second GitHub PoC (7h30th3r0n3/CVE-2026-9082-Drupal-PoC)

What We Can Learn

The patch path is structurally slower than the attack path. Vetting, staging, rollback planning, and change windows are not optional in enterprise environments. The faster the attacker side moves, the more brittle "patch first" becomes as a primary strategy.
Time-to-exploit has collapsed. For high-impact application CVEs, working exploits now appear within hours of disclosure, not days. Operations teams cannot win a race they only learn about at the starting line.
The shape of disclosure is changing. Urgent pre-announcements, awkward operational workarounds, and exploit-in-the-wild within hours of public release used to be tail-end edge cases. They are becoming the modal pattern for high-severity application-layer CVEs.

What Defenders Should Do Now

Before the May 20 patches drop, every Drupal instance needs to be on a baseline that can actually receive the fix. The maintainers were specific:

Supported branches receiving the patches directly: 11.3.x, 11.2.x, 10.6.x, 10.5.x.
Sites on 11.1 or 11.0: update to at least 11.1.9 before the window opens.
Sites on 10.4, 10.3, 10.2, 10.1, or 10.0: update to at least 10.4.9.
Sites on Drupal 9: update to 9.5.11. Sites on Drupal 8: update to 8.9.20. Patches for these end-of-life versions will ship on a best-effort basis and may not apply cleanly. A migration to a supported branch is the real fix.
Drupal 7 is not affected.

Get the staging work done asap. Sites should already be on the newest patch level for their branch so that any upgrade conflicts, dependency issues, or compatibility problems surface now, not at 5:00 PM UTC on Wednesday. The release window runs from 5:00 to 9:00 PM UTC. Have an administrator available for the full four hours, back up files and databases before applying the patch, test the update path in staging, and have a rollback plan ready.

During and after the window, watch traffic. Confirm WAF coverage is staged and that unusual request patterns get flagged on admin paths, module endpoints, and known-vulnerable surfaces. Past Drupal CVEs, including Drupalgeddon 2 in 2018, saw exploitation attempts inside the first day of disclosure. The defenders who survived those windows were the ones with the patch staged, the rollback rehearsed, and the runtime visibility live before the CVE went public.

Runtime Mitigation: A WAF Rule for CVE-2026-9082

Major WAF providers, like Cloudflare, Akamai, and AWS, typically receive pre-disclosure for exactly this reason. By the time the CVE is public, mitigation rules are staged at the protective layer. The asymmetry is structural: defenders with a runtime control plane get to act in advance; defenders relying only on a patch pipeline do not.

Runtime is where the asymmetry inverts. Application-layer mitigations, at the WAF, the runtime, or the request boundary, do not require a code change, a deployment, or a maintenance window. They are the only control surface that operates on the same clock as the attacker.

For CVE-2026-9082 specifically, the runtime mitigation is a tightly scoped WAF rule that blocks the malicious JSON:API filter-key payloads before they reach the Drupal application. The rule operates on the request boundary, requires no code change, and ships ahead of the patch pipeline..

Defending an application portfolio in 2026 means assuming you will be exposed to a new high-severity CVE before you can patch it and building the runtime defense that lets you survive the wait. Miggo's WAF Copilot and AI Runtime Defense platform deliver runtime mitigation for application-layer CVEs, ahead of the patch pipeline. See it in action.

<script src="https://cdn.jsdelivr.net/npm/gsap@3.12.5/dist/gsap.min.js"></script>
<script src="https://cdn.jsdelivr.net/npm/gsap@3.12.5/dist/Flip.min.js"></script>

<script>
  document.addEventListener("DOMContentLoaded", (event) => {
    gsap.registerPlugin(Flip);
    const state = Flip.getState("");
    const element = document.querySelector("");
    element.classList.toggle("");
    Flip.from(state, {
      duration: 0,
      ease: "none",
      absolute: true,
    });
  });
</script>

<script src="https://cdn.jsdelivr.net/npm/gsap@3.12.5/dist/gsap.min.js"></script>
<script src="https://cdn.jsdelivr.net/npm/gsap@3.12.5/dist/Flip.min.js"></script>

<script>
  document.addEventListener("DOMContentLoaded", (event) => {
    gsap.registerPlugin(Flip);
    const state = Flip.getState("");
    const element = document.querySelector("");
    element.classList.toggle("");
    Flip.from(state, {
      duration: 0,
      ease: "none",
      absolute: true,
    });
  });
</script>