Zalando Skipper CVE-2026-65838

Exploitation requires ALL of the following conditions simultaneously: (1) Skipper is deployed with the opaAuthorizeRequestWithBody filter (not opaAuthorizeRequest, which does not parse the body); (2) the associated OPA Rego policy uses deny-on-presence logic that inspects input.parsed_body fields (e.g., allow = false if input.parsed_body.<field> == <value>); (3) the Rego policy does NOT include a guard on input.attributes.request.http.truncated_body or input.truncated_body; and (4) the attacker can craft a request body that exceeds -open-policy-agent-max-request-body-size (default 1048576 bytes / 1 MB) by padding the payload while keeping the forbidden field present. Deployments using opaAuthorizeRequest (without body), policies that default-deny rather than deny-on-presence, policies that already check the truncated_body signal, or body sizes consistently under the limit are not affected. The original chunked-body vector from CVE-2026-50197 is fixed in v0.26.10 and is not reintroduced here.

The NVD-assigned CVSS vector (AV:N/AC:L/PR:N/UI:N/C:H/I:L) overstates the impact profile in two ways: complexity is genuinely high because exploitation requires the specific combination of opaAuthorizeRequestWithBody deployment, a deny-on-presence Rego policy that inspects parsed_body, a policy that does NOT check truncated_body, and a request body exceeding the size limit; and the primary impact is integrity (forbidden operations reaching the protected upstream), not confidentiality. The C:H/I:L assignment appears inverted relative to the actual threat model. The EPSS score is not provided, but given the configuration-gated nature of the flaw and the niche product footprint, real-world exploitation probability is moderate at most. There is no KEV listing and no standalone public exploit identified - only a researcher-provided Docker Compose reproduction harness in the GHSA advisory. Even a mid-sized municipal IT team in leszno running Skipper as an API gateway with OPA body-based authorization would only be exposed if they have deny-on-presence Rego policies that omit the truncated_body guard, a condition that many well-audited policies would already handle. The fail-open consequence is severe for the specific affected pattern, but the preconditions meaningfully limit exposed population. Defenders should audit Rego policies for any if input.parsed_body.<field> deny logic and verify the truncated_body guard is present regardless of patch status.

An attacker targeting a microservice protected by a Skipper proxy configured with opaAuthorizeRequestWithBody and a deny-on-presence policy (e.g., allow = false if input.parsed_body.action == 'delete') sends a POST request containing the forbidden payload padded to exceed the 1 MB OPA body-size limit, declaring the full size in Content-Length. Skipper's ExtractHttpBodyOptionally skips body extraction, OPA evaluates an empty parsed_body and returns allow, and the complete body - including the forbidden action: delete field - is forwarded to the upstream service. No public exploit tool exists at time of analysis, but the GHSA advisory includes a Docker Compose reproduction harness demonstrating the bypass from a 403 to a 200 status.