<?xml version='1.0' encoding='UTF-8'?>
<?xml-stylesheet href="/static/style.xsl" type="text/xsl"?>
<feed xmlns="http://www.w3.org/2005/Atom" xml:lang="en">
  <id>https://vulnerability.circl.lu/rss/recent/all/10</id>
  <title>Most recent entries from all</title>
  <updated>2026-10-11T17:09:40.063780+00:00</updated>
  <author>
    <name>Vulnerability-Lookup</name>
    <email>info@circl.lu</email>
  </author>
  <link href="https://vulnerability.circl.lu" rel="alternate"/>
  <generator uri="https://lkiesow.github.io/python-feedgen" version="1.0.0">python-feedgen</generator>
  <subtitle>Contains only the most 10 recent entries.</subtitle>
  <entry>
    <id>https://vulnerability.circl.lu/vuln/fkie_cve-2026-107715</id>
    <title>fkie_cve-2026-107715</title>
    <updated>2026-10-11T17:09:40.112247+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml">
        <p>The Mechanize library is used for automating interaction with websites. Prior to 2.14.1, Mechanize sends caller-supplied credential headers to a different host after an HTTP redirect. Mechanize#request_headers= is reapplied by Mechanize::HTTP::Agent#request_add_headers even after Mechanize::HTTP::Agent#response_redirect strips per-request headers, and the protected header lists omit Proxy-Authorization and Cookie2. An attacker who controls a redirect target can capture bearer tokens or session cookies supplied through request_headers= or the per-request headers argument, while Mechanize#cookie_jar and Mechanize::HTTP::AuthStore are not affected. This issue is fixed in version 2.14.1.</p>
      </div>
    </content>
    <link href="https://vulnerability.circl.lu/vuln/fkie_cve-2026-107715"/>
  </entry>
  <entry>
    <id>https://vulnerability.circl.lu/vuln/ghsa-2mwr-xjcg-37j7</id>
    <title>GHSA-2mwr-xjcg-37j7 — Mechanize sends credential headers to another host after an HTTP redirect</title>
    <updated>2026-10-11T17:09:40.112388+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml"><p><strong>Affected:</strong> RubyGems: mechanize</p>
<p>## Summary</p>
<p>`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`.</p>
<p>## Details</p>
<p>Two defects, both in `lib/mechanize/http/agent.rb`.</p>
<p>**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.</p>
<p>**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.</p>
<p>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.</p>
<p>## PoC</p>
<p>```ruby
agent = Mechanize.new
agent.request_headers = { 'Authorization' =&gt; 'Bearer secret' }
agent.get('https://example.test/redirects-to-attacker')
# the request to the attacker's host carries "Authorization: Bearer…</p></div>
    </content>
    <link href="https://vulnerability.circl.lu/vuln/ghsa-2mwr-xjcg-37j7"/>
  </entry>
</feed>
