mechanize

Summary

mechanize applied no trust boundary to a meta refresh, so credentials set through Mechanize#request_headers= followed a refresh that pointed at another origin.

Details

Mechanize::HTTP::Agent#response_follow_meta_refresh fetched the refresh target with no notion of a crossed origin, so @request_headers were re-applied in full. An attacker who could place a meta refresh in a page the agent fetched — through stored content, an open redirect, or control of any page in the crawl — collected the same credentials as through an HTTP redirect, on a code path that had none of the redirect path's protections.

The refresh fetch passes an empty per-request headers hash, so only headers set through Mechanize#request_headers= were exposed.

This requires Mechanize#follow_meta_refresh = true. It is false by default, so an agent in its default configuration is not affected. Crawlers commonly enable it.

Impact

An attacker who can place a meta refresh in any page the agent fetches captures bearer tokens and session cookies set through request_headers=. Disclosure only; no integrity or availability impact.

Patches

Fixed in mechanize v2.14.1. A meta refresh that points at another origin is now subject to the same rule as an HTTP redirect: credentials and cookies are withheld from the request that follows it.

Workarounds

Leave Mechanize#follow_meta_refresh at its default of false, or avoid request_headers= for credentials when it is enabled.

Summary

mechanize leaked credentials to the redirect target when an HTTP redirect crossed to another host. Credentials set through Mechanize#request_headers= leaked even when they were Authorization.

Details

Two defects, both in lib/mechanize/http/agent.rb.

1. Mechanize#request_headers= bypassed the redirect strip entirely. #request_add_headers copied @request_headers onto every request unconditionally, with no host check, including the request issued after a redirect. The strip in #response_redirect mutated only the per-request headers hash and never touched agent state. Because request_headers= is the documented way to set a default credential for every request, the header the code explicitly protected — Authorization — was the one most likely to leak.

2. The strip list omitted Proxy-Authorization and Cookie2. Only CREDENTIAL_HEADERS = ['Authorization'] and COOKIE_HEADERS = ['Cookie'] were removed from the per-request headers hash on a cross-host redirect.

Cookies held in Mechanize#cookie_jar and credentials held in Mechanize::HTTP::AuthStore are not affected. Both are looked up per-URI, so they never follow a redirect to a foreign host. The exposure was limited to headers the caller set by hand.

PoC

agent = Mechanize.new
agent.request_headers = { 'Authorization' => 'Bearer secret' }
agent.get('https://example.test/redirects-to-attacker')
# the request to the attacker's host carries "Authorization: Bearer secret"

Impact

An attacker who controls a redirect target — through an open redirect on the site being fetched, an attacker-supplied fetch URL, DNS rebinding, or MITM — captures bearer tokens and session cookies from any mechanize agent that sets credentials through request_headers= or the per-request headers argument. Disclosure only; no integrity or availability impact.

Patches

Fixed in mechanize v2.14.1.

• Credentials and cookies are withheld from a request that follows a redirect across an origin, from both header sources: the per-request headers argument and Mechanize#request_headers=.
• CREDENTIAL_HEADERS gains Proxy-Authorization; COOKIE_HEADERS gains Cookie2.

Proxy-Authorization is withheld here although curl does not withhold it, because Net::HTTP tunnels https: requests with CONNECT, so a caller-supplied Proxy-Authorization travels inside the tunnel to the origin server rather than to the proxy.

Headers set through Mechanize#request_headers= no longer reach a redirect target on another origin when they are credentials. Callers that relied on the previous behavior will see those headers withheld.

What this fix does not cover

Only the headers in CREDENTIAL_HEADERS and COOKIE_HEADERS are withheld. A caller-supplied header that carries a credential under some other name — X-API-Key, X-Vault-Token, or any bespoke token header — still follows a redirect to another origin, matching the behavior of curl's CURLOPT_HTTPHEADER. If you set such a header, do not enable redirect following for requests that carry it, or scope it to a single request whose destination you control.

Workarounds

Set Mechanize#redirect_ok = false and handle redirects explicitly, or avoid request_headers= for credentials and pass them per-request only to hosts you intend to authenticate to.

Credit

Reported by @SnailSploit.

Summary

mechanize applied no trust boundary to a meta refresh, so credentials set through Mechanize#request_headers= followed a refresh that pointed at another origin.

Details

Mechanize::HTTP::Agent#response_follow_meta_refresh fetched the refresh target with no notion of a crossed origin, so @request_headers were re-applied in full. An attacker who could place a meta refresh in a page the agent fetched — through stored content, an open redirect, or control of any page in the crawl — collected the same credentials as through an HTTP redirect, on a code path that had none of the redirect path's protections.

The refresh fetch passes an empty per-request headers hash, so only headers set through Mechanize#request_headers= were exposed.

This requires Mechanize#follow_meta_refresh = true. It is false by default, so an agent in its default configuration is not affected. Crawlers commonly enable it.

Impact

An attacker who can place a meta refresh in any page the agent fetches captures bearer tokens and session cookies set through request_headers=. Disclosure only; no integrity or availability impact.

Patches

Fixed in mechanize v2.14.1. A meta refresh that points at another origin is now subject to the same rule as an HTTP redirect: credentials and cookies are withheld from the request that follows it.

Workarounds

Leave Mechanize#follow_meta_refresh at its default of false, or avoid request_headers= for credentials when it is enabled.

Summary

mechanize leaked credentials to the redirect target when an HTTP redirect crossed to another host. Credentials set through Mechanize#request_headers= leaked even when they were Authorization.

Details

Two defects, both in lib/mechanize/http/agent.rb.

1. Mechanize#request_headers= bypassed the redirect strip entirely. #request_add_headers copied @request_headers onto every request unconditionally, with no host check, including the request issued after a redirect. The strip in #response_redirect mutated only the per-request headers hash and never touched agent state. Because request_headers= is the documented way to set a default credential for every request, the header the code explicitly protected — Authorization — was the one most likely to leak.

2. The strip list omitted Proxy-Authorization and Cookie2. Only CREDENTIAL_HEADERS = ['Authorization'] and COOKIE_HEADERS = ['Cookie'] were removed from the per-request headers hash on a cross-host redirect.

Cookies held in Mechanize#cookie_jar and credentials held in Mechanize::HTTP::AuthStore are not affected. Both are looked up per-URI, so they never follow a redirect to a foreign host. The exposure was limited to headers the caller set by hand.

PoC

agent = Mechanize.new
agent.request_headers = { 'Authorization' => 'Bearer secret' }
agent.get('https://example.test/redirects-to-attacker')
# the request to the attacker's host carries "Authorization: Bearer secret"

Impact

An attacker who controls a redirect target — through an open redirect on the site being fetched, an attacker-supplied fetch URL, DNS rebinding, or MITM — captures bearer tokens and session cookies from any mechanize agent that sets credentials through request_headers= or the per-request headers argument. Disclosure only; no integrity or availability impact.

Patches

Fixed in mechanize v2.14.1.

• Credentials and cookies are withheld from a request that follows a redirect across an origin, from both header sources: the per-request headers argument and Mechanize#request_headers=.
• CREDENTIAL_HEADERS gains Proxy-Authorization; COOKIE_HEADERS gains Cookie2.

Proxy-Authorization is withheld here although curl does not withhold it, because Net::HTTP tunnels https: requests with CONNECT, so a caller-supplied Proxy-Authorization travels inside the tunnel to the origin server rather than to the proxy.

Headers set through Mechanize#request_headers= no longer reach a redirect target on another origin when they are credentials. Callers that relied on the previous behavior will see those headers withheld.

What this fix does not cover

Only the headers in CREDENTIAL_HEADERS and COOKIE_HEADERS are withheld. A caller-supplied header that carries a credential under some other name — X-API-Key, X-Vault-Token, or any bespoke token header — still follows a redirect to another origin, matching the behavior of curl's CURLOPT_HTTPHEADER. If you set such a header, do not enable redirect following for requests that carry it, or scope it to a single request whose destination you control.

Workarounds

Set Mechanize#redirect_ok = false and handle redirects explicitly, or avoid request_headers= for credentials and pass them per-request only to hosts you intend to authenticate to.

Credit

Reported by @SnailSploit.

Summary

mechanize applied no trust boundary to a meta refresh, so credentials set through Mechanize#request_headers= followed a refresh that pointed at another origin.

Details

