CVE-2026-107292 is an origin validation error in pydantic-ai affecting versions from 1.34.0 up to but not including 2.30.0. The vulnerability allows DNS rebinding attacks via the Host header in the Agent.to_web() and clai web chat server, enabling a malicious website to interact with a loopback-hosted agent as a same-origin service. This can lead to unauthorized execution of agent tools with local process privileges, causing data disclosure and unwanted side effects. The issue is fixed in versions 1.107.5 and 2.30.0.
CVE-2026-107287 is a medium severity vulnerability in pydantic-ai affecting versions from 1.77.0 up to but not including 1.107.7, and from 2.0.0b1 up to but not including 2.52.0. The issue involves uncontrolled resource consumption during HTML-to-Markdown conversion of attacker-controlled HTML with deeply nested block elements, causing excessive CPU and memory use. This can delay processing of other tasks. The vulnerability is fixed in versions 1.107.7 and 2.52.0.
> This issue was posted by Codex Desktop using gpt-6.1-sol on behalf of David.
### Summary
Applications that wrap a model with `ConcurrencyLimitedModel` or `limit_model_concurrency` can permanently lose shared concurrency capacity when a streamed request releases its slot from a different task than the one that acquired it. This can happen when a stream ends early, and also when a stream is fully consumed using the default `stream_text()` debouncing.
In an application that exposes an affected streaming endpoint to network clients and shares a long-lived model limiter across requests, a client can repeatedly start a stream and disconnect. The completed requests retain their slots, eventually preventing subsequent requests that share the limiter from proceeding.
Agent-level `max_concurrency` and non-streaming model requests are not affected by this defect.
### Details
The built-in limiter uses `anyio.CapacityLimiter`, which associates each acquired slot with its borrowing task. Pydantic AI's streaming lifecycle can acquire the slot on the task consuming the stream and run cleanup on another internal task. The limiter rejects that release, so the slot remains occupied even after the request has ended. Cleanup can raise a `RuntimeError`; a later request on the borrowing task can also fail because that task still holds a slot.
Early termination includes stopping iteration, a consumer exception, and cancellation. Fully consuming `stream_text()` with its default `debounce_by=0.1` can also reach the cross-task release path. Fully consumed streams must therefore not be assumed safe.
### Mitigation
Upgrade to a patched release of `pydantic-ai` or `pydantic-ai-slim`. If you cannot upgrade yet, use the agent-level `max_concurrency` setting instead of a concurrency-limited model, or avoid streaming runs through a concurrency-limited model.
An authorization bypass vulnerability in wger allows an authenticated attacker to inject workout log entries into another user's SlotEntry by omitting ownership checks on the slot_entry foreign key. This leads to cross-user data corruption affecting the victim's workout progression calculations.
A privilege escalation vulnerability in wger allows a user with the gym_trainer role to deactivate accounts of other users within the same gym, including those with higher privileges such as gym_manager and general_gym_manager. This occurs because the UserDeactivateView grants access if the user has any one of several permissions, including gym.gym_trainer, without verifying privilege hierarchy. Consequently, trainers can deactivate managers' accounts, effectively locking them out. The same issue exists in UserActivateView. The vulnerability affects wger versions up to and including 2.1 and has a CVSS score of 7.1 (high severity).
wger contains an access control vulnerability affecting five gym management views where a gym-scope guard fails when both the requesting trainer and target user have no gym assigned (gym=None). This flaw allows an authenticated trainer with specific permissions and no gym assignment to access private admin notes, documents, contracts, user configurations, and permissions of any other unaffiliated user with gym=None. The root cause is a comparison that incorrectly allows access when both gym values are None, combined with querysets that lack secondary gym-scoped filtering.
LMCache multiprocess mode (distributed mode) exposes an unauthenticated ZeroMQ ROUTER socket that accepts msgpack messages. A vulnerability in the deserialization process allows remote attackers to execute arbitrary code via a specially crafted message. This occurs because the server calls pickle.loads on untrusted data before request handling. The default transport binds to localhost, but if configured with a routable address, it can be exploited remotely. Official container images run the LMCache process as root, increasing the impact of exploitation.
CVE-2026-106443 is a high-severity remote code execution vulnerability in Kozea WeasyPrint that arises from improper input validation. WeasyPrint passes untrusted image bytes directly to Pillow's format dispatcher without restricting input formats. When Ghostscript is installed on the host, Pillow's EPS image plugin invokes Ghostscript to rasterize EPS/PS input, allowing attacker-controlled PostScript to execute. Hosts running vulnerable Ghostscript versions with known -dSAFER bypasses can be fully compromised. The vulnerability affects WeasyPrint versions prior to 70.0 and impacts any deployment rendering untrusted content on hosts with Ghostscript installed.
## Summary
Hydra's `instantiate()` API resolves and invokes Python callables named by the `_target_` field in configuration. The target blacklist introduced for CVE-2026-68508 was incomplete.
Representative bypasses included execution wrappers such as `timeit.timeit`, executable deserialization through `pickle.loads`, and generic dispatch or wrapper targets that obscured the effective callable. Target aliases, callable-returning helpers, and deferred dispatch could similarly bypass name-based checks.
An attacker who can cause an application to instantiate an untrusted Hydra configuration can use these gaps to execute code with the application's privileges.
## Fix
Hydra 1.3.6 expands and hardens the blacklist used by the 1.3 compatibility line. It blocks the reported execution and deserialization surfaces, checks canonical callable identities and aliases, mediates callable results, and blocks generic dispatch and wrapper targets that bypass immediate target checks.
The Hydra 1.3 blacklist is a best-effort, defense-in-depth measure. It is not a complete security boundary and does not make untrusted configuration safe to instantiate.
Hydra 1.4.0.dev9 applies the same hardening and introduces the execution whitelist as the recommended primary security boundary. When a whitelist is supplied, targets are rejected unless trusted Python code authorizes them. If no whitelist is supplied, Hydra preserves legacy behavior with a deprecation warning and the blacklist as a best-effort compatibility fallback. Targets that permit configuration to select or supply executable behavior remain non-whitelistable.
## Remediation
Upgrade to Hydra 1.3.6, or to Hydra 1.4.0.dev9 or later when testing the 1.4 prerelease line.
On Hydra 1.3, do not instantiate configuration from untrusted sources. On Hydra 1.4 and later, constrain untrusted configuration with a narrow execution whitelist supplied by trusted Python code.
For Hydra 1.4 execution-whitelist configuration, see: https://hydra.cc/docs/advanced/execution_whitelist/
CVE-2026-106441 is a high-severity code injection vulnerability in the hydra-ecosystem hydra project. The issue arises because Hydra passed its Python logging configuration directly to logging.config.dictConfig() without applying its target policy, allowing resolution and invocation of arbitrary importable classes and factories. This flaw enables an attacker who can control the logging configuration to execute arbitrary code with the application's privileges during logging setup. The vulnerability affects Hydra versions before 1.3.6 and prerelease versions from 1.4.0.dev0 up to but not including 1.4.0.dev9. Hydra 1.3.6 and later apply a hardened blacklist, and 1.4.0.dev9 and later introduce an execution whitelist to control callable invocation securely. Users are advised to upgrade to 1.3.6 or 1.4.0.dev9 or later and avoid composing logging configurations from untrusted sources.
A high-severity vulnerability (CVE-2026-106440) exists in the hydra-ecosystem hydra framework, specifically in the hydra-optuna-sweeper package versions 1.2.0 up to but not including 1.3.0 and 1.4.0.dev4 up to but not including 1.4.0.dev10. The issue involves unsafe reflection where externally controlled input can specify a dotted path to Python code that is resolved and invoked without proper execution policy enforcement. This allows an attacker controlling Optuna sweep configuration or command-line overrides to execute arbitrary Python code with the application's privileges, bypassing trusted execution whitelists. The vulnerability is fixed in versions 1.3.0 and 1.4.0.dev10.
CVE-2026-106439 is a high-severity vulnerability in hydra-ecosystem's hydra affecting versions 1.3.4 through 1.3.6 and 1.4.0.dev4 through 1.4.0.dev9. It involves unsafe reflection where mutable module-level state used for target blocklists can be manipulated via configuration to remove blocked targets and instantiate them, bypassing intended execution restrictions. The vulnerability affects the legacy/default path without an execution whitelist and allows a configuration controlling multiple sibling _target_ entries to mutate the blocklist and invoke otherwise blocked targets. The issue is fixed in hydra-core 1.3.7 and 1.4.0.dev10. Users are advised to upgrade and avoid passing untrusted configuration to instantiate().
A memory corruption vulnerability exists in Vyper versions prior to 0.2.6 when performing function calls inside tuples or nested function calls. This occurs due to an incorrect pointer to the tip of the stack during such calls. The issue was fixed in Vyper version 0.2.6.
A vulnerability in Vyper prior to version 0.2.6 causes call stack corruption when passing multi-dimensional arrays as arguments to internal or external functions. This occurs due to incorrect assumptions about the size of array or struct subtypes during stack management, leading to incorrect output.
A vulnerability in Vyper versions from 0.1.0b10 up to but not including 0.2.3 causes a transaction revert when a return statement is used inside a for loop nested more than one level deep in internal calls. This results in an invalid jump destination and a stack underflow error. The impact is minor and mainly causes unnecessary transaction reverts, but under certain conditions, it could lead to a denial-of-service (DoS) on public contracts. The issue is fixed in Vyper 0.2.3.
CVE-2026-105801 is a code injection vulnerability in openapi-python-client versions prior to 0.29.1. The tool generates Python clients from OpenAPI documents but does not safely neutralize malicious content in string, docstring, and f-string contexts. This allows attacker-controlled Python code to be included in the generated client, which executes upon import, potentially compromising the importing environment's integrity, confidentiality, and availability. The issue is fixed in version 0.29.1.
CVE-2026-105749 is an uncontrolled resource consumption vulnerability in the docling-project's docling software. Versions from 2.0.0 up to but not including 2.131.0 allow HTML, JATS, OpenDocument spreadsheet, and BoxNote backends to accept rowspan and colspan attribute values without upper bounds. This can cause excessive CPU usage or multi-gigabyte memory allocation when processing small documents. The document_timeout setting does not interrupt the backend conversion call, exacerbating the impact. The issue is fixed in version 2.131.0.
### Summary
docling accepts serialized `DoclingDocument` JSON as an input format (`InputFormat.JSON_DOCLING`, enabled by default). A crafted JSON file can set a picture's image `uri` to a local file path. When the converted document is exported with embedded images (`ImageRefMode.EMBEDDED`, the CLI default for Markdown and HTML), the referenced file is read and embedded as base64 in the output.
### Details
`docling/backend/json/docling_json_backend.py` validates the JSON into a `DoclingDocument` without checking image references. The file is then read by docling-core:
- `DoclingDocument._with_embedded_pictures` opens `file://` and plain-path URIs with PIL.
- `ImageRef.pil_image` checks `allow_image_file_uri` for `file://` URIs but not for plain `Path` values. docling's picture enrichment models load images through this property.
Only files that PIL can decode as an image are disclosed. Other files, such as text files or keys, fail to decode and are not embedded. The different error behaviour does reveal whether a path exists.
### Impact
Disclosure of image files readable by the converting process (for example other users' uploads or page images in a shared service), and disclosure of whether a local path exists.
### Proof of concept
```python
from pathlib import Path
from docling_core.types.doc import DoclingDocument, ImageRef
from docling_core.types.doc.base import Size
doc = DoclingDocument(name="poc")
doc.add_picture(image=ImageRef(mimetype="image/png", dpi=72, size=Size(width=1, height=1),
uri=Path("/srv/uploads/other-user/scan.png")))
doc.save_as_json("poc.json")
```
`docling poc.json --to md` embeds the referenced PNG as base64 in `poc.md`.
### Patches
Fixed in docling 2.131.0 by [#4417](https://github.com/docling-project/docling/pull/4417). The Docling JSON backend now drops image references that point at local files (paths, `file:` URIs and any scheme other than `data:` and `http(s)`) and logs a warning. Callers that need to load local images from JSON they trust can opt in with `DoclingJSONFormatOption(backend_options=DeclarativeBackendOptions(enable_local_fetch=True))`; the CLI has no such option.
Code that loads untrusted JSON directly with docling-core (`DoclingDocument.load_from_json`) and exports it with embedded images is not covered by this fix; that part is tracked in docling-core.
### Workarounds
Upgrade to 2.131.0. For older versions:
- Remove `InputFormat.JSON_DOCLING` from `allowed_formats` when converting untrusted input.
- Export with `ImageRefMode.PLACEHOLDER` or `ImageRefMode.REFERENCED` instead of `EMBEDDED`.
### Summary
`allow_external_plugins=False` (the default, and the CLI default) is meant to restrict docling to its own model plugins. However, docling's plugin factories call pluggy's `load_setuptools_entrypoints()`, which imports every module registered under docling's plugin entry-point group. Only afterwards does docling filter out modules outside the `docling.` namespace. Import-time code in any installed third-party plugin therefore runs even though external plugins are disabled.
### Details
In `docling/models/factories/base_factory.py`, `load_from_plugins()` loads all entry points first and applies the `allow_external_plugins` check only to the already-imported modules. The CLI creates these factories when it starts, so running `docling` imports every registered plugin module. A log message says the plugin "will not be loaded", although its module has already been imported.
### Affected configurations
Environments in which a package registering a docling plugin entry point is installed, for example an unvetted or compromised dependency, and which rely on `allow_external_plugins=False` to keep that code from running.
### Impact
Execution of a third-party plugin module's import-time code in the docling process, contrary to the documented behaviour of `allow_external_plugins=False`.
### Patches
Fixed in docling 2.131.0 by [#4413](https://github.com/docling-project/docling/pull/4413). Plugin entry points are now filtered by module name before they are loaded, so with `allow_external_plugins=False` third-party plugin modules are no longer imported.
### Workarounds
Upgrade to 2.131.0. For older versions:
Only install trusted packages in environments that run docling. Check which packages register docling plugin entry points with `importlib.metadata.entry_points()`.
### Summary
When the LaTeX backend is configured to render TikZ pictures with the Tectonic engine (`LatexBackendOptions(tikz_engine="tectonic")`), the TikZ body and the document preamble from the input file are compiled by Tectonic without any restriction on TeX's file primitives. A crafted `.tex` file can read files the process can read and write files at paths the process can write. If the caller also sets `tikz_engine_allow_shell_escape=True`, the document can run shell commands through `\write18`.
### Details
`docling/backend/latex/engines/tectonic.py` writes the picture source into a temporary document and runs the `tectonic` binary on it. `_resolve_local_dependency` only decides which files are staged into the temporary directory. It does not limit what TeX opens at compile time, so:
- `\input{/abs/path}`, `\verbatiminput{...}` and `\openin` read arbitrary files, and their content can be typeset into the rendered picture that ends up in the conversion output. For an in-memory `DocumentStream`, staging is skipped entirely.
- `\immediate\openout` / `\write` create or overwrite files outside the temporary directory. Neither needs shell escape. Tectonic's `--untrusted` flag does not block them either.
Separately, the `TectonicEngine` constructor defaults to `allow_shell_escape=True`. The LaTeX backend always passes `tikz_engine_allow_shell_escape` explicitly (default `False`), so this default only affects code that instantiates `TectonicEngine` directly.
### Affected configurations
- Affected: callers that set `tikz_engine="tectonic"`, have a `tectonic` binary available (on `PATH` or in the docling cache), and convert untrusted LaTeX.
- Not affected: the default configuration (`tikz_engine=None`). docling does not install `tectonic` automatically, and the CLI exposes no option to enable it.
### Impact
Disclosure of local files readable by the process, and creation or overwrite of files writable by the process. Writing to startup or configuration files can lead to code execution. With shell escape enabled, commands run directly.
### Proof of concept
```latex
\documentclass{article}
\usepackage{tikz}
\begin{document}
\begin{tikzpicture}
\immediate\openout15=/tmp/docling-tectonic-poc.txt
\immediate\write15{written by the input document}
\immediate\closeout15
\node {x};
\end{tikzpicture}
\end{document}
```
Converting this file with `LatexBackendOptions(tikz_engine="tectonic")` creates `/tmp/docling-tectonic-poc.txt`.
### Patches
Mitigated in docling 2.132.0 by [#4419](https://github.com/docling-project/docling/pull/4419):
- `TectonicEngine` now defaults to `allow_shell_escape=False`, and without shell escape Tectonic runs with `--untrusted` and `--only-cached`.
- Before compiling, docling checks the generated document and every staged file. It skips rendering, and keeps the diagram as TikZ code, when the source uses the `\openin`, `\openout`, `\XeTeXpicfile` or `\XeTeXpdffile` primitives, or names an absolute, home, drive-letter or parent-directory path in `\input`, `\include`, `\includegraphics`, `\InputIfFileExists` or `\graphicspath`.
This check is best-effort. It reads the source text, and TeX can open files in ways a text check cannot see, for example through package commands or names built by macros. As documented in the [pipeline options reference](https://github.com/docling-project/docling/blob/main/docs/reference/pipeline_options.md), untrusted LaTeX rendered with `tikz_engine="tectonic"` should still be processed in an isolated environment.
### Workarounds
Upgrade to 2.132.0. For older versions:
- Do not enable `tikz_engine="tectonic"` for untrusted input, or run the conversion in an OS-level sandbox (container, no host mounts, read-only filesystem, no network).
- Never set `tikz_engine_allow_shell_escape=True` for untrusted input.