Description

Skipper is an HTTP router and reverse proxy for service composition. Prior to 0.27.35, the opaAuthorizeRequestWithBody filter in filters/openpolicyagent/openpolicyagent.go can allow an oversized declared Content-Length request to bypass a deny-on-presence Rego policy because ExtractHttpBodyOptionally leaves OPA with an empty parsed_body while forwarding the complete request body upstream. This incomplete remediation of CVE-2026-50197 affects deployments that authorize request-body content and exceed -open-policy-agent-max-request-body-size, which defaults to 1 MB. Policy logic that does not reject input.attributes.request.http.truncated_body can therefore fail open and permit a forbidden payload to reach the protected service, while small bodies and the previously fixed chunked-body case are evaluated normally. This issue is fixed in version 0.27.35.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "8.2",
  "pubDate": "2026-09-14T20:16:49.103Z",
  "pubdate": "2026-09-14T20:16:49.103Z",
  "executiveSummary": "Skipper versions prior to 0.27.35 are susceptible to a security policy bypass vulnerability within the opaAuthorizeRequestWithBody filter. This flaw involves an improper handling of HTTP request bodies that exceed the defined maximum size limit (-open-policy-agent-max-request-body-size, default 1 MB).\nThe vulnerability allows a malicious actor to circumvent Rego-based authorization policies by crafting requests with oversized Content-Length headers. Because the filter's body extraction logic fails to capture the payload for OPA inspection while still forwarding the full request to the upstream service, the security engine receives an empty body. If the OPA policy is not explicitly designed to reject inputs with the truncated_body flag set, it may default to an 'allow' decision.\nThis vulnerability effectively renders OPA authorization ineffective for large request bodies, potentially allowing forbidden or malicious payloads to reach protected backend services. Successful exploitation requires knowledge of the OPA policy logic and the ability to send requests exceeding the configured byte limit. This represents a significant failure in the enforcement of request-body authorization, impacting the integrity and security posture of service compositions relying on Skipper as a proxy.",
  "technicalDetails": "The root cause of this vulnerability lies in the implementation of the opaAuthorizeRequestWithBody filter located in filters/openpolicyagent/openpolicyagent.go. The function ExtractHttpBodyOptionally is responsible for retrieving the request body to pass to the Open Policy Agent (OPA) for authorization evaluation. When a request's Content-Length header indicates a size greater than the configured -open-policy-agent-max-request-body-size, the filter fails to populate the OPA request body object.\nIn this failure state, the internal parsed_body sent to OPA is empty, but the underlying proxy mechanism proceeds to forward the complete, original request body to the upstream service. This creates an authorization gap: the security policy engine makes a determination based on an empty body—which often results in a permit decision—while the backend application processes the full, un-inspected request payload.\nThe attack flow proceeds as follows: First, an attacker identifies a protected endpoint utilizing OPA authorization that inspects the request body. Second, the attacker crafts an HTTP request where the Content-Length exceeds the 1 MB threshold defined by -open-policy-agent-max-request-body-size. Third, Skipper's opaAuthorizeRequestWithBody filter encounters the size limit, truncates or skips the body extraction, and sets the input.attributes.request.http.truncated_body flag within the OPA input data. Fourth, if the specific Rego policy lacks logic to explicitly deny requests when truncated_body is true, the OPA engine returns an 'allow' response. Finally, Skipper forwards the complete, potentially forbidden, payload to the upstream application, bypassing the intended security controls.\nThe issue represents an incomplete remediation of CVE-2026-50197, as it specifically addresses the boundary conditions involving oversized payloads that were previously overlooked. This bypass is limited to cases where the request body exceeds the maximum configured size, while smaller requests and the previously patched chunked-body cases are processed as expected. The vulnerability persists across all versions of Skipper prior to 0.27.35, regardless of the authentication or privilege level of the requester, provided they can interact with the proxy."
}