Mechanize::HTTP::Agent#response_follow_meta_refresh fetched the refresh target with no notion of a crossed origin, so @request_headers were re-applied in full. An attacker who could place a meta refresh in a page the agent fetched — through stored content, an open redirect, or control of any page in the crawl — collected the same credentials as through an HTTP redirect, on a code path that had none of the redirect path's protections.

The refresh fetch passes an empty per-request headers hash, so only headers set through Mechanize#request_headers= were exposed.

This requires Mechanize#follow_meta_refresh = true. It is false by default, so an agent in its default configuration is not affected. Crawlers commonly enable it.

Impact

An attacker who can place a meta refresh in any page the agent fetches captures bearer tokens and session cookies set through request_headers=. Disclosure only; no integrity or availability impact.

Patches

Fixed in mechanize v2.14.1. A meta refresh that points at another origin is now subject to the same rule as an HTTP redirect: credentials and cookies are withheld from the request that follows it.

Workarounds

Leave Mechanize#follow_meta_refresh at its default of false, or avoid request_headers= for credentials when it is enabled.

Summary

mechanize leaked credentials to the redirect target when an HTTP redirect crossed to another host. Credentials set through Mechanize#request_headers= leaked even when they were Authorization.

Details

Two defects, both in lib/mechanize/http/agent.rb.

1. Mechanize#request_headers= bypassed the redirect strip entirely. #request_add_headers copied @request_headers onto every request unconditionally, with no host check, including the request issued after a redirect. The strip in #response_redirect mutated only the per-request headers hash and never touched agent state. Because request_headers= is the documented way to set a default credential for every request, the header the code explicitly protected — Authorization — was the one most likely to leak.

2. The strip list omitted Proxy-Authorization and Cookie2. Only CREDENTIAL_HEADERS = ['Authorization'] and COOKIE_HEADERS = ['Cookie'] were removed from the per-request headers hash on a cross-host redirect.

Cookies held in Mechanize#cookie_jar and credentials held in Mechanize::HTTP::AuthStore are not affected. Both are looked up per-URI, so they never follow a redirect to a foreign host. The exposure was limited to headers the caller set by hand.

PoC

agent = Mechanize.new
agent.request_headers = { 'Authorization' => 'Bearer secret' }
agent.get('https://example.test/redirects-to-attacker')
# the request to the attacker's host carries "Authorization: Bearer secret"

Impact

An attacker who controls a redirect target — through an open redirect on the site being fetched, an attacker-supplied fetch URL, DNS rebinding, or MITM — captures bearer tokens and session cookies from any mechanize agent that sets credentials through request_headers= or the per-request headers argument. Disclosure only; no integrity or availability impact.

Patches

Fixed in mechanize v2.14.1.

• Credentials and cookies are withheld from a request that follows a redirect across an origin, from both header sources: the per-request headers argument and Mechanize#request_headers=.
• CREDENTIAL_HEADERS gains Proxy-Authorization; COOKIE_HEADERS gains Cookie2.

Proxy-Authorization is withheld here although curl does not withhold it, because Net::HTTP tunnels https: requests with CONNECT, so a caller-supplied Proxy-Authorization travels inside the tunnel to the origin server rather than to the proxy.

Headers set through Mechanize#request_headers= no longer reach a redirect target on another origin when they are credentials. Callers that relied on the previous behavior will see those headers withheld.

What this fix does not cover

Only the headers in CREDENTIAL_HEADERS and COOKIE_HEADERS are withheld. A caller-supplied header that carries a credential under some other name — X-API-Key, X-Vault-Token, or any bespoke token header — still follows a redirect to another origin, matching the behavior of curl's CURLOPT_HTTPHEADER. If you set such a header, do not enable redirect following for requests that carry it, or scope it to a single request whose destination you control.

Workarounds

Set Mechanize#redirect_ok = false and handle redirects explicitly, or avoid request_headers= for credentials and pass them per-request only to hosts you intend to authenticate to.

Credit

Reported by @SnailSploit.

Summary

mechanize applied no trust boundary to a meta refresh, so credentials set through Mechanize#request_headers= followed a refresh that pointed at another origin.

Details

Mechanize::HTTP::Agent#response_follow_meta_refresh fetched the refresh target with no notion of a crossed origin, so @request_headers were re-applied in full. An attacker who could place a meta refresh in a page the agent fetched — through stored content, an open redirect, or control of any page in the crawl — collected the same credentials as through an HTTP redirect, on a code path that had none of the redirect path's protections.

The refresh fetch passes an empty per-request headers hash, so only headers set through Mechanize#request_headers= were exposed.

This requires Mechanize#follow_meta_refresh = true. It is false by default, so an agent in its default configuration is not affected. Crawlers commonly enable it.

Impact

An attacker who can place a meta refresh in any page the agent fetches captures bearer tokens and session cookies set through request_headers=. Disclosure only; no integrity or availability impact.

Patches

Fixed in mechanize v2.14.1. A meta refresh that points at another origin is now subject to the same rule as an HTTP redirect: credentials and cookies are withheld from the request that follows it.

Workarounds

Leave Mechanize#follow_meta_refresh at its default of false, or avoid request_headers= for credentials when it is enabled.

Summary

mechanize leaked credentials to the redirect target when an HTTP redirect crossed to another host. Credentials set through Mechanize#request_headers= leaked even when they were Authorization.

Details

Two defects, both in lib/mechanize/http/agent.rb.

1. Mechanize#request_headers= bypassed the redirect strip entirely. #request_add_headers copied @request_headers onto every request unconditionally, with no host check, including the request issued after a redirect. The strip in #response_redirect mutated only the per-request headers hash and never touched agent state. Because request_headers= is the documented way to set a default credential for every request, the header the code explicitly protected — Authorization — was the one most likely to leak.

2. The strip list omitted Proxy-Authorization and Cookie2. Only CREDENTIAL_HEADERS = ['Authorization'] and COOKIE_HEADERS = ['Cookie'] were removed from the per-request headers hash on a cross-host redirect.

Cookies held in Mechanize#cookie_jar and credentials held in Mechanize::HTTP::AuthStore are not affected. Both are looked up per-URI, so they never follow a redirect to a foreign host. The exposure was limited to headers the caller set by hand.

PoC

agent = Mechanize.new
agent.request_headers = { 'Authorization' => 'Bearer secret' }
agent.get('https://example.test/redirects-to-attacker')
# the request to the attacker's host carries "Authorization: Bearer secret"

Impact

An attacker who controls a redirect target — through an open redirect on the site being fetched, an attacker-supplied fetch URL, DNS rebinding, or MITM — captures bearer tokens and session cookies from any mechanize agent that sets credentials through request_headers= or the per-request headers argument. Disclosure only; no integrity or availability impact.

Patches

Fixed in mechanize v2.14.1.

• Credentials and cookies are withheld from a request that follows a redirect across an origin, from both header sources: the per-request headers argument and Mechanize#request_headers=.
• CREDENTIAL_HEADERS gains Proxy-Authorization; COOKIE_HEADERS gains Cookie2.

Proxy-Authorization is withheld here although curl does not withhold it, because Net::HTTP tunnels https: requests with CONNECT, so a caller-supplied Proxy-Authorization travels inside the tunnel to the origin server rather than to the proxy.

Headers set through Mechanize#request_headers= no longer reach a redirect target on another origin when they are credentials. Callers that relied on the previous behavior will see those headers withheld.

What this fix does not cover

Only the headers in CREDENTIAL_HEADERS and COOKIE_HEADERS are withheld. A caller-supplied header that carries a credential under some other name — X-API-Key, X-Vault-Token, or any bespoke token header — still follows a redirect to another origin, matching the behavior of curl's CURLOPT_HTTPHEADER. If you set such a header, do not enable redirect following for requests that carry it, or scope it to a single request whose destination you control.

Workarounds

Set Mechanize#redirect_ok = false and handle redirects explicitly, or avoid request_headers= for credentials and pass them per-request only to hosts you intend to authenticate to.

Credit

Reported by @SnailSploit.

Summary

mechanize applied no trust boundary to a meta refresh, so credentials set through Mechanize#request_headers= followed a refresh that pointed at another origin.

Details

Mechanize::HTTP::Agent#response_follow_meta_refresh fetched the refresh target with no notion of a crossed origin, so @request_headers were re-applied in full. An attacker who could place a meta refresh in a page the agent fetched — through stored content, an open redirect, or control of any page in the crawl — collected the same credentials as through an HTTP redirect, on a code path that had none of the redirect path's protections.

