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
6 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
Go github.com/ory/oathkeeper < 0.40.10-0.20260320084758-8e0002140491
Fixed in
0.40.10-0.20260320084758-8e0002140491· Vendor fix available
Issue
Ory Oathkeeper is vulnerable to an authorization bypass via HTTP path traversal. An attacker can craft a URL containing path traversal sequences (e.g. /public/../admin/secrets) that resolves to a protected path after normalization, but is matched against a permissive rule because the raw, un-normalized path is used during rule evaluation. Preconditions Ory Oathkeeper rules are typically configured with patterns like: Without path normalization, a request to /public/../admin/secrets is matched against the raw path /public/../admin/secrets. This matches the /public/<. rule, bypassing the authentication required for /admin/secrets. After Ory Oathkeeper permits the request, the upstream server normalizes the path and serves the protected /admin/secrets resource. Mitigation Going forward, Ory Oathkeeper normalizes the request path before performing rule matching and before forwarding. The path /public/../admin/secrets is normalized to /admin/secrets, which correctly matches…
Recommended action: Upgrade to 0.40.10-0.20260320084758-8e0002140491 (pre-release) or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Go github.com/ory/oathkeeper < 0.40.10-0.20260320084801-198a2bc82a99
Fixed in
0.40.10-0.20260320084801-198a2bc82a99· Vendor fix available
Issue
Ory Oathkeeper is vulnerable to authentication bypass due to cache key confusion. The oauth2introspection authenticator cache does not distinguish tokens that were validated with different introspection URLs. An attacker can therefore legitimately use a token to prime the cache, and subsequently use the same token for rules that use a different introspection server. Preconditions Ory Oathkeeper has to be configured with multiple oauth2introspection authenticator servers, each accepting different tokens. The authenticators also must be configured to use caching. An attacker has to have a way to gain a valid token for one of the configured introspection servers. Mitigation Ory Oathkeeper now includes the introspection server URL in the cache key, preventing confusion of tokens. Update to the patched version of Ory Oathkeeper. If that is not immediately possible, disable caching for oauth2introspection authenticators.
Recommended action: Upgrade to 0.40.10-0.20260320084801-198a2bc82a99 (pre-release) or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Go github.com/ory/oathkeeper < 0.40.10-0.20260320084810-e9acca14a04d
Fixed in
0.40.10-0.20260320084810-e9acca14a04d· Vendor fix available
Issue
Ory Oathkeeper is often deployed behind other components like CDNs, WAFs, or reverse proxies. Depending on the setup, another component might forward the request to the Oathkeeper proxy with a different protocol (http vs. https) than the original request. In order to properly match the request against the configured rules, Oathkeeper considers the X-Forwarded-Proto header when evaluating rules. The configuration option serve.proxy.trustforwardedheaders (defaults to false) governs whether this and other X-Forwarded- headers should be trusted. Oathkeeper did not properly respect this configuration, and would always consider the X-Forwarded-Proto header. Preconditions In order for an attacker to abuse this, an installation of Ory Oathkeeper needs to have distinct rules for HTTP and HTTPS requests. Also, the attacker needs to be able to trigger one but not the other rule. In this scenario, the attacker can send the same request but with the X-Forwarded-Proto header in order…
Recommended action: Upgrade to 0.40.10-0.20260320084810-e9acca14a04d (pre-release) or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact Downstream services relying on the presence of headers set by the header mutator could be exploited. A client can drop the header set by the header mutator by including that header's name in the Connection header. Example minimal config: The X-Subject header will not arrive at the downstream server. It is completely dropped. In case the downstream server handles such a request in an unexpected way, an attacker can exploit this, assuming they know or guess the internal header name. Patches c5cc7f736dc84185034be4356057d1c7a656d797 Workarounds The downstream server should handle the case that an expected header is not set by responding with an appropriate error. References See background info in https://github.com/golang/go/issues/50580
Recommended action: Upgrade to 0.40.3 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Go github.com/ory/oathkeeper >= 0.38.0-beta.2, <= 0.38.11-beta.1
Fixed in
0.38.12-beta.1· Vendor fix available
Issue
ORY Oathkeeper is an Identity & Access Proxy (IAP) and Access Control Decision API that authorizes HTTP requests based on sets of Access Rules. When you make a request to an endpoint that requires the scope foo using an access token granted with that foo scope, introspection will be valid and that token will be cached. The problem comes when a second requests to an endpoint that requires the scope bar is made before the cache has expired. Whether the token is granted or not to the bar scope, introspection will be valid. A patch will be released with v0.38.12-beta.1. Per default, caching is disabled for the oauth2introspection authenticator. When caching is disabled, this vulnerability does not exist. The cache is checked in func (a AuthenticatorOAuth2Introspection) Authenticate(...). From tokenFromCache() it seems that it only validates the token expiration date, but ignores whether the token has or not the proper scopes. The vulnerability was introduced in PR #424. During review, we…
Recommended action: Upgrade to 0.38.12-beta.1 (pre-release) or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Go github.com/ory/oathkeeper >= 0.38.0-beta.2, <= 0.38.11-beta.1
Fixed in
0.38.12-beta.1· Vendor fix available
Issue
Impact When you make a request to an endpoint that requires the scope foo using an access token granted with that foo scope, introspection will be valid and that token will be cached. The problem comes when a second requests to an endpoint that requires the scope bar is made before the cache has expired. Whether the token is granted or not to the bar scope, introspection will be valid. Patches A patch will be released with v0.38.12-beta.1. Workarounds Per default, caching is disabled for the oauth2introspection authenticator. When caching is disabled, this vulnerability does not exist. Trace The cache is checked in func (a AuthenticatorOAuth2Introspection) Authenticate(...). From tokenFromCache() it seems that it only validates the token expiration date, but ignores whether the token has or not the proper scopes. Post-Mortem The vulnerability was introduced in PR #424. During review, we failed to require appropriate test coverage by the submitter which is the primary reason that the…
Recommended action: Upgrade to 0.38.12-beta.1 (pre-release) or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.