chore(deps): update dependency pymdown-extensions to v11 [security] by renovate[bot] · Pull Request #179 · enter-at/python-aws-lambda-handlers

renovate · 2023-05-31T01:54:45Z

This PR contains the following updates:

Package	Change	Age	Confidence
pymdown-extensions	`==7.1` → `==11.0`

Any file can be included with the pymdown-snippets extension

CVE-2023-32309 / GHSA-jh85-wwv9-24hv

More information

Details

Summary

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 base_path option but the implementation is vulnerable to Directory Traversal.
The vulnerable section exists in get_snippet_path(self, path) lines 155 to 174 in snippets.py.

base = "docs"
path = "/etc/passwd"
filename = os.path.join(base,path) # Filename is now /etc/passwd

PoC

import markdown

payload = "--8<-- \"/etc/passwd\""
html = markdown.markdown(payload, extensions=['pymdownx.snippets'])

print(html)

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 accidentally enable it for user-facing content, undesired information could be exposed.

Suggestion

Specified snippets should be restricted to the configured, specified base paths as a safe default. Allowing relative or absolute paths that escape the specified base paths would need to be behind a feature switch that must be opt-in and would be at the developer's own risk.

Severity

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

References

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

PyMdown Extensions has a ReDOS bug in its Figure Capture extension

CVE-2025-68142 / GHSA-r6h4-mm7h-8pmq

More information

Details

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, PyMdown Extensions will ensure such issues, even if prematurely made public through the normal issue flow, are redirected through the typical security process.

The regular expression pattern in question is as follows:

RE_FIG_NUM = re.compile(r'^(\^)?([1-9][0-9]*(?:.[1-9][0-9]*)*)(?= |$)')

The POC was provided by @ShangzhiXu

import re
import time

regex_pattern = re.compile(r'^(\^)?([1-9][0-9]*(?:.[1-9][0-9]*)*)(?= |$)')

for i in range(50, 500, 50):
    long_string = '1' * i + 'a'
    start_time = time.time()
    match = re.match(regex_pattern, long_string)
    end_time = time.time()
    print(f"long_string execution time: {end_time - start_time:.6f} s")

The issue with the above pattern is that . was used, which accepts any character when we meant to use \.. The fix was to update the pattern to:

RE_FIG_NUM = re.compile(r'^(\^)?([1-9][0-9]*(?:\.[1-9][0-9]*)*)(?= |$)')

Relevant PR with fix: https://github.com/facelessuser/pymdown-extensions/pull/2717

Version(s) & System Info

Operating System: Any
Python Version: Any

Severity

CVSS Score: 2.7 / 10 (Low)
Vector String: CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N/E:U

References

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

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

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

Release Notes

facelessuser/pymdown-extensions (pymdown-extensions)

Uh oh!

Conversation

renovate Bot commented May 31, 2023 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Any file can be included with the pymdown-snippets extension

Details

Summary

Details

PoC

Impact

Suggestion

Severity

References

PyMdown Extensions has a ReDOS bug in its Figure Capture extension

Details

Impact

Patches

Workarounds

References

Description

Version(s) & System Info

Severity

References

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

Details

Summary

Details

PoC

Impact

Suggested fix

Severity

References

Release Notes

11.0

10.21.3

v10.21.2: 10.21. 2

10.21.2

10.21

10.20

10.19.1

10.19

10.18

10.17.2

10.17.1

10.17

v10.16.1: 10.6.1

10.16.1

10.16

10.15.0

10.14.3

10.14.2

10.14.1

10.14

10.13

10.12

10.11.2

10.11.1

10.11

10.10.2

10.10.1

10.10

10.9

10.8.1

10.8

10.7.1

10.7

10.6

10.5

10.4

10.3.1

10.3

10.2.1

10.2

10.0.1

10.0

9.11

9.10

9.9.2

9.9.1

9.9

renovate Bot commented May 31, 2023 •

edited

Loading

`v10.21.2`: 10.21. 2

`v10.16.1`: 10.6.1