The refresh fetch passes an empty per-request headers hash, so only headers set through Mechanize#request_headers= were exposed.

This requires Mechanize#follow_meta_refresh = true. It is false by default, so an agent in its default configuration is not affected. Crawlers commonly enable it.

Impact

An attacker who can place a meta refresh in any page the agent fetches captures bearer tokens and session cookies set through request_headers=. Disclosure only; no integrity or availability impact.

Patches

Fixed in mechanize v2.14.1. A meta refresh that points at another origin is now subject to the same rule as an HTTP redirect: credentials and cookies are withheld from the request that follows it.

Workarounds

Leave Mechanize#follow_meta_refresh at its default of false, or avoid request_headers= for credentials when it is enabled.

Summary

mechanize leaked credentials to the redirect target when an HTTP redirect crossed to another host. Credentials set through Mechanize#request_headers= leaked even when they were Authorization.

Details

Two defects, both in lib/mechanize/http/agent.rb.

1. Mechanize#request_headers= bypassed the redirect strip entirely. #request_add_headers copied @request_headers onto every request unconditionally, with no host check, including the request issued after a redirect. The strip in #response_redirect mutated only the per-request headers hash and never touched agent state. Because request_headers= is the documented way to set a default credential for every request, the header the code explicitly protected — Authorization — was the one most likely to leak.

2. The strip list omitted Proxy-Authorization and Cookie2. Only CREDENTIAL_HEADERS = ['Authorization'] and COOKIE_HEADERS = ['Cookie'] were removed from the per-request headers hash on a cross-host redirect.

Cookies held in Mechanize#cookie_jar and credentials held in Mechanize::HTTP::AuthStore are not affected. Both are looked up per-URI, so they never follow a redirect to a foreign host. The exposure was limited to headers the caller set by hand.

PoC

agent = Mechanize.new
agent.request_headers = { 'Authorization' => 'Bearer secret' }
agent.get('https://example.test/redirects-to-attacker')
# the request to the attacker's host carries "Authorization: Bearer secret"

Impact

An attacker who controls a redirect target — through an open redirect on the site being fetched, an attacker-supplied fetch URL, DNS rebinding, or MITM — captures bearer tokens and session cookies from any mechanize agent that sets credentials through request_headers= or the per-request headers argument. Disclosure only; no integrity or availability impact.

Patches

Fixed in mechanize v2.14.1.

• Credentials and cookies are withheld from a request that follows a redirect across an origin, from both header sources: the per-request headers argument and Mechanize#request_headers=.
• CREDENTIAL_HEADERS gains Proxy-Authorization; COOKIE_HEADERS gains Cookie2.

Proxy-Authorization is withheld here although curl does not withhold it, because Net::HTTP tunnels https: requests with CONNECT, so a caller-supplied Proxy-Authorization travels inside the tunnel to the origin server rather than to the proxy.

Headers set through Mechanize#request_headers= no longer reach a redirect target on another origin when they are credentials. Callers that relied on the previous behavior will see those headers withheld.

What this fix does not cover

Only the headers in CREDENTIAL_HEADERS and COOKIE_HEADERS are withheld. A caller-supplied header that carries a credential under some other name — X-API-Key, X-Vault-Token, or any bespoke token header — still follows a redirect to another origin, matching the behavior of curl's CURLOPT_HTTPHEADER. If you set such a header, do not enable redirect following for requests that carry it, or scope it to a single request whose destination you control.

Workarounds

Set Mechanize#redirect_ok = false and handle redirects explicitly, or avoid request_headers= for credentials and pass them per-request only to hosts you intend to authenticate to.

Credit

Reported by @SnailSploit.

Summary

mechanize applied no trust boundary to a meta refresh, so credentials set through Mechanize#request_headers= followed a refresh that pointed at another origin.

Details

Mechanize::HTTP::Agent#response_follow_meta_refresh fetched the refresh target with no notion of a crossed origin, so @request_headers were re-applied in full. An attacker who could place a meta refresh in a page the agent fetched — through stored content, an open redirect, or control of any page in the crawl — collected the same credentials as through an HTTP redirect, on a code path that had none of the redirect path's protections.

The refresh fetch passes an empty per-request headers hash, so only headers set through Mechanize#request_headers= were exposed.

This requires Mechanize#follow_meta_refresh = true. It is false by default, so an agent in its default configuration is not affected. Crawlers commonly enable it.

Impact

An attacker who can place a meta refresh in any page the agent fetches captures bearer tokens and session cookies set through request_headers=. Disclosure only; no integrity or availability impact.

Patches

Fixed in mechanize v2.14.1. A meta refresh that points at another origin is now subject to the same rule as an HTTP redirect: credentials and cookies are withheld from the request that follows it.

Workarounds

Leave Mechanize#follow_meta_refresh at its default of false, or avoid request_headers= for credentials when it is enabled.

Summary

mechanize leaked credentials to the redirect target when an HTTP redirect crossed to another host. Credentials set through Mechanize#request_headers= leaked even when they were Authorization.

Details

Two defects, both in lib/mechanize/http/agent.rb.

1. Mechanize#request_headers= bypassed the redirect strip entirely. #request_add_headers copied @request_headers onto every request unconditionally, with no host check, including the request issued after a redirect. The strip in #response_redirect mutated only the per-request headers hash and never touched agent state. Because request_headers= is the documented way to set a default credential for every request, the header the code explicitly protected — Authorization — was the one most likely to leak.

2. The strip list omitted Proxy-Authorization and Cookie2. Only CREDENTIAL_HEADERS = ['Authorization'] and COOKIE_HEADERS = ['Cookie'] were removed from the per-request headers hash on a cross-host redirect.

Cookies held in Mechanize#cookie_jar and credentials held in Mechanize::HTTP::AuthStore are not affected. Both are looked up per-URI, so they never follow a redirect to a foreign host. The exposure was limited to headers the caller set by hand.

PoC

agent = Mechanize.new
agent.request_headers = { 'Authorization' => 'Bearer secret' }
agent.get('https://example.test/redirects-to-attacker')
# the request to the attacker's host carries "Authorization: Bearer secret"

Impact

An attacker who controls a redirect target — through an open redirect on the site being fetched, an attacker-supplied fetch URL, DNS rebinding, or MITM — captures bearer tokens and session cookies from any mechanize agent that sets credentials through request_headers= or the per-request headers argument. Disclosure only; no integrity or availability impact.

Patches

Fixed in mechanize v2.14.1.

• Credentials and cookies are withheld from a request that follows a redirect across an origin, from both header sources: the per-request headers argument and Mechanize#request_headers=.
• CREDENTIAL_HEADERS gains Proxy-Authorization; COOKIE_HEADERS gains Cookie2.

Proxy-Authorization is withheld here although curl does not withhold it, because Net::HTTP tunnels https: requests with CONNECT, so a caller-supplied Proxy-Authorization travels inside the tunnel to the origin server rather than to the proxy.

Headers set through Mechanize#request_headers= no longer reach a redirect target on another origin when they are credentials. Callers that relied on the previous behavior will see those headers withheld.

What this fix does not cover

Only the headers in CREDENTIAL_HEADERS and COOKIE_HEADERS are withheld. A caller-supplied header that carries a credential under some other name — X-API-Key, X-Vault-Token, or any bespoke token header — still follows a redirect to another origin, matching the behavior of curl's CURLOPT_HTTPHEADER. If you set such a header, do not enable redirect following for requests that carry it, or scope it to a single request whose destination you control.

Workarounds

Set Mechanize#redirect_ok = false and handle redirects explicitly, or avoid request_headers= for credentials and pass them per-request only to hosts you intend to authenticate to.

Credit

Reported by @SnailSploit.

Summary

mechanize applied no trust boundary to a meta refresh, so credentials set through Mechanize#request_headers= followed a refresh that pointed at another origin.

Details

Mechanize::HTTP::Agent#response_follow_meta_refresh fetched the refresh target with no notion of a crossed origin, so @request_headers were re-applied in full. An attacker who could place a meta refresh in a page the agent fetched — through stored content, an open redirect, or control of any page in the crawl — collected the same credentials as through an HTTP redirect, on a code path that had none of the redirect path's protections.

The refresh fetch passes an empty per-request headers hash, so only headers set through Mechanize#request_headers= were exposed.

This requires Mechanize#follow_meta_refresh = true. It is false by default, so an agent in its default configuration is not affected. Crawlers commonly enable it.

Impact

