Drupal CVE-2026-9082 as a parser-differential class — what the 20/22 May SQLi wave tells TYPO3 operators

TL;DR — the 90-second summary

What's the problem? — three independent design decisions that collapse on top of each other

The flaw doesn't arise in one place. It arises in the interplay of three design decisions, each of which is sensible on its own and would pass any Drupal code review. Only the overlay of all three in the same request produces the unauthenticated DB access.

First contribution — Symfony JsonEncoder hands out associative arrays

The JSON login endpoint /user/login?_format=json is part of the Drupal core user module and is enabled by default in every installation. It parses the request body via Symfony's JsonEncoder. The encoder correctly decodes JSON objects into associative PHP arrays — that's not the bug, it's the documented expected behaviour. If you send the name field as a JSON string ({"name": "alice"}), the controller receives a string. If you send it as a JSON object ({"name": {"x": "1"}}), the controller receives an associative array. The Drupal login controller passes whatever it gets, without form-type validation, on to the entity query — because Drupal's entity query can interpret arrays as multi-value conditions (IN (…) clauses) and is therefore a legitimate input type. From the controller's perspective, name is polymorphic: string or array, both are permitted.

Second contribution — the implicit trust assumption in the DB abstraction layer

Drupal's DB API works with named placeholders (:name) and an auto-expand mechanism for array conditions (:name[] → :name_0, :name_1, :name_2, …). The expand logic iterates over the array, builds a cleanly parameterised placeholder for each value — and constructs the placeholder name from the array key. For numerically indexed arrays ([0 => 'a', 1 => 'b']) the keys are 0, 1, …, the placeholders read :name_0, :name_1, …, everything flows cleanly through PDO.

This is where the Drupal core authors' unspoken assumption sits: values are untrusted, keys are trusted, because keys are always machine-generated indexes from the framework's perspective. This assumption holds for every internal call site of the DB layer; it does not hold once a user path passes an associative array form through to placeholder construction. That's the actual weakness — not a forgotten escape, not a missing cast, but an assumption about the shape of the data that is nowhere reified as a constraint in code.

Third contribution — the PostgreSQL-specific emission path

This is the reason the flaw is PG-only and not Drupal-wide. Drupal's DB API has per-backend driver overrides. The pgsql driver has its own placeholder emission because PostgreSQL behaves differently from MySQL and SQLite around type-cast hints, standard_conforming_strings handling, and named-vs-positional mapping. In the PG driver, the attacker-controlled key reached a code path where it was interpolated raw into the SQL string before the PDO layer parameterised the values. On MySQL and SQLite the equivalent path either dropped the key or interpolated it at a SQL position that didn't leave the placeholder context — and therefore didn't turn into SQLi.

Three conditions, one bypass. You need all three: an entry point that hands the controller an associative array (JSON endpoint with an object-shaped field); an abstraction-layer assumption that the keys are trusted (universal in Drupal core); and a backend driver that emits the key into the SQL string (only PG). Once the three line up, an anonymous attacker has SQL injection on a login route that was explicitly built for anonymous requests.

The patch and what it doesn't fix

Drupal's fix in 11.3.10 / 11.2.12 / 11.1.10 / 10.6.9 / 10.5.10 / 10.4.10 is a one-liner: array_values() on the incoming condition array. That strips the attacker-controlled keys and replaces them with numeric indexes — the DB layer's implicit assumption is restored on the caller side. It's a defensible 24-hour patch and it closes the exploitable spot completely.

What it doesn't fix: the assumption „keys are trusted“ still lives in the DB layer and is nowhere reified in the Drupal coding standard. The PG-vs-MySQL/SQLite divergence in the placeholder emit path remains. And the question of whether other call sites exist where a user path passes an associative array shape through to placeholder construction is not answered by the patch — it's only pragmatically suppressed at this one site. The Drupal Security Team's reflex „patch first, harden later“ is not wrong at this pace; it leaves an audit debt in the codebase, though, and Drupal as an open-source project will look at it in the coming months.

Who is affected?

