Skipper EUVD-2026-48437

Exploitation requires the target to run Skipper as an OPA-authorizing proxy using the opaAuthorizeRequestWithBody filter with a configured maxBodyBytes/WithMaxRequestBodyBytes limit and a deny-on-presence Rego policy (default allow = true; allow = false if input.parsed_body.<forbidden>). The concrete trigger is a request whose declared Content-Length exceeds maxBodyBytes, which causes ExtractHttpBodyOptionally to return a nil body and OPA to evaluate an empty parsed_body while the full payload is forwarded upstream. Per the CVSS vector (AV:N/AC:L/PR:N/UI:N) the attacker needs no authentication and no user interaction, so the sole limiting factor is this non-default body-based authorization configuration; deployments not authorizing on body content are unaffected.

The supplied CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:N/UI:N, base 8.8) indicates a network-reachable, low-complexity, unauthenticated attack, which is consistent with the described technique of simply inflating the request body. No EPSS score, KEV entry, or SSVC decision was provided, so probability-of-exploitation and automatability cannot be quantified from this data; there is no evidence of active exploitation. The practical risk is gated by deployment: it only matters where Skipper uses opaAuthorizeRequestWithBody with deny-on-presence Rego policies and a maxBodyBytes limit - a non-default authorization pattern. Where that pattern exists, real risk is high because exploitation is trivial and the advisory ships a working PoC, but the population of affected deployments is narrower than the raw 8.8 suggests. Note a conflict between vendor VC:H (confidentiality) and the actual described impact, which is primarily unauthorized forbidden actions reaching upstream (an integrity/authorization-bypass effect) - verify the impact type against your specific policies.

An attacker targets an API endpoint that Skipper protects with an OPA body-content policy (for example, deny requests where parsed_body.action == "delete"). They send the forbidden JSON payload but append padding so the declared Content-Length exceeds maxBodyBytes; OPA sees an empty parsed_body and allows the request while the full "delete" payload reaches and is executed by the upstream service. A working docker-compose PoC (setup.sh/exploit.sh) is included in the GHSA advisory, and given AV:N/AC:L/PR:N the attack requires only a single crafted HTTP request.