CVE-2026-9082: Drupal core PostgreSQL SQL injection

CVE-2026-9082 is an SQL-injection vulnerability in Drupal core's database abstraction API. Drupal's security team states that an anonymous attacker can send crafted requests that cause arbitrary SQL injection when a site uses PostgreSQL. Impact can include information disclosure and, in some cases, privilege escalation or remote code execution. The advisory was updated on May 22, 2026 after exploit attempts were detected in the wild. CISA added the CVE to its Known Exploited Vulnerabilities catalog that day with a May 27, 2026 remediation due date for agencies subject to BOD 22-01.

Do not validate this finding by sending a payload. Establish applicability from the installed Drupal core version, the runtime database driver, deployment inventory, and the official version boundaries. Then update through the repository's normal dependency-release process and verify the deployed result.

Evidence basis and limits

I reviewed Drupal security advisory SA-CORE-2026-004, live GHAD GHSA-ghwc-95x2-682j, the CISA KEV data in the NVD record, and the official Composer and Drush command documentation. Live GHAD first_patched 10.4.10 / 10.5.10 / 10.6.9 / 11.1.10 / 11.2.12 / 11.3.10 matches NVD excludes and vendor SA-CORE-2026-004. I did not access or test a live Drupal site, inspect a site's database or logs, execute crafted input, or validate an update. The Drupal advisory remains authoritative for the affected ranges and branch-specific fixes.

The SQL-injection path applies only to sites using PostgreSQL. Drupal also says the fixed releases contain third-party Symfony and Twig security updates that apply more broadly, so a non-PostgreSQL site should not automatically discard the update. This recipe scopes the exposure decision for CVE-2026-9082 and does not claim to close those separate upstream findings.

When to use this recipe

Use it when a repository, scanner result, asset inventory, or incident ticket identifies Drupal core in the advisory's affected range and the task is scoped to CVE-2026-9082. A repository may own Composer constraints and lockfiles, container images, deployment manifests, inventory policy, tests, or release runbooks for the affected application.

The exact SQL-injection exposure requires PostgreSQL. Do not use this recipe to classify a non-PostgreSQL site as exposed to this CVE, send a crafted request, probe a public site, inspect production data without authorization, or make an unapproved dependency or production change.

Inputs

• Composer lockfiles, composer.json constraints, container images, and deployment manifests that pin Drupal core.
• Runtime evidence of the installed core version and whether the site uses the PostgreSQL driver.
• Inventory of preview, standby, worker, and disaster-recovery copies.
• Approved upgrade path to a currently supported Drupal branch and the repository's test, backup, and rollback commands.
• Authorization and log coverage if the site was reachable while unpatched.

Affected and fixed branches

Drupal core branch or range	Vendor action in SA-CORE-2026-004	Support note
Drupal 8.9.x	Manually apply the advisory's Drupal 8.9 patch only as an emergency bridge	End of life; migrate to a supported branch
Drupal 9.x	Manually apply the advisory's Drupal 9.5 patch only as an emergency bridge	End of life; migrate to a supported branch
>=10.0.0 <10.4.10	Update to 10.4.10, then migrate to a supported branch	10.4 and earlier are end of life; the release is supplied on a best-effort basis
>=10.5.0 <10.5.10	10.5.10	Prefer the latest supported release allowed by the approved upgrade path
>=10.6.0 <10.6.9	10.6.9	Prefer the latest supported release allowed by the approved upgrade path
>=11.0.0 <11.1.10	11.1.10	11.0 and 11.1 are end of life; migrate to a supported branch
>=11.2.0 <11.2.12	11.2.12	Prefer the latest supported release allowed by the approved upgrade path
>=11.3.0 <11.3.10	11.3.10	Prefer the latest supported release allowed by the approved upgrade path

The listed releases are historical minimums for this CVE, not a reason to remain on an obsolete branch. Live GHAD first_patched matches those same floors. The Drupal 8 and 9 patches are not fixed releases and do not restore vendor support; Drupal warns that unsupported versions still contain other previously disclosed vulnerabilities. Drupal's advisory identifies 11.3, 11.2, 10.6, and 10.5 as supported branches at publication. Resolve the current supported destination from Drupal before changing dependencies.

How to determine exposure safely

1. Find every Drupal application, tenant, immutable image, scheduled worker, preview environment, standby deployment, and disaster-recovery artifact.
2. Record the installed core version from the lockfile, built artifact, and running application. Do not rely on only composer.json constraints.
3. Establish the runtime database driver from approved deployment inventory or an authenticated status command. Do not print database URLs, passwords, or secret-backed settings into logs or a pull request.
4. Classify the exact injection exposure as affected only when the running core version is in an affected range and the site uses PostgreSQL. Version or driver uncertainty must remain open.
5. Record internet, partner, and internal reachability during the vulnerable period and preserve application, reverse-proxy, WAF, database, identity, and deployment logs according to incident policy.

Useful read-only inventory in an authorized repository or application shell may include:

composer show --locked drupal/core-recommended
composer show --locked drupal/core
drush status --fields=drupal-version,db-driver

