WordPress: path traversal in page-template resolution (CVE-2026-87902)

An unauthenticated caller can make affected WordPress template resolution include a readable PHP file outside the active theme, with possible code execution when server and theme prerequisites are met. Upgrade WordPress to remove the unsafe template selection.

Public CVE record · Vendor or publisher advisory · Native module source

CVE advisory record · Vendor advisory · Module source

Result. Both baseline requests returned HTTP 200 with zero marker change. The native rule refused the second probe and let the benign request through. These observations establish request refusal for the tested bytes. The synthetic fixture ran through Eden 1.103.0 on November 12, 2026 (UTC).

The vulnerability

WordPress page-template selection can resolve a readable PHP file outside the active theme’s directories. Execution requires server and theme conditions that let the selected file be included. The vulnerability concerns template resolution inside WordPress, which occurs after the HTTP request is routed.

WordPress lists 7.1.2 as the fixed release. The CVE record reports a CVSS base score of 8.1.

The Eden patch

Tier 1 — declarative policy. The recorded policy denies requests to /wp-content/themes 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.

{
  "version": 1,
  "profile": "http-structure-v1",
  "policy": {
    "version": 1,
    "rules": [
      {
        "scope": {
          "methods": [],
          "path": "/wp-content/themes",
          "descendants": true
        },
        "require": {
          "kind": "deny"
        }
      }
    ]
  }
}

Tier 2 — native Rust module. gabriel_wppagetpl_v1 waits for the request to be complete, checks whether the request target starts with /wp-content/themes, and looks for any configured marker in the request target. 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.

const ROUTE: &[u8] = b"/wp-content/themes";
static NEEDLES: [&[u8]; 2] = [b"../", b"..%2F"];

NEEDLES.iter().any(|n| find_ignore_case(target, 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 /wp-content/themes 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.

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

3. Verify the serving policy. Read back the interlay.

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 both recorded probes in an isolated fixture. The baseline recorded no marker, so the check establishes request refusal for the tested bytes. 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 to select the fixed release for the installed branch. Reported fixed releases include 7.1.2. Follow the vendor’s 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. GET /wp-content/themes/twentytwelve/page.php for the benign probe and the same request path with a traversal query for the second probe.

The benign probe was a GET for a theme PHP path. The second added a template query containing parent directory segments. Both requests had empty bodies. The fixture’s marker detector reads the body, while the module scans the request target and can see the query.

Measured comparison (2026-11-12 UTC)

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

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 79028f1cb227dfaf64d04b641b5f02dcc25eb5f5b9f9d9557b2adcf491724858
• Tested binary SHA-256 b61652fc1bd51b514d7d4c7f7294b0ed4c4d5f9a6c682d4d44143a670b58da11

Test scope

The baseline returned 200 with zero observed marker change. The module refused the same request with 403, demonstrating request filtering. The fixture did not establish a vulnerable template lookup, PHP inclusion, or an effect that the filter prevented. URL normalization and alternative encodings were outside the test.

Performance

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

Evidence and artifacts

• Public CVE record
• Vendor or publisher advisory
• Published module source