Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
5 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
Four inline processors in pymdown-extensions contain regular expressions with exponential backtracking. A single untrusted Markdown line under 50 bytes drives markdown.markdown() into unbounded CPU on the rendering thread (seconds at ~45 bytes, growing exponentially with each added character). All four fire in the extension's default configuration and are reachable through the documented public API. The caret/tilde/ betterem blow-up was introduced by the emphasis-pattern rewrite in PR #2547 (first released in 10.13, Dec 2024) — earlier releases used a linear (.+?) / ([^\s]+?) content group — and is present through 11.0 (latest); magiclink's host pattern is long-standing and affects effectively all releases. Likely CWE-1333 (Inefficient Regular Expression Complexity). This is a distinct issue from CVE-2025-68142 (ReDoS in pymdownx.blocks.caption, REFIGNUM, fixed in 10.16.1): different extensions, different regexes, and a different root cause (delimiter-run partition ambiguity…
Recommended action: Upgrade to 11.0.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The b64 extension inlines images referenced by <img src="..." as base64 data URIs. When resolving the src path it joins it onto the configured basepath with os.path.normpath and opens the result directly, with no check that the resolved path stays inside basepath. A src containing ../ sequences, or an absolute path, therefore reads a file outside basepath as long as that file has an allowed image extension (.png, .jpg, .jpeg, .gif, .svg). The base64 of that file is then embedded in the rendered output, disclosing its contents. This is a separate code path from the snippets traversal issues (GHSA-jh85-wwv9-24hv, GHSA-62q4-447f-wv8h). It lives in pymdownx/b64.py and has no path restriction of any kind. Confirmed on 10.21.3 installed from PyPI. Details In pymdownx/b64.py, function replpath (around lines 68 to 90 on main): There is no startswith(basepath), no os.path.realpath comparison, and no rejection of ... Both branches are reachable from an attacker-controlled src. PoC…
Recommended action: Upgrade to 11.0.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
pymdownx.snippets has a regression of the CVE-2023-32309 / GHSA-jh85-wwv9-24hv fix. With restrictbasepath: True (the default), the current filename.startswith(base) containment check does not enforce a directory boundary. As a result, a markdown snippet directive can read files from sibling paths that share the same prefix as basepath, such as docs vs docsinternal. The regression was introduced in PR #2039 / commit 7c13bda5b7793b172efd1abb6712e156a83fe07d, which replaced the original directory-identity check with a plain string-prefix comparison. Details The regression was introduced in commit 7c13bda5b7793b172efd1abb6712e156a83fe07d (2023-05-15, #2039 "Fix regression of snippets nested deeply under specified base path"), which relaxed the original os.path.samefile(base, os.path.dirname(filename)) check to a plain startswith(base). SnippetPreprocessor.getsnippetpath() in pymdownx/snippets.py: base is os.path.abspath(b) and has no trailing separator. str.startswith(base) is…
Recommended action: Upgrade to 10.21.3 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact This issue describes a ReDOS bug found within the figure caption extension (pymdownx.blocks.caption ). In systems that take unchecked user content, this could cause long hangs when processing the data if a malicious payload was crafted. Patches This issue is patched in Release 10.16.1. Workarounds Some possible workarounds If users are concerned about this vulnerability and process unknown user content without timeouts or other safeguards in place to prevent really large, malicious content being aimed at systems, the use of pymdownx.blocks.caption could be avoided until the library is updated to 10.16.1+. References The original issue https://github.com/facelessuser/pymdown-extensions/issues/2716. Description The original issue came through PyMdown Extensions' normal issue tracker instead of the typical security flow: https://github.com/facelessuser/pymdown-extensions/issues/2716. Because this came through the normal issue flow, it was handled as a normal issue. In the future,…
Recommended action: Upgrade to 10.16.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Arbitrary file read when using include file syntax. Details By using the syntax --8<--"/etc/passwd" or --8<--"/proc/self/environ" the content of these files will be rendered in the generated documentation. Additionally, a path relative to a specified, allowed base path can also be used to render the content of a file outside the specified base paths: --8<-- "../../../../etc/passwd". Within the Snippets extension, there exists a basepath option but the implementation is vulnerable to Directory Traversal. The vulnerable section exists in getsnippetpath(self, path) lines 155 to 174 in snippets.py. PoC Impact Any readable file on the host where the plugin is executing may have its content exposed. This can impact any use of Snippets that exposes the use of Snippets to external users. It is never recommended to use Snippets to process user-facing, dynamic content. It is designed to process known content on the backend under the control of the host, but if someone were to…
Recommended action: Upgrade to 10.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.