<?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-09-28T13:19:45.965868+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/cve-2023-23934</id>
    <title>CVE-2023-23934 — Wrkzeug's incorrect parsing of nameless cookies leads to __Host- cookies bypass</title>
    <updated>2026-09-28T13:19:45.967868+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml"><p><strong>Affected:</strong> pallets werkzeug</p>
<p>Werkzeug is a comprehensive WSGI web application library. Browsers may allow "nameless" cookies that look like `=value` instead of `key=value`. A vulnerable browser may allow a compromised application on an adjacent subdomain to exploit this to set a cookie like `=__Host-test=bad` for another subdomain. Werkzeug prior to 2.2.3 will parse the cookie `=__Host-test=bad` as __Host-test=bad`. If a Werkzeug application is running next to a vulnerable or malicious subdomain which sets such a cookie using a vulnerable browser, the Werkzeug application will see the bad cookie value but the valid cookie key. The issue is fixed in Werkzeug 2.2.3.</p></div>
    </content>
    <link href="https://vulnerability.circl.lu/vuln/cve-2023-23934"/>
  </entry>
  <entry>
    <id>https://vulnerability.circl.lu/vuln/ghsa-px8h-6qxv-m22q</id>
    <title>GHSA-px8h-6qxv-m22q — Incorrect parsing of nameless cookies leads to __Host- cookies bypass</title>
    <updated>2026-09-28T13:19:45.967944+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml"><p><strong>Affected:</strong> PyPI: Werkzeug</p>
<p>Browsers may allow "nameless" cookies that look like `=value` instead of `key=value`. A vulnerable browser may allow a compromised application on an adjacent subdomain to exploit this to set a cookie like `=__Host-test=bad` for another subdomain.</p>
<p>Werkzeug &lt;= 2.2.2 will parse the cookie `=__Host-test=bad` as `__Host-test=bad`. If a Werkzeug application is running next to a vulnerable or malicious subdomain which sets such a cookie using a vulnerable browser, the Werkzeug application will see the bad cookie value but the valid cookie key.</p></div>
    </content>
    <link href="https://vulnerability.circl.lu/vuln/ghsa-px8h-6qxv-m22q"/>
  </entry>
  <entry>
    <id>https://vulnerability.circl.lu/vuln/pysec-2023-57</id>
    <title>PYSEC-2023-57</title>
    <updated>2026-09-28T13:19:45.967977+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml"><p><strong>Affected:</strong> PyPI: werkzeug</p>
<p>Werkzeug is a comprehensive WSGI web application library. Browsers may allow "nameless" cookies that look like `=value` instead of `key=value`. A vulnerable browser may allow a compromised application on an adjacent subdomain to exploit this to set a cookie like `=__Host-test=bad` for another subdomain. Werkzeug prior to 2.2.3 will parse the cookie `=__Host-test=bad` as __Host-test=bad`. If a Werkzeug application is running next to a vulnerable or malicious subdomain which sets such a cookie using a vulnerable browser, the Werkzeug application will see the bad cookie value but the valid cookie key. The issue is fixed in Werkzeug 2.2.3.</p></div>
    </content>
    <link href="https://vulnerability.circl.lu/vuln/pysec-2023-57"/>
  </entry>
</feed>