An attacker who can place a meta refresh in any page the agent fetches captures bearer tokens and session cookies set through request_headers=. Disclosure only; no integrity or availability impact.

Patches

Fixed in mechanize v2.14.1. A meta refresh that points at another origin is now subject to the same rule as an HTTP redirect: credentials and cookies are withheld from the request that follows it.

Workarounds

Leave Mechanize#follow_meta_refresh at its default of false, or avoid request_headers= for credentials when it is enabled.

Summary

mechanize leaked credentials to the redirect target when an HTTP redirect crossed to another host. Credentials set through Mechanize#request_headers= leaked even when they were Authorization.

Details

Two defects, both in lib/mechanize/http/agent.rb.

1. Mechanize#request_headers= bypassed the redirect strip entirely. #request_add_headers copied @request_headers onto every request unconditionally, with no host check, including the request issued after a redirect. The strip in #response_redirect mutated only the per-request headers hash and never touched agent state. Because request_headers= is the documented way to set a default credential for every request, the header the code explicitly protected — Authorization — was the one most likely to leak.

2. The strip list omitted Proxy-Authorization and Cookie2. Only CREDENTIAL_HEADERS = ['Authorization'] and COOKIE_HEADERS = ['Cookie'] were removed from the per-request headers hash on a cross-host redirect.

Cookies held in Mechanize#cookie_jar and credentials held in Mechanize::HTTP::AuthStore are not affected. Both are looked up per-URI, so they never follow a redirect to a foreign host. The exposure was limited to headers the caller set by hand.

PoC

agent = Mechanize.new
agent.request_headers = { 'Authorization' => 'Bearer secret' }
agent.get('https://example.test/redirects-to-attacker')
# the request to the attacker's host carries "Authorization: Bearer secret"

Impact

An attacker who controls a redirect target — through an open redirect on the site being fetched, an attacker-supplied fetch URL, DNS rebinding, or MITM — captures bearer tokens and session cookies from any mechanize agent that sets credentials through request_headers= or the per-request headers argument. Disclosure only; no integrity or availability impact.

Patches

Fixed in mechanize v2.14.1.

• Credentials and cookies are withheld from a request that follows a redirect across an origin, from both header sources: the per-request headers argument and Mechanize#request_headers=.
• CREDENTIAL_HEADERS gains Proxy-Authorization; COOKIE_HEADERS gains Cookie2.

Proxy-Authorization is withheld here although curl does not withhold it, because Net::HTTP tunnels https: requests with CONNECT, so a caller-supplied Proxy-Authorization travels inside the tunnel to the origin server rather than to the proxy.

Headers set through Mechanize#request_headers= no longer reach a redirect target on another origin when they are credentials. Callers that relied on the previous behavior will see those headers withheld.

What this fix does not cover

Only the headers in CREDENTIAL_HEADERS and COOKIE_HEADERS are withheld. A caller-supplied header that carries a credential under some other name — X-API-Key, X-Vault-Token, or any bespoke token header — still follows a redirect to another origin, matching the behavior of curl's CURLOPT_HTTPHEADER. If you set such a header, do not enable redirect following for requests that carry it, or scope it to a single request whose destination you control.

Workarounds

Set Mechanize#redirect_ok = false and handle redirects explicitly, or avoid request_headers= for credentials and pass them per-request only to hosts you intend to authenticate to.

Credit

Reported by @SnailSploit.

Summary

mechanize applied no trust boundary to a meta refresh, so credentials set through Mechanize#request_headers= followed a refresh that pointed at another origin.

Details

Mechanize::HTTP::Agent#response_follow_meta_refresh fetched the refresh target with no notion of a crossed origin, so @request_headers were re-applied in full. An attacker who could place a meta refresh in a page the agent fetched — through stored content, an open redirect, or control of any page in the crawl — collected the same credentials as through an HTTP redirect, on a code path that had none of the redirect path's protections.

The refresh fetch passes an empty per-request headers hash, so only headers set through Mechanize#request_headers= were exposed.

This requires Mechanize#follow_meta_refresh = true. It is false by default, so an agent in its default configuration is not affected. Crawlers commonly enable it.

Impact

An attacker who can place a meta refresh in any page the agent fetches captures bearer tokens and session cookies set through request_headers=. Disclosure only; no integrity or availability impact.

Patches

Fixed in mechanize v2.14.1. A meta refresh that points at another origin is now subject to the same rule as an HTTP redirect: credentials and cookies are withheld from the request that follows it.

Workarounds

Leave Mechanize#follow_meta_refresh at its default of false, or avoid request_headers= for credentials when it is enabled.

Summary

mechanize leaked credentials to the redirect target when an HTTP redirect crossed to another host. Credentials set through Mechanize#request_headers= leaked even when they were Authorization.

Details

Two defects, both in lib/mechanize/http/agent.rb.

1. Mechanize#request_headers= bypassed the redirect strip entirely. #request_add_headers copied @request_headers onto every request unconditionally, with no host check, including the request issued after a redirect. The strip in #response_redirect mutated only the per-request headers hash and never touched agent state. Because request_headers= is the documented way to set a default credential for every request, the header the code explicitly protected — Authorization — was the one most likely to leak.

2. The strip list omitted Proxy-Authorization and Cookie2. Only CREDENTIAL_HEADERS = ['Authorization'] and COOKIE_HEADERS = ['Cookie'] were removed from the per-request headers hash on a cross-host redirect.

Cookies held in Mechanize#cookie_jar and credentials held in Mechanize::HTTP::AuthStore are not affected. Both are looked up per-URI, so they never follow a redirect to a foreign host. The exposure was limited to headers the caller set by hand.

PoC

agent = Mechanize.new
agent.request_headers = { 'Authorization' => 'Bearer secret' }
agent.get('https://example.test/redirects-to-attacker')
# the request to the attacker's host carries "Authorization: Bearer secret"

Impact

An attacker who controls a redirect target — through an open redirect on the site being fetched, an attacker-supplied fetch URL, DNS rebinding, or MITM — captures bearer tokens and session cookies from any mechanize agent that sets credentials through request_headers= or the per-request headers argument. Disclosure only; no integrity or availability impact.

Patches

Fixed in mechanize v2.14.1.

• Credentials and cookies are withheld from a request that follows a redirect across an origin, from both header sources: the per-request headers argument and Mechanize#request_headers=.
• CREDENTIAL_HEADERS gains Proxy-Authorization; COOKIE_HEADERS gains Cookie2.

Proxy-Authorization is withheld here although curl does not withhold it, because Net::HTTP tunnels https: requests with CONNECT, so a caller-supplied Proxy-Authorization travels inside the tunnel to the origin server rather than to the proxy.

Headers set through Mechanize#request_headers= no longer reach a redirect target on another origin when they are credentials. Callers that relied on the previous behavior will see those headers withheld.

What this fix does not cover

Only the headers in CREDENTIAL_HEADERS and COOKIE_HEADERS are withheld. A caller-supplied header that carries a credential under some other name — X-API-Key, X-Vault-Token, or any bespoke token header — still follows a redirect to another origin, matching the behavior of curl's CURLOPT_HTTPHEADER. If you set such a header, do not enable redirect following for requests that carry it, or scope it to a single request whose destination you control.

Workarounds

Set Mechanize#redirect_ok = false and handle redirects explicitly, or avoid request_headers= for credentials and pass them per-request only to hosts you intend to authenticate to.

Credit

Reported by @SnailSploit.

Summary

mechanize applied no trust boundary to a meta refresh, so credentials set through Mechanize#request_headers= followed a refresh that pointed at another origin.

Details

Mechanize::HTTP::Agent#response_follow_meta_refresh fetched the refresh target with no notion of a crossed origin, so @request_headers were re-applied in full. An attacker who could place a meta refresh in a page the agent fetched — through stored content, an open redirect, or control of any page in the crawl — collected the same credentials as through an HTTP redirect, on a code path that had none of the redirect path's protections.

The refresh fetch passes an empty per-request headers hash, so only headers set through Mechanize#request_headers= were exposed.

This requires Mechanize#follow_meta_refresh = true. It is false by default, so an agent in its default configuration is not affected. Crawlers commonly enable it.

Impact

An attacker who can place a meta refresh in any page the agent fetches captures bearer tokens and session cookies set through request_headers=. Disclosure only; no integrity or availability impact.

Patches

Fixed in mechanize v2.14.1. A meta refresh that points at another origin is now subject to the same rule as an HTTP redirect: credentials and cookies are withheld from the request that follows it.

