Loading story…
A high-severity flaw tracked as CVE-2026-54603 affects the Ruby oauth2 library and can leak bearer credentials during redirect handling. In versions 0.4.0 through 2.0.21, a protocol-relative Location header processed by OAuth2::Client#request can override the intended authority, causing the Authorization header to be forwarded to an attacker-controlled host. The issue is classified under CWE-200 and CWE-601 and carries a CVSS 3.1 vector of AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:N/A:N.
The maintainers released oauth2 v2.0.22 with a fix that prevents protocol-relative redirects from changing request authority and strips Authorization headers from cross-origin redirects. A related GitHub commit shows added tests confirming that credentials remain on same-origin redirects, are removed on cross-origin redirects, and that cross-origin redirects can still proceed when no credential headers are present. GitHub also published a security advisory for the issue, and users are urged to upgrade to the patched release.
See affected versions and whether adversaries are exploiting it.
3 events from the most recent confirmed update back to the earliest known activity.
On 2026-06-07, ruby-oauth released version 2.0.22 containing the security fix for advisory GHSA-pp92-crg2-gfv9. The release notes state it prevents protocol-relative redirects from changing request authority and removes Authorization headers from cross-origin redirects.
On 2026-06-07, a commit to ruby-oauth/oauth2 changed redirect handling so protocol-relative Location headers could not change request authority and stripped Authorization headers on cross-origin redirects. The patch also added tests covering same-origin and cross-origin redirect behavior.
CVE-2026-54603 was disclosed as affecting ruby-oauth oauth2 versions 0.4.0 through 2.0.21, where a protocol-relative redirect could override the intended authority and leak bearer Authorization headers to an attacker-controlled host. The CVE record notes the issue is fixed in version 2.0.22.
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.
cvefeed.io
Open sourcecvereports.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.
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
ORY disclosed two high-severity vulnerabilities in **Oathkeeper** that can let attackers bypass access controls in deployments running versions prior to `26.2.0`. `CVE-2026-33496` is an authentication bypass in the `oauth2_introspection` authenticator caused by cache key confusion: cached token validation results do not distinguish between different introspection server URLs. In affected environments, an attacker with a valid token for one configured introspection server may be able to have that result reused against another server if caching is enabled and multiple introspection backends accept different tokens. ORY also fixed `CVE-2026-33494`, an authorization bypass caused by HTTP path traversal when Oathkeeper evaluates raw, unnormalized request paths against access rules. An attacker can craft requests such as: ```text /public/../admin/secrets ``` so the request matches a permissive rule before normalization but reaches a protected resource afterward. Both issues were addressed in **Oathkeeper `26.2.0`**, with ORY recommending upgrades; for `CVE-2026-33496`, disabling caching for `oauth2_introspection` authenticators is listed as a workaround where immediate patching is not possible.
Jun 29, 2026
Flowise fixed two closely related flaws in its OAuth2 credential refresh functionality that allowed unauthenticated access to `POST /api/v1/oauth2-credential/refresh/:credentialId`. In versions before 3.1.3, tracked as **CVE-2026-70478**, the endpoint was placed in `WHITELIST_URLS` without authentication, letting an attacker who knew a credential ID decrypt stored OAuth details, trigger a refresh with the provider, and receive the new access token in the response. The issue exposed connected third-party services to token theft and could also be abused to consume refresh-token quotas. A follow-on bug, **CVE-2026-70636**, showed the earlier fix was incomplete and that Flowise through 3.1.4 still allowed authentication bypass through prefix-based whitelist matching. Researchers reported that crafted requests with a trailing credential identifier could still reach the refresh handler, which refreshed and updated OAuth credentials without validating caller identity, workspace ownership, or RBAC permissions. The flaw enabled cross-workspace token rotation and unauthorized mutation of credential state, and was described as a bypass of an earlier remediation tied to `GHSA-6f7g-v4pp-r667`.
Aug 7, 2026