Outside direct Drupal exposure, but stylistically part of the class:

• TYPO3 — no direct hit (Doctrine DBAL without auto-expand magic), but every third-party extension that passes user-structured arrays into QueryBuilder::where() or dynamically composed expr()->in(…) strings requires an audit (see „What we actually did“ below).
• Symfony — the SymfonyRuntime patch bypass from 20 May (CVE-2026-46626) is the same pattern class: two parsers (parse_str vs SAPI argv builder) interpret the same input slightly differently, and the attacker sits on the translation boundary.
• HtmlSanitizer waves (CVE-2026-45064 BiDi override, CVE-2026-45066 allowLinkHosts bypass from the Symfony wave of 20 May) — also parser-differential class: URL parser on the sanitizer side vs URL parser on the browser side.

Impact

We don't sort by CVSS numbers (Drupal awarded the 20/25 score via their own risk scale, NVD runs CVSS 6.5, the operational severity sits considerably above that), we sort by observed escalation depth.

Escalation depth 1 — information disclosure. An anonymous attacker can read arbitrary table contents via the SQLi: user hashes, session tokens, configuration values, arbitrary custom-entity data. For Drupal platforms that hold personal data in custom entities or fields, this is a complete data exfiltration from the DB layer.

Escalation depth 2 — privilege escalation. Via INSERT/UPDATE on users_field_data and the Drupal permissions tables, the attacker can create their own accounts or equip existing accounts with privileged roles. Once an admin account is controlled, the attack has migrated from the SQLi layer into the application layer.

Escalation depth 3 — remote code execution via PostgreSQL. PostgreSQL provides direct OS command invocation through COPY FROM PROGRAM, provided the DB user has the necessary privileges (typical for self-hosted PG installations, less typical for managed services like RDS, Aiven, Hetzner Managed PG). On top of that, lo_import / lo_export give file-system access, and CREATE EXTENSION opens further RCE paths. Searchlight Cyber demonstrates an end-to-end path to OS shell in their published analysis. Akamai confirms active exploit attempts with RCE payloads in their own telemetry.

Escalation depth 4 — lateral movement in the cloud. Once the OS layer is reached, IAM roles, cloud metadata endpoints, and potentially SSM / cloud-init paths sit in the same trust zone. If you operate a Drupal installation on an EC2 instance whose IAM role has access to S3 buckets or Secrets Manager, you lose the cloud credentials at the moment the SQLi escalates to RCE.

The bracket around all four: operational severity is not set by the SQLi itself, it's set by what hangs below the DB layer. A Hetzner Managed PG installation behind a Drupal instance with moderate DB user privileges probably ends at depth 2. A self-hosted PG instance on an EC2 host with broad IAM roles ends at depth 4. The CVSS 6.5 number is an average modelling; in practice the distribution sits at both extremes.

Mitigation / immediate action

We keep the immediate-action block for Drupal operators short — the patch is trivial, the recommendation is immediate. The emphasis is on the next section („What we actually did“).

Path 1 — full patch (recommended)

# Pull the patch
composer update drupal/core-recommended drupal/core --with-all-dependencies

# Verify the version
composer show drupal/core
# Expected: 10.4.10 | 10.5.10 | 10.6.9 | 11.1.10 | 11.2.12 | 11.3.10 — matching your line

# Apply database updates
drush updatedb
drush cache:rebuild

If you have Composer audits integrated, you'll see the block immediately. If you don't, install now:

composer require --dev roave/security-advisories:dev-latest

Path 2 — stopgap, if patching is not possible in the current window

Four edge-level mitigations, cumulative — none replaces the patch:

1. Block the JSON format on the login endpoint. Reject the _format=json query parameter on /user/login at the reverse proxy. nginx:

location = /user/login {
    if ($arg__format = "json") {
        return 403;
    }
    # ... usual Drupal backend chain
}

Caddy:

@drupal_login_json {
    path /user/login
    query _format=json
}
respond @drupal_login_json 403

2. Temporarily disable the JSON API module, if it's not used in production:

drush pm:uninstall jsonapi

3. WAF rule on POST bodies to /user/login with an object-shaped name field. Suricata rule sketch (not complete):

alert http any any -> $HTTP_SERVERS any (msg:"Drupal CVE-2026-9082 JSON name-object";
    http.uri; content:"/user/login"; http.method; content:"POST";
    http.request_body; content:"\"name\":{"; sid:2026908201;)

4. Constrain PostgreSQL user privileges hard. If the Drupal DB user doesn't actually need the pg_execute_server_program role or superuser privilege, the escalation to RCE via COPY FROM PROGRAM is closed. This is the default for managed PG services anyway, but for self-hosted PG installations it's an audit step.

Path 3 — detection: identify active exploit attempts

# Scan the nginx access log for JSON login POSTs
grep -E 'POST /user/login.*_format=json' /var/log/nginx/access.log \
  | awk '{print $1, $4, $7}' \
  | sort | uniq -c | sort -nr | head -20

# Review the Drupal watchdog log for DB errors on the entity query
drush watchdog:show --type=database --severity=error --count=200

# Scan the PostgreSQL slow query log for unusual condition structures
grep -E "FROM users_field_data WHERE.*name" /var/log/postgresql/postgresql-*.log \
  | head -50

If you run Falco / Tetragon / eBPF monitoring, you'll additionally see whether unusual outbound connections or shell-exec paths arise from the PHP-FPM process — the escalation-depth-3 signal.

Detection / verification

This section is provided as a standalone block in the classic CVE template (element 9 per section 3 of the editorial guide). We fold it together with the „Path 3“ block above — the detection notes sit technically cleaner in the context of mitigation. The explicit detection block for platform operators:

Composer state and audit:

composer audit --format=json | jq '.advisories[] | select(.package == "drupal/core")'

Watchdog inspection via Drush:

drush watchdog:show --type=user --severity=warning --count=500 \
  | grep -iE 'login|json|format'

Pre-patch forensics: If you operated the platform publicly before the patch and no WAF sat in front, retroactively scan access logs from the last two weeks for POSTs to /user/login?_format=json and preserve the request bodies, provided your log format includes them. On hits: full audit of the Drupal DB user's privileges, audit of all admin accounts for new entries, audit of modules for subsequently installed extensions.

Operator recommendation

Operational decision block

Before the sub-scenarios, the if/then reading order:

• Patch immediately if you run Drupal core on a PostgreSQL backend and the platform is publicly reachable. The CISA KEV due date is 27 May 2026; the operational deadline is the next free maintenance hour.
• Patch immediately and apply stopgaps if the patch can't be rolled out within 24 hours. Both paths cumulate (see the mitigation block above).
• Trigger an audit if you operate TYPO3, Sylius, or another Symfony / Doctrine-backed platform — no patch path for you, but a trigger for an inventory of your own third-party extensions for parser-differential patterns (see the sub-scenario below).
• Purely internal platform if the Drupal surface sits entirely behind VPN / mTLS and the JSON endpoint is not reachable from outside. Patch even then, but without the stopgap path — patch in the next regular release train.

German Mittelstand

For the few Drupal-PostgreSQL setups in the German Mittelstand: 24 hours is the operational window, not the maintenance window. If you run monthly Composer updates, this wave is the trigger to move to biweekly — the Glasswing waves are not getting smaller.

Enterprise

Same patch path, plus an audit of the DB user privileges. If the Drupal DB user holds more privileges than actually required for operation (typical: superuser default from the initial setup, never rolled back), escalation depth 3 (RCE via PostgreSQL) is operationally open. Least-privilege hardening of the DB user is the structural consequence of this CVE — independently of whether the concrete patch is in place.

Kubernetes / container platforms

Rebuild Drupal images as soon as the Composer update is incorporated into the build layer. If you run Wolfi-OS / Chainguard PHP images, you don't see the patch in the base image — it sits in the app layer (Composer tree). Trigger a new multi-stage build, push a new image tag, roll the pods. Container restart is mandatory because Drupal otherwise continues running with the old codebase via container-reuse optimisations (e.g. OPCache, Twig compiled cache).

