Skip to content

Commit 762faf3

Browse files
1 parent 7dd1c1c commit 762faf3

4 files changed

Lines changed: 280 additions & 0 deletions

File tree

Lines changed: 57 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,57 @@
1+
{
2+
"schema_version": "1.4.0",
3+
"id": "GHSA-436v-8fw5-4mj8",
4+
"modified": "2026-04-07T20:13:11Z",
5+
"published": "2026-04-07T20:13:11Z",
6+
"aliases": [
7+
"CVE-2026-35533"
8+
],
9+
"summary": "Local settings bypass config trust checks",
10+
"details": "### Summary\n\n`mise` loads trust-control settings from a local project `.mise.toml` before the trust check runs. An attacker who can place a malicious `.mise.toml` in a repository can make that same file appear trusted and then reach dangerous directives such as `[env] _.source`, templates, hooks, or tasks.\n\nThe strongest current variant is `trusted_config_paths = [\"/\"]`. I confirmed on current `v2026.3.17` in Docker that this causes an untrusted project config to become trusted during `mise hook-env`, which then executes an attacker-controlled `_.source` script. The same preload issue also lets local `yes = true` / `ci = true` auto-approve trust prompts on `v2026.2.18+`, but the primary PoC below uses the stronger `trusted_config_paths` path.\n\n### Details\n\nThe vulnerable load order is:\n\n1. [`Settings::try_get()`](https://github.com/jdx/mise/blob/37997e70cd2216d1a86726fba0c8c09c3986ad06/src/config/settings.rs#L254-L283) preloads local settings files.\n2. [`parse_settings_file()`](https://github.com/jdx/mise/blob/37997e70cd2216d1a86726fba0c8c09c3986ad06/src/config/settings.rs#L505-L510) returns `settings_file.settings` without checking whether the file is trusted.\n3. [`trust_check()`](https://github.com/jdx/mise/blob/37997e70cd2216d1a86726fba0c8c09c3986ad06/src/config/config_file/mod.rs#L297-L321) later consults those already-loaded settings.\n\nThe main trust-bypass path is in [`is_trusted()`](https://github.com/jdx/mise/blob/37997e70cd2216d1a86726fba0c8c09c3986ad06/src/config/config_file/mod.rs#L324-L387):\n\n```rust\nlet settings = Settings::get();\nfor p in settings.trusted_config_paths() {\n if canonicalized_path.starts_with(p) {\n add_trusted(canonicalized_path.to_path_buf());\n return true;\n }\n}\n```\n\nIf a local project file sets:\n\n```toml\n[settings]\ntrusted_config_paths = [\"/\"]\n```\n\nthen every absolute path matches, so the same untrusted file is marked trusted before the dangerous-directive guard is reached.\n\nRelated variant: [`trust_check()`](https://github.com/jdx/mise/blob/37997e70cd2216d1a86726fba0c8c09c3986ad06/src/config/config_file/mod.rs#L307-L316) auto-accepts explicit trust prompts when `Settings::get().yes` is true, and [`Settings::try_get()`](https://github.com/jdx/mise/blob/37997e70cd2216d1a86726fba0c8c09c3986ad06/src/config/settings.rs#L330-L332) sets `yes = true` when `ci` is set. I confirmed that regression on `v2026.2.18`, but the primary PoC below does not depend on it.\n\n### PoC\n\nTest environment:\n\n- Docker\n- `linux-arm64`\n- `mise v2026.3.17`\n\nNegative control:\n\n```toml\n[env]\n_.source = [\"./poc.sh\"]\n```\n\n`mise ls` fails with:\n\n```text\nConfig files in /work/poc/.mise.toml are not trusted.\n```\n\nand `/tmp/mise-proof.txt` is not created.\n\nPrimary exploit:\n\n```toml\n[settings]\ntrusted_config_paths = [\"/\"]\n\n[env]\n_.source = [\"./poc.sh\"]\n```\n\nwith:\n\n```bash\n#!/usr/bin/env bash\necho trusted_paths_hookenv > /tmp/mise-proof.txt\n```\n\nThen:\n\n```bash\nmise hook-env -s bash --force\n```\n\nObserved:\n\n```text\n/tmp/mise-proof.txt => trusted_paths_hookenv\n```\n\nRelated regression check:\n\n- `v2026.2.17`: local `yes = true` does not bypass trust\n- `v2026.2.18`: the same local `yes = true` value auto-approves the trust prompt and the side effect file is created\n\n### Impact\n\nAn attacker who can place a `.mise.toml` in a repository can make `mise` trust and evaluate dangerous directives from that same untrusted file.\n\nDemonstrated on current supported versions:\n\n- execution via `[env] _.source` during `mise hook-env`\n- bypass of the protection that `mise trust` is supposed to provide for dangerous config features\n\nOn newer versions, the same root cause also lets local `yes` / `ci` values auto-approve explicit trust prompts.\n\n### Suggested Fix\n\nDo not honor trust-control settings from non-global project config files.\n\nAt minimum, ignore these fields when loading local project config:\n\n- `trusted_config_paths`\n- `yes`\n- `ci`\n- `paranoid`\n\nFor example:\n\n```rust\npub fn parse_settings_file(path: &Path) -> Result<SettingsPartial> {\n let raw = file::read_to_string(path)?;\n let settings_file: SettingsFile = toml::from_str(&raw)?;\n let mut settings = settings_file.settings;\n\n if !config::is_global_config(path) {\n settings.yes = None;\n settings.ci = None;\n settings.trusted_config_paths = None;\n settings.paranoid = None;\n }\n\n Ok(settings)\n}\n```",
11+
"severity": [
12+
{
13+
"type": "CVSS_V3",
14+
"score": "CVSS:3.1/AV:L/AC:H/PR:N/UI:R/S:C/C:H/I:H/A:H"
15+
}
16+
],
17+
"affected": [
18+
{
19+
"package": {
20+
"ecosystem": "crates.io",
21+
"name": "mise"
22+
},
23+
"ranges": [
24+
{
25+
"type": "ECOSYSTEM",
26+
"events": [
27+
{
28+
"introduced": "2026.2.18"
29+
},
30+
{
31+
"last_affected": "2026.4.5"
32+
}
33+
]
34+
}
35+
]
36+
}
37+
],
38+
"references": [
39+
{
40+
"type": "WEB",
41+
"url": "https://github.com/jdx/mise/security/advisories/GHSA-436v-8fw5-4mj8"
42+
},
43+
{
44+
"type": "PACKAGE",
45+
"url": "https://github.com/jdx/mise"
46+
}
47+
],
48+
"database_specific": {
49+
"cwe_ids": [
50+
"CWE-284"
51+
],
52+
"severity": "HIGH",
53+
"github_reviewed": true,
54+
"github_reviewed_at": "2026-04-07T20:13:11Z",
55+
"nvd_published_at": null
56+
}
57+
}
Lines changed: 61 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,61 @@
1+
{
2+
"schema_version": "1.4.0",
3+
"id": "GHSA-8jxr-pr72-r468",
4+
"modified": "2026-04-07T20:13:32Z",
5+
"published": "2026-04-07T20:13:32Z",
6+
"aliases": [
7+
"CVE-2026-35568"
8+
],
9+
"summary": "Java-SDK has a DNS Rebinding Vulnerability",
10+
"details": "### Summary\n\nThe java-sdk contains a DNS rebinding vulnerability. This vulnerability allows an attacker to access a locally or network-private java-sdk MCP server via a victims browser that is either local, or network adjacent.\n\nThis allows an attacker to make any tool call to the server as if they were a locally running MCP connected AI agent.\n\n### Details\n\nPrior to 1.0.0 no Origin header validation was occurring, in violation of the MCP specification. [Base Protocol > Transports: 2.0.1 Security Warning](https://modelcontextprotocol.io/specification/2025-06-18/basic/transports#security-warning):\n\n> 1: Servers MUST validate the Origin header on all incoming connections to prevent DNS rebinding attacks.\n\nWhen the web server serving HTTP traffic to the MCP server does not perform standard CORS checks, a DNS rebinding attack is possible.\n\nSome default server configurations and frameworks come with embedded `Origin` header validation. MCP servers built using those are not vulnerable to this issue. For example, the following are NOT vulnerable:\n- Spring AI\n\n### Impact\n\nAny developer connecting to a malicious website can inadvertently allow an attacker to make tool calls to local or private-network MCP servers.\n\n### Workarounds\n\nUsers can mitigate this risk by:\n1. Running the MCP server behind a reverse proxy (like Nginx or HAProxy) configured to strictly validate the `Host` and `Origin` headers.\n2. Using a framework that inherently enforces strict CORS and Origin validation (such as Spring AI).",
11+
"severity": [
12+
{
13+
"type": "CVSS_V4",
14+
"score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:P/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N"
15+
}
16+
],
17+
"affected": [
18+
{
19+
"package": {
20+
"ecosystem": "Maven",
21+
"name": "io.modelcontextprotocol.sdk:mcp-core"
22+
},
23+
"ranges": [
24+
{
25+
"type": "ECOSYSTEM",
26+
"events": [
27+
{
28+
"introduced": "0"
29+
},
30+
{
31+
"fixed": "1.0.0"
32+
}
33+
]
34+
}
35+
]
36+
}
37+
],
38+
"references": [
39+
{
40+
"type": "WEB",
41+
"url": "https://github.com/modelcontextprotocol/java-sdk/security/advisories/GHSA-8jxr-pr72-r468"
42+
},
43+
{
44+
"type": "PACKAGE",
45+
"url": "https://github.com/modelcontextprotocol/java-sdk"
46+
},
47+
{
48+
"type": "WEB",
49+
"url": "https://github.com/modelcontextprotocol/java-sdk/releases/tag/v1.0.0"
50+
}
51+
],
52+
"database_specific": {
53+
"cwe_ids": [
54+
"CWE-346"
55+
],
56+
"severity": "HIGH",
57+
"github_reviewed": true,
58+
"github_reviewed_at": "2026-04-07T20:13:32Z",
59+
"nvd_published_at": null
60+
}
61+
}
Lines changed: 68 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,68 @@
1+
{
2+
"schema_version": "1.4.0",
3+
"id": "GHSA-hfpq-x728-986j",
4+
"modified": "2026-04-07T20:13:04Z",
5+
"published": "2026-04-07T20:13:04Z",
6+
"aliases": [
7+
"CVE-2026-35406"
8+
],
9+
"summary": "netavark has incorrect error handling for malformed tcp packets",
10+
"details": "### Impact\n\nA truncated TCP DNS query followed by a connection reset causes aardvark-dns to enter an unrecoverable infinite error loop at 100% CPU.\n\n### Patches\nhttps://github.com/containers/aardvark-dns/commit/3b49ea7b38bdea134b7f03256f2e13f44ce73bb1\n\n### Workarounds\nNone\n\n### Credits\n\nThanks to @dkane01 for reporting this",
11+
"severity": [
12+
{
13+
"type": "CVSS_V3",
14+
"score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H"
15+
}
16+
],
17+
"affected": [
18+
{
19+
"package": {
20+
"ecosystem": "crates.io",
21+
"name": "netavark"
22+
},
23+
"ranges": [
24+
{
25+
"type": "ECOSYSTEM",
26+
"events": [
27+
{
28+
"introduced": "1.16.0"
29+
},
30+
{
31+
"fixed": "1.17.1"
32+
}
33+
]
34+
}
35+
],
36+
"database_specific": {
37+
"last_known_affected_version_range": "<= 1.17.0"
38+
}
39+
}
40+
],
41+
"references": [
42+
{
43+
"type": "WEB",
44+
"url": "https://github.com/containers/aardvark-dns/security/advisories/GHSA-hfpq-x728-986j"
45+
},
46+
{
47+
"type": "WEB",
48+
"url": "https://github.com/containers/aardvark-dns/commit/3b49ea7b38bdea134b7f03256f2e13f44ce73bb1"
49+
},
50+
{
51+
"type": "PACKAGE",
52+
"url": "https://github.com/containers/aardvark-dns"
53+
},
54+
{
55+
"type": "WEB",
56+
"url": "https://github.com/containers/aardvark-dns/releases/tag/v1.17.1"
57+
}
58+
],
59+
"database_specific": {
60+
"cwe_ids": [
61+
"CWE-400"
62+
],
63+
"severity": "MODERATE",
64+
"github_reviewed": true,
65+
"github_reviewed_at": "2026-04-07T20:13:04Z",
66+
"nvd_published_at": null
67+
}
68+
}
Lines changed: 94 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,94 @@
1+
{
2+
"schema_version": "1.4.0",
3+
"id": "GHSA-mh2q-q3fh-2475",
4+
"modified": "2026-04-07T20:12:57Z",
5+
"published": "2026-04-07T20:12:57Z",
6+
"aliases": [
7+
"CVE-2026-29181"
8+
],
9+
"summary": "OpenTelemetry-Go: multi-value `baggage` header extraction causes excessive allocations (remote dos amplification)",
10+
"details": "multi-value `baggage:` header extraction parses each header field-value independently and aggregates members across values. this allows an attacker to amplify cpu and allocations by sending many `baggage:` header lines, even when each individual value is within the 8192-byte per-value parse limit.\n\n## severity\n\nHIGH (availability / remote request amplification)\n\n## relevant links\n\n- repository: https://github.com/open-telemetry/opentelemetry-go\n- pinned callsite: https://github.com/open-telemetry/opentelemetry-go/blob/1ee4a4126dbdd1bc79e9fae072fa488beffac52a/propagation/baggage.go#L58\n\n## vulnerability details\n\n**pins:** open-telemetry/opentelemetry-go@1ee4a4126dbdd1bc79e9fae072fa488beffac52a\n**as-of:** 2026-02-04\n**policy:** direct (no program scope provided)\n\n**callsite:** propagation/baggage.go:58 (`extractMultiBaggage`)\n**attacker control:** inbound HTTP request headers (many `baggage` field-values) → `propagation.HeaderCarrier.Values(\"baggage\")` → repeated `baggage.Parse` + member aggregation\n\n### root cause\n\n`extractMultiBaggage` iterates over all `baggage` header field-values and parses each one independently, then appends members into a shared slice. the 8192-byte parsing cap applies per header value, but the multi-value path repeats that work once per header line (bounded only by the server/proxy header byte limit).\n\n### impact\n\nin a default `net/http` configuration (max header bytes 1mb), a single request with many `baggage:` header field-values can cause large per-request allocations and increased latency.\n\nexample from the attached PoC harness (darwin/arm64; 80 values; 40 requests):\n\n- canonical: `per_req_alloc_bytes=10315458` and `p95_ms=7`\n- control: `per_req_alloc_bytes=133429` and `p95_ms=0`\n\n## proof of concept\n\ncanonical:\n\n```bash\nmkdir -p poc\nunzip poc.zip -d poc\ncd poc\nmake test\n```\n\noutput (excerpt):\n\n```\n[CALLSITE_HIT]: propagation/baggage.go:58 extractMultiBaggage\n[PROOF_MARKER]: baggage_multi_value_amplification p95_ms=7 per_req_alloc_bytes=10315458 per_req_allocs=16165\n```\n\ncontrol:\n\n```bash\ncd poc\nmake control\n```\n\ncontrol output (excerpt):\n\n```\n[NC_MARKER]: baggage_single_value_baseline p95_ms=0 per_req_alloc_bytes=133429 per_req_allocs=480\n```\n\n**expected:** multiple `baggage` header field-values should be semantically equivalent to a single comma-joined `baggage` value and should not multiply parsing/alloc work within the effective header byte budget.\n**actual:** multiple `baggage` header field-values trigger repeated parsing and member aggregation, causing high per-request allocations and increased latency even when each individual value is within 8192 bytes.\n\n## fix recommendation\n\navoid repeated parsing across multi-values by enforcing a global budget and/or normalizing multi-values into a single value before parsing. one mitigation approach is to treat multi-values as a single comma-joined string and cap total parsed bytes (for example 8192 bytes total).\n\n**fix accepted when:** under the default PoC harness settings, canonical stays within 2x of control for `per_req_alloc_bytes` and `per_req_allocs`, and `p95_ms` stays below 2ms.\n\n\n[poc.zip](https://github.com/user-attachments/files/25079945/poc.zip)\n[PR_DESCRIPTION.md](https://github.com/user-attachments/files/25079946/PR_DESCRIPTION.md)",
11+
"severity": [
12+
{
13+
"type": "CVSS_V3",
14+
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H"
15+
}
16+
],
17+
"affected": [
18+
{
19+
"package": {
20+
"ecosystem": "Go",
21+
"name": "go.opentelemetry.io/otel/baggage"
22+
},
23+
"ranges": [
24+
{
25+
"type": "ECOSYSTEM",
26+
"events": [
27+
{
28+
"introduced": "1.36.0"
29+
},
30+
{
31+
"fixed": "1.41.0"
32+
}
33+
]
34+
}
35+
],
36+
"database_specific": {
37+
"last_known_affected_version_range": "<= 1.40.0"
38+
}
39+
},
40+
{
41+
"package": {
42+
"ecosystem": "Go",
43+
"name": "go.opentelemetry.io/otel/propagation"
44+
},
45+
"ranges": [
46+
{
47+
"type": "ECOSYSTEM",
48+
"events": [
49+
{
50+
"introduced": "1.36.0"
51+
},
52+
{
53+
"fixed": "1.41.0"
54+
}
55+
]
56+
}
57+
],
58+
"database_specific": {
59+
"last_known_affected_version_range": "<= 1.40.0"
60+
}
61+
}
62+
],
63+
"references": [
64+
{
65+
"type": "WEB",
66+
"url": "https://github.com/open-telemetry/opentelemetry-go/security/advisories/GHSA-mh2q-q3fh-2475"
67+
},
68+
{
69+
"type": "WEB",
70+
"url": "https://github.com/open-telemetry/opentelemetry-go/pull/7880"
71+
},
72+
{
73+
"type": "WEB",
74+
"url": "https://github.com/open-telemetry/opentelemetry-go/commit/aa1894e09e3fe66860c7885cb40f98901b35277f"
75+
},
76+
{
77+
"type": "PACKAGE",
78+
"url": "https://github.com/open-telemetry/opentelemetry-go"
79+
},
80+
{
81+
"type": "WEB",
82+
"url": "https://github.com/open-telemetry/opentelemetry-go/releases/tag/v1.41.0"
83+
}
84+
],
85+
"database_specific": {
86+
"cwe_ids": [
87+
"CWE-400"
88+
],
89+
"severity": "HIGH",
90+
"github_reviewed": true,
91+
"github_reviewed_at": "2026-04-07T20:12:57Z",
92+
"nvd_published_at": null
93+
}
94+
}

0 commit comments

Comments
 (0)