Not every project installs drupal/core-recommended, and not every environment has Drush. Treat a missing command as an inventory limitation, not proof that Drupal or PostgreSQL is absent. Redact secret-bearing output before attaching evidence.

Immediate containment

For an affected PostgreSQL deployment that cannot be updated immediately, have the application and network owners restrict untrusted reachability or place the service into an approved maintenance state. Drupal's advisory does not publish a configuration workaround, so containment is temporary and must not be represented as the fix.

Preserve evidence before cache rebuilds, dependency updates, restarts, or log rotation. When an affected public site had exposure during the vulnerable period, notify the incident-response owner. A successful update does not prove that earlier SQL injection did not occur.

How to remediate CVE-2026-9082

1. Select a currently supported Drupal branch and a release at or above the applicable fixed floor. For an EOL branch, plan the supported migration; use the advisory's best-effort legacy patch only as a documented emergency bridge when the owner approves the residual risk.
2. Update the repository's Drupal core constraints and lockfile through its established Composer workflow. Preserve the package source, resolved versions, lockfile diff, and integrity metadata.
3. Review transitive Symfony and Twig changes, contributed-module constraints, PHP compatibility, database migrations, patches, and deployment hooks.
4. Run the existing unit, integration, kernel, functional, static-analysis, Composer audit, and application smoke tests. Add a regression test only when it can exercise sanitized query behavior without reproducing an exploit.
5. Back up the database and files through the approved recovery process, stage the deployment, and keep production database updates and traffic changes under the service owner's authority.
6. Deploy every web, worker, CLI, cron, preview, and standby artifact from the same reviewed lockfile. Remove vulnerable images and restoration paths.

Do not hand-edit Drupal core or add a request deny list as the permanent fix. Do not run untrusted SQL, copy a proof of concept into tests, or use production data to demonstrate exploitability.

How to verify remediation

• Confirm the running version on every deployment is at or above the fixed floor for its branch and that the branch remains vendor-supported.
• Match the deployed artifact and lockfile digest to the reviewed build.
• Confirm no old image, pod, worker, preview environment, standby, snapshot, or rollback package can re-enter service.
• Run authenticated application health checks for ordinary anonymous pages, forms, search, administration, queues, cron, and PostgreSQL-backed workflows.
• Re-run the approved dependency and vulnerability scanners without suppressing a conflicting result.
• Record application version, database driver, artifact identity, environment, verifier, timestamp, and test evidence.

If the site previously ran an affected version on PostgreSQL, patch verification and incident assessment are separate decisions. Let incident response determine database-log review, credential rotation, rebuild, and any notification obligations.

Agent prompt

You are remediating exactly CVE-2026-9082 in a Drupal repository. Return one
reviewer-ready change set or TRIAGE.md.

1. Inventory every deployed copy and record the running Drupal core version,
   database driver, artifact, owner, and reachability. Do not expose secrets.
2. Compare the exact version with SA-CORE-2026-004. The injection path requires
   PostgreSQL, but the release also includes separate dependency security fixes.
3. Select a current supported branch at or above its fixed version. Update the
   Composer constraints and lockfile through the repository's normal workflow.
4. Review transitive changes and run the existing tests, Composer audit, and
   benign application health checks. Do not include or execute exploit input.
5. Document staging, database backup, production-owner approval, rollback,
   per-deployment version verification, stale-image removal, and residual risk.

Do not deploy, alter production traffic, run database updates, scan public
systems, execute crafted requests, or suppress findings without authorization.
Do not claim that a patched version proves no prior compromise.

Stop with TRIAGE.md when the exact version, PostgreSQL use, complete deployment
scope, supported upgrade path, lockfile ownership, test coverage, backup,
rollback, exposure history, or production authority cannot be established.

Rollback and stop conditions

Rollback must restore the recorded application artifact and compatible database state through the existing recovery process. If that artifact is vulnerable, keep the service under approved containment and escalate a forward fix. Never make an affected build publicly reachable merely to recover service.

Stop and write TRIAGE.md when:

• the running core version, database driver, fleet scope, or artifact identity is unknown;
• the repository cannot safely resolve a supported fixed branch;
• contributed modules, PHP, Symfony, Twig, or database changes exceed scope;
• an affected public deployment lacks adequate historical logs;
• suspicious database or application activity is found;
• production backup, rollout, or rollback lacks an authorized owner; or
• verification would require an SQL-injection payload.

Output contract

Return one reviewer-ready CVE-2026-9082 change or TRIAGE.md. The change must include application inventory, before/after core versions, database driver, Composer and artifact evidence, test results, exposure and incident handoff, deployment and stale-image verification, rollback, and residual risk. No secrets, production data, exploit material, or unsupported clean claims.

Primary references

• Drupal SA-CORE-2026-004
• GitHub Advisory GHSA-ghwc-95x2-682j
• CISA Known Exploited Vulnerabilities entry
• NVD record for CVE-2026-9082
• Composer show documentation
• Composer audit documentation
• Drush core:status command

Related workflow

• Vulnerable Dependency Remediation
• How to remediate vulnerabilities with AI agents