By ByteBot
Drupal shipped an emergency security patch yesterday for a highly critical SQL injection flaw that requires zero login, zero configuration knowledge, and zero complexity to exploit. SA-CORE-2026-004 (CVE-2026-9082) scores 20 out of 25 on Drupal’s severity scale — the highest rating the project has assigned in years. If you run Drupal on PostgreSQL, you are patching today, not after standup.
What Is the Vulnerability?
The bug lives in Drupal core’s database abstraction API — the layer responsible for sanitizing queries before they hit the database. An attacker sends a specially crafted HTTP request, the abstraction layer fails to neutralize it, and raw SQL reaches your PostgreSQL backend. The impact ceiling is about as high as it goes:
- Read all non-public data on the site — user records, private content, credentials
- Modify or delete any data in the database
- In some configurations: privilege escalation and full remote code execution
No login required. No special privileges. No unusual server configuration beyond running PostgreSQL. The Drupal Security Team’s pre-release advisory was unusually blunt: “exploits might be developed within hours or days.” That is not boilerplate — take it literally.
One important scope limiter: this vulnerability only affects sites using PostgreSQL as their database backend. MySQL and MariaDB installations are not vulnerable to CVE-2026-9082 specifically — though the bundled Symfony and Twig dependency updates in this release are worth applying regardless.
Which Versions Are Affected?
All supported Drupal 10 and 11 branches running PostgreSQL are vulnerable. Target versions after patching:
- Drupal 11.3.x → update to 11.3.10
- Drupal 11.2.x → update to 11.2.12
- Drupal 10.6.x → update to 10.6.9
- Drupal 10.5.x → update to 10.5.10
- Drupal 11.1.x and 10.4.x (EOL) → one-time best-effort patches at 11.1.10 and 10.4.10
- Drupal 8.9 and 9.5 → manual patches available on drupal.org
- Drupal 7 → not affected
To confirm whether your site uses PostgreSQL, check your settings.php for the database driver:
// PostgreSQL — patch immediately
$databases['default']['default']['driver'] = 'pgsql';
// MySQL — still update for bundled Twig/Symfony fixes
$databases['default']['default']['driver'] = 'mysql';How to Patch
The standard Composer-based update path applies. Back up first — there is no excuse for skipping that step:
# 1. Dump your database before touching anything
vendor/bin/drush sql:dump > backup-$(date +%Y%m%d).sql
# 2. Update Drupal core and all dependencies
composer update "drupal/core-*" --with-all-dependencies
# 3. Apply any pending database schema updates
vendor/bin/drush updatedb
# 4. Rebuild caches
vendor/bin/drush cache:rebuild
# 5. Confirm your version
vendor/bin/drush status | grep 'Drupal version'The official Drupal update documentation covers edge cases including Composer version requirements and composer.json constraint overrides if you are pinned to a specific release.
This release also bundles Twig updated to 3.26.0 and Symfony updated to 6.4.40 (Drupal 10) or 7.4.12 (Drupal 11). These address independent security advisories from those projects. If you run MySQL, CVE-2026-9082 does not apply to you — but you should still apply this update for the Twig and Symfony patches.
Why the Clock Is Already Running
The window between public disclosure and active exploitation has collapsed. The same week this Drupal advisory shipped, PraisonAI’s CVE-2026-44338 — another unauthenticated flaw — was actively exploited within four hours of disclosure. AI-assisted vulnerability research has made this the new normal: attackers ingest an advisory, map the patch diff, and generate working exploit code faster than most operations teams can schedule a maintenance window.
CVE-2026-9082 deserves particular urgency because its attack vector mirrors the Drupalgeddon family. Drupalgeddon 2 in 2018 — another unauthenticated SQL injection through Drupal’s abstraction layer — saw botnet campaigns begin within 24 hours of patch publication. The fingerprint is identical: no auth, SQL layer, high-impact vector. Assume the weaponization clock is already ticking.
Government portals, university systems, and enterprise intranets lean heavily on Drupal and make high-value targets. Berkeley’s Information Security Office and the University of Michigan both issued immediate advisories to their communities. If your Drupal site sits in front of anything sensitive, this is a P0.
If You Cannot Patch Immediately
Patch first. But if a maintenance window is hours away:
- Block external access to Drupal REST API endpoints not required for public use
- Apply WAF rules inspecting and blocking crafted SQL payloads targeting Drupal’s query patterns
- Audit PostgreSQL user permissions — the Drupal database user should not have superuser rights
- Monitor application logs for unexpected query errors or unusual access patterns
These are mitigations, not fixes. The patch is the fix.
