<?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://cve.radiocsirt.org/rss/recent/all/10</id>
  <title>Most recent entries from all</title>
  <updated>2026-10-08T04:49:11.863094+00:00</updated>
  <author>
    <name>Vulnerability-Lookup</name>
    <email>csirt@opendfir.org</email>
  </author>
  <link href="https://cve.radiocsirt.org" 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://cve.radiocsirt.org/vuln/cve-2026-27205</id>
    <title>CVE-2026-27205 — Flask session does not add `Vary: Cookie` header when accessed in some ways</title>
    <updated>2026-10-08T04:49:11.879818+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml"><p><strong>Affected:</strong> pallets flask</p>
<p>Flask is a web server gateway interface (WSGI) web application framework. In versions 3.1.2 and below, when the session object is accessed, Flask should set the Vary: Cookie header., resulting in a Use of Cache Containing Sensitive Information vulnerability. The logic instructs caches not to cache the response, as it may contain information specific to a logged in user. This is handled in most cases, but some forms of access such as the Python in operator were overlooked. The severity and risk depend on the application being hosted behind a caching proxy that doesn't ignore responses with cookies, not setting a Cache-Control header to mark pages as private or non-cacheable, and accessing the session in a way that only touches keys without reading values or mutating the session. The issue has been fixed in version 3.1.3.</p></div>
    </content>
    <link href="https://cve.radiocsirt.org/vuln/cve-2026-27205"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/ghsa-2h4p-vjrc-8xpq</id>
    <title>GHSA-2h4p-vjrc-8xpq — Mako vulnerable to path traversal via backslash URI on Windows in TemplateLookup</title>
    <updated>2026-10-08T04:49:11.879907+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml"><p><strong>Affected:</strong> PyPI: Mako</p>
<p>## Summary</p>
<p>On Windows, a URI using backslash traversal (e.g. `\..\..\ secret.txt`) bypasses the directory traversal check in `Template.__init__` and the `posixpath`-based normalization in `TemplateLookup.get_template()`, allowing reads of files outside the configured template directory.</p>
<p>## Details</p>
<p>The root cause is a mismatch between `posixpath` (used for URI normalization in `get_template()`) and `os.path` (used for file access via `os.path.isfile()` and validation via `os.path.normpath()` in `Template.__init__`). On Windows, `os.path` is `ntpath`, which treats `\` as a path separator, while `posixpath` treats it as a literal character.</p>
<p>The vulnerability chain:</p>
<p>1. `get_template()` strips only leading `/` via `re.sub(r"^\/+", "", uri)` and normalizes with `posixpath` — backslash `\` is treated as a literal character, so `\..\ secret.txt` passes through with `..` undetected.
2. `Template.__init__()` validation uses `os.path.normpath()` — on Windows this resolves `\..\ secret.txt` to `\secret.txt`, which does not start with `..`, so the `startswith("..")` check passes.
3. `os.path.isfile()` on Windows interprets `\` as a path separator, resolving the `..` traversal and finding files outside the template directory.</p>
<p>### Affected code</p>
<p>- `mako/lookup.py`: `TemplateLookup.get_template()` uses `posixpath.normpath`/`posixpath.join` for path construction but `os.path.isfile()` for existence check
- `mako/template.py`: `Template.__init__()` URI validation uses `os.path.normpath…</p></div>
    </content>
    <link href="https://cve.radiocsirt.org/vuln/ghsa-2h4p-vjrc-8xpq"/>
  </entry>
</feed>