Workarounds

Leave Mechanize#follow_meta_refresh at its default of false, or avoid request_headers= for credentials when it is enabled.

Summary

mechanize leaked credentials to the redirect target when an HTTP redirect crossed to another host. Credentials set through Mechanize#request_headers= leaked even when they were Authorization.

Details

Two defects, both in lib/mechanize/http/agent.rb.

1. Mechanize#request_headers= bypassed the redirect strip entirely. #request_add_headers copied @request_headers onto every request unconditionally, with no host check, including the request issued after a redirect. The strip in #response_redirect mutated only the per-request headers hash and never touched agent state. Because request_headers= is the documented way to set a default credential for every request, the header the code explicitly protected — Authorization — was the one most likely to leak.

2. The strip list omitted Proxy-Authorization and Cookie2. Only CREDENTIAL_HEADERS = ['Authorization'] and COOKIE_HEADERS = ['Cookie'] were removed from the per-request headers hash on a cross-host redirect.

Cookies held in Mechanize#cookie_jar and credentials held in Mechanize::HTTP::AuthStore are not affected. Both are looked up per-URI, so they never follow a redirect to a foreign host. The exposure was limited to headers the caller set by hand.

PoC

agent = Mechanize.new
agent.request_headers = { 'Authorization' => 'Bearer secret' }
agent.get('https://example.test/redirects-to-attacker')
# the request to the attacker's host carries "Authorization: Bearer secret"

Impact

An attacker who controls a redirect target — through an open redirect on the site being fetched, an attacker-supplied fetch URL, DNS rebinding, or MITM — captures bearer tokens and session cookies from any mechanize agent that sets credentials through request_headers= or the per-request headers argument. Disclosure only; no integrity or availability impact.

Patches

Fixed in mechanize v2.14.1.

• Credentials and cookies are withheld from a request that follows a redirect across an origin, from both header sources: the per-request headers argument and Mechanize#request_headers=.
• CREDENTIAL_HEADERS gains Proxy-Authorization; COOKIE_HEADERS gains Cookie2.

Proxy-Authorization is withheld here although curl does not withhold it, because Net::HTTP tunnels https: requests with CONNECT, so a caller-supplied Proxy-Authorization travels inside the tunnel to the origin server rather than to the proxy.

Headers set through Mechanize#request_headers= no longer reach a redirect target on another origin when they are credentials. Callers that relied on the previous behavior will see those headers withheld.

What this fix does not cover

Only the headers in CREDENTIAL_HEADERS and COOKIE_HEADERS are withheld. A caller-supplied header that carries a credential under some other name — X-API-Key, X-Vault-Token, or any bespoke token header — still follows a redirect to another origin, matching the behavior of curl's CURLOPT_HTTPHEADER. If you set such a header, do not enable redirect following for requests that carry it, or scope it to a single request whose destination you control.

Workarounds

Set Mechanize#redirect_ok = false and handle redirects explicitly, or avoid request_headers= for credentials and pass them per-request only to hosts you intend to authenticate to.

Credit

Reported by @SnailSploit.

Summary

mechanize applied no trust boundary to a meta refresh, so credentials set through Mechanize#request_headers= followed a refresh that pointed at another origin.

Details

Mechanize::HTTP::Agent#response_follow_meta_refresh fetched the refresh target with no notion of a crossed origin, so @request_headers were re-applied in full. An attacker who could place a meta refresh in a page the agent fetched — through stored content, an open redirect, or control of any page in the crawl — collected the same credentials as through an HTTP redirect, on a code path that had none of the redirect path's protections.

The refresh fetch passes an empty per-request headers hash, so only headers set through Mechanize#request_headers= were exposed.

This requires Mechanize#follow_meta_refresh = true. It is false by default, so an agent in its default configuration is not affected. Crawlers commonly enable it.

Impact

An attacker who can place a meta refresh in any page the agent fetches captures bearer tokens and session cookies set through request_headers=. Disclosure only; no integrity or availability impact.

Patches

Fixed in mechanize v2.14.1. A meta refresh that points at another origin is now subject to the same rule as an HTTP redirect: credentials and cookies are withheld from the request that follows it.

Workarounds

Leave Mechanize#follow_meta_refresh at its default of false, or avoid request_headers= for credentials when it is enabled.

Summary

mechanize leaked credentials to the redirect target when an HTTP redirect crossed to another host. Credentials set through Mechanize#request_headers= leaked even when they were Authorization.

Details

Two defects, both in lib/mechanize/http/agent.rb.

1. Mechanize#request_headers= bypassed the redirect strip entirely. #request_add_headers copied @request_headers onto every request unconditionally, with no host check, including the request issued after a redirect. The strip in #response_redirect mutated only the per-request headers hash and never touched agent state. Because request_headers= is the documented way to set a default credential for every request, the header the code explicitly protected — Authorization — was the one most likely to leak.

2. The strip list omitted Proxy-Authorization and Cookie2. Only CREDENTIAL_HEADERS = ['Authorization'] and COOKIE_HEADERS = ['Cookie'] were removed from the per-request headers hash on a cross-host redirect.

Cookies held in Mechanize#cookie_jar and credentials held in Mechanize::HTTP::AuthStore are not affected. Both are looked up per-URI, so they never follow a redirect to a foreign host. The exposure was limited to headers the caller set by hand.

PoC

agent = Mechanize.new
agent.request_headers = { 'Authorization' => 'Bearer secret' }
agent.get('https://example.test/redirects-to-attacker')
# the request to the attacker's host carries "Authorization: Bearer secret"

Impact

An attacker who controls a redirect target — through an open redirect on the site being fetched, an attacker-supplied fetch URL, DNS rebinding, or MITM — captures bearer tokens and session cookies from any mechanize agent that sets credentials through request_headers= or the per-request headers argument. Disclosure only; no integrity or availability impact.

Patches

Fixed in mechanize v2.14.1.

• Credentials and cookies are withheld from a request that follows a redirect across an origin, from both header sources: the per-request headers argument and Mechanize#request_headers=.
• CREDENTIAL_HEADERS gains Proxy-Authorization; COOKIE_HEADERS gains Cookie2.

Proxy-Authorization is withheld here although curl does not withhold it, because Net::HTTP tunnels https: requests with CONNECT, so a caller-supplied Proxy-Authorization travels inside the tunnel to the origin server rather than to the proxy.

Headers set through Mechanize#request_headers= no longer reach a redirect target on another origin when they are credentials. Callers that relied on the previous behavior will see those headers withheld.

What this fix does not cover

Only the headers in CREDENTIAL_HEADERS and COOKIE_HEADERS are withheld. A caller-supplied header that carries a credential under some other name — X-API-Key, X-Vault-Token, or any bespoke token header — still follows a redirect to another origin, matching the behavior of curl's CURLOPT_HTTPHEADER. If you set such a header, do not enable redirect following for requests that carry it, or scope it to a single request whose destination you control.

Workarounds

Set Mechanize#redirect_ok = false and handle redirects explicitly, or avoid request_headers= for credentials and pass them per-request only to hosts you intend to authenticate to.

Credit

Reported by @SnailSploit.

Summary

mechanize applied no trust boundary to a meta refresh, so credentials set through Mechanize#request_headers= followed a refresh that pointed at another origin.

Details

Mechanize::HTTP::Agent#response_follow_meta_refresh fetched the refresh target with no notion of a crossed origin, so @request_headers were re-applied in full. An attacker who could place a meta refresh in a page the agent fetched — through stored content, an open redirect, or control of any page in the crawl — collected the same credentials as through an HTTP redirect, on a code path that had none of the redirect path's protections.

The refresh fetch passes an empty per-request headers hash, so only headers set through Mechanize#request_headers= were exposed.

This requires Mechanize#follow_meta_refresh = true. It is false by default, so an agent in its default configuration is not affected. Crawlers commonly enable it.

Impact

An attacker who can place a meta refresh in any page the agent fetches captures bearer tokens and session cookies set through request_headers=. Disclosure only; no integrity or availability impact.

Patches

Fixed in mechanize v2.14.1. A meta refresh that points at another origin is now subject to the same rule as an HTTP redirect: credentials and cookies are withheld from the request that follows it.

Workarounds

Leave Mechanize#follow_meta_refresh at its default of false, or avoid request_headers= for credentials when it is enabled.

Summary

