IBM Langflow OSS 1.0.0 through 1.12.2 could allow a remote authenticated attacker to obtain sensitive information due to a path traversal vulnerability.
IBM Langflow OSS versions 1.0.0 through 1.12.2 contain a path traversal vulnerability (CWE-22) that allows a remote authenticated attacker to access sensitive information by bypassing directory restrictions. This vulnerability has a high severity with a CVSS score of 8.1, indicating significant confidentiality and integrity impact without affecting availability.
CVE-2026-101155 is a critical path traversal vulnerability in Arista Networks CloudVision Portal. An authenticated remote attacker with specific permissions can exploit this flaw to read or write files outside the intended directory scope via crafted requests or file uploads in the Software Management Studio Software Repository. The vulnerability affects multiple versions from 2024.2.0 through 2026.2.0. It has a high CVSS score of 9.1, indicating severe impact on confidentiality, integrity, and availability.
CVE-2026-101154 is a path traversal vulnerability in Arista Networks CloudVision Portal that allows an authenticated remote attacker with specific permissions to read or write files outside the intended directory scope. This occurs through specially crafted requests or file uploads to the Network Provisioning Image Repository. The vulnerability affects multiple versions of CloudVision Portal from 2018.1.0 through 2026.2.0. It has a high severity rating with a CVSS score of 7.2, indicating significant confidentiality, integrity, and availability impacts. No known exploits are reported in the wild, and no patch links are provided in the available data. The product is not a cloud service, so remediation depends on vendor advisories. The vulnerability is identified as CWE-22, improper limitation of a pathname to a restricted directory.
CVE-2026-101153 is a path traversal vulnerability in Arista Networks CloudVision Portal (on-premises) and CloudVision Sensor. It allows an authenticated user with high privileges to access unintended data by exploiting improper limitation of pathnames. The vulnerability affects multiple versions from 1.0.0 up to 2026.2.0. The CVSS score is 8.0, indicating high severity with significant confidentiality, integrity, and availability impacts.
Dell System Update versions prior to 2.3.0.0 contain a critical path traversal vulnerability (CWE-22) that allows an unauthenticated remote attacker to access the filesystem. This flaw can be exploited to execute arbitrary code with root privileges, potentially leading to full system compromise. Dell recommends upgrading to version 2.3.0.0 or later to remediate this issue.
Dell System Update, versions prior to 2.3.0.0, contains an Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal') vulnerability. A low privileged attacker with local access could potentially exploit this vulnerability, leading to Remote execution.
CVE-2026-106109 is a path traversal vulnerability in the Quasar Framework's @quasar/app-vite build tool. Versions from 1.0.0 up to but not including 3.3.0 recursively remove the resolved build.distDir directory before building without properly restricting critical directories such as the project root, user home, filesystem roots, or symlink-resolved external directories. This can lead to unintended deletion of data writable by the build user if an unsafe trusted configuration is used. Exploitation requires either compromised or less-trusted automation influencing the build configuration or a developer running a mistaken configuration. The vulnerability is fixed in version 3.3.0.
CVE-2026-106103 is a path traversal vulnerability in the Quasar Framework's icongenie tool prior to version 6.1.1. The vulnerability allows a developer running a crafted profile to write or overwrite files outside the intended project directory, potentially modifying critical executable configuration files. This issue is fixed in version 6.1.1.
## Impact
Under certain conditions, an authenticated user with permission to modify uploads could cause unintended files to be removed during file cleanup. This may result in data loss or service disruption.
You are affected if:
- You use Payload upload collections with local file storage.
- Untrusted authenticated users can update or delete uploads.
Deployments that restrict upload management to trusted users are less exposed.
## Patches
Payload now validates uploaded filenames and ensures file cleanup remains within the configured upload directory.
Users should upgrade Payload packages to `>= 3.90.0` or `>= 4.0.0-canary.34`.
## Workarounds
Restrict upload update and deletion operations to trusted users and validate submitted filenames. These measures are temporary mitigations. Upgrading to a patched version is recommended.
### Impact
When generating an API plugin manifest from an attacker-controlled or compromised OpenAPI description, Kiota copies `x-ai-capabilities.response_semantics.oauth_card_path` into the manifest without validating that it is a safe package-relative file reference. An attacker can supply parent-directory traversal, rooted paths, or absolute URIs instead of a card file within the plugin package.
The unsafe reference is propagated into the generated manifest. Its security effect depends on the downstream host's handling of the reference when the plugin is packaged and deployed. This is not local code execution or a file read performed by Kiota merely during generation. A consuming host that resolves the untrusted reference can cross the intended package boundary or use an unintended authentication card.
### Affected versions
The affected NuGet packages are `Microsoft.OpenApi.Kiota` and `Microsoft.OpenApi.Kiota.Builder`, starting with version 1.25.1, which introduced this manifest field. The field remains unvalidated through version 1.34.1, including the separate 1.29.1 security-backport release. Version 1.35.0 fixes the issue.
### Patches
Upgrade to Kiota 1.35.0 or later and regenerate affected plugin manifests. Kiota now applies the existing safe-file-reference validator to `oauth_card_path`, drops unsafe references, and emits a warning. Valid relative card paths remain supported.
- Fix: https://github.com/microsoft/kiota/pull/8055
- Fixed release: https://github.com/microsoft/kiota/releases/tag/v1.35.0
### Workarounds
Generate plugins only from trusted, integrity-protected OpenAPI descriptions. Before packaging or deployment, review generated manifests and remove any `oauth_card_path` that is not a safe relative reference confined to the plugin package. Do not rely on validation of sibling manifest fields to validate this field.
### Related advisories
GHSA-4jwf-m4wg-8p66 and GHSA-p5rm-jg5c-8c77 cover `static_template.file`. Their fixes do not enforce validation at the separate `oauth_card_path` emission site.
Docling simplifies document processing by parsing diverse formats and providing integrations with the generative AI ecosystem. From 2.107.0 until 2.120.3, docling/backend/opendocument_backend.py uses the xlink:href attribute value of a draw:image element as a filesystem path when the referenced part is not found in the document archive. The _image_ref_from_odf_image function reads that attacker-controlled path without a scheme check, extraction-directory confinement, or the enable_local_fetch setting used by other backends. Readable files that Pillow can decode as images are embedded in converted output, and other existing paths can be distinguished through the attempted read. This issue is fixed in 2.120.3.
### 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.
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.
CVE-2026-105677 is a path traversal vulnerability in TryGhost Ghost that allows an authenticated Administrator to execute arbitrary code on the server via a crafted theme. The issue affects Ghost versions from 6.10.3 up to but not including 6.64.0. The vulnerability is fixed in version 6.64.0. This flaw arises from improper limitation of pathname to a restricted directory when loading theme translation files.
CVE-2026-105676 is a path traversal vulnerability in TryGhost Ghost affecting versions from 1.20.0 up to but not including 6.64.0. It allows an authenticated Administrator to read JSON files outside the active theme's directory, potentially exposing sensitive server configuration secrets. The issue is fixed in version 6.64.0.
auto-changelog versions before 2.6.1 merge configuration from inside the target repository, including untrusted files, into their options. This allows execution of attacker-controlled code via the handlebarsSetup option, loading malicious modules via plugins, git argument injection, arbitrary file writes, and outbound requests to attacker-chosen URLs. Version 2.6.1 mitigates this by treating in-repository configuration as untrusted and refusing to run if unsafe options are set unless overridden by a specific flag.