Summary
A redirect handling flaw in the Ruby OAuth2 gem causes bearer Authorization headers to be sent to attacker-controlled hosts when protocol-relative redirects are followed.
Under certain redirect responses, this can leak OAuth access tokens or other bearer credentials to third parties that control the redirection target.
A redirect handling flaw in the Ruby OAuth2 gem causes bearer Authorization headers to be sent to attacker-controlled hosts when protocol-relative redirects are followed.
Under certain redirect responses, this can leak OAuth access tokens or other bearer credentials to third parties that control the redirection target.
Affected context
The vulnerability affects applications using the Ruby OAuth2 gem (versions 0.4.0 through 2.0.21) that:
- Rely on
OAuth2::Client#requestto follow HTTP redirects from authorization or API endpoints - Process responses that include protocol-relative
Locationheaders (e.g.,//attacker.example.com/path) - Use bearer tokens in the
Authorizationheader for OAuth 2.0 / 2.1 or OIDC flows
In these conditions, the redirect logic may change the request authority in a way that sends sensitive Authorization headers to a host not originally intended by the client.
The vulnerability affects applications using the Ruby OAuth2 gem (versions 0.4.0 through 2.0.21) that:
- Rely on
OAuth2::Client#requestto follow HTTP redirects from authorization or API endpoints - Process responses that include protocol-relative
Locationheaders (e.g.,//attacker.example.com/path) - Use bearer tokens in the
Authorizationheader for OAuth 2.0 / 2.1 or OIDC flows
In these conditions, the redirect logic may change the request authority in a way that sends sensitive Authorization headers to a host not originally intended by the client.
Exploit preconditions
- Attack surface: HTTP(S) interactions where the OAuth2 client follows server redirects (authorization server, resource server, or intermediary endpoints).
- Required access: Ability for an attacker to cause or control an HTTP response with a protocol-relative
Locationheader observed by the OAuth2 client (e.g., compromised endpoint, malicious proxy, or untrusted OAuth / OIDC provider). - Trigger point: The
OAuth2::Client#requestmethod receives a redirect response and automatically follows the protocol-relativeLocationURL. - Why exploitation is possible: The redirect handling treats a protocol-relative URL as authoritative and preserves the bearer
Authorizationheader across the redirect, allowing credentials to be sent to a different, attacker-controlled authority.
- Attack surface: HTTP(S) interactions where the OAuth2 client follows server redirects (authorization server, resource server, or intermediary endpoints).
- Required access: Ability for an attacker to cause or control an HTTP response with a protocol-relative
Locationheader observed by the OAuth2 client (e.g., compromised endpoint, malicious proxy, or untrusted OAuth / OIDC provider). - Trigger point: The
OAuth2::Client#requestmethod receives a redirect response and automatically follows the protocol-relativeLocationURL. - Why exploitation is possible: The redirect handling treats a protocol-relative URL as authoritative and preserves the bearer
Authorizationheader across the redirect, allowing credentials to be sent to a different, attacker-controlled authority.
Why this happens
The root cause is improper handling of protocol-relative redirect URLs in the OAuth2 gem's HTTP client.
When encountering a redirect with a Location such as //evil.example.com/callback, the library constructs the follow-up request using the authority from the redirect target but continues to include the original bearer Authorization header.
This behavior embodies CWE-601: Open Redirect in combination with CWE-200: Exposure of Sensitive Information, because authentication headers are automatically reused across redirects without constraining the authority or enforcing stricter origin checks.
Abstractly, the bug arises from trusting redirect targets as equivalent to the original endpoint and not scoping credentials to the original host or an explicit allowlist of trusted domains.
The root cause is improper handling of protocol-relative redirect URLs in the OAuth2 gem's HTTP client.
When encountering a redirect with a Location such as //evil.example.com/callback, the library constructs the follow-up request using the authority from the redirect target but continues to include the original bearer Authorization header.
This behavior embodies CWE-601: Open Redirect in combination with CWE-200: Exposure of Sensitive Information, because authentication headers are automatically reused across redirects without constraining the authority or enforcing stricter origin checks.
Abstractly, the bug arises from trusting redirect targets as equivalent to the original endpoint and not scoping credentials to the original host or an explicit allowlist of trusted domains.
Potential impact
- OAuth access tokens and other bearer credentials can be sent to attacker-controlled domains.
- Attackers may reuse stolen tokens to impersonate users against legitimate OAuth or OIDC-protected APIs.
- Compromise of user accounts or sessions at downstream services that trust the leaked tokens.
- Exposure of scopes and permissions associated with the leaked token, enabling broader data access.
- Potential compliance violations due to leakage of authentication secrets to untrusted infrastructure.
- OAuth access tokens and other bearer credentials can be sent to attacker-controlled domains.
- Attackers may reuse stolen tokens to impersonate users against legitimate OAuth or OIDC-protected APIs.
- Compromise of user accounts or sessions at downstream services that trust the leaked tokens.
- Exposure of scopes and permissions associated with the leaked token, enabling broader data access.
- Potential compliance violations due to leakage of authentication secrets to untrusted infrastructure.
General mitigation guidance
Effective mitigation focuses on tightening redirect and credential-scoping behavior:
- Treat redirect targets as untrusted by default and avoid forwarding bearer tokens to a different authority unless explicitly allowed.
- Constrain the set of domains to which OAuth clients will follow redirects using an allowlist of trusted hosts.
- Strip or selectively re-attach
Authorizationheaders on redirects, especially when the authority or scheme changes. - Separate authentication contexts per host: do not reuse tokens or headers across distinct domains.
- Implement defense-in-depth by minimizing token lifetimes, using narrowly scoped tokens, and favoring sender-constrained tokens (e.g., bound to client keys) where possible.
- Log and monitor unexpected redirect destinations during OAuth flows to identify potential misconfigurations or malicious behavior.
Effective mitigation focuses on tightening redirect and credential-scoping behavior:
- Treat redirect targets as untrusted by default and avoid forwarding bearer tokens to a different authority unless explicitly allowed.
- Constrain the set of domains to which OAuth clients will follow redirects using an allowlist of trusted hosts.
- Strip or selectively re-attach
Authorizationheaders on redirects, especially when the authority or scheme changes. - Separate authentication contexts per host: do not reuse tokens or headers across distinct domains.
- Implement defense-in-depth by minimizing token lifetimes, using narrowly scoped tokens, and favoring sender-constrained tokens (e.g., bound to client keys) where possible.
- Log and monitor unexpected redirect destinations during OAuth flows to identify potential misconfigurations or malicious behavior.
How teams detect issues like this
Detection can rely on both code-centric and runtime approaches:
- Static analysis and code review:
- Look for uses of
OAuth2::Client#requestor similar methods where redirects are automatically followed. - Identify code paths that do not validate redirect targets or that reuse
Authorizationheaders across requests without host verification. - Flag logic that accepts or constructs protocol-relative URLs without normalizing or constraining them.
- Configuration and policy checks:
- Enforce policies that require explicit host allowlists for OAuth redirect handling.
- Use automated checks in CI pipelines to search for HTTP clients configured to follow redirects while always including authentication headers.
- Runtime monitoring:
- Inspect HTTP logs to identify outbound requests carrying bearer tokens to unexpected domains.
- Configure security proxies or gateways to block or alert on
Authorizationheaders sent to unapproved hosts. - Automated application security testing tools can be configured to fuzz redirect responses and verify whether credentials are propagated to alternate authorities.
Detection can rely on both code-centric and runtime approaches:
- Static analysis and code review:
- Look for uses of
OAuth2::Client#requestor similar methods where redirects are automatically followed. - Identify code paths that do not validate redirect targets or that reuse
Authorizationheaders across requests without host verification. - Flag logic that accepts or constructs protocol-relative URLs without normalizing or constraining them.
- Configuration and policy checks:
- Enforce policies that require explicit host allowlists for OAuth redirect handling.
- Use automated checks in CI pipelines to search for HTTP clients configured to follow redirects while always including authentication headers.
- Runtime monitoring:
- Inspect HTTP logs to identify outbound requests carrying bearer tokens to unexpected domains.
- Configure security proxies or gateways to block or alert on
Authorizationheaders sent to unapproved hosts. - Automated application security testing tools can be configured to fuzz redirect responses and verify whether credentials are propagated to alternate authorities.