mechanize leaked credentials to the redirect target when an HTTP redirect crossed to another host. Credentials set through Mechanize#request_headers= leaked even when they were Authorization.

Details

Two defects, both in lib/mechanize/http/agent.rb.

1. Mechanize#request_headers= bypassed the redirect strip entirely. #request_add_headers copied @request_headers onto every request unconditionally, with no host check, including the request issued after a redirect. The strip in #response_redirect mutated only the per-request headers hash and never touched agent state. Because request_headers= is the documented way to set a default credential for every request, the header the code explicitly protected — Authorization — was the one most likely to leak.

2. The strip list omitted Proxy-Authorization and Cookie2. Only CREDENTIAL_HEADERS = ['Authorization'] and COOKIE_HEADERS = ['Cookie'] were removed from the per-request headers hash on a cross-host redirect.

Cookies held in Mechanize#cookie_jar and credentials held in Mechanize::HTTP::AuthStore are not affected. Both are looked up per-URI, so they never follow a redirect to a foreign host. The exposure was limited to headers the caller set by hand.

PoC

agent = Mechanize.new
agent.request_headers = { 'Authorization' => 'Bearer secret' }
agent.get('https://example.test/redirects-to-attacker')
# the request to the attacker's host carries "Authorization: Bearer secret"

Impact

An attacker who controls a redirect target — through an open redirect on the site being fetched, an attacker-supplied fetch URL, DNS rebinding, or MITM — captures bearer tokens and session cookies from any mechanize agent that sets credentials through request_headers= or the per-request headers argument. Disclosure only; no integrity or availability impact.

Patches

Fixed in mechanize v2.14.1.

• Credentials and cookies are withheld from a request that follows a redirect across an origin, from both header sources: the per-request headers argument and Mechanize#request_headers=.
• CREDENTIAL_HEADERS gains Proxy-Authorization; COOKIE_HEADERS gains Cookie2.

Proxy-Authorization is withheld here although curl does not withhold it, because Net::HTTP tunnels https: requests with CONNECT, so a caller-supplied Proxy-Authorization travels inside the tunnel to the origin server rather than to the proxy.

Headers set through Mechanize#request_headers= no longer reach a redirect target on another origin when they are credentials. Callers that relied on the previous behavior will see those headers withheld.

What this fix does not cover

Only the headers in CREDENTIAL_HEADERS and COOKIE_HEADERS are withheld. A caller-supplied header that carries a credential under some other name — X-API-Key, X-Vault-Token, or any bespoke token header — still follows a redirect to another origin, matching the behavior of curl's CURLOPT_HTTPHEADER. If you set such a header, do not enable redirect following for requests that carry it, or scope it to a single request whose destination you control.

Workarounds

Set Mechanize#redirect_ok = false and handle redirects explicitly, or avoid request_headers= for credentials and pass them per-request only to hosts you intend to authenticate to.

Credit

Reported by @SnailSploit.

Summary

mechanize applied no trust boundary to a meta refresh, so credentials set through Mechanize#request_headers= followed a refresh that pointed at another origin.

Details

Mechanize::HTTP::Agent#response_follow_meta_refresh fetched the refresh target with no notion of a crossed origin, so @request_headers were re-applied in full. An attacker who could place a meta refresh in a page the agent fetched — through stored content, an open redirect, or control of any page in the crawl — collected the same credentials as through an HTTP redirect, on a code path that had none of the redirect path's protections.

The refresh fetch passes an empty per-request headers hash, so only headers set through Mechanize#request_headers= were exposed.

This requires Mechanize#follow_meta_refresh = true. It is false by default, so an agent in its default configuration is not affected. Crawlers commonly enable it.

Impact

An attacker who can place a meta refresh in any page the agent fetches captures bearer tokens and session cookies set through request_headers=. Disclosure only; no integrity or availability impact.

Patches

Fixed in mechanize v2.14.1. A meta refresh that points at another origin is now subject to the same rule as an HTTP redirect: credentials and cookies are withheld from the request that follows it.

Workarounds

Leave Mechanize#follow_meta_refresh at its default of false, or avoid request_headers= for credentials when it is enabled.

Summary

mechanize leaked credentials to the redirect target when an HTTP redirect crossed to another host. Credentials set through Mechanize#request_headers= leaked even when they were Authorization.

Details

Two defects, both in lib/mechanize/http/agent.rb.

1. Mechanize#request_headers= bypassed the redirect strip entirely. #request_add_headers copied @request_headers onto every request unconditionally, with no host check, including the request issued after a redirect. The strip in #response_redirect mutated only the per-request headers hash and never touched agent state. Because request_headers= is the documented way to set a default credential for every request, the header the code explicitly protected — Authorization — was the one most likely to leak.

2. The strip list omitted Proxy-Authorization and Cookie2. Only CREDENTIAL_HEADERS = ['Authorization'] and COOKIE_HEADERS = ['Cookie'] were removed from the per-request headers hash on a cross-host redirect.

Cookies held in Mechanize#cookie_jar and credentials held in Mechanize::HTTP::AuthStore are not affected. Both are looked up per-URI, so they never follow a redirect to a foreign host. The exposure was limited to headers the caller set by hand.

PoC

agent = Mechanize.new
agent.request_headers = { 'Authorization' => 'Bearer secret' }
agent.get('https://example.test/redirects-to-attacker')
# the request to the attacker's host carries "Authorization: Bearer secret"

Impact

An attacker who controls a redirect target — through an open redirect on the site being fetched, an attacker-supplied fetch URL, DNS rebinding, or MITM — captures bearer tokens and session cookies from any mechanize agent that sets credentials through request_headers= or the per-request headers argument. Disclosure only; no integrity or availability impact.

Patches

Fixed in mechanize v2.14.1.

• Credentials and cookies are withheld from a request that follows a redirect across an origin, from both header sources: the per-request headers argument and Mechanize#request_headers=.
• CREDENTIAL_HEADERS gains Proxy-Authorization; COOKIE_HEADERS gains Cookie2.

Proxy-Authorization is withheld here although curl does not withhold it, because Net::HTTP tunnels https: requests with CONNECT, so a caller-supplied Proxy-Authorization travels inside the tunnel to the origin server rather than to the proxy.

Headers set through Mechanize#request_headers= no longer reach a redirect target on another origin when they are credentials. Callers that relied on the previous behavior will see those headers withheld.

What this fix does not cover

Only the headers in CREDENTIAL_HEADERS and COOKIE_HEADERS are withheld. A caller-supplied header that carries a credential under some other name — X-API-Key, X-Vault-Token, or any bespoke token header — still follows a redirect to another origin, matching the behavior of curl's CURLOPT_HTTPHEADER. If you set such a header, do not enable redirect following for requests that carry it, or scope it to a single request whose destination you control.

Workarounds

Set Mechanize#redirect_ok = false and handle redirects explicitly, or avoid request_headers= for credentials and pass them per-request only to hosts you intend to authenticate to.

Credit

Reported by @SnailSploit.

Summary

mechanize applied no trust boundary to a meta refresh, so credentials set through Mechanize#request_headers= followed a refresh that pointed at another origin.

Details

Mechanize::HTTP::Agent#response_follow_meta_refresh fetched the refresh target with no notion of a crossed origin, so @request_headers were re-applied in full. An attacker who could place a meta refresh in a page the agent fetched — through stored content, an open redirect, or control of any page in the crawl — collected the same credentials as through an HTTP redirect, on a code path that had none of the redirect path's protections.

The refresh fetch passes an empty per-request headers hash, so only headers set through Mechanize#request_headers= were exposed.

This requires Mechanize#follow_meta_refresh = true. It is false by default, so an agent in its default configuration is not affected. Crawlers commonly enable it.

Impact

An attacker who can place a meta refresh in any page the agent fetches captures bearer tokens and session cookies set through request_headers=. Disclosure only; no integrity or availability impact.

Patches

Fixed in mechanize v2.14.1. A meta refresh that points at another origin is now subject to the same rule as an HTTP redirect: credentials and cookies are withheld from the request that follows it.

Workarounds

Leave Mechanize#follow_meta_refresh at its default of false, or avoid request_headers= for credentials when it is enabled.

Summary

mechanize leaked credentials to the redirect target when an HTTP redirect crossed to another host. Credentials set through Mechanize#request_headers= leaked even when they were Authorization.

Details

Two defects, both in lib/mechanize/http/agent.rb.

