Apache mod_session: cookie not removed during internal redirect (CVE-2026-47360)

An internal redirect can forward a session cookie to a backend even when Apache was configured to remove it. Upgrade the affected session module to protect cookies that should stay at the gateway.

Public CVE record · Vendor or publisher advisory

cve.now entry. The experiment used a synthetic HTTP fixture.

Eden terminates the HTTP connection to the affected product, evaluates a declarative policy and — in tier 2 — a separately compiled native Rust module under signed module authority, before any byte reaches the application. It does not patch the affected component; the vendor's fixed release remains the durable repair.

Status: Declarative route-deny fixture comparison recorded. The fixture ran against Eden 1.103.0.

The vulnerability

mod_session fails to clear session cookies across internal redirects, leaking session state (high, 7.5). Cookie persistence across a redirect chain is stateful and not expressible in a stateless request-stage module; tier-2 is NA-grade and the tier-1 window deny is proven live.

The Eden patch

Tier 1 — declarative policy (blunt, fail-closed): deny every request under /internal (non-slash scope), legitimate traffic included — false positives measured below.

Tier 2: the case records a declarative result. The test scope below explains the native module limitation.

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 this reconstruction of the report’s scoped fixture deny.
2. Apply the declarative policy. Scope the policy to /internal 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 declaration as remediation.json.

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

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 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 to identify the supported update or workaround for the installed release. The advisory data used here supplies no fixed version. Confirm the running version and verify the affected feature after the change.

Measured comparison (2026-11-12 UTC)

The comparison covers the baseline and the declarative route deny:

• Baseline (no remediation): benign 200, attack 200 with the primitive recorded at the fixture oracle
• Tier 1 (deny): both probes refused 403 (blunt, false positives included)
• Tier 2 (module): pass-through — no module (NA-grade)

Authority lifecycle and negatives

Tier-1 window deny applied and revoked live; no tier-2 module exists for this stateful primitive.

Test scope

The fixture reproduces the delivery shape with a harmless marker effect, not the full product surface. Bypass variants (encodings, alternate routes, sibling entry points) are not bypass-tested; the rule is a lab-grade partial by construction. See the tier-2 note above for this case's stateful or transport-level limitation.

Performance trace (Eden telemetry)

Measured with Eden's built-in request telemetry (gateway.request.baseline spans, read back through /api/v1/analytics/telemetry?signal=traces), not client wall-clock. Latency Eden introduces per remediation arm for this case:

This case is tier-1-only: the exploit primitive is stateful, so no tier-2 module exists (see Test scope).

Measurements describe declarative refusals for fresh connections to a single-host lab fixture.

Evidence and artifacts

• Public CVE record
• Vendor or publisher advisory