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.
1099 vulnerabilities reference this CWE, most recent first.
GHSA-4PWQ-XW7J-M297
Vulnerability from github – Published: 2026-06-26 00:32 – Updated: 2026-06-26 00:32Flowise before 3.0.6 contains an arbitrary file read vulnerability in the chatId parameter of the /api/v1/get-upload-file and /api/v1/openai-assistants-file/download endpoints. The chatId value is not validated and is passed to streamStorageFile(), where a fallback file-lookup path constructed without the orgId is evaluated after the storage-directory containment check, allowing path traversal beyond the intended storage directory. Unauthenticated attackers can read sensitive files such as /root/.flowise/database.sqlite, exposing all database content in the default configuration.
{
"affected": [],
"aliases": [
"CVE-2025-71324"
],
"database_specific": {
"cwe_ids": [
"CWE-73"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-06-25T22:16:58Z",
"severity": "HIGH"
},
"details": "Flowise before 3.0.6 contains an arbitrary file read vulnerability in the chatId parameter of the /api/v1/get-upload-file and /api/v1/openai-assistants-file/download endpoints. The chatId value is not validated and is passed to streamStorageFile(), where a fallback file-lookup path constructed without the orgId is evaluated after the storage-directory containment check, allowing path traversal beyond the intended storage directory. Unauthenticated attackers can read sensitive files such as /root/.flowise/database.sqlite, exposing all database content in the default configuration.",
"id": "GHSA-4pwq-xw7j-m297",
"modified": "2026-06-26T00:32:04Z",
"published": "2026-06-26T00:32:04Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/FlowiseAI/Flowise/security/advisories/GHSA-99pg-hqvx-r4gf"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-71324"
},
{
"type": "WEB",
"url": "https://www.vulncheck.com/advisories/flowise-arbitrary-file-read-via-chatid-parameter"
}
],
"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:N/UI:N/VC:H/VI:N/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:X/R:X/V:X/RE:X/U:X",
"type": "CVSS_V4"
}
]
}
GHSA-4Q5V-7G7X-J79W
Vulnerability from github – Published: 2026-05-28 17:44 – Updated: 2026-08-17 17:54Relevant Products/Components:
trestle/core/commands/author/jinja.pytrestle author jinja
Detailed Description:
The -o/--output argument in trestle author jinja allows writing files outside the intended workspace.
The application does not properly validate:
../..\- absolute paths
This allows arbitrary file write to attacker-controlled locations.
Vulnerable code:
output_file = trestle_root / r_output_file
An attacker can overwrite files such as:
.github/workflows/*.yml.git/hooks/*- user writable config files
This can lead to CI/CD compromise or local code execution.
Steps To Reproduce:
- Clone the repository:
git clone https://github.com/oscal-compass/compliance-trestle.git
cd compliance-trestle
- Create template:
echo "hello" > template.j2
- Run:
trestle author jinja -i template.j2 -o "subdir\..\..\..\..\..\poc.txt"
- Observe:
dir E:\poc.txt
The file is written outside the repository workspace.
Browsers Verified In:
Not browser related.
Tested on:
- Windows 11
- Python 3.13
Supporting Material/References:
Affected file:
trestle/core/commands/author/jinja.py
Successfully verified:
- directory traversal using
../ - Windows traversal using
..\ - arbitrary file write outside workspace
Access Vector Required for Exploitation:
Local
Vulnerability Exists in Default Configuration?:
Yes
Is the exploitation trivial or does it involve a multi-step process that may depend on user/victim interaction?:
Trivial. Single command execution.
Exploitation Requires Authentication?:
No
Under what privileges does the vulnerable service or component run?:
Runs with privileges of the user executing the trestle command.
Impact
An attacker can write files outside the intended workspace directory and overwrite sensitive files writable by the current user.
Possible impacts include:
- overwriting
.github/workflows/*.ymlto execute attacker-controlled GitHub Actions workflows - overwriting
.git/hooks/*for local code execution - modifying user configuration files such as
.bashrc - tampering with repository files and generated compliance artifacts
In CI/CD environments, this may result in execution of attacker-controlled commands on build runners.
{
"affected": [
{
"package": {
"ecosystem": "PyPI",
"name": "compliance-trestle"
},
"ranges": [
{
"events": [
{
"introduced": "4.0.0"
},
{
"fixed": "4.0.3"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 3.12.1"
},
"package": {
"ecosystem": "PyPI",
"name": "compliance-trestle"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "3.12.2"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-46345"
],
"database_specific": {
"cwe_ids": [
"CWE-22",
"CWE-36",
"CWE-73"
],
"github_reviewed": true,
"github_reviewed_at": "2026-05-28T17:44:03Z",
"nvd_published_at": null,
"severity": "HIGH"
},
"details": "**Relevant Products/Components:**\n\n* `trestle/core/commands/author/jinja.py`\n* `trestle author jinja`\n\n---\n\n## Detailed Description:\n\nThe `-o/--output` argument in `trestle author jinja` allows writing files outside the intended workspace.\n\nThe application does not properly validate:\n\n* `../`\n* `..\\`\n* absolute paths\n\nThis allows arbitrary file write to attacker-controlled locations.\n\nVulnerable code:\n\n```python\noutput_file = trestle_root / r_output_file\n```\n\nAn attacker can overwrite files such as:\n\n* `.github/workflows/*.yml`\n* `.git/hooks/*`\n* user writable config files\n\nThis can lead to CI/CD compromise or local code execution.\n\n---\n\n## Steps To Reproduce:\n\n1. Clone the repository:\n\n```bash\ngit clone https://github.com/oscal-compass/compliance-trestle.git\ncd compliance-trestle\n```\n\n2. Create template:\n\n```bash\necho \"hello\" \u003e template.j2\n```\n\n3. Run:\n\n```powershell\ntrestle author jinja -i template.j2 -o \"subdir\\..\\..\\..\\..\\..\\poc.txt\"\n```\n\n4. Observe:\n\n```powershell\ndir E:\\poc.txt\n```\n\nThe file is written outside the repository workspace.\n\n---\n\n## Browsers Verified In:\n\nNot browser related.\n\nTested on:\n\n* Windows 11\n* Python 3.13\n\n---\n\n## Supporting Material/References:\n\nAffected file:\n\n```text\ntrestle/core/commands/author/jinja.py\n```\n\nSuccessfully verified:\n\n* directory traversal using `../`\n* Windows traversal using `..\\`\n* arbitrary file write outside workspace\n\n---\n\n## Access Vector Required for Exploitation:\n\nLocal\n\n---\n\n## Vulnerability Exists in Default Configuration?:\n\nYes\n\n---\n\n## Is the exploitation trivial or does it involve a multi-step process that may depend on user/victim interaction?:\n\nTrivial.\nSingle command execution.\n\n---\n\n## Exploitation Requires Authentication?:\n\nNo\n\n---\n\n## Under what privileges does the vulnerable service or component run?:\n\nRuns with privileges of the user executing the `trestle` command.\n\n## Impact\n\nAn attacker can write files outside the intended workspace directory and overwrite sensitive files writable by the current user.\n\nPossible impacts include:\n\n* overwriting `.github/workflows/*.yml` to execute attacker-controlled GitHub Actions workflows\n* overwriting `.git/hooks/*` for local code execution\n* modifying user configuration files such as `.bashrc`\n* tampering with repository files and generated compliance artifacts\n\nIn CI/CD environments, this may result in execution of attacker-controlled commands on build runners.",
"id": "GHSA-4q5v-7g7x-j79w",
"modified": "2026-08-17T17:54:42Z",
"published": "2026-05-28T17:44:03Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/oscal-compass/compliance-trestle/security/advisories/GHSA-4q5v-7g7x-j79w"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-46345"
},
{
"type": "WEB",
"url": "https://github.com/oscal-compass/compliance-trestle/commit/247fcce289f60103f3d8e28d8ec51a6986b94fb6"
},
{
"type": "WEB",
"url": "https://github.com/oscal-compass/compliance-trestle/commit/7d107b3ac53caca7bde97a6278b23cd739d94525"
},
{
"type": "PACKAGE",
"url": "https://github.com/oscal-compass/compliance-trestle"
},
{
"type": "WEB",
"url": "https://github.com/pypa/advisory-database/tree/main/vulns/compliance-trestle/PYSEC-2026-2423.yaml"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
],
"summary": "compliance-trestle - jinja has an Arbitrary File Write via Path Traversal"
}
GHSA-4WH8-2PQJ-9GW4
Vulnerability from github – Published: 2026-06-03 03:30 – Updated: 2026-06-03 03:30A vulnerability was detected in SourceCodester Online Food Ordering System 2.0. Affected by this issue is the function include of the file /index.php. The manipulation of the argument page results in file inclusion. The attack can be launched remotely. The exploit is now public and may be used.
{
"affected": [],
"aliases": [
"CVE-2026-10694"
],
"database_specific": {
"cwe_ids": [
"CWE-73"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-06-03T01:16:23Z",
"severity": "MODERATE"
},
"details": "A vulnerability was detected in SourceCodester Online Food Ordering System 2.0. Affected by this issue is the function include of the file /index.php. The manipulation of the argument page results in file inclusion. The attack can be launched remotely. The exploit is now public and may be used.",
"id": "GHSA-4wh8-2pqj-9gw4",
"modified": "2026-06-03T03:30:24Z",
"published": "2026-06-03T03:30:24Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-10694"
},
{
"type": "WEB",
"url": "https://github.com/Mikkoseven/cve/issues/4"
},
{
"type": "WEB",
"url": "https://vuldb.com/cve/CVE-2026-10694"
},
{
"type": "WEB",
"url": "https://vuldb.com/submit/830903"
},
{
"type": "WEB",
"url": "https://vuldb.com/vuln/367963"
},
{
"type": "WEB",
"url": "https://vuldb.com/vuln/367963/cti"
},
{
"type": "WEB",
"url": "https://www.sourcecodester.com"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:L",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:L/VI:L/VA:L/SC:N/SI:N/SA:N/E:P/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-4XMM-W6FX-6VM3
Vulnerability from github – Published: 2025-10-18 06:30 – Updated: 2025-10-18 06:30The Media Library Assistant plugin for WordPress is vulnerable to limited file reading in all versions up to, and including, 3.29 via the mla-stream-image.php file. This makes it possible for unauthenticated attackers to read the contents of arbitrary ai/eps/pdf/ps files on the server, which can contain sensitive information.
{
"affected": [],
"aliases": [
"CVE-2025-11738"
],
"database_specific": {
"cwe_ids": [
"CWE-73"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-10-18T06:15:37Z",
"severity": "MODERATE"
},
"details": "The Media Library Assistant plugin for WordPress is vulnerable to limited file reading in all versions up to, and including, 3.29 via the mla-stream-image.php file. This makes it possible for unauthenticated attackers to read the contents of arbitrary ai/eps/pdf/ps files on the server, which can contain sensitive information.",
"id": "GHSA-4xmm-w6fx-6vm3",
"modified": "2025-10-18T06:30:26Z",
"published": "2025-10-18T06:30:25Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-11738"
},
{
"type": "WEB",
"url": "https://plugins.trac.wordpress.org/changeset?sfp_email=\u0026sfph_mail=\u0026reponame=\u0026old=3379043%40media-library-assistant\u0026new=3379043%40media-library-assistant\u0026sfp_email=\u0026sfph_mail="
},
{
"type": "WEB",
"url": "https://plugins.trac.wordpress.org/changeset?sfp_email=\u0026sfph_mail=\u0026reponame=\u0026old=3379044%40media-library-assistant\u0026new=3379044%40media-library-assistant\u0026sfp_email=\u0026sfph_mail="
},
{
"type": "WEB",
"url": "https://www.wordfence.com/threat-intel/vulnerabilities/id/43d1264a-2265-4423-a643-7ef6436d3764?source=cve"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-52VM-MXX8-F227
Vulnerability from github – Published: 2026-07-09 13:37 – Updated: 2026-07-09 13:37Impact
In Phantom <= 1.3.0, when PHANTOM_OUTPUT_DIR was unset (the default), the MCP tools accepted arbitrary absolute output paths with no confinement. Anything able to send tool calls (e.g. an AI agent driving the MCP interface) could write or overwrite arbitrary files the process user can write — including shell startup files (~/.zshrc) or a Reaper __startup.lua, which is effectively local code execution on a developer workstation.
Separately, the stem-separation and render paths decoded input audio with no size/duration cap (the analysis path was already guarded). A small, highly compressed FLAC/OGG could expand to multi-gigabyte PCM, causing memory-exhaustion DoS, and widened exposure to decoder bugs including libsndfile CVE-2026-37555.
Patches
Fixed in 1.3.1:
- File writes are always confined to PHANTOM_OUTPUT_DIR (default ~/.phantom/output); symlinks resolved and re-verified on the final path.
- Decode/duration/size guards mirrored onto the separation and render paths (plus ffmpeg -max_alloc/-t/-fs).
- Atomic O_CREAT|O_EXCL output creation in reference matching and symlink-TOCTOU hardening on confined input reads.
Workarounds
Set PHANTOM_OUTPUT_DIR (and optionally PHANTOM_AUDIO_DIR) to dedicated directories before starting the server.
Credit
Found during an internal security audit.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 1.3.0"
},
"package": {
"ecosystem": "PyPI",
"name": "phantom-audio"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.3.1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [],
"database_specific": {
"cwe_ids": [
"CWE-22",
"CWE-400",
"CWE-73"
],
"github_reviewed": true,
"github_reviewed_at": "2026-07-09T13:37:34Z",
"nvd_published_at": null,
"severity": "HIGH"
},
"details": "### Impact\n\nIn Phantom \u003c= 1.3.0, when `PHANTOM_OUTPUT_DIR` was unset (the default), the MCP tools accepted arbitrary absolute output paths with no confinement. Anything able to send tool calls (e.g. an AI agent driving the MCP interface) could **write or overwrite arbitrary files** the process user can write \u2014 including shell startup files (`~/.zshrc`) or a Reaper `__startup.lua`, which is effectively local code execution on a developer workstation.\n\nSeparately, the stem-separation and render paths decoded input audio with no size/duration cap (the analysis path was already guarded). A small, highly compressed FLAC/OGG could expand to multi-gigabyte PCM, causing memory-exhaustion DoS, and widened exposure to decoder bugs including libsndfile CVE-2026-37555.\n\n### Patches\nFixed in **1.3.1**:\n- File writes are always confined to `PHANTOM_OUTPUT_DIR` (default `~/.phantom/output`); symlinks resolved and re-verified on the final path.\n- Decode/duration/size guards mirrored onto the separation and render paths (plus ffmpeg `-max_alloc`/`-t`/`-fs`).\n- Atomic `O_CREAT|O_EXCL` output creation in reference matching and symlink-TOCTOU hardening on confined input reads.\n\n### Workarounds\nSet `PHANTOM_OUTPUT_DIR` (and optionally `PHANTOM_AUDIO_DIR`) to dedicated directories before starting the server.\n\n### Credit\nFound during an internal security audit.",
"id": "GHSA-52vm-mxx8-f227",
"modified": "2026-07-09T13:37:34Z",
"published": "2026-07-09T13:37:34Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/fadelabs/phantom/security/advisories/GHSA-52vm-mxx8-f227"
},
{
"type": "PACKAGE",
"url": "https://github.com/fadelabs/phantom"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N",
"type": "CVSS_V3"
}
],
"summary": "Phantom: Arbitrary file write and decode-bomb DoS via unconfined MCP tool paths"
}
GHSA-5383-J2P9-QFG3
Vulnerability from github – Published: 2026-07-13 18:30 – Updated: 2026-07-13 18:30mcp-gitlab contains a path traversal vulnerability in the job_id parameter of build/index.js that allows attackers to redirect GitLab API requests to arbitrary endpoints. Attackers can supply crafted job_id values like ../../../user to escape the intended path prefix and access arbitrary GitLab API resources using the operator's personal access token.
{
"affected": [],
"aliases": [
"CVE-2026-61462"
],
"database_specific": {
"cwe_ids": [
"CWE-73"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-07-13T18:16:29Z",
"severity": "CRITICAL"
},
"details": "mcp-gitlab contains a path traversal vulnerability in the job_id parameter of build/index.js that allows attackers to redirect GitLab API requests to arbitrary endpoints. Attackers can supply crafted job_id values like ../../../user to escape the intended path prefix and access arbitrary GitLab API resources using the operator\u0027s personal access token.",
"id": "GHSA-5383-j2p9-qfg3",
"modified": "2026-07-13T18:30:53Z",
"published": "2026-07-13T18:30:53Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-61462"
},
{
"type": "WEB",
"url": "https://github.com/zereight/gitlab-mcp/issues/587"
},
{
"type": "WEB",
"url": "https://github.com/zereight/gitlab-mcp/commit/e2a81a047ab8750fa5bfa1763b5d85e5616f3994"
},
{
"type": "WEB",
"url": "https://github.com/zereight/gitlab-mcp"
},
{
"type": "WEB",
"url": "https://www.vulncheck.com/advisories/mcp-gitlab-path-traversal-via-job-id-parameter"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:N/A:N",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:N/VA:N/SC:H/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-539C-MJ4X-M9HP
Vulnerability from github – Published: 2026-09-03 15:32 – Updated: 2026-09-03 15:32AVideo through commit c91b5975d contains a cross-site request forgery and path traversal vulnerability in stopLive.php that allows attackers to delete directories by exploiting missing token validation and unsanitized key parameter concatenation. Attackers can craft an image tag with a traversal payload like key=../../videos to trigger recursive deletion of the videos directory when an admin visits a malicious page.
{
"affected": [],
"aliases": [
"CVE-2026-85160"
],
"database_specific": {
"cwe_ids": [
"CWE-73"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-09-03T13:06:22Z",
"severity": "HIGH"
},
"details": "AVideo through commit c91b5975d contains a cross-site request forgery and path traversal vulnerability in stopLive.php that allows attackers to delete directories by exploiting missing token validation and unsanitized key parameter concatenation. Attackers can craft an image tag with a traversal payload like key=../../videos to trigger recursive deletion of the videos directory when an admin visits a malicious page.",
"id": "GHSA-539c-mj4x-m9hp",
"modified": "2026-09-03T15:32:18Z",
"published": "2026-09-03T15:32:18Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/WWBN/AVideo/security/advisories/GHSA-qqhx-ccvr-97q7"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-85160"
},
{
"type": "WEB",
"url": "https://www.vulncheck.com/advisories/avideo-through-c91b5975d-csrf-and-path-traversal-via-stoplive-php"
}
],
"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:H",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:P/VC:N/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-539M-9XH6-Q6RR
Vulnerability from github – Published: 2026-08-03 20:14 – Updated: 2026-08-03 20:14Target: gitpython-developers/GitPython
Tested: HEAD 07e80555 (2026-07-25), latest release 3.1.55, git version 2.50.1
Summary
Repo.archive() does call the option guard, so this is not a missing-guard report. The guard is present and working; the denylist it consults is incomplete.
# git/repo/base.py:169
unsafe_git_archive_options = [
# Allows arbitrary command execution through the remote git-upload-archive command.
"--exec",
# Writes output to a caller-controlled filesystem path.
"--output",
"-o",
]
The comment on --output states the protected class in the project's own words: an option that lets the caller name a filesystem path is unsafe. --output is blocked because it writes to a caller-chosen path.
git archive also accepts --add-file=<path> and --add-virtual-file=<path:content> (both present in current git; verified against git version 2.50.1). --add-file reads a caller-chosen path — including an absolute path outside the repository — and places the bytes into the archive the caller receives. Neither option is in the list, and no other layer references them:
$ grep -rniE "add.file|add_file" git/
git/index/base.py:771: R"""Add files from the working tree, ... # unrelated docstring
Net effect: the guard blocks arbitrary file write at this sink while permitting arbitrary file read at the same sink.
Reachability proof (verified at the sink)
poc/poc_addfile.py at HEAD 07e80555. The PoC creates its own out-of-tree canary, so it runs from a clean machine:
-- CONTROL: options the denylist covers (expect BLOCKED) --
[BLOCKED] output='/tmp/gp_written.tar': --output is not allowed, use `allow_unsafe_options=True` to allow it.
[BLOCKED] o='/tmp/gp_written.tar': -o is not allowed, use `allow_unsafe_options=True` to allow it.
[BLOCKED] exec='touch /tmp/gp_exec': --exec is not allowed, use `allow_unsafe_options=True` to allow it.
-- SIBLING OMITTED FROM THE DENYLIST: --add-file (expect ALLOWED) --
[ALLOWED] add_file='/tmp/gp_canary.txt' -> archive 10240 bytes
archive members: ['f.txt', 'gp_canary.txt']
>>> EXFILTRATED gp_canary.txt: 'secret-canary-12345'
>>> byte-for-byte match with the out-of-tree file: CONFIRMED
-- also: --add-virtual-file (attacker-chosen name AND content) --
[ALLOWED] add_virtual_file='pwn.txt:hello' -> archive 10240 bytes
The three blocked lines are the control: they prove the guard is active on this call path, so the fourth result is a gap in list membership rather than a guard that never ran.
Minimal reproduction:
import io, tarfile
from git import Repo
buf = io.BytesIO()
Repo("/path/to/repo").archive(buf, format="tar", add_file="/etc/passwd")
print(tarfile.open(fileobj=io.BytesIO(buf.getvalue())).getnames())
# ['<repo files>', 'passwd'] <- contents readable by whoever receives the archive
The canary is untracked and lives outside the repository; its contents are recovered from the returned archive and asserted byte-for-byte against the on-disk file. The option is rendered by transform_kwargs into --add-file=<path> and reaches git archive unmodified.
Direct precedent
GHSA-6p8h-3wgx-97gf (High, published 2026-07-22) is the same defect on the sibling list: "Incomplete unsafe_git_clone_options denylist omits --template" — an option absent from one of these denylists, reachable under the same caller-controlled-options precondition, accepted and fixed by adding it. git log shows the archive list itself has already been extended reactively once, in 701ce32f (fix: Guard unsafe git command options, GHSA-956x-8gvw-wg5v), and the --template omission was then fixed separately in ffcb5359.
--add-virtual-file is the same gap pointing the other way
--add-virtual-file=<path:content> lets the caller inject attacker-chosen content under an attacker-chosen name into an archive that downstream consumers will reasonably treat as repository-derived.
Suggested remediation
- Preferred — allowlist.
Repo.archive()has a small legitimate option surface (format,prefix,worktree_attributes,remote, compression level, plus paths). Accepting those and rejecting the rest means a future git release cannot add another path-taking option that silently reopens this. - Minimum — extend the list with
--add-fileand--add-virtual-file, and make the membership rule "the option takes a filesystem path or URL" rather than "the option executes a command". The existing comment on--outputalready implies that rule; applying it consistently is what closes the class instead of this instance.
Scope limits
- Impact is arbitrary file read at the privileges of the process. Not code execution — I make no such claim here.
- It requires the embedding application to forward caller-influenced kwargs into
Repo.archive(). That is the identical precondition to--output,--execand--template, all of which this project has treated as reportable.
Disclosure
Reported privately via GitHub private vulnerability reporting. Happy to test a candidate patch against the PoC. No public disclosure until you have shipped a fix and are ready.
Addendum (2026-07-25) — related observation on the same membership question, filed here rather than separately
While auditing the archive denylist, the same class of gap was identified in unsafe_git_clone_options. A second advisory is not being requested, as the issue is lower severity and should inform the fix for the issue above rather than require separate triage. Recording it here to provide the complete picture in one place.
Repo._clone() treats a URL's protocol as a security boundary and applies check_unsafe_protocols() to exactly one input:
clone_url = Git.polish_url(url, expand_vars=False)
if not allow_unsafe_protocols:
Git.check_unsafe_protocols(clone_url) # the positional url only
git clone accepts a second URL via --bundle-uri=<uri>, which git dereferences before the main transport runs. That option is absent from unsafe_git_clone_options, so the option guard passes it, and check_unsafe_protocols() never inspects it. A caller-influenced value therefore drives an outbound request from the host:
Repo.clone_from(trusted_url, dest,
multi_options=["--bundle-uri=http://169.254.169.254/latest/meta-data/"])
# no UnsafeProtocolError, no UnsafeOptionError
Confirmed against a local listener — the request leaves the process:
127.0.0.1 - - [24/Jul/2026 23:07:41] "GET /internal-metadata HTTP/1.1" 404 -
file:///path is likewise accepted without error. Note this is not a tokenisation bypass: multi_options is shlex.split before the check (per c9a26789 / GHSA-x2qx-6953-8485), so the fully-split --bundle-uri=... token is checked and legitimately passes because the option is not on the list.
Why it belongs with this report: both are the membership question rather than the matching logic — is the set of blocked options complete, and does the protocol guard inspect every URL git will dereference? The structural remediation proposed above covers both if extended slightly: prefer an allowlist per command, and route every URL-bearing option through check_unsafe_protocols(), not only the positional URL. Adding --bundle-uri to unsafe_git_clone_options would be the minimal fix.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 3.1.56"
},
"package": {
"ecosystem": "PyPI",
"name": "GitPython"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "3.1.57"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [],
"database_specific": {
"cwe_ids": [
"CWE-200",
"CWE-73"
],
"github_reviewed": true,
"github_reviewed_at": "2026-08-03T20:14:28Z",
"nvd_published_at": null,
"severity": "MODERATE"
},
"details": "**Target:** gitpython-developers/GitPython\n**Tested:** HEAD `07e80555` (2026-07-25), latest release 3.1.55, `git version 2.50.1`\n\n## Summary\n\n`Repo.archive()` does call the option guard, so this is not a missing-guard report. The guard is present and working; the **denylist it consults is incomplete**.\n\n```python\n# git/repo/base.py:169\nunsafe_git_archive_options = [\n # Allows arbitrary command execution through the remote git-upload-archive command.\n \"--exec\",\n # Writes output to a caller-controlled filesystem path.\n \"--output\",\n \"-o\",\n]\n```\n\nThe comment on `--output` states the protected class in the project\u0027s own words: an option that lets the caller name **a filesystem path** is unsafe. `--output` is blocked because it *writes* to a caller-chosen path.\n\n`git archive` also accepts `--add-file=\u003cpath\u003e` and `--add-virtual-file=\u003cpath:content\u003e` (both present in current git; verified against `git version 2.50.1`). `--add-file` *reads* a caller-chosen path \u2014 including an absolute path outside the repository \u2014 and places the bytes into the archive the caller receives. Neither option is in the list, and no other layer references them:\n\n```\n$ grep -rniE \"add.file|add_file\" git/\ngit/index/base.py:771: R\"\"\"Add files from the working tree, ... # unrelated docstring\n```\n\nNet effect: the guard blocks arbitrary file **write** at this sink while permitting arbitrary file **read** at the same sink.\n\n## Reachability proof (verified at the sink)\n\n`poc/poc_addfile.py` at HEAD `07e80555`. The PoC creates its own out-of-tree canary, so it runs from a clean machine:\n\n```\n-- CONTROL: options the denylist covers (expect BLOCKED) --\n [BLOCKED] output=\u0027/tmp/gp_written.tar\u0027: --output is not allowed, use `allow_unsafe_options=True` to allow it.\n [BLOCKED] o=\u0027/tmp/gp_written.tar\u0027: -o is not allowed, use `allow_unsafe_options=True` to allow it.\n [BLOCKED] exec=\u0027touch /tmp/gp_exec\u0027: --exec is not allowed, use `allow_unsafe_options=True` to allow it.\n\n-- SIBLING OMITTED FROM THE DENYLIST: --add-file (expect ALLOWED) --\n [ALLOWED] add_file=\u0027/tmp/gp_canary.txt\u0027 -\u003e archive 10240 bytes\n archive members: [\u0027f.txt\u0027, \u0027gp_canary.txt\u0027]\n \u003e\u003e\u003e EXFILTRATED gp_canary.txt: \u0027secret-canary-12345\u0027\n \u003e\u003e\u003e byte-for-byte match with the out-of-tree file: CONFIRMED\n\n-- also: --add-virtual-file (attacker-chosen name AND content) --\n [ALLOWED] add_virtual_file=\u0027pwn.txt:hello\u0027 -\u003e archive 10240 bytes\n```\n\nThe three blocked lines are the control: they prove the guard is active on this call path, so the fourth result is a gap in list membership rather than a guard that never ran.\n\nMinimal reproduction:\n\n```python\nimport io, tarfile\nfrom git import Repo\n\nbuf = io.BytesIO()\nRepo(\"/path/to/repo\").archive(buf, format=\"tar\", add_file=\"/etc/passwd\")\nprint(tarfile.open(fileobj=io.BytesIO(buf.getvalue())).getnames())\n# [\u0027\u003crepo files\u003e\u0027, \u0027passwd\u0027] \u003c- contents readable by whoever receives the archive\n```\n\nThe canary is untracked and lives outside the repository; its contents are recovered from the returned archive and asserted byte-for-byte against the on-disk file. The option is rendered by `transform_kwargs` into `--add-file=\u003cpath\u003e` and reaches `git archive` unmodified.\n\n## Direct precedent\n\n`GHSA-6p8h-3wgx-97gf` (High, published 2026-07-22) is the same defect on the sibling list: *\"Incomplete `unsafe_git_clone_options` denylist omits `--template`\"* \u2014 an option absent from one of these denylists, reachable under the same caller-controlled-options precondition, accepted and fixed by adding it. `git log` shows the archive list itself has already been extended reactively once, in `701ce32f` (*fix: Guard unsafe git command options*, GHSA-956x-8gvw-wg5v), and the `--template` omission was then fixed separately in `ffcb5359`.\n\n## `--add-virtual-file` is the same gap pointing the other way\n\n`--add-virtual-file=\u003cpath:content\u003e` lets the caller inject **attacker-chosen content under an attacker-chosen name** into an archive that downstream consumers will reasonably treat as repository-derived. \n\n## Suggested remediation\n\n1. **Preferred \u2014 allowlist.** `Repo.archive()` has a small legitimate option surface (`format`, `prefix`, `worktree_attributes`, `remote`, compression level, plus paths). Accepting those and rejecting the rest means a future git release cannot add another path-taking option that silently reopens this.\n2. **Minimum \u2014 extend the list** with `--add-file` and `--add-virtual-file`, and make the membership rule *\"the option takes a filesystem path or URL\"* rather than *\"the option executes a command\"*. The existing comment on `--output` already implies that rule; applying it consistently is what closes the class instead of this instance.\n\n## Scope limits\n\n- Impact is **arbitrary file read at the privileges of the process**. Not code execution \u2014 I make no such claim here.\n- It requires the embedding application to forward caller-influenced kwargs into `Repo.archive()`. That is the identical precondition to `--output`, `--exec` and `--template`, all of which this project has treated as reportable.\n\n## Disclosure\n\nReported privately via GitHub private vulnerability reporting. Happy to test a candidate patch against the PoC. No public disclosure until you have shipped a fix and are ready.\n---\n\n## Addendum (2026-07-25) \u2014 related observation on the same membership question, filed here rather than separately\n\nWhile auditing the archive denylist, the same class of gap was identified in unsafe_git_clone_options. A second advisory is not being requested, as the issue is lower severity and should inform the fix for the issue above rather than require separate triage. Recording it here to provide the complete picture in one place.\n\n`Repo._clone()` treats a URL\u0027s protocol as a security boundary and applies `check_unsafe_protocols()` to exactly one input:\n\n```python\nclone_url = Git.polish_url(url, expand_vars=False)\nif not allow_unsafe_protocols:\n Git.check_unsafe_protocols(clone_url) # the positional url only\n```\n\n`git clone` accepts a **second** URL via `--bundle-uri=\u003curi\u003e`, which git dereferences before the main transport runs. That option is absent from `unsafe_git_clone_options`, so the option guard passes it, and `check_unsafe_protocols()` never inspects it. A caller-influenced value therefore drives an outbound request from the host:\n\n```python\nRepo.clone_from(trusted_url, dest,\n multi_options=[\"--bundle-uri=http://169.254.169.254/latest/meta-data/\"])\n# no UnsafeProtocolError, no UnsafeOptionError\n```\n\nConfirmed against a local listener \u2014 the request leaves the process:\n\n```\n127.0.0.1 - - [24/Jul/2026 23:07:41] \"GET /internal-metadata HTTP/1.1\" 404 -\n```\n\n`file:///path` is likewise accepted without error. Note this is **not** a tokenisation bypass: `multi_options` is `shlex.split` before the check (per `c9a26789` / GHSA-x2qx-6953-8485), so the fully-split `--bundle-uri=...` token is checked and legitimately passes because the option is not on the list.\n\nWhy it belongs with this report: both are the *membership* question rather than the matching logic \u2014 is the set of blocked options complete, and does the protocol guard inspect every URL git will dereference? The structural remediation proposed above covers both if extended slightly: prefer an allowlist per command, and route **every** URL-bearing option through `check_unsafe_protocols()`, not only the positional URL. Adding `--bundle-uri` to `unsafe_git_clone_options` would be the minimal fix.",
"id": "GHSA-539m-9xh6-q6rr",
"modified": "2026-08-03T20:14:28Z",
"published": "2026-08-03T20:14:28Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/gitpython-developers/GitPython/security/advisories/GHSA-539m-9xh6-q6rr"
},
{
"type": "WEB",
"url": "https://github.com/gitpython-developers/GitPython/pull/2193"
},
{
"type": "WEB",
"url": "https://github.com/gitpython-developers/GitPython/commit/7a4f5dcb7bf3cbcbf6e438017efcdfe0bc0d36ca"
},
{
"type": "PACKAGE",
"url": "https://github.com/gitpython-developers/GitPython"
},
{
"type": "WEB",
"url": "https://github.com/gitpython-developers/GitPython/releases/tag/3.1.57"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
}
],
"summary": "GitPython: Incomplete unsafe_git_archive_options denylist omits --add-file / --add-virtual-file, enabling arbitrary file read via Repo.archive()"
}
GHSA-53CW-7XJX-6838
Vulnerability from github – Published: 2026-03-31 18:31 – Updated: 2026-04-01 21:30An arbitrary file overwrite vulnerability in MaruNuri LLC v2.0.23 allows attackers to overwrite critical internal files via the file import process, leading to arbitrary code execution or information exposure.
{
"affected": [],
"aliases": [
"CVE-2026-30281"
],
"database_specific": {
"cwe_ids": [
"CWE-73"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-03-31T16:16:29Z",
"severity": "CRITICAL"
},
"details": "An arbitrary file overwrite vulnerability in MaruNuri LLC v2.0.23 allows attackers to overwrite critical internal files via the file import process, leading to arbitrary code execution or information exposure.",
"id": "GHSA-53cw-7xjx-6838",
"modified": "2026-04-01T21:30:27Z",
"published": "2026-03-31T18:31:31Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-30281"
},
{
"type": "WEB",
"url": "https://github.com/Secsys-FDU/AF_CVEs/issues/21"
},
{
"type": "WEB",
"url": "https://maru.xyz"
},
{
"type": "WEB",
"url": "https://play.google.com/store/apps/details?id=neo.maru"
},
{
"type": "WEB",
"url": "https://secsys.fudan.edu.cn"
}
],
"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-53MW-8PFF-677J
Vulnerability from github – Published: 2024-07-31 03:32 – Updated: 2024-07-31 03:32A vulnerability in the JSON file handling of gaizhenbiao/chuanhuchatgpt version 20240410 allows any user to delete any JSON file on the server, including critical configuration files such as config.json and ds_config_chatbot.json. This issue arises due to improper validation of file paths, enabling directory traversal attacks. An attacker can exploit this vulnerability to disrupt the functioning of the system, manipulate settings, or potentially cause data loss or corruption.
{
"affected": [],
"aliases": [
"CVE-2024-6255"
],
"database_specific": {
"cwe_ids": [
"CWE-22",
"CWE-73"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-07-31T01:15:09Z",
"severity": "HIGH"
},
"details": "A vulnerability in the JSON file handling of gaizhenbiao/chuanhuchatgpt version 20240410 allows any user to delete any JSON file on the server, including critical configuration files such as `config.json` and `ds_config_chatbot.json`. This issue arises due to improper validation of file paths, enabling directory traversal attacks. An attacker can exploit this vulnerability to disrupt the functioning of the system, manipulate settings, or potentially cause data loss or corruption.",
"id": "GHSA-53mw-8pff-677j",
"modified": "2024-07-31T03:32:22Z",
"published": "2024-07-31T03:32:22Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-6255"
},
{
"type": "WEB",
"url": "https://huntr.com/bounties/48f3e370-6dcd-4f38-9350-d0419b3a7f82"
}
],
"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"
}
]
}
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.