1. Mechanize#request_headers= bypassed the redirect strip entirely. #request_add_headers copied @request_headers onto every request unconditionally, with no host check, including the request issued after a redirect. The strip in #response_redirect mutated only the per-request headers hash and never touched agent state. Because request_headers= is the documented way to set a default credential for every request, the header the code explicitly protected — Authorization — was the one most likely to leak.

2. The strip list omitted Proxy-Authorization and Cookie2. Only CREDENTIAL_HEADERS = ['Authorization'] and COOKIE_HEADERS = ['Cookie'] were removed from the per-request headers hash on a cross-host redirect.

Cookies held in Mechanize#cookie_jar and credentials held in Mechanize::HTTP::AuthStore are not affected. Both are looked up per-URI, so they never follow a redirect to a foreign host. The exposure was limited to headers the caller set by hand.

PoC

agent = Mechanize.new
agent.request_headers = { 'Authorization' => 'Bearer secret' }
agent.get('https://example.test/redirects-to-attacker')
# the request to the attacker's host carries "Authorization: Bearer secret"

Impact

An attacker who controls a redirect target — through an open redirect on the site being fetched, an attacker-supplied fetch URL, DNS rebinding, or MITM — captures bearer tokens and session cookies from any mechanize agent that sets credentials through request_headers= or the per-request headers argument. Disclosure only; no integrity or availability impact.

Patches

Fixed in mechanize v2.14.1.

• Credentials and cookies are withheld from a request that follows a redirect across an origin, from both header sources: the per-request headers argument and Mechanize#request_headers=.
• CREDENTIAL_HEADERS gains Proxy-Authorization; COOKIE_HEADERS gains Cookie2.

Proxy-Authorization is withheld here although curl does not withhold it, because Net::HTTP tunnels https: requests with CONNECT, so a caller-supplied Proxy-Authorization travels inside the tunnel to the origin server rather than to the proxy.

Headers set through Mechanize#request_headers= no longer reach a redirect target on another origin when they are credentials. Callers that relied on the previous behavior will see those headers withheld.

What this fix does not cover

Only the headers in CREDENTIAL_HEADERS and COOKIE_HEADERS are withheld. A caller-supplied header that carries a credential under some other name — X-API-Key, X-Vault-Token, or any bespoke token header — still follows a redirect to another origin, matching the behavior of curl's CURLOPT_HTTPHEADER. If you set such a header, do not enable redirect following for requests that carry it, or scope it to a single request whose destination you control.

Workarounds

Set Mechanize#redirect_ok = false and handle redirects explicitly, or avoid request_headers= for credentials and pass them per-request only to hosts you intend to authenticate to.

Credit

Reported by @SnailSploit.

Summary

Mechanize (rubygem) < v2.8.5 leaks the Authorization header after a redirect to a different port on the same site.

Mitigation

Upgrade to Mechanize v2.8.5 or later.

Notes

See https://curl.se/docs/CVE-2022-27776.html for a similar vulnerability in curl.

Cookies are shared with a server at a different port on the same site, per https://datatracker.ietf.org/doc/html/rfc6265#section-8.5 which states in part:

Cookies do not provide isolation by port. If a cookie is readable by a service running on one port, the cookie is also readable by a service running on another port of the same server. If a cookie is writable by a service on one port, the cookie is also writable by a service running on another port of the same server. For this reason, servers SHOULD NOT both run mutually distrusting services on different ports of the same host and use cookies to store security- sensitive information.

Summary

mechanize applied no trust boundary to a meta refresh, so credentials set through Mechanize#request_headers= followed a refresh that pointed at another origin.

Details

Mechanize::HTTP::Agent#response_follow_meta_refresh fetched the refresh target with no notion of a crossed origin, so @request_headers were re-applied in full. An attacker who could place a meta refresh in a page the agent fetched — through stored content, an open redirect, or control of any page in the crawl — collected the same credentials as through an HTTP redirect, on a code path that had none of the redirect path's protections.

The refresh fetch passes an empty per-request headers hash, so only headers set through Mechanize#request_headers= were exposed.

This requires Mechanize#follow_meta_refresh = true. It is false by default, so an agent in its default configuration is not affected. Crawlers commonly enable it.

Impact

An attacker who can place a meta refresh in any page the agent fetches captures bearer tokens and session cookies set through request_headers=. Disclosure only; no integrity or availability impact.

Patches

Fixed in mechanize v2.14.1. A meta refresh that points at another origin is now subject to the same rule as an HTTP redirect: credentials and cookies are withheld from the request that follows it.

Workarounds

Leave Mechanize#follow_meta_refresh at its default of false, or avoid request_headers= for credentials when it is enabled.

Summary

mechanize leaked credentials to the redirect target when an HTTP redirect crossed to another host. Credentials set through Mechanize#request_headers= leaked even when they were Authorization.

Details

Two defects, both in lib/mechanize/http/agent.rb.

1. Mechanize#request_headers= bypassed the redirect strip entirely. #request_add_headers copied @request_headers onto every request unconditionally, with no host check, including the request issued after a redirect. The strip in #response_redirect mutated only the per-request headers hash and never touched agent state. Because request_headers= is the documented way to set a default credential for every request, the header the code explicitly protected — Authorization — was the one most likely to leak.

2. The strip list omitted Proxy-Authorization and Cookie2. Only CREDENTIAL_HEADERS = ['Authorization'] and COOKIE_HEADERS = ['Cookie'] were removed from the per-request headers hash on a cross-host redirect.

Cookies held in Mechanize#cookie_jar and credentials held in Mechanize::HTTP::AuthStore are not affected. Both are looked up per-URI, so they never follow a redirect to a foreign host. The exposure was limited to headers the caller set by hand.

PoC

agent = Mechanize.new
agent.request_headers = { 'Authorization' => 'Bearer secret' }
agent.get('https://example.test/redirects-to-attacker')
# the request to the attacker's host carries "Authorization: Bearer secret"

Impact

An attacker who controls a redirect target — through an open redirect on the site being fetched, an attacker-supplied fetch URL, DNS rebinding, or MITM — captures bearer tokens and session cookies from any mechanize agent that sets credentials through request_headers= or the per-request headers argument. Disclosure only; no integrity or availability impact.

Patches

Fixed in mechanize v2.14.1.

• Credentials and cookies are withheld from a request that follows a redirect across an origin, from both header sources: the per-request headers argument and Mechanize#request_headers=.
• CREDENTIAL_HEADERS gains Proxy-Authorization; COOKIE_HEADERS gains Cookie2.

Proxy-Authorization is withheld here although curl does not withhold it, because Net::HTTP tunnels https: requests with CONNECT, so a caller-supplied Proxy-Authorization travels inside the tunnel to the origin server rather than to the proxy.

Headers set through Mechanize#request_headers= no longer reach a redirect target on another origin when they are credentials. Callers that relied on the previous behavior will see those headers withheld.

What this fix does not cover

Only the headers in CREDENTIAL_HEADERS and COOKIE_HEADERS are withheld. A caller-supplied header that carries a credential under some other name — X-API-Key, X-Vault-Token, or any bespoke token header — still follows a redirect to another origin, matching the behavior of curl's CURLOPT_HTTPHEADER. If you set such a header, do not enable redirect following for requests that carry it, or scope it to a single request whose destination you control.

Workarounds

Set Mechanize#redirect_ok = false and handle redirects explicitly, or avoid request_headers= for credentials and pass them per-request only to hosts you intend to authenticate to.

Credit

Reported by @SnailSploit.

Summary

Mechanize (rubygem) < v2.8.5 leaks the Authorization header after a redirect to a different port on the same site.

Mitigation

Upgrade to Mechanize v2.8.5 or later.

Notes

See https://curl.se/docs/CVE-2022-27776.html for a similar vulnerability in curl.

Cookies are shared with a server at a different port on the same site, per https://datatracker.ietf.org/doc/html/rfc6265#section-8.5 which states in part:

Cookies do not provide isolation by port. If a cookie is readable by a service running on one port, the cookie is also readable by a service running on another port of the same server. If a cookie is writable by a service on one port, the cookie is also writable by a service running on another port of the same server. For this reason, servers SHOULD NOT both run mutually distrusting services on different ports of the same host and use cookies to store security- sensitive information.

Summary

mechanize applied no trust boundary to a meta refresh, so credentials set through Mechanize#request_headers= followed a refresh that pointed at another origin.

Details

