Loading story…
Zalando patched an authorization bypass in Skipper affecting its Open Policy Agent (OPA) integration, where request-body handling could cause policy checks to evaluate an empty, omitted, or unparsed body instead of the actual payload. The flaw affected cases such as HTTP/1.1 requests sent with Transfer-Encoding: chunked and requests that exceeded the configured maxBodyBytes limit, allowing upstream actions to proceed when Rego policies depended on body content to deny them. A proof of concept showed a JSON payload such as {"admin":true} being blocked when sent with Content-Length but incorrectly reaching the upstream service when sent chunked.
The fix was merged in pull request #4041 and released in Skipper v0.26.10, updating body extraction logic so unknown-length requests are buffered up to maxBodyBytes and checked consistently before OPA evaluation. Advisory GHSA-8QQM-FP2Q-V734 warns that vulnerable deployments using allow-by-default policies could mistakenly approve forbidden operations, and recommends fail-closed Rego logic that denies requests when input.attributes.request.http.truncated_body indicates the body was truncated or omitted. Updated container images were also published alongside the release.
See affected versions and whether adversaries are exploiting it.
3 events from the most recent confirmed update back to the earliest known activity.
A GHSA/CVE report described the authorization bypass in Skipper's Open Policy Agent request-body handling, including vulnerable and fixed code paths, impact, and mitigation guidance. It also documented the CVSS v3.1 rating and recommended fail-closed Rego policy logic when request bodies are truncated or omitted.
Zalando published Skipper release v0.26.10, whose primary security-relevant change was the fix for the OPA authorization bypass tracked in issue #4041. The release notes also pointed users to updated container images.
Zalando merged pull request #4041 into Skipper's master branch to fix a security-related OPA authorization bypass issue. The associated commit and PR indicate the change was treated as a security bugfix and included proof-of-concept coverage.
Vulnerabilities, threat actors, malware, products, organizations, and breaches Mallory has linked to this story.
See whether adversaries are exploiting this yet, and where the affected versions run in your environment.
4 references tracked. Mallory keeps watching after this page renders.
cvereports.com
Open sourcegithub.com
Open sourcegithub.com
Open sourcegithub.com
Open sourceMap indicators from this story to your assets and identify affected systems in minutes.
Every observed campaign, victim, and pivot linked to actors named in this story.
Malware, exploits, and IOCs connected to the activity described here.
YARA, Sigma, and Snort rules deployed to your SIEM as soon as they’re published.
Get matching new stories delivered to your team as they break — not the next morning.
Ask questions about this story and take action on the answers.
Other stories Mallory is tracking that overlap on entities, sources, or topic labels.
Docker disclosed a high-severity Docker Engine vulnerability, **CVE-2026-34040** (`CVSS 8.8`), that allows attackers to bypass authorization plugins and perform actions that should be blocked. The flaw stems from an incomplete fix for **CVE-2024-41110** and is triggered when a specially crafted oversized Docker API request causes the request body to be dropped before inspection by an AuthZ plugin. In affected environments, the plugin may approve container operations it would otherwise deny, opening a path to unauthorized privileged actions and potential host compromise. Researchers said an attacker with Docker API access could exploit the bug by padding a container-creation request beyond **1 MB** to launch a privileged container with access to the host filesystem, exposing sensitive assets such as **AWS credentials**, **SSH keys**, and **Kubernetes configurations**. The issue affects deployments that rely on authorization plugins inspecting request bodies, while environments not using those plugins are not impacted. Docker patched the vulnerability in **Docker Engine 29.3.1** and urged defenders to upgrade, restrict Docker API access, avoid AuthZ plugins that depend on request-body inspection, and use controls such as rootless mode, user namespace remapping, and least-privilege access to reduce risk.
Jul 23, 2026
Two high-severity vulnerabilities in **OAuth2 Proxy** can let unauthenticated remote attackers reach protected upstream resources in specific reverse-proxy deployments. `CVE-2026-34457` affects versions prior to **7.15.2** when OAuth2 Proxy is used with **auth_request**-style integrations such as nginx `auth_request` and either `--ping-user-agent` or `--gcp-healthchecks` is enabled. In that configuration, any request carrying the configured health-check User-Agent can be treated as a successful health check regardless of the requested path, creating an authentication bypass. The flaw is tracked as **CWE-290** and carries a **CVSS 3.1** score vector of `AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N`. A second flaw, `CVE-2026-40575`, affects OAuth2 Proxy versions **7.5.0 through 7.15.1** when `--reverse-proxy` is enabled alongside `--skip-auth-regex` or `--skip-auth-route`. In those setups, the product may trust a client-supplied `X-Forwarded-Uri` header, allowing attackers to spoof the header so authentication and skip-auth rules are evaluated against a different path than the one actually forwarded upstream. Both issues were fixed in **OAuth2 Proxy 7.15.2**. Recommended mitigations include upgrading immediately, stripping or overwriting `X-Forwarded-Uri`, restricting direct access to OAuth2 Proxy, and narrowing or removing skip-auth rules where possible.
Jun 29, 2026
A high-severity flaw tracked as **CVE-2026-33186** allows attackers to bypass path-based authorization in **gRPC-Go** by sending malformed HTTP/2 requests whose `:path` pseudo-header omits the required leading slash. In affected versions before **1.79.3**, the server still routed requests correctly, but authorization components evaluated the non-canonical path value, creating a mismatch that let canonical deny rules fail. The issue affects deployments using **`google.golang.org/grpc/authz`** RBAC as well as custom interceptors that rely on **`info.FullMethod`** or **`grpc.Method(ctx)`** while otherwise permitting requests by default. Reports say the flaw can also impact products and middleware built on gRPC-Go, including **Traefik** custom middleware, where policies written for paths such as `/InternalService/SensitiveMethod` could be bypassed with malformed variants like `InternalService/SensitiveMethod`. Exploitation requires the ability to send raw HTTP/2 frames directly to a gRPC server. The fix in **gRPC-Go 1.79.3** rejects any request whose `:path` does not begin with `/` and returns a **`codes.Unimplemented`** error; recommended mitigations also include adding request-validation interceptors, normalizing requests upstream, and tightening authorization policies.
Jun 29, 2026