Zalando Skipper CVE-2026-86043

Requires Skipper deployed with the opaAuthorizeRequestWithBody filter and an Open Policy Agent policy that inspects the request body AND explicitly allows requests when input.truncated_body == false (the recommended prior mitigation for CVE-2026-50197). The attacker must send a body exceeding the configured maxBodyBytes using HTTP/1.1 Transfer-Encoding: chunked or an HTTP/2 request that omits Content-Length, so Skipper's truncated-body signal (derived from Content-Length) reads false. Limiting factors: this is a non-default configuration - installations that do not use OPA body authorization, or whose policies do not key on truncated_body, are unaffected; requests that carry an accurate Content-Length are correctly flagged as truncated and denied.

This is a genuine unauthenticated remote authorization bypass (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N, CWE-863), but its real-world risk is materially narrower than the 7.5 base score implies because exploitation is heavily gated on a specific, non-default deployment. It only bites when Skipper is configured with the opaAuthorizeRequestWithBody filter AND the Open Policy Agent policy inspects the body and permits requests where input.truncated_body == false - i.e. a policy that already followed the prior CVE-2026-50197 mitigation. No EPSS score, KEV entry, or standalone public exploit was provided, so this is 'no public exploit identified at time of analysis'; however, the fix commit (2cfceabaa6) ships a reproducing test (TestTruncatedBodyChunkedBypass) that demonstrates the bypass, lowering the bar for weaponization. Conflicting signal to verify: the CVSS I:H rates the integrity impact as total, but the actual damage is bounded by what the protected upstream does with an oversized body that slipped past a size/content policy - the base I:H is defensible for a bypassed authorization control but the concrete impact is upstream-dependent. Net: this is a real priority ONLY for shops running Skipper's OPA body-authorization filter with truncation-aware policies; for everyone else it is a high-CVSS-but-low-real-risk item.

An attacker sends a POST to a Skipper-fronted service using Transfer-Encoding: chunked (or HTTP/2 with no Content-Length) carrying a body larger than maxBodyBytes. Skipper truncates the body to the limit but, because input.truncated_body is derived from the (absent/unreliable) Content-Length rather than the actual read, the OPA policy sees truncated_body == false, evaluates only the truncated prefix, and authorizes the request - after which the full oversized body is forwarded to the protected upstream. A reproducing test case exists in the public fix commit, though no separate weaponized exploit was reported.