Mechanize::HTTP::Agent#response_follow_meta_refresh fetched the refresh target with no notion of a crossed origin, so @request_headers were re-applied in full. An attacker who could place a meta refresh in a page the agent fetched — through stored content, an open redirect, or control of any page in the crawl — collected the same credentials as through an HTTP redirect, on a code path that had none of the redirect path's protections.

The refresh fetch passes an empty per-request headers hash, so only headers set through Mechanize#request_headers= were exposed.

This requires Mechanize#follow_meta_refresh = true. It is false by default, so an agent in its default configuration is not affected. Crawlers commonly enable it.

Impact

An attacker who can place a meta refresh in any page the agent fetches captures bearer tokens and session cookies set through request_headers=. Disclosure only; no integrity or availability impact.

Patches

Fixed in mechanize v2.14.1. A meta refresh that points at another origin is now subject to the same rule as an HTTP redirect: credentials and cookies are withheld from the request that follows it.

Workarounds

Leave Mechanize#follow_meta_refresh at its default of false, or avoid request_headers= for credentials when it is enabled.

Summary

mechanize leaked credentials to the redirect target when an HTTP redirect crossed to another host. Credentials set through Mechanize#request_headers= leaked even when they were Authorization.

Details

Two defects, both in lib/mechanize/http/agent.rb.

1. Mechanize#request_headers= bypassed the redirect strip entirely. #request_add_headers copied @request_headers onto every request unconditionally, with no host check, including the request issued after a redirect. The strip in #response_redirect mutated only the per-request headers hash and never touched agent state. Because request_headers= is the documented way to set a default credential for every request, the header the code explicitly protected — Authorization — was the one most likely to leak.

2. The strip list omitted Proxy-Authorization and Cookie2. Only CREDENTIAL_HEADERS = ['Authorization'] and COOKIE_HEADERS = ['Cookie'] were removed from the per-request headers hash on a cross-host redirect.

Cookies held in Mechanize#cookie_jar and credentials held in Mechanize::HTTP::AuthStore are not affected. Both are looked up per-URI, so they never follow a redirect to a foreign host. The exposure was limited to headers the caller set by hand.

PoC

agent = Mechanize.new
agent.request_headers = { 'Authorization' => 'Bearer secret' }
agent.get('https://example.test/redirects-to-attacker')
# the request to the attacker's host carries "Authorization: Bearer secret"

Impact

An attacker who controls a redirect target — through an open redirect on the site being fetched, an attacker-supplied fetch URL, DNS rebinding, or MITM — captures bearer tokens and session cookies from any mechanize agent that sets credentials through request_headers= or the per-request headers argument. Disclosure only; no integrity or availability impact.

Patches

Fixed in mechanize v2.14.1.

• Credentials and cookies are withheld from a request that follows a redirect across an origin, from both header sources: the per-request headers argument and Mechanize#request_headers=.
• CREDENTIAL_HEADERS gains Proxy-Authorization; COOKIE_HEADERS gains Cookie2.

Proxy-Authorization is withheld here although curl does not withhold it, because Net::HTTP tunnels https: requests with CONNECT, so a caller-supplied Proxy-Authorization travels inside the tunnel to the origin server rather than to the proxy.

Headers set through Mechanize#request_headers= no longer reach a redirect target on another origin when they are credentials. Callers that relied on the previous behavior will see those headers withheld.

What this fix does not cover

Only the headers in CREDENTIAL_HEADERS and COOKIE_HEADERS are withheld. A caller-supplied header that carries a credential under some other name — X-API-Key, X-Vault-Token, or any bespoke token header — still follows a redirect to another origin, matching the behavior of curl's CURLOPT_HTTPHEADER. If you set such a header, do not enable redirect following for requests that carry it, or scope it to a single request whose destination you control.

Workarounds

Set Mechanize#redirect_ok = false and handle redirects explicitly, or avoid request_headers= for credentials and pass them per-request only to hosts you intend to authenticate to.

Credit

Reported by @SnailSploit.

Summary

Mechanize (rubygem) < v2.8.5 leaks the Authorization header after a redirect to a different port on the same site.

Mitigation

Upgrade to Mechanize v2.8.5 or later.

Notes

See https://curl.se/docs/CVE-2022-27776.html for a similar vulnerability in curl.

Cookies are shared with a server at a different port on the same site, per https://datatracker.ietf.org/doc/html/rfc6265#section-8.5 which states in part:

Cookies do not provide isolation by port. If a cookie is readable by a service running on one port, the cookie is also readable by a service running on another port of the same server. If a cookie is writable by a service on one port, the cookie is also writable by a service running on another port of the same server. For this reason, servers SHOULD NOT both run mutually distrusting services on different ports of the same host and use cookies to store security- sensitive information.

Summary

mechanize applied no trust boundary to a meta refresh, so credentials set through Mechanize#request_headers= followed a refresh that pointed at another origin.

Details

Mechanize::HTTP::Agent#response_follow_meta_refresh fetched the refresh target with no notion of a crossed origin, so @request_headers were re-applied in full. An attacker who could place a meta refresh in a page the agent fetched — through stored content, an open redirect, or control of any page in the crawl — collected the same credentials as through an HTTP redirect, on a code path that had none of the redirect path's protections.

The refresh fetch passes an empty per-request headers hash, so only headers set through Mechanize#request_headers= were exposed.

This requires Mechanize#follow_meta_refresh = true. It is false by default, so an agent in its default configuration is not affected. Crawlers commonly enable it.

Impact

An attacker who can place a meta refresh in any page the agent fetches captures bearer tokens and session cookies set through request_headers=. Disclosure only; no integrity or availability impact.

Patches

Fixed in mechanize v2.14.1. A meta refresh that points at another origin is now subject to the same rule as an HTTP redirect: credentials and cookies are withheld from the request that follows it.

Workarounds

Leave Mechanize#follow_meta_refresh at its default of false, or avoid request_headers= for credentials when it is enabled.

Summary

mechanize leaked credentials to the redirect target when an HTTP redirect crossed to another host. Credentials set through Mechanize#request_headers= leaked even when they were Authorization.

Details

Two defects, both in lib/mechanize/http/agent.rb.

1. Mechanize#request_headers= bypassed the redirect strip entirely. #request_add_headers copied @request_headers onto every request unconditionally, with no host check, including the request issued after a redirect. The strip in #response_redirect mutated only the per-request headers hash and never touched agent state. Because request_headers= is the documented way to set a default credential for every request, the header the code explicitly protected — Authorization — was the one most likely to leak.

2. The strip list omitted Proxy-Authorization and Cookie2. Only CREDENTIAL_HEADERS = ['Authorization'] and COOKIE_HEADERS = ['Cookie'] were removed from the per-request headers hash on a cross-host redirect.

Cookies held in Mechanize#cookie_jar and credentials held in Mechanize::HTTP::AuthStore are not affected. Both are looked up per-URI, so they never follow a redirect to a foreign host. The exposure was limited to headers the caller set by hand.

PoC

agent = Mechanize.new
agent.request_headers = { 'Authorization' => 'Bearer secret' }
agent.get('https://example.test/redirects-to-attacker')
# the request to the attacker's host carries "Authorization: Bearer secret"

Impact

An attacker who controls a redirect target — through an open redirect on the site being fetched, an attacker-supplied fetch URL, DNS rebinding, or MITM — captures bearer tokens and session cookies from any mechanize agent that sets credentials through request_headers= or the per-request headers argument. Disclosure only; no integrity or availability impact.

Patches

Fixed in mechanize v2.14.1.

• Credentials and cookies are withheld from a request that follows a redirect across an origin, from both header sources: the per-request headers argument and Mechanize#request_headers=.
• CREDENTIAL_HEADERS gains Proxy-Authorization; COOKIE_HEADERS gains Cookie2.

Proxy-Authorization is withheld here although curl does not withhold it, because Net::HTTP tunnels https: requests with CONNECT, so a caller-supplied Proxy-Authorization travels inside the tunnel to the origin server rather than to the proxy.

Headers set through Mechanize#request_headers= no longer reach a redirect target on another origin when they are credentials. Callers that relied on the previous behavior will see those headers withheld.

What this fix does not cover

Only the headers in CREDENTIAL_HEADERS and COOKIE_HEADERS are withheld. A caller-supplied header that carries a credential under some other name — X-API-Key, X-Vault-Token, or any bespoke token header — still follows a redirect to another origin, matching the behavior of curl's CURLOPT_HTTPHEADER. If you set such a header, do not enable redirect following for requests that carry it, or scope it to a single request whose destination you control.