Declarative stacks (NixOS / Talos / Flatcar)

Pull the nixpkgs pin to the Drupal patch tag, or fix the composer update in the build layer. Talos and Flatcar: patches sit in the app image, not in the OS layer; the rollout follows the app update pipeline, not the OS update window.

What we actually did

We don't run Drupal in production customer platforms — so no patch train at our end for this CVE. What we did concerns our own codebase and the third-party extensions in the TYPO3 trees we operate.

The real audit reflex sits in the carry-over to the TYPO3 / Doctrine DBAL stack. TYPO3 uses Doctrine DBAL rather than its own DB API. Doctrine has no auto-expand on arrays — if you want an IN condition, you have to call Connection::executeQuery() with an explicit value array and either enumerate the placeholders yourself or set the Connection::PARAM_*_ARRAY type hint. That makes the exact Drupal flaw non-portable. The pattern, however, is very much portable: every TYPO3 extension that accepts user input via $request->getParsedBody() or $request->getQueryParams() and passes it without explicit form validation into a QueryBuilder->where(…) call can stumble on associatively structured input — particularly if the where condition is built via $queryBuilder->expr()->in(…) with a dynamically composed column string, or if createNamedParameter() is called without an explicit type hint.

Over the weekend we ran a grep sweep across the third-party extension trees of our customer platforms:

# In each TYPO3 project tree
find typo3conf/ext -type f -name "*.php" -exec grep -lE \
  'getParsedBody|getQueryParams' {} \; \
  | xargs -I {} grep -lE 'QueryBuilder|createNamedParameter|expr\(\)->in' {} \
  | sort -u

The hit list is manageable, because most extensions do strict form validation via Extbase/Fluid or TYPO3 Forms. Three extensions in the long-tail range (all custom builds from the years before 2024, i.e. before the broad migration to Extbase 14) we reviewed manually — no exploitable spot found, but two of the three extensions had code paths that would have been cleaner with an explicit type hint in createNamedParameter(). We added those to the next refactoring window, without escalation.

Reflection in two points. First: the fact that we don't run a Drupal platform isn't a glory; it's a platform choice we made years ago that occasionally produces less work in waves like this. In other waves (for instance the Symfony 20 May Patch Tuesday) we were fully on the hook. The platform choice is a risk distribution, not a risk exclusion. Second: parser differentials of this CVE class are not controllable through codebase size or code-review culture of a single project — they sit at layer boundaries where two components interpret the same input slightly differently. Drupal-Symfony-JsonEncoder ↔ Drupal DB layer is one class; SymfonyRuntime parse_str ↔ SAPI argv builder is another; HtmlSanitizer URL parser ↔ browser URL parser is the third. If you want to push this class structurally out of your own stack, you don't build a better sanitising function — you reduce the number of layer transitions: fewer parsing stages, fewer format indirections, less auto-magic in abstraction layers.

Conclusion

CVE-2026-9082 isn't the patch trigger for Moselwal — it's the audit trigger. We don't run Drupal, but we run TYPO3, and the class to which the Drupal flaw belongs isn't Drupal-specific. Three independent design decisions, each sensible on its own, produce unauthenticated DB access when overlaid: a JSON encoder that correctly decodes associative arrays; a DB layer that implicitly assumes array keys are trusted; a backend driver that emits the key into the SQL string. We saw the same pattern on 20 May in SymfonyRuntime (CVE-2026-46626, parse_str vs SAPI argv) and in the Symfony HtmlSanitizer wave (CVE-2026-45064/-45066, URL parser differentials) — three different stacks, the same class, three weeks of time window. The structural consequence isn't „better sanitising functions“, it's fewer transitions between parsing stages, less auto-magic in abstraction layers, more explicit type hints at the layer boundaries. The question isn't whether the next parser-differential CVE arrives in your stack. It's at which layer boundary you'll see it first — and whether you've looked there carefully before it arrives.