Eden
All case studies
CVE-2026-9082

Drupal core: SQL injection on PostgreSQL sites (CVE-2026-9082)

An anonymous caller can inject SQL through the affected Drupal database abstraction path on PostgreSQL-backed sites. Upgrade Drupal to protect site data and privileges accessible to its database role.

Public CVE record · Native module source

FieldValue
Affected component and versionsSee the advisory for the affected versions of each product or package: Drupal core, drupal, drupal/core
Fixed releaseSee the advisory for product-specific fixes
SeverityCVSS 9.8
Evidence statusRecorded fixture comparison
Test environmentLab fixture or affected build documented in the evidence below
Eden release and module version1.103.0
Tested at2026-11-12 UTC
First publicly published2026-11-12T18:25:13Z

CVE advisory record · Vendor advisory · Module source

Result. The marked request reached the backend in the baseline and raised its counter. The native rule refused that request with HTTP 403 and preserved HTTP 200 for the benign probe. The synthetic fixture ran through Eden 1.103.0 on November 12, 2026 (UTC).

The vulnerability

Drupal’s database abstraction layer is supposed to keep request data separate from SQL. On the affected PostgreSQL path, a crafted request can reach query construction and change the resulting SQL. Anonymous access matters because the advisory does not require an authenticated Drupal account.

Drupal lists fixed releases 10.4.10, 10.5.10, 10.6.9, 11.1.10, 11.2.12, and 11.3.10. Its advisory documents separate guidance for Drupal 8 and 9. The CVE record reports a CVSS base score of 9.8.

The Eden patch

Tier 1 — declarative policy. The recorded policy denies requests to /api/entity_form/system and its descendants. The empty method list leaves the deny unrestricted by HTTP method. This is a coarse rule and blocked the benign probe on the same path.

JSON
{
  "version": 1,
  "profile": "http-structure-v1",
  "policy": {
    "version": 1,
    "rules": [
      {
        "scope": {
          "methods": [],
          "path": "/api/entity_form/system",
          "descendants": true
        },
        "require": {
          "kind": "deny"
        }
      }
    ]
  }
}

Tier 2 — native Rust module. gabriel_drupalsqli_v1 waits for the request to be complete, checks whether the request target starts with /api/entity_form/system, and looks for any configured marker in the body. The substring comparison is ASCII case-insensitive. Outside that prefix or without a marker, the module returns Continue. The shown lines are excerpts from the linked source.

Rust
const ROUTE: &[u8] = b"/api/entity_form/system";
static NEEDLES: [&[u8]; 3] = [b"' OR ", b"union select", b"1=1"];
Rust
NEEDLES.iter().any(|n| find_ignore_case(body, n).is_some()) && return Ok(Decision::Refuse);

Implement the remediation

Use this procedure in an isolated fixture to reproduce the scoped restriction. Follow the vendor update for the underlying exposure. See deployment prerequisites.

  1. Prepare the target. Verify the loaded product and version against the advisory. Use a compatible Eden HTTP interlay and an authenticated operator with Configure permission. Use the recorded declaration and the linked source when applicable.
  2. Apply the declarative policy. Scope the policy to /api/entity_form/system and descendants (all methods, deny). Set INTERLAY to the target interlay UUID in the authenticated Eden CLI. Run an authenticated GET /api/v1/interlays/{interlay} with X-Eden-Verbose: true. Save its complete current settings object as current-settings.json and retain the prior remediation declaration for recovery. Set IDEMPOTENCY_KEY to a fresh key for this intended mutation.

Save the JSON in the patch section as remediation.json.

sh
jq -e --slurpfile policy remediation.json \
  '.remediation = $policy[0] | {settings: .}' current-settings.json \
  > interlay-update.json
eden api request PATCH "/api/v1/interlays/$INTERLAY" \
  --header "Idempotency-Key:$IDEMPOTENCY_KEY" \
  --body-file interlay-update.json --content-type application/json --confirm
  1. Verify the serving policy. Read back the interlay.
sh
eden api request GET "/api/v1/interlays/$INTERLAY" \
  --header 'X-Eden-Verbose:true'

Check that remediation_status.state is ready and both desired and effective SHA-256 values match the intended declaration. Replay the benign and marked requests in the recorded comparison on an isolated target. Check the recorded response and backend outcome for each probe. 4. Restore the previous policy. Coordinate the change with any other operator updating this interlay. Read current settings again and merge the saved remediation field into them. If the prior settings had no remediation field, omit it in the replacement. Send the same PATCH with a fresh idempotency key, then read back the intended state. Repeat the verification probes. Keep the affected route isolated if restoring the prior settings reopens exposure.

Vendor update. Use the advisory and its product-specific vendor references to select the fixed release for the exact installed product or package and release line. Follow its update instructions and confirm the version actually loaded by the service.

Fixture and probes

The fixture was a synthetic HTTP handler behind Eden. It answered the probes and kept a separate counter that increased when the handler recognized its marker bytes. The counter measures a fixture effect. An HTTP 200 from the baseline does not by itself establish that the counter moved.

Request. POST /api/entity_form/system for the benign probe and the marked probe.

The benign fixture requested a search operation in a form field. The second body used a SQL predicate marker in that field. The handler incremented a marker on byte match and did not execute a database query.

Measured comparison (2026-11-12 UTC)

The values after each status are the observed increases in the backend marker counter.

ProbeBaselineTier 1 route denyTier 2 native module
BenignHTTP 200, 0HTTP 403, 0HTTP 200, 0
Marked inputHTTP 200, 1HTTP 403, 0HTTP 403, 0

Signed module authority

The module import returned HTTP 201 and required explicit activation. Signature verification was deferred at import. Read-only inspection returned HTTP 403, admission with a tampered statement returned HTTP 400, and admission with an invalid signature returned HTTP 403. The activation receipt reported the module serving on all expected shards.

After revocation, the same marked request received HTTP 503. Re-approval and reactivation restored HTTP 403. The source digest below identifies the linked Rust file. The binary digest identifies the artifact recorded in the activation evidence.

  • Source SHA-256 0a5fb5f4e30ef8c1475c32626694dfe9b488405f40ea8f79c0e55d9bf9e39c6c
  • Tested binary SHA-256 caecd6d53cb7282c170d907f6614b12143be7d6abe6aecc293f2e3939248d5be

Test scope

The fixture used a synthetic form route. The experiment did not exercise Drupal’s database abstraction layer or a PostgreSQL backend. This rule can also refuse innocent input containing SQL-like text and does not cover all request shapes that might reach the database path.

Performance

The public evidence for this case does not include request-latency measurements.

Evidence and artifacts

Official CVE record