Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
9 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
- Affected component: filters/openpolicyagent/openpolicyagent.go → ExtractHttpBodyOptionally; combined with github.com/open-policy-agent/opa-envoy-plugin envoyauth/request.go → getParsedBody / checkIfHTTPBodyTruncated. Filter: opaAuthorizeRequestWithBody. - Affected versions: <= 0.27.33 (current HEAD e7d7014c). The truncatedbody mitigation was introduced/recommended in v0.27.26 (advisory GHSA-8qqm-fp2q-v734) and remains bypassable. - Fix chain being audited: CVE-2026-50197 (GHSA-659f-rgp5-w4wf, commit 3152f3b0) → GHSA-8qqm-fp2q-v734 (docs + code, commit 1be950cd #4126, v0.27.26). This finding is the third, still-open variant. Summary Skipper's opaAuthorizeRequestWithBody filter authorizes requests by handing the (bounded) request body to Open Policy Agent. When a body exceeds -open-policy-agent-max-request-body-size (default 1 MB), Skipper truncates it before OPA sees it. Advisory GHSA-8qqm-fp2q-v734 established that deny-on-presence / body-inspecting policies fail OPEN on oversized…
Recommended action: Upgrade to 0.27.37 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
A wrong policy can be an open door. You have to check input.attributes.request.http.truncatedbody in your policy. Description Incomplete fix for CVE-2026-50197: an oversized declared-Content-Length body still hands OPA an empty parsedbody, so deny-on-presence Rego policies fail OPEN while the full payload reaches upstream. The CVE-2026-50197 fix (commit 3152f3b0, PR #4041, v0.26.10) substituted expectedSize = maxBodyBytes only when req.ContentLength < 0 (chunked / HTTP/2 without content-length). But when a request declares a Content-Length larger than maxBodyBytes, expectedSize maxBodyBytes, the body-extraction if is skipped entirely, and ExtractHttpBodyOptionally returns rawBodyBytes = nil — so OPA evaluates an empty parsedbody, while the full forbidden payload still flows to the upstream. A deny-on-presence policy (default allow = true; allow = false if input.parsedbody.<forbidden) — the exact Rego shape the advisory describes — fails OPEN. The fix's own comment reasons…
Recommended action: Upgrade to 0.27.26 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The routesrv component exposes the full cluster route topology (Ingress/RouteGroup configurations, backend URLs, filter chains, OAuth/OIDC callback paths) and cache-cluster topology (Redis/Valkey shard addresses) over plain HTTP with zero authentication. Any pod in the Kubernetes cluster can reach routesrv via its predictable DNS name and retrieve sensitive cluster-wide routing and cache infrastructure data. Vulnerable Code routesrv/routesrv.go:87-99,114-137 — all handler registrations on the main mux: routesrv/eskipbytes.go:134-196 — eskipBytes.ServeHTTP: routesrv/redishandler.go:28-41 — RedisHandler.ServeHTTP: routesrv/valkeyhandler.go:28-41 — ValkeyHandler.ServeHTTP: Attack Path 1. Initial Compromise: Attacker compromises any pod in the Kubernetes cluster (via application CVE, supply-chain attack, malicious container image, etc.) 2. Discovery: Attacker discovers routesrv via predictable Kubernetes DNS name: skipper-ingress-routesrv.kube-system.svc.cluster.local:9090…
Recommended action: Upgrade to 0.27.13 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The Kubernetes admission webhook handler reads the entire request body using io.ReadAll(r.Body) without any size limit. Any client that can reach the webhook port within the cluster can send a multi-GB payload, causing the skipper process to exhaust memory and be OOM-killed. This disrupts all Kubernetes admission control, potentially blocking all pod creation and updates. Vulnerable Code For comparison, the OPA filter has a body size limit: Attack Path 1. Attacker identifies the admission webhook endpoint (default: :9443/admission or configured path) 2. Attacker sends: POST /admission HTTP/1.1, Content-Type: application/json with a multi-GB request body 3. io.ReadAll(r.Body) allocates unbounded memory for the entire body 4. Skipper process is OOM-killed by the Kubernetes kubelet Permission Boundary Analysis - Attacker: Any client with network access to the admission webhook port within the Kubernetes cluster - Boundary crossed: Memory safety — unbounded allocation from…
Recommended action: Upgrade to 0.26.22 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
zalando/skipper's OpenPolicyAgent integration silently bypasses request-body inspection on HTTP/1.1 Transfer-Encoding: chunked and HTTP/2 requests that omit the content-length pseudo-header. When the opaAuthorizeRequestWithBody filter is configured, the OpenPolicyAgentInstance.ExtractHttpBodyOptionally helper produces an empty rawbody for any request whose Content-Length header is missing, while the underlying chunked body still flows through to the upstream service. Rego policies that gate on input.parsedbody (e.g. "deny when a forbidden field is present") evaluate against an empty document, treat the forbidden field as absent, and authorize the request. The upstream handler then receives the full attacker payload that the policy intended to block. Affected versions github.com/zalando/skipper versions <= v0.26.8 (the latest release on 2026-05-26, current master 4eed47ff). The vulnerable helper and gate have lived in filters/openpolicyagent/openpolicyagent.go since the…
Recommended action: Upgrade to 0.26.10 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact When running Skipper as an Ingress controller, users with permissions to create an Ingress and a Service of type ExternalName can create routes that enable them to use Skipper's network access to reach internal services. Patches https://github.com/zalando/skipper/releases/tag/v0.24.0 disables Kubernetes ExternalName by default. Workarounds Developers can allow list targets of an ExternalName by using -kubernetes-only-allowed-external-names=true and allow list via regular expressions -kubernetes-allowed-external-name '^[a-z][a-z0-9-.]+[.].allowed.example$' References https://kubernetes.io/docs/concepts/services-networking/service/#externalname
Recommended action: Upgrade to 0.24.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact Arbitrary code execution through lua filters. The default skipper configuration before v0.23 was -lua-sources=inline,file. The problem starts if untrusted users can create lua filters, because of -lua-sources=inline , for example through a Kubernetes Ingress resource. The configuration inline allows these user to create a script that is able to read the filesystem accessible to the skipper process and if the user has access to read the logs they an read skipper secrets. Kubernetes example (vulnerability is not limited to Kubernetes) Patches https://github.com/zalando/skipper/releases/tag/v0.23.0 disables Lua by default. Workarounds You can reduce support of how you can pass lua filter script data by providing config for lua sources https://opensource.zalando.com/skipper/reference/scripts/#enable-and-disable-lua-sources. For example -lua-sources=file will only be exploitable if the attacker can create a lua script file on the target system. References…
Recommended action: Upgrade to 0.23.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact Skipper prior to version v0.13.236 is vulnerable to server-side request forgery (SSRF). An attacker can exploit a vulnerable version of proxy to access the internal metadata server or other unauthenticated URLs by adding an specific header (X-Skipper-Proxy) to the http request. Patches The problem was patched in version https://github.com/zalando/skipper/releases/tag/v0.13.237. Users need to upgrade to skipper =v0.13.237. Workarounds Use dropRequestHeader("X-Skipper-Proxy") filter References https://github.com/zalando/skipper/releases/tag/v0.13.237 For more information If you have any questions or comments about this advisory: Open an issue in https://github.com/zalando/skipper/issues/new/choose Chat with us in slack: https://app.slack.com/client/T029RQSE6/C82Q5JNH5
Recommended action: Upgrade to 0.13.237 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
In Zalando Skipper before 0.13.218, a query predicate could be bypassed via a prepared request.
Recommended action: Upgrade to 0.13.218 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.