Staging Environment: Content and features may be unstable or change without notice.

Advisory Severity Curation

GHSA-v92g-xgxw-vvmm

Progress 0 / 0

Advisory Summaries

github_osv/GHSA-v92g-xgxw-vvmm

Mako: Path traversal via double-slash URI prefix in TemplateLookup ### Summary `TemplateLookup.get_template()` is vulnerable to path traversal when a URI starts with `//` (e.g., `//../../../secret.txt`). The root cause is an inconsistency between two slash-stripping implementations: - `Template.__init__` strips **one** leading `/` using `if`/slice - `TemplateLookup.get_template()` strips **all** leading `/` using `re.sub(r"^\/+", "")` When a URI like `//../../../../etc/passwd` is passed: 1. `get_template()` strips all `/` → `../../../../etc/passwd` → file found via `posixpath.join(dir_, u)` 2. `Template.__init__` strips one `/` → `/../../../../etc/passwd` → `normpath` → `/etc/passwd` 3. `/etc/passwd`.startswith(`..`) → `False` → **check bypassed** ### Impact Arbitrary file read: any file readable by the process can be returned as rendered template content when an application passes untrusted input directly to `TemplateLookup.get_template()`. Note: this is exploitable at the library API level. HTTP-based exploitation is mitigated by Python's `BaseHTTPRequestHandler` which normalizes double-slash prefixes since CPython gh-87389. Applications using other HTTP servers that do not normalize paths may be affected. ### Fix Changed `Template.__init__` to use `lstrip("/")` instead of stripping only a single leading slash, so both code paths handle leading slashes consistently.

gitlab/pypi/Mako/CVE-2026-41205

Mako: Path traversal via double-slash URI prefix in TemplateLookup `TemplateLookup.get_template()` is vulnerable to path traversal when a URI starts with `//` (e.g., `//../../../secret.txt`). The root cause is an inconsistency between two slash-stripping implementations: - `Template.__init__` strips **one** leading `/` using `if`/slice - `TemplateLookup.get_template()` strips **all** leading `/` using `re.sub(r"^\/+", "")` When a URI like `//../../../../etc/passwd` is passed: 1. `get_template()` strips all `/` → `../../../../etc/passwd` → file found via `posixpath.join(dir_, u)` 2. `Template.__init__` strips one `/` → `/../../../../etc/passwd` → `normpath` → `/etc/passwd` 3. `/etc/passwd`.startswith(`..`) → `False` → **check bypassed**

gitlab/pypi/Mako/GHSA-v92g-xgxw-vvmm

Mako: Path traversal via double-slash URI prefix in TemplateLookup `TemplateLookup.get_template()` is vulnerable to path traversal when a URI starts with `//` (e.g., `//../../../secret.txt`). The root cause is an inconsistency between two slash-stripping implementations: - `Template.__init__` strips **one** leading `/` using `if`/slice - `TemplateLookup.get_template()` strips **all** leading `/` using `re.sub(r"^\/+", "")` When a URI like `//../../../../etc/passwd` is passed: 1. `get_template()` strips all `/` → `../../../../etc/passwd` → file found via `posixpath.join(dir_, u)` 2. `Template.__init__` strips one `/` → `/../../../../etc/passwd` → `normpath` → `/etc/passwd` 3. `/etc/passwd`.startswith(`..`) → `False` → **check bypassed**

pypa/mako/PYSEC-2026-88

Mako is a template library written in Python. Prior to 1.3.11, TemplateLookup.get_template() is vulnerable to path traversal when a URI starts with // (e.g., //../../../secret.txt). The root cause is an inconsistency between two slash-stripping implementations. Any file readable by the process can be returned as rendered template content when an application passes untrusted input directly to TemplateLookup.get_template(). This vulnerability is fixed in 1.3.11.

pysec/PYSEC-2026-88

Mako is a template library written in Python. Prior to 1.3.11, TemplateLookup.get_template() is vulnerable to path traversal when a URI starts with // (e.g., //../../../secret.txt). The root cause is an inconsistency between two slash-stripping implementations. Any file readable by the process can be returned as rendered template content when an application passes untrusted input directly to TemplateLookup.get_template(). This vulnerability is fixed in 1.3.11.