Search
Find a vulnerability
Search criteria
336 vulnerabilities
CVE-2026-103061 (GCVE-0-2026-103061)
Vulnerability from cvelistv5 – Published: 2026-10-12 18:23 – Updated: 2026-10-12 18:23
VLAI
EPSS
VEX
Title
Path traversal in Gleam via unvalidated package application names
Summary
Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal') vulnerability in gleam-lang gleam allows a malicious package publisher to delete a directory outside the project's build directory when a developer builds a project.
A Hex package release's metadata carries an app field with the release's OTP application name. Gleam reads this field from the hex.pm release API when it downloads dependencies and uses it as the package's build directory name without validating it (hex_manifest_package in compiler-cli/src/dependencies.rs, ProjectPaths::build_directory_for_package). When a dependency fails to compile, Gleam deletes that directory with remove_dir_all. hex.pm didn't restrict the field to a directory name before 2026-10-12, so a publisher could set it to a value such as ../../../../target or an absolute path. When a project depends on such a release directly or transitively and the release fails to compile, gleam build, gleam check, gleam run, gleam test or gleam export deletes the directory the name resolves to. For a pure Gleam package no publisher code runs.
This issue affects gleam: from 0.32.4 before 1.19.2.
Severity
CWE
- CWE-22 - Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')
Assigner
References
6 references
Impacted products
3 products
| Vendor | Product | Version | |
|---|---|---|---|
| Gleam | Gleam |
Affected:
0.32.4 , < 1.19.2
(semver)
cpe:2.3:a:gleam-lang:gleam:*:*:*:*:*:*:*:* |
|
| Gleam | Gleam |
Affected:
v0.32.4-elixir , < v1.19.2-elixir
(other)
Affected: v0.32.4-erlang , < v1.19.2-erlang (other) Affected: v0.32.4-node , < v1.19.2-node (other) Affected: v0.32.4-node-slim , < v1.19.2-node-slim (other) Affected: v0.32.4-elixir-slim , < v1.19.2-elixir-slim (other) Affected: v0.32.4-erlang-slim , < v1.19.2-erlang-slim (other) Affected: v0.32.4-erlang-alpine , < v1.19.2-erlang-alpine (other) Affected: v0.32.4-elixir-alpine , < v1.19.2-elixir-alpine (other) Affected: v0.32.4-node-alpine , < v1.19.2-node-alpine (other) Affected: v0.32.4-scratch , < v1.19.2-scratch (other) cpe:2.3:a:gleam-lang:gleam:*:*:*:*:*:*:*:* |
|
| Gleam | Gleam |
Affected:
d13f27ee80aae7a521d2e9433c4deaf53f892574 , < *
(git)
cpe:2.3:a:gleam-lang:gleam:*:*:*:*:*:*:*:* |
{
"containers": {
"cna": {
"affected": [
{
"cpes": [
"cpe:2.3:a:gleam-lang:gleam:*:*:*:*:*:*:*:*"
],
"defaultStatus": "unaffected",
"modules": [
"gleam_cli::dependencies",
"gleam_core::manifest",
"gleam_core::paths",
"gleam_core::build::project_compiler",
"gleam_cli::fs"
],
"packageName": "gleam",
"packageURL": "pkg:software-id/gleam.run/gleam",
"product": "Gleam",
"programFiles": [
"compiler-cli/src/dependencies.rs",
"compiler-core/src/manifest.rs",
"compiler-core/src/paths.rs",
"compiler-core/src/build/project_compiler.rs",
"compiler-cli/src/fs.rs"
],
"programRoutines": [
{
"name": "gleam_cli::dependencies::hex_manifest_package"
},
{
"name": "gleam_core::manifest::ManifestPackage::application_name"
},
{
"name": "gleam_core::paths::ProjectPaths::build_directory_for_package"
},
{
"name": "gleam_core::build::project_compiler::ProjectCompiler::load_cache_or_compile_package"
},
{
"name": "gleam_cli::fs::delete_directory"
}
],
"vendor": "Gleam",
"versions": [
{
"lessThan": "1.19.2",
"status": "affected",
"version": "0.32.4",
"versionType": "semver"
}
]
},
{
"collectionURL": "https://ghcr.io",
"cpes": [
"cpe:2.3:a:gleam-lang:gleam:*:*:*:*:*:*:*:*"
],
"defaultStatus": "unaffected",
"modules": [
"gleam_cli::dependencies",
"gleam_core::manifest",
"gleam_core::paths",
"gleam_core::build::project_compiler",
"gleam_cli::fs"
],
"packageName": "gleam-lang/gleam",
"packageURL": "pkg:oci/gleam?repository_url=ghcr.io%2Fgleam-lang",
"product": "Gleam",
"programFiles": [
"compiler-cli/src/dependencies.rs",
"compiler-core/src/manifest.rs",
"compiler-core/src/paths.rs",
"compiler-core/src/build/project_compiler.rs",
"compiler-cli/src/fs.rs"
],
"programRoutines": [
{
"name": "gleam_cli::dependencies::hex_manifest_package"
},
{
"name": "gleam_core::manifest::ManifestPackage::application_name"
},
{
"name": "gleam_core::paths::ProjectPaths::build_directory_for_package"
},
{
"name": "gleam_core::build::project_compiler::ProjectCompiler::load_cache_or_compile_package"
},
{
"name": "gleam_cli::fs::delete_directory"
}
],
"vendor": "Gleam",
"versions": [
{
"lessThan": "v1.19.2-elixir",
"status": "affected",
"version": "v0.32.4-elixir",
"versionType": "other"
},
{
"lessThan": "v1.19.2-erlang",
"status": "affected",
"version": "v0.32.4-erlang",
"versionType": "other"
},
{
"lessThan": "v1.19.2-node",
"status": "affected",
"version": "v0.32.4-node",
"versionType": "other"
},
{
"lessThan": "v1.19.2-node-slim",
"status": "affected",
"version": "v0.32.4-node-slim",
"versionType": "other"
},
{
"lessThan": "v1.19.2-elixir-slim",
"status": "affected",
"version": "v0.32.4-elixir-slim",
"versionType": "other"
},
{
"lessThan": "v1.19.2-erlang-slim",
"status": "affected",
"version": "v0.32.4-erlang-slim",
"versionType": "other"
},
{
"lessThan": "v1.19.2-erlang-alpine",
"status": "affected",
"version": "v0.32.4-erlang-alpine",
"versionType": "other"
},
{
"lessThan": "v1.19.2-elixir-alpine",
"status": "affected",
"version": "v0.32.4-elixir-alpine",
"versionType": "other"
},
{
"lessThan": "v1.19.2-node-alpine",
"status": "affected",
"version": "v0.32.4-node-alpine",
"versionType": "other"
},
{
"lessThan": "v1.19.2-scratch",
"status": "affected",
"version": "v0.32.4-scratch",
"versionType": "other"
}
]
},
{
"collectionURL": "https://github.com",
"cpes": [
"cpe:2.3:a:gleam-lang:gleam:*:*:*:*:*:*:*:*"
],
"defaultStatus": "unaffected",
"modules": [
"gleam_cli::dependencies",
"gleam_core::manifest",
"gleam_core::paths",
"gleam_core::build::project_compiler",
"gleam_cli::fs"
],
"packageName": "gleam-lang/gleam",
"packageURL": "pkg:github/gleam-lang/gleam",
"product": "Gleam",
"programFiles": [
"compiler-cli/src/dependencies.rs",
"compiler-core/src/manifest.rs",
"compiler-core/src/paths.rs",
"compiler-core/src/build/project_compiler.rs",
"compiler-cli/src/fs.rs"
],
"programRoutines": [
{
"name": "gleam_cli::dependencies::hex_manifest_package"
},
{
"name": "gleam_core::manifest::ManifestPackage::application_name"
},
{
"name": "gleam_core::paths::ProjectPaths::build_directory_for_package"
},
{
"name": "gleam_core::build::project_compiler::ProjectCompiler::load_cache_or_compile_package"
},
{
"name": "gleam_cli::fs::delete_directory"
}
],
"repo": "https://github.com/gleam-lang/gleam",
"vendor": "Gleam",
"versions": [
{
"changes": [
{
"at": "d15c981fac6e533d70ac8ee89a6ef4dbf139adc3",
"status": "unaffected"
},
{
"at": "54bbb2b98af1505b6eed93c45b1936fc76412e5c",
"status": "unaffected"
}
],
"lessThan": "*",
"status": "affected",
"version": "d13f27ee80aae7a521d2e9433c4deaf53f892574",
"versionType": "git"
}
]
}
],
"configurations": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003eAffects projects whose dependency tree, directly or transitively, contains a hex.pm package release whose OTP application name is a path, when the project is built with \u003ccode\u003egleam build\u003c/code\u003e, \u003ccode\u003egleam check\u003c/code\u003e, \u003ccode\u003egleam run\u003c/code\u003e, \u003ccode\u003egleam test\u003c/code\u003e or \u003ccode\u003egleam export\u003c/code\u003e. \u003ccode\u003egleam deps download\u003c/code\u003e alone doesn\u0027t reach the delete. Gleam only uses hex.pm, which rejects such application names when a release is published since 2026-10-12, so only releases published before then can have one.\u003c/p\u003e"
},
{
"base64": false,
"type": "text/markdown",
"value": "Affects projects whose dependency tree, directly or transitively, contains a hex.pm package release whose OTP application name is a path, when the project is built with `gleam build`, `gleam check`, `gleam run`, `gleam test` or `gleam export`. `gleam deps download` alone doesn\u0027t reach the delete. Gleam only uses hex.pm, which rejects such application names when a release is published since 2026-10-12, so only releases published before then can have one."
}
],
"value": "Affects projects whose dependency tree, directly or transitively, contains a hex.pm package release whose OTP application name is a path, when the project is built with gleam build, gleam check, gleam run, gleam test or gleam export. gleam deps download alone doesn\u0027t reach the delete. Gleam only uses hex.pm, which rejects such application names when a release is published since 2026-10-12, so only releases published before then can have one."
}
],
"cpeApplicability": [
{
"nodes": [
{
"cpeMatch": [
{
"criteria": "cpe:2.3:a:gleam-lang:gleam:*:*:*:*:*:*:*:*",
"versionEndExcluding": "1.19.2",
"versionStartIncluding": "0.32.4",
"vulnerable": true
}
],
"negate": false,
"operator": "OR"
}
],
"operator": "AND"
}
],
"credits": [
{
"lang": "en",
"type": "finder",
"value": "Peter Ullrich"
},
{
"lang": "en",
"type": "remediation developer",
"value": "Louis Pilfold"
},
{
"lang": "en",
"type": "coordinator",
"value": "Eric Meadows-J\u00f6nsson"
},
{
"lang": "en",
"type": "analyst",
"value": "Jonatan M\u00e4nnchen / EEF"
}
],
"dateAssigned": "2026-10-07T22:06:26.000Z",
"descriptions": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003eImproper Limitation of a Pathname to a Restricted Directory (\u0027Path Traversal\u0027) vulnerability in gleam-lang gleam allows a malicious package publisher to delete a directory outside the project\u0027s build directory when a developer builds a project.\u003c/p\u003e\n\u003cp\u003eA Hex package release\u0027s metadata carries an \u003ccode\u003eapp\u003c/code\u003e field with the release\u0027s OTP application name. Gleam reads this field from the hex.pm release API when it downloads dependencies and uses it as the package\u0027s build directory name without validating it (\u003ccode\u003ehex_manifest_package\u003c/code\u003e in \u003ccode\u003ecompiler-cli/src/dependencies.rs\u003c/code\u003e, \u003ccode\u003eProjectPaths::build_directory_for_package\u003c/code\u003e). When a dependency fails to compile, Gleam deletes that directory with \u003ccode\u003eremove_dir_all\u003c/code\u003e. hex.pm didn\u0027t restrict the field to a directory name before 2026-10-12, so a publisher could set it to a value such as \u003ccode\u003e../../../../target\u003c/code\u003e or an absolute path. When a project depends on such a release directly or transitively and the release fails to compile, \u003ccode\u003egleam build\u003c/code\u003e, \u003ccode\u003egleam check\u003c/code\u003e, \u003ccode\u003egleam run\u003c/code\u003e, \u003ccode\u003egleam test\u003c/code\u003e or \u003ccode\u003egleam export\u003c/code\u003e deletes the directory the name resolves to. For a pure Gleam package no publisher code runs.\u003c/p\u003e\n\u003cp\u003eThis issue affects gleam: from 0.32.4 before 1.19.2.\u003c/p\u003e"
},
{
"base64": false,
"type": "text/markdown",
"value": "Improper Limitation of a Pathname to a Restricted Directory (\u0027Path Traversal\u0027) vulnerability in gleam-lang gleam allows a malicious package publisher to delete a directory outside the project\u0027s build directory when a developer builds a project.\n\nA Hex package release\u0027s metadata carries an `app` field with the release\u0027s OTP application name. Gleam reads this field from the hex.pm release API when it downloads dependencies and uses it as the package\u0027s build directory name without validating it (`hex_manifest_package` in `compiler-cli/src/dependencies.rs`, `ProjectPaths::build_directory_for_package`). When a dependency fails to compile, Gleam deletes that directory with `remove_dir_all`. hex.pm didn\u0027t restrict the field to a directory name before 2026-10-12, so a publisher could set it to a value such as `../../../../target` or an absolute path. When a project depends on such a release directly or transitively and the release fails to compile, `gleam build`, `gleam check`, `gleam run`, `gleam test` or `gleam export` deletes the directory the name resolves to. For a pure Gleam package no publisher code runs.\n\nThis issue affects gleam: from 0.32.4 before 1.19.2."
}
],
"value": "Improper Limitation of a Pathname to a Restricted Directory (\u0027Path Traversal\u0027) vulnerability in gleam-lang gleam allows a malicious package publisher to delete a directory outside the project\u0027s build directory when a developer builds a project.\n\nA Hex package release\u0027s metadata carries an app field with the release\u0027s OTP application name. Gleam reads this field from the hex.pm release API when it downloads dependencies and uses it as the package\u0027s build directory name without validating it (hex_manifest_package in compiler-cli/src/dependencies.rs, ProjectPaths::build_directory_for_package). When a dependency fails to compile, Gleam deletes that directory with remove_dir_all. hex.pm didn\u0027t restrict the field to a directory name before 2026-10-12, so a publisher could set it to a value such as ../../../../target or an absolute path. When a project depends on such a release directly or transitively and the release fails to compile, gleam build, gleam check, gleam run, gleam test or gleam export deletes the directory the name resolves to. For a pure Gleam package no publisher code runs.\n\nThis issue affects gleam: from 0.32.4 before 1.19.2."
}
],
"impacts": [
{
"capecId": "CAPEC-126",
"descriptions": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003eA publisher of a package in a project\u0027s dependency tree can make a Gleam build delete a directory that the developer\u0027s account can write, outside the project\u0027s build directory or anywhere on the filesystem when the application name is an absolute path. For a pure Gleam package this happens without running any of the publisher\u0027s code. Developers and CI jobs that build projects with Gleam are affected; \u003ccode\u003egleam deps download\u003c/code\u003e alone isn\u0027t.\u003c/p\u003e"
},
{
"base64": false,
"type": "text/markdown",
"value": "A publisher of a package in a project\u0027s dependency tree can make a Gleam build delete a directory that the developer\u0027s account can write, outside the project\u0027s build directory or anywhere on the filesystem when the application name is an absolute path. For a pure Gleam package this happens without running any of the publisher\u0027s code. Developers and CI jobs that build projects with Gleam are affected; `gleam deps download` alone isn\u0027t."
}
],
"value": "A publisher of a package in a project\u0027s dependency tree can make a Gleam build delete a directory that the developer\u0027s account can write, outside the project\u0027s build directory or anywhere on the filesystem when the application name is an absolute path. For a pure Gleam package this happens without running any of the publisher\u0027s code. Developers and CI jobs that build projects with Gleam are affected; gleam deps download alone isn\u0027t."
}
]
}
],
"metrics": [
{
"cvssV4_0": {
"Automatable": "NOT_DEFINED",
"Recovery": "NOT_DEFINED",
"Safety": "NOT_DEFINED",
"attackComplexity": "LOW",
"attackRequirements": "PRESENT",
"attackVector": "NETWORK",
"baseScore": 5.9,
"baseSeverity": "MEDIUM",
"privilegesRequired": "NONE",
"providerUrgency": "NOT_DEFINED",
"subAvailabilityImpact": "NONE",
"subConfidentialityImpact": "NONE",
"subIntegrityImpact": "NONE",
"userInteraction": "ACTIVE",
"valueDensity": "NOT_DEFINED",
"vectorString": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:A/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N",
"version": "4.0",
"vulnAvailabilityImpact": "HIGH",
"vulnConfidentialityImpact": "NONE",
"vulnIntegrityImpact": "NONE",
"vulnerabilityResponseEffort": "NOT_DEFINED"
},
"format": "CVSS",
"scenarios": [
{
"lang": "en",
"value": "GENERAL"
}
]
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-22",
"description": "CWE-22 Improper Limitation of a Pathname to a Restricted Directory (\u0027Path Traversal\u0027)",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-10-12T18:23:41.507Z",
"orgId": "6b3ad84c-e1a6-4bf7-a703-f496b71e49db",
"shortName": "EEF"
},
"references": [
{
"name": "GitHub Advisory",
"tags": [
"related",
"vendor-advisory"
],
"url": "https://github.com/gleam-lang/gleam/security/advisories/GHSA-jhcr-c7qm-8589"
},
{
"name": "EEF CNA record for CVE-2026-103061",
"tags": [
"related"
],
"url": "https://cna.erlef.org/cves/CVE-2026-103061.html"
},
{
"name": "OSV record EEF-CVE-2026-103061",
"tags": [
"related"
],
"url": "https://osv.dev/vulnerability/EEF-CVE-2026-103061"
},
{
"name": "Introducing commit d13f27e in gleam-lang/gleam",
"tags": [
"related"
],
"url": "https://github.com/gleam-lang/gleam/commit/d13f27ee80aae7a521d2e9433c4deaf53f892574"
},
{
"name": "Fix commit d15c981 in gleam-lang/gleam",
"tags": [
"patch"
],
"url": "https://github.com/gleam-lang/gleam/commit/d15c981fac6e533d70ac8ee89a6ef4dbf139adc3"
},
{
"name": "Fix commit 54bbb2b in gleam-lang/gleam",
"tags": [
"patch"
],
"url": "https://github.com/gleam-lang/gleam/commit/54bbb2b98af1505b6eed93c45b1936fc76412e5c"
}
],
"solutions": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003eUpgrade Gleam to 1.19.2 or later. Gleam then rejects a hex.pm release whose OTP application name, or the application name it gives a dependency, isn\u0027t a lowercase letter followed by lowercase letters, digits and \u003ccode\u003e_\u003c/code\u003e.\u003c/p\u003e"
},
{
"base64": false,
"type": "text/markdown",
"value": "Upgrade Gleam to 1.19.2 or later. Gleam then rejects a hex.pm release whose OTP application name, or the application name it gives a dependency, isn\u0027t a lowercase letter followed by lowercase letters, digits and `_`."
}
],
"value": "Upgrade Gleam to 1.19.2 or later. Gleam then rejects a hex.pm release whose OTP application name, or the application name it gives a dependency, isn\u0027t a lowercase letter followed by lowercase letters, digits and _."
}
],
"source": {
"discovery": "UNKNOWN"
},
"title": "Path traversal in Gleam via unvalidated package application names",
"x_proofOfConcept": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003eNot reproduced end to end, because Gleam only uses hex.pm and has no setting for another repository. A unit test calling \u003ccode\u003eProjectPaths::build_directory_for_package\u003c/code\u003e with the application names \u003ccode\u003e../../../../canary\u003c/code\u003e and an absolute path computed build directories outside the project, and \u003ccode\u003estd::fs::remove_dir_all\u003c/code\u003e, the call behind \u003ccode\u003edelete_directory\u003c/code\u003e, deleted a canary directory placed there. The chain from \u003ccode\u003emeta.app\u003c/code\u003e to the delete was established by reading the source.\u003c/p\u003e"
},
{
"base64": false,
"type": "text/markdown",
"value": "Not reproduced end to end, because Gleam only uses hex.pm and has no setting for another repository. A unit test calling `ProjectPaths::build_directory_for_package` with the application names `../../../../canary` and an absolute path computed build directories outside the project, and `std::fs::remove_dir_all`, the call behind `delete_directory`, deleted a canary directory placed there. The chain from `meta.app` to the delete was established by reading the source."
}
],
"value": "Not reproduced end to end, because Gleam only uses hex.pm and has no setting for another repository. A unit test calling ProjectPaths::build_directory_for_package with the application names ../../../../canary and an absolute path computed build directories outside the project, and std::fs::remove_dir_all, the call behind delete_directory, deleted a canary directory placed there. The chain from meta.app to the delete was established by reading the source."
}
],
"x_technicalAnalysis": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003col\u003e\n\u003cli\u003e\u003ccode\u003ehex_manifest_package\u003c/code\u003e (\u003ccode\u003ecompiler-cli/src/dependencies.rs\u003c/code\u003e) sets the manifest package\u0027s \u003ccode\u003eotp_app\u003c/code\u003e to \u003ccode\u003emeta.app\u003c/code\u003e from \u003ccode\u003eGET packages/\u0026lt;name\u0026gt;/releases/\u0026lt;version\u0026gt;\u003c/code\u003e without validation. hex.pm doesn\u0027t restrict this field to a directory name. The signed registry record\u0027s dependency \u003ccode\u003eapp\u003c/code\u003e label is decoded but never used as a path.\u003c/li\u003e\n\u003cli\u003e\u003ccode\u003eManifestPackage::application_name\u003c/code\u003e (\u003ccode\u003ecompiler-core/src/manifest.rs\u003c/code\u003e) returns \u003ccode\u003eotp_app\u003c/code\u003e when it is set.\u003c/li\u003e\n\u003cli\u003e\u003ccode\u003eProjectPaths::build_directory_for_package\u003c/code\u003e (\u003ccode\u003ecompiler-core/src/paths.rs\u003c/code\u003e) joins the application name onto the target\u0027s build directory. A \u003ccode\u003e..\u003c/code\u003e component escapes the build directory, and an absolute path replaces the whole path.\u003c/li\u003e\n\u003cli\u003eWhen a dependency fails to compile, \u003ccode\u003eProjectCompiler::load_cache_or_compile_package\u003c/code\u003e (\u003ccode\u003ecompiler-core/src/build/project_compiler.rs\u003c/code\u003e) calls \u003ccode\u003edelete_directory\u003c/code\u003e on that path, which runs \u003ccode\u003estd::fs::remove_dir_all\u003c/code\u003e (\u003ccode\u003ecompiler-cli/src/fs.rs\u003c/code\u003e).\u003c/li\u003e\n\u003cli\u003eThe manifest built by \u003ccode\u003edownload_dependencies\u003c/code\u003e is passed to \u003ccode\u003ebuild::main\u003c/code\u003e in the same run, so the name reaches compilation without a \u003ccode\u003emanifest.toml\u003c/code\u003e round trip. \u003ccode\u003eotp_app\u003c/code\u003e is validated against \u003ccode\u003e^[a-z][a-z0-9_]*$\u003c/code\u003e only when \u003ccode\u003emanifest.toml\u003c/code\u003e is read from disk (commit 2dc0467, first released in v1.16.0), which rejects a stored malicious manifest on a later run but not the first run that produces it.\u003c/li\u003e\n\u003cli\u003eExtraction uses the package name, which hex.pm validates, so the effect is a directory delete without an overwrite. For a package with \u003ccode\u003ebuild_tools = [\"gleam\"]\u003c/code\u003e no publisher code runs, so source that fails to compile or a malformed \u003ccode\u003egleam.toml\u003c/code\u003e triggers the delete. For rebar3 and Mix dependencies, publisher code runs anyway.\u003c/li\u003e\n\u003c/ol\u003e"
},
{
"base64": false,
"type": "text/markdown",
"value": "1. `hex_manifest_package` (`compiler-cli/src/dependencies.rs`) sets the manifest package\u0027s `otp_app` to `meta.app` from `GET packages/\u003cname\u003e/releases/\u003cversion\u003e` without validation. hex.pm doesn\u0027t restrict this field to a directory name. The signed registry record\u0027s dependency `app` label is decoded but never used as a path.\n2. `ManifestPackage::application_name` (`compiler-core/src/manifest.rs`) returns `otp_app` when it is set.\n3. `ProjectPaths::build_directory_for_package` (`compiler-core/src/paths.rs`) joins the application name onto the target\u0027s build directory. A `..` component escapes the build directory, and an absolute path replaces the whole path.\n4. When a dependency fails to compile, `ProjectCompiler::load_cache_or_compile_package` (`compiler-core/src/build/project_compiler.rs`) calls `delete_directory` on that path, which runs `std::fs::remove_dir_all` (`compiler-cli/src/fs.rs`).\n5. The manifest built by `download_dependencies` is passed to `build::main` in the same run, so the name reaches compilation without a `manifest.toml` round trip. `otp_app` is validated against `^[a-z][a-z0-9_]*$` only when `manifest.toml` is read from disk (commit 2dc0467, first released in v1.16.0), which rejects a stored malicious manifest on a later run but not the first run that produces it.\n6. Extraction uses the package name, which hex.pm validates, so the effect is a directory delete without an overwrite. For a package with `build_tools = [\"gleam\"]` no publisher code runs, so source that fails to compile or a malformed `gleam.toml` triggers the delete. For rebar3 and Mix dependencies, publisher code runs anyway."
}
],
"value": "* hex_manifest_package (compiler-cli/src/dependencies.rs) sets the manifest package\u0027s otp_app to meta.app from GET packages/\u003cname\u003e/releases/\u003cversion\u003e without validation. hex.pm doesn\u0027t restrict this field to a directory name. The signed registry record\u0027s dependency app label is decoded but never used as a path.\n* ManifestPackage::application_name (compiler-core/src/manifest.rs) returns otp_app when it is set.\n* ProjectPaths::build_directory_for_package (compiler-core/src/paths.rs) joins the application name onto the target\u0027s build directory. A .. component escapes the build directory, and an absolute path replaces the whole path.\n* When a dependency fails to compile, ProjectCompiler::load_cache_or_compile_package (compiler-core/src/build/project_compiler.rs) calls delete_directory on that path, which runs std::fs::remove_dir_all (compiler-cli/src/fs.rs).\n* The manifest built by download_dependencies is passed to build::main in the same run, so the name reaches compilation without a manifest.toml round trip. otp_app is validated against ^[a-z][a-z0-9_]*$ only when manifest.toml is read from disk (commit 2dc0467, first released in v1.16.0), which rejects a stored malicious manifest on a later run but not the first run that produces it.\n* Extraction uses the package name, which hex.pm validates, so the effect is a directory delete without an overwrite. For a package with build_tools = [\"gleam\"] no publisher code runs, so source that fails to compile or a malformed gleam.toml triggers the delete. For rebar3 and Mix dependencies, publisher code runs anyway."
}
]
}
},
"cveMetadata": {
"assignerOrgId": "6b3ad84c-e1a6-4bf7-a703-f496b71e49db",
"assignerShortName": "EEF",
"cveId": "CVE-2026-103061",
"datePublished": "2026-10-12T18:23:41.507Z",
"dateReserved": "2026-10-07T13:15:01.364Z",
"dateUpdated": "2026-10-12T18:23:41.507Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
CVE-2026-105274 (GCVE-0-2026-105274)
Vulnerability from cvelistv5 – Published: 2026-10-12 16:43 – Updated: 2026-10-12 18:16
VLAI
EPSS
VEX
Title
hex_core decompresses registry and Erlang term API responses without size limits
Summary
Improper Handling of Highly Compressed Data (Data Amplification) vulnerability in hexpm hex_core allows an untrusted repository mirror, or a server answering hex_core's API requests, to exhaust the memory of the Erlang VM running hex_core. The same code is vendored in Hex (mix_hex_repo, mix_hex_api) and rebar3 (r3_hex_repo, r3_hex_api).
hex_repo:get_names/1, hex_repo:get_versions/1, hex_repo:get_package/2 and hex_repo:get_policy/2 decompress the registry response with zlib:gunzip/1 and decode the signed envelope before verifying its signature. A mirror doesn't have the repository's private key, but it chooses the compressed bytes, so a small response decompresses into an envelope of any size before the signature check rejects it.
hex_api decodes responses with the application/vnd.hex+erlang content type through hex_safe_binary_to_term:safe_binary_to_term/1, which calls binary_to_term(Binary, [safe]). The safe option prevents atom creation, but it accepts compressed terms and doesn't limit the size of the decoded term, and the check that rejects functions and ports runs after the term has been built. The fix for CVE-2026-21619 added the safe option and that check without bounding the decoded size.
This issue affects rebar3: from 3.9.1 before 3.27.3; hex: from 2.1.0 before 2.5.2; hex_core: from 0.1.0 before 0.20.0.
Severity
CWE
- CWE-409 - Improper Handling of Highly Compressed Data (Data Amplification)
Assigner
References
9 references
Impacted products
6 products
| Vendor | Product | Version | |
|---|---|---|---|
| erlang | rebar3 |
Affected:
3.9.1 , < 3.27.3
(semver)
cpe:2.3:a:erlang:rebar3:*:*:*:*:*:*:*:* |
|
| erlang | rebar3 |
Affected:
209c02ec57c2cc3207ee0174c3af3675b8dc8f79 , < 360838a22f5b3a88c0358207f2923059bcbb3afb
(git)
cpe:2.3:a:erlang:rebar3:*:*:*:*:*:*:*:* |
|
| hexpm | hex_core |
Affected:
0.1.0 , < 0.20.0
(semver)
cpe:2.3:a:hexpm:hex_core:*:*:*:*:*:*:*:* |
|
| hexpm | hex_core |
Affected:
fbb6d9de472e5edb8d6fb6b32a91cb266137892e , < ebe25d110717f6a3addba5232cd4a7dc1c76b628
(git)
cpe:2.3:a:hexpm:hex_core:*:*:*:*:*:*:*:* |
|
| hexpm | hex |
Affected:
2.1.0 , < 2.5.2
(semver)
cpe:2.3:a:hexpm:hex:*:*:*:*:*:*:*:* |
|
| hexpm | hex |
Affected:
671f695ac548ed01f5828c2a739ecaa942b21007 , < d8b60eee97abb119d525306f048969a217d793a5
(git)
cpe:2.3:a:hexpm:hex:*:*:*:*:*:*:*:* |
Date Public
2026-10-12 16:43
{
"containers": {
"cna": {
"affected": [
{
"cpes": [
"cpe:2.3:a:erlang:rebar3:*:*:*:*:*:*:*:*"
],
"defaultStatus": "unaffected",
"modules": [
"r3_hex_repo",
"r3_hex_api"
],
"packageName": "rebar3",
"packageURL": "pkg:otp/rebar3?repository_url=https:%2F%2Fgithub.com%2Ferlang%2Frebar3\u0026vcs_url=repository_url=git%2Bhttps:%2F%2Fgithub.com%2Ferlang%2Frebar3.git",
"product": "rebar3",
"programFiles": [
"apps/rebar/src/vendored/r3_hex_repo.erl",
"apps/rebar/src/vendored/r3_hex_api.erl"
],
"programRoutines": [
{
"name": "r3_hex_repo:get_names/1"
},
{
"name": "r3_hex_repo:get_versions/1"
},
{
"name": "r3_hex_repo:get_package/2"
},
{
"name": "r3_hex_api:request/4"
}
],
"repo": "https://github.com/erlang/rebar3",
"vendor": "erlang",
"versions": [
{
"lessThan": "3.27.3",
"status": "affected",
"version": "3.9.1",
"versionType": "semver"
}
]
},
{
"collectionURL": "https://github.com",
"cpes": [
"cpe:2.3:a:erlang:rebar3:*:*:*:*:*:*:*:*"
],
"defaultStatus": "unaffected",
"modules": [
"r3_hex_repo",
"r3_hex_api"
],
"packageName": "erlang/rebar3",
"packageURL": "pkg:github/erlang/rebar3",
"product": "rebar3",
"programFiles": [
"apps/rebar/src/vendored/r3_hex_repo.erl",
"apps/rebar/src/vendored/r3_hex_api.erl"
],
"programRoutines": [
{
"name": "r3_hex_repo:get_names/1"
},
{
"name": "r3_hex_repo:get_versions/1"
},
{
"name": "r3_hex_repo:get_package/2"
},
{
"name": "r3_hex_api:request/4"
}
],
"repo": "https://github.com/erlang/rebar3",
"vendor": "erlang",
"versions": [
{
"lessThan": "360838a22f5b3a88c0358207f2923059bcbb3afb",
"status": "affected",
"version": "209c02ec57c2cc3207ee0174c3af3675b8dc8f79",
"versionType": "git"
}
]
},
{
"collectionURL": "https://repo.hex.pm",
"cpes": [
"cpe:2.3:a:hexpm:hex_core:*:*:*:*:*:*:*:*"
],
"defaultStatus": "unaffected",
"modules": [
"hex_repo",
"hex_api",
"hex_safe_binary_to_term"
],
"packageName": "hex_core",
"packageURL": "pkg:hex/hex_core",
"product": "hex_core",
"programFiles": [
"src/hex_repo.erl",
"src/hex_api.erl",
"src/hex_safe_binary_to_term.erl"
],
"programRoutines": [
{
"name": "hex_repo:get_names/1"
},
{
"name": "hex_repo:get_versions/1"
},
{
"name": "hex_repo:get_package/2"
},
{
"name": "hex_repo:get_policy/2"
},
{
"name": "hex_api:request/4"
},
{
"name": "hex_safe_binary_to_term:safe_binary_to_term/1"
}
],
"repo": "https://github.com/hexpm/hex_core",
"vendor": "hexpm",
"versions": [
{
"lessThan": "0.20.0",
"status": "affected",
"version": "0.1.0",
"versionType": "semver"
}
]
},
{
"collectionURL": "https://github.com",
"cpes": [
"cpe:2.3:a:hexpm:hex_core:*:*:*:*:*:*:*:*"
],
"defaultStatus": "unaffected",
"modules": [
"hex_repo",
"hex_api",
"hex_safe_binary_to_term"
],
"packageName": "hexpm/hex_core",
"packageURL": "pkg:github/hexpm/hex_core",
"product": "hex_core",
"programFiles": [
"src/hex_repo.erl",
"src/hex_api.erl",
"src/hex_safe_binary_to_term.erl"
],
"programRoutines": [
{
"name": "hex_repo:get_names/1"
},
{
"name": "hex_repo:get_versions/1"
},
{
"name": "hex_repo:get_package/2"
},
{
"name": "hex_repo:get_policy/2"
},
{
"name": "hex_api:request/4"
},
{
"name": "hex_safe_binary_to_term:safe_binary_to_term/1"
}
],
"repo": "https://github.com/hexpm/hex_core",
"vendor": "hexpm",
"versions": [
{
"lessThan": "ebe25d110717f6a3addba5232cd4a7dc1c76b628",
"status": "affected",
"version": "fbb6d9de472e5edb8d6fb6b32a91cb266137892e",
"versionType": "git"
}
]
},
{
"cpes": [
"cpe:2.3:a:hexpm:hex:*:*:*:*:*:*:*:*"
],
"defaultStatus": "unaffected",
"modules": [
"mix_hex_repo",
"mix_hex_api"
],
"packageName": "hex",
"packageURL": "pkg:otp/hex?repository_url=https:%2F%2Fgithub.com%2Fhexpm%2Fhex\u0026vcs_url=repository_url=git%2Bhttps:%2F%2Fgithub.com%2Fhexpm%2Fhex.git",
"product": "hex",
"programFiles": [
"src/mix_hex_repo.erl",
"src/mix_hex_api.erl"
],
"programRoutines": [
{
"name": "mix_hex_repo:get_names/1"
},
{
"name": "mix_hex_repo:get_versions/1"
},
{
"name": "mix_hex_repo:get_package/2"
},
{
"name": "mix_hex_repo:get_policy/2"
},
{
"name": "mix_hex_api:request/4"
}
],
"repo": "https://github.com/hexpm/hex",
"vendor": "hexpm",
"versions": [
{
"lessThan": "2.5.2",
"status": "affected",
"version": "2.1.0",
"versionType": "semver"
}
]
},
{
"collectionURL": "https://github.com",
"cpes": [
"cpe:2.3:a:hexpm:hex:*:*:*:*:*:*:*:*"
],
"defaultStatus": "unaffected",
"modules": [
"mix_hex_repo",
"mix_hex_api"
],
"packageName": "hexpm/hex",
"packageURL": "pkg:github/hexpm/hex",
"product": "hex",
"programFiles": [
"src/mix_hex_repo.erl",
"src/mix_hex_api.erl"
],
"programRoutines": [
{
"name": "mix_hex_repo:get_names/1"
},
{
"name": "mix_hex_repo:get_versions/1"
},
{
"name": "mix_hex_repo:get_package/2"
},
{
"name": "mix_hex_repo:get_policy/2"
},
{
"name": "mix_hex_api:request/4"
}
],
"repo": "https://github.com/hexpm/hex",
"vendor": "hexpm",
"versions": [
{
"lessThan": "d8b60eee97abb119d525306f048969a217d793a5",
"status": "affected",
"version": "671f695ac548ed01f5828c2a739ecaa942b21007",
"versionType": "git"
}
]
}
],
"configurations": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003eRegistry decoding is affected when a repository\u0027s URL points at a mirror or another server the user doesn\u0027t trust with the availability of their builds, for example Hex\u0027s \u003ccode\u003eHEX_MIRROR_URL\u003c/code\u003e or \u003ccode\u003emirror_url\u003c/code\u003e and rebar3\u0027s \u003ccode\u003eHEX_MIRROR_URL\u003c/code\u003e. API decoding is affected when the API URL points at such a server or an attacker can alter API responses. Requests to repo.hex.pm and hex.pm over verified HTTPS aren\u0027t affected.\u003c/p\u003e"
},
{
"base64": false,
"type": "text/markdown",
"value": "Registry decoding is affected when a repository\u0027s URL points at a mirror or another server the user doesn\u0027t trust with the availability of their builds, for example Hex\u0027s `HEX_MIRROR_URL` or `mirror_url` and rebar3\u0027s `HEX_MIRROR_URL`. API decoding is affected when the API URL points at such a server or an attacker can alter API responses. Requests to repo.hex.pm and hex.pm over verified HTTPS aren\u0027t affected."
}
],
"value": "Registry decoding is affected when a repository\u0027s URL points at a mirror or another server the user doesn\u0027t trust with the availability of their builds, for example Hex\u0027s HEX_MIRROR_URL or mirror_url and rebar3\u0027s HEX_MIRROR_URL. API decoding is affected when the API URL points at such a server or an attacker can alter API responses. Requests to repo.hex.pm and hex.pm over verified HTTPS aren\u0027t affected."
}
],
"cpeApplicability": [
{
"nodes": [
{
"cpeMatch": [
{
"criteria": "cpe:2.3:a:erlang:rebar3:*:*:*:*:*:*:*:*",
"versionEndExcluding": "3.27.3",
"versionStartIncluding": "3.9.1",
"vulnerable": true
},
{
"criteria": "cpe:2.3:a:hexpm:hex_core:*:*:*:*:*:*:*:*",
"versionEndExcluding": "0.20.0",
"versionStartIncluding": "0.1.0",
"vulnerable": true
},
{
"criteria": "cpe:2.3:a:hexpm:hex:*:*:*:*:*:*:*:*",
"versionEndExcluding": "2.5.2",
"versionStartIncluding": "2.1.0",
"vulnerable": true
}
],
"negate": false,
"operator": "OR"
}
],
"operator": "AND"
}
],
"credits": [
{
"lang": "en",
"type": "finder",
"value": "Peter Ullrich"
},
{
"lang": "en",
"type": "remediation developer",
"value": "Eric Meadows-J\u00f6nsson"
},
{
"lang": "en",
"type": "analyst",
"value": "Jonatan M\u00e4nnchen / EEF"
}
],
"dateAssigned": "2026-10-10T13:01:00.000Z",
"datePublic": "2026-10-12T16:43:59.000Z",
"descriptions": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003eImproper Handling of Highly Compressed Data (Data Amplification) vulnerability in hexpm hex_core allows an untrusted repository mirror, or a server answering hex_core\u0027s API requests, to exhaust the memory of the Erlang VM running hex_core. The same code is vendored in Hex (\u003ccode\u003emix_hex_repo\u003c/code\u003e, \u003ccode\u003emix_hex_api\u003c/code\u003e) and rebar3 (\u003ccode\u003er3_hex_repo\u003c/code\u003e, \u003ccode\u003er3_hex_api\u003c/code\u003e).\u003c/p\u003e\n\u003cp\u003e\u003ccode\u003ehex_repo:get_names/1\u003c/code\u003e, \u003ccode\u003ehex_repo:get_versions/1\u003c/code\u003e, \u003ccode\u003ehex_repo:get_package/2\u003c/code\u003e and \u003ccode\u003ehex_repo:get_policy/2\u003c/code\u003e decompress the registry response with \u003ccode\u003ezlib:gunzip/1\u003c/code\u003e and decode the signed envelope before verifying its signature. A mirror doesn\u0027t have the repository\u0027s private key, but it chooses the compressed bytes, so a small response decompresses into an envelope of any size before the signature check rejects it.\u003c/p\u003e\n\u003cp\u003e\u003ccode\u003ehex_api\u003c/code\u003e decodes responses with the \u003ccode\u003eapplication/vnd.hex+erlang\u003c/code\u003e content type through \u003ccode\u003ehex_safe_binary_to_term:safe_binary_to_term/1\u003c/code\u003e, which calls \u003ccode\u003ebinary_to_term(Binary, [safe])\u003c/code\u003e. The \u003ccode\u003esafe\u003c/code\u003e option prevents atom creation, but it accepts compressed terms and doesn\u0027t limit the size of the decoded term, and the check that rejects functions and ports runs after the term has been built. The fix for CVE-2026-21619 added the \u003ccode\u003esafe\u003c/code\u003e option and that check without bounding the decoded size.\u003c/p\u003e\n\u003cp\u003eThis issue affects rebar3: from 3.9.1 before 3.27.3; hex: from 2.1.0 before 2.5.2; hex_core: from 0.1.0 before 0.20.0.\u003c/p\u003e"
},
{
"base64": false,
"type": "text/markdown",
"value": "Improper Handling of Highly Compressed Data (Data Amplification) vulnerability in hexpm hex_core allows an untrusted repository mirror, or a server answering hex_core\u0027s API requests, to exhaust the memory of the Erlang VM running hex_core. The same code is vendored in Hex (`mix_hex_repo`, `mix_hex_api`) and rebar3 (`r3_hex_repo`, `r3_hex_api`).\n\n`hex_repo:get_names/1`, `hex_repo:get_versions/1`, `hex_repo:get_package/2` and `hex_repo:get_policy/2` decompress the registry response with `zlib:gunzip/1` and decode the signed envelope before verifying its signature. A mirror doesn\u0027t have the repository\u0027s private key, but it chooses the compressed bytes, so a small response decompresses into an envelope of any size before the signature check rejects it.\n\n`hex_api` decodes responses with the `application/vnd.hex+erlang` content type through `hex_safe_binary_to_term:safe_binary_to_term/1`, which calls `binary_to_term(Binary, [safe])`. The `safe` option prevents atom creation, but it accepts compressed terms and doesn\u0027t limit the size of the decoded term, and the check that rejects functions and ports runs after the term has been built. The fix for CVE-2026-21619 added the `safe` option and that check without bounding the decoded size.\n\nThis issue affects rebar3: from 3.9.1 before 3.27.3; hex: from 2.1.0 before 2.5.2; hex_core: from 0.1.0 before 0.20.0."
}
],
"value": "Improper Handling of Highly Compressed Data (Data Amplification) vulnerability in hexpm hex_core allows an untrusted repository mirror, or a server answering hex_core\u0027s API requests, to exhaust the memory of the Erlang VM running hex_core. The same code is vendored in Hex (mix_hex_repo, mix_hex_api) and rebar3 (r3_hex_repo, r3_hex_api).\n\nhex_repo:get_names/1, hex_repo:get_versions/1, hex_repo:get_package/2 and hex_repo:get_policy/2 decompress the registry response with zlib:gunzip/1 and decode the signed envelope before verifying its signature. A mirror doesn\u0027t have the repository\u0027s private key, but it chooses the compressed bytes, so a small response decompresses into an envelope of any size before the signature check rejects it.\n\nhex_api decodes responses with the application/vnd.hex+erlang content type through hex_safe_binary_to_term:safe_binary_to_term/1, which calls binary_to_term(Binary, [safe]). The safe option prevents atom creation, but it accepts compressed terms and doesn\u0027t limit the size of the decoded term, and the check that rejects functions and ports runs after the term has been built. The fix for CVE-2026-21619 added the safe option and that check without bounding the decoded size.\n\nThis issue affects rebar3: from 3.9.1 before 3.27.3; hex: from 2.1.0 before 2.5.2; hex_core: from 0.1.0 before 0.20.0."
}
],
"impacts": [
{
"capecId": "CAPEC-130",
"descriptions": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003eA mirror can make every registry fetch allocate memory far beyond the size of its response: in a test against Hex main 851b938, which vendors this code, a 65 KB registry response decompressed into a 64 MiB envelope before the signature check failed. The API server, or an attacker who can alter its responses, can do the same with API responses: 8 KB of compressed Erlang term format decoded into a list of 4.2 million elements. Large enough responses stop the Erlang VM, which fails the build tool command or the program using hex_core. No package code has to run.\u003c/p\u003e"
},
{
"base64": false,
"type": "text/markdown",
"value": "A mirror can make every registry fetch allocate memory far beyond the size of its response: in a test against Hex main 851b938, which vendors this code, a 65 KB registry response decompressed into a 64 MiB envelope before the signature check failed. The API server, or an attacker who can alter its responses, can do the same with API responses: 8 KB of compressed Erlang term format decoded into a list of 4.2 million elements. Large enough responses stop the Erlang VM, which fails the build tool command or the program using hex_core. No package code has to run."
}
],
"value": "A mirror can make every registry fetch allocate memory far beyond the size of its response: in a test against Hex main 851b938, which vendors this code, a 65 KB registry response decompressed into a 64 MiB envelope before the signature check failed. The API server, or an attacker who can alter its responses, can do the same with API responses: 8 KB of compressed Erlang term format decoded into a list of 4.2 million elements. Large enough responses stop the Erlang VM, which fails the build tool command or the program using hex_core. No package code has to run."
}
]
}
],
"metrics": [
{
"cvssV4_0": {
"Automatable": "NOT_DEFINED",
"Recovery": "NOT_DEFINED",
"Safety": "NOT_DEFINED",
"attackComplexity": "LOW",
"attackRequirements": "PRESENT",
"attackVector": "NETWORK",
"baseScore": 2.1,
"baseSeverity": "LOW",
"privilegesRequired": "NONE",
"providerUrgency": "NOT_DEFINED",
"subAvailabilityImpact": "NONE",
"subConfidentialityImpact": "NONE",
"subIntegrityImpact": "NONE",
"userInteraction": "ACTIVE",
"valueDensity": "NOT_DEFINED",
"vectorString": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:A/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N",
"version": "4.0",
"vulnAvailabilityImpact": "LOW",
"vulnConfidentialityImpact": "NONE",
"vulnIntegrityImpact": "NONE",
"vulnerabilityResponseEffort": "NOT_DEFINED"
},
"format": "CVSS",
"scenarios": [
{
"lang": "en",
"value": "GENERAL"
}
]
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-409",
"description": "CWE-409 Improper Handling of Highly Compressed Data (Data Amplification)",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-10-12T18:16:57.155Z",
"orgId": "6b3ad84c-e1a6-4bf7-a703-f496b71e49db",
"shortName": "EEF"
},
"references": [
{
"name": "GitHub Advisory",
"tags": [
"related",
"vendor-advisory"
],
"url": "https://github.com/hexpm/hex_core/security/advisories/GHSA-7c4r-cgf9-9jmq"
},
{
"name": "EEF CNA record for CVE-2026-105274",
"tags": [
"related"
],
"url": "https://cna.erlef.org/cves/CVE-2026-105274.html"
},
{
"name": "OSV record EEF-CVE-2026-105274",
"tags": [
"related"
],
"url": "https://osv.dev/vulnerability/EEF-CVE-2026-105274"
},
{
"name": "Introducing commit 209c02e in erlang/rebar3",
"tags": [
"related"
],
"url": "https://github.com/erlang/rebar3/commit/209c02ec57c2cc3207ee0174c3af3675b8dc8f79"
},
{
"name": "Fix commit 360838a in erlang/rebar3",
"tags": [
"patch"
],
"url": "https://github.com/erlang/rebar3/commit/360838a22f5b3a88c0358207f2923059bcbb3afb"
},
{
"name": "Introducing commit fbb6d9d in hexpm/hex_core",
"tags": [
"related"
],
"url": "https://github.com/hexpm/hex_core/commit/fbb6d9de472e5edb8d6fb6b32a91cb266137892e"
},
{
"name": "Fix commit ebe25d1 in hexpm/hex_core",
"tags": [
"patch"
],
"url": "https://github.com/hexpm/hex_core/commit/ebe25d110717f6a3addba5232cd4a7dc1c76b628"
},
{
"name": "Introducing commit 671f695 in hexpm/hex",
"tags": [
"related"
],
"url": "https://github.com/hexpm/hex/commit/671f695ac548ed01f5828c2a739ecaa942b21007"
},
{
"name": "Fix commit d8b60ee in hexpm/hex",
"tags": [
"patch"
],
"url": "https://github.com/hexpm/hex/commit/d8b60eee97abb119d525306f048969a217d793a5"
}
],
"solutions": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003eUpgrade hex_core to 0.20.0 or later. Registry resources larger than 16 MiB after decompression are rejected with \u003ccode\u003e{too_big_uncompressed, MaxSize}\u003c/code\u003e, configurable with \u003ccode\u003eregistry_max_uncompressed_size\u003c/code\u003e.\u003c/p\u003e\n\u003cp\u003eUpgrade Hex to 2.5.2 or later, which vendors hex_core 0.20.0. No rebar3 release vendors hex_core 0.20.0 yet.\u003c/p\u003e"
},
{
"base64": false,
"type": "text/markdown",
"value": "Upgrade hex_core to 0.20.0 or later. Registry resources larger than 16 MiB after decompression are rejected with `{too_big_uncompressed, MaxSize}`, configurable with `registry_max_uncompressed_size`.\n\nUpgrade Hex to 2.5.2 or later, which vendors hex_core 0.20.0. No rebar3 release vendors hex_core 0.20.0 yet."
}
],
"value": "Upgrade hex_core to 0.20.0 or later. Registry resources larger than 16 MiB after decompression are rejected with {too_big_uncompressed, MaxSize}, configurable with registry_max_uncompressed_size.\n\nUpgrade Hex to 2.5.2 or later, which vendors hex_core 0.20.0. No rebar3 release vendors hex_core 0.20.0 yet."
}
],
"source": {
"discovery": "UNKNOWN"
},
"title": "hex_core decompresses registry and Erlang term API responses without size limits",
"workarounds": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003ePoint repository URLs at repo.hex.pm or a mirror you operate, and the API URL at hex.pm.\u003c/p\u003e"
},
{
"base64": false,
"type": "text/markdown",
"value": "Point repository URLs at repo.hex.pm or a mirror you operate, and the API URL at hex.pm."
}
],
"value": "Point repository URLs at repo.hex.pm or a mirror you operate, and the API URL at hex.pm."
}
],
"x_proofOfConcept": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003col\u003e\n\u003cli\u003ePoint a repository at a loopback mirror (in Hex, \u003ccode\u003eHEX_MIRROR_URL\u003c/code\u003e) that answers \u003ccode\u003e/packages/probe\u003c/code\u003e with a 65,268-byte gzip stream decompressing to a 67,108,872-byte signed envelope with a 64 MiB payload and a one-byte signature.\u003c/li\u003e\n\u003cli\u003e\u003ccode\u003eHex.Repo.get_package(\"hexpm\", \"probe\", nil)\u003c/code\u003e, which calls the vendored \u003ccode\u003ehex_repo:get_package/2\u003c/code\u003e, returns \u003ccode\u003e{:error, :bad_signature}\u003c/code\u003e after allocating the envelope. Peak RSS was 234 MiB, against 96 MiB for a 1,030-byte invalid envelope.\u003c/li\u003e\n\u003cli\u003eAnswer an API request with \u003ccode\u003econtent-type: application/vnd.hex+erlang\u003c/code\u003e and 8,178 bytes of compressed Erlang term format encoding a list of 4,194,304 elements. \u003ccode\u003emix_hex_api:get/2\u003c/code\u003e accepts the decoded term, and BEAM memory rises from 58 MiB to 272 MiB.\u003c/li\u003e\n\u003c/ol\u003e"
},
{
"base64": false,
"type": "text/markdown",
"value": "1. Point a repository at a loopback mirror (in Hex, `HEX_MIRROR_URL`) that answers `/packages/probe` with a 65,268-byte gzip stream decompressing to a 67,108,872-byte signed envelope with a 64 MiB payload and a one-byte signature.\n2. `Hex.Repo.get_package(\"hexpm\", \"probe\", nil)`, which calls the vendored `hex_repo:get_package/2`, returns `{:error, :bad_signature}` after allocating the envelope. Peak RSS was 234 MiB, against 96 MiB for a 1,030-byte invalid envelope.\n3. Answer an API request with `content-type: application/vnd.hex+erlang` and 8,178 bytes of compressed Erlang term format encoding a list of 4,194,304 elements. `mix_hex_api:get/2` accepts the decoded term, and BEAM memory rises from 58 MiB to 272 MiB."
}
],
"value": "* Point a repository at a loopback mirror (in Hex, HEX_MIRROR_URL) that answers /packages/probe with a 65,268-byte gzip stream decompressing to a 67,108,872-byte signed envelope with a 64 MiB payload and a one-byte signature.\n* Hex.Repo.get_package(\"hexpm\", \"probe\", nil), which calls the vendored hex_repo:get_package/2, returns {:error, :bad_signature} after allocating the envelope. Peak RSS was 234 MiB, against 96 MiB for a 1,030-byte invalid envelope.\n* Answer an API request with content-type: application/vnd.hex+erlang and 8,178 bytes of compressed Erlang term format encoding a list of 4,194,304 elements. mix_hex_api:get/2 accepts the decoded term, and BEAM memory rises from 58 MiB to 272 MiB."
}
],
"x_technicalAnalysis": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003col\u003e\n\u003cli\u003e\u003ccode\u003ehex_repo:get_protobuf/3\u003c/code\u003e, used by \u003ccode\u003eget_names/1\u003c/code\u003e, \u003ccode\u003eget_versions/1\u003c/code\u003e, \u003ccode\u003eget_package/2\u003c/code\u003e and \u003ccode\u003eget_policy/2\u003c/code\u003e, calls \u003ccode\u003ezlib:gunzip/1\u003c/code\u003e on the whole response body with no output limit.\u003c/li\u003e\n\u003cli\u003e\u003ccode\u003ehex_repo:decode/4\u003c/code\u003e then calls \u003ccode\u003ehex_registry:decode_and_verify_signed/2\u003c/code\u003e, which decodes the protobuf envelope, copying its payload and signature, before checking the signature.\u003c/li\u003e\n\u003cli\u003e\u003ccode\u003ehex_api:request/4\u003c/code\u003e passes every response whose content type contains \u003ccode\u003eapplication/vnd.hex+erlang\u003c/code\u003e to \u003ccode\u003ehex_safe_binary_to_term:safe_binary_to_term/1\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003e\u003ccode\u003esafe_binary_to_term/1\u003c/code\u003e calls \u003ccode\u003ebinary_to_term(Binary, [safe])\u003c/code\u003e, which decompresses compressed terms and builds the whole term, and only then walks it to reject functions and ports.\u003c/li\u003e\n\u003c/ol\u003e"
},
{
"base64": false,
"type": "text/markdown",
"value": "1. `hex_repo:get_protobuf/3`, used by `get_names/1`, `get_versions/1`, `get_package/2` and `get_policy/2`, calls `zlib:gunzip/1` on the whole response body with no output limit.\n2. `hex_repo:decode/4` then calls `hex_registry:decode_and_verify_signed/2`, which decodes the protobuf envelope, copying its payload and signature, before checking the signature.\n3. `hex_api:request/4` passes every response whose content type contains `application/vnd.hex+erlang` to `hex_safe_binary_to_term:safe_binary_to_term/1`.\n4. `safe_binary_to_term/1` calls `binary_to_term(Binary, [safe])`, which decompresses compressed terms and builds the whole term, and only then walks it to reject functions and ports."
}
],
"value": "* hex_repo:get_protobuf/3, used by get_names/1, get_versions/1, get_package/2 and get_policy/2, calls zlib:gunzip/1 on the whole response body with no output limit.\n* hex_repo:decode/4 then calls hex_registry:decode_and_verify_signed/2, which decodes the protobuf envelope, copying its payload and signature, before checking the signature.\n* hex_api:request/4 passes every response whose content type contains application/vnd.hex+erlang to hex_safe_binary_to_term:safe_binary_to_term/1.\n* safe_binary_to_term/1 calls binary_to_term(Binary, [safe]), which decompresses compressed terms and builds the whole term, and only then walks it to reject functions and ports."
}
]
}
},
"cveMetadata": {
"assignerOrgId": "6b3ad84c-e1a6-4bf7-a703-f496b71e49db",
"assignerShortName": "EEF",
"cveId": "CVE-2026-105274",
"datePublished": "2026-10-12T16:43:58.730Z",
"dateReserved": "2026-10-10T13:00:02.355Z",
"dateUpdated": "2026-10-12T18:16:57.155Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
CVE-2026-81856 (GCVE-0-2026-81856)
Vulnerability from cvelistv5 – Published: 2026-10-12 15:46 – Updated: 2026-10-12 15:46
VLAI
EPSS
VEX
Title
Terminal escape sequence injection in Hex via unneutralized server-supplied output
Summary
Improper Neutralization of Escape, Meta, or Control Sequences vulnerability in hexpm hex allows a malicious package publisher or a hostile repository server to inject terminal control sequences into the output of Mix tasks.
Hex prints strings supplied by the package repository and the documentation search service straight to the terminal through Hex.Shell.info/1 and Hex.Shell.error/1, neutralizing no control characters. Affected sinks span package metadata and configuration snippets in mix hex.info, search results in mix hex.package search and mix hex.search, owner and organization listings, publish and sponsor URLs, the authenticated username in mix hex.user, policy identities in mix hex.policy, and API error bodies rendered by Hex.Utils.print_error_result/1. A malicious package can embed ANSI escape sequences (cursor movement, line erase, carriage returns, OSC 52 clipboard writes) or Unicode bidirectional overrides in any of those fields, so the bytes reach the terminal unchanged, forging displayed URLs, package descriptions and suggested commands, concealing real output, or writing to the clipboard. No authentication or privileged position is required; only publishing a package.
This issue affects hex: from 0.0.1 before 2.5.2.
Severity
CWE
- CWE-150 - Improper Neutralization of Escape, Meta, or Control Sequences
Assigner
References
5 references
| URL | Tags |
|---|---|
| https://github.com/hexpm/hex/security/advisories/… | relatedvendor-advisory |
| https://cna.erlef.org/cves/CVE-2026-81856.html | related |
| https://osv.dev/vulnerability/EEF-CVE-2026-81856 | related |
| https://github.com/hexpm/hex/commit/211303e3f68f5… | related |
| https://github.com/hexpm/hex/commit/dd3305ddf0032… | patch |
Impacted products
{
"containers": {
"cna": {
"affected": [
{
"cpes": [
"cpe:2.3:a:hexpm:hex:*:*:*:*:*:*:*:*"
],
"defaultStatus": "unaffected",
"modules": [
"\u0027Elixir.Mix.Tasks.Hex.Search\u0027"
],
"packageName": "hex",
"packageURL": "pkg:otp/hex?repository_url=https:%2F%2Fgithub.com%2Fhexpm%2Fhex\u0026vcs_url=repository_url=git%2Bhttps:%2F%2Fgithub.com%2Fhexpm%2Fhex.git",
"product": "hex",
"programFiles": [
"lib/mix/tasks/hex.search.ex"
],
"programRoutines": [
{
"name": "\u0027Elixir.Mix.Tasks.Hex.Search\u0027:run/1"
}
],
"repo": "https://github.com/hexpm/hex",
"vendor": "hexpm",
"versions": [
{
"lessThan": "2.5.2",
"status": "affected",
"version": "0.0.1",
"versionType": "semver"
}
]
},
{
"collectionURL": "https://github.com",
"cpes": [
"cpe:2.3:a:hexpm:hex:*:*:*:*:*:*:*:*"
],
"defaultStatus": "unaffected",
"modules": [
"\u0027Elixir.Mix.Tasks.Hex.Search\u0027"
],
"packageName": "hexpm/hex",
"packageURL": "pkg:github/hexpm/hex",
"product": "hex",
"programFiles": [
"lib/mix/tasks/hex.search.ex"
],
"programRoutines": [
{
"name": "\u0027Elixir.Mix.Tasks.Hex.Search\u0027:run/1"
}
],
"repo": "https://github.com/hexpm/hex",
"vendor": "hexpm",
"versions": [
{
"lessThan": "dd3305ddf0032f6d0b468fd40dbbc3072bfcb8b8",
"status": "affected",
"version": "211303e3f68f5d3ce06450c1ff1a7a770a9ab236",
"versionType": "git"
}
]
}
],
"configurations": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003eReachable only when a developer runs an affected Mix task in a terminal emulator that interprets ANSI escape sequences, and the printed content originates from an attacker-published package or a hostile repository server.\u003c/p\u003e"
},
{
"base64": false,
"type": "text/markdown",
"value": "Reachable only when a developer runs an affected Mix task in a terminal emulator that interprets ANSI escape sequences, and the printed content originates from an attacker-published package or a hostile repository server."
}
],
"value": "Reachable only when a developer runs an affected Mix task in a terminal emulator that interprets ANSI escape sequences, and the printed content originates from an attacker-published package or a hostile repository server."
}
],
"cpeApplicability": [
{
"nodes": [
{
"cpeMatch": [
{
"criteria": "cpe:2.3:a:hexpm:hex:*:*:*:*:*:*:*:*",
"versionEndExcluding": "2.5.2",
"versionStartIncluding": "0.0.1",
"vulnerable": true
}
],
"negate": false,
"operator": "OR"
}
],
"operator": "AND"
}
],
"credits": [
{
"lang": "en",
"type": "reporter",
"value": "Zach Daniel"
},
{
"lang": "en",
"type": "remediation reviewer",
"value": "Eric Meadows-J\u00f6nsson"
},
{
"lang": "en",
"type": "remediation developer",
"value": "Jonatan M\u00e4nnchen"
},
{
"lang": "en",
"type": "coordinator",
"value": "Jonatan M\u00e4nnchen"
}
],
"dateAssigned": "2026-09-09T16:47:17.000Z",
"descriptions": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003eImproper Neutralization of Escape, Meta, or Control Sequences vulnerability in hexpm hex allows a malicious package publisher or a hostile repository server to inject terminal control sequences into the output of Mix tasks.\u003c/p\u003e\n\u003cp\u003eHex prints strings supplied by the package repository and the documentation search service straight to the terminal through \u003ccode\u003eHex.Shell.info/1\u003c/code\u003e and \u003ccode\u003eHex.Shell.error/1\u003c/code\u003e, neutralizing no control characters. Affected sinks span package metadata and configuration snippets in \u003ccode\u003emix hex.info\u003c/code\u003e, search results in \u003ccode\u003emix hex.package search\u003c/code\u003e and \u003ccode\u003emix hex.search\u003c/code\u003e, owner and organization listings, publish and sponsor URLs, the authenticated username in \u003ccode\u003emix hex.user\u003c/code\u003e, policy identities in \u003ccode\u003emix hex.policy\u003c/code\u003e, and API error bodies rendered by \u003ccode\u003eHex.Utils.print_error_result/1\u003c/code\u003e. A malicious package can embed ANSI escape sequences (cursor movement, line erase, carriage returns, OSC 52 clipboard writes) or Unicode bidirectional overrides in any of those fields, so the bytes reach the terminal unchanged, forging displayed URLs, package descriptions and suggested commands, concealing real output, or writing to the clipboard. No authentication or privileged position is required; only publishing a package.\u003c/p\u003e\n\u003cp\u003eThis issue affects hex: from 0.0.1 before 2.5.2.\u003c/p\u003e"
},
{
"base64": false,
"type": "text/markdown",
"value": "Improper Neutralization of Escape, Meta, or Control Sequences vulnerability in hexpm hex allows a malicious package publisher or a hostile repository server to inject terminal control sequences into the output of Mix tasks.\n\nHex prints strings supplied by the package repository and the documentation search service straight to the terminal through `Hex.Shell.info/1` and `Hex.Shell.error/1`, neutralizing no control characters. Affected sinks span package metadata and configuration snippets in `mix hex.info`, search results in `mix hex.package search` and `mix hex.search`, owner and organization listings, publish and sponsor URLs, the authenticated username in `mix hex.user`, policy identities in `mix hex.policy`, and API error bodies rendered by `Hex.Utils.print_error_result/1`. A malicious package can embed ANSI escape sequences (cursor movement, line erase, carriage returns, OSC 52 clipboard writes) or Unicode bidirectional overrides in any of those fields, so the bytes reach the terminal unchanged, forging displayed URLs, package descriptions and suggested commands, concealing real output, or writing to the clipboard. No authentication or privileged position is required; only publishing a package.\n\nThis issue affects hex: from 0.0.1 before 2.5.2."
}
],
"value": "Improper Neutralization of Escape, Meta, or Control Sequences vulnerability in hexpm hex allows a malicious package publisher or a hostile repository server to inject terminal control sequences into the output of Mix tasks.\n\nHex prints strings supplied by the package repository and the documentation search service straight to the terminal through Hex.Shell.info/1 and Hex.Shell.error/1, neutralizing no control characters. Affected sinks span package metadata and configuration snippets in mix hex.info, search results in mix hex.package search and mix hex.search, owner and organization listings, publish and sponsor URLs, the authenticated username in mix hex.user, policy identities in mix hex.policy, and API error bodies rendered by Hex.Utils.print_error_result/1. A malicious package can embed ANSI escape sequences (cursor movement, line erase, carriage returns, OSC 52 clipboard writes) or Unicode bidirectional overrides in any of those fields, so the bytes reach the terminal unchanged, forging displayed URLs, package descriptions and suggested commands, concealing real output, or writing to the clipboard. No authentication or privileged position is required; only publishing a package.\n\nThis issue affects hex: from 0.0.1 before 2.5.2."
}
],
"impacts": [
{
"capecId": "CAPEC-93",
"descriptions": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003eA malicious package publisher can forge what a developer sees when running \u003ccode\u003emix hex.search\u003c/code\u003e, rewriting the displayed hexdocs URL or a suggested command, concealing real output, or writing attacker-chosen text to the clipboard through OSC 52. Any developer who runs a documentation search that surfaces the attacker\u0027s package is affected.\u003c/p\u003e"
},
{
"base64": false,
"type": "text/markdown",
"value": "A malicious package publisher can forge what a developer sees when running `mix hex.search`, rewriting the displayed hexdocs URL or a suggested command, concealing real output, or writing attacker-chosen text to the clipboard through OSC 52. Any developer who runs a documentation search that surfaces the attacker\u0027s package is affected."
}
],
"value": "A malicious package publisher can forge what a developer sees when running mix hex.search, rewriting the displayed hexdocs URL or a suggested command, concealing real output, or writing attacker-chosen text to the clipboard through OSC 52. Any developer who runs a documentation search that surfaces the attacker\u0027s package is affected."
}
]
}
],
"metrics": [
{
"cvssV4_0": {
"Automatable": "NOT_DEFINED",
"Recovery": "NOT_DEFINED",
"Safety": "NOT_DEFINED",
"attackComplexity": "LOW",
"attackRequirements": "PRESENT",
"attackVector": "NETWORK",
"baseScore": 2.3,
"baseSeverity": "LOW",
"privilegesRequired": "NONE",
"providerUrgency": "NOT_DEFINED",
"subAvailabilityImpact": "NONE",
"subConfidentialityImpact": "NONE",
"subIntegrityImpact": "NONE",
"userInteraction": "PASSIVE",
"valueDensity": "NOT_DEFINED",
"vectorString": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:P/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N",
"version": "4.0",
"vulnAvailabilityImpact": "NONE",
"vulnConfidentialityImpact": "NONE",
"vulnIntegrityImpact": "LOW",
"vulnerabilityResponseEffort": "NOT_DEFINED"
},
"format": "CVSS",
"scenarios": [
{
"lang": "en",
"value": "GENERAL"
}
]
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-150",
"description": "CWE-150 Improper Neutralization of Escape, Meta, or Control Sequences",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-10-12T15:46:12.146Z",
"orgId": "6b3ad84c-e1a6-4bf7-a703-f496b71e49db",
"shortName": "EEF"
},
"references": [
{
"name": "GitHub Advisory",
"tags": [
"related",
"vendor-advisory"
],
"url": "https://github.com/hexpm/hex/security/advisories/GHSA-fpmj-3cxg-p766"
},
{
"name": "EEF CNA record for CVE-2026-81856",
"tags": [
"related"
],
"url": "https://cna.erlef.org/cves/CVE-2026-81856.html"
},
{
"name": "OSV record EEF-CVE-2026-81856",
"tags": [
"related"
],
"url": "https://osv.dev/vulnerability/EEF-CVE-2026-81856"
},
{
"name": "Introducing commit 211303e in hexpm/hex",
"tags": [
"related"
],
"url": "https://github.com/hexpm/hex/commit/211303e3f68f5d3ce06450c1ff1a7a770a9ab236"
},
{
"name": "Fix commit dd3305d in hexpm/hex",
"tags": [
"patch"
],
"url": "https://github.com/hexpm/hex/commit/dd3305ddf0032f6d0b468fd40dbbc3072bfcb8b8"
}
],
"solutions": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003eUpgrade Hex to 2.5.2 or later, for example with \u003ccode\u003emix local.hex\u003c/code\u003e. Hex then escapes terminal control characters in text from hex.pm and the registry before printing it, and rejects registry dependencies whose package or repository name isn\u0027t a valid name.\u003c/p\u003e"
},
{
"base64": false,
"type": "text/markdown",
"value": "Upgrade Hex to 2.5.2 or later, for example with `mix local.hex`. Hex then escapes terminal control characters in text from hex.pm and the registry before printing it, and rejects registry dependencies whose package or repository name isn\u0027t a valid name."
}
],
"value": "Upgrade Hex to 2.5.2 or later, for example with mix local.hex. Hex then escapes terminal control characters in text from hex.pm and the registry before printing it, and rejects registry dependencies whose package or repository name isn\u0027t a valid name."
}
],
"source": {
"discovery": "EXTERNAL"
},
"title": "Terminal escape sequence injection in Hex via unneutralized server-supplied output"
}
},
"cveMetadata": {
"assignerOrgId": "6b3ad84c-e1a6-4bf7-a703-f496b71e49db",
"assignerShortName": "EEF",
"cveId": "CVE-2026-81856",
"datePublished": "2026-10-12T15:46:12.146Z",
"dateReserved": "2026-08-31T00:45:02.431Z",
"dateUpdated": "2026-10-12T15:46:12.146Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
CVE-2026-103060 (GCVE-0-2026-103060)
Vulnerability from cvelistv5 – Published: 2026-10-12 15:43 – Updated: 2026-10-12 15:43
VLAI
EPSS
VEX
Title
Path traversal in rebar3 via unvalidated dependency app names
Summary
Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal') vulnerability in erlang rebar3 allows a malicious package publisher to delete a directory outside the project's _build directory and extract package files into it when a developer fetches dependencies.
A package release's dependencies in a Hex registry carry an app field that names the dependency's OTP application. rebar3 uses this field as the dependency's name without validating it (rebar_packages:parse_deps/1) and builds the dependency's directory from that name (rebar_app_utils:dep_to_app/7). rebar_fetch:download_source_online/2 deletes that directory with rm -rf and moves the fetched package into it. hex.pm didn't restrict the field to a directory name before 2026-10-12, so a publisher could set it to a value such as ../../../../target. When a project depends on such a release directly or transitively, rebar3 get-deps deletes the directory the name resolves to and writes the dependency's files there. This happens before the dependency's own rebar.config.script is evaluated, and get-deps compiles nothing.
This issue affects rebar3: from 3.7.0-rc1 before 3.27.2.
Severity
CWE
- CWE-22 - Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')
Assigner
References
5 references
| URL | Tags |
|---|---|
| https://github.com/erlang/rebar3/security/advisor… | relatedvendor-advisory |
| https://cna.erlef.org/cves/CVE-2026-103060.html | related |
| https://osv.dev/vulnerability/EEF-CVE-2026-103060 | related |
| https://github.com/erlang/rebar3/commit/56b7d8897… | related |
| https://github.com/erlang/rebar3/commit/e35282b26… | patch |
Impacted products
{
"containers": {
"cna": {
"affected": [
{
"cpes": [
"cpe:2.3:a:erlang:rebar3:*:*:*:*:*:*:*:*"
],
"defaultStatus": "unaffected",
"modules": [
"rebar_packages",
"rebar_app_utils",
"rebar_fetch"
],
"packageName": "rebar3",
"packageURL": "pkg:otp/rebar3?repository_url=https:%2F%2Fgithub.com%2Ferlang%2Frebar3\u0026vcs_url=git%2Bhttps:%2F%2Fgithub.com%2Ferlang%2Frebar3.git",
"product": "rebar3",
"programFiles": [
"apps/rebar/src/rebar_packages.erl",
"apps/rebar/src/rebar_app_utils.erl",
"apps/rebar/src/rebar_fetch.erl"
],
"programRoutines": [
{
"name": "rebar_packages:parse_deps/1"
},
{
"name": "rebar_app_utils:dep_to_app/7"
},
{
"name": "rebar_fetch:download_source/2"
},
{
"name": "rebar_fetch:download_source_online/2"
}
],
"repo": "https://github.com/erlang/rebar3",
"vendor": "erlang",
"versions": [
{
"lessThan": "3.27.2",
"status": "affected",
"version": "3.7.0-rc1",
"versionType": "semver"
}
]
},
{
"collectionURL": "https://github.com",
"cpes": [
"cpe:2.3:a:erlang:rebar3:*:*:*:*:*:*:*:*"
],
"defaultStatus": "unaffected",
"modules": [
"rebar_packages",
"rebar_app_utils",
"rebar_fetch"
],
"packageName": "erlang/rebar3",
"packageURL": "pkg:github/erlang/rebar3",
"product": "rebar3",
"programFiles": [
"apps/rebar/src/rebar_packages.erl",
"apps/rebar/src/rebar_app_utils.erl",
"apps/rebar/src/rebar_fetch.erl"
],
"programRoutines": [
{
"name": "rebar_packages:parse_deps/1"
},
{
"name": "rebar_app_utils:dep_to_app/7"
},
{
"name": "rebar_fetch:download_source/2"
},
{
"name": "rebar_fetch:download_source_online/2"
}
],
"repo": "https://github.com/erlang/rebar3",
"vendor": "erlang",
"versions": [
{
"lessThan": "e35282b26e499b1d9e8f30bba9dccd71cd8b02ba",
"status": "affected",
"version": "56b7d88975aa8da6446857cfd92de0825024bf63",
"versionType": "git"
}
]
}
],
"configurations": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003eAffects projects whose dependency tree, directly or transitively, contains a package release whose registry metadata gives a dependency a crafted \u003ccode\u003eapp\u003c/code\u003e name, when dependencies are fetched with \u003ccode\u003erebar3 get-deps\u003c/code\u003e or another command that fetches dependencies. hex.pm rejects such names when a release is published since 2026-10-12, and every requirement \u003ccode\u003eapp\u003c/code\u003e name in hex.pm\u0027s public registry on 2026-10-06 was a letter followed by letters, digits, \u003ccode\u003e_\u003c/code\u003e and \u003ccode\u003e-\u003c/code\u003e. Packages on other Hex repositories are affected when the repository operator signs such metadata.\u003c/p\u003e"
},
{
"base64": false,
"type": "text/markdown",
"value": "Affects projects whose dependency tree, directly or transitively, contains a package release whose registry metadata gives a dependency a crafted `app` name, when dependencies are fetched with `rebar3 get-deps` or another command that fetches dependencies. hex.pm rejects such names when a release is published since 2026-10-12, and every requirement `app` name in hex.pm\u0027s public registry on 2026-10-06 was a letter followed by letters, digits, `_` and `-`. Packages on other Hex repositories are affected when the repository operator signs such metadata."
}
],
"value": "Affects projects whose dependency tree, directly or transitively, contains a package release whose registry metadata gives a dependency a crafted app name, when dependencies are fetched with rebar3 get-deps or another command that fetches dependencies. hex.pm rejects such names when a release is published since 2026-10-12, and every requirement app name in hex.pm\u0027s public registry on 2026-10-06 was a letter followed by letters, digits, _ and -. Packages on other Hex repositories are affected when the repository operator signs such metadata."
}
],
"cpeApplicability": [
{
"nodes": [
{
"cpeMatch": [
{
"criteria": "cpe:2.3:a:erlang:rebar3:*:*:*:*:*:*:*:*",
"versionEndExcluding": "3.27.2",
"versionStartIncluding": "3.7.0-rc1",
"vulnerable": true
}
],
"negate": false,
"operator": "OR"
}
],
"operator": "AND"
}
],
"credits": [
{
"lang": "en",
"type": "finder",
"value": "Peter Ullrich"
},
{
"lang": "en",
"type": "remediation developer",
"value": "Eric Meadows-J\u00f6nsson"
},
{
"lang": "en",
"type": "analyst",
"value": "Jonatan M\u00e4nnchen / EEF"
}
],
"dateAssigned": "2026-10-07T22:04:17.000Z",
"descriptions": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003eImproper Limitation of a Pathname to a Restricted Directory (\u0027Path Traversal\u0027) vulnerability in erlang rebar3 allows a malicious package publisher to delete a directory outside the project\u0027s \u003ccode\u003e_build\u003c/code\u003e directory and extract package files into it when a developer fetches dependencies.\u003c/p\u003e\n\u003cp\u003eA package release\u0027s dependencies in a Hex registry carry an \u003ccode\u003eapp\u003c/code\u003e field that names the dependency\u0027s OTP application. rebar3 uses this field as the dependency\u0027s name without validating it (\u003ccode\u003erebar_packages:parse_deps/1\u003c/code\u003e) and builds the dependency\u0027s directory from that name (\u003ccode\u003erebar_app_utils:dep_to_app/7\u003c/code\u003e). \u003ccode\u003erebar_fetch:download_source_online/2\u003c/code\u003e deletes that directory with \u003ccode\u003erm -rf\u003c/code\u003e and moves the fetched package into it. hex.pm didn\u0027t restrict the field to a directory name before 2026-10-12, so a publisher could set it to a value such as \u003ccode\u003e../../../../target\u003c/code\u003e. When a project depends on such a release directly or transitively, \u003ccode\u003erebar3 get-deps\u003c/code\u003e deletes the directory the name resolves to and writes the dependency\u0027s files there. This happens before the dependency\u0027s own \u003ccode\u003erebar.config.script\u003c/code\u003e is evaluated, and \u003ccode\u003eget-deps\u003c/code\u003e compiles nothing.\u003c/p\u003e\n\u003cp\u003eThis issue affects rebar3: from 3.7.0-rc1 before 3.27.2.\u003c/p\u003e"
},
{
"base64": false,
"type": "text/markdown",
"value": "Improper Limitation of a Pathname to a Restricted Directory (\u0027Path Traversal\u0027) vulnerability in erlang rebar3 allows a malicious package publisher to delete a directory outside the project\u0027s `_build` directory and extract package files into it when a developer fetches dependencies.\n\nA package release\u0027s dependencies in a Hex registry carry an `app` field that names the dependency\u0027s OTP application. rebar3 uses this field as the dependency\u0027s name without validating it (`rebar_packages:parse_deps/1`) and builds the dependency\u0027s directory from that name (`rebar_app_utils:dep_to_app/7`). `rebar_fetch:download_source_online/2` deletes that directory with `rm -rf` and moves the fetched package into it. hex.pm didn\u0027t restrict the field to a directory name before 2026-10-12, so a publisher could set it to a value such as `../../../../target`. When a project depends on such a release directly or transitively, `rebar3 get-deps` deletes the directory the name resolves to and writes the dependency\u0027s files there. This happens before the dependency\u0027s own `rebar.config.script` is evaluated, and `get-deps` compiles nothing.\n\nThis issue affects rebar3: from 3.7.0-rc1 before 3.27.2."
}
],
"value": "Improper Limitation of a Pathname to a Restricted Directory (\u0027Path Traversal\u0027) vulnerability in erlang rebar3 allows a malicious package publisher to delete a directory outside the project\u0027s _build directory and extract package files into it when a developer fetches dependencies.\n\nA package release\u0027s dependencies in a Hex registry carry an app field that names the dependency\u0027s OTP application. rebar3 uses this field as the dependency\u0027s name without validating it (rebar_packages:parse_deps/1) and builds the dependency\u0027s directory from that name (rebar_app_utils:dep_to_app/7). rebar_fetch:download_source_online/2 deletes that directory with rm -rf and moves the fetched package into it. hex.pm didn\u0027t restrict the field to a directory name before 2026-10-12, so a publisher could set it to a value such as ../../../../target. When a project depends on such a release directly or transitively, rebar3 get-deps deletes the directory the name resolves to and writes the dependency\u0027s files there. This happens before the dependency\u0027s own rebar.config.script is evaluated, and get-deps compiles nothing.\n\nThis issue affects rebar3: from 3.7.0-rc1 before 3.27.2."
}
],
"impacts": [
{
"capecId": "CAPEC-126",
"descriptions": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003eA publisher of a package in a project\u0027s dependency tree can make \u003ccode\u003erebar3 get-deps\u003c/code\u003e delete a directory outside the project\u0027s \u003ccode\u003e_build\u003c/code\u003e directory that the developer\u0027s account can write, such as the project directory or its parent, and replace its contents with a dependency package\u0027s files. Replacing a directory whose contents are later run or loaded, such as a project directory whose \u003ccode\u003erebar.config.script\u003c/code\u003e the next rebar3 command there evaluates, can lead to code execution. It works when the package is a transitive dependency and needs no compilation. Developers, CI jobs and dependency update bots that fetch dependencies with rebar3 are affected.\u003c/p\u003e"
},
{
"base64": false,
"type": "text/markdown",
"value": "A publisher of a package in a project\u0027s dependency tree can make `rebar3 get-deps` delete a directory outside the project\u0027s `_build` directory that the developer\u0027s account can write, such as the project directory or its parent, and replace its contents with a dependency package\u0027s files. Replacing a directory whose contents are later run or loaded, such as a project directory whose `rebar.config.script` the next rebar3 command there evaluates, can lead to code execution. It works when the package is a transitive dependency and needs no compilation. Developers, CI jobs and dependency update bots that fetch dependencies with rebar3 are affected."
}
],
"value": "A publisher of a package in a project\u0027s dependency tree can make rebar3 get-deps delete a directory outside the project\u0027s _build directory that the developer\u0027s account can write, such as the project directory or its parent, and replace its contents with a dependency package\u0027s files. Replacing a directory whose contents are later run or loaded, such as a project directory whose rebar.config.script the next rebar3 command there evaluates, can lead to code execution. It works when the package is a transitive dependency and needs no compilation. Developers, CI jobs and dependency update bots that fetch dependencies with rebar3 are affected."
}
]
}
],
"metrics": [
{
"cvssV4_0": {
"Automatable": "NOT_DEFINED",
"Recovery": "NOT_DEFINED",
"Safety": "NOT_DEFINED",
"attackComplexity": "LOW",
"attackRequirements": "PRESENT",
"attackVector": "NETWORK",
"baseScore": 7.5,
"baseSeverity": "HIGH",
"privilegesRequired": "NONE",
"providerUrgency": "NOT_DEFINED",
"subAvailabilityImpact": "NONE",
"subConfidentialityImpact": "NONE",
"subIntegrityImpact": "NONE",
"userInteraction": "ACTIVE",
"valueDensity": "NOT_DEFINED",
"vectorString": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:A/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N",
"version": "4.0",
"vulnAvailabilityImpact": "HIGH",
"vulnConfidentialityImpact": "HIGH",
"vulnIntegrityImpact": "HIGH",
"vulnerabilityResponseEffort": "NOT_DEFINED"
},
"format": "CVSS",
"scenarios": [
{
"lang": "en",
"value": "GENERAL"
}
]
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-22",
"description": "CWE-22 Improper Limitation of a Pathname to a Restricted Directory (\u0027Path Traversal\u0027)",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-10-12T15:43:57.636Z",
"orgId": "6b3ad84c-e1a6-4bf7-a703-f496b71e49db",
"shortName": "EEF"
},
"references": [
{
"name": "GitHub Advisory",
"tags": [
"related",
"vendor-advisory"
],
"url": "https://github.com/erlang/rebar3/security/advisories/GHSA-6ggr-r7mh-2mv8"
},
{
"name": "EEF CNA record for CVE-2026-103060",
"tags": [
"related"
],
"url": "https://cna.erlef.org/cves/CVE-2026-103060.html"
},
{
"name": "OSV record EEF-CVE-2026-103060",
"tags": [
"related"
],
"url": "https://osv.dev/vulnerability/EEF-CVE-2026-103060"
},
{
"name": "Introducing commit 56b7d88 in erlang/rebar3",
"tags": [
"related"
],
"url": "https://github.com/erlang/rebar3/commit/56b7d88975aa8da6446857cfd92de0825024bf63"
},
{
"name": "Fix commit e35282b in erlang/rebar3",
"tags": [
"patch"
],
"url": "https://github.com/erlang/rebar3/commit/e35282b26e499b1d9e8f30bba9dccd71cd8b02ba"
}
],
"solutions": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003eUpgrade rebar3 to 3.27.2 or later, for example with \u003ccode\u003erebar3 local upgrade\u003c/code\u003e. rebar3 then fails with an error when a dependency\u0027s name, including the \u003ccode\u003eapp\u003c/code\u003e name a package release gives a dependency, isn\u0027t a letter followed by letters, digits, \u003ccode\u003e_\u003c/code\u003e and \u003ccode\u003e-\u003c/code\u003e.\u003c/p\u003e"
},
{
"base64": false,
"type": "text/markdown",
"value": "Upgrade rebar3 to 3.27.2 or later, for example with `rebar3 local upgrade`. rebar3 then fails with an error when a dependency\u0027s name, including the `app` name a package release gives a dependency, isn\u0027t a letter followed by letters, digits, `_` and `-`."
}
],
"value": "Upgrade rebar3 to 3.27.2 or later, for example with rebar3 local upgrade. rebar3 then fails with an error when a dependency\u0027s name, including the app name a package release gives a dependency, isn\u0027t a letter followed by letters, digits, _ and -."
}
],
"source": {
"discovery": "UNKNOWN"
},
"title": "Path traversal in rebar3 via unvalidated dependency app names",
"x_proofOfConcept": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003eReproduced with rebar3 3.27.0 on Erlang/OTP 29 against a local Hex repository, with origin and signature verification left on:\u003c/p\u003e\n\u003col\u003e\n\u003cli\u003eBuild a signed local Hex repository serving \u003ccode\u003eparent\u003c/code\u003e 1.0.0, whose dependency is \u003ccode\u003e#{package =\u0026gt; \u0026lt;\u0026lt;\"evildep\"\u0026gt;\u0026gt;, requirement =\u0026gt; \u0026lt;\u0026lt;\"1.0.0\"\u0026gt;\u0026gt;, optional =\u0026gt; false, app =\u0026gt; \u0026lt;\u0026lt;\"../../../../CANARY_OUTSIDE\"\u0026gt;\u0026gt;}\u003c/code\u003e, and \u003ccode\u003eevildep\u003c/code\u003e 1.0.0.\u003c/li\u003e\n\u003cli\u003eCreate a project with \u003ccode\u003e{deps, [{parent, \"1.0.0\"}]}\u003c/code\u003e that uses the local repository, and a file \u003ccode\u003eCANARY_OUTSIDE/precious.txt\u003c/code\u003e one level above the project root.\u003c/li\u003e\n\u003cli\u003eRun \u003ccode\u003erebar3 get-deps\u003c/code\u003e. It prints \u003ccode\u003eFetching parent v1.0.0\u003c/code\u003e and then \u003ccode\u003eFetching ../../../../CANARY_OUTSIDE v1.0.0\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003e\u003ccode\u003eCANARY_OUTSIDE/precious.txt\u003c/code\u003e is gone and \u003ccode\u003eCANARY_OUTSIDE/\u003c/code\u003e holds \u003ccode\u003eevildep\u003c/code\u003e\u0027s extracted files (\u003ccode\u003ehex_metadata.config\u003c/code\u003e, \u003ccode\u003esrc/evildep.app.src\u003c/code\u003e). No scripts, plugins or hooks are in either package.\u003c/li\u003e\n\u003c/ol\u003e"
},
{
"base64": false,
"type": "text/markdown",
"value": "Reproduced with rebar3 3.27.0 on Erlang/OTP 29 against a local Hex repository, with origin and signature verification left on:\n\n1. Build a signed local Hex repository serving `parent` 1.0.0, whose dependency is `#{package =\u003e \u003c\u003c\"evildep\"\u003e\u003e, requirement =\u003e \u003c\u003c\"1.0.0\"\u003e\u003e, optional =\u003e false, app =\u003e \u003c\u003c\"../../../../CANARY_OUTSIDE\"\u003e\u003e}`, and `evildep` 1.0.0.\n2. Create a project with `{deps, [{parent, \"1.0.0\"}]}` that uses the local repository, and a file `CANARY_OUTSIDE/precious.txt` one level above the project root.\n3. Run `rebar3 get-deps`. It prints `Fetching parent v1.0.0` and then `Fetching ../../../../CANARY_OUTSIDE v1.0.0`.\n4. `CANARY_OUTSIDE/precious.txt` is gone and `CANARY_OUTSIDE/` holds `evildep`\u0027s extracted files (`hex_metadata.config`, `src/evildep.app.src`). No scripts, plugins or hooks are in either package."
}
],
"value": "Reproduced with rebar3 3.27.0 on Erlang/OTP 29 against a local Hex repository, with origin and signature verification left on:\n\n* Build a signed local Hex repository serving parent 1.0.0, whose dependency is #{package =\u003e \u003c\u003c\"evildep\"\u003e\u003e, requirement =\u003e \u003c\u003c\"1.0.0\"\u003e\u003e, optional =\u003e false, app =\u003e \u003c\u003c\"../../../../CANARY_OUTSIDE\"\u003e\u003e}, and evildep 1.0.0.\n* Create a project with {deps, [{parent, \"1.0.0\"}]} that uses the local repository, and a file CANARY_OUTSIDE/precious.txt one level above the project root.\n* Run rebar3 get-deps. It prints Fetching parent v1.0.0 and then Fetching ../../../../CANARY_OUTSIDE v1.0.0.\n* CANARY_OUTSIDE/precious.txt is gone and CANARY_OUTSIDE/ holds evildep\u0027s extracted files (hex_metadata.config, src/evildep.app.src). No scripts, plugins or hooks are in either package."
}
],
"x_technicalAnalysis": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003col\u003e\n\u003cli\u003ehex.pm\u0027s registry record lists each release\u0027s dependencies as maps with \u003ccode\u003epackage\u003c/code\u003e, \u003ccode\u003erequirement\u003c/code\u003e, \u003ccode\u003eoptional\u003c/code\u003e, \u003ccode\u003eapp\u003c/code\u003e and \u003ccode\u003erepository\u003c/code\u003e. The \u003ccode\u003eapp\u003c/code\u003e value comes from the publisher\u0027s package metadata and hex.pm doesn\u0027t restrict it to a directory name. The record is signed with the repository\u0027s key after the publisher has chosen the value, so the signature doesn\u0027t constrain it.\u003c/li\u003e\n\u003cli\u003e\u003ccode\u003er3_hex_registry:decode_package/3\u003c/code\u003e decodes each dependency, including \u003ccode\u003eapp\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003e\u003ccode\u003erebar_packages:parse_deps/1\u003c/code\u003e sets the dependency\u0027s name to the \u003ccode\u003eapp\u003c/code\u003e value, falling back to the package name: \u003ccode\u003e{maps:get(app, D, Name), {pkg, Name, Constraint, undefined, undefined}}\u003c/code\u003e. The name is stored in \u003ccode\u003e#package.dependencies\u003c/code\u003e and passed through \u003ccode\u003erebar_app_utils:update_source/3\u003c/code\u003e and \u003ccode\u003erebar_prv_install_deps:handle_dep/6\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003e\u003ccode\u003erebar_app_utils:dep_to_app/7\u003c/code\u003e builds the fetch directory with \u003ccode\u003efilename:join([DepsDir, Name])\u003c/code\u003e and no check.\u003c/li\u003e\n\u003cli\u003e\u003ccode\u003erebar_fetch:download_source_online/2\u003c/code\u003e runs \u003ccode\u003erebar_file_utils:rm_rf(filename:absname(FetchDir))\u003c/code\u003e and then \u003ccode\u003erebar_file_utils:mv(TmpDir, filename:absname(FetchDir))\u003c/code\u003e. \u003ccode\u003efilename:absname/1\u003c/code\u003e doesn\u0027t collapse \u003ccode\u003e..\u003c/code\u003e segments, and on Unix \u003ccode\u003erm_rf/1\u003c/code\u003e runs \u003ccode\u003erm -rf\u003c/code\u003e through the shell with \u003ccode\u003erebar_utils:escape_chars/1\u003c/code\u003e, which doesn\u0027t escape \u003ccode\u003e/\u003c/code\u003e or \u003ccode\u003e.\u003c/code\u003e, so the \u003ccode\u003e..\u003c/code\u003e segments resolve outside the deps directory.\u003c/li\u003e\n\u003cli\u003eThe delete and overwrite happen for the dependency named by \u003ccode\u003eapp\u003c/code\u003e before its own \u003ccode\u003erebar.config.script\u003c/code\u003e is consulted (later in \u003ccode\u003erebar_fetch:download_source/2\u003c/code\u003e), and \u003ccode\u003eget-deps\u003c/code\u003e compiles nothing. rebar3 already runs publisher code during \u003ccode\u003eget-deps\u003c/code\u003e by evaluating a fetched package\u0027s \u003ccode\u003erebar.config.script\u003c/code\u003e and installing a dependency\u0027s plugins; the \u003ccode\u003eapp\u003c/code\u003e name adds a delete and overwrite outside \u003ccode\u003e_build\u003c/code\u003e for a dependency named by its parent package.\u003c/li\u003e\n\u003c/ol\u003e"
},
{
"base64": false,
"type": "text/markdown",
"value": "1. hex.pm\u0027s registry record lists each release\u0027s dependencies as maps with `package`, `requirement`, `optional`, `app` and `repository`. The `app` value comes from the publisher\u0027s package metadata and hex.pm doesn\u0027t restrict it to a directory name. The record is signed with the repository\u0027s key after the publisher has chosen the value, so the signature doesn\u0027t constrain it.\n2. `r3_hex_registry:decode_package/3` decodes each dependency, including `app`.\n3. `rebar_packages:parse_deps/1` sets the dependency\u0027s name to the `app` value, falling back to the package name: `{maps:get(app, D, Name), {pkg, Name, Constraint, undefined, undefined}}`. The name is stored in `#package.dependencies` and passed through `rebar_app_utils:update_source/3` and `rebar_prv_install_deps:handle_dep/6`.\n4. `rebar_app_utils:dep_to_app/7` builds the fetch directory with `filename:join([DepsDir, Name])` and no check.\n5. `rebar_fetch:download_source_online/2` runs `rebar_file_utils:rm_rf(filename:absname(FetchDir))` and then `rebar_file_utils:mv(TmpDir, filename:absname(FetchDir))`. `filename:absname/1` doesn\u0027t collapse `..` segments, and on Unix `rm_rf/1` runs `rm -rf` through the shell with `rebar_utils:escape_chars/1`, which doesn\u0027t escape `/` or `.`, so the `..` segments resolve outside the deps directory.\n6. The delete and overwrite happen for the dependency named by `app` before its own `rebar.config.script` is consulted (later in `rebar_fetch:download_source/2`), and `get-deps` compiles nothing. rebar3 already runs publisher code during `get-deps` by evaluating a fetched package\u0027s `rebar.config.script` and installing a dependency\u0027s plugins; the `app` name adds a delete and overwrite outside `_build` for a dependency named by its parent package."
}
],
"value": "* hex.pm\u0027s registry record lists each release\u0027s dependencies as maps with package, requirement, optional, app and repository. The app value comes from the publisher\u0027s package metadata and hex.pm doesn\u0027t restrict it to a directory name. The record is signed with the repository\u0027s key after the publisher has chosen the value, so the signature doesn\u0027t constrain it.\n* r3_hex_registry:decode_package/3 decodes each dependency, including app.\n* rebar_packages:parse_deps/1 sets the dependency\u0027s name to the app value, falling back to the package name: {maps:get(app, D, Name), {pkg, Name, Constraint, undefined, undefined}}. The name is stored in #package.dependencies and passed through rebar_app_utils:update_source/3 and rebar_prv_install_deps:handle_dep/6.\n* rebar_app_utils:dep_to_app/7 builds the fetch directory with filename:join([DepsDir, Name]) and no check.\n* rebar_fetch:download_source_online/2 runs rebar_file_utils:rm_rf(filename:absname(FetchDir)) and then rebar_file_utils:mv(TmpDir, filename:absname(FetchDir)). filename:absname/1 doesn\u0027t collapse .. segments, and on Unix rm_rf/1 runs rm -rf through the shell with rebar_utils:escape_chars/1, which doesn\u0027t escape / or ., so the .. segments resolve outside the deps directory.\n* The delete and overwrite happen for the dependency named by app before its own rebar.config.script is consulted (later in rebar_fetch:download_source/2), and get-deps compiles nothing. rebar3 already runs publisher code during get-deps by evaluating a fetched package\u0027s rebar.config.script and installing a dependency\u0027s plugins; the app name adds a delete and overwrite outside _build for a dependency named by its parent package."
}
]
}
},
"cveMetadata": {
"assignerOrgId": "6b3ad84c-e1a6-4bf7-a703-f496b71e49db",
"assignerShortName": "EEF",
"cveId": "CVE-2026-103060",
"datePublished": "2026-10-12T15:43:57.636Z",
"dateReserved": "2026-10-06T08:45:01.521Z",
"dateUpdated": "2026-10-12T15:43:57.636Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
CVE-2026-96612 (GCVE-0-2026-96612)
Vulnerability from cvelistv5 – Published: 2026-10-12 15:39 – Updated: 2026-10-12 15:39
VLAI
EPSS
VEX
Title
Path traversal in Hex via unvalidated dependency app names
Summary
Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal') vulnerability in hexpm hex allows a malicious package publisher to delete a directory outside the project's deps directory and extract package files into it when a developer fetches dependencies.
A package release's requirements carry an app label that names the dependency's OTP application. Hex takes this label from the repository's signed registry and uses it as the dependency's application name without validating it (Hex.RemoteConverger.deps/2, Hex.Mix.to_lock/1). Mix derives the dependency's checkout directory as deps/<app>, and Hex.SCM.update/1 runs File.rm_rf!/1 on that directory and unpacks the package into it. hex.pm only checks the label's length, so a publisher can set it to a value such as ../../target. When a project depends on such a release directly or transitively, mix deps.get or mix deps.update deletes the directory the label resolves to and writes the labelled package's files there. This happens before any dependency code is compiled.
This issue affects hex: from 0.6.0 before 2.5.2.
Severity
CWE
- CWE-22 - Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')
Assigner
References
6 references
Impacted products
{
"containers": {
"cna": {
"affected": [
{
"cpes": [
"cpe:2.3:a:hexpm:hex:*:*:*:*:*:*:*:*"
],
"defaultStatus": "unaffected",
"modules": [
"\u0027Elixir.Hex.RemoteConverger\u0027",
"\u0027Elixir.Hex.Mix\u0027",
"\u0027Elixir.Hex.SCM\u0027"
],
"packageName": "hex",
"packageURL": "pkg:otp/hex?repository_url=https:%2F%2Fgithub.com%2Fhexpm%2Fhex\u0026vcs_url=repository_url=git%2Bhttps:%2F%2Fgithub.com%2Fhexpm%2Fhex.git",
"product": "hex",
"programFiles": [
"lib/hex/remote_converger.ex",
"lib/hex/mix.ex",
"lib/hex/scm.ex"
],
"programRoutines": [
{
"name": "\u0027Elixir.Hex.RemoteConverger\u0027:deps/2"
},
{
"name": "\u0027Elixir.Hex.RemoteConverger\u0027:converge/2"
},
{
"name": "\u0027Elixir.Hex.Mix\u0027:to_lock/1"
},
{
"name": "\u0027Elixir.Hex.SCM\u0027:update/1"
},
{
"name": "\u0027Elixir.Hex.SCM\u0027:checkout/1"
}
],
"repo": "https://github.com/hexpm/hex",
"vendor": "hexpm",
"versions": [
{
"lessThan": "2.5.2",
"status": "affected",
"version": "0.6.0",
"versionType": "semver"
}
]
},
{
"collectionURL": "https://github.com",
"cpes": [
"cpe:2.3:a:hexpm:hex:*:*:*:*:*:*:*:*"
],
"defaultStatus": "unaffected",
"modules": [
"\u0027Elixir.Hex.RemoteConverger\u0027",
"\u0027Elixir.Hex.Mix\u0027",
"\u0027Elixir.Hex.SCM\u0027"
],
"packageName": "hexpm/hex",
"packageURL": "pkg:github/hexpm/hex",
"product": "hex",
"programFiles": [
"lib/hex/remote_converger.ex",
"lib/hex/mix.ex",
"lib/hex/scm.ex"
],
"programRoutines": [
{
"name": "\u0027Elixir.Hex.RemoteConverger\u0027:deps/2"
},
{
"name": "\u0027Elixir.Hex.RemoteConverger\u0027:converge/2"
},
{
"name": "\u0027Elixir.Hex.Mix\u0027:to_lock/1"
},
{
"name": "\u0027Elixir.Hex.SCM\u0027:update/1"
},
{
"name": "\u0027Elixir.Hex.SCM\u0027:checkout/1"
}
],
"repo": "https://github.com/hexpm/hex",
"vendor": "hexpm",
"versions": [
{
"changes": [
{
"at": "1b3e2ae8f0dd7273a2c2625b9e50b6c67c8568fb",
"status": "unaffected"
},
{
"at": "72279a8e2004b32b20d8767ff010c117193dd02c",
"status": "unaffected"
}
],
"lessThan": "*",
"status": "affected",
"version": "380f87054e1bc08ee13d2b5311bc01f98dad2fc6",
"versionType": "git"
}
]
}
],
"configurations": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003eAffects projects whose dependency tree, directly or transitively, contains a package release whose registry metadata carries a crafted dependency \u003ccode\u003eapp\u003c/code\u003e label, when dependencies are fetched with \u003ccode\u003emix deps.get\u003c/code\u003e or \u003ccode\u003emix deps.update\u003c/code\u003e. Packages on hex.pm are affected while hex.pm accepts such labels; packages on self-hosted repositories are affected when the repository operator signs such metadata.\u003c/p\u003e"
},
{
"base64": false,
"type": "text/markdown",
"value": "Affects projects whose dependency tree, directly or transitively, contains a package release whose registry metadata carries a crafted dependency `app` label, when dependencies are fetched with `mix deps.get` or `mix deps.update`. Packages on hex.pm are affected while hex.pm accepts such labels; packages on self-hosted repositories are affected when the repository operator signs such metadata."
}
],
"value": "Affects projects whose dependency tree, directly or transitively, contains a package release whose registry metadata carries a crafted dependency app label, when dependencies are fetched with mix deps.get or mix deps.update. Packages on hex.pm are affected while hex.pm accepts such labels; packages on self-hosted repositories are affected when the repository operator signs such metadata."
}
],
"cpeApplicability": [
{
"nodes": [
{
"cpeMatch": [
{
"criteria": "cpe:2.3:a:hexpm:hex:*:*:*:*:*:*:*:*",
"versionEndExcluding": "2.5.2",
"versionStartIncluding": "0.6.0",
"vulnerable": true
}
],
"negate": false,
"operator": "OR"
}
],
"operator": "AND"
}
],
"credits": [
{
"lang": "en",
"type": "finder",
"value": "Peter Ullrich"
},
{
"lang": "en",
"type": "remediation developer",
"value": "Eric Meadows-J\u00f6nsson"
},
{
"lang": "en",
"type": "analyst",
"value": "Jonatan M\u00e4nnchen / EEF"
}
],
"dateAssigned": "2026-10-07T22:03:18.000Z",
"descriptions": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003eImproper Limitation of a Pathname to a Restricted Directory (\u0027Path Traversal\u0027) vulnerability in hexpm hex allows a malicious package publisher to delete a directory outside the project\u0027s \u003ccode\u003edeps\u003c/code\u003e directory and extract package files into it when a developer fetches dependencies.\u003c/p\u003e\n\u003cp\u003eA package release\u0027s requirements carry an \u003ccode\u003eapp\u003c/code\u003e label that names the dependency\u0027s OTP application. Hex takes this label from the repository\u0027s signed registry and uses it as the dependency\u0027s application name without validating it (\u003ccode\u003eHex.RemoteConverger.deps/2\u003c/code\u003e, \u003ccode\u003eHex.Mix.to_lock/1\u003c/code\u003e). Mix derives the dependency\u0027s checkout directory as \u003ccode\u003edeps/\u0026lt;app\u0026gt;\u003c/code\u003e, and \u003ccode\u003eHex.SCM.update/1\u003c/code\u003e runs \u003ccode\u003eFile.rm_rf!/1\u003c/code\u003e on that directory and unpacks the package into it. hex.pm only checks the label\u0027s length, so a publisher can set it to a value such as \u003ccode\u003e../../target\u003c/code\u003e. When a project depends on such a release directly or transitively, \u003ccode\u003emix deps.get\u003c/code\u003e or \u003ccode\u003emix deps.update\u003c/code\u003e deletes the directory the label resolves to and writes the labelled package\u0027s files there. This happens before any dependency code is compiled.\u003c/p\u003e\n\u003cp\u003eThis issue affects hex: from 0.6.0 before 2.5.2.\u003c/p\u003e"
},
{
"base64": false,
"type": "text/markdown",
"value": "Improper Limitation of a Pathname to a Restricted Directory (\u0027Path Traversal\u0027) vulnerability in hexpm hex allows a malicious package publisher to delete a directory outside the project\u0027s `deps` directory and extract package files into it when a developer fetches dependencies.\n\nA package release\u0027s requirements carry an `app` label that names the dependency\u0027s OTP application. Hex takes this label from the repository\u0027s signed registry and uses it as the dependency\u0027s application name without validating it (`Hex.RemoteConverger.deps/2`, `Hex.Mix.to_lock/1`). Mix derives the dependency\u0027s checkout directory as `deps/\u003capp\u003e`, and `Hex.SCM.update/1` runs `File.rm_rf!/1` on that directory and unpacks the package into it. hex.pm only checks the label\u0027s length, so a publisher can set it to a value such as `../../target`. When a project depends on such a release directly or transitively, `mix deps.get` or `mix deps.update` deletes the directory the label resolves to and writes the labelled package\u0027s files there. This happens before any dependency code is compiled.\n\nThis issue affects hex: from 0.6.0 before 2.5.2."
}
],
"value": "Improper Limitation of a Pathname to a Restricted Directory (\u0027Path Traversal\u0027) vulnerability in hexpm hex allows a malicious package publisher to delete a directory outside the project\u0027s deps directory and extract package files into it when a developer fetches dependencies.\n\nA package release\u0027s requirements carry an app label that names the dependency\u0027s OTP application. Hex takes this label from the repository\u0027s signed registry and uses it as the dependency\u0027s application name without validating it (Hex.RemoteConverger.deps/2, Hex.Mix.to_lock/1). Mix derives the dependency\u0027s checkout directory as deps/\u003capp\u003e, and Hex.SCM.update/1 runs File.rm_rf!/1 on that directory and unpacks the package into it. hex.pm only checks the label\u0027s length, so a publisher can set it to a value such as ../../target. When a project depends on such a release directly or transitively, mix deps.get or mix deps.update deletes the directory the label resolves to and writes the labelled package\u0027s files there. This happens before any dependency code is compiled.\n\nThis issue affects hex: from 0.6.0 before 2.5.2."
}
],
"impacts": [
{
"capecId": "CAPEC-126",
"descriptions": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003eA publisher of any package in a project\u0027s dependency tree can make \u003ccode\u003emix deps.get\u003c/code\u003e delete a directory that the developer\u0027s account can write and that \u003ccode\u003e..\u003c/code\u003e segments relative to \u003ccode\u003edeps\u003c/code\u003e reach, such as the project directory or its parent, and fill it with the labelled package\u0027s files. Writing attacker-chosen files into a directory whose contents are later run or loaded can lead to code execution without the developer compiling the dependency. Developers who fetch dependencies to review them before compiling, CI jobs and dependency update bots that only run \u003ccode\u003emix deps.get\u003c/code\u003e or \u003ccode\u003emix deps.update\u003c/code\u003e are affected.\u003c/p\u003e"
},
{
"base64": false,
"type": "text/markdown",
"value": "A publisher of any package in a project\u0027s dependency tree can make `mix deps.get` delete a directory that the developer\u0027s account can write and that `..` segments relative to `deps` reach, such as the project directory or its parent, and fill it with the labelled package\u0027s files. Writing attacker-chosen files into a directory whose contents are later run or loaded can lead to code execution without the developer compiling the dependency. Developers who fetch dependencies to review them before compiling, CI jobs and dependency update bots that only run `mix deps.get` or `mix deps.update` are affected."
}
],
"value": "A publisher of any package in a project\u0027s dependency tree can make mix deps.get delete a directory that the developer\u0027s account can write and that .. segments relative to deps reach, such as the project directory or its parent, and fill it with the labelled package\u0027s files. Writing attacker-chosen files into a directory whose contents are later run or loaded can lead to code execution without the developer compiling the dependency. Developers who fetch dependencies to review them before compiling, CI jobs and dependency update bots that only run mix deps.get or mix deps.update are affected."
}
]
}
],
"metrics": [
{
"cvssV4_0": {
"Automatable": "NOT_DEFINED",
"Recovery": "NOT_DEFINED",
"Safety": "NOT_DEFINED",
"attackComplexity": "LOW",
"attackRequirements": "PRESENT",
"attackVector": "NETWORK",
"baseScore": 7.5,
"baseSeverity": "HIGH",
"privilegesRequired": "NONE",
"providerUrgency": "NOT_DEFINED",
"subAvailabilityImpact": "NONE",
"subConfidentialityImpact": "NONE",
"subIntegrityImpact": "NONE",
"userInteraction": "ACTIVE",
"valueDensity": "NOT_DEFINED",
"vectorString": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:A/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N",
"version": "4.0",
"vulnAvailabilityImpact": "HIGH",
"vulnConfidentialityImpact": "HIGH",
"vulnIntegrityImpact": "HIGH",
"vulnerabilityResponseEffort": "NOT_DEFINED"
},
"format": "CVSS",
"scenarios": [
{
"lang": "en",
"value": "GENERAL"
}
]
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-22",
"description": "CWE-22 Improper Limitation of a Pathname to a Restricted Directory (\u0027Path Traversal\u0027)",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-10-12T15:39:49.862Z",
"orgId": "6b3ad84c-e1a6-4bf7-a703-f496b71e49db",
"shortName": "EEF"
},
"references": [
{
"name": "GitHub Advisory",
"tags": [
"related",
"vendor-advisory"
],
"url": "https://github.com/hexpm/hex/security/advisories/GHSA-2vjj-c5hr-6xc3"
},
{
"name": "EEF CNA record for CVE-2026-96612",
"tags": [
"related"
],
"url": "https://cna.erlef.org/cves/CVE-2026-96612.html"
},
{
"name": "OSV record EEF-CVE-2026-96612",
"tags": [
"related"
],
"url": "https://osv.dev/vulnerability/EEF-CVE-2026-96612"
},
{
"name": "Introducing commit 380f870 in hexpm/hex",
"tags": [
"related"
],
"url": "https://github.com/hexpm/hex/commit/380f87054e1bc08ee13d2b5311bc01f98dad2fc6"
},
{
"name": "Fix commit 1b3e2ae in hexpm/hex",
"tags": [
"patch"
],
"url": "https://github.com/hexpm/hex/commit/1b3e2ae8f0dd7273a2c2625b9e50b6c67c8568fb"
},
{
"name": "Fix commit 72279a8 in hexpm/hex",
"tags": [
"patch"
],
"url": "https://github.com/hexpm/hex/commit/72279a8e2004b32b20d8767ff010c117193dd02c"
}
],
"solutions": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003eUpgrade Hex to 2.5.2 or later, for example with \u003ccode\u003emix local.hex\u003c/code\u003e. Hex then skips package releases that give a dependency an application name other than a letter followed by letters, digits, \u003ccode\u003e_\u003c/code\u003e and \u003ccode\u003e-\u003c/code\u003e, and warns about them. Resolution fails if no other release of the package fits the requirements.\u003c/p\u003e"
},
{
"base64": false,
"type": "text/markdown",
"value": "Upgrade Hex to 2.5.2 or later, for example with `mix local.hex`. Hex then skips package releases that give a dependency an application name other than a letter followed by letters, digits, `_` and `-`, and warns about them. Resolution fails if no other release of the package fits the requirements."
}
],
"value": "Upgrade Hex to 2.5.2 or later, for example with mix local.hex. Hex then skips package releases that give a dependency an application name other than a letter followed by letters, digits, _ and -, and warns about them. Resolution fails if no other release of the package fits the requirements."
}
],
"source": {
"discovery": "UNKNOWN"
},
"title": "Path traversal in Hex via unvalidated dependency app names",
"workarounds": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003eBefore running \u003ccode\u003emix deps.get\u003c/code\u003e on a \u003ccode\u003emix.lock\u003c/code\u003e from an untrusted change, check that every key in \u003ccode\u003emix.lock\u003c/code\u003e is a plain application name without \u003ccode\u003e/\u003c/code\u003e, \u003ccode\u003e\\\u003c/code\u003e or \u003ccode\u003e..\u003c/code\u003e. There\u0027s no workaround for new dependency resolution with \u003ccode\u003emix deps.update\u003c/code\u003e or \u003ccode\u003emix deps.get\u003c/code\u003e without a lock entry.\u003c/p\u003e"
},
{
"base64": false,
"type": "text/markdown",
"value": "Before running `mix deps.get` on a `mix.lock` from an untrusted change, check that every key in `mix.lock` is a plain application name without `/`, `\\` or `..`. There\u0027s no workaround for new dependency resolution with `mix deps.update` or `mix deps.get` without a lock entry."
}
],
"value": "Before running mix deps.get on a mix.lock from an untrusted change, check that every key in mix.lock is a plain application name without /, \\ or ... There\u0027s no workaround for new dependency resolution with mix deps.update or mix deps.get without a lock entry."
}
],
"x_proofOfConcept": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003col\u003e\n\u003cli\u003ePublish package \u003ccode\u003ebeta\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003ePublish package \u003ccode\u003ealpha\u003c/code\u003e with a requirement on \u003ccode\u003ebeta\u003c/code\u003e whose \u003ccode\u003eapp\u003c/code\u003e is \u003ccode\u003e../../escape_marker\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eIn a project that depends on \u003ccode\u003ealpha\u003c/code\u003e, create \u003ccode\u003e../escape_marker/canary.txt\u003c/code\u003e next to the project directory.\u003c/li\u003e\n\u003cli\u003eRun \u003ccode\u003emix deps.get\u003c/code\u003e. Hex prints \u003ccode\u003e* Updating ../../escape_marker (Hex package)\u003c/code\u003e, deletes \u003ccode\u003ecanary.txt\u003c/code\u003e and writes \u003ccode\u003ebeta\u003c/code\u003e\u0027s files into \u003ccode\u003e../escape_marker\u003c/code\u003e.\u003c/li\u003e\n\u003c/ol\u003e"
},
{
"base64": false,
"type": "text/markdown",
"value": "1. Publish package `beta`.\n2. Publish package `alpha` with a requirement on `beta` whose `app` is `../../escape_marker`.\n3. In a project that depends on `alpha`, create `../escape_marker/canary.txt` next to the project directory.\n4. Run `mix deps.get`. Hex prints `* Updating ../../escape_marker (Hex package)`, deletes `canary.txt` and writes `beta`\u0027s files into `../escape_marker`."
}
],
"value": "* Publish package beta.\n* Publish package alpha with a requirement on beta whose app is ../../escape_marker.\n* In a project that depends on alpha, create ../escape_marker/canary.txt next to the project directory.\n* Run mix deps.get. Hex prints * Updating ../../escape_marker (Hex package), deletes canary.txt and writes beta\u0027s files into ../escape_marker."
}
],
"x_technicalAnalysis": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003col\u003e\n\u003cli\u003ehex.pm stores each requirement\u0027s \u003ccode\u003eapp\u003c/code\u003e field with only a length check (255 codepoints) and copies it into the signed package registry resource when it differs from the dependency\u0027s package name.\u003c/li\u003e\n\u003cli\u003e\u003ccode\u003eHex.RemoteConverger.deps/2\u003c/code\u003e returns the dependency\u0027s children with \u003ccode\u003eString.to_atom/1\u003c/code\u003e of that label as the application name, and \u003ccode\u003eHex.Mix.to_lock/1\u003c/code\u003e writes it as the \u003ccode\u003emix.lock\u003c/code\u003e key.\u003c/li\u003e\n\u003cli\u003eMix computes the dependency destination as \u003ccode\u003ePath.join(Mix.Project.deps_path(), Atom.to_string(app))\u003c/code\u003e without validating the name.\u003c/li\u003e\n\u003cli\u003e\u003ccode\u003eHex.SCM.update/1\u003c/code\u003e calls \u003ccode\u003eFile.rm_rf!(dest)\u003c/code\u003e and then \u003ccode\u003eHex.Tar.unpack!(path, dest)\u003c/code\u003e, so a label containing \u003ccode\u003e..\u003c/code\u003e segments deletes and repopulates a directory outside \u003ccode\u003edeps\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eMix doesn\u0027t evaluate a Hex dependency\u0027s \u003ccode\u003emix.exs\u003c/code\u003e during \u003ccode\u003emix deps.get\u003c/code\u003e, so this is reachable before any package code runs.\u003c/li\u003e\n\u003c/ol\u003e"
},
{
"base64": false,
"type": "text/markdown",
"value": "1. hex.pm stores each requirement\u0027s `app` field with only a length check (255 codepoints) and copies it into the signed package registry resource when it differs from the dependency\u0027s package name.\n2. `Hex.RemoteConverger.deps/2` returns the dependency\u0027s children with `String.to_atom/1` of that label as the application name, and `Hex.Mix.to_lock/1` writes it as the `mix.lock` key.\n3. Mix computes the dependency destination as `Path.join(Mix.Project.deps_path(), Atom.to_string(app))` without validating the name.\n4. `Hex.SCM.update/1` calls `File.rm_rf!(dest)` and then `Hex.Tar.unpack!(path, dest)`, so a label containing `..` segments deletes and repopulates a directory outside `deps`.\n5. Mix doesn\u0027t evaluate a Hex dependency\u0027s `mix.exs` during `mix deps.get`, so this is reachable before any package code runs."
}
],
"value": "* hex.pm stores each requirement\u0027s app field with only a length check (255 codepoints) and copies it into the signed package registry resource when it differs from the dependency\u0027s package name.\n* Hex.RemoteConverger.deps/2 returns the dependency\u0027s children with String.to_atom/1 of that label as the application name, and Hex.Mix.to_lock/1 writes it as the mix.lock key.\n* Mix computes the dependency destination as Path.join(Mix.Project.deps_path(), Atom.to_string(app)) without validating the name.\n* Hex.SCM.update/1 calls File.rm_rf!(dest) and then Hex.Tar.unpack!(path, dest), so a label containing .. segments deletes and repopulates a directory outside deps.\n* Mix doesn\u0027t evaluate a Hex dependency\u0027s mix.exs during mix deps.get, so this is reachable before any package code runs."
}
]
}
},
"cveMetadata": {
"assignerOrgId": "6b3ad84c-e1a6-4bf7-a703-f496b71e49db",
"assignerShortName": "EEF",
"cveId": "CVE-2026-96612",
"datePublished": "2026-10-12T15:39:49.862Z",
"dateReserved": "2026-10-01T09:00:02.103Z",
"dateUpdated": "2026-10-12T15:39:49.862Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
CVE-2026-105668 (GCVE-0-2026-105668)
Vulnerability from cvelistv5 – Published: 2026-10-12 15:31 – Updated: 2026-10-12 15:31
VLAI
EPSS
VEX
Title
Hex release-age cooldown is lifted package-wide when the locked release is retired
Summary
Protection Mechanism Failure vulnerability in hexpm hex allows the owner of a package, or an attacker who has taken over the owner's account, to get a newly published release past the release-age cooldown.
The cooldown (cooldown config, HEX_COOLDOWN) withholds versions younger than the configured age during dependency resolution. When the release of a package locked in mix.lock is retired or has a security advisory, Hex.RemoteConverger.build_cooldown_bypass/3 and Hex.RemoteConverger.unsafe_lock_bypass/1 lift the cooldown for every version of that package and of every package the locked release depends on, so that mix deps.update can move off the unsafe release. Retiring a release needs the same package owner permission as publishing one. An attacker who publishes a malicious release can retire the currently locked release, and the next mix deps.update that unlocks the package selects the new release regardless of its age. Hex.Registry.Cooldown.versions/2 checks the bypass by package name alone, so the bypass also covers packages with the same name in other repositories. Cooldown configured through an organization dependency policy is not affected.
This issue affects hex: from 2.5.0 before 2.5.2.
Severity
CWE
- CWE-693 - Protection Mechanism Failure
Assigner
References
6 references
Impacted products
{
"containers": {
"cna": {
"affected": [
{
"cpes": [
"cpe:2.3:a:hexpm:hex:*:*:*:*:*:*:*:*"
],
"defaultStatus": "unaffected",
"modules": [
"\u0027Elixir.Hex.RemoteConverger\u0027",
"\u0027Elixir.Hex.Registry.Cooldown\u0027"
],
"packageName": "hex",
"packageURL": "pkg:otp/hex?repository_url=https:%2F%2Fgithub.com%2Fhexpm%2Fhex\u0026vcs_url=repository_url=git%2Bhttps:%2F%2Fgithub.com%2Fhexpm%2Fhex.git",
"product": "hex",
"programFiles": [
"lib/hex/remote_converger.ex",
"lib/hex/registry/cooldown.ex"
],
"programRoutines": [
{
"name": "\u0027Elixir.Hex.RemoteConverger\u0027:build_cooldown_bypass/3"
},
{
"name": "\u0027Elixir.Hex.RemoteConverger\u0027:unsafe_lock_bypass/1"
},
{
"name": "\u0027Elixir.Hex.Registry.Cooldown\u0027:versions/2"
}
],
"repo": "https://github.com/hexpm/hex",
"vendor": "hexpm",
"versions": [
{
"lessThan": "2.5.2",
"status": "affected",
"version": "2.5.0",
"versionType": "semver"
}
]
},
{
"collectionURL": "https://github.com",
"cpes": [
"cpe:2.3:a:hexpm:hex:*:*:*:*:*:*:*:*"
],
"defaultStatus": "unaffected",
"modules": [
"\u0027Elixir.Hex.RemoteConverger\u0027",
"\u0027Elixir.Hex.Registry.Cooldown\u0027"
],
"packageName": "hexpm/hex",
"packageURL": "pkg:github/hexpm/hex",
"product": "hex",
"programFiles": [
"lib/hex/remote_converger.ex",
"lib/hex/registry/cooldown.ex"
],
"programRoutines": [
{
"name": "\u0027Elixir.Hex.RemoteConverger\u0027:build_cooldown_bypass/3"
},
{
"name": "\u0027Elixir.Hex.RemoteConverger\u0027:unsafe_lock_bypass/1"
},
{
"name": "\u0027Elixir.Hex.Registry.Cooldown\u0027:versions/2"
}
],
"repo": "https://github.com/hexpm/hex",
"vendor": "hexpm",
"versions": [
{
"changes": [
{
"at": "eed2bdf85320ae9e244629511c03f5f3f8c5d0b5",
"status": "unaffected"
},
{
"at": "1b6fddfeadd98ed26a143f60356efade0494e2ae",
"status": "unaffected"
}
],
"lessThan": "*",
"status": "affected",
"version": "b4e665d46be8a5f81e8cbbe4c3a67058a19cf133",
"versionType": "git"
}
]
}
],
"configurations": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003eAffects projects that set the \u003ccode\u003ecooldown\u003c/code\u003e config or \u003ccode\u003eHEX_COOLDOWN\u003c/code\u003e and update dependencies with \u003ccode\u003emix deps.update\u003c/code\u003e, or otherwise unlock the package during resolution. Cooldowns enforced through an organization dependency policy aren\u0027t affected.\u003c/p\u003e"
},
{
"base64": false,
"type": "text/markdown",
"value": "Affects projects that set the `cooldown` config or `HEX_COOLDOWN` and update dependencies with `mix deps.update`, or otherwise unlock the package during resolution. Cooldowns enforced through an organization dependency policy aren\u0027t affected."
}
],
"value": "Affects projects that set the cooldown config or HEX_COOLDOWN and update dependencies with mix deps.update, or otherwise unlock the package during resolution. Cooldowns enforced through an organization dependency policy aren\u0027t affected."
}
],
"cpeApplicability": [
{
"nodes": [
{
"cpeMatch": [
{
"criteria": "cpe:2.3:a:hexpm:hex:*:*:*:*:*:*:*:*",
"versionEndExcluding": "2.5.2",
"versionStartIncluding": "2.5.0",
"vulnerable": true
}
],
"negate": false,
"operator": "OR"
}
],
"operator": "AND"
}
],
"credits": [
{
"lang": "en",
"type": "finder",
"value": "Peter Ullrich"
},
{
"lang": "en",
"type": "remediation developer",
"value": "Eric Meadows-J\u00f6nsson"
},
{
"lang": "en",
"type": "coordinator",
"value": "Eric Meadows-J\u00f6nsson"
},
{
"lang": "en",
"type": "analyst",
"value": "Jonatan M\u00e4nnchen / EEF"
}
],
"dateAssigned": "2026-10-10T13:01:56.000Z",
"descriptions": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003eProtection Mechanism Failure vulnerability in hexpm hex allows the owner of a package, or an attacker who has taken over the owner\u0027s account, to get a newly published release past the release-age cooldown.\u003c/p\u003e\n\u003cp\u003eThe cooldown (\u003ccode\u003ecooldown\u003c/code\u003e config, \u003ccode\u003eHEX_COOLDOWN\u003c/code\u003e) withholds versions younger than the configured age during dependency resolution. When the release of a package locked in \u003ccode\u003emix.lock\u003c/code\u003e is retired or has a security advisory, \u003ccode\u003eHex.RemoteConverger.build_cooldown_bypass/3\u003c/code\u003e and \u003ccode\u003eHex.RemoteConverger.unsafe_lock_bypass/1\u003c/code\u003e lift the cooldown for every version of that package and of every package the locked release depends on, so that \u003ccode\u003emix deps.update\u003c/code\u003e can move off the unsafe release. Retiring a release needs the same package owner permission as publishing one. An attacker who publishes a malicious release can retire the currently locked release, and the next \u003ccode\u003emix deps.update\u003c/code\u003e that unlocks the package selects the new release regardless of its age. \u003ccode\u003eHex.Registry.Cooldown.versions/2\u003c/code\u003e checks the bypass by package name alone, so the bypass also covers packages with the same name in other repositories. Cooldown configured through an organization dependency policy is not affected.\u003c/p\u003e\n\u003cp\u003eThis issue affects hex: from 2.5.0 before 2.5.2.\u003c/p\u003e"
},
{
"base64": false,
"type": "text/markdown",
"value": "Protection Mechanism Failure vulnerability in hexpm hex allows the owner of a package, or an attacker who has taken over the owner\u0027s account, to get a newly published release past the release-age cooldown.\n\nThe cooldown (`cooldown` config, `HEX_COOLDOWN`) withholds versions younger than the configured age during dependency resolution. When the release of a package locked in `mix.lock` is retired or has a security advisory, `Hex.RemoteConverger.build_cooldown_bypass/3` and `Hex.RemoteConverger.unsafe_lock_bypass/1` lift the cooldown for every version of that package and of every package the locked release depends on, so that `mix deps.update` can move off the unsafe release. Retiring a release needs the same package owner permission as publishing one. An attacker who publishes a malicious release can retire the currently locked release, and the next `mix deps.update` that unlocks the package selects the new release regardless of its age. `Hex.Registry.Cooldown.versions/2` checks the bypass by package name alone, so the bypass also covers packages with the same name in other repositories. Cooldown configured through an organization dependency policy is not affected.\n\nThis issue affects hex: from 2.5.0 before 2.5.2."
}
],
"value": "Protection Mechanism Failure vulnerability in hexpm hex allows the owner of a package, or an attacker who has taken over the owner\u0027s account, to get a newly published release past the release-age cooldown.\n\nThe cooldown (cooldown config, HEX_COOLDOWN) withholds versions younger than the configured age during dependency resolution. When the release of a package locked in mix.lock is retired or has a security advisory, Hex.RemoteConverger.build_cooldown_bypass/3 and Hex.RemoteConverger.unsafe_lock_bypass/1 lift the cooldown for every version of that package and of every package the locked release depends on, so that mix deps.update can move off the unsafe release. Retiring a release needs the same package owner permission as publishing one. An attacker who publishes a malicious release can retire the currently locked release, and the next mix deps.update that unlocks the package selects the new release regardless of its age. Hex.Registry.Cooldown.versions/2 checks the bypass by package name alone, so the bypass also covers packages with the same name in other repositories. Cooldown configured through an organization dependency policy is not affected.\n\nThis issue affects hex: from 2.5.0 before 2.5.2."
}
],
"impacts": [
{
"capecId": "CAPEC-538",
"descriptions": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003eThe cooldown exists to keep a compromised release out of projects until it can be detected and retired. An attacker who controls a package owner account can defeat it by also retiring the currently locked release, so a malicious release reaches projects that rely on the local cooldown as soon as they run \u003ccode\u003emix deps.update\u003c/code\u003e, including automated dependency update jobs. The malicious release\u0027s code then runs when the dependency is compiled.\u003c/p\u003e"
},
{
"base64": false,
"type": "text/markdown",
"value": "The cooldown exists to keep a compromised release out of projects until it can be detected and retired. An attacker who controls a package owner account can defeat it by also retiring the currently locked release, so a malicious release reaches projects that rely on the local cooldown as soon as they run `mix deps.update`, including automated dependency update jobs. The malicious release\u0027s code then runs when the dependency is compiled."
}
],
"value": "The cooldown exists to keep a compromised release out of projects until it can be detected and retired. An attacker who controls a package owner account can defeat it by also retiring the currently locked release, so a malicious release reaches projects that rely on the local cooldown as soon as they run mix deps.update, including automated dependency update jobs. The malicious release\u0027s code then runs when the dependency is compiled."
}
]
}
],
"metrics": [
{
"cvssV4_0": {
"Automatable": "NOT_DEFINED",
"Recovery": "NOT_DEFINED",
"Safety": "NOT_DEFINED",
"attackComplexity": "LOW",
"attackRequirements": "PRESENT",
"attackVector": "NETWORK",
"baseScore": 7.1,
"baseSeverity": "HIGH",
"privilegesRequired": "HIGH",
"providerUrgency": "NOT_DEFINED",
"subAvailabilityImpact": "NONE",
"subConfidentialityImpact": "NONE",
"subIntegrityImpact": "NONE",
"userInteraction": "ACTIVE",
"valueDensity": "NOT_DEFINED",
"vectorString": "CVSS:4.0/AV:N/AC:L/AT:P/PR:H/UI:A/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N",
"version": "4.0",
"vulnAvailabilityImpact": "HIGH",
"vulnConfidentialityImpact": "HIGH",
"vulnIntegrityImpact": "HIGH",
"vulnerabilityResponseEffort": "NOT_DEFINED"
},
"format": "CVSS",
"scenarios": [
{
"lang": "en",
"value": "GENERAL"
}
]
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-693",
"description": "CWE-693 Protection Mechanism Failure",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-10-12T15:31:58.926Z",
"orgId": "6b3ad84c-e1a6-4bf7-a703-f496b71e49db",
"shortName": "EEF"
},
"references": [
{
"name": "GitHub Advisory",
"tags": [
"related",
"vendor-advisory"
],
"url": "https://github.com/hexpm/hex/security/advisories/GHSA-pqhp-5x9x-69h7"
},
{
"name": "EEF CNA record for CVE-2026-105668",
"tags": [
"related"
],
"url": "https://cna.erlef.org/cves/CVE-2026-105668.html"
},
{
"name": "OSV record EEF-CVE-2026-105668",
"tags": [
"related"
],
"url": "https://osv.dev/vulnerability/EEF-CVE-2026-105668"
},
{
"name": "Introducing commit b4e665d in hexpm/hex",
"tags": [
"related"
],
"url": "https://github.com/hexpm/hex/commit/b4e665d46be8a5f81e8cbbe4c3a67058a19cf133"
},
{
"name": "Fix commit eed2bdf in hexpm/hex",
"tags": [
"patch"
],
"url": "https://github.com/hexpm/hex/commit/eed2bdf85320ae9e244629511c03f5f3f8c5d0b5"
},
{
"name": "Fix commit 1b6fddf in hexpm/hex",
"tags": [
"patch"
],
"url": "https://github.com/hexpm/hex/commit/1b6fddfeadd98ed26a143f60356efade0494e2ae"
}
],
"solutions": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003eUpgrade Hex to 2.5.2 or later, for example with \u003ccode\u003emix local.hex\u003c/code\u003e. A retired locked release then no longer lifts the release-age cooldown for its package. A locked release with a security advisory still lifts it for its package and the direct dependencies of the locked release, only in the repository the package is locked from.\u003c/p\u003e"
},
{
"base64": false,
"type": "text/markdown",
"value": "Upgrade Hex to 2.5.2 or later, for example with `mix local.hex`. A retired locked release then no longer lifts the release-age cooldown for its package. A locked release with a security advisory still lifts it for its package and the direct dependencies of the locked release, only in the repository the package is locked from."
}
],
"value": "Upgrade Hex to 2.5.2 or later, for example with mix local.hex. A retired locked release then no longer lifts the release-age cooldown for its package. A locked release with a security advisory still lifts it for its package and the direct dependencies of the locked release, only in the repository the package is locked from."
}
],
"source": {
"discovery": "UNKNOWN"
},
"title": "Hex release-age cooldown is lifted package-wide when the locked release is retired",
"workarounds": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003eEnforce the cooldown through an organization dependency policy instead of the local \u003ccode\u003ecooldown\u003c/code\u003e setting, or run \u003ccode\u003emix hex.audit\u003c/code\u003e before \u003ccode\u003emix deps.update\u003c/code\u003e and don\u0027t update a package whose locked release was retired until its replacement has been reviewed.\u003c/p\u003e"
},
{
"base64": false,
"type": "text/markdown",
"value": "Enforce the cooldown through an organization dependency policy instead of the local `cooldown` setting, or run `mix hex.audit` before `mix deps.update` and don\u0027t update a package whose locked release was retired until its replacement has been reviewed."
}
],
"value": "Enforce the cooldown through an organization dependency policy instead of the local cooldown setting, or run mix hex.audit before mix deps.update and don\u0027t update a package whose locked release was retired until its replacement has been reviewed."
}
],
"x_proofOfConcept": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003col\u003e\n\u003cli\u003eLock \u003ccode\u003efoo 1.0.0\u003c/code\u003e in a project with \u003ccode\u003eHEX_COOLDOWN=7d\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003ePublish \u003ccode\u003efoo 1.0.1\u003c/code\u003e; \u003ccode\u003emix deps.update foo\u003c/code\u003e reports it as filtered by cooldown and keeps 1.0.0.\u003c/li\u003e\n\u003cli\u003eRetire \u003ccode\u003efoo 1.0.0\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eRun \u003ccode\u003emix deps.update foo\u003c/code\u003e again; it upgrades to the 1-hour-old 1.0.1.\u003c/li\u003e\n\u003c/ol\u003e"
},
{
"base64": false,
"type": "text/markdown",
"value": "1. Lock `foo 1.0.0` in a project with `HEX_COOLDOWN=7d`.\n2. Publish `foo 1.0.1`; `mix deps.update foo` reports it as filtered by cooldown and keeps 1.0.0.\n3. Retire `foo 1.0.0`.\n4. Run `mix deps.update foo` again; it upgrades to the 1-hour-old 1.0.1."
}
],
"value": "* Lock foo 1.0.0 in a project with HEX_COOLDOWN=7d.\n* Publish foo 1.0.1; mix deps.update foo reports it as filtered by cooldown and keeps 1.0.0.\n* Retire foo 1.0.0.\n* Run mix deps.update foo again; it upgrades to the 1-hour-old 1.0.1."
}
],
"x_technicalAnalysis": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003col\u003e\n\u003cli\u003e\u003ccode\u003eHex.RemoteConverger.build_cooldown_bypass/3\u003c/code\u003e adds \u003ccode\u003eunsafe_lock_bypass(old_lock)\u003c/code\u003e to the set of packages exempt from the cooldown.\u003c/li\u003e\n\u003cli\u003e\u003ccode\u003eunsafe_lock_bypass/1\u003c/code\u003e adds a package\u0027s name, and the names of its locked children, whenever \u003ccode\u003eRegistry.retired/3\u003c/code\u003e or \u003ccode\u003eRegistry.advisories/3\u003c/code\u003e reports the locked version as unsafe.\u003c/li\u003e\n\u003cli\u003e\u003ccode\u003eHex.Registry.Cooldown.versions/2\u003c/code\u003e returns every version unfiltered for any package name in that set, so freshly published versions become eligible as soon as the package is unlocked.\u003c/li\u003e\n\u003cli\u003ehex.pm lets the package owner retire any of their releases, so the owner controls the trigger. \u003ccode\u003eHex.Policy.Filter\u003c/code\u003e applies policy cooldowns without consulting the bypass set.\u003c/li\u003e\n\u003c/ol\u003e"
},
{
"base64": false,
"type": "text/markdown",
"value": "1. `Hex.RemoteConverger.build_cooldown_bypass/3` adds `unsafe_lock_bypass(old_lock)` to the set of packages exempt from the cooldown.\n2. `unsafe_lock_bypass/1` adds a package\u0027s name, and the names of its locked children, whenever `Registry.retired/3` or `Registry.advisories/3` reports the locked version as unsafe.\n3. `Hex.Registry.Cooldown.versions/2` returns every version unfiltered for any package name in that set, so freshly published versions become eligible as soon as the package is unlocked.\n4. hex.pm lets the package owner retire any of their releases, so the owner controls the trigger. `Hex.Policy.Filter` applies policy cooldowns without consulting the bypass set."
}
],
"value": "* Hex.RemoteConverger.build_cooldown_bypass/3 adds unsafe_lock_bypass(old_lock) to the set of packages exempt from the cooldown.\n* unsafe_lock_bypass/1 adds a package\u0027s name, and the names of its locked children, whenever Registry.retired/3 or Registry.advisories/3 reports the locked version as unsafe.\n* Hex.Registry.Cooldown.versions/2 returns every version unfiltered for any package name in that set, so freshly published versions become eligible as soon as the package is unlocked.\n* hex.pm lets the package owner retire any of their releases, so the owner controls the trigger. Hex.Policy.Filter applies policy cooldowns without consulting the bypass set."
}
]
}
},
"cveMetadata": {
"assignerOrgId": "6b3ad84c-e1a6-4bf7-a703-f496b71e49db",
"assignerShortName": "EEF",
"cveId": "CVE-2026-105668",
"datePublished": "2026-10-12T15:31:58.926Z",
"dateReserved": "2026-10-07T22:15:01.885Z",
"dateUpdated": "2026-10-12T15:31:58.926Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
CVE-2026-105280 (GCVE-0-2026-105280)
Vulnerability from cvelistv5 – Published: 2026-10-12 15:30 – Updated: 2026-10-12 15:30
VLAI
EPSS
VEX
Title
Hex writes unverified package tarballs to standard output in mix hex.package fetch
Summary
Improper Validation of Integrity Check Value vulnerability in hexpm hex allows a package mirror to substitute the tarball that mix hex.package fetch PACKAGE VERSION --output - writes to standard output.
Hex compares a fetched tarball's inner and outer checksums with the repository's signed registry before writing it to a file or unpacking it. The standard output branch of mix hex.package fetch writes the bytes returned by Hex.SCM.fetch/3 without that comparison, and Hex.SCM.fetch/3 doesn't verify freshly downloaded tarballs itself. When a mirror configured with HEX_MIRROR_URL or mirror_url serves altered bytes, the command prints them and exits successfully, while the same fetch with --output FILE fails with a checksum mismatch.
Hex also prints diagnostics to standard output while the command runs: the body of a failed HTTP response from the update check or a registry fetch, and API warnings from the x-hex-message header. A mirror that answers one of those requests with an error whose body is a tar archive gets that archive written to standard output ahead of the verified tarball, so a pipeline that unpacks standard output extracts the mirror's files. This happens even when the checksum check then fails, because the archive is already on standard output.
This issue affects hex: from 0.20.2 before 2.5.2.
Severity
CWE
- CWE-354 - Improper Validation of Integrity Check Value
Assigner
References
6 references
Impacted products
{
"containers": {
"cna": {
"affected": [
{
"cpes": [
"cpe:2.3:a:hexpm:hex:*:*:*:*:*:*:*:*"
],
"defaultStatus": "unaffected",
"modules": [
"\u0027Elixir.Mix.Tasks.Hex.Package\u0027",
"\u0027Elixir.Hex.SCM\u0027"
],
"packageName": "hex",
"packageURL": "pkg:otp/hex?repository_url=https:%2F%2Fgithub.com%2Fhexpm%2Fhex\u0026vcs_url=repository_url=git%2Bhttps:%2F%2Fgithub.com%2Fhexpm%2Fhex.git",
"product": "hex",
"programFiles": [
"lib/mix/tasks/hex.package.ex",
"lib/hex/scm.ex"
],
"programRoutines": [
{
"name": "\u0027Elixir.Mix.Tasks.Hex.Package\u0027:run/1"
},
{
"name": "\u0027Elixir.Hex.SCM\u0027:fetch/3"
}
],
"repo": "https://github.com/hexpm/hex",
"vendor": "hexpm",
"versions": [
{
"lessThan": "2.5.2",
"status": "affected",
"version": "0.20.2",
"versionType": "semver"
}
]
},
{
"collectionURL": "https://github.com",
"cpes": [
"cpe:2.3:a:hexpm:hex:*:*:*:*:*:*:*:*"
],
"defaultStatus": "unaffected",
"modules": [
"\u0027Elixir.Mix.Tasks.Hex.Package\u0027",
"\u0027Elixir.Hex.SCM\u0027"
],
"packageName": "hexpm/hex",
"packageURL": "pkg:github/hexpm/hex",
"product": "hex",
"programFiles": [
"lib/mix/tasks/hex.package.ex",
"lib/hex/scm.ex"
],
"programRoutines": [
{
"name": "\u0027Elixir.Mix.Tasks.Hex.Package\u0027:run/1"
},
{
"name": "\u0027Elixir.Hex.SCM\u0027:fetch/3"
}
],
"repo": "https://github.com/hexpm/hex",
"vendor": "hexpm",
"versions": [
{
"changes": [
{
"at": "8a14632ca6ba8a8afd2a3f2098bc267c13e13d93",
"status": "unaffected"
},
{
"at": "69489f8b74213f03db10169e6e5407e6d5fee512",
"status": "unaffected"
}
],
"lessThan": "*",
"status": "affected",
"version": "d1f5a085d9d4748e1f7d195e4bc39ebd77c28d9c",
"versionType": "git"
}
]
}
],
"configurations": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003eAffects \u003ccode\u003emix hex.package fetch\u003c/code\u003e with \u003ccode\u003e--output -\u003c/code\u003e when packages are downloaded through a mirror set with \u003ccode\u003eHEX_MIRROR_URL\u003c/code\u003e or \u003ccode\u003emirror_url\u003c/code\u003e. Downloads directly from the repository over HTTPS aren\u0027t affected unless TLS verification is broken.\u003c/p\u003e"
},
{
"base64": false,
"type": "text/markdown",
"value": "Affects `mix hex.package fetch` with `--output -` when packages are downloaded through a mirror set with `HEX_MIRROR_URL` or `mirror_url`. Downloads directly from the repository over HTTPS aren\u0027t affected unless TLS verification is broken."
}
],
"value": "Affects mix hex.package fetch with --output - when packages are downloaded through a mirror set with HEX_MIRROR_URL or mirror_url. Downloads directly from the repository over HTTPS aren\u0027t affected unless TLS verification is broken."
}
],
"cpeApplicability": [
{
"nodes": [
{
"cpeMatch": [
{
"criteria": "cpe:2.3:a:hexpm:hex:*:*:*:*:*:*:*:*",
"versionEndExcluding": "2.5.2",
"versionStartIncluding": "0.20.2",
"vulnerable": true
}
],
"negate": false,
"operator": "OR"
}
],
"operator": "AND"
}
],
"credits": [
{
"lang": "en",
"type": "finder",
"value": "Peter Ullrich"
},
{
"lang": "en",
"type": "remediation developer",
"value": "Eric Meadows-J\u00f6nsson"
},
{
"lang": "en",
"type": "analyst",
"value": "Jonatan M\u00e4nnchen / EEF"
}
],
"dateAssigned": "2026-10-10T13:01:30.000Z",
"descriptions": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003eImproper Validation of Integrity Check Value vulnerability in hexpm hex allows a package mirror to substitute the tarball that \u003ccode\u003emix hex.package fetch PACKAGE VERSION --output -\u003c/code\u003e writes to standard output.\u003c/p\u003e\n\u003cp\u003eHex compares a fetched tarball\u0027s inner and outer checksums with the repository\u0027s signed registry before writing it to a file or unpacking it. The standard output branch of \u003ccode\u003emix hex.package fetch\u003c/code\u003e writes the bytes returned by \u003ccode\u003eHex.SCM.fetch/3\u003c/code\u003e without that comparison, and \u003ccode\u003eHex.SCM.fetch/3\u003c/code\u003e doesn\u0027t verify freshly downloaded tarballs itself. When a mirror configured with \u003ccode\u003eHEX_MIRROR_URL\u003c/code\u003e or \u003ccode\u003emirror_url\u003c/code\u003e serves altered bytes, the command prints them and exits successfully, while the same fetch with \u003ccode\u003e--output FILE\u003c/code\u003e fails with a checksum mismatch.\u003c/p\u003e\n\u003cp\u003eHex also prints diagnostics to standard output while the command runs: the body of a failed HTTP response from the update check or a registry fetch, and API warnings from the \u003ccode\u003ex-hex-message\u003c/code\u003e header. A mirror that answers one of those requests with an error whose body is a tar archive gets that archive written to standard output ahead of the verified tarball, so a pipeline that unpacks standard output extracts the mirror\u0027s files. This happens even when the checksum check then fails, because the archive is already on standard output.\u003c/p\u003e\n\u003cp\u003eThis issue affects hex: from 0.20.2 before 2.5.2.\u003c/p\u003e"
},
{
"base64": false,
"type": "text/markdown",
"value": "Improper Validation of Integrity Check Value vulnerability in hexpm hex allows a package mirror to substitute the tarball that `mix hex.package fetch PACKAGE VERSION --output -` writes to standard output.\n\nHex compares a fetched tarball\u0027s inner and outer checksums with the repository\u0027s signed registry before writing it to a file or unpacking it. The standard output branch of `mix hex.package fetch` writes the bytes returned by `Hex.SCM.fetch/3` without that comparison, and `Hex.SCM.fetch/3` doesn\u0027t verify freshly downloaded tarballs itself. When a mirror configured with `HEX_MIRROR_URL` or `mirror_url` serves altered bytes, the command prints them and exits successfully, while the same fetch with `--output FILE` fails with a checksum mismatch.\n\nHex also prints diagnostics to standard output while the command runs: the body of a failed HTTP response from the update check or a registry fetch, and API warnings from the `x-hex-message` header. A mirror that answers one of those requests with an error whose body is a tar archive gets that archive written to standard output ahead of the verified tarball, so a pipeline that unpacks standard output extracts the mirror\u0027s files. This happens even when the checksum check then fails, because the archive is already on standard output.\n\nThis issue affects hex: from 0.20.2 before 2.5.2."
}
],
"value": "Improper Validation of Integrity Check Value vulnerability in hexpm hex allows a package mirror to substitute the tarball that mix hex.package fetch PACKAGE VERSION --output - writes to standard output.\n\nHex compares a fetched tarball\u0027s inner and outer checksums with the repository\u0027s signed registry before writing it to a file or unpacking it. The standard output branch of mix hex.package fetch writes the bytes returned by Hex.SCM.fetch/3 without that comparison, and Hex.SCM.fetch/3 doesn\u0027t verify freshly downloaded tarballs itself. When a mirror configured with HEX_MIRROR_URL or mirror_url serves altered bytes, the command prints them and exits successfully, while the same fetch with --output FILE fails with a checksum mismatch.\n\nHex also prints diagnostics to standard output while the command runs: the body of a failed HTTP response from the update check or a registry fetch, and API warnings from the x-hex-message header. A mirror that answers one of those requests with an error whose body is a tar archive gets that archive written to standard output ahead of the verified tarball, so a pipeline that unpacks standard output extracts the mirror\u0027s files. This happens even when the checksum check then fails, because the archive is already on standard output.\n\nThis issue affects hex: from 0.20.2 before 2.5.2."
}
],
"impacts": [
{
"capecId": "CAPEC-186",
"descriptions": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003eHex treats mirrors as untrusted and relies on registry signatures and checksums for package integrity. Scripts that pipe \u003ccode\u003emix hex.package fetch --output -\u003c/code\u003e into another tool, such as an unpacker, a vendoring step or an installer, receive whatever the mirror served, so the mirror operator can deliver modified package contents that downstream steps treat as the published release.\u003c/p\u003e"
},
{
"base64": false,
"type": "text/markdown",
"value": "Hex treats mirrors as untrusted and relies on registry signatures and checksums for package integrity. Scripts that pipe `mix hex.package fetch --output -` into another tool, such as an unpacker, a vendoring step or an installer, receive whatever the mirror served, so the mirror operator can deliver modified package contents that downstream steps treat as the published release."
}
],
"value": "Hex treats mirrors as untrusted and relies on registry signatures and checksums for package integrity. Scripts that pipe mix hex.package fetch --output - into another tool, such as an unpacker, a vendoring step or an installer, receive whatever the mirror served, so the mirror operator can deliver modified package contents that downstream steps treat as the published release."
}
]
}
],
"metrics": [
{
"cvssV4_0": {
"Automatable": "NOT_DEFINED",
"Recovery": "NOT_DEFINED",
"Safety": "NOT_DEFINED",
"attackComplexity": "LOW",
"attackRequirements": "PRESENT",
"attackVector": "NETWORK",
"baseScore": 6.9,
"baseSeverity": "MEDIUM",
"privilegesRequired": "NONE",
"providerUrgency": "NOT_DEFINED",
"subAvailabilityImpact": "NONE",
"subConfidentialityImpact": "NONE",
"subIntegrityImpact": "HIGH",
"userInteraction": "ACTIVE",
"valueDensity": "NOT_DEFINED",
"vectorString": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:A/VC:N/VI:H/VA:N/SC:N/SI:H/SA:N",
"version": "4.0",
"vulnAvailabilityImpact": "NONE",
"vulnConfidentialityImpact": "NONE",
"vulnIntegrityImpact": "HIGH",
"vulnerabilityResponseEffort": "NOT_DEFINED"
},
"format": "CVSS",
"scenarios": [
{
"lang": "en",
"value": "GENERAL"
}
]
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-354",
"description": "CWE-354 Improper Validation of Integrity Check Value",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-10-12T15:30:14.126Z",
"orgId": "6b3ad84c-e1a6-4bf7-a703-f496b71e49db",
"shortName": "EEF"
},
"references": [
{
"name": "GitHub Advisory",
"tags": [
"related",
"vendor-advisory"
],
"url": "https://github.com/hexpm/hex/security/advisories/GHSA-98jr-23pm-vj7c"
},
{
"name": "EEF CNA record for CVE-2026-105280",
"tags": [
"related"
],
"url": "https://cna.erlef.org/cves/CVE-2026-105280.html"
},
{
"name": "OSV record EEF-CVE-2026-105280",
"tags": [
"related"
],
"url": "https://osv.dev/vulnerability/EEF-CVE-2026-105280"
},
{
"name": "Introducing commit d1f5a08 in hexpm/hex",
"tags": [
"related"
],
"url": "https://github.com/hexpm/hex/commit/d1f5a085d9d4748e1f7d195e4bc39ebd77c28d9c"
},
{
"name": "Fix commit 8a14632 in hexpm/hex",
"tags": [
"patch"
],
"url": "https://github.com/hexpm/hex/commit/8a14632ca6ba8a8afd2a3f2098bc267c13e13d93"
},
{
"name": "Fix commit 69489f8 in hexpm/hex",
"tags": [
"patch"
],
"url": "https://github.com/hexpm/hex/commit/69489f8b74213f03db10169e6e5407e6d5fee512"
}
],
"solutions": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003eUpgrade Hex to 2.5.2 or later, for example with \u003ccode\u003emix local.hex\u003c/code\u003e. \u003ccode\u003emix hex.package fetch PACKAGE VERSION --output -\u003c/code\u003e then verifies the registry checksum before writing the tarball to standard output and prints its messages to standard error.\u003c/p\u003e"
},
{
"base64": false,
"type": "text/markdown",
"value": "Upgrade Hex to 2.5.2 or later, for example with `mix local.hex`. `mix hex.package fetch PACKAGE VERSION --output -` then verifies the registry checksum before writing the tarball to standard output and prints its messages to standard error."
}
],
"value": "Upgrade Hex to 2.5.2 or later, for example with mix local.hex. mix hex.package fetch PACKAGE VERSION --output - then verifies the registry checksum before writing the tarball to standard output and prints its messages to standard error."
}
],
"source": {
"discovery": "UNKNOWN"
},
"title": "Hex writes unverified package tarballs to standard output in mix hex.package fetch",
"workarounds": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003eWrite the tarball to a file with \u003ccode\u003e--output FILE\u003c/code\u003e, which verifies the checksums, and read that file instead of standard output.\u003c/p\u003e"
},
{
"base64": false,
"type": "text/markdown",
"value": "Write the tarball to a file with `--output FILE`, which verifies the checksums, and read that file instead of standard output."
}
],
"value": "Write the tarball to a file with --output FILE, which verifies the checksums, and read that file instead of standard output."
}
],
"x_proofOfConcept": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003col\u003e\n\u003cli\u003eSet \u003ccode\u003eHEX_MIRROR_URL\u003c/code\u003e to a server that returns modified bytes for \u003ccode\u003etarballs/decimal-2.4.1.tar\u003c/code\u003e and proxies everything else to repo.hex.pm.\u003c/li\u003e\n\u003cli\u003e\u003ccode\u003emix hex.package fetch decimal 2.4.1 --output -\u003c/code\u003e prints the modified bytes and exits 0.\u003c/li\u003e\n\u003cli\u003e\u003ccode\u003emix hex.package fetch decimal 2.4.1 --output decimal.tar\u003c/code\u003e fails with \u003ccode\u003eChecksum mismatch against registry (outer)\u003c/code\u003e.\u003c/li\u003e\n\u003c/ol\u003e"
},
{
"base64": false,
"type": "text/markdown",
"value": "1. Set `HEX_MIRROR_URL` to a server that returns modified bytes for `tarballs/decimal-2.4.1.tar` and proxies everything else to repo.hex.pm.\n2. `mix hex.package fetch decimal 2.4.1 --output -` prints the modified bytes and exits 0.\n3. `mix hex.package fetch decimal 2.4.1 --output decimal.tar` fails with `Checksum mismatch against registry (outer)`."
}
],
"value": "* Set HEX_MIRROR_URL to a server that returns modified bytes for tarballs/decimal-2.4.1.tar and proxies everything else to repo.hex.pm.\n* mix hex.package fetch decimal 2.4.1 --output - prints the modified bytes and exits 0.\n* mix hex.package fetch decimal 2.4.1 --output decimal.tar fails with Checksum mismatch against registry (outer)."
}
],
"x_technicalAnalysis": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003col\u003e\n\u003cli\u003e\u003ccode\u003emix hex.package fetch PACKAGE VERSION --output -\u003c/code\u003e calls \u003ccode\u003efetch_tarball!/3\u003c/code\u003e, which calls \u003ccode\u003eHex.SCM.fetch/3\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eFor a fresh download, \u003ccode\u003eHex.SCM.fetch/3\u003c/code\u003e writes the response body to the cache and returns it without comparing it to the registry checksum.\u003c/li\u003e\n\u003cli\u003eThe standard output branch passes those bytes to \u003ccode\u003eIO.binwrite/1\u003c/code\u003e. The file and \u003ccode\u003e--unpack\u003c/code\u003e branches call \u003ccode\u003everify_inner_checksum!/4\u003c/code\u003e and \u003ccode\u003everify_outer_checksum!/4\u003c/code\u003e first.\u003c/li\u003e\n\u003cli\u003eWhile the task runs, Hex prints messages with \u003ccode\u003eHex.Shell.info/1\u003c/code\u003e, which writes to standard output. \u003ccode\u003eHex.Utils.print_error_result/1\u003c/code\u003e prints the body of an error response that way; the update checker calls it when its request for \u003ccode\u003einstalls/hex-1.x.csv\u003c/code\u003e fails, and \u003ccode\u003eHex.Registry.Server\u003c/code\u003e calls it when a registry fetch fails and the cached registry is used. \u003ccode\u003eHex.HTTP\u003c/code\u003e prints the \u003ccode\u003ex-hex-message\u003c/code\u003e warning of each response the same way. These are printed before the tarball is written, so the mirror chooses bytes that come before the tarball on standard output.\u003c/li\u003e\n\u003c/ol\u003e"
},
{
"base64": false,
"type": "text/markdown",
"value": "1. `mix hex.package fetch PACKAGE VERSION --output -` calls `fetch_tarball!/3`, which calls `Hex.SCM.fetch/3`.\n2. For a fresh download, `Hex.SCM.fetch/3` writes the response body to the cache and returns it without comparing it to the registry checksum.\n3. The standard output branch passes those bytes to `IO.binwrite/1`. The file and `--unpack` branches call `verify_inner_checksum!/4` and `verify_outer_checksum!/4` first.\n4. While the task runs, Hex prints messages with `Hex.Shell.info/1`, which writes to standard output. `Hex.Utils.print_error_result/1` prints the body of an error response that way; the update checker calls it when its request for `installs/hex-1.x.csv` fails, and `Hex.Registry.Server` calls it when a registry fetch fails and the cached registry is used. `Hex.HTTP` prints the `x-hex-message` warning of each response the same way. These are printed before the tarball is written, so the mirror chooses bytes that come before the tarball on standard output."
}
],
"value": "* mix hex.package fetch PACKAGE VERSION --output - calls fetch_tarball!/3, which calls Hex.SCM.fetch/3.\n* For a fresh download, Hex.SCM.fetch/3 writes the response body to the cache and returns it without comparing it to the registry checksum.\n* The standard output branch passes those bytes to IO.binwrite/1. The file and --unpack branches call verify_inner_checksum!/4 and verify_outer_checksum!/4 first.\n* While the task runs, Hex prints messages with Hex.Shell.info/1, which writes to standard output. Hex.Utils.print_error_result/1 prints the body of an error response that way; the update checker calls it when its request for installs/hex-1.x.csv fails, and Hex.Registry.Server calls it when a registry fetch fails and the cached registry is used. Hex.HTTP prints the x-hex-message warning of each response the same way. These are printed before the tarball is written, so the mirror chooses bytes that come before the tarball on standard output."
}
]
}
},
"cveMetadata": {
"assignerOrgId": "6b3ad84c-e1a6-4bf7-a703-f496b71e49db",
"assignerShortName": "EEF",
"cveId": "CVE-2026-105280",
"datePublished": "2026-10-12T15:30:14.126Z",
"dateReserved": "2026-10-08T13:45:02.134Z",
"dateUpdated": "2026-10-12T15:30:14.126Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
CVE-2026-96618 (GCVE-0-2026-96618)
Vulnerability from cvelistv5 – Published: 2026-10-12 15:29 – Updated: 2026-10-12 15:29
VLAI
EPSS
VEX
Title
Hex exhausts memory and disk on oversized or compressed responses from an untrusted mirror
Summary
Improper Handling of Highly Compressed Data (Data Amplification) vulnerability in hexpm hex allows an untrusted package mirror to exhaust the memory or disk space of the machine running mix deps.get, mix deps.update, mix hex.package fetch or mix hex.docs fetch.
Hex treats a mirror configured with HEX_MIRROR_URL, HEX_MIRROR or mirror_url as untrusted: it doesn't send credentials to it, and it checks registry signatures and package checksums that the mirror can't forge. Several response paths consume memory or disk in proportion to what the mirror sends before any of those checks run.
Hex.HTTP.request/5 reads the whole response body into memory and decompresses it with :zlib.gunzip/1 whenever the response's Content-Encoding contains gzip, with no limit on the compressed or decompressed size. Hex doesn't ask for compressed responses, so the server decides whether this step runs. It applies to registry, package, docs and API responses.
Package tarballs have no download size limit. Hex 2.5.1 holds the whole tarball in memory and writes it to the cache, and the development branch streams it to a temporary file; the 16 MiB tarball limit is checked only when the file is unpacked. The tarball is then unpacked, into deps/<app> in 2.5.1 and into a staging directory on the development branch, before its checksums are compared with the registry.
mix hex.docs fetch, and mix hex.docs offline when docs are missing, write the docs tarball to disk and extract it with :mix_hex_erl_tar.extract/2 without the 16 MiB compressed and 128 MiB decompressed limits that mix_hex_tarball:unpack_docs/3 applies. The signed registry doesn't cover docs tarballs, so nothing checks them.
Registry responses are also decompressed before their signature is checked, in hex_core code that Hex vendors; that part is tracked in https://github.com/hexpm/hex_core/security/advisories/GHSA-7c4r-cgf9-9jmq.
This issue affects hex: from 0.11.2 before 2.5.2.
Severity
CWE
Assigner
References
6 references
Impacted products
{
"containers": {
"cna": {
"affected": [
{
"cpes": [
"cpe:2.3:a:hexpm:hex:*:*:*:*:*:*:*:*"
],
"defaultStatus": "unaffected",
"modules": [
"\u0027Elixir.Hex.HTTP\u0027",
"\u0027Elixir.Hex.SCM\u0027",
"\u0027Elixir.Mix.Tasks.Hex.Docs\u0027"
],
"packageName": "hex",
"packageURL": "pkg:otp/hex?repository_url=https:%2F%2Fgithub.com%2Fhexpm%2Fhex\u0026vcs_url=repository_url=git%2Bhttps:%2F%2Fgithub.com%2Fhexpm%2Fhex.git",
"product": "hex",
"programFiles": [
"lib/hex/http.ex",
"lib/hex/scm.ex",
"lib/mix/tasks/hex.docs.ex"
],
"programRoutines": [
{
"name": "\u0027Elixir.Hex.HTTP\u0027:request/5"
},
{
"name": "\u0027Elixir.Hex.SCM\u0027:fetch/3"
},
{
"name": "\u0027Elixir.Hex.SCM\u0027:update/1"
},
{
"name": "\u0027Elixir.Mix.Tasks.Hex.Docs\u0027:run/1"
}
],
"repo": "https://github.com/hexpm/hex",
"vendor": "hexpm",
"versions": [
{
"lessThan": "2.5.2",
"status": "affected",
"version": "0.11.2",
"versionType": "semver"
}
]
},
{
"collectionURL": "https://github.com",
"cpes": [
"cpe:2.3:a:hexpm:hex:*:*:*:*:*:*:*:*"
],
"defaultStatus": "unaffected",
"modules": [
"\u0027Elixir.Hex.HTTP\u0027",
"\u0027Elixir.Hex.SCM\u0027",
"\u0027Elixir.Mix.Tasks.Hex.Docs\u0027"
],
"packageName": "hexpm/hex",
"packageURL": "pkg:github/hexpm/hex",
"product": "hex",
"programFiles": [
"lib/hex/http.ex",
"lib/hex/scm.ex",
"lib/mix/tasks/hex.docs.ex"
],
"programRoutines": [
{
"name": "\u0027Elixir.Hex.HTTP\u0027:request/5"
},
{
"name": "\u0027Elixir.Hex.SCM\u0027:fetch/3"
},
{
"name": "\u0027Elixir.Hex.SCM\u0027:update/1"
},
{
"name": "\u0027Elixir.Mix.Tasks.Hex.Docs\u0027:run/1"
}
],
"repo": "https://github.com/hexpm/hex",
"vendor": "hexpm",
"versions": [
{
"changes": [
{
"at": "bb5189eade682c5fc3f98d9725973a7beb4e1deb",
"status": "unaffected"
},
{
"at": "08956100a8283ba500a123e5539ac64d5d7e91d8",
"status": "unaffected"
}
],
"lessThan": "*",
"status": "affected",
"version": "51ea632424fb6ea8765148f96dc25dfeb526b1f8",
"versionType": "git"
}
]
}
],
"configurations": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003eAffects users who fetch packages or docs through a mirror set with \u003ccode\u003eHEX_MIRROR_URL\u003c/code\u003e, \u003ccode\u003eHEX_MIRROR\u003c/code\u003e or \u003ccode\u003emirror_url\u003c/code\u003e. Fetches from repo.hex.pm over HTTPS aren\u0027t affected unless TLS verification is broken. A trusted mirror (\u003ccode\u003eHEX_TRUSTED_MIRROR_URL\u003c/code\u003e) or a self-hosted repository can do the same, but Hex already trusts those with credentials.\u003c/p\u003e"
},
{
"base64": false,
"type": "text/markdown",
"value": "Affects users who fetch packages or docs through a mirror set with `HEX_MIRROR_URL`, `HEX_MIRROR` or `mirror_url`. Fetches from repo.hex.pm over HTTPS aren\u0027t affected unless TLS verification is broken. A trusted mirror (`HEX_TRUSTED_MIRROR_URL`) or a self-hosted repository can do the same, but Hex already trusts those with credentials."
}
],
"value": "Affects users who fetch packages or docs through a mirror set with HEX_MIRROR_URL, HEX_MIRROR or mirror_url. Fetches from repo.hex.pm over HTTPS aren\u0027t affected unless TLS verification is broken. A trusted mirror (HEX_TRUSTED_MIRROR_URL) or a self-hosted repository can do the same, but Hex already trusts those with credentials."
}
],
"cpeApplicability": [
{
"nodes": [
{
"cpeMatch": [
{
"criteria": "cpe:2.3:a:hexpm:hex:*:*:*:*:*:*:*:*",
"versionEndExcluding": "2.5.2",
"versionStartIncluding": "0.11.2",
"vulnerable": true
}
],
"negate": false,
"operator": "OR"
}
],
"operator": "AND"
}
],
"credits": [
{
"lang": "en",
"type": "finder",
"value": "Peter Ullrich"
},
{
"lang": "en",
"type": "remediation developer",
"value": "Eric Meadows-J\u00f6nsson"
},
{
"lang": "en",
"type": "analyst",
"value": "Jonatan M\u00e4nnchen / EEF"
}
],
"dateAssigned": "2026-10-10T13:00:30.000Z",
"descriptions": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003eImproper Handling of Highly Compressed Data (Data Amplification) vulnerability in hexpm hex allows an untrusted package mirror to exhaust the memory or disk space of the machine running \u003ccode\u003emix deps.get\u003c/code\u003e, \u003ccode\u003emix deps.update\u003c/code\u003e, \u003ccode\u003emix hex.package fetch\u003c/code\u003e or \u003ccode\u003emix hex.docs fetch\u003c/code\u003e.\u003c/p\u003e\n\u003cp\u003eHex treats a mirror configured with \u003ccode\u003eHEX_MIRROR_URL\u003c/code\u003e, \u003ccode\u003eHEX_MIRROR\u003c/code\u003e or \u003ccode\u003emirror_url\u003c/code\u003e as untrusted: it doesn\u0027t send credentials to it, and it checks registry signatures and package checksums that the mirror can\u0027t forge. Several response paths consume memory or disk in proportion to what the mirror sends before any of those checks run.\u003c/p\u003e\n\u003cp\u003e\u003ccode\u003eHex.HTTP.request/5\u003c/code\u003e reads the whole response body into memory and decompresses it with \u003ccode\u003e:zlib.gunzip/1\u003c/code\u003e whenever the response\u0027s \u003ccode\u003eContent-Encoding\u003c/code\u003e contains \u003ccode\u003egzip\u003c/code\u003e, with no limit on the compressed or decompressed size. Hex doesn\u0027t ask for compressed responses, so the server decides whether this step runs. It applies to registry, package, docs and API responses.\u003c/p\u003e\n\u003cp\u003ePackage tarballs have no download size limit. Hex 2.5.1 holds the whole tarball in memory and writes it to the cache, and the development branch streams it to a temporary file; the 16 MiB tarball limit is checked only when the file is unpacked. The tarball is then unpacked, into \u003ccode\u003edeps/\u0026lt;app\u0026gt;\u003c/code\u003e in 2.5.1 and into a staging directory on the development branch, before its checksums are compared with the registry.\u003c/p\u003e\n\u003cp\u003e\u003ccode\u003emix hex.docs fetch\u003c/code\u003e, and \u003ccode\u003emix hex.docs offline\u003c/code\u003e when docs are missing, write the docs tarball to disk and extract it with \u003ccode\u003e:mix_hex_erl_tar.extract/2\u003c/code\u003e without the 16 MiB compressed and 128 MiB decompressed limits that \u003ccode\u003emix_hex_tarball:unpack_docs/3\u003c/code\u003e applies. The signed registry doesn\u0027t cover docs tarballs, so nothing checks them.\u003c/p\u003e\n\u003cp\u003eRegistry responses are also decompressed before their signature is checked, in hex_core code that Hex vendors; that part is tracked in \u003ca href=\"https://github.com/hexpm/hex_core/security/advisories/GHSA-7c4r-cgf9-9jmq\" rel=\"noopener noreferrer\"\u003ehttps://github.com/hexpm/hex_core/security/advisories/GHSA-7c4r-cgf9-9jmq\u003c/a\u003e.\u003c/p\u003e\n\u003cp\u003eThis issue affects hex: from 0.11.2 before 2.5.2.\u003c/p\u003e"
},
{
"base64": false,
"type": "text/markdown",
"value": "Improper Handling of Highly Compressed Data (Data Amplification) vulnerability in hexpm hex allows an untrusted package mirror to exhaust the memory or disk space of the machine running `mix deps.get`, `mix deps.update`, `mix hex.package fetch` or `mix hex.docs fetch`.\n\nHex treats a mirror configured with `HEX_MIRROR_URL`, `HEX_MIRROR` or `mirror_url` as untrusted: it doesn\u0027t send credentials to it, and it checks registry signatures and package checksums that the mirror can\u0027t forge. Several response paths consume memory or disk in proportion to what the mirror sends before any of those checks run.\n\n`Hex.HTTP.request/5` reads the whole response body into memory and decompresses it with `:zlib.gunzip/1` whenever the response\u0027s `Content-Encoding` contains `gzip`, with no limit on the compressed or decompressed size. Hex doesn\u0027t ask for compressed responses, so the server decides whether this step runs. It applies to registry, package, docs and API responses.\n\nPackage tarballs have no download size limit. Hex 2.5.1 holds the whole tarball in memory and writes it to the cache, and the development branch streams it to a temporary file; the 16 MiB tarball limit is checked only when the file is unpacked. The tarball is then unpacked, into `deps/\u003capp\u003e` in 2.5.1 and into a staging directory on the development branch, before its checksums are compared with the registry.\n\n`mix hex.docs fetch`, and `mix hex.docs offline` when docs are missing, write the docs tarball to disk and extract it with `:mix_hex_erl_tar.extract/2` without the 16 MiB compressed and 128 MiB decompressed limits that `mix_hex_tarball:unpack_docs/3` applies. The signed registry doesn\u0027t cover docs tarballs, so nothing checks them.\n\nRegistry responses are also decompressed before their signature is checked, in hex_core code that Hex vendors; that part is tracked in https://github.com/hexpm/hex_core/security/advisories/GHSA-7c4r-cgf9-9jmq.\n\nThis issue affects hex: from 0.11.2 before 2.5.2."
}
],
"value": "Improper Handling of Highly Compressed Data (Data Amplification) vulnerability in hexpm hex allows an untrusted package mirror to exhaust the memory or disk space of the machine running mix deps.get, mix deps.update, mix hex.package fetch or mix hex.docs fetch.\n\nHex treats a mirror configured with HEX_MIRROR_URL, HEX_MIRROR or mirror_url as untrusted: it doesn\u0027t send credentials to it, and it checks registry signatures and package checksums that the mirror can\u0027t forge. Several response paths consume memory or disk in proportion to what the mirror sends before any of those checks run.\n\nHex.HTTP.request/5 reads the whole response body into memory and decompresses it with :zlib.gunzip/1 whenever the response\u0027s Content-Encoding contains gzip, with no limit on the compressed or decompressed size. Hex doesn\u0027t ask for compressed responses, so the server decides whether this step runs. It applies to registry, package, docs and API responses.\n\nPackage tarballs have no download size limit. Hex 2.5.1 holds the whole tarball in memory and writes it to the cache, and the development branch streams it to a temporary file; the 16 MiB tarball limit is checked only when the file is unpacked. The tarball is then unpacked, into deps/\u003capp\u003e in 2.5.1 and into a staging directory on the development branch, before its checksums are compared with the registry.\n\nmix hex.docs fetch, and mix hex.docs offline when docs are missing, write the docs tarball to disk and extract it with :mix_hex_erl_tar.extract/2 without the 16 MiB compressed and 128 MiB decompressed limits that mix_hex_tarball:unpack_docs/3 applies. The signed registry doesn\u0027t cover docs tarballs, so nothing checks them.\n\nRegistry responses are also decompressed before their signature is checked, in hex_core code that Hex vendors; that part is tracked in https://github.com/hexpm/hex_core/security/advisories/GHSA-7c4r-cgf9-9jmq.\n\nThis issue affects hex: from 0.11.2 before 2.5.2."
}
],
"impacts": [
{
"capecId": "CAPEC-130",
"descriptions": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003eA mirror operator, or an attacker who controls the mirror\u0027s responses, can make Hex allocate memory or write data far larger than what it sent: in tests against Hex main 851b938, a 65 KB gzip-encoded response decompressed to 64 MiB in memory, a 17 MiB tarball was downloaded in full despite the 16 MiB limit, and a 131 KB docs tarball wrote 129 MiB to disk. Larger responses stop the Erlang VM running Mix or fill the disk, failing builds and CI jobs, and a full disk affects other processes on the machine. No package code has to run, and the mirror doesn\u0027t need the repository\u0027s signing key.\u003c/p\u003e"
},
{
"base64": false,
"type": "text/markdown",
"value": "A mirror operator, or an attacker who controls the mirror\u0027s responses, can make Hex allocate memory or write data far larger than what it sent: in tests against Hex main 851b938, a 65 KB gzip-encoded response decompressed to 64 MiB in memory, a 17 MiB tarball was downloaded in full despite the 16 MiB limit, and a 131 KB docs tarball wrote 129 MiB to disk. Larger responses stop the Erlang VM running Mix or fill the disk, failing builds and CI jobs, and a full disk affects other processes on the machine. No package code has to run, and the mirror doesn\u0027t need the repository\u0027s signing key."
}
],
"value": "A mirror operator, or an attacker who controls the mirror\u0027s responses, can make Hex allocate memory or write data far larger than what it sent: in tests against Hex main 851b938, a 65 KB gzip-encoded response decompressed to 64 MiB in memory, a 17 MiB tarball was downloaded in full despite the 16 MiB limit, and a 131 KB docs tarball wrote 129 MiB to disk. Larger responses stop the Erlang VM running Mix or fill the disk, failing builds and CI jobs, and a full disk affects other processes on the machine. No package code has to run, and the mirror doesn\u0027t need the repository\u0027s signing key."
}
]
}
],
"metrics": [
{
"cvssV4_0": {
"Automatable": "NOT_DEFINED",
"Recovery": "NOT_DEFINED",
"Safety": "NOT_DEFINED",
"attackComplexity": "LOW",
"attackRequirements": "PRESENT",
"attackVector": "NETWORK",
"baseScore": 2.1,
"baseSeverity": "LOW",
"privilegesRequired": "NONE",
"providerUrgency": "NOT_DEFINED",
"subAvailabilityImpact": "NONE",
"subConfidentialityImpact": "NONE",
"subIntegrityImpact": "NONE",
"userInteraction": "ACTIVE",
"valueDensity": "NOT_DEFINED",
"vectorString": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:A/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N",
"version": "4.0",
"vulnAvailabilityImpact": "LOW",
"vulnConfidentialityImpact": "NONE",
"vulnIntegrityImpact": "NONE",
"vulnerabilityResponseEffort": "NOT_DEFINED"
},
"format": "CVSS",
"scenarios": [
{
"lang": "en",
"value": "GENERAL"
}
]
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-409",
"description": "CWE-409 Improper Handling of Highly Compressed Data (Data Amplification)",
"lang": "en",
"type": "CWE"
}
]
},
{
"descriptions": [
{
"cweId": "CWE-770",
"description": "CWE-770 Allocation of Resources Without Limits or Throttling",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-10-12T15:29:19.117Z",
"orgId": "6b3ad84c-e1a6-4bf7-a703-f496b71e49db",
"shortName": "EEF"
},
"references": [
{
"name": "GitHub Advisory",
"tags": [
"related",
"vendor-advisory"
],
"url": "https://github.com/hexpm/hex/security/advisories/GHSA-gf42-pg2f-63jp"
},
{
"name": "EEF CNA record for CVE-2026-96618",
"tags": [
"related"
],
"url": "https://cna.erlef.org/cves/CVE-2026-96618.html"
},
{
"name": "OSV record EEF-CVE-2026-96618",
"tags": [
"related"
],
"url": "https://osv.dev/vulnerability/EEF-CVE-2026-96618"
},
{
"name": "Introducing commit 51ea632 in hexpm/hex",
"tags": [
"related"
],
"url": "https://github.com/hexpm/hex/commit/51ea632424fb6ea8765148f96dc25dfeb526b1f8"
},
{
"name": "Fix commit bb5189e in hexpm/hex",
"tags": [
"patch"
],
"url": "https://github.com/hexpm/hex/commit/bb5189eade682c5fc3f98d9725973a7beb4e1deb"
},
{
"name": "Fix commit 0895610 in hexpm/hex",
"tags": [
"patch"
],
"url": "https://github.com/hexpm/hex/commit/08956100a8283ba500a123e5539ac64d5d7e91d8"
}
],
"solutions": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003eUpgrade Hex to 2.5.2 or later, for example with \u003ccode\u003emix local.hex\u003c/code\u003e. Hex then stops downloading a registry file, package, docs tarball or other file from a repository or mirror once it\u0027s larger than 16 MiB, including after decompressing a gzip-encoded response, and checks packages against the registry checksum before writing them to the package cache or unpacking a cached copy.\u003c/p\u003e"
},
{
"base64": false,
"type": "text/markdown",
"value": "Upgrade Hex to 2.5.2 or later, for example with `mix local.hex`. Hex then stops downloading a registry file, package, docs tarball or other file from a repository or mirror once it\u0027s larger than 16 MiB, including after decompressing a gzip-encoded response, and checks packages against the registry checksum before writing them to the package cache or unpacking a cached copy."
}
],
"value": "Upgrade Hex to 2.5.2 or later, for example with mix local.hex. Hex then stops downloading a registry file, package, docs tarball or other file from a repository or mirror once it\u0027s larger than 16 MiB, including after decompressing a gzip-encoded response, and checks packages against the registry checksum before writing them to the package cache or unpacking a cached copy."
}
],
"source": {
"discovery": "UNKNOWN"
},
"title": "Hex exhausts memory and disk on oversized or compressed responses from an untrusted mirror",
"workarounds": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003eFetch from repo.hex.pm or a mirror you operate. Running Mix under operating system memory and disk limits, such as container limits, confines the effect to that container.\u003c/p\u003e"
},
{
"base64": false,
"type": "text/markdown",
"value": "Fetch from repo.hex.pm or a mirror you operate. Running Mix under operating system memory and disk limits, such as container limits, confines the effect to that container."
}
],
"value": "Fetch from repo.hex.pm or a mirror you operate. Running Mix under operating system memory and disk limits, such as container limits, confines the effect to that container."
}
],
"x_proofOfConcept": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003col\u003e\n\u003cli\u003eRun a loopback HTTP server that answers with a 65,255-byte gzip stream decompressing to 64 MiB and \u003ccode\u003eContent-Encoding: gzip\u003c/code\u003e. \u003ccode\u003eHex.HTTP.request(:get, url, %{}, nil)\u003c/code\u003e returns a 67,108,864-byte body; peak RSS was 220 MiB, against 91 MiB for an uncompressed control.\u003c/li\u003e\n\u003cli\u003eServe a 17 MiB file as a package tarball. \u003ccode\u003eHex.Repo.get_tarball/3\u003c/code\u003e returns all of it, and only the following unpack fails with \u003ccode\u003e{:tarball, :too_big}\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eServe a 131,574-byte docs tarball containing a 129 MiB file and set \u003ccode\u003eHEX_MIRROR_URL\u003c/code\u003e to the server. \u003ccode\u003emix hex.docs fetch probe 1.0.0\u003c/code\u003e writes the 129 MiB file and reports success.\u003c/li\u003e\n\u003c/ol\u003e"
},
{
"base64": false,
"type": "text/markdown",
"value": "1. Run a loopback HTTP server that answers with a 65,255-byte gzip stream decompressing to 64 MiB and `Content-Encoding: gzip`. `Hex.HTTP.request(:get, url, %{}, nil)` returns a 67,108,864-byte body; peak RSS was 220 MiB, against 91 MiB for an uncompressed control.\n2. Serve a 17 MiB file as a package tarball. `Hex.Repo.get_tarball/3` returns all of it, and only the following unpack fails with `{:tarball, :too_big}`.\n3. Serve a 131,574-byte docs tarball containing a 129 MiB file and set `HEX_MIRROR_URL` to the server. `mix hex.docs fetch probe 1.0.0` writes the 129 MiB file and reports success."
}
],
"value": "* Run a loopback HTTP server that answers with a 65,255-byte gzip stream decompressing to 64 MiB and Content-Encoding: gzip. Hex.HTTP.request(:get, url, %{}, nil) returns a 67,108,864-byte body; peak RSS was 220 MiB, against 91 MiB for an uncompressed control.\n* Serve a 17 MiB file as a package tarball. Hex.Repo.get_tarball/3 returns all of it, and only the following unpack fails with {:tarball, :too_big}.\n* Serve a 131,574-byte docs tarball containing a 129 MiB file and set HEX_MIRROR_URL to the server. mix hex.docs fetch probe 1.0.0 writes the 129 MiB file and reports success."
}
],
"x_technicalAnalysis": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003col\u003e\n\u003cli\u003e\u003ccode\u003eHex.HTTP.request/5\u003c/code\u003e calls \u003ccode\u003e:httpc.request/5\u003c/code\u003e with \u003ccode\u003ebody_format: :binary\u003c/code\u003e, so the whole body is held in memory, and then calls \u003ccode\u003e:zlib.gunzip/1\u003c/code\u003e when the \u003ccode\u003econtent-encoding\u003c/code\u003e header contains \u003ccode\u003egzip\u003c/code\u003e. Hex doesn\u0027t send \u003ccode\u003eAccept-Encoding\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eWhen \u003ccode\u003emirror_url\u003c/code\u003e is set, \u003ccode\u003eHex.Repo\u003c/code\u003e sends registry, tarball and docs requests to the mirror and marks it untrusted, so no credentials are sent to it.\u003c/li\u003e\n\u003cli\u003eHex 2.5.1: \u003ccode\u003eHex.SCM.fetch/3\u003c/code\u003e writes the body returned by \u003ccode\u003eHex.Repo.get_tarball/3\u003c/code\u003e to the cache. \u003ccode\u003eHex.SCM.update/1\u003c/code\u003e deletes \u003ccode\u003edeps/\u0026lt;app\u0026gt;\u003c/code\u003e, unpacks the tarball into it with \u003ccode\u003eHex.Tar.unpack!/2\u003c/code\u003e and compares the inner and outer checksums afterwards. Development branch: \u003ccode\u003eHex.Repo.get_tarball_to_file/4\u003c/code\u003e streams the tarball to a temporary file without counting bytes; the file is renamed into the cache and unpacked into a staging directory before the checksums are compared.\u003c/li\u003e\n\u003cli\u003e\u003ccode\u003eMix.Tasks.Hex.Docs\u003c/code\u003e writes the body returned by \u003ccode\u003eHex.Repo.get_docs/3\u003c/code\u003e to disk and calls \u003ccode\u003e:mix_hex_erl_tar.extract/2\u003c/code\u003e with \u003ccode\u003e[:compressed, cwd: ...]\u003c/code\u003e and no \u003ccode\u003emax_size\u003c/code\u003e, while \u003ccode\u003emix_hex_tarball:unpack_docs/3\u003c/code\u003e enforces a 16 MiB compressed and 128 MiB decompressed limit.\u003c/li\u003e\n\u003c/ol\u003e"
},
{
"base64": false,
"type": "text/markdown",
"value": "1. `Hex.HTTP.request/5` calls `:httpc.request/5` with `body_format: :binary`, so the whole body is held in memory, and then calls `:zlib.gunzip/1` when the `content-encoding` header contains `gzip`. Hex doesn\u0027t send `Accept-Encoding`.\n2. When `mirror_url` is set, `Hex.Repo` sends registry, tarball and docs requests to the mirror and marks it untrusted, so no credentials are sent to it.\n3. Hex 2.5.1: `Hex.SCM.fetch/3` writes the body returned by `Hex.Repo.get_tarball/3` to the cache. `Hex.SCM.update/1` deletes `deps/\u003capp\u003e`, unpacks the tarball into it with `Hex.Tar.unpack!/2` and compares the inner and outer checksums afterwards. Development branch: `Hex.Repo.get_tarball_to_file/4` streams the tarball to a temporary file without counting bytes; the file is renamed into the cache and unpacked into a staging directory before the checksums are compared.\n4. `Mix.Tasks.Hex.Docs` writes the body returned by `Hex.Repo.get_docs/3` to disk and calls `:mix_hex_erl_tar.extract/2` with `[:compressed, cwd: ...]` and no `max_size`, while `mix_hex_tarball:unpack_docs/3` enforces a 16 MiB compressed and 128 MiB decompressed limit."
}
],
"value": "* Hex.HTTP.request/5 calls :httpc.request/5 with body_format: :binary, so the whole body is held in memory, and then calls :zlib.gunzip/1 when the content-encoding header contains gzip. Hex doesn\u0027t send Accept-Encoding.\n* When mirror_url is set, Hex.Repo sends registry, tarball and docs requests to the mirror and marks it untrusted, so no credentials are sent to it.\n* Hex 2.5.1: Hex.SCM.fetch/3 writes the body returned by Hex.Repo.get_tarball/3 to the cache. Hex.SCM.update/1 deletes deps/\u003capp\u003e, unpacks the tarball into it with Hex.Tar.unpack!/2 and compares the inner and outer checksums afterwards. Development branch: Hex.Repo.get_tarball_to_file/4 streams the tarball to a temporary file without counting bytes; the file is renamed into the cache and unpacked into a staging directory before the checksums are compared.\n* Mix.Tasks.Hex.Docs writes the body returned by Hex.Repo.get_docs/3 to disk and calls :mix_hex_erl_tar.extract/2 with [:compressed, cwd: ...] and no max_size, while mix_hex_tarball:unpack_docs/3 enforces a 16 MiB compressed and 128 MiB decompressed limit."
}
]
}
},
"cveMetadata": {
"assignerOrgId": "6b3ad84c-e1a6-4bf7-a703-f496b71e49db",
"assignerShortName": "EEF",
"cveId": "CVE-2026-96618",
"datePublished": "2026-10-12T15:29:19.117Z",
"dateReserved": "2026-10-10T13:00:02.352Z",
"dateUpdated": "2026-10-12T15:29:19.117Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
CVE-2026-103503 (GCVE-0-2026-103503)
Vulnerability from cvelistv5 – Published: 2026-10-12 15:17 – Updated: 2026-10-12 15:17
VLAI
EPSS
VEX
Title
Hex trusts its bundled CA certificates when cacerts_path is set
Summary
Improper Certificate Validation vulnerability in hexpm hex allows an attacker who can intercept HTTPS connections, and holds a certificate for a Hex host issued by a CA in Hex's bundled CA store, to impersonate that host to users who set cacerts_path to a CA store that leaves that CA out.
cacerts_path (HEX_CACERTS_PATH) is documented as the path to the CA certificate store, used instead of the CA bundle that ships with Hex. Hex.HTTP.SSL.ssl_opts/1 passes the configured store as the cacerts option, but builds the partial_chain callback from the bundled store whether cacerts_path is set or not. Hex.HTTP.SSL.partial_chain/2 accepts a server chain when any certificate in it has the same public key as a bundled CA certificate, so a chain that leads to a bundled CA passes verification although the configured store doesn't contain that CA. Hostname verification still applies.
This issue affects hex: from 0.20.2 before 2.5.2.
Severity
CWE
- CWE-295 - Improper Certificate Validation
Assigner
References
6 references
Impacted products
{
"containers": {
"cna": {
"affected": [
{
"cpes": [
"cpe:2.3:a:hexpm:hex:*:*:*:*:*:*:*:*"
],
"defaultStatus": "unaffected",
"modules": [
"\u0027Elixir.Hex.HTTP.SSL\u0027"
],
"packageName": "hex",
"packageURL": "pkg:otp/hex?repository_url=https:%2F%2Fgithub.com%2Fhexpm%2Fhex\u0026vcs_url=repository_url=git%2Bhttps:%2F%2Fgithub.com%2Fhexpm%2Fhex.git",
"product": "hex",
"programFiles": [
"lib/hex/http/ssl.ex"
],
"programRoutines": [
{
"name": "\u0027Elixir.Hex.HTTP.SSL\u0027:ssl_opts/1"
},
{
"name": "\u0027Elixir.Hex.HTTP.SSL\u0027:partial_chain/2"
}
],
"repo": "https://github.com/hexpm/hex",
"vendor": "hexpm",
"versions": [
{
"lessThan": "2.5.2",
"status": "affected",
"version": "0.20.2",
"versionType": "semver"
}
]
},
{
"collectionURL": "https://github.com",
"cpes": [
"cpe:2.3:a:hexpm:hex:*:*:*:*:*:*:*:*"
],
"defaultStatus": "unaffected",
"modules": [
"\u0027Elixir.Hex.HTTP.SSL\u0027"
],
"packageName": "hexpm/hex",
"packageURL": "pkg:github/hexpm/hex",
"product": "hex",
"programFiles": [
"lib/hex/http/ssl.ex"
],
"programRoutines": [
{
"name": "\u0027Elixir.Hex.HTTP.SSL\u0027:ssl_opts/1"
},
{
"name": "\u0027Elixir.Hex.HTTP.SSL\u0027:partial_chain/2"
}
],
"repo": "https://github.com/hexpm/hex",
"vendor": "hexpm",
"versions": [
{
"changes": [
{
"at": "5f5a2136c7cf5991b6e8a30d645ca9f8e74b0785",
"status": "unaffected"
},
{
"at": "6232a6498015e559743bec4f4fbec9138837cec8",
"status": "unaffected"
}
],
"lessThan": "*",
"status": "affected",
"version": "c9b26a46928bfcd546773571e09c1d05f4cd9fb7",
"versionType": "git"
}
]
}
],
"configurations": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003eAffects users who set \u003ccode\u003ecacerts_path\u003c/code\u003e or \u003ccode\u003eHEX_CACERTS_PATH\u003c/code\u003e to a CA store that leaves out some of the CAs bundled with Hex. Users who don\u0027t set it trust the bundled store already and aren\u0027t affected.\u003c/p\u003e"
},
{
"base64": false,
"type": "text/markdown",
"value": "Affects users who set `cacerts_path` or `HEX_CACERTS_PATH` to a CA store that leaves out some of the CAs bundled with Hex. Users who don\u0027t set it trust the bundled store already and aren\u0027t affected."
}
],
"value": "Affects users who set cacerts_path or HEX_CACERTS_PATH to a CA store that leaves out some of the CAs bundled with Hex. Users who don\u0027t set it trust the bundled store already and aren\u0027t affected."
}
],
"cpeApplicability": [
{
"nodes": [
{
"cpeMatch": [
{
"criteria": "cpe:2.3:a:hexpm:hex:*:*:*:*:*:*:*:*",
"versionEndExcluding": "2.5.2",
"versionStartIncluding": "0.20.2",
"vulnerable": true
}
],
"negate": false,
"operator": "OR"
}
],
"operator": "AND"
}
],
"credits": [
{
"lang": "en",
"type": "finder",
"value": "Peter Ullrich"
},
{
"lang": "en",
"type": "remediation developer",
"value": "Eric Meadows-J\u00f6nsson"
},
{
"lang": "en",
"type": "analyst",
"value": "Jonatan M\u00e4nnchen / EEF"
}
],
"dateAssigned": "2026-10-10T12:59:48.000Z",
"descriptions": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003eImproper Certificate Validation vulnerability in hexpm hex allows an attacker who can intercept HTTPS connections, and holds a certificate for a Hex host issued by a CA in Hex\u0027s bundled CA store, to impersonate that host to users who set \u003ccode\u003ecacerts_path\u003c/code\u003e to a CA store that leaves that CA out.\u003c/p\u003e\n\u003cp\u003e\u003ccode\u003ecacerts_path\u003c/code\u003e (\u003ccode\u003eHEX_CACERTS_PATH\u003c/code\u003e) is documented as the path to the CA certificate store, used instead of the CA bundle that ships with Hex. \u003ccode\u003eHex.HTTP.SSL.ssl_opts/1\u003c/code\u003e passes the configured store as the \u003ccode\u003ecacerts\u003c/code\u003e option, but builds the \u003ccode\u003epartial_chain\u003c/code\u003e callback from the bundled store whether \u003ccode\u003ecacerts_path\u003c/code\u003e is set or not. \u003ccode\u003eHex.HTTP.SSL.partial_chain/2\u003c/code\u003e accepts a server chain when any certificate in it has the same public key as a bundled CA certificate, so a chain that leads to a bundled CA passes verification although the configured store doesn\u0027t contain that CA. Hostname verification still applies.\u003c/p\u003e\n\u003cp\u003eThis issue affects hex: from 0.20.2 before 2.5.2.\u003c/p\u003e"
},
{
"base64": false,
"type": "text/markdown",
"value": "Improper Certificate Validation vulnerability in hexpm hex allows an attacker who can intercept HTTPS connections, and holds a certificate for a Hex host issued by a CA in Hex\u0027s bundled CA store, to impersonate that host to users who set `cacerts_path` to a CA store that leaves that CA out.\n\n`cacerts_path` (`HEX_CACERTS_PATH`) is documented as the path to the CA certificate store, used instead of the CA bundle that ships with Hex. `Hex.HTTP.SSL.ssl_opts/1` passes the configured store as the `cacerts` option, but builds the `partial_chain` callback from the bundled store whether `cacerts_path` is set or not. `Hex.HTTP.SSL.partial_chain/2` accepts a server chain when any certificate in it has the same public key as a bundled CA certificate, so a chain that leads to a bundled CA passes verification although the configured store doesn\u0027t contain that CA. Hostname verification still applies.\n\nThis issue affects hex: from 0.20.2 before 2.5.2."
}
],
"value": "Improper Certificate Validation vulnerability in hexpm hex allows an attacker who can intercept HTTPS connections, and holds a certificate for a Hex host issued by a CA in Hex\u0027s bundled CA store, to impersonate that host to users who set cacerts_path to a CA store that leaves that CA out.\n\ncacerts_path (HEX_CACERTS_PATH) is documented as the path to the CA certificate store, used instead of the CA bundle that ships with Hex. Hex.HTTP.SSL.ssl_opts/1 passes the configured store as the cacerts option, but builds the partial_chain callback from the bundled store whether cacerts_path is set or not. Hex.HTTP.SSL.partial_chain/2 accepts a server chain when any certificate in it has the same public key as a bundled CA certificate, so a chain that leads to a bundled CA passes verification although the configured store doesn\u0027t contain that CA. Hostname verification still applies.\n\nThis issue affects hex: from 0.20.2 before 2.5.2."
}
],
"impacts": [
{
"capecId": "CAPEC-94",
"descriptions": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003eUsers set \u003ccode\u003ecacerts_path\u003c/code\u003e to limit which CAs can authenticate Hex\u0027s servers, for example to their organization\u0027s internal CA. Every CA in Hex\u0027s bundled store can still authenticate those servers, so a certificate mis-issued by one of those CAs, or obtained through compromised domain validation, lets an attacker on the network path impersonate hex.pm, repo.hex.pm, a self-hosted repository or a mirror. The attacker receives the API keys, OAuth tokens and repository keys Hex sends, and can alter API responses. Registry signatures and package checksums still prevent changes to registry contents and packages.\u003c/p\u003e"
},
{
"base64": false,
"type": "text/markdown",
"value": "Users set `cacerts_path` to limit which CAs can authenticate Hex\u0027s servers, for example to their organization\u0027s internal CA. Every CA in Hex\u0027s bundled store can still authenticate those servers, so a certificate mis-issued by one of those CAs, or obtained through compromised domain validation, lets an attacker on the network path impersonate hex.pm, repo.hex.pm, a self-hosted repository or a mirror. The attacker receives the API keys, OAuth tokens and repository keys Hex sends, and can alter API responses. Registry signatures and package checksums still prevent changes to registry contents and packages."
}
],
"value": "Users set cacerts_path to limit which CAs can authenticate Hex\u0027s servers, for example to their organization\u0027s internal CA. Every CA in Hex\u0027s bundled store can still authenticate those servers, so a certificate mis-issued by one of those CAs, or obtained through compromised domain validation, lets an attacker on the network path impersonate hex.pm, repo.hex.pm, a self-hosted repository or a mirror. The attacker receives the API keys, OAuth tokens and repository keys Hex sends, and can alter API responses. Registry signatures and package checksums still prevent changes to registry contents and packages."
}
]
}
],
"metrics": [
{
"cvssV4_0": {
"Automatable": "NOT_DEFINED",
"Recovery": "NOT_DEFINED",
"Safety": "NOT_DEFINED",
"attackComplexity": "HIGH",
"attackRequirements": "PRESENT",
"attackVector": "NETWORK",
"baseScore": 5.9,
"baseSeverity": "MEDIUM",
"privilegesRequired": "NONE",
"providerUrgency": "NOT_DEFINED",
"subAvailabilityImpact": "NONE",
"subConfidentialityImpact": "NONE",
"subIntegrityImpact": "NONE",
"userInteraction": "ACTIVE",
"valueDensity": "NOT_DEFINED",
"vectorString": "CVSS:4.0/AV:N/AC:H/AT:P/PR:N/UI:A/VC:H/VI:L/VA:N/SC:N/SI:N/SA:N",
"version": "4.0",
"vulnAvailabilityImpact": "NONE",
"vulnConfidentialityImpact": "HIGH",
"vulnIntegrityImpact": "LOW",
"vulnerabilityResponseEffort": "NOT_DEFINED"
},
"format": "CVSS",
"scenarios": [
{
"lang": "en",
"value": "GENERAL"
}
]
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-295",
"description": "CWE-295 Improper Certificate Validation",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-10-12T15:17:45.545Z",
"orgId": "6b3ad84c-e1a6-4bf7-a703-f496b71e49db",
"shortName": "EEF"
},
"references": [
{
"name": "GitHub Advisory",
"tags": [
"related",
"vendor-advisory"
],
"url": "https://github.com/hexpm/hex/security/advisories/GHSA-rw8q-hg7m-cxgr"
},
{
"name": "EEF CNA record for CVE-2026-103503",
"tags": [
"related"
],
"url": "https://cna.erlef.org/cves/CVE-2026-103503.html"
},
{
"name": "OSV record EEF-CVE-2026-103503",
"tags": [
"related"
],
"url": "https://osv.dev/vulnerability/EEF-CVE-2026-103503"
},
{
"name": "Introducing commit c9b26a4 in hexpm/hex",
"tags": [
"related"
],
"url": "https://github.com/hexpm/hex/commit/c9b26a46928bfcd546773571e09c1d05f4cd9fb7"
},
{
"name": "Fix commit 5f5a213 in hexpm/hex",
"tags": [
"patch"
],
"url": "https://github.com/hexpm/hex/commit/5f5a2136c7cf5991b6e8a30d645ca9f8e74b0785"
},
{
"name": "Fix commit 6232a64 in hexpm/hex",
"tags": [
"patch"
],
"url": "https://github.com/hexpm/hex/commit/6232a6498015e559743bec4f4fbec9138837cec8"
}
],
"solutions": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003eUpgrade Hex to 2.5.2 or later, for example with \u003ccode\u003emix local.hex\u003c/code\u003e. With \u003ccode\u003ecacerts_path\u003c/code\u003e (\u003ccode\u003eHEX_CACERTS_PATH\u003c/code\u003e) set, Hex then only accepts server certificates that chain to a CA in that file, and it doesn\u0027t trust copies of CA certificates sent by the server.\u003c/p\u003e"
},
{
"base64": false,
"type": "text/markdown",
"value": "Upgrade Hex to 2.5.2 or later, for example with `mix local.hex`. With `cacerts_path` (`HEX_CACERTS_PATH`) set, Hex then only accepts server certificates that chain to a CA in that file, and it doesn\u0027t trust copies of CA certificates sent by the server."
}
],
"value": "Upgrade Hex to 2.5.2 or later, for example with mix local.hex. With cacerts_path (HEX_CACERTS_PATH) set, Hex then only accepts server certificates that chain to a CA in that file, and it doesn\u0027t trust copies of CA certificates sent by the server."
}
],
"source": {
"discovery": "UNKNOWN"
},
"title": "Hex trusts its bundled CA certificates when cacerts_path is set",
"workarounds": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003eThere\u0027s no Hex configuration that stops the bundled CAs from being trusted.\u003c/p\u003e"
},
{
"base64": false,
"type": "text/markdown",
"value": "There\u0027s no Hex configuration that stops the bundled CAs from being trusted."
}
],
"value": "There\u0027s no Hex configuration that stops the bundled CAs from being trusted."
}
],
"x_proofOfConcept": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003col\u003e\n\u003cli\u003eCreate a PEM file that contains only an unrelated test CA certificate and set \u003ccode\u003ecacerts_path\u003c/code\u003e to it.\u003c/li\u003e\n\u003cli\u003eOpen a TLS connection to hex.pm with the options from \u003ccode\u003eHex.HTTP.SSL.ssl_opts(\"https://hex.pm\")\u003c/code\u003e. The handshake succeeds, and the accepted chain leads to ISRG Root X2 cross-signed by ISRG Root X1, neither of which is in the PEM file.\u003c/li\u003e\n\u003cli\u003eRemove the \u003ccode\u003epartial_chain\u003c/code\u003e option and connect again. The handshake fails with \u003ccode\u003eunknown_ca\u003c/code\u003e.\u003c/li\u003e\n\u003c/ol\u003e"
},
{
"base64": false,
"type": "text/markdown",
"value": "1. Create a PEM file that contains only an unrelated test CA certificate and set `cacerts_path` to it.\n2. Open a TLS connection to hex.pm with the options from `Hex.HTTP.SSL.ssl_opts(\"https://hex.pm\")`. The handshake succeeds, and the accepted chain leads to ISRG Root X2 cross-signed by ISRG Root X1, neither of which is in the PEM file.\n3. Remove the `partial_chain` option and connect again. The handshake fails with `unknown_ca`."
}
],
"value": "* Create a PEM file that contains only an unrelated test CA certificate and set cacerts_path to it.\n* Open a TLS connection to hex.pm with the options from Hex.HTTP.SSL.ssl_opts(\"https://hex.pm\"). The handshake succeeds, and the accepted chain leads to ISRG Root X2 cross-signed by ISRG Root X1, neither of which is in the PEM file.\n* Remove the partial_chain option and connect again. The handshake fails with unknown_ca."
}
],
"x_technicalAnalysis": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003col\u003e\n\u003cli\u003e\u003ccode\u003eHex.HTTP.SSL.get_ca_certs/0\u003c/code\u003e returns the certificates from \u003ccode\u003ecacerts_path\u003c/code\u003e when it\u0027s set, and \u003ccode\u003essl_opts/1\u003c/code\u003e passes them as \u003ccode\u003ecacerts\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003e\u003ccode\u003essl_opts/1\u003c/code\u003e sets \u003ccode\u003epartial_chain\u003c/code\u003e to \u003ccode\u003e\u0026amp;partial_chain(Certs.cacerts(), \u0026amp;1)\u003c/code\u003e, which always uses the bundled store.\u003c/li\u003e\n\u003cli\u003eWhen the server\u0027s chain doesn\u0027t lead to a certificate in \u003ccode\u003ecacerts\u003c/code\u003e, OTP calls \u003ccode\u003epartial_chain\u003c/code\u003e with the chain. \u003ccode\u003epartial_chain/2\u003c/code\u003e returns \u003ccode\u003e{:trusted_ca, der}\u003c/code\u003e for the first certificate whose public key matches a bundled CA certificate, and OTP validates the chain with that certificate as the trust anchor.\u003c/li\u003e\n\u003cli\u003eChain validation and the hostname check from \u003ccode\u003ecustomize_hostname_check/1\u003c/code\u003e still run, so the attacker needs a certificate for the requested host that chains to a bundled CA.\u003c/li\u003e\n\u003c/ol\u003e"
},
{
"base64": false,
"type": "text/markdown",
"value": "1. `Hex.HTTP.SSL.get_ca_certs/0` returns the certificates from `cacerts_path` when it\u0027s set, and `ssl_opts/1` passes them as `cacerts`.\n2. `ssl_opts/1` sets `partial_chain` to `\u0026partial_chain(Certs.cacerts(), \u00261)`, which always uses the bundled store.\n3. When the server\u0027s chain doesn\u0027t lead to a certificate in `cacerts`, OTP calls `partial_chain` with the chain. `partial_chain/2` returns `{:trusted_ca, der}` for the first certificate whose public key matches a bundled CA certificate, and OTP validates the chain with that certificate as the trust anchor.\n4. Chain validation and the hostname check from `customize_hostname_check/1` still run, so the attacker needs a certificate for the requested host that chains to a bundled CA."
}
],
"value": "* Hex.HTTP.SSL.get_ca_certs/0 returns the certificates from cacerts_path when it\u0027s set, and ssl_opts/1 passes them as cacerts.\n* ssl_opts/1 sets partial_chain to \u0026partial_chain(Certs.cacerts(), \u00261), which always uses the bundled store.\n* When the server\u0027s chain doesn\u0027t lead to a certificate in cacerts, OTP calls partial_chain with the chain. partial_chain/2 returns {:trusted_ca, der} for the first certificate whose public key matches a bundled CA certificate, and OTP validates the chain with that certificate as the trust anchor.\n* Chain validation and the hostname check from customize_hostname_check/1 still run, so the attacker needs a certificate for the requested host that chains to a bundled CA."
}
]
}
},
"cveMetadata": {
"assignerOrgId": "6b3ad84c-e1a6-4bf7-a703-f496b71e49db",
"assignerShortName": "EEF",
"cveId": "CVE-2026-103503",
"datePublished": "2026-10-12T15:17:45.545Z",
"dateReserved": "2026-10-08T15:45:02.372Z",
"dateUpdated": "2026-10-12T15:17:45.545Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
CVE-2026-103502 (GCVE-0-2026-103502)
Vulnerability from cvelistv5 – Published: 2026-10-12 13:15 – Updated: 2026-10-12 13:15
VLAI
EPSS
VEX
Title
hex_core's default HTTP adapter doesn't verify TLS certificates on OTP 24 and 25
Summary
Improper Certificate Validation vulnerability in hexpm hex_core allows an attacker who can intercept HTTPS connections to impersonate hex.pm, repo.hex.pm or any other repository or API server to programs that use hex_core's default HTTP adapter on Erlang/OTP 24, or on OTP 25 when the operating system's CA certificates can't be loaded.
hex_core:default_config/0 selects the built-in hex_http_httpc adapter. For an HTTPS request whose adapter config has no ssl option, hex_http_httpc:http_options/2 builds options that verify the server certificate against public_key:cacerts_get/0. When that call raises, the adapter prints a warning and sends the request without ssl options, so httpc uses the defaults of the ssl application, which before OTP 26 don't verify the server certificate. public_key:cacerts_get/0 doesn't exist on OTP 24, so every HTTPS request falls back there, and on OTP 25 it raises when no CA store is found. hex_core versions before 0.11.0 never set ssl options, so they don't verify the server certificate on OTP 25 and earlier whether or not a CA store is found.
The fallback was intended and documented, but the documentation didn't make clear that it meant no certificate verification. Since hex_core 0.8.2 the README has warned that the built-in httpc adapter "has insecure default settings" and recommended other HTTP clients, and the adapter prints "using default ssl options which are insecure" on every request that falls back. hex_core 0.11.0 added certificate verification with the changelog entry "Use secure SSL defaults for OTP 25+". Neither the README nor the warning says that the server certificate isn't verified, the README doesn't say which OTP versions the warning applies to, and on OTP 25 without CA certificates the warning tells users to upgrade to OTP 25 or later, which they already run. This advisory is published so that users who took those notices as general advice know their HTTPS requests weren't authenticated.
This issue affects hex_core: from 0.1.0 before 0.20.0.
Severity
Assigner
References
5 references
| URL | Tags |
|---|---|
| https://github.com/hexpm/hex_core/security/adviso… | relatedvendor-advisory |
| https://cna.erlef.org/cves/CVE-2026-103502.html | related |
| https://osv.dev/vulnerability/EEF-CVE-2026-103502 | related |
| https://github.com/hexpm/hex_core/commit/fbb6d9de… | related |
| https://github.com/hexpm/hex_core/commit/b7b3a42d… | patch |
Impacted products
{
"containers": {
"cna": {
"affected": [
{
"collectionURL": "https://repo.hex.pm",
"cpes": [
"cpe:2.3:a:hexpm:hex_core:*:*:*:*:*:*:*:*"
],
"defaultStatus": "unaffected",
"modules": [
"hex_http_httpc"
],
"packageName": "hex_core",
"packageURL": "pkg:hex/hex_core",
"product": "hex_core",
"programFiles": [
"src/hex_http_httpc.erl"
],
"programRoutines": [
{
"name": "hex_http_httpc:request/5"
},
{
"name": "hex_http_httpc:request_to_file/6"
}
],
"repo": "https://github.com/hexpm/hex_core",
"vendor": "hexpm",
"versions": [
{
"lessThan": "0.20.0",
"status": "affected",
"version": "0.1.0",
"versionType": "semver"
}
]
},
{
"collectionURL": "https://github.com",
"cpes": [
"cpe:2.3:a:hexpm:hex_core:*:*:*:*:*:*:*:*"
],
"defaultStatus": "unaffected",
"modules": [
"hex_http_httpc"
],
"packageName": "hexpm/hex_core",
"packageURL": "pkg:github/hexpm/hex_core",
"product": "hex_core",
"programFiles": [
"src/hex_http_httpc.erl"
],
"programRoutines": [
{
"name": "hex_http_httpc:request/5"
},
{
"name": "hex_http_httpc:request_to_file/6"
}
],
"repo": "https://github.com/hexpm/hex_core",
"vendor": "hexpm",
"versions": [
{
"lessThan": "b7b3a42defb4ed8e20a5c68a4412ce68a95b7938",
"status": "affected",
"version": "fbb6d9de472e5edb8d6fb6b32a91cb266137892e",
"versionType": "git"
}
]
}
],
"configurations": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003eAffects programs that use the \u003ccode\u003ehex_http_httpc\u003c/code\u003e adapter, the default in \u003ccode\u003ehex_core:default_config/0\u003c/code\u003e, without an \u003ccode\u003essl\u003c/code\u003e option in the adapter\u0027s \u003ccode\u003ehttp_options\u003c/code\u003e, on OTP 24, or on OTP 25 when \u003ccode\u003epublic_key:cacerts_get/0\u003c/code\u003e fails. hex_core versions before 0.11.0 are affected on OTP 25 and earlier whether or not the CA certificates load. On OTP 26 and later the \u003ccode\u003essl\u003c/code\u003e defaults verify the server certificate. Hex and rebar3 vendor hex_core but configure their own HTTP adapters, so they aren\u0027t affected.\u003c/p\u003e"
},
{
"base64": false,
"type": "text/markdown",
"value": "Affects programs that use the `hex_http_httpc` adapter, the default in `hex_core:default_config/0`, without an `ssl` option in the adapter\u0027s `http_options`, on OTP 24, or on OTP 25 when `public_key:cacerts_get/0` fails. hex_core versions before 0.11.0 are affected on OTP 25 and earlier whether or not the CA certificates load. On OTP 26 and later the `ssl` defaults verify the server certificate. Hex and rebar3 vendor hex_core but configure their own HTTP adapters, so they aren\u0027t affected."
}
],
"value": "Affects programs that use the hex_http_httpc adapter, the default in hex_core:default_config/0, without an ssl option in the adapter\u0027s http_options, on OTP 24, or on OTP 25 when public_key:cacerts_get/0 fails. hex_core versions before 0.11.0 are affected on OTP 25 and earlier whether or not the CA certificates load. On OTP 26 and later the ssl defaults verify the server certificate. Hex and rebar3 vendor hex_core but configure their own HTTP adapters, so they aren\u0027t affected."
}
],
"cpeApplicability": [
{
"nodes": [
{
"cpeMatch": [
{
"criteria": "cpe:2.3:a:hexpm:hex_core:*:*:*:*:*:*:*:*",
"versionEndExcluding": "0.20.0",
"versionStartIncluding": "0.1.0",
"vulnerable": true
}
],
"negate": false,
"operator": "OR"
}
],
"operator": "AND"
}
],
"credits": [
{
"lang": "en",
"type": "finder",
"value": "Peter Ullrich"
},
{
"lang": "en",
"type": "remediation developer",
"value": "Eric Meadows-J\u00f6nsson"
},
{
"lang": "en",
"type": "analyst",
"value": "Jonatan M\u00e4nnchen / EEF"
}
],
"dateAssigned": "2026-10-10T12:59:18.000Z",
"descriptions": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003eImproper Certificate Validation vulnerability in hexpm hex_core allows an attacker who can intercept HTTPS connections to impersonate hex.pm, repo.hex.pm or any other repository or API server to programs that use hex_core\u0027s default HTTP adapter on Erlang/OTP 24, or on OTP 25 when the operating system\u0027s CA certificates can\u0027t be loaded.\u003c/p\u003e\n\u003cp\u003e\u003ccode\u003ehex_core:default_config/0\u003c/code\u003e selects the built-in \u003ccode\u003ehex_http_httpc\u003c/code\u003e adapter. For an HTTPS request whose adapter config has no \u003ccode\u003essl\u003c/code\u003e option, \u003ccode\u003ehex_http_httpc:http_options/2\u003c/code\u003e builds options that verify the server certificate against \u003ccode\u003epublic_key:cacerts_get/0\u003c/code\u003e. When that call raises, the adapter prints a warning and sends the request without \u003ccode\u003essl\u003c/code\u003e options, so httpc uses the defaults of the \u003ccode\u003essl\u003c/code\u003e application, which before OTP 26 don\u0027t verify the server certificate. \u003ccode\u003epublic_key:cacerts_get/0\u003c/code\u003e doesn\u0027t exist on OTP 24, so every HTTPS request falls back there, and on OTP 25 it raises when no CA store is found. hex_core versions before 0.11.0 never set \u003ccode\u003essl\u003c/code\u003e options, so they don\u0027t verify the server certificate on OTP 25 and earlier whether or not a CA store is found.\u003c/p\u003e\n\u003cp\u003eThe fallback was intended and documented, but the documentation didn\u0027t make clear that it meant no certificate verification. Since hex_core 0.8.2 the README has warned that the built-in httpc adapter \"has insecure default settings\" and recommended other HTTP clients, and the adapter prints \"using default ssl options which are insecure\" on every request that falls back. hex_core 0.11.0 added certificate verification with the changelog entry \"Use secure SSL defaults for OTP 25+\". Neither the README nor the warning says that the server certificate isn\u0027t verified, the README doesn\u0027t say which OTP versions the warning applies to, and on OTP 25 without CA certificates the warning tells users to upgrade to OTP 25 or later, which they already run. This advisory is published so that users who took those notices as general advice know their HTTPS requests weren\u0027t authenticated.\u003c/p\u003e\n\u003cp\u003eThis issue affects hex_core: from 0.1.0 before 0.20.0.\u003c/p\u003e"
},
{
"base64": false,
"type": "text/markdown",
"value": "Improper Certificate Validation vulnerability in hexpm hex_core allows an attacker who can intercept HTTPS connections to impersonate hex.pm, repo.hex.pm or any other repository or API server to programs that use hex_core\u0027s default HTTP adapter on Erlang/OTP 24, or on OTP 25 when the operating system\u0027s CA certificates can\u0027t be loaded.\n\n`hex_core:default_config/0` selects the built-in `hex_http_httpc` adapter. For an HTTPS request whose adapter config has no `ssl` option, `hex_http_httpc:http_options/2` builds options that verify the server certificate against `public_key:cacerts_get/0`. When that call raises, the adapter prints a warning and sends the request without `ssl` options, so httpc uses the defaults of the `ssl` application, which before OTP 26 don\u0027t verify the server certificate. `public_key:cacerts_get/0` doesn\u0027t exist on OTP 24, so every HTTPS request falls back there, and on OTP 25 it raises when no CA store is found. hex_core versions before 0.11.0 never set `ssl` options, so they don\u0027t verify the server certificate on OTP 25 and earlier whether or not a CA store is found.\n\nThe fallback was intended and documented, but the documentation didn\u0027t make clear that it meant no certificate verification. Since hex_core 0.8.2 the README has warned that the built-in httpc adapter \"has insecure default settings\" and recommended other HTTP clients, and the adapter prints \"using default ssl options which are insecure\" on every request that falls back. hex_core 0.11.0 added certificate verification with the changelog entry \"Use secure SSL defaults for OTP 25+\". Neither the README nor the warning says that the server certificate isn\u0027t verified, the README doesn\u0027t say which OTP versions the warning applies to, and on OTP 25 without CA certificates the warning tells users to upgrade to OTP 25 or later, which they already run. This advisory is published so that users who took those notices as general advice know their HTTPS requests weren\u0027t authenticated.\n\nThis issue affects hex_core: from 0.1.0 before 0.20.0."
}
],
"value": "Improper Certificate Validation vulnerability in hexpm hex_core allows an attacker who can intercept HTTPS connections to impersonate hex.pm, repo.hex.pm or any other repository or API server to programs that use hex_core\u0027s default HTTP adapter on Erlang/OTP 24, or on OTP 25 when the operating system\u0027s CA certificates can\u0027t be loaded.\n\nhex_core:default_config/0 selects the built-in hex_http_httpc adapter. For an HTTPS request whose adapter config has no ssl option, hex_http_httpc:http_options/2 builds options that verify the server certificate against public_key:cacerts_get/0. When that call raises, the adapter prints a warning and sends the request without ssl options, so httpc uses the defaults of the ssl application, which before OTP 26 don\u0027t verify the server certificate. public_key:cacerts_get/0 doesn\u0027t exist on OTP 24, so every HTTPS request falls back there, and on OTP 25 it raises when no CA store is found. hex_core versions before 0.11.0 never set ssl options, so they don\u0027t verify the server certificate on OTP 25 and earlier whether or not a CA store is found.\n\nThe fallback was intended and documented, but the documentation didn\u0027t make clear that it meant no certificate verification. Since hex_core 0.8.2 the README has warned that the built-in httpc adapter \"has insecure default settings\" and recommended other HTTP clients, and the adapter prints \"using default ssl options which are insecure\" on every request that falls back. hex_core 0.11.0 added certificate verification with the changelog entry \"Use secure SSL defaults for OTP 25+\". Neither the README nor the warning says that the server certificate isn\u0027t verified, the README doesn\u0027t say which OTP versions the warning applies to, and on OTP 25 without CA certificates the warning tells users to upgrade to OTP 25 or later, which they already run. This advisory is published so that users who took those notices as general advice know their HTTPS requests weren\u0027t authenticated.\n\nThis issue affects hex_core: from 0.1.0 before 0.20.0."
}
],
"impacts": [
{
"capecId": "CAPEC-94",
"descriptions": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003eAn attacker on the network path between a program using hex_core\u0027s default adapter and a Hex repository or API server completes the TLS handshake with any certificate. It receives the API keys, OAuth tokens and repository keys the program sends, and can alter API requests and responses. Registry signatures, which hex_core verifies by default, still prevent changes to registry contents. Hex and rebar3 aren\u0027t affected because they configure their own HTTP adapters.\u003c/p\u003e"
},
{
"base64": false,
"type": "text/markdown",
"value": "An attacker on the network path between a program using hex_core\u0027s default adapter and a Hex repository or API server completes the TLS handshake with any certificate. It receives the API keys, OAuth tokens and repository keys the program sends, and can alter API requests and responses. Registry signatures, which hex_core verifies by default, still prevent changes to registry contents. Hex and rebar3 aren\u0027t affected because they configure their own HTTP adapters."
}
],
"value": "An attacker on the network path between a program using hex_core\u0027s default adapter and a Hex repository or API server completes the TLS handshake with any certificate. It receives the API keys, OAuth tokens and repository keys the program sends, and can alter API requests and responses. Registry signatures, which hex_core verifies by default, still prevent changes to registry contents. Hex and rebar3 aren\u0027t affected because they configure their own HTTP adapters."
}
]
}
],
"metrics": [
{
"cvssV4_0": {
"Automatable": "NOT_DEFINED",
"Recovery": "NOT_DEFINED",
"Safety": "NOT_DEFINED",
"attackComplexity": "LOW",
"attackRequirements": "PRESENT",
"attackVector": "NETWORK",
"baseScore": 5.9,
"baseSeverity": "MEDIUM",
"privilegesRequired": "NONE",
"providerUrgency": "NOT_DEFINED",
"subAvailabilityImpact": "NONE",
"subConfidentialityImpact": "NONE",
"subIntegrityImpact": "NONE",
"userInteraction": "ACTIVE",
"valueDensity": "NOT_DEFINED",
"vectorString": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:A/VC:H/VI:L/VA:N/SC:N/SI:N/SA:N",
"version": "4.0",
"vulnAvailabilityImpact": "NONE",
"vulnConfidentialityImpact": "HIGH",
"vulnIntegrityImpact": "LOW",
"vulnerabilityResponseEffort": "NOT_DEFINED"
},
"format": "CVSS",
"scenarios": [
{
"lang": "en",
"value": "GENERAL"
}
]
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-295",
"description": "CWE-295 Improper Certificate Validation",
"lang": "en",
"type": "CWE"
}
]
},
{
"descriptions": [
{
"cweId": "CWE-636",
"description": "CWE-636 Not Failing Securely (\u0027Failing Open\u0027)",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-10-12T13:15:29.040Z",
"orgId": "6b3ad84c-e1a6-4bf7-a703-f496b71e49db",
"shortName": "EEF"
},
"references": [
{
"name": "GitHub Advisory",
"tags": [
"related",
"vendor-advisory"
],
"url": "https://github.com/hexpm/hex_core/security/advisories/GHSA-p26c-h8c2-rwqj"
},
{
"name": "EEF CNA record for CVE-2026-103502",
"tags": [
"related"
],
"url": "https://cna.erlef.org/cves/CVE-2026-103502.html"
},
{
"name": "OSV record EEF-CVE-2026-103502",
"tags": [
"related"
],
"url": "https://osv.dev/vulnerability/EEF-CVE-2026-103502"
},
{
"name": "Introducing commit fbb6d9d in hexpm/hex_core",
"tags": [
"related"
],
"url": "https://github.com/hexpm/hex_core/commit/fbb6d9de472e5edb8d6fb6b32a91cb266137892e"
},
{
"name": "Fix commit b7b3a42 in hexpm/hex_core",
"tags": [
"patch"
],
"url": "https://github.com/hexpm/hex_core/commit/b7b3a42defb4ed8e20a5c68a4412ce68a95b7938"
}
],
"solutions": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003eUpgrade hex_core to 0.20.0 or later. On OTP 24, or on OTP 25 without the operating system\u0027s CA certificates, HTTPS requests through \u003ccode\u003ehex_http_httpc\u003c/code\u003e then fail with \u003ccode\u003e{error, {cacerts_unavailable, Reason}}\u003c/code\u003e unless the adapter config has \u003ccode\u003essl\u003c/code\u003e options.\u003c/p\u003e"
},
{
"base64": false,
"type": "text/markdown",
"value": "Upgrade hex_core to 0.20.0 or later. On OTP 24, or on OTP 25 without the operating system\u0027s CA certificates, HTTPS requests through `hex_http_httpc` then fail with `{error, {cacerts_unavailable, Reason}}` unless the adapter config has `ssl` options."
}
],
"value": "Upgrade hex_core to 0.20.0 or later. On OTP 24, or on OTP 25 without the operating system\u0027s CA certificates, HTTPS requests through hex_http_httpc then fail with {error, {cacerts_unavailable, Reason}} unless the adapter config has ssl options."
}
],
"source": {
"discovery": "UNKNOWN"
},
"title": "hex_core\u0027s default HTTP adapter doesn\u0027t verify TLS certificates on OTP 24 and 25",
"workarounds": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003ePass \u003ccode\u003essl\u003c/code\u003e options that verify the server certificate in the adapter config, for example \u003ccode\u003e{hex_http_httpc, #{http_options =\u0026gt; [{ssl, SslOpts}]}}\u003c/code\u003e, use another HTTP adapter, or run on OTP 26 or later.\u003c/p\u003e"
},
{
"base64": false,
"type": "text/markdown",
"value": "Pass `ssl` options that verify the server certificate in the adapter config, for example `{hex_http_httpc, #{http_options =\u003e [{ssl, SslOpts}]}}`, use another HTTP adapter, or run on OTP 26 or later."
}
],
"value": "Pass ssl options that verify the server certificate in the adapter config, for example {hex_http_httpc, #{http_options =\u003e [{ssl, SslOpts}]}}, use another HTTP adapter, or run on OTP 26 or later."
}
],
"x_proofOfConcept": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003col\u003e\n\u003cli\u003eCompile \u003ccode\u003esrc/hex_http.erl\u003c/code\u003e and \u003ccode\u003esrc/hex_http_httpc.erl\u003c/code\u003e from hex_core main 4fbc5d1 in the \u003ccode\u003eerlang:24\u003c/code\u003e Docker image and run \u003ccode\u003ehex_http_httpc:request(get, \u0026lt;\u0026lt;\"https://self-signed.badssl.com/\"\u0026gt;\u0026gt;, #{}, undefined, #{profile =\u0026gt; default})\u003c/code\u003e after starting inets and ssl.\u003c/li\u003e\n\u003cli\u003eThe adapter prints \u003ccode\u003e[hex_http_httpc] using default ssl options which are insecure.\u003c/code\u003e and returns \u003ccode\u003e{ok, {200, Headers, Body}}\u003c/code\u003e from the server with the self-signed certificate.\u003c/li\u003e\n\u003cli\u003eIn the \u003ccode\u003eerlang:25\u003c/code\u003e image with an empty tmpfs mounted on \u003ccode\u003e/etc/ssl/certs\u003c/code\u003e, \u003ccode\u003epublic_key:cacerts_get/0\u003c/code\u003e raises and the request also returns \u003ccode\u003e{ok, {200, ...}}\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eIn the \u003ccode\u003eerlang:25\u003c/code\u003e image with the CA store present (150 certificates), the same request fails with \u003ccode\u003e{error, {failed_connect, ...}}\u003c/code\u003e after a \u003ccode\u003eBad Certificate\u003c/code\u003e alert.\u003c/li\u003e\n\u003c/ol\u003e"
},
{
"base64": false,
"type": "text/markdown",
"value": "1. Compile `src/hex_http.erl` and `src/hex_http_httpc.erl` from hex_core main 4fbc5d1 in the `erlang:24` Docker image and run `hex_http_httpc:request(get, \u003c\u003c\"https://self-signed.badssl.com/\"\u003e\u003e, #{}, undefined, #{profile =\u003e default})` after starting inets and ssl.\n2. The adapter prints `[hex_http_httpc] using default ssl options which are insecure.` and returns `{ok, {200, Headers, Body}}` from the server with the self-signed certificate.\n3. In the `erlang:25` image with an empty tmpfs mounted on `/etc/ssl/certs`, `public_key:cacerts_get/0` raises and the request also returns `{ok, {200, ...}}`.\n4. In the `erlang:25` image with the CA store present (150 certificates), the same request fails with `{error, {failed_connect, ...}}` after a `Bad Certificate` alert."
}
],
"value": "* Compile src/hex_http.erl and src/hex_http_httpc.erl from hex_core main 4fbc5d1 in the erlang:24 Docker image and run hex_http_httpc:request(get, \u003c\u003c\"https://self-signed.badssl.com/\"\u003e\u003e, #{}, undefined, #{profile =\u003e default}) after starting inets and ssl.\n* The adapter prints [hex_http_httpc] using default ssl options which are insecure. and returns {ok, {200, Headers, Body}} from the server with the self-signed certificate.\n* In the erlang:25 image with an empty tmpfs mounted on /etc/ssl/certs, public_key:cacerts_get/0 raises and the request also returns {ok, {200, ...}}.\n* In the erlang:25 image with the CA store present (150 certificates), the same request fails with {error, {failed_connect, ...}} after a Bad Certificate alert."
}
],
"x_technicalAnalysis": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003col\u003e\n\u003cli\u003e\u003ccode\u003ehex_core:default_config/0\u003c/code\u003e sets \u003ccode\u003ehttp_adapter\u003c/code\u003e to \u003ccode\u003e{hex_http_httpc, #{profile =\u0026gt; default}}\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003e\u003ccode\u003ehex_http_httpc:request/5\u003c/code\u003e and \u003ccode\u003ehex_http_httpc:request_to_file/6\u003c/code\u003e build their httpc options with \u003ccode\u003ehttp_options/2\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eFor an \u003ccode\u003ehttps\u003c/code\u003e URI whose adapter config has no \u003ccode\u003essl\u003c/code\u003e entry in \u003ccode\u003ehttp_options\u003c/code\u003e, \u003ccode\u003ehttp_options/2\u003c/code\u003e adds \u003ccode\u003e{ssl, [{verify, verify_peer}, {cacerts, public_key:cacerts_get()}, ...]}\u003c/code\u003e inside a \u003ccode\u003etry\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eWhen \u003ccode\u003epublic_key:cacerts_get/0\u003c/code\u003e raises (\u003ccode\u003eundef\u003c/code\u003e on OTP 24; an error on OTP 25 when no CA store is found), the \u003ccode\u003ecatch\u003c/code\u003e prints a warning with \u003ccode\u003eio:format/1\u003c/code\u003e and returns the options without \u003ccode\u003essl\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003ehttpc then uses the \u003ccode\u003essl\u003c/code\u003e application\u0027s defaults, which are \u003ccode\u003everify_none\u003c/code\u003e before OTP 26, and completes the handshake with any certificate.\u003c/li\u003e\n\u003cli\u003ehex_core before 0.11.0 (e57b4fb) had no step 3: it never passed \u003ccode\u003essl\u003c/code\u003e options, so step 5 applied on every OTP version before 26.\u003c/li\u003e\n\u003c/ol\u003e"
},
{
"base64": false,
"type": "text/markdown",
"value": "1. `hex_core:default_config/0` sets `http_adapter` to `{hex_http_httpc, #{profile =\u003e default}}`.\n2. `hex_http_httpc:request/5` and `hex_http_httpc:request_to_file/6` build their httpc options with `http_options/2`.\n3. For an `https` URI whose adapter config has no `ssl` entry in `http_options`, `http_options/2` adds `{ssl, [{verify, verify_peer}, {cacerts, public_key:cacerts_get()}, ...]}` inside a `try`.\n4. When `public_key:cacerts_get/0` raises (`undef` on OTP 24; an error on OTP 25 when no CA store is found), the `catch` prints a warning with `io:format/1` and returns the options without `ssl`.\n5. httpc then uses the `ssl` application\u0027s defaults, which are `verify_none` before OTP 26, and completes the handshake with any certificate.\n6. hex_core before 0.11.0 (e57b4fb) had no step 3: it never passed `ssl` options, so step 5 applied on every OTP version before 26."
}
],
"value": "* hex_core:default_config/0 sets http_adapter to {hex_http_httpc, #{profile =\u003e default}}.\n* hex_http_httpc:request/5 and hex_http_httpc:request_to_file/6 build their httpc options with http_options/2.\n* For an https URI whose adapter config has no ssl entry in http_options, http_options/2 adds {ssl, [{verify, verify_peer}, {cacerts, public_key:cacerts_get()}, ...]} inside a try.\n* When public_key:cacerts_get/0 raises (undef on OTP 24; an error on OTP 25 when no CA store is found), the catch prints a warning with io:format/1 and returns the options without ssl.\n* httpc then uses the ssl application\u0027s defaults, which are verify_none before OTP 26, and completes the handshake with any certificate.\n* hex_core before 0.11.0 (e57b4fb) had no step 3: it never passed ssl options, so step 5 applied on every OTP version before 26."
}
]
}
},
"cveMetadata": {
"assignerOrgId": "6b3ad84c-e1a6-4bf7-a703-f496b71e49db",
"assignerShortName": "EEF",
"cveId": "CVE-2026-103502",
"datePublished": "2026-10-12T13:15:29.040Z",
"dateReserved": "2026-10-09T16:45:02.344Z",
"dateUpdated": "2026-10-12T13:15:29.040Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
CVE-2026-105283 (GCVE-0-2026-105283)
Vulnerability from cvelistv5 – Published: 2026-10-12 11:16 – Updated: 2026-10-12 11:16
VLAI
EPSS
VEX
Title
Internal error terms inspected into AshTypescript RPC error responses
Summary
Generation of Error Message Containing Sensitive Information vulnerability in ash-project ash_typescript allows an unauthenticated attacker to read internal Elixir terms from an RPC error response by provoking an error the error builder has no dedicated clause for.
AshTypescript.Rpc.ErrorBuilder.build_error_response/1 in lib/ash_typescript/rpc/error_builder.ex renders a pipeline error term that matches no specific clause with inspect/1 and places the result in details.error of the client-facing error. Ash exceptions take a separate path in AshTypescript.Rpc.Errors where unhandled cases are redacted behind an errorId, but these fallbacks have no redaction, so whatever the term carries reaches the HTTP or channel response. Two request paths hand it such terms: a struct-typed action argument with an invalid nested value, where cast_map_to_struct/2 in lib/ash_typescript/rpc/input_formatter.ex throws the raw Ash.Type cast error into the builder, and field selection on a generic action that returns a primitive, where format_field_type/1 inspects the full Ash.Info.Manifest.Type struct into vars.returnType. Resource module names in vars.resource are not treated as sensitive and are out of scope.
This issue affects ash_typescript: from 0.1.0 before 0.19.1.
Severity
CWE
- CWE-209 - Generation of Error Message Containing Sensitive Information
Assigner
References
5 references
| URL | Tags |
|---|---|
| https://github.com/ash-project/ash_typescript/sec… | relatedvendor-advisory |
| https://cna.erlef.org/cves/CVE-2026-105283.html | related |
| https://osv.dev/vulnerability/EEF-CVE-2026-105283 | related |
| https://github.com/ash-project/ash_typescript/com… | related |
| https://github.com/ash-project/ash_typescript/com… | patch |
Impacted products
2 products
| Vendor | Product | Version | |
|---|---|---|---|
| ash-project | ash_typescript |
Affected:
0.1.0 , < 0.19.1
(semver)
cpe:2.3:a:ash-project:ash_typescript:*:*:*:*:*:*:*:* |
|
| ash-project | ash_typescript |
Affected:
8e204ce34e24a158cf22a2dac4d53c44716c9e30 , < 4b3c65203ee78dc992d6d2e6559625c5460a01cd
(git)
cpe:2.3:a:ash-project:ash_typescript:*:*:*:*:*:*:*:* |
{
"containers": {
"cna": {
"affected": [
{
"collectionURL": "https://repo.hex.pm",
"cpes": [
"cpe:2.3:a:ash-project:ash_typescript:*:*:*:*:*:*:*:*"
],
"defaultStatus": "unaffected",
"modules": [
"\u0027Elixir.AshTypescript.Rpc.ErrorBuilder\u0027",
"\u0027Elixir.AshTypescript.Rpc.InputFormatter\u0027",
"\u0027Elixir.AshTypescript.Rpc\u0027"
],
"packageName": "ash_typescript",
"packageURL": "pkg:hex/ash_typescript",
"product": "ash_typescript",
"programFiles": [
"lib/ash_typescript/rpc/error_builder.ex",
"lib/ash_typescript/rpc/input_formatter.ex",
"lib/ash_typescript/rpc.ex"
],
"programRoutines": [
{
"name": "\u0027Elixir.AshTypescript.Rpc.ErrorBuilder\u0027:build_error_response/1"
},
{
"name": "\u0027Elixir.AshTypescript.Rpc.ErrorBuilder\u0027:format_field_type/1"
},
{
"name": "\u0027Elixir.AshTypescript.Rpc.InputFormatter\u0027:cast_map_to_struct/2"
},
{
"name": "\u0027Elixir.AshTypescript.Rpc\u0027:run_action/3"
},
{
"name": "\u0027Elixir.AshTypescript.Rpc\u0027:validate_action/3"
}
],
"repo": "https://github.com/ash-project/ash_typescript",
"vendor": "ash-project",
"versions": [
{
"lessThan": "0.19.1",
"status": "affected",
"version": "0.1.0",
"versionType": "semver"
}
]
},
{
"collectionURL": "https://github.com",
"cpes": [
"cpe:2.3:a:ash-project:ash_typescript:*:*:*:*:*:*:*:*"
],
"defaultStatus": "unaffected",
"modules": [
"\u0027Elixir.AshTypescript.Rpc.ErrorBuilder\u0027",
"\u0027Elixir.AshTypescript.Rpc.InputFormatter\u0027",
"\u0027Elixir.AshTypescript.Rpc\u0027"
],
"packageName": "ash-project/ash_typescript",
"packageURL": "pkg:github/ash-project/ash_typescript",
"product": "ash_typescript",
"programFiles": [
"lib/ash_typescript/rpc/error_builder.ex",
"lib/ash_typescript/rpc/input_formatter.ex",
"lib/ash_typescript/rpc.ex"
],
"programRoutines": [
{
"name": "\u0027Elixir.AshTypescript.Rpc.ErrorBuilder\u0027:build_error_response/1"
},
{
"name": "\u0027Elixir.AshTypescript.Rpc.ErrorBuilder\u0027:format_field_type/1"
},
{
"name": "\u0027Elixir.AshTypescript.Rpc.InputFormatter\u0027:cast_map_to_struct/2"
},
{
"name": "\u0027Elixir.AshTypescript.Rpc\u0027:run_action/3"
},
{
"name": "\u0027Elixir.AshTypescript.Rpc\u0027:validate_action/3"
}
],
"repo": "https://github.com/ash-project/ash_typescript",
"vendor": "ash-project",
"versions": [
{
"lessThan": "4b3c65203ee78dc992d6d2e6559625c5460a01cd",
"status": "affected",
"version": "8e204ce34e24a158cf22a2dac4d53c44716c9e30",
"versionType": "git"
}
]
}
],
"configurations": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003eThe application exposes an AshTypescript RPC endpoint over HTTP or a channel and has an action with a struct-typed argument, or a generic action with a primitive return type that accepts field selection.\u003c/p\u003e"
},
{
"base64": false,
"type": "text/markdown",
"value": "The application exposes an AshTypescript RPC endpoint over HTTP or a channel and has an action with a struct-typed argument, or a generic action with a primitive return type that accepts field selection."
}
],
"value": "The application exposes an AshTypescript RPC endpoint over HTTP or a channel and has an action with a struct-typed argument, or a generic action with a primitive return type that accepts field selection."
}
],
"cpeApplicability": [
{
"nodes": [
{
"cpeMatch": [
{
"criteria": "cpe:2.3:a:ash-project:ash_typescript:*:*:*:*:*:*:*:*",
"versionEndExcluding": "0.19.1",
"versionStartIncluding": "0.1.0",
"vulnerable": true
}
],
"negate": false,
"operator": "OR"
}
],
"operator": "AND"
}
],
"credits": [
{
"lang": "en",
"type": "finder",
"value": "Peter Shoukry / Udin"
},
{
"lang": "en",
"type": "reporter",
"value": "Peter Shoukry / Udin"
},
{
"lang": "en",
"type": "remediation developer",
"value": "Torkild Gundersen Kjevik / Ash Project"
},
{
"lang": "en",
"type": "coordinator",
"value": "Jonatan M\u00e4nnchen / EEF"
}
],
"dateAssigned": "2026-10-12T09:59:25.000Z",
"descriptions": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003eGeneration of Error Message Containing Sensitive Information vulnerability in ash-project ash_typescript allows an unauthenticated attacker to read internal Elixir terms from an RPC error response by provoking an error the error builder has no dedicated clause for.\u003c/p\u003e\n\u003cp\u003e\u003ccode\u003eAshTypescript.Rpc.ErrorBuilder.build_error_response/1\u003c/code\u003e in \u003ccode\u003elib/ash_typescript/rpc/error_builder.ex\u003c/code\u003e renders a pipeline error term that matches no specific clause with \u003ccode\u003einspect/1\u003c/code\u003e and places the result in \u003ccode\u003edetails.error\u003c/code\u003e of the client-facing error. Ash exceptions take a separate path in \u003ccode\u003eAshTypescript.Rpc.Errors\u003c/code\u003e where unhandled cases are redacted behind an \u003ccode\u003eerrorId\u003c/code\u003e, but these fallbacks have no redaction, so whatever the term carries reaches the HTTP or channel response. Two request paths hand it such terms: a struct-typed action argument with an invalid nested value, where \u003ccode\u003ecast_map_to_struct/2\u003c/code\u003e in \u003ccode\u003elib/ash_typescript/rpc/input_formatter.ex\u003c/code\u003e throws the raw \u003ccode\u003eAsh.Type\u003c/code\u003e cast error into the builder, and field selection on a generic action that returns a primitive, where \u003ccode\u003eformat_field_type/1\u003c/code\u003e inspects the full \u003ccode\u003eAsh.Info.Manifest.Type\u003c/code\u003e struct into \u003ccode\u003evars.returnType\u003c/code\u003e. Resource module names in \u003ccode\u003evars.resource\u003c/code\u003e are not treated as sensitive and are out of scope.\u003c/p\u003e\n\u003cp\u003eThis issue affects ash_typescript: from 0.1.0 before 0.19.1.\u003c/p\u003e"
},
{
"base64": false,
"type": "text/markdown",
"value": "Generation of Error Message Containing Sensitive Information vulnerability in ash-project ash_typescript allows an unauthenticated attacker to read internal Elixir terms from an RPC error response by provoking an error the error builder has no dedicated clause for.\n\n`AshTypescript.Rpc.ErrorBuilder.build_error_response/1` in `lib/ash_typescript/rpc/error_builder.ex` renders a pipeline error term that matches no specific clause with `inspect/1` and places the result in `details.error` of the client-facing error. Ash exceptions take a separate path in `AshTypescript.Rpc.Errors` where unhandled cases are redacted behind an `errorId`, but these fallbacks have no redaction, so whatever the term carries reaches the HTTP or channel response. Two request paths hand it such terms: a struct-typed action argument with an invalid nested value, where `cast_map_to_struct/2` in `lib/ash_typescript/rpc/input_formatter.ex` throws the raw `Ash.Type` cast error into the builder, and field selection on a generic action that returns a primitive, where `format_field_type/1` inspects the full `Ash.Info.Manifest.Type` struct into `vars.returnType`. Resource module names in `vars.resource` are not treated as sensitive and are out of scope.\n\nThis issue affects ash_typescript: from 0.1.0 before 0.19.1."
}
],
"value": "Generation of Error Message Containing Sensitive Information vulnerability in ash-project ash_typescript allows an unauthenticated attacker to read internal Elixir terms from an RPC error response by provoking an error the error builder has no dedicated clause for.\n\nAshTypescript.Rpc.ErrorBuilder.build_error_response/1 in lib/ash_typescript/rpc/error_builder.ex renders a pipeline error term that matches no specific clause with inspect/1 and places the result in details.error of the client-facing error. Ash exceptions take a separate path in AshTypescript.Rpc.Errors where unhandled cases are redacted behind an errorId, but these fallbacks have no redaction, so whatever the term carries reaches the HTTP or channel response. Two request paths hand it such terms: a struct-typed action argument with an invalid nested value, where cast_map_to_struct/2 in lib/ash_typescript/rpc/input_formatter.ex throws the raw Ash.Type cast error into the builder, and field selection on a generic action that returns a primitive, where format_field_type/1 inspects the full Ash.Info.Manifest.Type struct into vars.returnType. Resource module names in vars.resource are not treated as sensitive and are out of scope.\n\nThis issue affects ash_typescript: from 0.1.0 before 0.19.1."
}
],
"impacts": [
{
"capecId": "CAPEC-54",
"descriptions": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003eAny client able to call the RPC endpoint can submit malformed struct arguments or field selections and read internal Elixir terms, including any state the failing pipeline step carried, from the error response.\u003c/p\u003e"
},
{
"base64": false,
"type": "text/markdown",
"value": "Any client able to call the RPC endpoint can submit malformed struct arguments or field selections and read internal Elixir terms, including any state the failing pipeline step carried, from the error response."
}
],
"value": "Any client able to call the RPC endpoint can submit malformed struct arguments or field selections and read internal Elixir terms, including any state the failing pipeline step carried, from the error response."
}
]
}
],
"metrics": [
{
"cvssV4_0": {
"Automatable": "NOT_DEFINED",
"Recovery": "NOT_DEFINED",
"Safety": "NOT_DEFINED",
"attackComplexity": "LOW",
"attackRequirements": "PRESENT",
"attackVector": "NETWORK",
"baseScore": 6.3,
"baseSeverity": "MEDIUM",
"privilegesRequired": "NONE",
"providerUrgency": "NOT_DEFINED",
"subAvailabilityImpact": "NONE",
"subConfidentialityImpact": "NONE",
"subIntegrityImpact": "NONE",
"userInteraction": "NONE",
"valueDensity": "NOT_DEFINED",
"vectorString": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N",
"version": "4.0",
"vulnAvailabilityImpact": "NONE",
"vulnConfidentialityImpact": "LOW",
"vulnIntegrityImpact": "NONE",
"vulnerabilityResponseEffort": "NOT_DEFINED"
},
"format": "CVSS",
"scenarios": [
{
"lang": "en",
"value": "GENERAL"
}
]
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-209",
"description": "CWE-209 Generation of Error Message Containing Sensitive Information",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-10-12T11:16:30.582Z",
"orgId": "6b3ad84c-e1a6-4bf7-a703-f496b71e49db",
"shortName": "EEF"
},
"references": [
{
"name": "GitHub Advisory",
"tags": [
"related",
"vendor-advisory"
],
"url": "https://github.com/ash-project/ash_typescript/security/advisories/GHSA-7gxc-w225-f7f3"
},
{
"name": "EEF CNA record for CVE-2026-105283",
"tags": [
"related"
],
"url": "https://cna.erlef.org/cves/CVE-2026-105283.html"
},
{
"name": "OSV record EEF-CVE-2026-105283",
"tags": [
"related"
],
"url": "https://osv.dev/vulnerability/EEF-CVE-2026-105283"
},
{
"name": "Introducing commit 8e204ce in ash-project/ash_typescript",
"tags": [
"related"
],
"url": "https://github.com/ash-project/ash_typescript/commit/8e204ce34e24a158cf22a2dac4d53c44716c9e30"
},
{
"name": "Fix commit 4b3c652 in ash-project/ash_typescript",
"tags": [
"patch"
],
"url": "https://github.com/ash-project/ash_typescript/commit/4b3c65203ee78dc992d6d2e6559625c5460a01cd"
}
],
"source": {
"discovery": "EXTERNAL"
},
"title": "Internal error terms inspected into AshTypescript RPC error responses",
"x_proofOfConcept": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003col\u003e\n\u003cli\u003eExpose an AshTypescript RPC action that takes a struct-typed argument, for example an \u003ccode\u003eassignee\u003c/code\u003e argument whose struct has a UUID \u003ccode\u003eid\u003c/code\u003e field.\u003c/li\u003e\n\u003cli\u003eSend the action request with an invalid nested value, such as \u003ccode\u003e{\"assignee\": {\"id\": \"not-a-uuid\", \"name\": \"x\", \"email\": \"e\"}}\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eRead the response: each pair of the raw \u003ccode\u003eAsh.Type\u003c/code\u003e cast error is returned as its own \u003ccode\u003efield_validation_error\u003c/code\u003e with the inspected term in \u003ccode\u003edetails.error\u003c/code\u003e.\u003c/li\u003e\n\u003c/ol\u003e\n\u003cp\u003eFor the second path, send a \u003ccode\u003efields\u003c/code\u003e list to a generic action that returns a primitive and read the inspected \u003ccode\u003eAsh.Info.Manifest.Type\u003c/code\u003e struct in \u003ccode\u003evars.returnType\u003c/code\u003e of the resulting error.\u003c/p\u003e"
},
{
"base64": false,
"type": "text/markdown",
"value": "1. Expose an AshTypescript RPC action that takes a struct-typed argument, for example an `assignee` argument whose struct has a UUID `id` field.\n2. Send the action request with an invalid nested value, such as `{\"assignee\": {\"id\": \"not-a-uuid\", \"name\": \"x\", \"email\": \"e\"}}`.\n3. Read the response: each pair of the raw `Ash.Type` cast error is returned as its own `field_validation_error` with the inspected term in `details.error`.\n\nFor the second path, send a `fields` list to a generic action that returns a primitive and read the inspected `Ash.Info.Manifest.Type` struct in `vars.returnType` of the resulting error."
}
],
"value": "* Expose an AshTypescript RPC action that takes a struct-typed argument, for example an assignee argument whose struct has a UUID id field.\n* Send the action request with an invalid nested value, such as {\"assignee\": {\"id\": \"not-a-uuid\", \"name\": \"x\", \"email\": \"e\"}}.\n* Read the response: each pair of the raw Ash.Type cast error is returned as its own field_validation_error with the inspected term in details.error.\n\nFor the second path, send a fields list to a generic action that returns a primitive and read the inspected Ash.Info.Manifest.Type struct in vars.returnType of the resulting error."
}
],
"x_technicalAnalysis": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003e\u003cstrong\u003e1. Error funnel.\u003c/strong\u003e \u003ccode\u003eAshTypescript.Rpc.run_action/3\u003c/code\u003e runs the request through \u003ccode\u003ePipeline.parse_request/3\u003c/code\u003e, \u003ccode\u003eexecute_ash_action/1\u003c/code\u003e and \u003ccode\u003eprocess_result/2\u003c/code\u003e. Any \u003ccode\u003e{:error, reason}\u003c/code\u003e from these goes to \u003ccode\u003eerror_response/1\u003c/code\u003e, which calls \u003ccode\u003eAshTypescript.Rpc.ErrorBuilder.build_error_response/1\u003c/code\u003e with the raw reason term.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e2. Unredacted fallbacks.\u003c/strong\u003e \u003ccode\u003ebuild_error_response/1\u003c/code\u003e has clauses for the error tuples the pipeline is expected to emit. A two-tuple whose first element is an atom but matches no clause is rendered as \u003ccode\u003efield_validation_error\u003c/code\u003e with \u003ccode\u003edetails.error\u003c/code\u003e set to \u003ccode\u003einspect(error)\u003c/code\u003e, and any other term becomes \u003ccode\u003eunknown_error\u003c/code\u003e with \u003ccode\u003edetails.error\u003c/code\u003e set to \u003ccode\u003einspect(other)\u003c/code\u003e. Ash exceptions never reach these clauses because \u003ccode\u003eAshTypescript.Rpc.Errors\u003c/code\u003e handles them and redacts unhandled ones behind an \u003ccode\u003eerrorId\u003c/code\u003e, so only this path has no redaction.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e3. Reachable triggers.\u003c/strong\u003e \u003ccode\u003eAshTypescript.Rpc.InputFormatter.cast_map_to_struct/2\u003c/code\u003e throws the raw \u003ccode\u003eAsh.Type.cast_input/3\u003c/code\u003e error, a keyword list, when a struct-typed argument fails to cast, and \u003ccode\u003eformat/6\u003c/code\u003e turns the throw into \u003ccode\u003e{:error, term}\u003c/code\u003e for the funnel. Separately, requesting \u003ccode\u003efields\u003c/code\u003e on a generic action whose return type is a primitive produces an \u003ccode\u003e{:invalid_field_selection, :primitive_type, return_type, ...}\u003c/code\u003e tuple whose \u003ccode\u003ereturn_type\u003c/code\u003e is formatted by \u003ccode\u003eformat_field_type/1\u003c/code\u003e, which inspects the whole \u003ccode\u003eAsh.Info.Manifest.Type\u003c/code\u003e struct, constraints and decoration included, into \u003ccode\u003evars.returnType\u003c/code\u003e.\u003c/p\u003e"
},
{
"base64": false,
"type": "text/markdown",
"value": "**1. Error funnel.** `AshTypescript.Rpc.run_action/3` runs the request through `Pipeline.parse_request/3`, `execute_ash_action/1` and `process_result/2`. Any `{:error, reason}` from these goes to `error_response/1`, which calls `AshTypescript.Rpc.ErrorBuilder.build_error_response/1` with the raw reason term.\n\n**2. Unredacted fallbacks.** `build_error_response/1` has clauses for the error tuples the pipeline is expected to emit. A two-tuple whose first element is an atom but matches no clause is rendered as `field_validation_error` with `details.error` set to `inspect(error)`, and any other term becomes `unknown_error` with `details.error` set to `inspect(other)`. Ash exceptions never reach these clauses because `AshTypescript.Rpc.Errors` handles them and redacts unhandled ones behind an `errorId`, so only this path has no redaction.\n\n**3. Reachable triggers.** `AshTypescript.Rpc.InputFormatter.cast_map_to_struct/2` throws the raw `Ash.Type.cast_input/3` error, a keyword list, when a struct-typed argument fails to cast, and `format/6` turns the throw into `{:error, term}` for the funnel. Separately, requesting `fields` on a generic action whose return type is a primitive produces an `{:invalid_field_selection, :primitive_type, return_type, ...}` tuple whose `return_type` is formatted by `format_field_type/1`, which inspects the whole `Ash.Info.Manifest.Type` struct, constraints and decoration included, into `vars.returnType`."
}
],
"value": "1. Error funnel. AshTypescript.Rpc.run_action/3 runs the request through Pipeline.parse_request/3, execute_ash_action/1 and process_result/2. Any {:error, reason} from these goes to error_response/1, which calls AshTypescript.Rpc.ErrorBuilder.build_error_response/1 with the raw reason term.\n\n2. Unredacted fallbacks. build_error_response/1 has clauses for the error tuples the pipeline is expected to emit. A two-tuple whose first element is an atom but matches no clause is rendered as field_validation_error with details.error set to inspect(error), and any other term becomes unknown_error with details.error set to inspect(other). Ash exceptions never reach these clauses because AshTypescript.Rpc.Errors handles them and redacts unhandled ones behind an errorId, so only this path has no redaction.\n\n3. Reachable triggers. AshTypescript.Rpc.InputFormatter.cast_map_to_struct/2 throws the raw Ash.Type.cast_input/3 error, a keyword list, when a struct-typed argument fails to cast, and format/6 turns the throw into {:error, term} for the funnel. Separately, requesting fields on a generic action whose return type is a primitive produces an {:invalid_field_selection, :primitive_type, return_type, ...} tuple whose return_type is formatted by format_field_type/1, which inspects the whole Ash.Info.Manifest.Type struct, constraints and decoration included, into vars.returnType."
}
]
}
},
"cveMetadata": {
"assignerOrgId": "6b3ad84c-e1a6-4bf7-a703-f496b71e49db",
"assignerShortName": "EEF",
"cveId": "CVE-2026-105283",
"datePublished": "2026-10-12T11:16:30.582Z",
"dateReserved": "2026-10-10T13:15:02.310Z",
"dateUpdated": "2026-10-12T11:16:30.582Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
CVE-2026-97853 (GCVE-0-2026-97853)
Vulnerability from cvelistv5 – Published: 2026-10-10 19:43 – Updated: 2026-10-10 19:43
VLAI
EPSS
VEX
Title
Unbounded allocation in decimal Decimal.round/3 driven by the places argument enables DoS
Summary
Memory Allocation with Excessive Size Value vulnerability in ericmj decimal allows Denial of Service.
Decimal.round/3 builds the full result for the requested number of decimal places before the context precision (34 digits by default) is applied, so its cost grows with the places argument instead of with the size of the result. For positive places it appends places zero digits to the coefficient as a charlist before converting it to an integer, and for negative places it builds a charlist of -places zero digits. A single call such as Decimal.round(Decimal.new("1.5"), -50_000_000) allocates about 5.5 GB of memory, which can exhaust available memory and get the BEAM VM killed. The oldest releases instead loop once per decimal place, consuming CPU in proportion to places.
Any application that passes a user-supplied number of decimal places or scale to Decimal.round/2 or Decimal.round/3 without bounding it is exposed. The input limits added for CVE-2026-32686 do not cover the places argument.
This issue affects decimal: from 0.1.0 before 3.1.2.
Severity
CWE
- CWE-789 - Memory Allocation with Excessive Size Value
Assigner
References
6 references
Impacted products
Date Public
2026-10-10 00:00
{
"containers": {
"cna": {
"affected": [
{
"collectionURL": "https://repo.hex.pm",
"cpes": [
"cpe:2.3:a:ericmj:decimal:*:*:*:*:*:*:*:*"
],
"defaultStatus": "unaffected",
"modules": [
"\u0027Elixir.Decimal\u0027"
],
"packageName": "decimal",
"packageURL": "pkg:hex/decimal",
"product": "decimal",
"programFiles": [
"lib/decimal.ex"
],
"programRoutines": [
{
"name": "\u0027Elixir.Decimal\u0027:round/2"
},
{
"name": "\u0027Elixir.Decimal\u0027:round/3"
}
],
"repo": "https://github.com/ericmj/decimal",
"vendor": "ericmj",
"versions": [
{
"lessThan": "3.1.2",
"status": "affected",
"version": "0.1.0",
"versionType": "semver"
}
]
},
{
"collectionURL": "https://github.com",
"cpes": [
"cpe:2.3:a:ericmj:decimal:*:*:*:*:*:*:*:*"
],
"defaultStatus": "unaffected",
"modules": [
"\u0027Elixir.Decimal\u0027"
],
"packageName": "ericmj/decimal",
"packageURL": "pkg:github/ericmj/decimal",
"product": "decimal",
"programFiles": [
"lib/decimal.ex"
],
"programRoutines": [
{
"name": "\u0027Elixir.Decimal\u0027:round/2"
},
{
"name": "\u0027Elixir.Decimal\u0027:round/3"
}
],
"repo": "https://github.com/ericmj/decimal",
"vendor": "ericmj",
"versions": [
{
"changes": [
{
"at": "338f42c8cf6a9749ab70c5af04734c6050ca3dc6",
"status": "unaffected"
},
{
"at": "3c90af4c3c2dfa4bb4c138760a326dd0eb91822b",
"status": "unaffected"
}
],
"lessThan": "*",
"status": "affected",
"version": "05bb73eb40ddef24eda782d905766f56a3660522",
"versionType": "git"
}
]
}
],
"cpeApplicability": [
{
"nodes": [
{
"cpeMatch": [
{
"criteria": "cpe:2.3:a:ericmj:decimal:*:*:*:*:*:*:*:*",
"versionEndExcluding": "3.1.2",
"versionStartIncluding": "0.1.0",
"vulnerable": true
}
],
"negate": false,
"operator": "OR"
}
],
"operator": "AND"
}
],
"credits": [
{
"lang": "en",
"type": "finder",
"value": "Peter Ullrich"
},
{
"lang": "en",
"type": "remediation developer",
"value": "Eric Meadows-J\u00f6nsson"
},
{
"lang": "en",
"type": "coordinator",
"value": "Eric Meadows-J\u00f6nsson"
}
],
"dateAssigned": "2026-10-09T16:40:13.000Z",
"datePublic": "2026-10-10T00:00:00.000Z",
"descriptions": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003eMemory Allocation with Excessive Size Value vulnerability in ericmj decimal allows Denial of Service.\u003c/p\u003e\n\u003cp\u003e\u003ccode\u003eDecimal.round/3\u003c/code\u003e builds the full result for the requested number of decimal places before the context precision (34 digits by default) is applied, so its cost grows with the \u003ccode\u003eplaces\u003c/code\u003e argument instead of with the size of the result. For positive \u003ccode\u003eplaces\u003c/code\u003e it appends \u003ccode\u003eplaces\u003c/code\u003e zero digits to the coefficient as a charlist before converting it to an integer, and for negative \u003ccode\u003eplaces\u003c/code\u003e it builds a charlist of \u003ccode\u003e-places\u003c/code\u003e zero digits. A single call such as \u003ccode\u003eDecimal.round(Decimal.new(\"1.5\"), -50_000_000)\u003c/code\u003e allocates about 5.5 GB of memory, which can exhaust available memory and get the BEAM VM killed. The oldest releases instead loop once per decimal place, consuming CPU in proportion to \u003ccode\u003eplaces\u003c/code\u003e.\u003c/p\u003e\n\u003cp\u003eAny application that passes a user-supplied number of decimal places or scale to \u003ccode\u003eDecimal.round/2\u003c/code\u003e or \u003ccode\u003eDecimal.round/3\u003c/code\u003e without bounding it is exposed. The input limits added for CVE-2026-32686 do not cover the \u003ccode\u003eplaces\u003c/code\u003e argument.\u003c/p\u003e\n\u003cp\u003eThis issue affects decimal: from 0.1.0 before 3.1.2.\u003c/p\u003e"
},
{
"base64": false,
"type": "text/markdown",
"value": "Memory Allocation with Excessive Size Value vulnerability in ericmj decimal allows Denial of Service.\n\n`Decimal.round/3` builds the full result for the requested number of decimal places before the context precision (34 digits by default) is applied, so its cost grows with the `places` argument instead of with the size of the result. For positive `places` it appends `places` zero digits to the coefficient as a charlist before converting it to an integer, and for negative `places` it builds a charlist of `-places` zero digits. A single call such as `Decimal.round(Decimal.new(\"1.5\"), -50_000_000)` allocates about 5.5 GB of memory, which can exhaust available memory and get the BEAM VM killed. The oldest releases instead loop once per decimal place, consuming CPU in proportion to `places`.\n\nAny application that passes a user-supplied number of decimal places or scale to `Decimal.round/2` or `Decimal.round/3` without bounding it is exposed. The input limits added for CVE-2026-32686 do not cover the `places` argument.\n\nThis issue affects decimal: from 0.1.0 before 3.1.2."
}
],
"value": "Memory Allocation with Excessive Size Value vulnerability in ericmj decimal allows Denial of Service.\n\nDecimal.round/3 builds the full result for the requested number of decimal places before the context precision (34 digits by default) is applied, so its cost grows with the places argument instead of with the size of the result. For positive places it appends places zero digits to the coefficient as a charlist before converting it to an integer, and for negative places it builds a charlist of -places zero digits. A single call such as Decimal.round(Decimal.new(\"1.5\"), -50_000_000) allocates about 5.5 GB of memory, which can exhaust available memory and get the BEAM VM killed. The oldest releases instead loop once per decimal place, consuming CPU in proportion to places.\n\nAny application that passes a user-supplied number of decimal places or scale to Decimal.round/2 or Decimal.round/3 without bounding it is exposed. The input limits added for CVE-2026-32686 do not cover the places argument.\n\nThis issue affects decimal: from 0.1.0 before 3.1.2."
}
],
"impacts": [
{
"capecId": "CAPEC-130",
"descriptions": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003eAn attacker who controls the number of decimal places an application rounds to makes one \u003ccode\u003eDecimal.round/2,3\u003c/code\u003e call allocate memory in proportion to that number. A value of 50 million needs about 5.5 GB, enough to get the BEAM VM killed on hosts with less memory and take down every request it serves.\u003c/p\u003e"
},
{
"base64": false,
"type": "text/markdown",
"value": "An attacker who controls the number of decimal places an application rounds to makes one `Decimal.round/2,3` call allocate memory in proportion to that number. A value of 50 million needs about 5.5 GB, enough to get the BEAM VM killed on hosts with less memory and take down every request it serves."
}
],
"value": "An attacker who controls the number of decimal places an application rounds to makes one Decimal.round/2,3 call allocate memory in proportion to that number. A value of 50 million needs about 5.5 GB, enough to get the BEAM VM killed on hosts with less memory and take down every request it serves."
}
]
}
],
"metrics": [
{
"cvssV4_0": {
"Automatable": "NOT_DEFINED",
"Recovery": "NOT_DEFINED",
"Safety": "NOT_DEFINED",
"attackComplexity": "LOW",
"attackRequirements": "NONE",
"attackVector": "LOCAL",
"baseScore": 6.9,
"baseSeverity": "MEDIUM",
"privilegesRequired": "NONE",
"providerUrgency": "NOT_DEFINED",
"subAvailabilityImpact": "NONE",
"subConfidentialityImpact": "NONE",
"subIntegrityImpact": "NONE",
"userInteraction": "NONE",
"valueDensity": "NOT_DEFINED",
"vectorString": "CVSS:4.0/AV:L/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N",
"version": "4.0",
"vulnAvailabilityImpact": "HIGH",
"vulnConfidentialityImpact": "NONE",
"vulnIntegrityImpact": "NONE",
"vulnerabilityResponseEffort": "NOT_DEFINED"
},
"format": "CVSS",
"scenarios": [
{
"lang": "en",
"value": "GENERAL"
}
]
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-789",
"description": "CWE-789 Memory Allocation with Excessive Size Value",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-10-10T19:43:45.217Z",
"orgId": "6b3ad84c-e1a6-4bf7-a703-f496b71e49db",
"shortName": "EEF"
},
"references": [
{
"name": "GHSA-6c27-994x-c52f",
"tags": [
"vendor-advisory"
],
"url": "https://github.com/ericmj/decimal/security/advisories/GHSA-6c27-994x-c52f"
},
{
"name": "EEF CNA record for CVE-2026-97853",
"tags": [
"related"
],
"url": "https://cna.erlef.org/cves/CVE-2026-97853.html"
},
{
"name": "OSV record EEF-CVE-2026-97853",
"tags": [
"related"
],
"url": "https://osv.dev/vulnerability/EEF-CVE-2026-97853"
},
{
"name": "Introducing commit 05bb73e in ericmj/decimal",
"tags": [
"related"
],
"url": "https://github.com/ericmj/decimal/commit/05bb73eb40ddef24eda782d905766f56a3660522"
},
{
"name": "Fix commit 338f42c in ericmj/decimal",
"tags": [
"patch"
],
"url": "https://github.com/ericmj/decimal/commit/338f42c8cf6a9749ab70c5af04734c6050ca3dc6"
},
{
"name": "Fix commit 3c90af4 in ericmj/decimal",
"tags": [
"patch"
],
"url": "https://github.com/ericmj/decimal/commit/3c90af4c3c2dfa4bb4c138760a326dd0eb91822b"
}
],
"source": {
"discovery": "EXTERNAL"
},
"title": "Unbounded allocation in decimal Decimal.round/3 driven by the places argument enables DoS",
"workarounds": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003eBound \u003ccode\u003eplaces\u003c/code\u003e before calling \u003ccode\u003eDecimal.round/2,3\u003c/code\u003e, for example to \u003ccode\u003e-34..34\u003c/code\u003e or to the scales the application supports.\u003c/p\u003e"
},
{
"base64": false,
"type": "text/markdown",
"value": "Bound `places` before calling `Decimal.round/2,3`, for example to `-34..34` or to the scales the application supports."
}
],
"value": "Bound places before calling Decimal.round/2,3, for example to -34..34 or to the scales the application supports."
}
],
"x_proofOfConcept": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cpre\u003e\u003ccode class=\"language-elixir\"\u003eMix.install([{:decimal, \"3.1.1\"}])\n\n# Allocates about 5.5 GB.\nDecimal.round(Decimal.new(\"1.5\"), -50_000_000)\n\n# Builds a 50 million element list, then raises SystemLimitError.\nDecimal.round(Decimal.new(\"1.5\"), 50_000_000)\n\u003c/code\u003e\u003c/pre\u003e"
},
{
"base64": false,
"type": "text/markdown",
"value": "```elixir\nMix.install([{:decimal, \"3.1.1\"}])\n\n# Allocates about 5.5 GB.\nDecimal.round(Decimal.new(\"1.5\"), -50_000_000)\n\n# Builds a 50 million element list, then raises SystemLimitError.\nDecimal.round(Decimal.new(\"1.5\"), 50_000_000)\n```"
}
],
"value": "Mix.install([{:decimal, \"3.1.1\"}])\n\n# Allocates about 5.5 GB.\nDecimal.round(Decimal.new(\"1.5\"), -50_000_000)\n\n# Builds a 50 million element list, then raises SystemLimitError.\nDecimal.round(Decimal.new(\"1.5\"), 50_000_000)"
}
],
"x_technicalAnalysis": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003e\u003ccode\u003eDecimal.round/3\u003c/code\u003e sets the target exponent to \u003ccode\u003e-places\u003c/code\u003e and \u003ccode\u003edo_round/5\u003c/code\u003e materializes the coefficient at that exponent; \u003ccode\u003econtext/2\u003c/code\u003e only applies the precision afterwards.\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003ePositive \u003ccode\u003eplaces\u003c/code\u003e (introduced in 1.3.0 by commit 7a83d27): \u003ccode\u003edigits ++ Enum.map(1..(exp - target_exp), fn _ -\u0026gt; ?0 end)\u003c/code\u003e followed by \u003ccode\u003e:erlang.list_to_integer/1\u003c/code\u003e (\u003ccode\u003elib/decimal.ex:2409\u003c/code\u003e in 3.1.1). The list is built before \u003ccode\u003elist_to_integer/1\u003c/code\u003e raises \u003ccode\u003eSystemLimitError\u003c/code\u003e for results over about 1.26 million digits, the BEAM integer size limit.\u003c/li\u003e\n\u003cli\u003eNegative \u003ccode\u003eplaces\u003c/code\u003e (since 1.4.0): \u003ccode\u003e:lists.duplicate(target_exp - exp, ?0) ++ digits\u003c/code\u003e (\u003ccode\u003elib/decimal.ex:2385-2386\u003c/code\u003e in 3.1.1).\u003c/li\u003e\n\u003cli\u003eReleases from 0.1.0 before 1.1.0: \u003ccode\u003edo_round\u003c/code\u003e (and in 1.0.1 \u003ccode\u003esplit_coef\u003c/code\u003e) recurses once per decimal place for negative \u003ccode\u003eplaces\u003c/code\u003e; 1.0.1 also multiplies a power of ten by 10 on every iteration. Established by reading the code; these releases do not compile on current Elixir.\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003eMeasured on OTP 29 with 3.1.1, one call per fresh VM:\u003c/p\u003e\n\u003ctable\u003e\n\u003cthead\u003e\n\u003ctr\u003e\n\u003cth\u003eCall\u003c/th\u003e\n\u003cth\u003eTime\u003c/th\u003e\n\u003cth\u003ePeak VM memory\u003c/th\u003e\n\u003c/tr\u003e\n\u003c/thead\u003e\n\u003ctbody\u003e\n\u003ctr\u003e\n\u003ctd\u003e\u003ccode\u003eDecimal.round(Decimal.new(\"1.5\"), -10_000_000)\u003c/code\u003e\u003c/td\u003e\n\u003ctd\u003e0.25 s\u003c/td\u003e\n\u003ctd\u003e0.8 GB\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003e\u003ccode\u003eDecimal.round(Decimal.new(\"1.5\"), -50_000_000)\u003c/code\u003e\u003c/td\u003e\n\u003ctd\u003e1.2 s\u003c/td\u003e\n\u003ctd\u003e5.5 GB\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003e\u003ccode\u003eDecimal.round(Decimal.new(\"1.5\"), 50_000_000)\u003c/code\u003e\u003c/td\u003e\n\u003ctd\u003e2.1 s, then \u003ccode\u003eSystemLimitError\u003c/code\u003e\u003c/td\u003e\n\u003ctd\u003e2.4 GB\u003c/td\u003e\n\u003c/tr\u003e\n\u003c/tbody\u003e\n\u003c/table\u003e\n\u003cp\u003eIn an \u003ccode\u003eelixir:1.20.4\u003c/code\u003e container started with \u003ccode\u003e--memory=2g\u003c/code\u003e, either of the last two calls got the VM killed (exit status 137). Over HTTP (Plug and Bandit) a 34-byte JSON body carrying \u003ccode\u003eplaces: -50_000_000\u003c/code\u003e returned after 1.25 s with server memory at 4.3 GB.\u003c/p\u003e"
},
{
"base64": false,
"type": "text/markdown",
"value": "`Decimal.round/3` sets the target exponent to `-places` and `do_round/5` materializes the coefficient at that exponent; `context/2` only applies the precision afterwards.\n\n- Positive `places` (introduced in 1.3.0 by commit 7a83d27): `digits ++ Enum.map(1..(exp - target_exp), fn _ -\u003e ?0 end)` followed by `:erlang.list_to_integer/1` (`lib/decimal.ex:2409` in 3.1.1). The list is built before `list_to_integer/1` raises `SystemLimitError` for results over about 1.26 million digits, the BEAM integer size limit.\n- Negative `places` (since 1.4.0): `:lists.duplicate(target_exp - exp, ?0) ++ digits` (`lib/decimal.ex:2385-2386` in 3.1.1).\n- Releases from 0.1.0 before 1.1.0: `do_round` (and in 1.0.1 `split_coef`) recurses once per decimal place for negative `places`; 1.0.1 also multiplies a power of ten by 10 on every iteration. Established by reading the code; these releases do not compile on current Elixir.\n\nMeasured on OTP 29 with 3.1.1, one call per fresh VM:\n\n| Call | Time | Peak VM memory |\n|---|---|---|\n| `Decimal.round(Decimal.new(\"1.5\"), -10_000_000)` | 0.25 s | 0.8 GB |\n| `Decimal.round(Decimal.new(\"1.5\"), -50_000_000)` | 1.2 s | 5.5 GB |\n| `Decimal.round(Decimal.new(\"1.5\"), 50_000_000)` | 2.1 s, then `SystemLimitError` | 2.4 GB |\n\nIn an `elixir:1.20.4` container started with `--memory=2g`, either of the last two calls got the VM killed (exit status 137). Over HTTP (Plug and Bandit) a 34-byte JSON body carrying `places: -50_000_000` returned after 1.25 s with server memory at 4.3 GB."
}
],
"value": "Decimal.round/3 sets the target exponent to -places and do_round/5 materializes the coefficient at that exponent; context/2 only applies the precision afterwards.\n\n* Positive places (introduced in 1.3.0 by commit 7a83d27): digits ++ Enum.map(1..(exp - target_exp), fn _ -\u003e ?0 end) followed by :erlang.list_to_integer/1 (lib/decimal.ex:2409 in 3.1.1). The list is built before list_to_integer/1 raises SystemLimitError for results over about 1.26 million digits, the BEAM integer size limit.\n* Negative places (since 1.4.0): :lists.duplicate(target_exp - exp, ?0) ++ digits (lib/decimal.ex:2385-2386 in 3.1.1).\n* Releases from 0.1.0 before 1.1.0: do_round (and in 1.0.1 split_coef) recurses once per decimal place for negative places; 1.0.1 also multiplies a power of ten by 10 on every iteration. Established by reading the code; these releases do not compile on current Elixir.\n\nMeasured on OTP 29 with 3.1.1, one call per fresh VM:\n\nCallTimePeak VM memoryDecimal.round(Decimal.new(\"1.5\"), -10_000_000)0.25 s0.8 GBDecimal.round(Decimal.new(\"1.5\"), -50_000_000)1.2 s5.5 GBDecimal.round(Decimal.new(\"1.5\"), 50_000_000)2.1 s, then SystemLimitError2.4 GB\n\nIn an elixir:1.20.4 container started with --memory=2g, either of the last two calls got the VM killed (exit status 137). Over HTTP (Plug and Bandit) a 34-byte JSON body carrying places: -50_000_000 returned after 1.25 s with server memory at 4.3 GB."
}
]
}
},
"cveMetadata": {
"assignerOrgId": "6b3ad84c-e1a6-4bf7-a703-f496b71e49db",
"assignerShortName": "EEF",
"cveId": "CVE-2026-97853",
"datePublished": "2026-10-10T19:43:45.217Z",
"dateReserved": "2026-10-09T00:30:01.645Z",
"dateUpdated": "2026-10-10T19:43:45.217Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
CVE-2026-104635 (GCVE-0-2026-104635)
Vulnerability from cvelistv5 – Published: 2026-10-09 08:17 – Updated: 2026-10-09 09:24
VLAI
EPSS
VEX
Title
Uncontrolled recursion in elixir-protobuf/protobuf JSON decoding of self-referential messages
Summary
Uncontrolled Recursion vulnerability in Protobuf.JSON.Decode in elixir-protobuf protobuf allows an unauthenticated remote attacker to crash the decoding process via a deeply nested JSON document. Any application that decodes attacker-supplied JSON with Protobuf.JSON.decode/3, Protobuf.JSON.decode!/3, or Protobuf.JSON.from_decoded/3 into a schema that contains a self-referential or cyclic message type is affected.
In lib/protobuf/json/decode.ex, the embedded-message clause of decode_singular/3 recurses into internal_from_json_data/3 once per nesting level without incrementing or checking the decoder's depth counter. The depth guard increase_depth_and_maybe_throw/1 covers only the Google.Protobuf.ListValue and Google.Protobuf.Struct clauses, so the recursion_limit option has no effect on user-defined message types. Each nesting level allocates a stack frame and heap objects, and a sufficiently deep document exhausts the memory of the decoding process. Confidentiality and integrity are not affected.
This issue affects protobuf: from 0.8.0 before 0.17.1.
Severity
CWE
- CWE-674 - Uncontrolled Recursion
Assigner
References
5 references
| URL | Tags |
|---|---|
| https://github.com/elixir-protobuf/protobuf/secur… | relatedvendor-advisory |
| https://cna.erlef.org/cves/CVE-2026-104635.html | related |
| https://osv.dev/vulnerability/EEF-CVE-2026-104635 | related |
| https://github.com/elixir-protobuf/protobuf/commi… | related |
| https://github.com/elixir-protobuf/protobuf/commi… | patch |
Impacted products
2 products
| Vendor | Product | Version | |
|---|---|---|---|
| elixir-protobuf | protobuf |
Affected:
0.8.0 , < 0.17.1
(semver)
cpe:2.3:a:elixir-protobuf:protobuf:*:*:*:*:*:*:*:* |
|
| elixir-protobuf | protobuf |
Affected:
b0a1d4eaffaf50012fa71a8e931a47cf252d0370 , < e9432ad1c4099511905353cebcececa3a1f7c3ff
(git)
cpe:2.3:a:elixir-protobuf:protobuf:*:*:*:*:*:*:*:* |
Date Public
2026-10-09 08:17
{
"containers": {
"cna": {
"affected": [
{
"collectionURL": "https://repo.hex.pm",
"cpes": [
"cpe:2.3:a:elixir-protobuf:protobuf:*:*:*:*:*:*:*:*"
],
"defaultStatus": "unaffected",
"modules": [
"\u0027Elixir.Protobuf.JSON.Decode\u0027",
"\u0027Elixir.Protobuf.JSON\u0027"
],
"packageName": "protobuf",
"packageURL": "pkg:hex/protobuf",
"product": "protobuf",
"programFiles": [
"lib/protobuf/json/decode.ex",
"lib/protobuf/json.ex"
],
"programRoutines": [
{
"name": "\u0027Elixir.Protobuf.JSON.Decode\u0027:from_json_data/3"
},
{
"name": "\u0027Elixir.Protobuf.JSON.Decode\u0027:decode_singular/3"
},
{
"name": "\u0027Elixir.Protobuf.JSON\u0027:decode/3"
},
{
"name": "\u0027Elixir.Protobuf.JSON\u0027:decode!/3"
},
{
"name": "\u0027Elixir.Protobuf.JSON\u0027:from_decoded/3"
}
],
"repo": "https://github.com/elixir-protobuf/protobuf",
"vendor": "elixir-protobuf",
"versions": [
{
"lessThan": "0.17.1",
"status": "affected",
"version": "0.8.0",
"versionType": "semver"
}
]
},
{
"collectionURL": "https://github.com",
"cpes": [
"cpe:2.3:a:elixir-protobuf:protobuf:*:*:*:*:*:*:*:*"
],
"defaultStatus": "unaffected",
"modules": [
"\u0027Elixir.Protobuf.JSON.Decode\u0027",
"\u0027Elixir.Protobuf.JSON\u0027"
],
"packageName": "elixir-protobuf/protobuf",
"packageURL": "pkg:github/elixir-protobuf/protobuf",
"product": "protobuf",
"programFiles": [
"lib/protobuf/json/decode.ex",
"lib/protobuf/json.ex"
],
"programRoutines": [
{
"name": "\u0027Elixir.Protobuf.JSON.Decode\u0027:from_json_data/3"
},
{
"name": "\u0027Elixir.Protobuf.JSON.Decode\u0027:decode_singular/3"
},
{
"name": "\u0027Elixir.Protobuf.JSON\u0027:decode/3"
},
{
"name": "\u0027Elixir.Protobuf.JSON\u0027:decode!/3"
},
{
"name": "\u0027Elixir.Protobuf.JSON\u0027:from_decoded/3"
}
],
"repo": "https://github.com/elixir-protobuf/protobuf",
"vendor": "elixir-protobuf",
"versions": [
{
"lessThan": "e9432ad1c4099511905353cebcececa3a1f7c3ff",
"status": "affected",
"version": "b0a1d4eaffaf50012fa71a8e931a47cf252d0370",
"versionType": "git"
}
]
}
],
"configurations": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003eThe application decodes attacker-controlled JSON with \u003ccode\u003eProtobuf.JSON.decode/3\u003c/code\u003e, \u003ccode\u003eProtobuf.JSON.decode!/3\u003c/code\u003e, or \u003ccode\u003eProtobuf.JSON.from_decoded/3\u003c/code\u003e into a message type whose schema contains a self-referential or cyclic embedded message.\u003c/p\u003e"
},
{
"base64": false,
"type": "text/markdown",
"value": "The application decodes attacker-controlled JSON with `Protobuf.JSON.decode/3`, `Protobuf.JSON.decode!/3`, or `Protobuf.JSON.from_decoded/3` into a message type whose schema contains a self-referential or cyclic embedded message."
}
],
"value": "The application decodes attacker-controlled JSON with Protobuf.JSON.decode/3, Protobuf.JSON.decode!/3, or Protobuf.JSON.from_decoded/3 into a message type whose schema contains a self-referential or cyclic embedded message."
}
],
"cpeApplicability": [
{
"nodes": [
{
"cpeMatch": [
{
"criteria": "cpe:2.3:a:elixir-protobuf:protobuf:*:*:*:*:*:*:*:*",
"versionEndExcluding": "0.17.1",
"versionStartIncluding": "0.8.0",
"vulnerable": true
}
],
"negate": false,
"operator": "OR"
}
],
"operator": "AND"
}
],
"credits": [
{
"lang": "en",
"type": "reporter",
"value": "Daniel Coles"
},
{
"lang": "en",
"type": "finder",
"value": "Daniel Coles"
},
{
"lang": "en",
"type": "remediation developer",
"value": "Andrea Leopardi"
},
{
"lang": "en",
"type": "coordinator",
"value": "Jonatan M\u00e4nnchen / EEF"
}
],
"dateAssigned": "2026-10-08T15:40:42.000Z",
"datePublic": "2026-10-09T08:17:52.000Z",
"descriptions": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003eUncontrolled Recursion vulnerability in \u003ccode\u003eProtobuf.JSON.Decode\u003c/code\u003e in elixir-protobuf protobuf allows an unauthenticated remote attacker to crash the decoding process via a deeply nested JSON document. Any application that decodes attacker-supplied JSON with \u003ccode\u003eProtobuf.JSON.decode/3\u003c/code\u003e, \u003ccode\u003eProtobuf.JSON.decode!/3\u003c/code\u003e, or \u003ccode\u003eProtobuf.JSON.from_decoded/3\u003c/code\u003e into a schema that contains a self-referential or cyclic message type is affected.\u003c/p\u003e\n\u003cp\u003eIn \u003ccode\u003elib/protobuf/json/decode.ex\u003c/code\u003e, the embedded-message clause of \u003ccode\u003edecode_singular/3\u003c/code\u003e recurses into \u003ccode\u003einternal_from_json_data/3\u003c/code\u003e once per nesting level without incrementing or checking the decoder\u0027s depth counter. The depth guard \u003ccode\u003eincrease_depth_and_maybe_throw/1\u003c/code\u003e covers only the \u003ccode\u003eGoogle.Protobuf.ListValue\u003c/code\u003e and \u003ccode\u003eGoogle.Protobuf.Struct\u003c/code\u003e clauses, so the \u003ccode\u003erecursion_limit\u003c/code\u003e option has no effect on user-defined message types. Each nesting level allocates a stack frame and heap objects, and a sufficiently deep document exhausts the memory of the decoding process. Confidentiality and integrity are not affected.\u003c/p\u003e\n\u003cp\u003eThis issue affects protobuf: from 0.8.0 before 0.17.1.\u003c/p\u003e"
},
{
"base64": false,
"type": "text/markdown",
"value": "Uncontrolled Recursion vulnerability in `Protobuf.JSON.Decode` in elixir-protobuf protobuf allows an unauthenticated remote attacker to crash the decoding process via a deeply nested JSON document. Any application that decodes attacker-supplied JSON with `Protobuf.JSON.decode/3`, `Protobuf.JSON.decode!/3`, or `Protobuf.JSON.from_decoded/3` into a schema that contains a self-referential or cyclic message type is affected.\n\nIn `lib/protobuf/json/decode.ex`, the embedded-message clause of `decode_singular/3` recurses into `internal_from_json_data/3` once per nesting level without incrementing or checking the decoder\u0027s depth counter. The depth guard `increase_depth_and_maybe_throw/1` covers only the `Google.Protobuf.ListValue` and `Google.Protobuf.Struct` clauses, so the `recursion_limit` option has no effect on user-defined message types. Each nesting level allocates a stack frame and heap objects, and a sufficiently deep document exhausts the memory of the decoding process. Confidentiality and integrity are not affected.\n\nThis issue affects protobuf: from 0.8.0 before 0.17.1."
}
],
"value": "Uncontrolled Recursion vulnerability in Protobuf.JSON.Decode in elixir-protobuf protobuf allows an unauthenticated remote attacker to crash the decoding process via a deeply nested JSON document. Any application that decodes attacker-supplied JSON with Protobuf.JSON.decode/3, Protobuf.JSON.decode!/3, or Protobuf.JSON.from_decoded/3 into a schema that contains a self-referential or cyclic message type is affected.\n\nIn lib/protobuf/json/decode.ex, the embedded-message clause of decode_singular/3 recurses into internal_from_json_data/3 once per nesting level without incrementing or checking the decoder\u0027s depth counter. The depth guard increase_depth_and_maybe_throw/1 covers only the Google.Protobuf.ListValue and Google.Protobuf.Struct clauses, so the recursion_limit option has no effect on user-defined message types. Each nesting level allocates a stack frame and heap objects, and a sufficiently deep document exhausts the memory of the decoding process. Confidentiality and integrity are not affected.\n\nThis issue affects protobuf: from 0.8.0 before 0.17.1."
}
],
"impacts": [
{
"capecId": "CAPEC-230",
"descriptions": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003eAn unauthenticated client that can reach an endpoint decoding JSON into a self-referential message type can crash the decoding process through stack and memory exhaustion with a single request. Repeated or concurrent requests can exhaust the memory of the whole node and disrupt co-located workloads.\u003c/p\u003e"
},
{
"base64": false,
"type": "text/markdown",
"value": "An unauthenticated client that can reach an endpoint decoding JSON into a self-referential message type can crash the decoding process through stack and memory exhaustion with a single request. Repeated or concurrent requests can exhaust the memory of the whole node and disrupt co-located workloads."
}
],
"value": "An unauthenticated client that can reach an endpoint decoding JSON into a self-referential message type can crash the decoding process through stack and memory exhaustion with a single request. Repeated or concurrent requests can exhaust the memory of the whole node and disrupt co-located workloads."
}
]
}
],
"metrics": [
{
"cvssV4_0": {
"Automatable": "NOT_DEFINED",
"Recovery": "NOT_DEFINED",
"Safety": "NOT_DEFINED",
"attackComplexity": "LOW",
"attackRequirements": "PRESENT",
"attackVector": "NETWORK",
"baseScore": 8.2,
"baseSeverity": "HIGH",
"privilegesRequired": "NONE",
"providerUrgency": "NOT_DEFINED",
"subAvailabilityImpact": "NONE",
"subConfidentialityImpact": "NONE",
"subIntegrityImpact": "NONE",
"userInteraction": "NONE",
"valueDensity": "NOT_DEFINED",
"vectorString": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N",
"version": "4.0",
"vulnAvailabilityImpact": "HIGH",
"vulnConfidentialityImpact": "NONE",
"vulnIntegrityImpact": "NONE",
"vulnerabilityResponseEffort": "NOT_DEFINED"
},
"format": "CVSS",
"scenarios": [
{
"lang": "en",
"value": "GENERAL"
}
]
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-674",
"description": "CWE-674 Uncontrolled Recursion",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-10-09T09:24:37.025Z",
"orgId": "6b3ad84c-e1a6-4bf7-a703-f496b71e49db",
"shortName": "EEF"
},
"references": [
{
"name": "GitHub Advisory",
"tags": [
"related",
"vendor-advisory"
],
"url": "https://github.com/elixir-protobuf/protobuf/security/advisories/GHSA-m497-c2h9-rvw6"
},
{
"name": "EEF CNA record for CVE-2026-104635",
"tags": [
"related"
],
"url": "https://cna.erlef.org/cves/CVE-2026-104635.html"
},
{
"name": "OSV record EEF-CVE-2026-104635",
"tags": [
"related"
],
"url": "https://osv.dev/vulnerability/EEF-CVE-2026-104635"
},
{
"name": "Introducing commit b0a1d4e in elixir-protobuf/protobuf",
"tags": [
"related"
],
"url": "https://github.com/elixir-protobuf/protobuf/commit/b0a1d4eaffaf50012fa71a8e931a47cf252d0370"
},
{
"name": "Fix commit e9432ad in elixir-protobuf/protobuf",
"tags": [
"patch"
],
"url": "https://github.com/elixir-protobuf/protobuf/commit/e9432ad1c4099511905353cebcececa3a1f7c3ff"
}
],
"source": {
"discovery": "EXTERNAL"
},
"title": "Uncontrolled recursion in elixir-protobuf/protobuf JSON decoding of self-referential messages",
"workarounds": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003eReject JSON documents whose nesting depth exceeds a fixed bound at the web or middleware layer before passing them to the decoder. No decoder option limits recursion for user-defined message types, so the check must happen before \u003ccode\u003eProtobuf.JSON.decode/3\u003c/code\u003e, \u003ccode\u003eProtobuf.JSON.decode!/3\u003c/code\u003e, or \u003ccode\u003eProtobuf.JSON.from_decoded/3\u003c/code\u003e is called.\u003c/p\u003e"
},
{
"base64": false,
"type": "text/markdown",
"value": "Reject JSON documents whose nesting depth exceeds a fixed bound at the web or middleware layer before passing them to the decoder. No decoder option limits recursion for user-defined message types, so the check must happen before `Protobuf.JSON.decode/3`, `Protobuf.JSON.decode!/3`, or `Protobuf.JSON.from_decoded/3` is called."
}
],
"value": "Reject JSON documents whose nesting depth exceeds a fixed bound at the web or middleware layer before passing them to the decoder. No decoder option limits recursion for user-defined message types, so the check must happen before Protobuf.JSON.decode/3, Protobuf.JSON.decode!/3, or Protobuf.JSON.from_decoded/3 is called."
}
],
"x_proofOfConcept": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003col\u003e\n\u003cli\u003eDefine and compile a self-referential proto3 message, for example a \u003ccode\u003eTreeNode\u003c/code\u003e message with a single embedded field \u003ccode\u003echild\u003c/code\u003e of type \u003ccode\u003eTreeNode\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eBuild a JSON document that nests the \u003ccode\u003echild\u003c/code\u003e field several thousand levels deep, for example by wrapping \u003ccode\u003e{}\u003c/code\u003e in \u003ccode\u003e{\"child\": ...}\u003c/code\u003e 5,000 times.\u003c/li\u003e\n\u003cli\u003eDecode it with \u003ccode\u003eProtobuf.JSON.decode(json, TreeNode, recursion_limit: 100)\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eObserve that no \u003ccode\u003eProtobuf.JSON.DecodeError\u003c/code\u003e for an exceeded recursion limit is raised and the decoder walks every level. The same depth in a \u003ccode\u003eGoogle.Protobuf.Struct\u003c/code\u003e payload raises \u003ccode\u003e{:recursion_limit_exceeded, 100}\u003c/code\u003e. At larger depths the decoding process consumes hundreds of megabytes and crashes with stack and heap exhaustion.\u003c/li\u003e\n\u003c/ol\u003e"
},
{
"base64": false,
"type": "text/markdown",
"value": "1. Define and compile a self-referential proto3 message, for example a `TreeNode` message with a single embedded field `child` of type `TreeNode`.\n2. Build a JSON document that nests the `child` field several thousand levels deep, for example by wrapping `{}` in `{\"child\": ...}` 5,000 times.\n3. Decode it with `Protobuf.JSON.decode(json, TreeNode, recursion_limit: 100)`.\n4. Observe that no `Protobuf.JSON.DecodeError` for an exceeded recursion limit is raised and the decoder walks every level. The same depth in a `Google.Protobuf.Struct` payload raises `{:recursion_limit_exceeded, 100}`. At larger depths the decoding process consumes hundreds of megabytes and crashes with stack and heap exhaustion."
}
],
"value": "* Define and compile a self-referential proto3 message, for example a TreeNode message with a single embedded field child of type TreeNode.\n* Build a JSON document that nests the child field several thousand levels deep, for example by wrapping {} in {\"child\": ...} 5,000 times.\n* Decode it with Protobuf.JSON.decode(json, TreeNode, recursion_limit: 100).\n* Observe that no Protobuf.JSON.DecodeError for an exceeded recursion limit is raised and the decoder walks every level. The same depth in a Google.Protobuf.Struct payload raises {:recursion_limit_exceeded, 100}. At larger depths the decoding process consumes hundreds of megabytes and crashes with stack and heap exhaustion."
}
],
"x_technicalAnalysis": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003e\u003cstrong\u003e1. Entry points.\u003c/strong\u003e \u003ccode\u003eProtobuf.JSON.decode/3\u003c/code\u003e, \u003ccode\u003eProtobuf.JSON.decode!/3\u003c/code\u003e, and \u003ccode\u003eProtobuf.JSON.from_decoded/3\u003c/code\u003e in \u003ccode\u003elib/protobuf/json.ex\u003c/code\u003e validate options and call \u003ccode\u003eProtobuf.JSON.Decode.from_json_data/3\u003c/code\u003e, which builds a \u003ccode\u003estate\u003c/code\u003e map carrying \u003ccode\u003edepth: 0\u003c/code\u003e and the \u003ccode\u003erecursion_limit\u003c/code\u003e (default 100). \u003ccode\u003efrom_decoded/3\u003c/code\u003e accepts already-parsed data, so the underlying JSON parser never bounds the depth either.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e2. Unguarded recursion.\u003c/strong\u003e For a user-defined message module, \u003ccode\u003einternal_from_json_data/3\u003c/code\u003e calls \u003ccode\u003edecode_message/4\u003c/code\u003e, which calls \u003ccode\u003edecode_regular_fields/3\u003c/code\u003e and \u003ccode\u003edecode_oneof_fields/3\u003c/code\u003e. Each field value passes through \u003ccode\u003edecode_value/3\u003c/code\u003e and, for a singular embedded message, reaches the \u003ccode\u003edecode_singular/3\u003c/code\u003e clause matching \u003ccode\u003eembedded?: true\u003c/code\u003e. That clause calls \u003ccode\u003einternal_from_json_data/3\u003c/code\u003e with \u003ccode\u003estate\u003c/code\u003e unchanged, so \u003ccode\u003estate.depth\u003c/code\u003e stays at 0 at every nesting level. Repeated fields and map values reach the same clause through \u003ccode\u003edecode_repeated/3\u003c/code\u003e and \u003ccode\u003edecode_map/3\u003c/code\u003e.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e3. Guard coverage.\u003c/strong\u003e \u003ccode\u003eincrease_depth_and_maybe_throw/1\u003c/code\u003e increments \u003ccode\u003edepth\u003c/code\u003e and throws \u003ccode\u003e{:recursion_limit_exceeded, limit}\u003c/code\u003e when it exceeds the limit. It is called only from the \u003ccode\u003eGoogle.Protobuf.ListValue\u003c/code\u003e and \u003ccode\u003eGoogle.Protobuf.Struct\u003c/code\u003e clauses, which the \u003ccode\u003eGoogle.Protobuf.Value\u003c/code\u003e clause delegates to. The \u003ccode\u003erecursion_limit\u003c/code\u003e documentation scopes the option to those wrappers, and no other path checks depth.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e4. Result.\u003c/strong\u003e A self-referential schema such as a \u003ccode\u003eTree\u003c/code\u003e message with a \u003ccode\u003eTree child\u003c/code\u003e field recurses once per JSON nesting level with no bound. Each level holds a live stack frame and allocates heap objects, so a sufficiently deep document exhausts the memory of the decoding process and crashes it. The BEAM \u003ccode\u003emax_heap_size\u003c/code\u003e process flag defaults to unlimited, so repeated or concurrent requests can exhaust the memory of the whole node.\u003c/p\u003e"
},
{
"base64": false,
"type": "text/markdown",
"value": "**1. Entry points.** `Protobuf.JSON.decode/3`, `Protobuf.JSON.decode!/3`, and `Protobuf.JSON.from_decoded/3` in `lib/protobuf/json.ex` validate options and call `Protobuf.JSON.Decode.from_json_data/3`, which builds a `state` map carrying `depth: 0` and the `recursion_limit` (default 100). `from_decoded/3` accepts already-parsed data, so the underlying JSON parser never bounds the depth either.\n\n**2. Unguarded recursion.** For a user-defined message module, `internal_from_json_data/3` calls `decode_message/4`, which calls `decode_regular_fields/3` and `decode_oneof_fields/3`. Each field value passes through `decode_value/3` and, for a singular embedded message, reaches the `decode_singular/3` clause matching `embedded?: true`. That clause calls `internal_from_json_data/3` with `state` unchanged, so `state.depth` stays at 0 at every nesting level. Repeated fields and map values reach the same clause through `decode_repeated/3` and `decode_map/3`.\n\n**3. Guard coverage.** `increase_depth_and_maybe_throw/1` increments `depth` and throws `{:recursion_limit_exceeded, limit}` when it exceeds the limit. It is called only from the `Google.Protobuf.ListValue` and `Google.Protobuf.Struct` clauses, which the `Google.Protobuf.Value` clause delegates to. The `recursion_limit` documentation scopes the option to those wrappers, and no other path checks depth.\n\n**4. Result.** A self-referential schema such as a `Tree` message with a `Tree child` field recurses once per JSON nesting level with no bound. Each level holds a live stack frame and allocates heap objects, so a sufficiently deep document exhausts the memory of the decoding process and crashes it. The BEAM `max_heap_size` process flag defaults to unlimited, so repeated or concurrent requests can exhaust the memory of the whole node."
}
],
"value": "1. Entry points. Protobuf.JSON.decode/3, Protobuf.JSON.decode!/3, and Protobuf.JSON.from_decoded/3 in lib/protobuf/json.ex validate options and call Protobuf.JSON.Decode.from_json_data/3, which builds a state map carrying depth: 0 and the recursion_limit (default 100). from_decoded/3 accepts already-parsed data, so the underlying JSON parser never bounds the depth either.\n\n2. Unguarded recursion. For a user-defined message module, internal_from_json_data/3 calls decode_message/4, which calls decode_regular_fields/3 and decode_oneof_fields/3. Each field value passes through decode_value/3 and, for a singular embedded message, reaches the decode_singular/3 clause matching embedded?: true. That clause calls internal_from_json_data/3 with state unchanged, so state.depth stays at 0 at every nesting level. Repeated fields and map values reach the same clause through decode_repeated/3 and decode_map/3.\n\n3. Guard coverage. increase_depth_and_maybe_throw/1 increments depth and throws {:recursion_limit_exceeded, limit} when it exceeds the limit. It is called only from the Google.Protobuf.ListValue and Google.Protobuf.Struct clauses, which the Google.Protobuf.Value clause delegates to. The recursion_limit documentation scopes the option to those wrappers, and no other path checks depth.\n\n4. Result. A self-referential schema such as a Tree message with a Tree child field recurses once per JSON nesting level with no bound. Each level holds a live stack frame and allocates heap objects, so a sufficiently deep document exhausts the memory of the decoding process and crashes it. The BEAM max_heap_size process flag defaults to unlimited, so repeated or concurrent requests can exhaust the memory of the whole node."
}
]
}
},
"cveMetadata": {
"assignerOrgId": "6b3ad84c-e1a6-4bf7-a703-f496b71e49db",
"assignerShortName": "EEF",
"cveId": "CVE-2026-104635",
"datePublished": "2026-10-09T08:17:52.372Z",
"dateReserved": "2026-10-08T14:45:01.406Z",
"dateUpdated": "2026-10-09T09:24:37.025Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
CVE-2026-101028 (GCVE-0-2026-101028)
Vulnerability from cvelistv5 – Published: 2026-10-09 07:01 – Updated: 2026-10-09 18:04
VLAI
EPSS
VEX
Title
Ash.count, Ash.exists and Ash.aggregate skip related resources' read policies in filters and sorts
Summary
Incorrect Authorization vulnerability in ash-project ash allows an actor to infer data in related records they cannot read via Ash.count/2, Ash.exists/2 and Ash.aggregate/3.
Ash.Actions.Aggregate.run/4 (lib/ash/actions/aggregate.ex) applied only the root resource's read policy before running the aggregate query. The read path also applies each related resource's read policy to filter and sort references that cross a relationship, directly (for example comments.body) or through an aggregate over one, but the aggregate path skipped that step. A caller whose filter or sort reaches these functions, for example through Ash.Query.filter_input/2, an ash_lua script, or an AshAi tool offering count or exists results, can test conditions against related rows hidden from them and recover their existence and attribute values one query at a time. Ash.read/2 and its page counts are not affected.
This issue affects ash: from 2.6.0 before 3.34.6.
Severity
SSVC
Exploitation: poc
Automatable: no
Technical Impact: partial
CISA Coordinator · CISA-ADP (v2.0.3)
Decision recorded 2026-10-09 18:03 UTC
CWE
- CWE-863 - Incorrect Authorization
Assigner
References
5 references
| URL | Tags |
|---|---|
| https://github.com/ash-project/ash/security/advis… | vendor-advisoryrelated |
| https://cna.erlef.org/cves/CVE-2026-101028.html | related |
| https://osv.dev/vulnerability/EEF-CVE-2026-101028 | related |
| https://github.com/ash-project/ash/commit/30eaf1c… | related |
| https://github.com/ash-project/ash/commit/8093618… | patch |
Impacted products
2 products
| Vendor | Product | Version | |
|---|---|---|---|
| ash-project | ash |
Affected:
2.6.0 , < 3.34.6
(semver)
cpe:2.3:a:ash-project:ash:*:*:*:*:*:*:*:* |
|
| ash-project | ash |
Affected:
30eaf1c6e8524527b703e3c4bfeff7967ee0b37c , < 80936187b27ee94f15cd875affd3141b5cb23185
(git)
cpe:2.3:a:ash-project:ash:*:*:*:*:*:*:*:* |
{
"containers": {
"adp": [
{
"metrics": [
{
"other": {
"content": {
"id": "CVE-2026-101028",
"options": [
{
"Exploitation": "poc"
},
{
"Automatable": "no"
},
{
"Technical Impact": "partial"
}
],
"role": "CISA Coordinator",
"timestamp": "2026-10-09T18:03:54.666261Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"providerMetadata": {
"dateUpdated": "2026-10-09T18:04:24.729Z",
"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"shortName": "CISA-ADP"
},
"references": [
{
"tags": [
"exploit"
],
"url": "https://github.com/ash-project/ash/security/advisories/GHSA-xj24-8f5c-pp5p"
}
],
"title": "CISA ADP Vulnrichment"
}
],
"cna": {
"affected": [
{
"collectionURL": "https://repo.hex.pm",
"cpes": [
"cpe:2.3:a:ash-project:ash:*:*:*:*:*:*:*:*"
],
"defaultStatus": "unaffected",
"modules": [
"\u0027Elixir.Ash.Actions.Aggregate\u0027",
"\u0027Elixir.Ash\u0027"
],
"packageName": "ash",
"packageURL": "pkg:hex/ash",
"product": "ash",
"programFiles": [
"lib/ash/actions/aggregate.ex",
"lib/ash.ex"
],
"programRoutines": [
{
"name": "\u0027Elixir.Ash.Actions.Aggregate\u0027:run/4"
},
{
"name": "\u0027Elixir.Ash\u0027:count/2"
},
{
"name": "\u0027Elixir.Ash\u0027:exists/2"
},
{
"name": "\u0027Elixir.Ash\u0027:aggregate/3"
}
],
"repo": "https://github.com/ash-project/ash",
"vendor": "ash-project",
"versions": [
{
"lessThan": "3.34.6",
"status": "affected",
"version": "2.6.0",
"versionType": "semver"
}
]
},
{
"collectionURL": "https://github.com",
"cpes": [
"cpe:2.3:a:ash-project:ash:*:*:*:*:*:*:*:*"
],
"defaultStatus": "unaffected",
"modules": [
"\u0027Elixir.Ash.Actions.Aggregate\u0027",
"\u0027Elixir.Ash\u0027"
],
"packageName": "ash-project/ash",
"packageURL": "pkg:github/ash-project/ash",
"product": "ash",
"programFiles": [
"lib/ash/actions/aggregate.ex",
"lib/ash.ex"
],
"programRoutines": [
{
"name": "\u0027Elixir.Ash.Actions.Aggregate\u0027:run/4"
},
{
"name": "\u0027Elixir.Ash\u0027:count/2"
},
{
"name": "\u0027Elixir.Ash\u0027:exists/2"
},
{
"name": "\u0027Elixir.Ash\u0027:aggregate/3"
}
],
"repo": "https://github.com/ash-project/ash",
"vendor": "ash-project",
"versions": [
{
"lessThan": "80936187b27ee94f15cd875affd3141b5cb23185",
"status": "affected",
"version": "30eaf1c6e8524527b703e3c4bfeff7967ee0b37c",
"versionType": "git"
}
]
}
],
"configurations": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003eReachable only when an application passes caller-supplied filters or sorts that cross a relationship into \u003ccode\u003eAsh.count/2\u003c/code\u003e, \u003ccode\u003eAsh.exists/2\u003c/code\u003e or \u003ccode\u003eAsh.aggregate/3\u003c/code\u003e (directly, through ash_lua read operations, or through AshAi count, exists or aggregate result types), and a related resource\u0027s read policy is stricter than the root resource\u0027s.\u003c/p\u003e"
},
{
"base64": false,
"type": "text/markdown",
"value": "Reachable only when an application passes caller-supplied filters or sorts that cross a relationship into `Ash.count/2`, `Ash.exists/2` or `Ash.aggregate/3` (directly, through ash_lua read operations, or through AshAi count, exists or aggregate result types), and a related resource\u0027s read policy is stricter than the root resource\u0027s."
}
],
"value": "Reachable only when an application passes caller-supplied filters or sorts that cross a relationship into Ash.count/2, Ash.exists/2 or Ash.aggregate/3 (directly, through ash_lua read operations, or through AshAi count, exists or aggregate result types), and a related resource\u0027s read policy is stricter than the root resource\u0027s."
}
],
"cpeApplicability": [
{
"nodes": [
{
"cpeMatch": [
{
"criteria": "cpe:2.3:a:ash-project:ash:*:*:*:*:*:*:*:*",
"versionEndExcluding": "3.34.6",
"versionStartIncluding": "2.6.0",
"vulnerable": true
}
],
"negate": false,
"operator": "OR"
}
],
"operator": "AND"
}
],
"credits": [
{
"lang": "en",
"type": "reporter",
"value": "Glenn Rempe"
},
{
"lang": "en",
"type": "finder",
"value": "Glenn Rempe"
},
{
"lang": "en",
"type": "remediation developer",
"value": "Zach Daniel / Ash Project"
}
],
"dateAssigned": "2026-10-09T00:19:31.000Z",
"descriptions": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003eIncorrect Authorization vulnerability in ash-project ash allows an actor to infer data in related records they cannot read via \u003ccode\u003eAsh.count/2\u003c/code\u003e, \u003ccode\u003eAsh.exists/2\u003c/code\u003e and \u003ccode\u003eAsh.aggregate/3\u003c/code\u003e.\u003c/p\u003e\n\u003cp\u003e\u003ccode\u003eAsh.Actions.Aggregate.run/4\u003c/code\u003e (\u003ccode\u003elib/ash/actions/aggregate.ex\u003c/code\u003e) applied only the root resource\u0027s read policy before running the aggregate query. The read path also applies each related resource\u0027s read policy to filter and sort references that cross a relationship, directly (for example \u003ccode\u003ecomments.body\u003c/code\u003e) or through an aggregate over one, but the aggregate path skipped that step. A caller whose filter or sort reaches these functions, for example through \u003ccode\u003eAsh.Query.filter_input/2\u003c/code\u003e, an ash_lua script, or an AshAi tool offering count or exists results, can test conditions against related rows hidden from them and recover their existence and attribute values one query at a time. \u003ccode\u003eAsh.read/2\u003c/code\u003e and its page counts are not affected.\u003c/p\u003e\n\u003cp\u003eThis issue affects ash: from 2.6.0 before 3.34.6.\u003c/p\u003e"
},
{
"base64": false,
"type": "text/markdown",
"value": "Incorrect Authorization vulnerability in ash-project ash allows an actor to infer data in related records they cannot read via `Ash.count/2`, `Ash.exists/2` and `Ash.aggregate/3`.\n\n`Ash.Actions.Aggregate.run/4` (`lib/ash/actions/aggregate.ex`) applied only the root resource\u0027s read policy before running the aggregate query. The read path also applies each related resource\u0027s read policy to filter and sort references that cross a relationship, directly (for example `comments.body`) or through an aggregate over one, but the aggregate path skipped that step. A caller whose filter or sort reaches these functions, for example through `Ash.Query.filter_input/2`, an ash_lua script, or an AshAi tool offering count or exists results, can test conditions against related rows hidden from them and recover their existence and attribute values one query at a time. `Ash.read/2` and its page counts are not affected.\n\nThis issue affects ash: from 2.6.0 before 3.34.6."
}
],
"value": "Incorrect Authorization vulnerability in ash-project ash allows an actor to infer data in related records they cannot read via Ash.count/2, Ash.exists/2 and Ash.aggregate/3.\n\nAsh.Actions.Aggregate.run/4 (lib/ash/actions/aggregate.ex) applied only the root resource\u0027s read policy before running the aggregate query. The read path also applies each related resource\u0027s read policy to filter and sort references that cross a relationship, directly (for example comments.body) or through an aggregate over one, but the aggregate path skipped that step. A caller whose filter or sort reaches these functions, for example through Ash.Query.filter_input/2, an ash_lua script, or an AshAi tool offering count or exists results, can test conditions against related rows hidden from them and recover their existence and attribute values one query at a time. Ash.read/2 and its page counts are not affected.\n\nThis issue affects ash: from 2.6.0 before 3.34.6."
}
],
"impacts": [
{
"capecId": "CAPEC-1",
"descriptions": [
{
"lang": "en",
"value": "CAPEC-1 Accessing Functionality Not Properly Constrained by ACLs"
}
]
}
],
"metrics": [
{
"cvssV4_0": {
"Automatable": "NOT_DEFINED",
"Recovery": "NOT_DEFINED",
"Safety": "NOT_DEFINED",
"attackComplexity": "LOW",
"attackRequirements": "PRESENT",
"attackVector": "NETWORK",
"baseScore": 6,
"baseSeverity": "MEDIUM",
"privilegesRequired": "LOW",
"providerUrgency": "NOT_DEFINED",
"subAvailabilityImpact": "NONE",
"subConfidentialityImpact": "NONE",
"subIntegrityImpact": "NONE",
"userInteraction": "NONE",
"valueDensity": "NOT_DEFINED",
"vectorString": "CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N",
"version": "4.0",
"vulnAvailabilityImpact": "NONE",
"vulnConfidentialityImpact": "HIGH",
"vulnIntegrityImpact": "NONE",
"vulnerabilityResponseEffort": "NOT_DEFINED"
},
"format": "CVSS",
"scenarios": [
{
"lang": "en",
"value": "GENERAL"
}
]
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-863",
"description": "CWE-863 Incorrect Authorization",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-10-09T07:01:06.470Z",
"orgId": "6b3ad84c-e1a6-4bf7-a703-f496b71e49db",
"shortName": "EEF"
},
"references": [
{
"name": "GHSA-xj24-8f5c-pp5p",
"tags": [
"vendor-advisory",
"related"
],
"url": "https://github.com/ash-project/ash/security/advisories/GHSA-xj24-8f5c-pp5p"
},
{
"name": "EEF CNA record for CVE-2026-101028",
"tags": [
"related"
],
"url": "https://cna.erlef.org/cves/CVE-2026-101028.html"
},
{
"name": "OSV record EEF-CVE-2026-101028",
"tags": [
"related"
],
"url": "https://osv.dev/vulnerability/EEF-CVE-2026-101028"
},
{
"name": "Introducing commit 30eaf1c in ash-project/ash",
"tags": [
"related"
],
"url": "https://github.com/ash-project/ash/commit/30eaf1c6e8524527b703e3c4bfeff7967ee0b37c"
},
{
"name": "Fix commit 8093618 in ash-project/ash",
"tags": [
"patch"
],
"url": "https://github.com/ash-project/ash/commit/80936187b27ee94f15cd875affd3141b5cb23185"
}
],
"source": {
"discovery": "EXTERNAL"
},
"title": "Ash.count, Ash.exists and Ash.aggregate skip related resources\u0027 read policies in filters and sorts"
}
},
"cveMetadata": {
"assignerOrgId": "6b3ad84c-e1a6-4bf7-a703-f496b71e49db",
"assignerShortName": "EEF",
"cveId": "CVE-2026-101028",
"datePublished": "2026-10-09T07:01:06.470Z",
"dateReserved": "2026-10-08T15:45:02.376Z",
"dateUpdated": "2026-10-09T18:04:24.729Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
CVE-2026-104634 (GCVE-0-2026-104634)
Vulnerability from cvelistv5 – Published: 2026-10-08 13:41 – Updated: 2026-10-08 13:58
VLAI
EPSS
VEX
Title
beam_mcp: JSON boolean and null tool arguments reach dispatch as strings
Summary
Incorrect Type Conversion or Cast vulnerability in BeamMCP.Server in ScriptKittyOS beam_mcp allows an MCP client's JSON true, false and null tool arguments to reach the host's dispatch function as the strings "true", "false" and "nil". After BeamMCP.Schema.validate/2 accepted a value as a boolean, normalize_arguments/2 passed every argument through to_json_value/1, whose atom clause converts true, false and nil to strings. A string is truthy in Elixir, so a host that tests a boolean argument, for example if args.dry_run, takes the opposite branch for false, and a guard such as confirm: false reads as set.
The client controls the argument and could send true directly, so the practical impact is limited to hosts whose behaviour on false differs from their behaviour on true, and to any policy layer in front of the server that permits false but refuses true. The same normalisation applies to prompts/get arguments, which exist from 0.5.0.
This issue affects beam_mcp: from 0.1.0 before 0.10.1.
Severity
SSVC
Exploitation: none
Automatable: no
Technical Impact: partial
CISA Coordinator · CISA-ADP (v2.0.3)
Decision recorded 2026-10-08 13:58 UTC
CWE
- CWE-704 - Incorrect Type Conversion or Cast
Assigner
References
5 references
| URL | Tags |
|---|---|
| https://github.com/ScriptKittyOS/beam_mcp/securit… | relatedvendor-advisory |
| https://cna.erlef.org/cves/CVE-2026-104634.html | related |
| https://osv.dev/vulnerability/EEF-CVE-2026-104634 | related |
| https://github.com/ScriptKittyOS/beam_mcp/commit/… | related |
| https://github.com/ScriptKittyOS/beam_mcp/commit/… | patch |
Impacted products
2 products
| Vendor | Product | Version | |
|---|---|---|---|
| ScriptKittyOS | beam_mcp |
Affected:
0.1.0 , < 0.10.1
(semver)
cpe:2.3:a:scriptkittyos:beam_mcp:*:*:*:*:*:*:*:* |
|
| ScriptKittyOS | beam_mcp |
Affected:
083838eb8e17fe5f6fcaf761bdbe203110288b0b , < 289dbdbad641943b29a3b8d1eb36506cc8cec10a
(git)
cpe:2.3:a:scriptkittyos:beam_mcp:*:*:*:*:*:*:*:* |
Date Public
2026-09-26 00:00
{
"containers": {
"adp": [
{
"metrics": [
{
"other": {
"content": {
"id": "CVE-2026-104634",
"options": [
{
"Exploitation": "none"
},
{
"Automatable": "no"
},
{
"Technical Impact": "partial"
}
],
"role": "CISA Coordinator",
"timestamp": "2026-10-08T13:58:26.222349Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"providerMetadata": {
"dateUpdated": "2026-10-08T13:58:34.464Z",
"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"shortName": "CISA-ADP"
},
"title": "CISA ADP Vulnrichment"
}
],
"cna": {
"affected": [
{
"collectionURL": "https://repo.hex.pm",
"cpes": [
"cpe:2.3:a:scriptkittyos:beam_mcp:*:*:*:*:*:*:*:*"
],
"defaultStatus": "unaffected",
"modules": [
"\u0027Elixir.BeamMCP.Server\u0027"
],
"packageName": "beam_mcp",
"packageURL": "pkg:hex/beam_mcp",
"product": "beam_mcp",
"programFiles": [
"lib/beam_mcp/server.ex"
],
"programRoutines": [
{
"name": "\u0027Elixir.BeamMCP.Server\u0027:handle_message/2"
},
{
"name": "\u0027Elixir.BeamMCP.Server\u0027:normalize_arguments/2"
},
{
"name": "\u0027Elixir.BeamMCP.Server\u0027:to_json_value/1"
}
],
"repo": "https://github.com/ScriptKittyOS/beam_mcp",
"vendor": "ScriptKittyOS",
"versions": [
{
"lessThan": "0.10.1",
"status": "affected",
"version": "0.1.0",
"versionType": "semver"
}
]
},
{
"collectionURL": "https://github.com",
"cpes": [
"cpe:2.3:a:scriptkittyos:beam_mcp:*:*:*:*:*:*:*:*"
],
"defaultStatus": "unaffected",
"modules": [
"\u0027Elixir.BeamMCP.Server\u0027"
],
"packageName": "scriptkittyos/beam_mcp",
"packageURL": "pkg:github/scriptkittyos/beam_mcp",
"product": "beam_mcp",
"programFiles": [
"lib/beam_mcp/server.ex"
],
"programRoutines": [
{
"name": "\u0027Elixir.BeamMCP.Server\u0027:handle_message/2"
},
{
"name": "\u0027Elixir.BeamMCP.Server\u0027:normalize_arguments/2"
},
{
"name": "\u0027Elixir.BeamMCP.Server\u0027:to_json_value/1"
}
],
"repo": "https://github.com/ScriptKittyOS/beam_mcp",
"vendor": "ScriptKittyOS",
"versions": [
{
"lessThan": "289dbdbad641943b29a3b8d1eb36506cc8cec10a",
"status": "affected",
"version": "083838eb8e17fe5f6fcaf761bdbe203110288b0b",
"versionType": "git"
}
]
}
],
"cpeApplicability": [
{
"nodes": [
{
"cpeMatch": [
{
"criteria": "cpe:2.3:a:scriptkittyos:beam_mcp:*:*:*:*:*:*:*:*",
"versionEndExcluding": "0.10.1",
"versionStartIncluding": "0.1.0",
"vulnerable": true
}
],
"negate": false,
"operator": "OR"
}
],
"operator": "AND"
}
],
"credits": [
{
"lang": "en",
"type": "finder",
"value": "Ayla Croft / Script Kitty OS"
},
{
"lang": "en",
"type": "reporter",
"value": "Ayla Croft / Script Kitty OS"
},
{
"lang": "en",
"type": "remediation developer",
"value": "Ayla Croft / Script Kitty OS"
},
{
"lang": "en",
"type": "coordinator",
"value": "Jonatan M\u00e4nnchen / EEF"
}
],
"dateAssigned": "2026-10-08T13:40:59.000Z",
"datePublic": "2026-09-26T00:00:00.000Z",
"descriptions": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003eIncorrect Type Conversion or Cast vulnerability in \u003ccode\u003eBeamMCP.Server\u003c/code\u003e in ScriptKittyOS beam_mcp allows an MCP client\u0027s JSON \u003ccode\u003etrue\u003c/code\u003e, \u003ccode\u003efalse\u003c/code\u003e and \u003ccode\u003enull\u003c/code\u003e tool arguments to reach the host\u0027s dispatch function as the strings \"true\", \"false\" and \"nil\". After \u003ccode\u003eBeamMCP.Schema.validate/2\u003c/code\u003e accepted a value as a boolean, \u003ccode\u003enormalize_arguments/2\u003c/code\u003e passed every argument through \u003ccode\u003eto_json_value/1\u003c/code\u003e, whose atom clause converts \u003ccode\u003etrue\u003c/code\u003e, \u003ccode\u003efalse\u003c/code\u003e and \u003ccode\u003enil\u003c/code\u003e to strings. A string is truthy in Elixir, so a host that tests a boolean argument, for example \u003ccode\u003eif args.dry_run\u003c/code\u003e, takes the opposite branch for \u003ccode\u003efalse\u003c/code\u003e, and a guard such as \u003ccode\u003econfirm: false\u003c/code\u003e reads as set.\u003c/p\u003e\n\u003cp\u003eThe client controls the argument and could send \u003ccode\u003etrue\u003c/code\u003e directly, so the practical impact is limited to hosts whose behaviour on \u003ccode\u003efalse\u003c/code\u003e differs from their behaviour on \u003ccode\u003etrue\u003c/code\u003e, and to any policy layer in front of the server that permits \u003ccode\u003efalse\u003c/code\u003e but refuses \u003ccode\u003etrue\u003c/code\u003e. The same normalisation applies to \u003ccode\u003eprompts/get\u003c/code\u003e arguments, which exist from 0.5.0.\u003c/p\u003e\n\u003cp\u003eThis issue affects beam_mcp: from 0.1.0 before 0.10.1.\u003c/p\u003e"
},
{
"base64": false,
"type": "text/markdown",
"value": "Incorrect Type Conversion or Cast vulnerability in `BeamMCP.Server` in ScriptKittyOS beam_mcp allows an MCP client\u0027s JSON `true`, `false` and `null` tool arguments to reach the host\u0027s dispatch function as the strings \"true\", \"false\" and \"nil\". After `BeamMCP.Schema.validate/2` accepted a value as a boolean, `normalize_arguments/2` passed every argument through `to_json_value/1`, whose atom clause converts `true`, `false` and `nil` to strings. A string is truthy in Elixir, so a host that tests a boolean argument, for example `if args.dry_run`, takes the opposite branch for `false`, and a guard such as `confirm: false` reads as set.\n\nThe client controls the argument and could send `true` directly, so the practical impact is limited to hosts whose behaviour on `false` differs from their behaviour on `true`, and to any policy layer in front of the server that permits `false` but refuses `true`. The same normalisation applies to `prompts/get` arguments, which exist from 0.5.0.\n\nThis issue affects beam_mcp: from 0.1.0 before 0.10.1."
}
],
"value": "Incorrect Type Conversion or Cast vulnerability in BeamMCP.Server in ScriptKittyOS beam_mcp allows an MCP client\u0027s JSON true, false and null tool arguments to reach the host\u0027s dispatch function as the strings \"true\", \"false\" and \"nil\". After BeamMCP.Schema.validate/2 accepted a value as a boolean, normalize_arguments/2 passed every argument through to_json_value/1, whose atom clause converts true, false and nil to strings. A string is truthy in Elixir, so a host that tests a boolean argument, for example if args.dry_run, takes the opposite branch for false, and a guard such as confirm: false reads as set.\n\nThe client controls the argument and could send true directly, so the practical impact is limited to hosts whose behaviour on false differs from their behaviour on true, and to any policy layer in front of the server that permits false but refuses true. The same normalisation applies to prompts/get arguments, which exist from 0.5.0.\n\nThis issue affects beam_mcp: from 0.1.0 before 0.10.1."
}
],
"impacts": [
{
"capecId": "CAPEC-153",
"descriptions": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003eA host that branches on a boolean argument takes the opposite branch for \u003ccode\u003efalse\u003c/code\u003e, so a safety guard such as \u003ccode\u003econfirm: false\u003c/code\u003e or \u003ccode\u003edry_run: false\u003c/code\u003e is read as set. The client already controls the argument, so the gain over sending \u003ccode\u003etrue\u003c/code\u003e is limited to hosts and intermediaries that treat the two values differently.\u003c/p\u003e"
},
{
"base64": false,
"type": "text/markdown",
"value": "A host that branches on a boolean argument takes the opposite branch for `false`, so a safety guard such as `confirm: false` or `dry_run: false` is read as set. The client already controls the argument, so the gain over sending `true` is limited to hosts and intermediaries that treat the two values differently."
}
],
"value": "A host that branches on a boolean argument takes the opposite branch for false, so a safety guard such as confirm: false or dry_run: false is read as set. The client already controls the argument, so the gain over sending true is limited to hosts and intermediaries that treat the two values differently."
}
]
}
],
"metrics": [
{
"cvssV4_0": {
"Automatable": "NOT_DEFINED",
"Recovery": "NOT_DEFINED",
"Safety": "NOT_DEFINED",
"attackComplexity": "LOW",
"attackRequirements": "PRESENT",
"attackVector": "NETWORK",
"baseScore": 2.3,
"baseSeverity": "LOW",
"privilegesRequired": "LOW",
"providerUrgency": "NOT_DEFINED",
"subAvailabilityImpact": "NONE",
"subConfidentialityImpact": "NONE",
"subIntegrityImpact": "NONE",
"userInteraction": "NONE",
"valueDensity": "NOT_DEFINED",
"vectorString": "CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N",
"version": "4.0",
"vulnAvailabilityImpact": "NONE",
"vulnConfidentialityImpact": "NONE",
"vulnIntegrityImpact": "LOW",
"vulnerabilityResponseEffort": "NOT_DEFINED"
},
"format": "CVSS",
"scenarios": [
{
"lang": "en",
"value": "GENERAL"
}
]
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-704",
"description": "CWE-704 Incorrect Type Conversion or Cast",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-10-08T13:41:05.745Z",
"orgId": "6b3ad84c-e1a6-4bf7-a703-f496b71e49db",
"shortName": "EEF"
},
"references": [
{
"name": "GitHub Advisory",
"tags": [
"related",
"vendor-advisory"
],
"url": "https://github.com/ScriptKittyOS/beam_mcp/security/advisories/GHSA-wv7p-j6qh-3hj4"
},
{
"name": "EEF CNA record for CVE-2026-104634",
"tags": [
"related"
],
"url": "https://cna.erlef.org/cves/CVE-2026-104634.html"
},
{
"name": "OSV record EEF-CVE-2026-104634",
"tags": [
"related"
],
"url": "https://osv.dev/vulnerability/EEF-CVE-2026-104634"
},
{
"name": "Introducing commit 083838e in ScriptKittyOS/beam_mcp",
"tags": [
"related"
],
"url": "https://github.com/ScriptKittyOS/beam_mcp/commit/083838eb8e17fe5f6fcaf761bdbe203110288b0b"
},
{
"name": "Fix commit 289dbdb in ScriptKittyOS/beam_mcp",
"tags": [
"patch"
],
"url": "https://github.com/ScriptKittyOS/beam_mcp/commit/289dbdbad641943b29a3b8d1eb36506cc8cec10a"
}
],
"source": {
"discovery": "INTERNAL"
},
"title": "beam_mcp: JSON boolean and null tool arguments reach dispatch as strings",
"workarounds": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003eIn the host\u0027s dispatch function, compare boolean arguments against both forms, for example \u003ccode\u003eargs.flag in [true, \"true\"]\u003c/code\u003e and \u003ccode\u003eargs.flag in [false, \"false\"]\u003c/code\u003e, and treat the string \"nil\" as \u003ccode\u003enull\u003c/code\u003e where the schema admits null.\u003c/p\u003e"
},
{
"base64": false,
"type": "text/markdown",
"value": "In the host\u0027s dispatch function, compare boolean arguments against both forms, for example `args.flag in [true, \"true\"]` and `args.flag in [false, \"false\"]`, and treat the string \"nil\" as `null` where the schema admits null."
}
],
"value": "In the host\u0027s dispatch function, compare boolean arguments against both forms, for example args.flag in [true, \"true\"] and args.flag in [false, \"false\"], and treat the string \"nil\" as null where the schema admits null."
}
],
"x_proofOfConcept": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003col\u003e\n\u003cli\u003eDeclare a tool whose \u003ccode\u003einput_schema\u003c/code\u003e has \u003ccode\u003e\"dry_run\": {\"type\": \"boolean\"}\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eSend \u003ccode\u003etools/call\u003c/code\u003e with \u003ccode\u003e\"arguments\": {\"dry_run\": false}\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eOn beam_mcp 0.10.0 the dispatch function receives \u003ccode\u003e%{dry_run: \"false\"}\u003c/code\u003e and \u003ccode\u003eif args.dry_run\u003c/code\u003e evaluates the true branch. On 0.10.1 it receives \u003ccode\u003e%{dry_run: false}\u003c/code\u003e.\u003c/li\u003e\n\u003c/ol\u003e"
},
{
"base64": false,
"type": "text/markdown",
"value": "1. Declare a tool whose `input_schema` has `\"dry_run\": {\"type\": \"boolean\"}`.\n2. Send `tools/call` with `\"arguments\": {\"dry_run\": false}`.\n3. On beam_mcp 0.10.0 the dispatch function receives `%{dry_run: \"false\"}` and `if args.dry_run` evaluates the true branch. On 0.10.1 it receives `%{dry_run: false}`."
}
],
"value": "* Declare a tool whose input_schema has \"dry_run\": {\"type\": \"boolean\"}.\n* Send tools/call with \"arguments\": {\"dry_run\": false}.\n* On beam_mcp 0.10.0 the dispatch function receives %{dry_run: \"false\"} and if args.dry_run evaluates the true branch. On 0.10.1 it receives %{dry_run: false}."
}
],
"x_technicalAnalysis": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003e\u003cstrong\u003e1. Validation.\u003c/strong\u003e \u003ccode\u003eBeamMCP.Schema.check_type/3\u003c/code\u003e accepts a JSON \u003ccode\u003efalse\u003c/code\u003e for a \u003ccode\u003eboolean\u003c/code\u003e property because the decoded value is the atom \u003ccode\u003efalse\u003c/code\u003e.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e2. Normalisation.\u003c/strong\u003e \u003ccode\u003eBeamMCP.Server.normalize_arguments/2\u003c/code\u003e in \u003ccode\u003elib/beam_mcp/server.ex\u003c/code\u003e maps each declared key to an atom and passes each value through \u003ccode\u003eto_json_value/1\u003c/code\u003e. That function was written to encode host results for the wire, and its clause \u003ccode\u003ewhen is_atom(value)\u003c/code\u003e converts the value with \u003ccode\u003eAtom.to_string/1\u003c/code\u003e. \u003ccode\u003etrue\u003c/code\u003e, \u003ccode\u003efalse\u003c/code\u003e and \u003ccode\u003enil\u003c/code\u003e are atoms, so they become the strings \"true\", \"false\" and \"nil\", at any depth of the argument map.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e3. Dispatch.\u003c/strong\u003e The host receives \u003ccode\u003e%{dry_run: \"false\"}\u003c/code\u003e. Any string is truthy in Elixir, so \u003ccode\u003eif args.dry_run\u003c/code\u003e takes the true branch. A host result carrying booleans was stringified the same way on the way out. The fix in 0.10.1 adds a clause that passes booleans and \u003ccode\u003enil\u003c/code\u003e through unchanged.\u003c/p\u003e"
},
{
"base64": false,
"type": "text/markdown",
"value": "**1. Validation.** `BeamMCP.Schema.check_type/3` accepts a JSON `false` for a `boolean` property because the decoded value is the atom `false`.\n\n**2. Normalisation.** `BeamMCP.Server.normalize_arguments/2` in `lib/beam_mcp/server.ex` maps each declared key to an atom and passes each value through `to_json_value/1`. That function was written to encode host results for the wire, and its clause `when is_atom(value)` converts the value with `Atom.to_string/1`. `true`, `false` and `nil` are atoms, so they become the strings \"true\", \"false\" and \"nil\", at any depth of the argument map.\n\n**3. Dispatch.** The host receives `%{dry_run: \"false\"}`. Any string is truthy in Elixir, so `if args.dry_run` takes the true branch. A host result carrying booleans was stringified the same way on the way out. The fix in 0.10.1 adds a clause that passes booleans and `nil` through unchanged."
}
],
"value": "1. Validation. BeamMCP.Schema.check_type/3 accepts a JSON false for a boolean property because the decoded value is the atom false.\n\n2. Normalisation. BeamMCP.Server.normalize_arguments/2 in lib/beam_mcp/server.ex maps each declared key to an atom and passes each value through to_json_value/1. That function was written to encode host results for the wire, and its clause when is_atom(value) converts the value with Atom.to_string/1. true, false and nil are atoms, so they become the strings \"true\", \"false\" and \"nil\", at any depth of the argument map.\n\n3. Dispatch. The host receives %{dry_run: \"false\"}. Any string is truthy in Elixir, so if args.dry_run takes the true branch. A host result carrying booleans was stringified the same way on the way out. The fix in 0.10.1 adds a clause that passes booleans and nil through unchanged."
}
]
}
},
"cveMetadata": {
"assignerOrgId": "6b3ad84c-e1a6-4bf7-a703-f496b71e49db",
"assignerShortName": "EEF",
"cveId": "CVE-2026-104634",
"datePublished": "2026-10-08T13:41:05.745Z",
"dateReserved": "2026-10-04T16:00:02.420Z",
"dateUpdated": "2026-10-08T13:58:34.464Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
CVE-2026-88257 (GCVE-0-2026-88257)
Vulnerability from cvelistv5 – Published: 2026-10-08 13:40 – Updated: 2026-10-08 14:09
VLAI
EPSS
VEX
Title
beam_mcp: nested tool argument constraints advertised but not enforced
Summary
Improper Input Validation vulnerability in BeamMCP.Schema in ScriptKittyOS beam_mcp allows an MCP client to reach a tool's dispatch function with arguments that violate the input schema the server advertised. BeamMCP.Schema.validate/2 checked type, required, additionalProperties, enum and numeric bounds on the top-level arguments object only. Constraints inside nested objects and on array items (items, minItems, maxItems, minLength, maxLength, pattern, nested required, enum and additionalProperties: false) were advertised by tools/list and never checked at tools/call or prompts/get, and keywords outside the enforced subset (oneOf, anyOf, $ref) were advertised and ignored.
A host whose dispatch code relies on the schema it declared receives values the schema forbids, such as an out-of-range number or an undeclared key inside a nested object. What the host does with such a value decides the impact.
This issue affects beam_mcp: from 0.1.0 before 0.10.1.
Severity
SSVC
Exploitation: none
Automatable: no
Technical Impact: partial
CISA Coordinator · CISA-ADP (v2.0.3)
Decision recorded 2026-10-08 13:59 UTC
CWE
- CWE-20 - Improper Input Validation
Assigner
References
5 references
| URL | Tags |
|---|---|
| https://github.com/ScriptKittyOS/beam_mcp/securit… | relatedvendor-advisory |
| https://cna.erlef.org/cves/CVE-2026-88257.html | related |
| https://osv.dev/vulnerability/EEF-CVE-2026-88257 | related |
| https://github.com/ScriptKittyOS/beam_mcp/commit/… | related |
| https://github.com/ScriptKittyOS/beam_mcp/commit/… | patch |
Impacted products
2 products
| Vendor | Product | Version | |
|---|---|---|---|
| ScriptKittyOS | beam_mcp |
Affected:
0.1.0 , < 0.10.1
(semver)
cpe:2.3:a:scriptkittyos:beam_mcp:*:*:*:*:*:*:*:* |
|
| ScriptKittyOS | beam_mcp |
Affected:
083838eb8e17fe5f6fcaf761bdbe203110288b0b , < 289dbdbad641943b29a3b8d1eb36506cc8cec10a
(git)
cpe:2.3:a:scriptkittyos:beam_mcp:*:*:*:*:*:*:*:* |
Date Public
2026-09-26 00:00
{
"containers": {
"adp": [
{
"metrics": [
{
"other": {
"content": {
"id": "CVE-2026-88257",
"options": [
{
"Exploitation": "none"
},
{
"Automatable": "no"
},
{
"Technical Impact": "partial"
}
],
"role": "CISA Coordinator",
"timestamp": "2026-10-08T13:59:14.866448Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"providerMetadata": {
"dateUpdated": "2026-10-08T13:59:33.374Z",
"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"shortName": "CISA-ADP"
},
"title": "CISA ADP Vulnrichment"
}
],
"cna": {
"affected": [
{
"collectionURL": "https://repo.hex.pm",
"cpes": [
"cpe:2.3:a:scriptkittyos:beam_mcp:*:*:*:*:*:*:*:*"
],
"defaultStatus": "unaffected",
"modules": [
"\u0027Elixir.BeamMCP.Schema\u0027",
"\u0027Elixir.BeamMCP.Server\u0027"
],
"packageName": "beam_mcp",
"packageURL": "pkg:hex/beam_mcp",
"product": "beam_mcp",
"programFiles": [
"lib/beam_mcp/schema.ex",
"lib/beam_mcp/server.ex"
],
"programRoutines": [
{
"name": "\u0027Elixir.BeamMCP.Schema\u0027:validate/2"
},
{
"name": "\u0027Elixir.BeamMCP.Server\u0027:handle_message/2"
}
],
"repo": "https://github.com/ScriptKittyOS/beam_mcp",
"vendor": "ScriptKittyOS",
"versions": [
{
"lessThan": "0.10.1",
"status": "affected",
"version": "0.1.0",
"versionType": "semver"
}
]
},
{
"collectionURL": "https://github.com",
"cpes": [
"cpe:2.3:a:scriptkittyos:beam_mcp:*:*:*:*:*:*:*:*"
],
"defaultStatus": "unaffected",
"modules": [
"\u0027Elixir.BeamMCP.Schema\u0027",
"\u0027Elixir.BeamMCP.Server\u0027"
],
"packageName": "scriptkittyos/beam_mcp",
"packageURL": "pkg:github/scriptkittyos/beam_mcp",
"product": "beam_mcp",
"programFiles": [
"lib/beam_mcp/schema.ex",
"lib/beam_mcp/server.ex"
],
"programRoutines": [
{
"name": "\u0027Elixir.BeamMCP.Schema\u0027:validate/2"
},
{
"name": "\u0027Elixir.BeamMCP.Server\u0027:handle_message/2"
}
],
"repo": "https://github.com/ScriptKittyOS/beam_mcp",
"vendor": "ScriptKittyOS",
"versions": [
{
"lessThan": "289dbdbad641943b29a3b8d1eb36506cc8cec10a",
"status": "affected",
"version": "083838eb8e17fe5f6fcaf761bdbe203110288b0b",
"versionType": "git"
}
]
}
],
"cpeApplicability": [
{
"nodes": [
{
"cpeMatch": [
{
"criteria": "cpe:2.3:a:scriptkittyos:beam_mcp:*:*:*:*:*:*:*:*",
"versionEndExcluding": "0.10.1",
"versionStartIncluding": "0.1.0",
"vulnerable": true
}
],
"negate": false,
"operator": "OR"
}
],
"operator": "AND"
}
],
"credits": [
{
"lang": "en",
"type": "finder",
"value": "Ayla Croft / Script Kitty OS"
},
{
"lang": "en",
"type": "reporter",
"value": "Ayla Croft / Script Kitty OS"
},
{
"lang": "en",
"type": "remediation developer",
"value": "Ayla Croft / Script Kitty OS"
},
{
"lang": "en",
"type": "coordinator",
"value": "Jonatan M\u00e4nnchen / EEF"
}
],
"dateAssigned": "2026-10-08T13:40:44.000Z",
"datePublic": "2026-09-26T00:00:00.000Z",
"descriptions": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003eImproper Input Validation vulnerability in \u003ccode\u003eBeamMCP.Schema\u003c/code\u003e in ScriptKittyOS beam_mcp allows an MCP client to reach a tool\u0027s dispatch function with arguments that violate the input schema the server advertised. \u003ccode\u003eBeamMCP.Schema.validate/2\u003c/code\u003e checked \u003ccode\u003etype\u003c/code\u003e, \u003ccode\u003erequired\u003c/code\u003e, \u003ccode\u003eadditionalProperties\u003c/code\u003e, \u003ccode\u003eenum\u003c/code\u003e and numeric bounds on the top-level arguments object only. Constraints inside nested objects and on array items (\u003ccode\u003eitems\u003c/code\u003e, \u003ccode\u003eminItems\u003c/code\u003e, \u003ccode\u003emaxItems\u003c/code\u003e, \u003ccode\u003eminLength\u003c/code\u003e, \u003ccode\u003emaxLength\u003c/code\u003e, \u003ccode\u003epattern\u003c/code\u003e, nested \u003ccode\u003erequired\u003c/code\u003e, \u003ccode\u003eenum\u003c/code\u003e and \u003ccode\u003eadditionalProperties: false\u003c/code\u003e) were advertised by \u003ccode\u003etools/list\u003c/code\u003e and never checked at \u003ccode\u003etools/call\u003c/code\u003e or \u003ccode\u003eprompts/get\u003c/code\u003e, and keywords outside the enforced subset (\u003ccode\u003eoneOf\u003c/code\u003e, \u003ccode\u003eanyOf\u003c/code\u003e, \u003ccode\u003e$ref\u003c/code\u003e) were advertised and ignored.\u003c/p\u003e\n\u003cp\u003eA host whose dispatch code relies on the schema it declared receives values the schema forbids, such as an out-of-range number or an undeclared key inside a nested object. What the host does with such a value decides the impact.\u003c/p\u003e\n\u003cp\u003eThis issue affects beam_mcp: from 0.1.0 before 0.10.1.\u003c/p\u003e"
},
{
"base64": false,
"type": "text/markdown",
"value": "Improper Input Validation vulnerability in `BeamMCP.Schema` in ScriptKittyOS beam_mcp allows an MCP client to reach a tool\u0027s dispatch function with arguments that violate the input schema the server advertised. `BeamMCP.Schema.validate/2` checked `type`, `required`, `additionalProperties`, `enum` and numeric bounds on the top-level arguments object only. Constraints inside nested objects and on array items (`items`, `minItems`, `maxItems`, `minLength`, `maxLength`, `pattern`, nested `required`, `enum` and `additionalProperties: false`) were advertised by `tools/list` and never checked at `tools/call` or `prompts/get`, and keywords outside the enforced subset (`oneOf`, `anyOf`, `$ref`) were advertised and ignored.\n\nA host whose dispatch code relies on the schema it declared receives values the schema forbids, such as an out-of-range number or an undeclared key inside a nested object. What the host does with such a value decides the impact.\n\nThis issue affects beam_mcp: from 0.1.0 before 0.10.1."
}
],
"value": "Improper Input Validation vulnerability in BeamMCP.Schema in ScriptKittyOS beam_mcp allows an MCP client to reach a tool\u0027s dispatch function with arguments that violate the input schema the server advertised. BeamMCP.Schema.validate/2 checked type, required, additionalProperties, enum and numeric bounds on the top-level arguments object only. Constraints inside nested objects and on array items (items, minItems, maxItems, minLength, maxLength, pattern, nested required, enum and additionalProperties: false) were advertised by tools/list and never checked at tools/call or prompts/get, and keywords outside the enforced subset (oneOf, anyOf, $ref) were advertised and ignored.\n\nA host whose dispatch code relies on the schema it declared receives values the schema forbids, such as an out-of-range number or an undeclared key inside a nested object. What the host does with such a value decides the impact.\n\nThis issue affects beam_mcp: from 0.1.0 before 0.10.1."
}
],
"impacts": [
{
"capecId": "CAPEC-153",
"descriptions": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003eAn MCP client can hand a host\u0027s tool values the host\u0027s declared schema forbids, such as an out-of-range number or an undeclared key inside a nested object. The consequence depends on what the host\u0027s dispatch code does with a value it never expected to receive.\u003c/p\u003e"
},
{
"base64": false,
"type": "text/markdown",
"value": "An MCP client can hand a host\u0027s tool values the host\u0027s declared schema forbids, such as an out-of-range number or an undeclared key inside a nested object. The consequence depends on what the host\u0027s dispatch code does with a value it never expected to receive."
}
],
"value": "An MCP client can hand a host\u0027s tool values the host\u0027s declared schema forbids, such as an out-of-range number or an undeclared key inside a nested object. The consequence depends on what the host\u0027s dispatch code does with a value it never expected to receive."
}
]
}
],
"metrics": [
{
"cvssV4_0": {
"Automatable": "NOT_DEFINED",
"Recovery": "NOT_DEFINED",
"Safety": "NOT_DEFINED",
"attackComplexity": "LOW",
"attackRequirements": "NONE",
"attackVector": "NETWORK",
"baseScore": 5.3,
"baseSeverity": "MEDIUM",
"privilegesRequired": "LOW",
"providerUrgency": "NOT_DEFINED",
"subAvailabilityImpact": "NONE",
"subConfidentialityImpact": "NONE",
"subIntegrityImpact": "NONE",
"userInteraction": "NONE",
"valueDensity": "NOT_DEFINED",
"vectorString": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N",
"version": "4.0",
"vulnAvailabilityImpact": "NONE",
"vulnConfidentialityImpact": "NONE",
"vulnIntegrityImpact": "LOW",
"vulnerabilityResponseEffort": "NOT_DEFINED"
},
"format": "CVSS",
"scenarios": [
{
"lang": "en",
"value": "GENERAL"
}
]
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-20",
"description": "CWE-20 Improper Input Validation",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-10-08T14:09:41.540Z",
"orgId": "6b3ad84c-e1a6-4bf7-a703-f496b71e49db",
"shortName": "EEF"
},
"references": [
{
"name": "GitHub Advisory",
"tags": [
"related",
"vendor-advisory"
],
"url": "https://github.com/ScriptKittyOS/beam_mcp/security/advisories/GHSA-mrg2-4747-fmpw"
},
{
"name": "EEF CNA record for CVE-2026-88257",
"tags": [
"related"
],
"url": "https://cna.erlef.org/cves/CVE-2026-88257.html"
},
{
"name": "OSV record EEF-CVE-2026-88257",
"tags": [
"related"
],
"url": "https://osv.dev/vulnerability/EEF-CVE-2026-88257"
},
{
"name": "Introducing commit 083838e in ScriptKittyOS/beam_mcp",
"tags": [
"related"
],
"url": "https://github.com/ScriptKittyOS/beam_mcp/commit/083838eb8e17fe5f6fcaf761bdbe203110288b0b"
},
{
"name": "Fix commit 289dbdb in ScriptKittyOS/beam_mcp",
"tags": [
"patch"
],
"url": "https://github.com/ScriptKittyOS/beam_mcp/commit/289dbdbad641943b29a3b8d1eb36506cc8cec10a"
}
],
"source": {
"discovery": "INTERNAL"
},
"title": "beam_mcp: nested tool argument constraints advertised but not enforced",
"workarounds": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003eRe-validate the arguments inside the host\u0027s dispatch function against every constraint the schema declares below the top level, or move each constraint to a top-level property, which the affected versions do enforce.\u003c/p\u003e"
},
{
"base64": false,
"type": "text/markdown",
"value": "Re-validate the arguments inside the host\u0027s dispatch function against every constraint the schema declares below the top level, or move each constraint to a top-level property, which the affected versions do enforce."
}
],
"value": "Re-validate the arguments inside the host\u0027s dispatch function against every constraint the schema declares below the top level, or move each constraint to a top-level property, which the affected versions do enforce."
}
],
"x_proofOfConcept": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003col\u003e\n\u003cli\u003eDeclare a tool whose \u003ccode\u003einput_schema\u003c/code\u003e has a nested object property \u003ccode\u003eopts\u003c/code\u003e with \u003ccode\u003e\"properties\": {\"level\": {\"type\": \"integer\", \"maximum\": 3}}\u003c/code\u003e, \u003ccode\u003e\"required\": [\"level\"]\u003c/code\u003e and \u003ccode\u003e\"additionalProperties\": false\u003c/code\u003e, and an array property \u003ccode\u003etags\u003c/code\u003e with \u003ccode\u003e\"items\": {\"type\": \"string\"}\u003c/code\u003e and \u003ccode\u003e\"maxItems\": 2\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eSend \u003ccode\u003etools/call\u003c/code\u003e with \u003ccode\u003e\"arguments\": {\"opts\": {\"level\": 99, \"extra\": \"x\"}}\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eOn beam_mcp 0.10.0 the dispatch function receives \u003ccode\u003e%{opts: %{\"extra\" =\u0026gt; \"x\", \"level\" =\u0026gt; 99}}\u003c/code\u003e. On 0.10.1 the call is refused with \u003ccode\u003einvalid arguments: unknown property: opts.extra\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eSend \u003ccode\u003e\"arguments\": {\"tags\": [1, 2, 3]}\u003c/code\u003e. On 0.10.0 the dispatch function receives \u003ccode\u003etags: [1, 2, 3]\u003c/code\u003e. On 0.10.1 the call is refused with \u003ccode\u003etags must have at most 2 items\u003c/code\u003e.\u003c/li\u003e\n\u003c/ol\u003e"
},
{
"base64": false,
"type": "text/markdown",
"value": "1. Declare a tool whose `input_schema` has a nested object property `opts` with `\"properties\": {\"level\": {\"type\": \"integer\", \"maximum\": 3}}`, `\"required\": [\"level\"]` and `\"additionalProperties\": false`, and an array property `tags` with `\"items\": {\"type\": \"string\"}` and `\"maxItems\": 2`.\n2. Send `tools/call` with `\"arguments\": {\"opts\": {\"level\": 99, \"extra\": \"x\"}}`.\n3. On beam_mcp 0.10.0 the dispatch function receives `%{opts: %{\"extra\" =\u003e \"x\", \"level\" =\u003e 99}}`. On 0.10.1 the call is refused with `invalid arguments: unknown property: opts.extra`.\n4. Send `\"arguments\": {\"tags\": [1, 2, 3]}`. On 0.10.0 the dispatch function receives `tags: [1, 2, 3]`. On 0.10.1 the call is refused with `tags must have at most 2 items`."
}
],
"value": "* Declare a tool whose input_schema has a nested object property opts with \"properties\": {\"level\": {\"type\": \"integer\", \"maximum\": 3}}, \"required\": [\"level\"] and \"additionalProperties\": false, and an array property tags with \"items\": {\"type\": \"string\"} and \"maxItems\": 2.\n* Send tools/call with \"arguments\": {\"opts\": {\"level\": 99, \"extra\": \"x\"}}.\n* On beam_mcp 0.10.0 the dispatch function receives %{opts: %{\"extra\" =\u003e \"x\", \"level\" =\u003e 99}}. On 0.10.1 the call is refused with invalid arguments: unknown property: opts.extra.\n* Send \"arguments\": {\"tags\": [1, 2, 3]}. On 0.10.0 the dispatch function receives tags: [1, 2, 3]. On 0.10.1 the call is refused with tags must have at most 2 items."
}
],
"x_technicalAnalysis": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003e\u003cstrong\u003e1. Advertising.\u003c/strong\u003e \u003ccode\u003etools/list\u003c/code\u003e returns each tool\u0027s \u003ccode\u003einput_schema\u003c/code\u003e verbatim, including nested \u003ccode\u003eproperties\u003c/code\u003e, \u003ccode\u003eitems\u003c/code\u003e and constraint keywords.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e2. Validation.\u003c/strong\u003e \u003ccode\u003eBeamMCP.Schema.validate/2\u003c/code\u003e in \u003ccode\u003elib/beam_mcp/schema.ex\u003c/code\u003e walks only the first level: \u003ccode\u003echeck_required/2\u003c/code\u003e and \u003ccode\u003echeck_additional/3\u003c/code\u003e run on the top-level object, and \u003ccode\u003echeck_properties/2\u003c/code\u003e applies \u003ccode\u003echeck_type\u003c/code\u003e, \u003ccode\u003echeck_enum\u003c/code\u003e and \u003ccode\u003echeck_range\u003c/code\u003e to each top-level value. A value of type \u003ccode\u003eobject\u003c/code\u003e or \u003ccode\u003earray\u003c/code\u003e is accepted once its own type matches, and its contents are not visited. Keywords the validator does not know are ignored.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e3. Dispatch.\u003c/strong\u003e \u003ccode\u003eBeamMCP.Server.validate_and_dispatch/3\u003c/code\u003e passes the accepted arguments to \u003ccode\u003enormalize_arguments/2\u003c/code\u003e and then to the host\u0027s dispatch function, so an undeclared key inside a nested object, an out-of-range nested number, or an array item of the wrong type reaches host code that believed the schema excluded it. The same validator runs on \u003ccode\u003eprompts/get\u003c/code\u003e arguments. The fix in 0.10.1 enforces every keyword of the documented subset at every depth and refuses a schema that uses any other keyword when the catalog is loaded.\u003c/p\u003e"
},
{
"base64": false,
"type": "text/markdown",
"value": "**1. Advertising.** `tools/list` returns each tool\u0027s `input_schema` verbatim, including nested `properties`, `items` and constraint keywords.\n\n**2. Validation.** `BeamMCP.Schema.validate/2` in `lib/beam_mcp/schema.ex` walks only the first level: `check_required/2` and `check_additional/3` run on the top-level object, and `check_properties/2` applies `check_type`, `check_enum` and `check_range` to each top-level value. A value of type `object` or `array` is accepted once its own type matches, and its contents are not visited. Keywords the validator does not know are ignored.\n\n**3. Dispatch.** `BeamMCP.Server.validate_and_dispatch/3` passes the accepted arguments to `normalize_arguments/2` and then to the host\u0027s dispatch function, so an undeclared key inside a nested object, an out-of-range nested number, or an array item of the wrong type reaches host code that believed the schema excluded it. The same validator runs on `prompts/get` arguments. The fix in 0.10.1 enforces every keyword of the documented subset at every depth and refuses a schema that uses any other keyword when the catalog is loaded."
}
],
"value": "1. Advertising. tools/list returns each tool\u0027s input_schema verbatim, including nested properties, items and constraint keywords.\n\n2. Validation. BeamMCP.Schema.validate/2 in lib/beam_mcp/schema.ex walks only the first level: check_required/2 and check_additional/3 run on the top-level object, and check_properties/2 applies check_type, check_enum and check_range to each top-level value. A value of type object or array is accepted once its own type matches, and its contents are not visited. Keywords the validator does not know are ignored.\n\n3. Dispatch. BeamMCP.Server.validate_and_dispatch/3 passes the accepted arguments to normalize_arguments/2 and then to the host\u0027s dispatch function, so an undeclared key inside a nested object, an out-of-range nested number, or an array item of the wrong type reaches host code that believed the schema excluded it. The same validator runs on prompts/get arguments. The fix in 0.10.1 enforces every keyword of the documented subset at every depth and refuses a schema that uses any other keyword when the catalog is loaded."
}
]
}
},
"cveMetadata": {
"assignerOrgId": "6b3ad84c-e1a6-4bf7-a703-f496b71e49db",
"assignerShortName": "EEF",
"cveId": "CVE-2026-88257",
"datePublished": "2026-10-08T13:40:55.828Z",
"dateReserved": "2026-10-07T22:15:01.878Z",
"dateUpdated": "2026-10-08T14:09:41.540Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
CVE-2026-94206 (GCVE-0-2026-94206)
Vulnerability from cvelistv5 – Published: 2026-10-06 08:38 – Updated: 2026-10-06 11:36
VLAI
EPSS
VEX
Title
Cloak PBKDF2 field ignores the configured iteration count and runs only :size rounds
Summary
Use of Password Hash With Insufficient Computational Effort vulnerability in danielberkompas cloak_ecto and danielberkompas cloak allows an attacker who holds the hashed values and the configured secret to brute-force low-entropy plaintexts much faster than configured.
The dump/1 callback that Cloak.Ecto.PBKDF2 (Cloak.Fields.PBKDF2 in cloak before the Ecto code moved to cloak_ecto) injects into a field module calls :pbkdf2.pbkdf2/4 with config[:size] in the iteration-count position. The :iterations setting is validated but never used. With the cloak_ecto defaults (iterations: 600_000, size: 32) each hash runs 32 PBKDF2 rounds instead of 600,000, so offline guessing of values such as email addresses costs about 18,750 times less than configured.
This issue affects cloak_ecto: from 1.0.0-alpha.0 onward; cloak: from 0.7.0 before 1.0.0-alpha.0.
Severity
SSVC
Exploitation: poc
Automatable: no
Technical Impact: partial
CISA Coordinator · CISA-ADP (v2.0.3)
Decision recorded 2026-10-06 11:34 UTC
CWE
- CWE-916 - Use of Password Hash With Insufficient Computational Effort
Assigner
References
5 references
| URL | Tags |
|---|---|
| https://cna.erlef.org/cves/CVE-2026-94206.html | relatedthird-party-advisory |
| https://osv.dev/vulnerability/EEF-CVE-2026-94206 | related |
| https://github.com/danielberkompas/cloak_ecto/com… | related |
| https://github.com/danielberkompas/cloak/commit/8… | related |
| https://github.com/danielberkompas/cloak/commit/6… | patch |
Impacted products
4 products
| Vendor | Product | Version | |
|---|---|---|---|
| danielberkompas | cloak_ecto |
Affected:
1.0.0-alpha.0 , < *
(semver)
cpe:2.3:a:danielberkompas:cloak_ecto:*:*:*:*:*:*:*:* |
|
| danielberkompas | cloak_ecto |
Affected:
a8fa1642b02f1c445a1ee8794c9095eb0921f8f3 , < *
(git)
cpe:2.3:a:danielberkompas:cloak_ecto:*:*:*:*:*:*:*:* |
|
| danielberkompas | cloak |
Affected:
0.7.0 , < 1.0.0-alpha.0
(semver)
cpe:2.3:a:danielberkompas:cloak:*:*:*:*:*:*:*:* |
|
| danielberkompas | cloak |
Affected:
8699e6417a162c39d9f0ef63511bd23d3f38d1d2 , < 681c9702b7cd9afe0e5a840751ab009f550c69a9
(git)
cpe:2.3:a:danielberkompas:cloak:*:*:*:*:*:*:*:* |
{
"containers": {
"adp": [
{
"metrics": [
{
"other": {
"content": {
"id": "CVE-2026-94206",
"options": [
{
"Exploitation": "poc"
},
{
"Automatable": "no"
},
{
"Technical Impact": "partial"
}
],
"role": "CISA Coordinator",
"timestamp": "2026-10-06T11:34:00.942993Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"providerMetadata": {
"dateUpdated": "2026-10-06T11:36:25.466Z",
"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"shortName": "CISA-ADP"
},
"title": "CISA ADP Vulnrichment"
}
],
"cna": {
"affected": [
{
"collectionURL": "https://repo.hex.pm",
"cpes": [
"cpe:2.3:a:danielberkompas:cloak_ecto:*:*:*:*:*:*:*:*"
],
"defaultStatus": "unaffected",
"modules": [
"\u0027Elixir.Cloak.Ecto.PBKDF2\u0027"
],
"packageName": "cloak_ecto",
"packageURL": "pkg:hex/cloak_ecto",
"product": "cloak_ecto",
"programFiles": [
"lib/cloak_ecto/types/pbkdf2.ex"
],
"repo": "https://github.com/danielberkompas/cloak_ecto",
"vendor": "danielberkompas",
"versions": [
{
"lessThan": "*",
"status": "affected",
"version": "1.0.0-alpha.0",
"versionType": "semver"
}
]
},
{
"collectionURL": "https://github.com",
"cpes": [
"cpe:2.3:a:danielberkompas:cloak_ecto:*:*:*:*:*:*:*:*"
],
"defaultStatus": "unaffected",
"modules": [
"\u0027Elixir.Cloak.Ecto.PBKDF2\u0027"
],
"packageName": "danielberkompas/cloak_ecto",
"packageURL": "pkg:github/danielberkompas/cloak_ecto",
"product": "cloak_ecto",
"programFiles": [
"lib/cloak_ecto/types/pbkdf2.ex"
],
"repo": "https://github.com/danielberkompas/cloak_ecto",
"vendor": "danielberkompas",
"versions": [
{
"lessThan": "*",
"status": "affected",
"version": "a8fa1642b02f1c445a1ee8794c9095eb0921f8f3",
"versionType": "git"
}
]
},
{
"collectionURL": "https://repo.hex.pm",
"cpes": [
"cpe:2.3:a:danielberkompas:cloak:*:*:*:*:*:*:*:*"
],
"defaultStatus": "unaffected",
"modules": [
"\u0027Elixir.Cloak.Fields.PBKDF2\u0027"
],
"packageName": "cloak",
"packageURL": "pkg:hex/cloak",
"product": "cloak",
"programFiles": [
"lib/cloak/fields/pbkdf2.ex"
],
"repo": "https://github.com/danielberkompas/cloak",
"vendor": "danielberkompas",
"versions": [
{
"lessThan": "1.0.0-alpha.0",
"status": "affected",
"version": "0.7.0",
"versionType": "semver"
}
]
},
{
"collectionURL": "https://github.com",
"cpes": [
"cpe:2.3:a:danielberkompas:cloak:*:*:*:*:*:*:*:*"
],
"defaultStatus": "unaffected",
"modules": [
"\u0027Elixir.Cloak.Fields.PBKDF2\u0027"
],
"packageName": "danielberkompas/cloak",
"packageURL": "pkg:github/danielberkompas/cloak",
"product": "cloak",
"programFiles": [
"lib/cloak/fields/pbkdf2.ex"
],
"repo": "https://github.com/danielberkompas/cloak",
"vendor": "danielberkompas",
"versions": [
{
"lessThan": "681c9702b7cd9afe0e5a840751ab009f550c69a9",
"status": "affected",
"version": "8699e6417a162c39d9f0ef63511bd23d3f38d1d2",
"versionType": "git"
}
]
}
],
"cpeApplicability": [
{
"nodes": [
{
"cpeMatch": [
{
"criteria": "cpe:2.3:a:danielberkompas:cloak_ecto:*:*:*:*:*:*:*:*",
"versionStartIncluding": "1.0.0-alpha.0",
"vulnerable": true
},
{
"criteria": "cpe:2.3:a:danielberkompas:cloak:*:*:*:*:*:*:*:*",
"versionEndExcluding": "1.0.0-alpha.0",
"versionStartIncluding": "0.7.0",
"vulnerable": true
}
],
"negate": false,
"operator": "OR"
}
],
"operator": "AND"
}
],
"credits": [
{
"lang": "en",
"type": "finder",
"value": "Peter Ullrich"
},
{
"lang": "en",
"type": "reporter",
"value": "Peter Ullrich"
},
{
"lang": "en",
"type": "coordinator",
"value": "Jonatan M\u00e4nnchen / EEF"
}
],
"dateAssigned": "2026-10-06T08:35:00.000Z",
"descriptions": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003eUse of Password Hash With Insufficient Computational Effort vulnerability in danielberkompas cloak_ecto and danielberkompas cloak allows an attacker who holds the hashed values and the configured secret to brute-force low-entropy plaintexts much faster than configured.\u003c/p\u003e\n\u003cp\u003eThe \u003ccode\u003edump/1\u003c/code\u003e callback that \u003ccode\u003eCloak.Ecto.PBKDF2\u003c/code\u003e (\u003ccode\u003eCloak.Fields.PBKDF2\u003c/code\u003e in cloak before the Ecto code moved to cloak_ecto) injects into a field module calls \u003ccode\u003e:pbkdf2.pbkdf2/4\u003c/code\u003e with \u003ccode\u003econfig[:size]\u003c/code\u003e in the iteration-count position. The \u003ccode\u003e:iterations\u003c/code\u003e setting is validated but never used. With the cloak_ecto defaults (\u003ccode\u003eiterations: 600_000\u003c/code\u003e, \u003ccode\u003esize: 32\u003c/code\u003e) each hash runs 32 PBKDF2 rounds instead of 600,000, so offline guessing of values such as email addresses costs about 18,750 times less than configured.\u003c/p\u003e\n\u003cp\u003eThis issue affects cloak_ecto: from 1.0.0-alpha.0 onward; cloak: from 0.7.0 before 1.0.0-alpha.0.\u003c/p\u003e"
},
{
"base64": false,
"type": "text/markdown",
"value": "Use of Password Hash With Insufficient Computational Effort vulnerability in danielberkompas cloak_ecto and danielberkompas cloak allows an attacker who holds the hashed values and the configured secret to brute-force low-entropy plaintexts much faster than configured.\n\nThe `dump/1` callback that `Cloak.Ecto.PBKDF2` (`Cloak.Fields.PBKDF2` in cloak before the Ecto code moved to cloak_ecto) injects into a field module calls `:pbkdf2.pbkdf2/4` with `config[:size]` in the iteration-count position. The `:iterations` setting is validated but never used. With the cloak_ecto defaults (`iterations: 600_000`, `size: 32`) each hash runs 32 PBKDF2 rounds instead of 600,000, so offline guessing of values such as email addresses costs about 18,750 times less than configured.\n\nThis issue affects cloak_ecto: from 1.0.0-alpha.0 onward; cloak: from 0.7.0 before 1.0.0-alpha.0."
}
],
"value": "Use of Password Hash With Insufficient Computational Effort vulnerability in danielberkompas cloak_ecto and danielberkompas cloak allows an attacker who holds the hashed values and the configured secret to brute-force low-entropy plaintexts much faster than configured.\n\nThe dump/1 callback that Cloak.Ecto.PBKDF2 (Cloak.Fields.PBKDF2 in cloak before the Ecto code moved to cloak_ecto) injects into a field module calls :pbkdf2.pbkdf2/4 with config[:size] in the iteration-count position. The :iterations setting is validated but never used. With the cloak_ecto defaults (iterations: 600_000, size: 32) each hash runs 32 PBKDF2 rounds instead of 600,000, so offline guessing of values such as email addresses costs about 18,750 times less than configured.\n\nThis issue affects cloak_ecto: from 1.0.0-alpha.0 onward; cloak: from 0.7.0 before 1.0.0-alpha.0."
}
],
"impacts": [
{
"capecId": "CAPEC-55",
"descriptions": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003eAn attacker who obtains a database dump and the PBKDF2 secret can recover hashed values with low entropy, such as email addresses, by offline guessing at a cost far below what the configuration promises.\u003c/p\u003e"
},
{
"base64": false,
"type": "text/markdown",
"value": "An attacker who obtains a database dump and the PBKDF2 secret can recover hashed values with low entropy, such as email addresses, by offline guessing at a cost far below what the configuration promises."
}
],
"value": "An attacker who obtains a database dump and the PBKDF2 secret can recover hashed values with low entropy, such as email addresses, by offline guessing at a cost far below what the configuration promises."
}
]
}
],
"metrics": [
{
"cvssV4_0": {
"Automatable": "NOT_DEFINED",
"Recovery": "NOT_DEFINED",
"Safety": "NOT_DEFINED",
"attackComplexity": "LOW",
"attackRequirements": "PRESENT",
"attackVector": "NETWORK",
"baseScore": 6.3,
"baseSeverity": "MEDIUM",
"privilegesRequired": "NONE",
"providerUrgency": "NOT_DEFINED",
"subAvailabilityImpact": "NONE",
"subConfidentialityImpact": "NONE",
"subIntegrityImpact": "NONE",
"userInteraction": "NONE",
"valueDensity": "NOT_DEFINED",
"vectorString": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N",
"version": "4.0",
"vulnAvailabilityImpact": "NONE",
"vulnConfidentialityImpact": "LOW",
"vulnIntegrityImpact": "NONE",
"vulnerabilityResponseEffort": "NOT_DEFINED"
},
"format": "CVSS",
"scenarios": [
{
"lang": "en",
"value": "GENERAL"
}
]
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-916",
"description": "CWE-916 Use of Password Hash With Insufficient Computational Effort",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-10-06T08:38:04.584Z",
"orgId": "6b3ad84c-e1a6-4bf7-a703-f496b71e49db",
"shortName": "EEF"
},
"references": [
{
"name": "EEF CNA record for CVE-2026-94206",
"tags": [
"related",
"third-party-advisory"
],
"url": "https://cna.erlef.org/cves/CVE-2026-94206.html"
},
{
"name": "OSV record EEF-CVE-2026-94206",
"tags": [
"related"
],
"url": "https://osv.dev/vulnerability/EEF-CVE-2026-94206"
},
{
"name": "Introducing commit a8fa164 in danielberkompas/cloak_ecto",
"tags": [
"related"
],
"url": "https://github.com/danielberkompas/cloak_ecto/commit/a8fa1642b02f1c445a1ee8794c9095eb0921f8f3"
},
{
"name": "Introducing commit 8699e64 in danielberkompas/cloak",
"tags": [
"related"
],
"url": "https://github.com/danielberkompas/cloak/commit/8699e6417a162c39d9f0ef63511bd23d3f38d1d2"
},
{
"name": "Fix commit 681c970 in danielberkompas/cloak",
"tags": [
"patch"
],
"url": "https://github.com/danielberkompas/cloak/commit/681c9702b7cd9afe0e5a840751ab009f550c69a9"
}
],
"source": {
"discovery": "EXTERNAL"
},
"title": "Cloak PBKDF2 field ignores the configured iteration count and runs only :size rounds",
"workarounds": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003eOverride \u003ccode\u003edump/1\u003c/code\u003e in the field module that uses \u003ccode\u003eCloak.Ecto.PBKDF2\u003c/code\u003e, so that it calls \u003ccode\u003e:pbkdf2.pbkdf2/5\u003c/code\u003e with the configured \u003ccode\u003e:iterations\u003c/code\u003e and \u003ccode\u003e:size\u003c/code\u003e. Then recompute all stored hashes, because the existing values no longer match.\u003c/p\u003e"
},
{
"base64": false,
"type": "text/markdown",
"value": "Override `dump/1` in the field module that uses `Cloak.Ecto.PBKDF2`, so that it calls `:pbkdf2.pbkdf2/5` with the configured `:iterations` and `:size`. Then recompute all stored hashes, because the existing values no longer match."
}
],
"value": "Override dump/1 in the field module that uses Cloak.Ecto.PBKDF2, so that it calls :pbkdf2.pbkdf2/5 with the configured :iterations and :size. Then recompute all stored hashes, because the existing values no longer match."
}
],
"x_proofOfConcept": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003col\u003e\n\u003cli\u003eDefine a field module with \u003ccode\u003euse Cloak.Ecto.PBKDF2\u003c/code\u003e and configure only a \u003ccode\u003e:secret\u003c/code\u003e, so that the defaults \u003ccode\u003eiterations: 600_000\u003c/code\u003e and \u003ccode\u003esize: 32\u003c/code\u003e apply.\u003c/li\u003e\n\u003cli\u003eCall \u003ccode\u003edump/1\u003c/code\u003e on a value.\u003c/li\u003e\n\u003cli\u003eCompare the result with \u003ccode\u003e:pbkdf2.pbkdf2({:hmac, :sha256}, value, secret, 32)\u003c/code\u003e and with the same call at 600,000 rounds. It matches the 32-round hash, not the 600,000-round hash, and returns in microseconds instead of about one second.\u003c/li\u003e\n\u003c/ol\u003e"
},
{
"base64": false,
"type": "text/markdown",
"value": "1. Define a field module with `use Cloak.Ecto.PBKDF2` and configure only a `:secret`, so that the defaults `iterations: 600_000` and `size: 32` apply.\n2. Call `dump/1` on a value.\n3. Compare the result with `:pbkdf2.pbkdf2({:hmac, :sha256}, value, secret, 32)` and with the same call at 600,000 rounds. It matches the 32-round hash, not the 600,000-round hash, and returns in microseconds instead of about one second."
}
],
"value": "* Define a field module with use Cloak.Ecto.PBKDF2 and configure only a :secret, so that the defaults iterations: 600_000 and size: 32 apply.\n* Call dump/1 on a value.\n* Compare the result with :pbkdf2.pbkdf2({:hmac, :sha256}, value, secret, 32) and with the same call at 600,000 rounds. It matches the 32-round hash, not the 600,000-round hash, and returns in microseconds instead of about one second."
}
]
}
},
"cveMetadata": {
"assignerOrgId": "6b3ad84c-e1a6-4bf7-a703-f496b71e49db",
"assignerShortName": "EEF",
"cveId": "CVE-2026-94206",
"datePublished": "2026-10-06T08:38:04.584Z",
"dateReserved": "2026-09-24T09:30:02.102Z",
"dateUpdated": "2026-10-06T11:36:25.466Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
CVE-2026-95105 (GCVE-0-2026-95105)
Vulnerability from cvelistv5 – Published: 2026-10-06 08:37 – Updated: 2026-10-06 11:40
VLAI
EPSS
VEX
Title
Cloak AES-CTR cipher lacks ciphertext authentication, allowing chosen-plaintext forgery by bit flipping
Summary
Reliance on Obfuscation or Encryption of Security-Relevant Inputs without Integrity Checking vulnerability in danielberkompas cloak allows an attacker with write access to stored ciphertext to make it decrypt to a chosen value via bit flipping.
Cloak.Ciphers.AES.CTR encrypts with AES-256 in CTR mode and stores the key tag, the IV and the ciphertext with no MAC. decrypt/2 checks only the key tag and the minimum length before it returns the plaintext, and Cloak.Ciphers.Deprecated.AES.CTR decrypts the legacy format the same way. CTR is a stream cipher, so a value XORed into the stored ciphertext is XORed into the plaintext at the same offset. An attacker who can write to the encrypted store (for example through SQL injection or a compromised replica) and who knows or can guess a stored plaintext can replace it with any value of the same length. The application receives that value with no error.
This issue affects cloak: from 0.1.0-pre onward.
Severity
SSVC
Exploitation: poc
Automatable: no
Technical Impact: partial
CISA Coordinator · CISA-ADP (v2.0.3)
Decision recorded 2026-10-06 11:37 UTC
CWE
- CWE-649 - Reliance on Obfuscation or Encryption of Security-Relevant Inputs without Integrity Checking
Assigner
References
3 references
| URL | Tags |
|---|---|
| https://cna.erlef.org/cves/CVE-2026-95105.html | relatedthird-party-advisory |
| https://osv.dev/vulnerability/EEF-CVE-2026-95105 | related |
| https://github.com/danielberkompas/cloak/commit/2… | related |
Impacted products
2 products
| Vendor | Product | Version | |
|---|---|---|---|
| danielberkompas | cloak |
Affected:
0.1.0-pre , < *
(semver)
cpe:2.3:a:danielberkompas:cloak:*:*:*:*:*:*:*:* |
|
| danielberkompas | cloak |
Affected:
2bd17019e285b55c5c218cc842537bf9280f24c3 , < *
(git)
cpe:2.3:a:danielberkompas:cloak:*:*:*:*:*:*:*:* |
{
"containers": {
"adp": [
{
"metrics": [
{
"other": {
"content": {
"id": "CVE-2026-95105",
"options": [
{
"Exploitation": "poc"
},
{
"Automatable": "no"
},
{
"Technical Impact": "partial"
}
],
"role": "CISA Coordinator",
"timestamp": "2026-10-06T11:37:58.212117Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"providerMetadata": {
"dateUpdated": "2026-10-06T11:40:42.775Z",
"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"shortName": "CISA-ADP"
},
"references": [
{
"tags": [
"exploit"
],
"url": "https://cna.erlef.org/cves/CVE-2026-95105.html"
}
],
"title": "CISA ADP Vulnrichment"
}
],
"cna": {
"affected": [
{
"collectionURL": "https://repo.hex.pm",
"cpes": [
"cpe:2.3:a:danielberkompas:cloak:*:*:*:*:*:*:*:*"
],
"defaultStatus": "unaffected",
"modules": [
"\u0027Elixir.Cloak.Ciphers.AES.CTR\u0027",
"\u0027Elixir.Cloak.Ciphers.Deprecated.AES.CTR\u0027"
],
"packageName": "cloak",
"packageURL": "pkg:hex/cloak",
"product": "cloak",
"programFiles": [
"lib/cloak/ciphers/aes_ctr.ex",
"lib/cloak/ciphers/deprecated/aes_ctr.ex"
],
"programRoutines": [
{
"name": "\u0027Elixir.Cloak.Ciphers.AES.CTR\u0027:encrypt/2"
},
{
"name": "\u0027Elixir.Cloak.Ciphers.AES.CTR\u0027:decrypt/2"
},
{
"name": "\u0027Elixir.Cloak.Ciphers.Deprecated.AES.CTR\u0027:decrypt/2"
}
],
"repo": "https://github.com/danielberkompas/cloak",
"vendor": "danielberkompas",
"versions": [
{
"lessThan": "*",
"status": "affected",
"version": "0.1.0-pre",
"versionType": "semver"
}
]
},
{
"collectionURL": "https://github.com",
"cpes": [
"cpe:2.3:a:danielberkompas:cloak:*:*:*:*:*:*:*:*"
],
"defaultStatus": "unaffected",
"modules": [
"\u0027Elixir.Cloak.Ciphers.AES.CTR\u0027",
"\u0027Elixir.Cloak.Ciphers.Deprecated.AES.CTR\u0027"
],
"packageName": "danielberkompas/cloak",
"packageURL": "pkg:github/danielberkompas/cloak",
"product": "cloak",
"programFiles": [
"lib/cloak/ciphers/aes_ctr.ex",
"lib/cloak/ciphers/deprecated/aes_ctr.ex"
],
"programRoutines": [
{
"name": "\u0027Elixir.Cloak.Ciphers.AES.CTR\u0027:encrypt/2"
},
{
"name": "\u0027Elixir.Cloak.Ciphers.AES.CTR\u0027:decrypt/2"
},
{
"name": "\u0027Elixir.Cloak.Ciphers.Deprecated.AES.CTR\u0027:decrypt/2"
}
],
"repo": "https://github.com/danielberkompas/cloak",
"vendor": "danielberkompas",
"versions": [
{
"lessThan": "*",
"status": "affected",
"version": "2bd17019e285b55c5c218cc842537bf9280f24c3",
"versionType": "git"
}
]
}
],
"cpeApplicability": [
{
"nodes": [
{
"cpeMatch": [
{
"criteria": "cpe:2.3:a:danielberkompas:cloak:*:*:*:*:*:*:*:*",
"versionStartIncluding": "0.1.0-pre",
"vulnerable": true
}
],
"negate": false,
"operator": "OR"
}
],
"operator": "AND"
}
],
"credits": [
{
"lang": "en",
"type": "finder",
"value": "Peter Ullrich"
},
{
"lang": "en",
"type": "reporter",
"value": "Peter Ullrich"
},
{
"lang": "en",
"type": "coordinator",
"value": "Jonatan M\u00e4nnchen / EEF"
}
],
"dateAssigned": "2026-10-06T08:37:34.000Z",
"descriptions": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003eReliance on Obfuscation or Encryption of Security-Relevant Inputs without Integrity Checking vulnerability in danielberkompas cloak allows an attacker with write access to stored ciphertext to make it decrypt to a chosen value via bit flipping.\u003c/p\u003e\n\u003cp\u003e\u003ccode\u003eCloak.Ciphers.AES.CTR\u003c/code\u003e encrypts with AES-256 in CTR mode and stores the key tag, the IV and the ciphertext with no MAC. \u003ccode\u003edecrypt/2\u003c/code\u003e checks only the key tag and the minimum length before it returns the plaintext, and \u003ccode\u003eCloak.Ciphers.Deprecated.AES.CTR\u003c/code\u003e decrypts the legacy format the same way. CTR is a stream cipher, so a value XORed into the stored ciphertext is XORed into the plaintext at the same offset. An attacker who can write to the encrypted store (for example through SQL injection or a compromised replica) and who knows or can guess a stored plaintext can replace it with any value of the same length. The application receives that value with no error.\u003c/p\u003e\n\u003cp\u003eThis issue affects cloak: from 0.1.0-pre onward.\u003c/p\u003e"
},
{
"base64": false,
"type": "text/markdown",
"value": "Reliance on Obfuscation or Encryption of Security-Relevant Inputs without Integrity Checking vulnerability in danielberkompas cloak allows an attacker with write access to stored ciphertext to make it decrypt to a chosen value via bit flipping.\n\n`Cloak.Ciphers.AES.CTR` encrypts with AES-256 in CTR mode and stores the key tag, the IV and the ciphertext with no MAC. `decrypt/2` checks only the key tag and the minimum length before it returns the plaintext, and `Cloak.Ciphers.Deprecated.AES.CTR` decrypts the legacy format the same way. CTR is a stream cipher, so a value XORed into the stored ciphertext is XORed into the plaintext at the same offset. An attacker who can write to the encrypted store (for example through SQL injection or a compromised replica) and who knows or can guess a stored plaintext can replace it with any value of the same length. The application receives that value with no error.\n\nThis issue affects cloak: from 0.1.0-pre onward."
}
],
"value": "Reliance on Obfuscation or Encryption of Security-Relevant Inputs without Integrity Checking vulnerability in danielberkompas cloak allows an attacker with write access to stored ciphertext to make it decrypt to a chosen value via bit flipping.\n\nCloak.Ciphers.AES.CTR encrypts with AES-256 in CTR mode and stores the key tag, the IV and the ciphertext with no MAC. decrypt/2 checks only the key tag and the minimum length before it returns the plaintext, and Cloak.Ciphers.Deprecated.AES.CTR decrypts the legacy format the same way. CTR is a stream cipher, so a value XORed into the stored ciphertext is XORed into the plaintext at the same offset. An attacker who can write to the encrypted store (for example through SQL injection or a compromised replica) and who knows or can guess a stored plaintext can replace it with any value of the same length. The application receives that value with no error.\n\nThis issue affects cloak: from 0.1.0-pre onward."
}
],
"impacts": [
{
"capecId": "CAPEC-39",
"descriptions": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003eAn attacker who can write to the encrypted store can set encrypted fields with known or guessable contents, such as roles, flags, or fixed-format records, to values of their choice without the key. The application decrypts and trusts the forged value.\u003c/p\u003e"
},
{
"base64": false,
"type": "text/markdown",
"value": "An attacker who can write to the encrypted store can set encrypted fields with known or guessable contents, such as roles, flags, or fixed-format records, to values of their choice without the key. The application decrypts and trusts the forged value."
}
],
"value": "An attacker who can write to the encrypted store can set encrypted fields with known or guessable contents, such as roles, flags, or fixed-format records, to values of their choice without the key. The application decrypts and trusts the forged value."
}
]
}
],
"metrics": [
{
"cvssV4_0": {
"Automatable": "NOT_DEFINED",
"Recovery": "NOT_DEFINED",
"Safety": "NOT_DEFINED",
"attackComplexity": "LOW",
"attackRequirements": "PRESENT",
"attackVector": "NETWORK",
"baseScore": 8.2,
"baseSeverity": "HIGH",
"privilegesRequired": "NONE",
"providerUrgency": "NOT_DEFINED",
"subAvailabilityImpact": "NONE",
"subConfidentialityImpact": "NONE",
"subIntegrityImpact": "NONE",
"userInteraction": "NONE",
"valueDensity": "NOT_DEFINED",
"vectorString": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N",
"version": "4.0",
"vulnAvailabilityImpact": "NONE",
"vulnConfidentialityImpact": "NONE",
"vulnIntegrityImpact": "HIGH",
"vulnerabilityResponseEffort": "NOT_DEFINED"
},
"format": "CVSS",
"scenarios": [
{
"lang": "en",
"value": "GENERAL"
}
]
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-649",
"description": "CWE-649 Reliance on Obfuscation or Encryption of Security-Relevant Inputs without Integrity Checking",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-10-06T08:37:56.987Z",
"orgId": "6b3ad84c-e1a6-4bf7-a703-f496b71e49db",
"shortName": "EEF"
},
"references": [
{
"name": "EEF CNA record for CVE-2026-95105",
"tags": [
"related",
"third-party-advisory"
],
"url": "https://cna.erlef.org/cves/CVE-2026-95105.html"
},
{
"name": "OSV record EEF-CVE-2026-95105",
"tags": [
"related"
],
"url": "https://osv.dev/vulnerability/EEF-CVE-2026-95105"
},
{
"name": "Introducing commit 2bd1701 in danielberkompas/cloak",
"tags": [
"related"
],
"url": "https://github.com/danielberkompas/cloak/commit/2bd17019e285b55c5c218cc842537bf9280f24c3"
}
],
"source": {
"discovery": "EXTERNAL"
},
"title": "Cloak AES-CTR cipher lacks ciphertext authentication, allowing chosen-plaintext forgery by bit flipping",
"workarounds": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003eConfigure the vault with \u003ccode\u003eCloak.Ciphers.AES.GCM\u003c/code\u003e as the default cipher and re-encrypt existing values, for example with the \u003ccode\u003ecloak.migrate.ecto\u003c/code\u003e task from cloak_ecto. Then remove \u003ccode\u003eCloak.Ciphers.AES.CTR\u003c/code\u003e and \u003ccode\u003eCloak.Ciphers.Deprecated.AES.CTR\u003c/code\u003e from the vault configuration, so that ciphertext in the CTR format is no longer decrypted. AES-GCM authenticates the ciphertext and rejects modified values.\u003c/p\u003e"
},
{
"base64": false,
"type": "text/markdown",
"value": "Configure the vault with `Cloak.Ciphers.AES.GCM` as the default cipher and re-encrypt existing values, for example with the `cloak.migrate.ecto` task from cloak_ecto. Then remove `Cloak.Ciphers.AES.CTR` and `Cloak.Ciphers.Deprecated.AES.CTR` from the vault configuration, so that ciphertext in the CTR format is no longer decrypted. AES-GCM authenticates the ciphertext and rejects modified values."
}
],
"value": "Configure the vault with Cloak.Ciphers.AES.GCM as the default cipher and re-encrypt existing values, for example with the cloak.migrate.ecto task from cloak_ecto. Then remove Cloak.Ciphers.AES.CTR and Cloak.Ciphers.Deprecated.AES.CTR from the vault configuration, so that ciphertext in the CTR format is no longer decrypted. AES-GCM authenticates the ciphertext and rejects modified values."
}
],
"x_proofOfConcept": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003col\u003e\n\u003cli\u003eEncrypt \u003ccode\u003e\"role=user \"\u003c/code\u003e with \u003ccode\u003eCloak.Ciphers.AES.CTR.encrypt/2\u003c/code\u003e and a random 32-byte key.\u003c/li\u003e\n\u003cli\u003eWithout the key, XOR the last 10 bytes of the result (the ciphertext body) with \u003ccode\u003e:crypto.exor(\"role=user \", \"role=admin\")\u003c/code\u003e. Leave the key tag and the IV unchanged.\u003c/li\u003e\n\u003cli\u003eCall \u003ccode\u003eCloak.Ciphers.AES.CTR.decrypt/2\u003c/code\u003e on the modified value. It returns \u003ccode\u003e{:ok, \"role=admin\"}\u003c/code\u003e.\u003c/li\u003e\n\u003c/ol\u003e"
},
{
"base64": false,
"type": "text/markdown",
"value": "1. Encrypt `\"role=user \"` with `Cloak.Ciphers.AES.CTR.encrypt/2` and a random 32-byte key.\n2. Without the key, XOR the last 10 bytes of the result (the ciphertext body) with `:crypto.exor(\"role=user \", \"role=admin\")`. Leave the key tag and the IV unchanged.\n3. Call `Cloak.Ciphers.AES.CTR.decrypt/2` on the modified value. It returns `{:ok, \"role=admin\"}`."
}
],
"value": "* Encrypt \"role=user \" with Cloak.Ciphers.AES.CTR.encrypt/2 and a random 32-byte key.\n* Without the key, XOR the last 10 bytes of the result (the ciphertext body) with :crypto.exor(\"role=user \", \"role=admin\"). Leave the key tag and the IV unchanged.\n* Call Cloak.Ciphers.AES.CTR.decrypt/2 on the modified value. It returns {:ok, \"role=admin\"}."
}
]
}
},
"cveMetadata": {
"assignerOrgId": "6b3ad84c-e1a6-4bf7-a703-f496b71e49db",
"assignerShortName": "EEF",
"cveId": "CVE-2026-95105",
"datePublished": "2026-10-06T08:37:56.987Z",
"dateReserved": "2026-09-25T07:00:01.880Z",
"dateUpdated": "2026-10-06T11:40:42.775Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
CVE-2026-94201 (GCVE-0-2026-94201)
Vulnerability from cvelistv5 – Published: 2026-10-05 19:19 – Updated: 2026-10-06 13:41
VLAI
EPSS
VEX
Title
Filtering an :atom attribute with unsafe_to_atom? can exhaust the BEAM atom table in Ash
Summary
Ash stores :atom-typed attributes as strings and compares them as strings. When such an attribute is referenced in a filter, the comparison value is coerced through Ash.Type.Atom. Because the type defined no coerce/2 callback, coercion fell back to the default (cast_input/2), which calls String.to_atom/1 when the attribute is configured with the unsafe_to_atom?: true constraint.
Filtering such an attribute with attacker-controlled strings therefore interned a new, permanent atom for every distinct value. Atoms are never garbage collected and the BEAM caps the atom table, so an actor who can supply filter values for a public, filterable :atom attribute declared with unsafe_to_atom?: true can exhaust the atom table and crash the node (denial of service). AshPaperTrail is a notable example: its version resources expose a public, filterable version_action_name atom attribute with unsafe_to_atom?: true by default.
The fix adds a coerce/2 to Ash.Type.Atom that never interns atoms — a comparison value is left as a string, since the type is stored and compared as a string. Setting the attribute from action input (cast_input/2, which still honors unsafe_to_atom?) is unchanged.
This issue affects ash: from 3.5.1 before 3.34.3.
Severity
SSVC
Exploitation: none
Automatable: no
Technical Impact: partial
CISA Coordinator · CISA-ADP (v2.0.3)
Decision recorded 2026-10-06 13:41 UTC
CWE
- CWE-770 - Allocation of Resources Without Limits or Throttling
Assigner
References
4 references
| URL | Tags |
|---|---|
| https://cna.erlef.org/cves/CVE-2026-94201.html | relatedthird-party-advisory |
| https://osv.dev/vulnerability/EEF-CVE-2026-94201 | related |
| https://github.com/ash-project/ash/commit/2970ba3… | related |
| https://github.com/ash-project/ash/commit/5282f3f… | patch |
Impacted products
2 products
| Vendor | Product | Version | |
|---|---|---|---|
| ash-project | ash |
Affected:
3.5.1 , < 3.34.3
(semver)
cpe:2.3:a:ash-project:ash:*:*:*:*:*:*:*:* |
|
| ash-project | ash |
Affected:
2970ba3bd5d36d6ad04c731ac87385375d457147 , < 5282f3f513053628cdd1bf2236ea22d975d934d4
(git)
cpe:2.3:a:ash-project:ash:*:*:*:*:*:*:*:* |
{
"containers": {
"adp": [
{
"metrics": [
{
"other": {
"content": {
"id": "CVE-2026-94201",
"options": [
{
"Exploitation": "none"
},
{
"Automatable": "no"
},
{
"Technical Impact": "partial"
}
],
"role": "CISA Coordinator",
"timestamp": "2026-10-06T13:41:07.117450Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"providerMetadata": {
"dateUpdated": "2026-10-06T13:41:22.142Z",
"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"shortName": "CISA-ADP"
},
"title": "CISA ADP Vulnrichment"
}
],
"cna": {
"affected": [
{
"collectionURL": "https://repo.hex.pm",
"cpes": [
"cpe:2.3:a:ash-project:ash:*:*:*:*:*:*:*:*"
],
"defaultStatus": "unaffected",
"modules": [
"\u0027Elixir.Ash.Type.Atom\u0027"
],
"packageName": "ash",
"packageURL": "pkg:hex/ash",
"product": "ash",
"programFiles": [
"lib/ash/type/atom.ex"
],
"programRoutines": [
{
"name": "\u0027Elixir.Ash.Type.Atom\u0027:cast_value/2"
}
],
"repo": "https://github.com/ash-project/ash",
"vendor": "ash-project",
"versions": [
{
"lessThan": "3.34.3",
"status": "affected",
"version": "3.5.1",
"versionType": "semver"
}
]
},
{
"collectionURL": "https://github.com",
"cpes": [
"cpe:2.3:a:ash-project:ash:*:*:*:*:*:*:*:*"
],
"defaultStatus": "unaffected",
"modules": [
"\u0027Elixir.Ash.Type.Atom\u0027"
],
"packageName": "ash-project/ash",
"packageURL": "pkg:github/ash-project/ash",
"product": "ash",
"programFiles": [
"lib/ash/type/atom.ex"
],
"programRoutines": [
{
"name": "\u0027Elixir.Ash.Type.Atom\u0027:cast_value/2"
}
],
"repo": "https://github.com/ash-project/ash",
"vendor": "ash-project",
"versions": [
{
"lessThan": "5282f3f513053628cdd1bf2236ea22d975d934d4",
"status": "affected",
"version": "2970ba3bd5d36d6ad04c731ac87385375d457147",
"versionType": "git"
}
]
}
],
"configurations": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003eReachable only when an application exposes a public, filterable \u003ccode\u003e:atom\u003c/code\u003e attribute declared with the \u003ccode\u003eunsafe_to_atom?: true\u003c/code\u003e constraint, and an actor can supply filter values for it (for example through AshGraphql, AshJsonApi, or \u003ccode\u003eAsh.Query.filter_input/2\u003c/code\u003e). AshPaperTrail\u0027s version resources ship such an attribute (\u003ccode\u003eversion_action_name\u003c/code\u003e) by default.\u003c/p\u003e"
},
{
"base64": false,
"type": "text/markdown",
"value": "Reachable only when an application exposes a public, filterable `:atom` attribute declared with the `unsafe_to_atom?: true` constraint, and an actor can supply filter values for it (for example through AshGraphql, AshJsonApi, or `Ash.Query.filter_input/2`). AshPaperTrail\u0027s version resources ship such an attribute (`version_action_name`) by default."
}
],
"value": "Reachable only when an application exposes a public, filterable :atom attribute declared with the unsafe_to_atom?: true constraint, and an actor can supply filter values for it (for example through AshGraphql, AshJsonApi, or Ash.Query.filter_input/2). AshPaperTrail\u0027s version resources ship such an attribute (version_action_name) by default."
}
],
"cpeApplicability": [
{
"nodes": [
{
"cpeMatch": [
{
"criteria": "cpe:2.3:a:ash-project:ash:*:*:*:*:*:*:*:*",
"versionEndExcluding": "3.34.3",
"versionStartIncluding": "3.5.1",
"vulnerable": true
}
],
"negate": false,
"operator": "OR"
}
],
"operator": "AND"
}
],
"credits": [
{
"lang": "en",
"type": "finder",
"value": "Quinn Wilton"
},
{
"lang": "en",
"type": "reporter",
"value": "Quinn Wilton"
},
{
"lang": "en",
"type": "remediation developer",
"value": "Zach Daniel / Ash Project"
},
{
"lang": "en",
"type": "coordinator",
"value": "Jonatan M\u00e4nnchen / EEF"
}
],
"dateAssigned": "2026-10-04T15:49:18.000Z",
"descriptions": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003eAsh stores \u003ccode\u003e:atom\u003c/code\u003e-typed attributes as strings and compares them as strings. When such an attribute is referenced in a filter, the comparison value is coerced through \u003ccode\u003eAsh.Type.Atom\u003c/code\u003e. Because the type defined no \u003ccode\u003ecoerce/2\u003c/code\u003e callback, coercion fell back to the default (\u003ccode\u003ecast_input/2\u003c/code\u003e), which calls \u003ccode\u003eString.to_atom/1\u003c/code\u003e when the attribute is configured with the \u003ccode\u003eunsafe_to_atom?: true\u003c/code\u003e constraint.\u003c/p\u003e\n\u003cp\u003eFiltering such an attribute with attacker-controlled strings therefore interned a new, permanent atom for every distinct value. Atoms are never garbage collected and the BEAM caps the atom table, so an actor who can supply filter values for a public, filterable \u003ccode\u003e:atom\u003c/code\u003e attribute declared with \u003ccode\u003eunsafe_to_atom?: true\u003c/code\u003e can exhaust the atom table and crash the node (denial of service). AshPaperTrail is a notable example: its version resources expose a public, filterable \u003ccode\u003eversion_action_name\u003c/code\u003e atom attribute with \u003ccode\u003eunsafe_to_atom?: true\u003c/code\u003e by default.\u003c/p\u003e\n\u003cp\u003eThe fix adds a \u003ccode\u003ecoerce/2\u003c/code\u003e to \u003ccode\u003eAsh.Type.Atom\u003c/code\u003e that never interns atoms \u2014 a comparison value is left as a string, since the type is stored and compared as a string. Setting the attribute from action input (\u003ccode\u003ecast_input/2\u003c/code\u003e, which still honors \u003ccode\u003eunsafe_to_atom?\u003c/code\u003e) is unchanged.\u003c/p\u003e\n\u003cp\u003eThis issue affects ash: from 3.5.1 before 3.34.3.\u003c/p\u003e"
},
{
"base64": false,
"type": "text/markdown",
"value": "Ash stores `:atom`-typed attributes as strings and compares them as strings. When such an attribute is referenced in a filter, the comparison value is coerced through `Ash.Type.Atom`. Because the type defined no `coerce/2` callback, coercion fell back to the default (`cast_input/2`), which calls `String.to_atom/1` when the attribute is configured with the `unsafe_to_atom?: true` constraint.\n\nFiltering such an attribute with attacker-controlled strings therefore interned a new, permanent atom for every distinct value. Atoms are never garbage collected and the BEAM caps the atom table, so an actor who can supply filter values for a public, filterable `:atom` attribute declared with `unsafe_to_atom?: true` can exhaust the atom table and crash the node (denial of service). AshPaperTrail is a notable example: its version resources expose a public, filterable `version_action_name` atom attribute with `unsafe_to_atom?: true` by default.\n\nThe fix adds a `coerce/2` to `Ash.Type.Atom` that never interns atoms \u2014 a comparison value is left as a string, since the type is stored and compared as a string. Setting the attribute from action input (`cast_input/2`, which still honors `unsafe_to_atom?`) is unchanged.\n\nThis issue affects ash: from 3.5.1 before 3.34.3."
}
],
"value": "Ash stores :atom-typed attributes as strings and compares them as strings. When such an attribute is referenced in a filter, the comparison value is coerced through Ash.Type.Atom. Because the type defined no coerce/2 callback, coercion fell back to the default (cast_input/2), which calls String.to_atom/1 when the attribute is configured with the unsafe_to_atom?: true constraint.\n\nFiltering such an attribute with attacker-controlled strings therefore interned a new, permanent atom for every distinct value. Atoms are never garbage collected and the BEAM caps the atom table, so an actor who can supply filter values for a public, filterable :atom attribute declared with unsafe_to_atom?: true can exhaust the atom table and crash the node (denial of service). AshPaperTrail is a notable example: its version resources expose a public, filterable version_action_name atom attribute with unsafe_to_atom?: true by default.\n\nThe fix adds a coerce/2 to Ash.Type.Atom that never interns atoms \u2014 a comparison value is left as a string, since the type is stored and compared as a string. Setting the attribute from action input (cast_input/2, which still honors unsafe_to_atom?) is unchanged.\n\nThis issue affects ash: from 3.5.1 before 3.34.3."
}
],
"impacts": [
{
"capecId": "CAPEC-130",
"descriptions": [
{
"lang": "en",
"value": "CAPEC-130 Excessive Allocation"
}
]
}
],
"metrics": [
{
"cvssV4_0": {
"Automatable": "NOT_DEFINED",
"Recovery": "NOT_DEFINED",
"Safety": "NOT_DEFINED",
"attackComplexity": "LOW",
"attackRequirements": "PRESENT",
"attackVector": "NETWORK",
"baseScore": 8.2,
"baseSeverity": "HIGH",
"privilegesRequired": "NONE",
"providerUrgency": "NOT_DEFINED",
"subAvailabilityImpact": "NONE",
"subConfidentialityImpact": "NONE",
"subIntegrityImpact": "NONE",
"userInteraction": "NONE",
"valueDensity": "NOT_DEFINED",
"vectorString": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N",
"version": "4.0",
"vulnAvailabilityImpact": "HIGH",
"vulnConfidentialityImpact": "NONE",
"vulnIntegrityImpact": "NONE",
"vulnerabilityResponseEffort": "NOT_DEFINED"
},
"format": "CVSS",
"scenarios": [
{
"lang": "en",
"value": "GENERAL"
}
]
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-770",
"description": "CWE-770 Allocation of Resources Without Limits or Throttling",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-10-05T19:19:51.326Z",
"orgId": "6b3ad84c-e1a6-4bf7-a703-f496b71e49db",
"shortName": "EEF"
},
"references": [
{
"name": "EEF CNA record for CVE-2026-94201",
"tags": [
"related",
"third-party-advisory"
],
"url": "https://cna.erlef.org/cves/CVE-2026-94201.html"
},
{
"name": "OSV record EEF-CVE-2026-94201",
"tags": [
"related"
],
"url": "https://osv.dev/vulnerability/EEF-CVE-2026-94201"
},
{
"name": "Introducing commit 2970ba3 in ash-project/ash",
"tags": [
"related"
],
"url": "https://github.com/ash-project/ash/commit/2970ba3bd5d36d6ad04c731ac87385375d457147"
},
{
"name": "Fix commit 5282f3f in ash-project/ash",
"tags": [
"patch"
],
"url": "https://github.com/ash-project/ash/commit/5282f3f513053628cdd1bf2236ea22d975d934d4"
}
],
"source": {
"discovery": "EXTERNAL"
},
"title": "Filtering an :atom attribute with unsafe_to_atom? can exhaust the BEAM atom table in Ash"
}
},
"cveMetadata": {
"assignerOrgId": "6b3ad84c-e1a6-4bf7-a703-f496b71e49db",
"assignerShortName": "EEF",
"cveId": "CVE-2026-94201",
"datePublished": "2026-10-05T19:19:51.326Z",
"dateReserved": "2026-09-24T09:15:02.216Z",
"dateUpdated": "2026-10-06T13:41:22.142Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
CVE-2026-94194 (GCVE-0-2026-94194)
Vulnerability from cvelistv5 – Published: 2026-09-28 11:15 – Updated: 2026-09-30 13:17
VLAI
EPSS
VEX
Title
Mint HTTP/1 client applies chunked framing when chunked is not the final transfer coding, enabling response smuggling through intermediaries
Summary
Inconsistent Interpretation of HTTP Requests ('HTTP Request/Response Smuggling') vulnerability in elixir-mint mint allows a malicious HTTP/1 server to desynchronize an intermediary and the Mint client on a pooled connection, poisoning the responses to subsequent requests that share the connection.
message_body/1 in lib/mint/http1.ex selects chunked framing when chunked is the first coding listed in a response's Transfer-Encoding fields. RFC 9112 section 6.3 applies chunked framing only when chunked is the final coding, and otherwise reads the body until the server closes the connection. For a response such as Transfer-Encoding: chunked, gzip, an intermediary that follows the RFC treats every byte up to the close as the body, while Mint ends the body at the zero-length chunk and parses the remaining bytes as the response to the next request on the connection.
Mint also keeps the connection open after an HTTP/1.0 response, final or 1xx, that carries Transfer-Encoding and Connection: keep-alive. RFC 9112 section 6.1 requires treating the framing of such a message as faulty and closing the connection after it, so bytes after its chunked body are parsed as the response to the next request in the same way.
This issue affects mint: from 0.1.0 before 1.10.2.
Severity
SSVC
Exploitation: poc
Automatable: no
Technical Impact: partial
CISA Coordinator · CISA-ADP (v2.0.3)
Decision recorded 2026-09-30 13:16 UTC
CWE
- CWE-444 - Inconsistent Interpretation of HTTP Requests ('HTTP Request/Response Smuggling')
Assigner
References
6 references
Impacted products
2 products
| Vendor | Product | Version | |
|---|---|---|---|
| elixir-mint | mint |
Affected:
0.1.0 , < 1.10.2
(semver)
cpe:2.3:a:elixir-mint:mint:*:*:*:*:*:*:*:* |
|
| elixir-mint | mint |
Affected:
60089586ec7adc9fddb09f69a2f5919ba9ac7f33 , < *
(git)
cpe:2.3:a:elixir-mint:mint:*:*:*:*:*:*:*:* |
Date Public
2026-09-28 11:15
{
"containers": {
"adp": [
{
"metrics": [
{
"other": {
"content": {
"id": "CVE-2026-94194",
"options": [
{
"Exploitation": "poc"
},
{
"Automatable": "no"
},
{
"Technical Impact": "partial"
}
],
"role": "CISA Coordinator",
"timestamp": "2026-09-30T13:16:26.592339Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"providerMetadata": {
"dateUpdated": "2026-09-30T13:17:02.563Z",
"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"shortName": "CISA-ADP"
},
"references": [
{
"tags": [
"exploit"
],
"url": "https://github.com/elixir-mint/mint/security/advisories/GHSA-gvrc-75rc-7gj9"
}
],
"title": "CISA ADP Vulnrichment"
}
],
"cna": {
"affected": [
{
"collectionURL": "https://repo.hex.pm",
"cpes": [
"cpe:2.3:a:elixir-mint:mint:*:*:*:*:*:*:*:*"
],
"defaultStatus": "unaffected",
"modules": [
"\u0027Elixir.Mint.HTTP1\u0027"
],
"packageName": "mint",
"packageURL": "pkg:hex/mint",
"product": "mint",
"programFiles": [
"lib/mint/http1.ex"
],
"programRoutines": [
{
"name": "\u0027Elixir.Mint.HTTP1\u0027:message_body/1"
},
{
"name": "\u0027Elixir.Mint.HTTP1\u0027:stream/2"
},
{
"name": "\u0027Elixir.Mint.HTTP1\u0027:recv/3"
}
],
"repo": "https://github.com/elixir-mint/mint",
"vendor": "elixir-mint",
"versions": [
{
"lessThan": "1.10.2",
"status": "affected",
"version": "0.1.0",
"versionType": "semver"
}
]
},
{
"collectionURL": "https://github.com",
"cpes": [
"cpe:2.3:a:elixir-mint:mint:*:*:*:*:*:*:*:*"
],
"defaultStatus": "unaffected",
"modules": [
"\u0027Elixir.Mint.HTTP1\u0027"
],
"packageName": "elixir-mint/mint",
"packageURL": "pkg:github/elixir-mint/mint",
"product": "mint",
"programFiles": [
"lib/mint/http1.ex"
],
"programRoutines": [
{
"name": "\u0027Elixir.Mint.HTTP1\u0027:message_body/1"
},
{
"name": "\u0027Elixir.Mint.HTTP1\u0027:stream/2"
},
{
"name": "\u0027Elixir.Mint.HTTP1\u0027:recv/3"
}
],
"repo": "https://github.com/elixir-mint/mint",
"vendor": "elixir-mint",
"versions": [
{
"changes": [
{
"at": "2ec8b696b5475ecbdaa87c0098957bca339e17c0",
"status": "unaffected"
},
{
"at": "8d1bbcfa566a8c1dc23d33f40d550c28250ac7b9",
"status": "unaffected"
}
],
"lessThan": "*",
"status": "affected",
"version": "60089586ec7adc9fddb09f69a2f5919ba9ac7f33",
"versionType": "git"
}
]
}
],
"configurations": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003eExploitation requires an HTTP/1 intermediary (proxy, load balancer, or gateway) between the Mint client and the attacker-influenced origin that frames a response whose final transfer coding is not \u003ccode\u003echunked\u003c/code\u003e as ending at connection close and forwards its \u003ccode\u003eTransfer-Encoding\u003c/code\u003e header to the client unchanged, and HTTP/1 connections between the client and the intermediary that are reused across requests. Intermediaries that reject such a header or re-frame the body do not create the disagreement. Mint clients that connect to the origin directly, or that don\u0027t reuse connections, aren\u0027t exposed to response-queue poisoning.\u003c/p\u003e"
},
{
"base64": false,
"type": "text/markdown",
"value": "Exploitation requires an HTTP/1 intermediary (proxy, load balancer, or gateway) between the Mint client and the attacker-influenced origin that frames a response whose final transfer coding is not `chunked` as ending at connection close and forwards its `Transfer-Encoding` header to the client unchanged, and HTTP/1 connections between the client and the intermediary that are reused across requests. Intermediaries that reject such a header or re-frame the body do not create the disagreement. Mint clients that connect to the origin directly, or that don\u0027t reuse connections, aren\u0027t exposed to response-queue poisoning."
}
],
"value": "Exploitation requires an HTTP/1 intermediary (proxy, load balancer, or gateway) between the Mint client and the attacker-influenced origin that frames a response whose final transfer coding is not chunked as ending at connection close and forwards its Transfer-Encoding header to the client unchanged, and HTTP/1 connections between the client and the intermediary that are reused across requests. Intermediaries that reject such a header or re-frame the body do not create the disagreement. Mint clients that connect to the origin directly, or that don\u0027t reuse connections, aren\u0027t exposed to response-queue poisoning."
}
],
"cpeApplicability": [
{
"nodes": [
{
"cpeMatch": [
{
"criteria": "cpe:2.3:a:elixir-mint:mint:*:*:*:*:*:*:*:*",
"versionEndExcluding": "1.10.2",
"versionStartIncluding": "0.1.0",
"vulnerable": true
}
],
"negate": false,
"operator": "OR"
}
],
"operator": "AND"
}
],
"credits": [
{
"lang": "en",
"type": "finder",
"value": "zx"
},
{
"lang": "en",
"type": "reporter",
"value": "zx"
},
{
"lang": "en",
"type": "remediation developer",
"value": "Eric Meadows-J\u00f6nsson"
}
],
"dateAssigned": "2026-09-27T11:54:52.000Z",
"datePublic": "2026-09-28T11:15:31.000Z",
"descriptions": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003eInconsistent Interpretation of HTTP Requests (\u0027HTTP Request/Response Smuggling\u0027) vulnerability in elixir-mint mint allows a malicious HTTP/1 server to desynchronize an intermediary and the Mint client on a pooled connection, poisoning the responses to subsequent requests that share the connection.\u003c/p\u003e\n\u003cp\u003e\u003ccode\u003emessage_body/1\u003c/code\u003e in \u003ccode\u003elib/mint/http1.ex\u003c/code\u003e selects chunked framing when \u003ccode\u003echunked\u003c/code\u003e is the first coding listed in a response\u0027s \u003ccode\u003eTransfer-Encoding\u003c/code\u003e fields. RFC 9112 section 6.3 applies chunked framing only when \u003ccode\u003echunked\u003c/code\u003e is the final coding, and otherwise reads the body until the server closes the connection. For a response such as \u003ccode\u003eTransfer-Encoding: chunked, gzip\u003c/code\u003e, an intermediary that follows the RFC treats every byte up to the close as the body, while Mint ends the body at the zero-length chunk and parses the remaining bytes as the response to the next request on the connection.\u003c/p\u003e\n\u003cp\u003eMint also keeps the connection open after an HTTP/1.0 response, final or 1xx, that carries \u003ccode\u003eTransfer-Encoding\u003c/code\u003e and \u003ccode\u003eConnection: keep-alive\u003c/code\u003e. RFC 9112 section 6.1 requires treating the framing of such a message as faulty and closing the connection after it, so bytes after its chunked body are parsed as the response to the next request in the same way.\u003c/p\u003e\n\u003cp\u003eThis issue affects mint: from 0.1.0 before 1.10.2.\u003c/p\u003e"
},
{
"base64": false,
"type": "text/markdown",
"value": "Inconsistent Interpretation of HTTP Requests (\u0027HTTP Request/Response Smuggling\u0027) vulnerability in elixir-mint mint allows a malicious HTTP/1 server to desynchronize an intermediary and the Mint client on a pooled connection, poisoning the responses to subsequent requests that share the connection.\n\n`message_body/1` in `lib/mint/http1.ex` selects chunked framing when `chunked` is the first coding listed in a response\u0027s `Transfer-Encoding` fields. RFC 9112 section 6.3 applies chunked framing only when `chunked` is the final coding, and otherwise reads the body until the server closes the connection. For a response such as `Transfer-Encoding: chunked, gzip`, an intermediary that follows the RFC treats every byte up to the close as the body, while Mint ends the body at the zero-length chunk and parses the remaining bytes as the response to the next request on the connection.\n\nMint also keeps the connection open after an HTTP/1.0 response, final or 1xx, that carries `Transfer-Encoding` and `Connection: keep-alive`. RFC 9112 section 6.1 requires treating the framing of such a message as faulty and closing the connection after it, so bytes after its chunked body are parsed as the response to the next request in the same way.\n\nThis issue affects mint: from 0.1.0 before 1.10.2."
}
],
"value": "Inconsistent Interpretation of HTTP Requests (\u0027HTTP Request/Response Smuggling\u0027) vulnerability in elixir-mint mint allows a malicious HTTP/1 server to desynchronize an intermediary and the Mint client on a pooled connection, poisoning the responses to subsequent requests that share the connection.\n\nmessage_body/1 in lib/mint/http1.ex selects chunked framing when chunked is the first coding listed in a response\u0027s Transfer-Encoding fields. RFC 9112 section 6.3 applies chunked framing only when chunked is the final coding, and otherwise reads the body until the server closes the connection. For a response such as Transfer-Encoding: chunked, gzip, an intermediary that follows the RFC treats every byte up to the close as the body, while Mint ends the body at the zero-length chunk and parses the remaining bytes as the response to the next request on the connection.\n\nMint also keeps the connection open after an HTTP/1.0 response, final or 1xx, that carries Transfer-Encoding and Connection: keep-alive. RFC 9112 section 6.1 requires treating the framing of such a message as faulty and closing the connection after it, so bytes after its chunked body are parsed as the response to the next request in the same way.\n\nThis issue affects mint: from 0.1.0 before 1.10.2."
}
],
"impacts": [
{
"capecId": "CAPEC-273",
"descriptions": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003eA malicious or attacker-influenced HTTP/1 origin behind an intermediary that follows RFC 9112 framing can make the intermediary and the Mint client disagree on where a response ends. On a pooled keep-alive connection, bytes the origin appends to one response become the response to the next request sharing the connection, and the real responses shift to later requests.\u003c/p\u003e"
},
{
"base64": false,
"type": "text/markdown",
"value": "A malicious or attacker-influenced HTTP/1 origin behind an intermediary that follows RFC 9112 framing can make the intermediary and the Mint client disagree on where a response ends. On a pooled keep-alive connection, bytes the origin appends to one response become the response to the next request sharing the connection, and the real responses shift to later requests."
}
],
"value": "A malicious or attacker-influenced HTTP/1 origin behind an intermediary that follows RFC 9112 framing can make the intermediary and the Mint client disagree on where a response ends. On a pooled keep-alive connection, bytes the origin appends to one response become the response to the next request sharing the connection, and the real responses shift to later requests."
}
]
}
],
"metrics": [
{
"cvssV4_0": {
"Automatable": "NOT_DEFINED",
"Recovery": "NOT_DEFINED",
"Safety": "NOT_DEFINED",
"attackComplexity": "LOW",
"attackRequirements": "PRESENT",
"attackVector": "NETWORK",
"baseScore": 6.3,
"baseSeverity": "MEDIUM",
"privilegesRequired": "NONE",
"providerUrgency": "NOT_DEFINED",
"subAvailabilityImpact": "NONE",
"subConfidentialityImpact": "NONE",
"subIntegrityImpact": "NONE",
"userInteraction": "NONE",
"valueDensity": "NOT_DEFINED",
"vectorString": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:L/VI:L/VA:N/SC:N/SI:N/SA:N",
"version": "4.0",
"vulnAvailabilityImpact": "NONE",
"vulnConfidentialityImpact": "LOW",
"vulnIntegrityImpact": "LOW",
"vulnerabilityResponseEffort": "NOT_DEFINED"
},
"format": "CVSS",
"scenarios": [
{
"lang": "en",
"value": "GENERAL"
}
]
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-444",
"description": "CWE-444 Inconsistent Interpretation of HTTP Requests (\u0027HTTP Request/Response Smuggling\u0027)",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-09-29T10:16:39.032Z",
"orgId": "6b3ad84c-e1a6-4bf7-a703-f496b71e49db",
"shortName": "EEF"
},
"references": [
{
"name": "GitHub Advisory",
"tags": [
"related",
"vendor-advisory"
],
"url": "https://github.com/elixir-mint/mint/security/advisories/GHSA-gvrc-75rc-7gj9"
},
{
"name": "EEF CNA record for CVE-2026-94194",
"tags": [
"related"
],
"url": "https://cna.erlef.org/cves/CVE-2026-94194.html"
},
{
"name": "OSV record EEF-CVE-2026-94194",
"tags": [
"related"
],
"url": "https://osv.dev/vulnerability/EEF-CVE-2026-94194"
},
{
"name": "Introducing commit 6008958 in elixir-mint/mint",
"tags": [
"related"
],
"url": "https://github.com/elixir-mint/mint/commit/60089586ec7adc9fddb09f69a2f5919ba9ac7f33"
},
{
"name": "Fix commit 2ec8b69 in elixir-mint/mint",
"tags": [
"patch"
],
"url": "https://github.com/elixir-mint/mint/commit/2ec8b696b5475ecbdaa87c0098957bca339e17c0"
},
{
"name": "Fix commit 8d1bbcf in elixir-mint/mint",
"tags": [
"patch"
],
"url": "https://github.com/elixir-mint/mint/commit/8d1bbcfa566a8c1dc23d33f40d550c28250ac7b9"
}
],
"source": {
"discovery": "EXTERNAL"
},
"title": "Mint HTTP/1 client applies chunked framing when chunked is not the final transfer coding, enabling response smuggling through intermediaries",
"x_proofOfConcept": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003col\u003e\n\u003cli\u003eStart a loopback TCP server that answers the first request with \u003ccode\u003eHTTP/1.1 200 OK\u003c/code\u003e and \u003ccode\u003eTransfer-Encoding: chunked, gzip\u003c/code\u003e, the chunked body \u003ccode\u003e5\\r\\nLEGIT\\r\\n0\\r\\n\\r\\n\u003c/code\u003e, and directly after it the bytes \u003ccode\u003eHTTP/1.1 200 OK\\r\\nContent-Length: 8\\r\\n\\r\\nSMUGGLED\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eConnect with \u003ccode\u003eMint.HTTP1\u003c/code\u003e and send a request. Mint returns \u003ccode\u003eLEGIT\u003c/code\u003e as the complete body, keeps the connection open, and holds the second response in \u003ccode\u003econn.buffer\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eSend a second request on the same connection and have the server answer it with a real response. Mint returns \u003ccode\u003eSMUGGLED\u003c/code\u003e as the response to the second request and keeps the real one in the buffer.\u003c/li\u003e\n\u003cli\u003ePipelining both requests before the server answers gives the same result from a single \u003ccode\u003eMint.HTTP1.stream/2\u003c/code\u003e call.\u003c/li\u003e\n\u003c/ol\u003e"
},
{
"base64": false,
"type": "text/markdown",
"value": "1. Start a loopback TCP server that answers the first request with `HTTP/1.1 200 OK` and `Transfer-Encoding: chunked, gzip`, the chunked body `5\\r\\nLEGIT\\r\\n0\\r\\n\\r\\n`, and directly after it the bytes `HTTP/1.1 200 OK\\r\\nContent-Length: 8\\r\\n\\r\\nSMUGGLED`.\n2. Connect with `Mint.HTTP1` and send a request. Mint returns `LEGIT` as the complete body, keeps the connection open, and holds the second response in `conn.buffer`.\n3. Send a second request on the same connection and have the server answer it with a real response. Mint returns `SMUGGLED` as the response to the second request and keeps the real one in the buffer.\n4. Pipelining both requests before the server answers gives the same result from a single `Mint.HTTP1.stream/2` call."
}
],
"value": "* Start a loopback TCP server that answers the first request with HTTP/1.1 200 OK and Transfer-Encoding: chunked, gzip, the chunked body 5\\r\\nLEGIT\\r\\n0\\r\\n\\r\\n, and directly after it the bytes HTTP/1.1 200 OK\\r\\nContent-Length: 8\\r\\n\\r\\nSMUGGLED.\n* Connect with Mint.HTTP1 and send a request. Mint returns LEGIT as the complete body, keeps the connection open, and holds the second response in conn.buffer.\n* Send a second request on the same connection and have the server answer it with a real response. Mint returns SMUGGLED as the response to the second request and keeps the real one in the buffer.\n* Pipelining both requests before the server answers gives the same result from a single Mint.HTTP1.stream/2 call."
}
],
"x_technicalAnalysis": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003e\u003cstrong\u003e1. Coding list.\u003c/strong\u003e \u003ccode\u003estore_header/3\u003c/code\u003e in \u003ccode\u003elib/mint/http1.ex\u003c/code\u003e tokenizes each \u003ccode\u003eTransfer-Encoding\u003c/code\u003e field with \u003ccode\u003eMint.HTTP1.Parse.transfer_encoding_header/1\u003c/code\u003e and appends the codings to \u003ccode\u003erequest.transfer_encoding\u003c/code\u003e in the order received.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e2. Framing decision.\u003c/strong\u003e \u003ccode\u003emessage_body/1\u003c/code\u003e returns chunked framing when \u003ccode\u003eList.first(request.transfer_encoding)\u003c/code\u003e is \u003ccode\u003e\"chunked\"\u003c/code\u003e. The only other \u003ccode\u003eTransfer-Encoding\u003c/code\u003e check rejects a response that also carries \u003ccode\u003eContent-Length\u003c/code\u003e, so \u003ccode\u003echunked, gzip\u003c/code\u003e on its own is framed as chunked.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e3. Leftover bytes.\u003c/strong\u003e \u003ccode\u003edecode_body/5\u003c/code\u003e ends the body at the zero-length chunk and its trailer section, and \u003ccode\u003enext_request/3\u003c/code\u003e keeps the rest of the data in \u003ccode\u003econn.buffer\u003c/code\u003e or decodes it immediately as the next queued response. An RFC 9112 intermediary frames the same response as ending at connection close, so bytes it forwarded as body of the first response become the response to the next request on the Mint connection, and that request\u0027s real response is left in the buffer for the one after it.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e4. HTTP/1.0 keep-alive.\u003c/strong\u003e \u003ccode\u003erequest_done/2\u003c/code\u003e keeps an HTTP/1.0 connection open when the response has \u003ccode\u003eConnection: keep-alive\u003c/code\u003e, without checking for \u003ccode\u003eTransfer-Encoding\u003c/code\u003e, and \u003ccode\u003edecode_body(:informational, ...)\u003c/code\u003e resets the framing state of a 1xx response and keeps parsing. An HTTP/1.0 response with \u003ccode\u003eTransfer-Encoding: chunked\u003c/code\u003e and \u003ccode\u003eConnection: keep-alive\u003c/code\u003e therefore leaves the connection open after its chunked body, and the following bytes are decoded as the next queued response, although RFC 9112 section 6.1 requires closing the connection after such a message.\u003c/p\u003e"
},
{
"base64": false,
"type": "text/markdown",
"value": "**1. Coding list.** `store_header/3` in `lib/mint/http1.ex` tokenizes each `Transfer-Encoding` field with `Mint.HTTP1.Parse.transfer_encoding_header/1` and appends the codings to `request.transfer_encoding` in the order received.\n\n**2. Framing decision.** `message_body/1` returns chunked framing when `List.first(request.transfer_encoding)` is `\"chunked\"`. The only other `Transfer-Encoding` check rejects a response that also carries `Content-Length`, so `chunked, gzip` on its own is framed as chunked.\n\n**3. Leftover bytes.** `decode_body/5` ends the body at the zero-length chunk and its trailer section, and `next_request/3` keeps the rest of the data in `conn.buffer` or decodes it immediately as the next queued response. An RFC 9112 intermediary frames the same response as ending at connection close, so bytes it forwarded as body of the first response become the response to the next request on the Mint connection, and that request\u0027s real response is left in the buffer for the one after it.\n\n**4. HTTP/1.0 keep-alive.** `request_done/2` keeps an HTTP/1.0 connection open when the response has `Connection: keep-alive`, without checking for `Transfer-Encoding`, and `decode_body(:informational, ...)` resets the framing state of a 1xx response and keeps parsing. An HTTP/1.0 response with `Transfer-Encoding: chunked` and `Connection: keep-alive` therefore leaves the connection open after its chunked body, and the following bytes are decoded as the next queued response, although RFC 9112 section 6.1 requires closing the connection after such a message."
}
],
"value": "1. Coding list. store_header/3 in lib/mint/http1.ex tokenizes each Transfer-Encoding field with Mint.HTTP1.Parse.transfer_encoding_header/1 and appends the codings to request.transfer_encoding in the order received.\n\n2. Framing decision. message_body/1 returns chunked framing when List.first(request.transfer_encoding) is \"chunked\". The only other Transfer-Encoding check rejects a response that also carries Content-Length, so chunked, gzip on its own is framed as chunked.\n\n3. Leftover bytes. decode_body/5 ends the body at the zero-length chunk and its trailer section, and next_request/3 keeps the rest of the data in conn.buffer or decodes it immediately as the next queued response. An RFC 9112 intermediary frames the same response as ending at connection close, so bytes it forwarded as body of the first response become the response to the next request on the Mint connection, and that request\u0027s real response is left in the buffer for the one after it.\n\n4. HTTP/1.0 keep-alive. request_done/2 keeps an HTTP/1.0 connection open when the response has Connection: keep-alive, without checking for Transfer-Encoding, and decode_body(:informational, ...) resets the framing state of a 1xx response and keeps parsing. An HTTP/1.0 response with Transfer-Encoding: chunked and Connection: keep-alive therefore leaves the connection open after its chunked body, and the following bytes are decoded as the next queued response, although RFC 9112 section 6.1 requires closing the connection after such a message."
}
]
}
},
"cveMetadata": {
"assignerOrgId": "6b3ad84c-e1a6-4bf7-a703-f496b71e49db",
"assignerShortName": "EEF",
"cveId": "CVE-2026-94194",
"datePublished": "2026-09-28T11:15:30.684Z",
"dateReserved": "2026-09-24T13:45:02.496Z",
"dateUpdated": "2026-09-30T13:17:02.563Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
CVE-2026-92103 (GCVE-0-2026-92103)
Vulnerability from cvelistv5 – Published: 2026-09-28 11:15 – Updated: 2026-09-30 15:00
VLAI
EPSS
VEX
Title
Mint HTTP/2 client buffers oversized frames up to 16 MiB before enforcing max_frame_size
Summary
Allocation of Resources Without Limits or Throttling vulnerability in elixir-mint mint allows a malicious HTTP/2 server to make the client hold up to about 16 MiB per connection in frames it should reject, consuming client memory.
Mint.HTTP2.Frame.decode_next/2 in lib/mint/http2/frame.ex compares a frame with the client's max_frame_size (16,384 bytes by default) only once the whole declared payload has arrived. Until then it returns :more, and Mint.HTTP2 keeps every received byte in the connection buffer. A server can declare a frame length of up to 16,777,215 bytes and withhold the last byte, keeping roughly 1,024 times the advertised limit buffered for as long as the connection stays open. The server has to send every byte the client buffers, so there is no amplification, and the buffer stops at the 24-bit frame length limit.
This issue affects mint: from 0.1.0 before 1.10.2.
Severity
SSVC
Exploitation: poc
Automatable: no
Technical Impact: partial
CISA Coordinator · CISA-ADP (v2.0.3)
Decision recorded 2026-09-30 15:00 UTC
CWE
- CWE-770 - Allocation of Resources Without Limits or Throttling
Assigner
References
6 references
Impacted products
2 products
| Vendor | Product | Version | |
|---|---|---|---|
| elixir-mint | mint |
Affected:
0.1.0 , < 1.10.2
(semver)
cpe:2.3:a:elixir-mint:mint:*:*:*:*:*:*:*:* |
|
| elixir-mint | mint |
Affected:
596ca4304504be68939c4929e0831557097962b8 , < *
(git)
cpe:2.3:a:elixir-mint:mint:*:*:*:*:*:*:*:* |
Date Public
2026-09-28 11:15
{
"containers": {
"adp": [
{
"metrics": [
{
"other": {
"content": {
"id": "CVE-2026-92103",
"options": [
{
"Exploitation": "poc"
},
{
"Automatable": "no"
},
{
"Technical Impact": "partial"
}
],
"role": "CISA Coordinator",
"timestamp": "2026-09-30T15:00:25.491334Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"providerMetadata": {
"dateUpdated": "2026-09-30T15:00:38.567Z",
"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"shortName": "CISA-ADP"
},
"title": "CISA ADP Vulnrichment"
}
],
"cna": {
"affected": [
{
"collectionURL": "https://repo.hex.pm",
"cpes": [
"cpe:2.3:a:elixir-mint:mint:*:*:*:*:*:*:*:*"
],
"defaultStatus": "unaffected",
"modules": [
"\u0027Elixir.Mint.HTTP2.Frame\u0027",
"\u0027Elixir.Mint.HTTP2\u0027"
],
"packageName": "mint",
"packageURL": "pkg:hex/mint",
"product": "mint",
"programFiles": [
"lib/mint/http2/frame.ex",
"lib/mint/http2.ex"
],
"programRoutines": [
{
"name": "\u0027Elixir.Mint.HTTP2.Frame\u0027:decode_next/2"
},
{
"name": "\u0027Elixir.Mint.HTTP2\u0027:stream/2"
},
{
"name": "\u0027Elixir.Mint.HTTP2\u0027:recv/3"
},
{
"name": "\u0027Elixir.Mint.HTTP2\u0027:handle_new_data/3"
}
],
"repo": "https://github.com/elixir-mint/mint",
"vendor": "elixir-mint",
"versions": [
{
"lessThan": "1.10.2",
"status": "affected",
"version": "0.1.0",
"versionType": "semver"
}
]
},
{
"collectionURL": "https://github.com",
"cpes": [
"cpe:2.3:a:elixir-mint:mint:*:*:*:*:*:*:*:*"
],
"defaultStatus": "unaffected",
"modules": [
"\u0027Elixir.Mint.HTTP2.Frame\u0027",
"\u0027Elixir.Mint.HTTP2\u0027"
],
"packageName": "elixir-mint/mint",
"packageURL": "pkg:github/elixir-mint/mint",
"product": "mint",
"programFiles": [
"lib/mint/http2/frame.ex",
"lib/mint/http2.ex"
],
"programRoutines": [
{
"name": "\u0027Elixir.Mint.HTTP2.Frame\u0027:decode_next/2"
},
{
"name": "\u0027Elixir.Mint.HTTP2\u0027:stream/2"
},
{
"name": "\u0027Elixir.Mint.HTTP2\u0027:recv/3"
},
{
"name": "\u0027Elixir.Mint.HTTP2\u0027:handle_new_data/3"
}
],
"repo": "https://github.com/elixir-mint/mint",
"vendor": "elixir-mint",
"versions": [
{
"changes": [
{
"at": "20252ca85065f4d1092aed9ee4ed21841a507dfe",
"status": "unaffected"
},
{
"at": "44d7ce4755d0444ee415cbcca7ce4942382da4dd",
"status": "unaffected"
}
],
"lessThan": "*",
"status": "affected",
"version": "596ca4304504be68939c4929e0831557097962b8",
"versionType": "git"
}
]
}
],
"cpeApplicability": [
{
"nodes": [
{
"cpeMatch": [
{
"criteria": "cpe:2.3:a:elixir-mint:mint:*:*:*:*:*:*:*:*",
"versionEndExcluding": "1.10.2",
"versionStartIncluding": "0.1.0",
"vulnerable": true
}
],
"negate": false,
"operator": "OR"
}
],
"operator": "AND"
}
],
"credits": [
{
"lang": "en",
"type": "finder",
"value": "zx"
},
{
"lang": "en",
"type": "reporter",
"value": "zx"
},
{
"lang": "en",
"type": "remediation developer",
"value": "Andrea Leopardi"
},
{
"lang": "en",
"type": "remediation reviewer",
"value": "Eric Meadows-J\u00f6nsson"
}
],
"dateAssigned": "2026-09-24T09:19:17.000Z",
"datePublic": "2026-09-28T11:15:20.000Z",
"descriptions": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003eAllocation of Resources Without Limits or Throttling vulnerability in elixir-mint mint allows a malicious HTTP/2 server to make the client hold up to about 16 MiB per connection in frames it should reject, consuming client memory.\u003c/p\u003e\n\u003cp\u003e\u003ccode\u003eMint.HTTP2.Frame.decode_next/2\u003c/code\u003e in \u003ccode\u003elib/mint/http2/frame.ex\u003c/code\u003e compares a frame with the client\u0027s \u003ccode\u003emax_frame_size\u003c/code\u003e (16,384 bytes by default) only once the whole declared payload has arrived. Until then it returns \u003ccode\u003e:more\u003c/code\u003e, and \u003ccode\u003eMint.HTTP2\u003c/code\u003e keeps every received byte in the connection buffer. A server can declare a frame length of up to 16,777,215 bytes and withhold the last byte, keeping roughly 1,024 times the advertised limit buffered for as long as the connection stays open. The server has to send every byte the client buffers, so there is no amplification, and the buffer stops at the 24-bit frame length limit.\u003c/p\u003e\n\u003cp\u003eThis issue affects mint: from 0.1.0 before 1.10.2.\u003c/p\u003e"
},
{
"base64": false,
"type": "text/markdown",
"value": "Allocation of Resources Without Limits or Throttling vulnerability in elixir-mint mint allows a malicious HTTP/2 server to make the client hold up to about 16 MiB per connection in frames it should reject, consuming client memory.\n\n`Mint.HTTP2.Frame.decode_next/2` in `lib/mint/http2/frame.ex` compares a frame with the client\u0027s `max_frame_size` (16,384 bytes by default) only once the whole declared payload has arrived. Until then it returns `:more`, and `Mint.HTTP2` keeps every received byte in the connection buffer. A server can declare a frame length of up to 16,777,215 bytes and withhold the last byte, keeping roughly 1,024 times the advertised limit buffered for as long as the connection stays open. The server has to send every byte the client buffers, so there is no amplification, and the buffer stops at the 24-bit frame length limit.\n\nThis issue affects mint: from 0.1.0 before 1.10.2."
}
],
"value": "Allocation of Resources Without Limits or Throttling vulnerability in elixir-mint mint allows a malicious HTTP/2 server to make the client hold up to about 16 MiB per connection in frames it should reject, consuming client memory.\n\nMint.HTTP2.Frame.decode_next/2 in lib/mint/http2/frame.ex compares a frame with the client\u0027s max_frame_size (16,384 bytes by default) only once the whole declared payload has arrived. Until then it returns :more, and Mint.HTTP2 keeps every received byte in the connection buffer. A server can declare a frame length of up to 16,777,215 bytes and withhold the last byte, keeping roughly 1,024 times the advertised limit buffered for as long as the connection stays open. The server has to send every byte the client buffers, so there is no amplification, and the buffer stops at the 24-bit frame length limit.\n\nThis issue affects mint: from 0.1.0 before 1.10.2."
}
],
"impacts": [
{
"capecId": "CAPEC-130",
"descriptions": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003eA malicious or compromised HTTP/2 server can make a Mint client keep up to about 16 MiB per connection buffered, and keep it there while the connection stays open. Clients that hold many HTTP/2 connections to attacker-influenced origins, such as webhook senders, crawlers and proxies, can run out of memory.\u003c/p\u003e"
},
{
"base64": false,
"type": "text/markdown",
"value": "A malicious or compromised HTTP/2 server can make a Mint client keep up to about 16 MiB per connection buffered, and keep it there while the connection stays open. Clients that hold many HTTP/2 connections to attacker-influenced origins, such as webhook senders, crawlers and proxies, can run out of memory."
}
],
"value": "A malicious or compromised HTTP/2 server can make a Mint client keep up to about 16 MiB per connection buffered, and keep it there while the connection stays open. Clients that hold many HTTP/2 connections to attacker-influenced origins, such as webhook senders, crawlers and proxies, can run out of memory."
}
]
}
],
"metrics": [
{
"cvssV4_0": {
"Automatable": "NOT_DEFINED",
"Recovery": "NOT_DEFINED",
"Safety": "NOT_DEFINED",
"attackComplexity": "LOW",
"attackRequirements": "PRESENT",
"attackVector": "NETWORK",
"baseScore": 6.3,
"baseSeverity": "MEDIUM",
"privilegesRequired": "NONE",
"providerUrgency": "NOT_DEFINED",
"subAvailabilityImpact": "NONE",
"subConfidentialityImpact": "NONE",
"subIntegrityImpact": "NONE",
"userInteraction": "NONE",
"valueDensity": "NOT_DEFINED",
"vectorString": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N",
"version": "4.0",
"vulnAvailabilityImpact": "LOW",
"vulnConfidentialityImpact": "NONE",
"vulnIntegrityImpact": "NONE",
"vulnerabilityResponseEffort": "NOT_DEFINED"
},
"format": "CVSS",
"scenarios": [
{
"lang": "en",
"value": "GENERAL"
}
]
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-770",
"description": "CWE-770 Allocation of Resources Without Limits or Throttling",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-09-29T10:15:35.604Z",
"orgId": "6b3ad84c-e1a6-4bf7-a703-f496b71e49db",
"shortName": "EEF"
},
"references": [
{
"name": "GitHub Advisory",
"tags": [
"related",
"vendor-advisory"
],
"url": "https://github.com/elixir-mint/mint/security/advisories/GHSA-q95c-ccq6-j5j6"
},
{
"name": "EEF CNA record for CVE-2026-92103",
"tags": [
"related"
],
"url": "https://cna.erlef.org/cves/CVE-2026-92103.html"
},
{
"name": "OSV record EEF-CVE-2026-92103",
"tags": [
"related"
],
"url": "https://osv.dev/vulnerability/EEF-CVE-2026-92103"
},
{
"name": "Introducing commit 596ca43 in elixir-mint/mint",
"tags": [
"related"
],
"url": "https://github.com/elixir-mint/mint/commit/596ca4304504be68939c4929e0831557097962b8"
},
{
"name": "Fix commit 20252ca in elixir-mint/mint",
"tags": [
"patch"
],
"url": "https://github.com/elixir-mint/mint/commit/20252ca85065f4d1092aed9ee4ed21841a507dfe"
},
{
"name": "Fix commit 44d7ce4 in elixir-mint/mint",
"tags": [
"patch"
],
"url": "https://github.com/elixir-mint/mint/commit/44d7ce4755d0444ee415cbcca7ce4942382da4dd"
}
],
"source": {
"discovery": "EXTERNAL"
},
"title": "Mint HTTP/2 client buffers oversized frames up to 16 MiB before enforcing max_frame_size",
"workarounds": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003eConnect to untrusted origins over HTTP/1 only, with \u003ccode\u003eprotocols: [:http1]\u003c/code\u003e in \u003ccode\u003eMint.HTTP.connect/4\u003c/code\u003e, which never runs the HTTP/2 frame decoder. Finch and Req pools use HTTP/1 only unless \u003ccode\u003e:http2\u003c/code\u003e is added to their \u003ccode\u003eprotocols\u003c/code\u003e option.\u003c/p\u003e"
},
{
"base64": false,
"type": "text/markdown",
"value": "Connect to untrusted origins over HTTP/1 only, with `protocols: [:http1]` in `Mint.HTTP.connect/4`, which never runs the HTTP/2 frame decoder. Finch and Req pools use HTTP/1 only unless `:http2` is added to their `protocols` option."
}
],
"value": "Connect to untrusted origins over HTTP/1 only, with protocols: [:http1] in Mint.HTTP.connect/4, which never runs the HTTP/2 frame decoder. Finch and Req pools use HTTP/1 only unless :http2 is added to their protocols option."
}
],
"x_proofOfConcept": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003col\u003e\n\u003cli\u003eBuild an HTTP/2 frame header whose 24-bit length field declares 1,000,000 bytes, above the default \u003ccode\u003emax_frame_size\u003c/code\u003e of 16,384.\u003c/li\u003e\n\u003cli\u003ePass the header followed by 16,384 and then 512,000 payload bytes to \u003ccode\u003eMint.HTTP2.Frame.decode_next/2\u003c/code\u003e with a limit of 16,384. Each call returns \u003ccode\u003e:more\u003c/code\u003e, which makes \u003ccode\u003eMint.HTTP2\u003c/code\u003e keep the bytes in \u003ccode\u003econn.buffer\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003ePass the header with the complete 1,000,000-byte payload. Only this call returns \u003ccode\u003e{:error, :payload_too_big}\u003c/code\u003e.\u003c/li\u003e\n\u003c/ol\u003e"
},
{
"base64": false,
"type": "text/markdown",
"value": "1. Build an HTTP/2 frame header whose 24-bit length field declares 1,000,000 bytes, above the default `max_frame_size` of 16,384.\n2. Pass the header followed by 16,384 and then 512,000 payload bytes to `Mint.HTTP2.Frame.decode_next/2` with a limit of 16,384. Each call returns `:more`, which makes `Mint.HTTP2` keep the bytes in `conn.buffer`.\n3. Pass the header with the complete 1,000,000-byte payload. Only this call returns `{:error, :payload_too_big}`."
}
],
"value": "* Build an HTTP/2 frame header whose 24-bit length field declares 1,000,000 bytes, above the default max_frame_size of 16,384.\n* Pass the header followed by 16,384 and then 512,000 payload bytes to Mint.HTTP2.Frame.decode_next/2 with a limit of 16,384. Each call returns :more, which makes Mint.HTTP2 keep the bytes in conn.buffer.\n* Pass the header with the complete 1,000,000-byte payload. Only this call returns {:error, :payload_too_big}."
}
],
"x_technicalAnalysis": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003e\u003cstrong\u003e1. Late size check.\u003c/strong\u003e \u003ccode\u003eMint.HTTP2.Frame.decode_next/2\u003c/code\u003e calls \u003ccode\u003edecode_next_raw/1\u003c/code\u003e, whose binary pattern only matches once the full declared payload is present. The \u003ccode\u003emax_frame_size\u003c/code\u003e guard runs on the matched payload, so a partial frame of any declared length returns \u003ccode\u003e:more\u003c/code\u003e.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e2. Unbounded buffering.\u003c/strong\u003e On \u003ccode\u003e:more\u003c/code\u003e, \u003ccode\u003eMint.HTTP2.handle_new_data/3\u003c/code\u003e stores the accumulated data in \u003ccode\u003econn.buffer\u003c/code\u003e, and \u003ccode\u003emaybe_concat_and_handle_new_data/2\u003c/code\u003e prepends it to every later socket read, in both \u003ccode\u003estream/2\u003c/code\u003e (active mode) and \u003ccode\u003erecv/3\u003c/code\u003e (passive mode). Nothing caps the buffer.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e3. No release.\u003c/strong\u003e Mint has no idle timer. In active mode the buffer is held until the caller closes the connection. In passive mode a \u003ccode\u003erecv/3\u003c/code\u003e timeout closes it, but a server that sends a byte within each timeout keeps it open. \u003ccode\u003emax_frame_size\u003c/code\u003e can\u0027t be set below the 16,384-byte protocol minimum, and no setting moves the check earlier.\u003c/p\u003e"
},
{
"base64": false,
"type": "text/markdown",
"value": "**1. Late size check.** `Mint.HTTP2.Frame.decode_next/2` calls `decode_next_raw/1`, whose binary pattern only matches once the full declared payload is present. The `max_frame_size` guard runs on the matched payload, so a partial frame of any declared length returns `:more`.\n\n**2. Unbounded buffering.** On `:more`, `Mint.HTTP2.handle_new_data/3` stores the accumulated data in `conn.buffer`, and `maybe_concat_and_handle_new_data/2` prepends it to every later socket read, in both `stream/2` (active mode) and `recv/3` (passive mode). Nothing caps the buffer.\n\n**3. No release.** Mint has no idle timer. In active mode the buffer is held until the caller closes the connection. In passive mode a `recv/3` timeout closes it, but a server that sends a byte within each timeout keeps it open. `max_frame_size` can\u0027t be set below the 16,384-byte protocol minimum, and no setting moves the check earlier."
}
],
"value": "1. Late size check. Mint.HTTP2.Frame.decode_next/2 calls decode_next_raw/1, whose binary pattern only matches once the full declared payload is present. The max_frame_size guard runs on the matched payload, so a partial frame of any declared length returns :more.\n\n2. Unbounded buffering. On :more, Mint.HTTP2.handle_new_data/3 stores the accumulated data in conn.buffer, and maybe_concat_and_handle_new_data/2 prepends it to every later socket read, in both stream/2 (active mode) and recv/3 (passive mode). Nothing caps the buffer.\n\n3. No release. Mint has no idle timer. In active mode the buffer is held until the caller closes the connection. In passive mode a recv/3 timeout closes it, but a server that sends a byte within each timeout keeps it open. max_frame_size can\u0027t be set below the 16,384-byte protocol minimum, and no setting moves the check earlier."
}
]
}
},
"cveMetadata": {
"assignerOrgId": "6b3ad84c-e1a6-4bf7-a703-f496b71e49db",
"assignerShortName": "EEF",
"cveId": "CVE-2026-92103",
"datePublished": "2026-09-28T11:15:20.657Z",
"dateReserved": "2026-09-15T16:00:01.513Z",
"dateUpdated": "2026-09-30T15:00:38.567Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
CVE-2026-91043 (GCVE-0-2026-91043)
Vulnerability from cvelistv5 – Published: 2026-09-28 11:15 – Updated: 2026-09-29 10:15
VLAI
EPSS
VEX
Title
HPACK-indexed cookie fields in Mint HTTP/2 responses bypass max_header_list_size and exhaust client memory
Summary
Allocation of Resources Without Limits or Throttling vulnerability in elixir-mint mint allows a malicious HTTP/2 server to exhaust memory on the client host and cause a denial of service.
Mint.HTTP2 enforces the client's max_header_list_size setting only on the compressed size of an inbound header block, while RFC 9113 section 6.5.2 defines the limit on the decoded header list. An HPACK indexed field costs one byte on the wire and decodes to a dynamic table entry of up to 4 KB, and join_cookie_headers/1 in lib/mint/http2.ex copies every cookie value of a response into one new binary. A header block under the default 256 KB wire limit therefore makes the client allocate about 1 GB for a single response, and several such responses in one delivery exhaust the memory of the process that owns the connection or of the whole VM.
This issue affects mint: from 1.1.0 before 1.10.2.
Severity
SSVC
Exploitation: none
Automatable: no
Technical Impact: partial
CISA Coordinator · CISA-ADP (v2.0.3)
Decision recorded 2026-09-28 13:20 UTC
CWE
- CWE-770 - Allocation of Resources Without Limits or Throttling
Assigner
References
6 references
Impacted products
2 products
| Vendor | Product | Version | |
|---|---|---|---|
| elixir-mint | mint |
Affected:
1.1.0 , < 1.10.2
(semver)
cpe:2.3:a:elixir-mint:mint:*:*:*:*:*:*:*:* |
|
| elixir-mint | mint |
Affected:
8e0e04680476f90f9f68db4dfeabcbe66dabfc4d , < *
(git)
cpe:2.3:a:elixir-mint:mint:*:*:*:*:*:*:*:* |
Date Public
2026-09-28 11:15
{
"containers": {
"adp": [
{
"metrics": [
{
"other": {
"content": {
"id": "CVE-2026-91043",
"options": [
{
"Exploitation": "none"
},
{
"Automatable": "no"
},
{
"Technical Impact": "partial"
}
],
"role": "CISA Coordinator",
"timestamp": "2026-09-28T13:20:39.397915Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"providerMetadata": {
"dateUpdated": "2026-09-28T13:31:29.037Z",
"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"shortName": "CISA-ADP"
},
"title": "CISA ADP Vulnrichment"
}
],
"cna": {
"affected": [
{
"collectionURL": "https://repo.hex.pm",
"cpes": [
"cpe:2.3:a:elixir-mint:mint:*:*:*:*:*:*:*:*"
],
"defaultStatus": "unaffected",
"modules": [
"\u0027Elixir.Mint.HTTP2\u0027"
],
"packageName": "mint",
"packageURL": "pkg:hex/mint",
"product": "mint",
"programFiles": [
"lib/mint/http2.ex"
],
"programRoutines": [
{
"name": "\u0027Elixir.Mint.HTTP2\u0027:stream/2"
},
{
"name": "\u0027Elixir.Mint.HTTP2\u0027:decode_hbf_and_add_responses/5"
},
{
"name": "\u0027Elixir.Mint.HTTP2\u0027:join_cookie_headers/1"
}
],
"repo": "https://github.com/elixir-mint/mint",
"vendor": "elixir-mint",
"versions": [
{
"lessThan": "1.10.2",
"status": "affected",
"version": "1.1.0",
"versionType": "semver"
}
]
},
{
"collectionURL": "https://github.com",
"cpes": [
"cpe:2.3:a:elixir-mint:mint:*:*:*:*:*:*:*:*"
],
"defaultStatus": "unaffected",
"modules": [
"\u0027Elixir.Mint.HTTP2\u0027"
],
"packageName": "elixir-mint/mint",
"packageURL": "pkg:github/elixir-mint/mint",
"product": "mint",
"programFiles": [
"lib/mint/http2.ex"
],
"programRoutines": [
{
"name": "\u0027Elixir.Mint.HTTP2\u0027:stream/2"
},
{
"name": "\u0027Elixir.Mint.HTTP2\u0027:decode_hbf_and_add_responses/5"
},
{
"name": "\u0027Elixir.Mint.HTTP2\u0027:join_cookie_headers/1"
}
],
"repo": "https://github.com/elixir-mint/mint",
"vendor": "elixir-mint",
"versions": [
{
"changes": [
{
"at": "c7895cb022196c77ec35570c8e873a84393ff4b8",
"status": "unaffected"
},
{
"at": "65a0d61c9eab6b0dedac809de7212515bf506250",
"status": "unaffected"
}
],
"lessThan": "*",
"status": "affected",
"version": "8e0e04680476f90f9f68db4dfeabcbe66dabfc4d",
"versionType": "git"
}
]
}
],
"cpeApplicability": [
{
"nodes": [
{
"cpeMatch": [
{
"criteria": "cpe:2.3:a:elixir-mint:mint:*:*:*:*:*:*:*:*",
"versionEndExcluding": "1.10.2",
"versionStartIncluding": "1.1.0",
"vulnerable": true
}
],
"negate": false,
"operator": "OR"
}
],
"operator": "AND"
}
],
"credits": [
{
"lang": "en",
"type": "finder",
"value": "Eric Meadows-J\u00f6nsson"
},
{
"lang": "en",
"type": "remediation developer",
"value": "Eric Meadows-J\u00f6nsson"
},
{
"lang": "en",
"type": "remediation reviewer",
"value": "Andrea Leopardi"
}
],
"dateAssigned": "2026-09-21T12:06:31.000Z",
"datePublic": "2026-09-28T11:15:09.000Z",
"descriptions": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003eAllocation of Resources Without Limits or Throttling vulnerability in elixir-mint mint allows a malicious HTTP/2 server to exhaust memory on the client host and cause a denial of service.\u003c/p\u003e\n\u003cp\u003e\u003ccode\u003eMint.HTTP2\u003c/code\u003e enforces the client\u0027s \u003ccode\u003emax_header_list_size\u003c/code\u003e setting only on the compressed size of an inbound header block, while RFC 9113 section 6.5.2 defines the limit on the decoded header list. An HPACK indexed field costs one byte on the wire and decodes to a dynamic table entry of up to 4 KB, and \u003ccode\u003ejoin_cookie_headers/1\u003c/code\u003e in \u003ccode\u003elib/mint/http2.ex\u003c/code\u003e copies every \u003ccode\u003ecookie\u003c/code\u003e value of a response into one new binary. A header block under the default 256 KB wire limit therefore makes the client allocate about 1 GB for a single response, and several such responses in one delivery exhaust the memory of the process that owns the connection or of the whole VM.\u003c/p\u003e\n\u003cp\u003eThis issue affects mint: from 1.1.0 before 1.10.2.\u003c/p\u003e"
},
{
"base64": false,
"type": "text/markdown",
"value": "Allocation of Resources Without Limits or Throttling vulnerability in elixir-mint mint allows a malicious HTTP/2 server to exhaust memory on the client host and cause a denial of service.\n\n`Mint.HTTP2` enforces the client\u0027s `max_header_list_size` setting only on the compressed size of an inbound header block, while RFC 9113 section 6.5.2 defines the limit on the decoded header list. An HPACK indexed field costs one byte on the wire and decodes to a dynamic table entry of up to 4 KB, and `join_cookie_headers/1` in `lib/mint/http2.ex` copies every `cookie` value of a response into one new binary. A header block under the default 256 KB wire limit therefore makes the client allocate about 1 GB for a single response, and several such responses in one delivery exhaust the memory of the process that owns the connection or of the whole VM.\n\nThis issue affects mint: from 1.1.0 before 1.10.2."
}
],
"value": "Allocation of Resources Without Limits or Throttling vulnerability in elixir-mint mint allows a malicious HTTP/2 server to exhaust memory on the client host and cause a denial of service.\n\nMint.HTTP2 enforces the client\u0027s max_header_list_size setting only on the compressed size of an inbound header block, while RFC 9113 section 6.5.2 defines the limit on the decoded header list. An HPACK indexed field costs one byte on the wire and decodes to a dynamic table entry of up to 4 KB, and join_cookie_headers/1 in lib/mint/http2.ex copies every cookie value of a response into one new binary. A header block under the default 256 KB wire limit therefore makes the client allocate about 1 GB for a single response, and several such responses in one delivery exhaust the memory of the process that owns the connection or of the whole VM.\n\nThis issue affects mint: from 1.1.0 before 1.10.2."
}
],
"impacts": [
{
"capecId": "CAPEC-130",
"descriptions": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003eA malicious or compromised HTTP/2 server can make a Mint client allocate about 1 GB per response with default settings, exhausting host memory until the operating system kills the BEAM. HTTP/2 connection pools in Finch and Req, webhook and scraper clients, and reverse proxies fetching from untrusted upstreams are affected without any opt-in.\u003c/p\u003e"
},
{
"base64": false,
"type": "text/markdown",
"value": "A malicious or compromised HTTP/2 server can make a Mint client allocate about 1 GB per response with default settings, exhausting host memory until the operating system kills the BEAM. HTTP/2 connection pools in Finch and Req, webhook and scraper clients, and reverse proxies fetching from untrusted upstreams are affected without any opt-in."
}
],
"value": "A malicious or compromised HTTP/2 server can make a Mint client allocate about 1 GB per response with default settings, exhausting host memory until the operating system kills the BEAM. HTTP/2 connection pools in Finch and Req, webhook and scraper clients, and reverse proxies fetching from untrusted upstreams are affected without any opt-in."
}
]
}
],
"metrics": [
{
"cvssV4_0": {
"Automatable": "NOT_DEFINED",
"Recovery": "NOT_DEFINED",
"Safety": "NOT_DEFINED",
"attackComplexity": "LOW",
"attackRequirements": "PRESENT",
"attackVector": "NETWORK",
"baseScore": 8.2,
"baseSeverity": "HIGH",
"privilegesRequired": "NONE",
"providerUrgency": "NOT_DEFINED",
"subAvailabilityImpact": "NONE",
"subConfidentialityImpact": "NONE",
"subIntegrityImpact": "NONE",
"userInteraction": "NONE",
"valueDensity": "NOT_DEFINED",
"vectorString": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N",
"version": "4.0",
"vulnAvailabilityImpact": "HIGH",
"vulnConfidentialityImpact": "NONE",
"vulnIntegrityImpact": "NONE",
"vulnerabilityResponseEffort": "NOT_DEFINED"
},
"format": "CVSS",
"scenarios": [
{
"lang": "en",
"value": "GENERAL"
}
]
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-770",
"description": "CWE-770 Allocation of Resources Without Limits or Throttling",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-09-29T10:15:15.619Z",
"orgId": "6b3ad84c-e1a6-4bf7-a703-f496b71e49db",
"shortName": "EEF"
},
"references": [
{
"name": "GitHub Advisory",
"tags": [
"related",
"vendor-advisory"
],
"url": "https://github.com/elixir-mint/mint/security/advisories/GHSA-9x8p-qrf4-jq7g"
},
{
"name": "EEF CNA record for CVE-2026-91043",
"tags": [
"related"
],
"url": "https://cna.erlef.org/cves/CVE-2026-91043.html"
},
{
"name": "OSV record EEF-CVE-2026-91043",
"tags": [
"related"
],
"url": "https://osv.dev/vulnerability/EEF-CVE-2026-91043"
},
{
"name": "Introducing commit 8e0e046 in elixir-mint/mint",
"tags": [
"related"
],
"url": "https://github.com/elixir-mint/mint/commit/8e0e04680476f90f9f68db4dfeabcbe66dabfc4d"
},
{
"name": "Fix commit c7895cb in elixir-mint/mint",
"tags": [
"patch"
],
"url": "https://github.com/elixir-mint/mint/commit/c7895cb022196c77ec35570c8e873a84393ff4b8"
},
{
"name": "Fix commit 65a0d61 in elixir-mint/mint",
"tags": [
"patch"
],
"url": "https://github.com/elixir-mint/mint/commit/65a0d61c9eab6b0dedac809de7212515bf506250"
}
],
"source": {
"discovery": "INTERNAL"
},
"title": "HPACK-indexed cookie fields in Mint HTTP/2 responses bypass max_header_list_size and exhaust client memory",
"workarounds": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003eLower \u003ccode\u003eclient_settings: [max_header_list_size: n]\u003c/code\u003e in \u003ccode\u003eMint.HTTP.connect/4\u003c/code\u003e. The compressed check still applies, and each byte of the block can expand to at most one 4 KB table entry, so a limit of 4,096 bounds a response to roughly 16 MB. Alternatively, restrict connections to untrusted servers to HTTP/1 with \u003ccode\u003eprotocols: [:http1]\u003c/code\u003e, which avoids the HTTP/2 receive path entirely. Do not set \u003ccode\u003emax_header_list_size: :infinity\u003c/code\u003e, which disables the compressed check as well.\u003c/p\u003e"
},
{
"base64": false,
"type": "text/markdown",
"value": "Lower `client_settings: [max_header_list_size: n]` in `Mint.HTTP.connect/4`. The compressed check still applies, and each byte of the block can expand to at most one 4 KB table entry, so a limit of 4,096 bounds a response to roughly 16 MB. Alternatively, restrict connections to untrusted servers to HTTP/1 with `protocols: [:http1]`, which avoids the HTTP/2 receive path entirely. Do not set `max_header_list_size: :infinity`, which disables the compressed check as well."
}
],
"value": "Lower client_settings: [max_header_list_size: n] in Mint.HTTP.connect/4. The compressed check still applies, and each byte of the block can expand to at most one 4 KB table entry, so a limit of 4,096 bounds a response to roughly 16 MB. Alternatively, restrict connections to untrusted servers to HTTP/1 with protocols: [:http1], which avoids the HTTP/2 receive path entirely. Do not set max_header_list_size: :infinity, which disables the compressed check as well."
}
],
"x_proofOfConcept": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003col\u003e\n\u003cli\u003eConnect a \u003ccode\u003eMint.HTTP2\u003c/code\u003e client with default \u003ccode\u003eclient_settings\u003c/code\u003e to a server that writes raw HTTP/2 frames, and open a request.\u003c/li\u003e\n\u003cli\u003eAnswer with a header block that stores one large \u003ccode\u003ecookie\u003c/code\u003e value in the HPACK dynamic table and then references it many times with indexed fields, keeping the compressed block under the 262,144-byte limit.\u003c/li\u003e\n\u003cli\u003eMint accepts the block and returns one \u003ccode\u003ecookie\u003c/code\u003e header thousands of times larger than the wire bytes; the reporter measured a 1,047,808,858-byte value from 262,296 wire bytes on mint 1.10.1.\u003c/li\u003e\n\u003cli\u003eAnswering several open requests in one delivery adds up: four responses held 4,240,710,592 bytes of cookie values at once.\u003c/li\u003e\n\u003cli\u003eA block of 60,000 references costs about 240 MB under the \u003ccode\u003ecookie\u003c/code\u003e field name and about 5 MB under a non-cookie name, which isolates \u003ccode\u003ejoin_cookie_headers/1\u003c/code\u003e as the amplifier.\u003c/li\u003e\n\u003c/ol\u003e"
},
{
"base64": false,
"type": "text/markdown",
"value": "1. Connect a `Mint.HTTP2` client with default `client_settings` to a server that writes raw HTTP/2 frames, and open a request.\n2. Answer with a header block that stores one large `cookie` value in the HPACK dynamic table and then references it many times with indexed fields, keeping the compressed block under the 262,144-byte limit.\n3. Mint accepts the block and returns one `cookie` header thousands of times larger than the wire bytes; the reporter measured a 1,047,808,858-byte value from 262,296 wire bytes on mint 1.10.1.\n4. Answering several open requests in one delivery adds up: four responses held 4,240,710,592 bytes of cookie values at once.\n5. A block of 60,000 references costs about 240 MB under the `cookie` field name and about 5 MB under a non-cookie name, which isolates `join_cookie_headers/1` as the amplifier."
}
],
"value": "* Connect a Mint.HTTP2 client with default client_settings to a server that writes raw HTTP/2 frames, and open a request.\n* Answer with a header block that stores one large cookie value in the HPACK dynamic table and then references it many times with indexed fields, keeping the compressed block under the 262,144-byte limit.\n* Mint accepts the block and returns one cookie header thousands of times larger than the wire bytes; the reporter measured a 1,047,808,858-byte value from 262,296 wire bytes on mint 1.10.1.\n* Answering several open requests in one delivery adds up: four responses held 4,240,710,592 bytes of cookie values at once.\n* A block of 60,000 references costs about 240 MB under the cookie field name and about 5 MB under a non-cookie name, which isolates join_cookie_headers/1 as the amplifier."
}
],
"x_technicalAnalysis": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003e\u003cstrong\u003e1. Compressed-size check only.\u003c/strong\u003e \u003ccode\u003eMint.HTTP2.assert_header_block_within_max_size/2\u003c/code\u003e compares the accumulated \u003ccode\u003eHEADERS\u003c/code\u003e plus \u003ccode\u003eCONTINUATION\u003c/code\u003e bytes with \u003ccode\u003eclient_settings.max_header_list_size\u003c/code\u003e, which bounds a \u003ccode\u003eCONTINUATION\u003c/code\u003e chain but not the decoded size. After \u003ccode\u003eHPAX.decode/2\u003c/code\u003e returns, \u003ccode\u003edecode_hbf_and_add_responses/5\u003c/code\u003e passes the header list to \u003ccode\u003ehandle_decoded_headers_for_stream/5\u003c/code\u003e without measuring it. The only implementation of the RFC 9113 section 6.5.2 formula, \u003ccode\u003eassert_headers_smaller_than_max_header_list_size/2\u003c/code\u003e, applies the server\u0027s setting to headers Mint sends.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e2. Indexed-field expansion.\u003c/strong\u003e An HPACK indexed field (RFC 7541 section 6.1) is one byte for small table indexes and refers to a dynamic table entry of up to 4 KB. HPAX returns one shared binary per reference, so the decoded list itself stays small.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e3. Cookie join.\u003c/strong\u003e \u003ccode\u003ejoin_cookie_headers/1\u003c/code\u003e runs \u003ccode\u003eEnum.map_join/3\u003c/code\u003e over every \u003ccode\u003ecookie\u003c/code\u003e value, copying each shared value into one contiguous binary. The dynamic table entry persists for the connection, so the same block can answer every open stream, and \u003ccode\u003eMint.HTTP.stream/2\u003c/code\u003e returns all responses parsed from one delivery together.\u003c/p\u003e"
},
{
"base64": false,
"type": "text/markdown",
"value": "**1. Compressed-size check only.** `Mint.HTTP2.assert_header_block_within_max_size/2` compares the accumulated `HEADERS` plus `CONTINUATION` bytes with `client_settings.max_header_list_size`, which bounds a `CONTINUATION` chain but not the decoded size. After `HPAX.decode/2` returns, `decode_hbf_and_add_responses/5` passes the header list to `handle_decoded_headers_for_stream/5` without measuring it. The only implementation of the RFC 9113 section 6.5.2 formula, `assert_headers_smaller_than_max_header_list_size/2`, applies the server\u0027s setting to headers Mint sends.\n\n**2. Indexed-field expansion.** An HPACK indexed field (RFC 7541 section 6.1) is one byte for small table indexes and refers to a dynamic table entry of up to 4 KB. HPAX returns one shared binary per reference, so the decoded list itself stays small.\n\n**3. Cookie join.** `join_cookie_headers/1` runs `Enum.map_join/3` over every `cookie` value, copying each shared value into one contiguous binary. The dynamic table entry persists for the connection, so the same block can answer every open stream, and `Mint.HTTP.stream/2` returns all responses parsed from one delivery together."
}
],
"value": "1. Compressed-size check only. Mint.HTTP2.assert_header_block_within_max_size/2 compares the accumulated HEADERS plus CONTINUATION bytes with client_settings.max_header_list_size, which bounds a CONTINUATION chain but not the decoded size. After HPAX.decode/2 returns, decode_hbf_and_add_responses/5 passes the header list to handle_decoded_headers_for_stream/5 without measuring it. The only implementation of the RFC 9113 section 6.5.2 formula, assert_headers_smaller_than_max_header_list_size/2, applies the server\u0027s setting to headers Mint sends.\n\n2. Indexed-field expansion. An HPACK indexed field (RFC 7541 section 6.1) is one byte for small table indexes and refers to a dynamic table entry of up to 4 KB. HPAX returns one shared binary per reference, so the decoded list itself stays small.\n\n3. Cookie join. join_cookie_headers/1 runs Enum.map_join/3 over every cookie value, copying each shared value into one contiguous binary. The dynamic table entry persists for the connection, so the same block can answer every open stream, and Mint.HTTP.stream/2 returns all responses parsed from one delivery together."
}
]
}
},
"cveMetadata": {
"assignerOrgId": "6b3ad84c-e1a6-4bf7-a703-f496b71e49db",
"assignerShortName": "EEF",
"cveId": "CVE-2026-91043",
"datePublished": "2026-09-28T11:15:09.158Z",
"dateReserved": "2026-09-15T23:45:02.178Z",
"dateUpdated": "2026-09-29T10:15:15.619Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
CVE-2026-92106 (GCVE-0-2026-92106)
Vulnerability from cvelistv5 – Published: 2026-09-25 09:33 – Updated: 2026-09-25 12:41
VLAI
EPSS
VEX
Title
lazy_html serializes SVG and MathML style and script text unescaped, allowing mutation XSS
Summary
Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting') vulnerability in dashbitco lazy_html allows mutation XSS via a parse and serialize round-trip of attacker-supplied HTML.
LazyHTML.to_html/2 and LazyHTML.Tree.to_html/2 decide whether to escape an element's text from its tag name alone. A style or script element inside SVG or MathML foreign content is parsed with character references decoded, but is serialized as an HTML raw-text element, so its text is emitted unescaped. Encoded markup such as </style><img src=x onerror=...> inside <svg><style> therefore closes the element on re-parse and becomes live markup. Applications that parse untrusted HTML with lazy_html, filter the document or tree, and serialize it for display are affected, since the payload is a plain text node that no element or attribute filter sees.
This issue affects lazy_html: from 0.1.0 before 0.1.13.
Severity
SSVC
Exploitation: none
Automatable: no
Technical Impact: partial
CISA Coordinator · CISA-ADP (v2.0.3)
Decision recorded 2026-09-25 12:35 UTC
CWE
- CWE-79 - Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')
Assigner
References
5 references
| URL | Tags |
|---|---|
| https://github.com/dashbitco/lazy_html/security/a… | relatedvendor-advisory |
| https://cna.erlef.org/cves/CVE-2026-92106.html | related |
| https://osv.dev/vulnerability/EEF-CVE-2026-92106 | related |
| https://github.com/dashbitco/lazy_html/commit/1de… | related |
| https://github.com/dashbitco/lazy_html/commit/f32… | patch |
Impacted products
2 products
{
"containers": {
"adp": [
{
"metrics": [
{
"other": {
"content": {
"id": "CVE-2026-92106",
"options": [
{
"Exploitation": "none"
},
{
"Automatable": "no"
},
{
"Technical Impact": "partial"
}
],
"role": "CISA Coordinator",
"timestamp": "2026-09-25T12:35:42.717583Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"providerMetadata": {
"dateUpdated": "2026-09-25T12:41:30.597Z",
"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"shortName": "CISA-ADP"
},
"title": "CISA ADP Vulnrichment"
}
],
"cna": {
"affected": [
{
"collectionURL": "https://repo.hex.pm",
"cpes": [
"cpe:2.3:a:dashbitco:lazy_html:*:*:*:*:*:*:*:*"
],
"defaultStatus": "unaffected",
"modules": [
"\u0027Elixir.LazyHTML.Tree\u0027",
"\u0027Elixir.LazyHTML\u0027",
"\u0027Elixir.LazyHTML.NIF\u0027"
],
"packageName": "lazy_html",
"packageURL": "pkg:hex/lazy_html",
"product": "lazy_html",
"programFiles": [
"lib/lazy_html/tree.ex",
"lib/lazy_html.ex",
"c_src/lazy_html.cpp"
],
"programRoutines": [
{
"name": "\u0027Elixir.LazyHTML.Tree\u0027:to_html/2"
},
{
"name": "\u0027Elixir.LazyHTML\u0027:to_html/2"
},
{
"name": "is_noescape_text_node"
}
],
"repo": "https://github.com/dashbitco/lazy_html",
"vendor": "dashbitco",
"versions": [
{
"lessThan": "0.1.13",
"status": "affected",
"version": "0.1.0",
"versionType": "semver"
}
]
},
{
"collectionURL": "https://github.com",
"cpes": [
"cpe:2.3:a:dashbitco:lazy_html:*:*:*:*:*:*:*:*"
],
"defaultStatus": "unaffected",
"modules": [
"\u0027Elixir.LazyHTML.Tree\u0027",
"\u0027Elixir.LazyHTML\u0027",
"\u0027Elixir.LazyHTML.NIF\u0027"
],
"packageName": "dashbitco/lazy_html",
"packageURL": "pkg:github/dashbitco/lazy_html",
"product": "lazy_html",
"programFiles": [
"lib/lazy_html/tree.ex",
"lib/lazy_html.ex",
"c_src/lazy_html.cpp"
],
"programRoutines": [
{
"name": "\u0027Elixir.LazyHTML.Tree\u0027:to_html/2"
},
{
"name": "\u0027Elixir.LazyHTML\u0027:to_html/2"
},
{
"name": "is_noescape_text_node"
}
],
"repo": "https://github.com/dashbitco/lazy_html",
"vendor": "dashbitco",
"versions": [
{
"lessThan": "f32c7fd6223225b68bc8691c78b6d4a77972f1d5",
"status": "affected",
"version": "1dee15746c024916b3110af8b168c2f3b3065fbd",
"versionType": "git"
}
]
}
],
"cpeApplicability": [
{
"nodes": [
{
"cpeMatch": [
{
"criteria": "cpe:2.3:a:dashbitco:lazy_html:*:*:*:*:*:*:*:*",
"versionEndExcluding": "0.1.13",
"versionStartIncluding": "0.1.0",
"vulnerable": true
}
],
"negate": false,
"operator": "OR"
}
],
"operator": "AND"
}
],
"credits": [
{
"lang": "en",
"type": "reporter",
"value": "Peter Ullrich"
},
{
"lang": "en",
"type": "remediation developer",
"value": "Jonatan K\u0142osko"
},
{
"lang": "en",
"type": "analyst",
"value": "Jonatan M\u00e4nnchen / EEF"
},
{
"lang": "en",
"type": "analyst",
"value": "Jos\u00e9 Valim"
}
],
"dateAssigned": "2026-09-24T13:39:50.000Z",
"descriptions": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003eImproper Neutralization of Input During Web Page Generation (\u0027Cross-site Scripting\u0027) vulnerability in dashbitco lazy_html allows mutation XSS via a parse and serialize round-trip of attacker-supplied HTML.\u003c/p\u003e\n\u003cp\u003e\u003ccode\u003eLazyHTML.to_html/2\u003c/code\u003e and \u003ccode\u003eLazyHTML.Tree.to_html/2\u003c/code\u003e decide whether to escape an element\u0027s text from its tag name alone. A \u003ccode\u003estyle\u003c/code\u003e or \u003ccode\u003escript\u003c/code\u003e element inside SVG or MathML foreign content is parsed with character references decoded, but is serialized as an HTML raw-text element, so its text is emitted unescaped. Encoded markup such as \u003ccode\u003e\u0026amp;lt;/style\u0026amp;gt;\u0026amp;lt;img src=x onerror=...\u0026amp;gt;\u003c/code\u003e inside \u003ccode\u003e\u0026lt;svg\u0026gt;\u0026lt;style\u0026gt;\u003c/code\u003e therefore closes the element on re-parse and becomes live markup. Applications that parse untrusted HTML with lazy_html, filter the document or tree, and serialize it for display are affected, since the payload is a plain text node that no element or attribute filter sees.\u003c/p\u003e\n\u003cp\u003eThis issue affects lazy_html: from 0.1.0 before 0.1.13.\u003c/p\u003e"
},
{
"base64": false,
"type": "text/markdown",
"value": "Improper Neutralization of Input During Web Page Generation (\u0027Cross-site Scripting\u0027) vulnerability in dashbitco lazy_html allows mutation XSS via a parse and serialize round-trip of attacker-supplied HTML.\n\n`LazyHTML.to_html/2` and `LazyHTML.Tree.to_html/2` decide whether to escape an element\u0027s text from its tag name alone. A `style` or `script` element inside SVG or MathML foreign content is parsed with character references decoded, but is serialized as an HTML raw-text element, so its text is emitted unescaped. Encoded markup such as `\u0026lt;/style\u0026gt;\u0026lt;img src=x onerror=...\u0026gt;` inside `\u003csvg\u003e\u003cstyle\u003e` therefore closes the element on re-parse and becomes live markup. Applications that parse untrusted HTML with lazy_html, filter the document or tree, and serialize it for display are affected, since the payload is a plain text node that no element or attribute filter sees.\n\nThis issue affects lazy_html: from 0.1.0 before 0.1.13."
}
],
"value": "Improper Neutralization of Input During Web Page Generation (\u0027Cross-site Scripting\u0027) vulnerability in dashbitco lazy_html allows mutation XSS via a parse and serialize round-trip of attacker-supplied HTML.\n\nLazyHTML.to_html/2 and LazyHTML.Tree.to_html/2 decide whether to escape an element\u0027s text from its tag name alone. A style or script element inside SVG or MathML foreign content is parsed with character references decoded, but is serialized as an HTML raw-text element, so its text is emitted unescaped. Encoded markup such as \u0026lt;/style\u0026gt;\u0026lt;img src=x onerror=...\u0026gt; inside \u003csvg\u003e\u003cstyle\u003e therefore closes the element on re-parse and becomes live markup. Applications that parse untrusted HTML with lazy_html, filter the document or tree, and serialize it for display are affected, since the payload is a plain text node that no element or attribute filter sees.\n\nThis issue affects lazy_html: from 0.1.0 before 0.1.13."
}
],
"impacts": [
{
"capecId": "CAPEC-63",
"descriptions": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003eAn attacker who can submit HTML to an application that sanitizes it with lazy_html can run script in the browsers of users who view the sanitized output.\u003c/p\u003e"
},
{
"base64": false,
"type": "text/markdown",
"value": "An attacker who can submit HTML to an application that sanitizes it with lazy_html can run script in the browsers of users who view the sanitized output."
}
],
"value": "An attacker who can submit HTML to an application that sanitizes it with lazy_html can run script in the browsers of users who view the sanitized output."
}
]
}
],
"metrics": [
{
"cvssV4_0": {
"Automatable": "NOT_DEFINED",
"Recovery": "NOT_DEFINED",
"Safety": "NOT_DEFINED",
"attackComplexity": "LOW",
"attackRequirements": "PRESENT",
"attackVector": "NETWORK",
"baseScore": 2.3,
"baseSeverity": "LOW",
"privilegesRequired": "NONE",
"providerUrgency": "NOT_DEFINED",
"subAvailabilityImpact": "NONE",
"subConfidentialityImpact": "LOW",
"subIntegrityImpact": "LOW",
"userInteraction": "PASSIVE",
"valueDensity": "NOT_DEFINED",
"vectorString": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:P/VC:N/VI:N/VA:N/SC:L/SI:L/SA:N",
"version": "4.0",
"vulnAvailabilityImpact": "NONE",
"vulnConfidentialityImpact": "NONE",
"vulnIntegrityImpact": "NONE",
"vulnerabilityResponseEffort": "NOT_DEFINED"
},
"format": "CVSS",
"scenarios": [
{
"lang": "en",
"value": "GENERAL"
}
]
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-79",
"description": "CWE-79 Improper Neutralization of Input During Web Page Generation (\u0027Cross-site Scripting\u0027)",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-09-25T09:33:13.051Z",
"orgId": "6b3ad84c-e1a6-4bf7-a703-f496b71e49db",
"shortName": "EEF"
},
"references": [
{
"name": "GitHub Advisory",
"tags": [
"related",
"vendor-advisory"
],
"url": "https://github.com/dashbitco/lazy_html/security/advisories/GHSA-8rqp-v692-v82q"
},
{
"name": "EEF CNA record for CVE-2026-92106",
"tags": [
"related"
],
"url": "https://cna.erlef.org/cves/CVE-2026-92106.html"
},
{
"name": "OSV record EEF-CVE-2026-92106",
"tags": [
"related"
],
"url": "https://osv.dev/vulnerability/EEF-CVE-2026-92106"
},
{
"name": "Introducing commit 1dee157 in dashbitco/lazy_html",
"tags": [
"related"
],
"url": "https://github.com/dashbitco/lazy_html/commit/1dee15746c024916b3110af8b168c2f3b3065fbd"
},
{
"name": "Fix commit f32c7fd in dashbitco/lazy_html",
"tags": [
"patch"
],
"url": "https://github.com/dashbitco/lazy_html/commit/f32c7fd6223225b68bc8691c78b6d4a77972f1d5"
}
],
"source": {
"discovery": "EXTERNAL"
},
"title": "lazy_html serializes SVG and MathML style and script text unescaped, allowing mutation XSS"
}
},
"cveMetadata": {
"assignerOrgId": "6b3ad84c-e1a6-4bf7-a703-f496b71e49db",
"assignerShortName": "EEF",
"cveId": "CVE-2026-92106",
"datePublished": "2026-09-25T09:33:13.051Z",
"dateReserved": "2026-09-21T12:15:01.326Z",
"dateUpdated": "2026-09-25T12:41:30.597Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
CVE-2026-93477 (GCVE-0-2026-93477)
Vulnerability from cvelistv5 – Published: 2026-09-25 07:08 – Updated: 2026-09-25 13:26
VLAI
EPSS
VEX
Title
Private action arguments can be set by user input on the bulk destroy and bulk update paths in Ash
Summary
Improperly Controlled Modification of Dynamically-Determined Object Attributes vulnerability in ash-project ash allows a user to set the value of a private action argument on the bulk destroy and bulk update paths.
Action arguments declared with public?: false are meant to be set only by trusted server-side code (for example via Ash.Changeset.set_private_argument/3) and must not be settable from end-user input. CVE-2026-55736 fixed the non-bulk changeset path to strip private arguments from user-supplied parameter maps, but the bulk destroy and bulk update paths were not covered.
Ash.Actions.Destroy.Bulk.base_changeset/5 and Ash.Actions.Update.Bulk.base_changeset/5 match every key in the caller-supplied parameter map against all of the action's arguments with no public? check, then apply the matches to the base changeset. A caller who can submit parameters to a bulk destroy or bulk update action (for example through AshJsonApi, AshGraphql, or a controller that forwards request parameters to Ash.bulk_destroy/4 or Ash.bulk_update/4) can therefore set any private argument of that action, including one referenced by an arg(...) template in the action's changes or validations. Depending on how the application uses the argument (for example an acting_user_id driving authorization or record ownership, or audit metadata), this can lead to an integrity violation or privilege escalation.
The fix requires public? in the argument matching on both bulk paths; private arguments remain settable server-side via the :private_arguments option.
This issue affects ash: from 2.17.15 before 3.33.11.
Severity
SSVC
Exploitation: none
Automatable: no
Technical Impact: partial
CISA Coordinator · CISA-ADP (v2.0.3)
Decision recorded 2026-09-25 13:26 UTC
CWE
- CWE-915 - Improperly Controlled Modification of Dynamically-Determined Object Attributes
Assigner
References
5 references
Impacted products
2 products
| Vendor | Product | Version | |
|---|---|---|---|
| ash-project | ash |
Affected:
2.17.15 , < 3.33.11
(semver)
cpe:2.3:a:ash-project:ash:*:*:*:*:*:*:*:* |
|
| ash-project | ash |
Affected:
8c17434803b2e91de522bdfbd0ca918e5d5898df , < 6b7ac53a0a2532291eb940d7beaf0fbb2da6fc4f
(git)
cpe:2.3:a:ash-project:ash:*:*:*:*:*:*:*:* |
{
"containers": {
"adp": [
{
"metrics": [
{
"other": {
"content": {
"id": "CVE-2026-93477",
"options": [
{
"Exploitation": "none"
},
{
"Automatable": "no"
},
{
"Technical Impact": "partial"
}
],
"role": "CISA Coordinator",
"timestamp": "2026-09-25T13:26:14.200048Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"providerMetadata": {
"dateUpdated": "2026-09-25T13:26:42.369Z",
"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"shortName": "CISA-ADP"
},
"references": [
{
"tags": [
"exploit"
],
"url": "https://github.com/ash-project/ash/security/advisories/GHSA-c2p4-p7q6-hr2j"
}
],
"title": "CISA ADP Vulnrichment"
}
],
"cna": {
"affected": [
{
"collectionURL": "https://repo.hex.pm",
"cpes": [
"cpe:2.3:a:ash-project:ash:*:*:*:*:*:*:*:*"
],
"defaultStatus": "unaffected",
"modules": [
"\u0027Elixir.Ash.Actions.Destroy.Bulk\u0027",
"\u0027Elixir.Ash.Actions.Update.Bulk\u0027"
],
"packageName": "ash",
"packageURL": "pkg:hex/ash",
"product": "ash",
"programFiles": [
"lib/ash/actions/destroy/bulk.ex",
"lib/ash/actions/update/bulk.ex"
],
"programRoutines": [
{
"name": "\u0027Elixir.Ash.Actions.Destroy.Bulk\u0027:base_changeset/5"
},
{
"name": "\u0027Elixir.Ash.Actions.Update.Bulk\u0027:base_changeset/5"
}
],
"repo": "https://github.com/ash-project/ash",
"vendor": "ash-project",
"versions": [
{
"lessThan": "3.33.11",
"status": "affected",
"version": "2.17.15",
"versionType": "semver"
}
]
},
{
"collectionURL": "https://github.com",
"cpes": [
"cpe:2.3:a:ash-project:ash:*:*:*:*:*:*:*:*"
],
"defaultStatus": "unaffected",
"modules": [
"\u0027Elixir.Ash.Actions.Destroy.Bulk\u0027",
"\u0027Elixir.Ash.Actions.Update.Bulk\u0027"
],
"packageName": "ash-project/ash",
"packageURL": "pkg:github/ash-project/ash",
"product": "ash",
"programFiles": [
"lib/ash/actions/destroy/bulk.ex",
"lib/ash/actions/update/bulk.ex"
],
"programRoutines": [
{
"name": "\u0027Elixir.Ash.Actions.Destroy.Bulk\u0027:base_changeset/5"
},
{
"name": "\u0027Elixir.Ash.Actions.Update.Bulk\u0027:base_changeset/5"
}
],
"repo": "https://github.com/ash-project/ash",
"vendor": "ash-project",
"versions": [
{
"lessThan": "6b7ac53a0a2532291eb940d7beaf0fbb2da6fc4f",
"status": "affected",
"version": "8c17434803b2e91de522bdfbd0ca918e5d5898df",
"versionType": "git"
}
]
}
],
"configurations": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003eAn action must declare a private argument (\u003ccode\u003epublic?: false\u003c/code\u003e) that is referenced by an \u003ccode\u003earg(...)\u003c/code\u003e template in one of its changes or validations, be invocable as a bulk destroy or bulk update, and the application must pass untrusted user-supplied parameters into \u003ccode\u003eAsh.bulk_destroy/4\u003c/code\u003e or \u003ccode\u003eAsh.bulk_update/4\u003c/code\u003e (directly or through AshJsonApi/AshGraphql).\u003c/p\u003e"
},
{
"base64": false,
"type": "text/markdown",
"value": "An action must declare a private argument (`public?: false`) that is referenced by an `arg(...)` template in one of its changes or validations, be invocable as a bulk destroy or bulk update, and the application must pass untrusted user-supplied parameters into `Ash.bulk_destroy/4` or `Ash.bulk_update/4` (directly or through AshJsonApi/AshGraphql)."
}
],
"value": "An action must declare a private argument (public?: false) that is referenced by an arg(...) template in one of its changes or validations, be invocable as a bulk destroy or bulk update, and the application must pass untrusted user-supplied parameters into Ash.bulk_destroy/4 or Ash.bulk_update/4 (directly or through AshJsonApi/AshGraphql)."
}
],
"cpeApplicability": [
{
"nodes": [
{
"cpeMatch": [
{
"criteria": "cpe:2.3:a:ash-project:ash:*:*:*:*:*:*:*:*",
"versionEndExcluding": "3.33.11",
"versionStartIncluding": "2.17.15",
"vulnerable": true
}
],
"negate": false,
"operator": "OR"
}
],
"operator": "AND"
}
],
"credits": [
{
"lang": "en",
"type": "finder",
"value": "zx"
},
{
"lang": "en",
"type": "reporter",
"value": "zx"
},
{
"lang": "en",
"type": "remediation developer",
"value": "Zach Daniel / Ash Project"
},
{
"lang": "en",
"type": "coordinator",
"value": "Jonatan M\u00e4nnchen / EEF"
}
],
"dateAssigned": "2026-09-25T06:50:10.000Z",
"descriptions": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003eImproperly Controlled Modification of Dynamically-Determined Object Attributes vulnerability in ash-project ash allows a user to set the value of a private action argument on the bulk destroy and bulk update paths.\u003c/p\u003e\n\u003cp\u003eAction arguments declared with \u003ccode\u003epublic?: false\u003c/code\u003e are meant to be set only by trusted server-side code (for example via \u003ccode\u003eAsh.Changeset.set_private_argument/3\u003c/code\u003e) and must not be settable from end-user input. CVE-2026-55736 fixed the non-bulk changeset path to strip private arguments from user-supplied parameter maps, but the bulk destroy and bulk update paths were not covered.\u003c/p\u003e\n\u003cp\u003e\u003ccode\u003eAsh.Actions.Destroy.Bulk.base_changeset/5\u003c/code\u003e and \u003ccode\u003eAsh.Actions.Update.Bulk.base_changeset/5\u003c/code\u003e match every key in the caller-supplied parameter map against all of the action\u0027s arguments with no \u003ccode\u003epublic?\u003c/code\u003e check, then apply the matches to the base changeset. A caller who can submit parameters to a bulk destroy or bulk update action (for example through AshJsonApi, AshGraphql, or a controller that forwards request parameters to \u003ccode\u003eAsh.bulk_destroy/4\u003c/code\u003e or \u003ccode\u003eAsh.bulk_update/4\u003c/code\u003e) can therefore set any private argument of that action, including one referenced by an \u003ccode\u003earg(...)\u003c/code\u003e template in the action\u0027s changes or validations. Depending on how the application uses the argument (for example an \u003ccode\u003eacting_user_id\u003c/code\u003e driving authorization or record ownership, or audit metadata), this can lead to an integrity violation or privilege escalation.\u003c/p\u003e\n\u003cp\u003eThe fix requires \u003ccode\u003epublic?\u003c/code\u003e in the argument matching on both bulk paths; private arguments remain settable server-side via the \u003ccode\u003e:private_arguments\u003c/code\u003e option.\u003c/p\u003e\n\u003cp\u003eThis issue affects ash: from 2.17.15 before 3.33.11.\u003c/p\u003e"
},
{
"base64": false,
"type": "text/markdown",
"value": "Improperly Controlled Modification of Dynamically-Determined Object Attributes vulnerability in ash-project ash allows a user to set the value of a private action argument on the bulk destroy and bulk update paths.\n\nAction arguments declared with `public?: false` are meant to be set only by trusted server-side code (for example via `Ash.Changeset.set_private_argument/3`) and must not be settable from end-user input. CVE-2026-55736 fixed the non-bulk changeset path to strip private arguments from user-supplied parameter maps, but the bulk destroy and bulk update paths were not covered.\n\n`Ash.Actions.Destroy.Bulk.base_changeset/5` and `Ash.Actions.Update.Bulk.base_changeset/5` match every key in the caller-supplied parameter map against all of the action\u0027s arguments with no `public?` check, then apply the matches to the base changeset. A caller who can submit parameters to a bulk destroy or bulk update action (for example through AshJsonApi, AshGraphql, or a controller that forwards request parameters to `Ash.bulk_destroy/4` or `Ash.bulk_update/4`) can therefore set any private argument of that action, including one referenced by an `arg(...)` template in the action\u0027s changes or validations. Depending on how the application uses the argument (for example an `acting_user_id` driving authorization or record ownership, or audit metadata), this can lead to an integrity violation or privilege escalation.\n\nThe fix requires `public?` in the argument matching on both bulk paths; private arguments remain settable server-side via the `:private_arguments` option.\n\nThis issue affects ash: from 2.17.15 before 3.33.11."
}
],
"value": "Improperly Controlled Modification of Dynamically-Determined Object Attributes vulnerability in ash-project ash allows a user to set the value of a private action argument on the bulk destroy and bulk update paths.\n\nAction arguments declared with public?: false are meant to be set only by trusted server-side code (for example via Ash.Changeset.set_private_argument/3) and must not be settable from end-user input. CVE-2026-55736 fixed the non-bulk changeset path to strip private arguments from user-supplied parameter maps, but the bulk destroy and bulk update paths were not covered.\n\nAsh.Actions.Destroy.Bulk.base_changeset/5 and Ash.Actions.Update.Bulk.base_changeset/5 match every key in the caller-supplied parameter map against all of the action\u0027s arguments with no public? check, then apply the matches to the base changeset. A caller who can submit parameters to a bulk destroy or bulk update action (for example through AshJsonApi, AshGraphql, or a controller that forwards request parameters to Ash.bulk_destroy/4 or Ash.bulk_update/4) can therefore set any private argument of that action, including one referenced by an arg(...) template in the action\u0027s changes or validations. Depending on how the application uses the argument (for example an acting_user_id driving authorization or record ownership, or audit metadata), this can lead to an integrity violation or privilege escalation.\n\nThe fix requires public? in the argument matching on both bulk paths; private arguments remain settable server-side via the :private_arguments option.\n\nThis issue affects ash: from 2.17.15 before 3.33.11."
}
],
"impacts": [
{
"capecId": "CAPEC-77",
"descriptions": [
{
"lang": "en",
"value": "CAPEC-77 Manipulating User-Controlled Variables"
}
]
}
],
"metrics": [
{
"cvssV4_0": {
"Automatable": "NOT_DEFINED",
"Recovery": "NOT_DEFINED",
"Safety": "NOT_DEFINED",
"attackComplexity": "LOW",
"attackRequirements": "PRESENT",
"attackVector": "LOCAL",
"baseScore": 5.9,
"baseSeverity": "MEDIUM",
"privilegesRequired": "NONE",
"providerUrgency": "NOT_DEFINED",
"subAvailabilityImpact": "NONE",
"subConfidentialityImpact": "NONE",
"subIntegrityImpact": "NONE",
"userInteraction": "NONE",
"valueDensity": "NOT_DEFINED",
"vectorString": "CVSS:4.0/AV:L/AC:L/AT:P/PR:N/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N",
"version": "4.0",
"vulnAvailabilityImpact": "NONE",
"vulnConfidentialityImpact": "NONE",
"vulnIntegrityImpact": "HIGH",
"vulnerabilityResponseEffort": "NOT_DEFINED"
},
"format": "CVSS",
"scenarios": [
{
"lang": "en",
"value": "GENERAL"
}
]
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-915",
"description": "CWE-915 Improperly Controlled Modification of Dynamically-Determined Object Attributes",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-09-25T07:08:55.191Z",
"orgId": "6b3ad84c-e1a6-4bf7-a703-f496b71e49db",
"shortName": "EEF"
},
"references": [
{
"name": "GHSA-c2p4-p7q6-hr2j",
"tags": [
"vendor-advisory"
],
"url": "https://github.com/ash-project/ash/security/advisories/GHSA-c2p4-p7q6-hr2j"
},
{
"name": "EEF CNA record for CVE-2026-93477",
"tags": [
"related"
],
"url": "https://cna.erlef.org/cves/CVE-2026-93477.html"
},
{
"name": "OSV record EEF-CVE-2026-93477",
"tags": [
"related"
],
"url": "https://osv.dev/vulnerability/EEF-CVE-2026-93477"
},
{
"name": "Introducing commit 8c17434 in ash-project/ash",
"tags": [
"related"
],
"url": "https://github.com/ash-project/ash/commit/8c17434803b2e91de522bdfbd0ca918e5d5898df"
},
{
"name": "Fix commit 6b7ac53 in ash-project/ash",
"tags": [
"patch"
],
"url": "https://github.com/ash-project/ash/commit/6b7ac53a0a2532291eb940d7beaf0fbb2da6fc4f"
}
],
"source": {
"discovery": "EXTERNAL"
},
"title": "Private action arguments can be set by user input on the bulk destroy and bulk update paths in Ash"
}
},
"cveMetadata": {
"assignerOrgId": "6b3ad84c-e1a6-4bf7-a703-f496b71e49db",
"assignerShortName": "EEF",
"cveId": "CVE-2026-93477",
"datePublished": "2026-09-25T07:08:55.191Z",
"dateReserved": "2026-09-19T16:00:02.004Z",
"dateUpdated": "2026-09-25T13:26:42.369Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
CVE-2026-91187 (GCVE-0-2026-91187)
Vulnerability from cvelistv5 – Published: 2026-09-24 13:20 – Updated: 2026-09-24 14:47
VLAI
EPSS
VEX
Title
Improper Verification of Cryptographic Signature in dashbit nimble_zta Cloudflare strategy
Summary
Improper Verification of Cryptographic Signature vulnerability in dashbit nimble_zta allows an unauthenticated remote attacker to authenticate as an arbitrary Cloudflare service token. Applications using the Cloudflare Zero Trust authentication strategy are affected.
verify_token/2 in lib/nimble_zta/cloudflare.ex matches the result of JOSE.JWT.verify/2 against {_, token, _s}, which discards the boolean verification result and returns the decoded token after a failed signature check. The attacker sends a forged JWT in the cf-access-jwt-assertion header, carrying the expected iss claim and the seven service token claims. verify_iss/2 reads the iss claim from the forged token, so it rejects nothing, and the service token path then returns those claims as the authenticated identity.
This issue affects nimble_zta: from 0.1.2 before 0.1.3.
Severity
SSVC
Exploitation: none
Automatable: yes
Technical Impact: partial
CISA Coordinator · CISA-ADP (v2.0.3)
Decision recorded 2026-09-24 14:43 UTC
CWE
- CWE-347 - Improper Verification of Cryptographic Signature
Assigner
References
5 references
| URL | Tags |
|---|---|
| https://github.com/dashbitco/nimble_zta/security/… | relatedvendor-advisory |
| https://cna.erlef.org/cves/CVE-2026-91187.html | related |
| https://osv.dev/vulnerability/EEF-CVE-2026-91187 | related |
| https://github.com/dashbitco/nimble_zta/commit/bc… | related |
| https://github.com/dashbitco/nimble_zta/commit/64… | patch |
Impacted products
2 products
| Vendor | Product | Version | |
|---|---|---|---|
| dashbit | nimble_zta |
Affected:
0.1.2 , < 0.1.3
(semver)
cpe:2.3:a:dashbit:nimble_zta:*:*:*:*:*:*:*:* |
|
| dashbit | nimble_zta |
Affected:
bc004b70985ae5763901baab3a4e204047899768 , < 6458fd18a5ba41166d4973214c519e98fe05b72d
(git)
cpe:2.3:a:dashbit:nimble_zta:*:*:*:*:*:*:*:* |
{
"containers": {
"adp": [
{
"metrics": [
{
"other": {
"content": {
"id": "CVE-2026-91187",
"options": [
{
"Exploitation": "none"
},
{
"Automatable": "yes"
},
{
"Technical Impact": "partial"
}
],
"role": "CISA Coordinator",
"timestamp": "2026-09-24T14:43:06.738544Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"providerMetadata": {
"dateUpdated": "2026-09-24T14:47:30.520Z",
"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"shortName": "CISA-ADP"
},
"title": "CISA ADP Vulnrichment"
}
],
"cna": {
"affected": [
{
"collectionURL": "https://repo.hex.pm",
"cpes": [
"cpe:2.3:a:dashbit:nimble_zta:*:*:*:*:*:*:*:*"
],
"defaultStatus": "unaffected",
"modules": [
"\u0027Elixir.NimbleZTA.Cloudflare\u0027"
],
"packageName": "nimble_zta",
"packageURL": "pkg:hex/nimble_zta",
"product": "nimble_zta",
"programFiles": [
"lib/nimble_zta/cloudflare.ex"
],
"programRoutines": [
{
"name": "\u0027Elixir.NimbleZTA.Cloudflare\u0027:authenticate/3"
},
{
"name": "\u0027Elixir.NimbleZTA.Cloudflare\u0027:verify_token/2"
}
],
"repo": "https://github.com/dashbitco/nimble_zta",
"vendor": "dashbit",
"versions": [
{
"lessThan": "0.1.3",
"status": "affected",
"version": "0.1.2",
"versionType": "semver"
}
]
},
{
"collectionURL": "https://github.com",
"cpes": [
"cpe:2.3:a:dashbit:nimble_zta:*:*:*:*:*:*:*:*"
],
"defaultStatus": "unaffected",
"modules": [
"\u0027Elixir.NimbleZTA.Cloudflare\u0027"
],
"packageName": "dashbitco/nimble_zta",
"packageURL": "pkg:github/dashbitco/nimble_zta",
"product": "nimble_zta",
"programFiles": [
"lib/nimble_zta/cloudflare.ex"
],
"programRoutines": [
{
"name": "\u0027Elixir.NimbleZTA.Cloudflare\u0027:authenticate/3"
},
{
"name": "\u0027Elixir.NimbleZTA.Cloudflare\u0027:verify_token/2"
}
],
"repo": "https://github.com/dashbitco/nimble_zta",
"vendor": "dashbit",
"versions": [
{
"lessThan": "6458fd18a5ba41166d4973214c519e98fe05b72d",
"status": "affected",
"version": "bc004b70985ae5763901baab3a4e204047899768",
"versionType": "git"
}
]
}
],
"configurations": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003eThe application must add \u003ccode\u003eNimbleZTA.Cloudflare\u003c/code\u003e to its supervision tree and authenticate requests through it.\u003c/p\u003e"
},
{
"base64": false,
"type": "text/markdown",
"value": "The application must add `NimbleZTA.Cloudflare` to its supervision tree and authenticate requests through it."
}
],
"value": "The application must add NimbleZTA.Cloudflare to its supervision tree and authenticate requests through it."
}
],
"cpeApplicability": [
{
"nodes": [
{
"cpeMatch": [
{
"criteria": "cpe:2.3:a:dashbit:nimble_zta:*:*:*:*:*:*:*:*",
"versionEndExcluding": "0.1.3",
"versionStartIncluding": "0.1.2",
"vulnerable": true
}
],
"negate": false,
"operator": "OR"
}
],
"operator": "AND"
}
],
"credits": [
{
"lang": "en",
"type": "finder",
"value": "Kazlu"
},
{
"lang": "en",
"type": "remediation developer",
"value": "Jos\u00e9 Valim / Dashbit"
},
{
"lang": "en",
"type": "coordinator",
"value": "Jonatan M\u00e4nnchen / EEF"
}
],
"dateAssigned": "2026-09-24T09:09:36.000Z",
"descriptions": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003eImproper Verification of Cryptographic Signature vulnerability in dashbit nimble_zta allows an unauthenticated remote attacker to authenticate as an arbitrary Cloudflare service token. Applications using the Cloudflare Zero Trust authentication strategy are affected.\u003c/p\u003e\n\u003cp\u003e\u003ccode\u003everify_token/2\u003c/code\u003e in \u003ccode\u003elib/nimble_zta/cloudflare.ex\u003c/code\u003e matches the result of \u003ccode\u003eJOSE.JWT.verify/2\u003c/code\u003e against \u003ccode\u003e{_, token, _s}\u003c/code\u003e, which discards the boolean verification result and returns the decoded token after a failed signature check. The attacker sends a forged JWT in the \u003ccode\u003ecf-access-jwt-assertion\u003c/code\u003e header, carrying the expected \u003ccode\u003eiss\u003c/code\u003e claim and the seven service token claims. \u003ccode\u003everify_iss/2\u003c/code\u003e reads the \u003ccode\u003eiss\u003c/code\u003e claim from the forged token, so it rejects nothing, and the service token path then returns those claims as the authenticated identity.\u003c/p\u003e\n\u003cp\u003eThis issue affects nimble_zta: from 0.1.2 before 0.1.3.\u003c/p\u003e"
},
{
"base64": false,
"type": "text/markdown",
"value": "Improper Verification of Cryptographic Signature vulnerability in dashbit nimble_zta allows an unauthenticated remote attacker to authenticate as an arbitrary Cloudflare service token. Applications using the Cloudflare Zero Trust authentication strategy are affected.\n\n`verify_token/2` in `lib/nimble_zta/cloudflare.ex` matches the result of `JOSE.JWT.verify/2` against `{_, token, _s}`, which discards the boolean verification result and returns the decoded token after a failed signature check. The attacker sends a forged JWT in the `cf-access-jwt-assertion` header, carrying the expected `iss` claim and the seven service token claims. `verify_iss/2` reads the `iss` claim from the forged token, so it rejects nothing, and the service token path then returns those claims as the authenticated identity.\n\nThis issue affects nimble_zta: from 0.1.2 before 0.1.3."
}
],
"value": "Improper Verification of Cryptographic Signature vulnerability in dashbit nimble_zta allows an unauthenticated remote attacker to authenticate as an arbitrary Cloudflare service token. Applications using the Cloudflare Zero Trust authentication strategy are affected.\n\nverify_token/2 in lib/nimble_zta/cloudflare.ex matches the result of JOSE.JWT.verify/2 against {_, token, _s}, which discards the boolean verification result and returns the decoded token after a failed signature check. The attacker sends a forged JWT in the cf-access-jwt-assertion header, carrying the expected iss claim and the seven service token claims. verify_iss/2 reads the iss claim from the forged token, so it rejects nothing, and the service token path then returns those claims as the authenticated identity.\n\nThis issue affects nimble_zta: from 0.1.2 before 0.1.3."
}
],
"impacts": [
{
"capecId": "CAPEC-475",
"descriptions": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003eThe attacker authenticates as an arbitrary Cloudflare service token without holding the Cloudflare signing key. The application receives the \u003ccode\u003eclient_id\u003c/code\u003e and the claims of the forged token as the authenticated identity, so the attacker gets the access that the application grants to that service token.\u003c/p\u003e"
},
{
"base64": false,
"type": "text/markdown",
"value": "The attacker authenticates as an arbitrary Cloudflare service token without holding the Cloudflare signing key. The application receives the `client_id` and the claims of the forged token as the authenticated identity, so the attacker gets the access that the application grants to that service token."
}
],
"value": "The attacker authenticates as an arbitrary Cloudflare service token without holding the Cloudflare signing key. The application receives the client_id and the claims of the forged token as the authenticated identity, so the attacker gets the access that the application grants to that service token."
}
]
}
],
"metrics": [
{
"cvssV4_0": {
"Automatable": "NOT_DEFINED",
"Recovery": "NOT_DEFINED",
"Safety": "NOT_DEFINED",
"attackComplexity": "LOW",
"attackRequirements": "NONE",
"attackVector": "NETWORK",
"baseScore": 9.3,
"baseSeverity": "CRITICAL",
"privilegesRequired": "NONE",
"providerUrgency": "NOT_DEFINED",
"subAvailabilityImpact": "NONE",
"subConfidentialityImpact": "HIGH",
"subIntegrityImpact": "HIGH",
"userInteraction": "NONE",
"valueDensity": "NOT_DEFINED",
"vectorString": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:N/VA:N/SC:H/SI:H/SA:N",
"version": "4.0",
"vulnAvailabilityImpact": "NONE",
"vulnConfidentialityImpact": "HIGH",
"vulnIntegrityImpact": "NONE",
"vulnerabilityResponseEffort": "NOT_DEFINED"
},
"format": "CVSS",
"scenarios": [
{
"lang": "en",
"value": "GENERAL"
}
]
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-347",
"description": "CWE-347 Improper Verification of Cryptographic Signature",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-09-24T13:20:52.974Z",
"orgId": "6b3ad84c-e1a6-4bf7-a703-f496b71e49db",
"shortName": "EEF"
},
"references": [
{
"name": "GitHub Advisory",
"tags": [
"related",
"vendor-advisory"
],
"url": "https://github.com/dashbitco/nimble_zta/security/advisories/GHSA-rj24-g8cc-g7g2"
},
{
"name": "EEF CNA record for CVE-2026-91187",
"tags": [
"related"
],
"url": "https://cna.erlef.org/cves/CVE-2026-91187.html"
},
{
"name": "OSV record EEF-CVE-2026-91187",
"tags": [
"related"
],
"url": "https://osv.dev/vulnerability/EEF-CVE-2026-91187"
},
{
"name": "Introducing commit bc004b7 in dashbitco/nimble_zta",
"tags": [
"related"
],
"url": "https://github.com/dashbitco/nimble_zta/commit/bc004b70985ae5763901baab3a4e204047899768"
},
{
"name": "Fix commit 6458fd1 in dashbitco/nimble_zta",
"tags": [
"patch"
],
"url": "https://github.com/dashbitco/nimble_zta/commit/6458fd18a5ba41166d4973214c519e98fe05b72d"
}
],
"source": {
"discovery": "EXTERNAL"
},
"title": "Improper Verification of Cryptographic Signature in dashbit nimble_zta Cloudflare strategy",
"workarounds": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003eDisable the Cloudflare authentication strategy.\u003c/p\u003e\n\u003cp\u003eTo keep the user identity strategy available, reject the service token requests yourself. Examine each request before you call \u003ccode\u003eNimbleZTA.Cloudflare.authenticate/3\u003c/code\u003e, and reject it if its JWT carries the \u003ccode\u003ecommon_name\u003c/code\u003e claim and the \u003ccode\u003etype\u003c/code\u003e claim.\u003c/p\u003e"
},
{
"base64": false,
"type": "text/markdown",
"value": "Disable the Cloudflare authentication strategy.\n\nTo keep the user identity strategy available, reject the service token requests yourself. Examine each request before you call `NimbleZTA.Cloudflare.authenticate/3`, and reject it if its JWT carries the `common_name` claim and the `type` claim."
}
],
"value": "Disable the Cloudflare authentication strategy.\n\nTo keep the user identity strategy available, reject the service token requests yourself. Examine each request before you call NimbleZTA.Cloudflare.authenticate/3, and reject it if its JWT carries the common_name claim and the type claim."
}
],
"x_proofOfConcept": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003col\u003e\n\u003cli\u003eBuild a JWT payload that carries the \u003ccode\u003eaud\u003c/code\u003e, \u003ccode\u003ecommon_name\u003c/code\u003e, \u003ccode\u003eexp\u003c/code\u003e, \u003ccode\u003eiat\u003c/code\u003e, \u003ccode\u003eiss\u003c/code\u003e, \u003ccode\u003esub\u003c/code\u003e and \u003ccode\u003etype\u003c/code\u003e claims. Use the \u003ccode\u003eiss\u003c/code\u003e the application expects, set \u003ccode\u003eexp\u003c/code\u003e to a future timestamp, and set \u003ccode\u003ecommon_name\u003c/code\u003e to the service token to impersonate.\u003c/li\u003e\n\u003cli\u003eAppend any signature segment. The segment must be present, because \u003ccode\u003eJOSE.JWT.verify/2\u003c/code\u003e needs three segments to parse the token. The signature does not need to verify against the Cloudflare keys.\u003c/li\u003e\n\u003cli\u003eSend a request to the application with the forged JWT in the \u003ccode\u003ecf-access-jwt-assertion\u003c/code\u003e header.\u003c/li\u003e\n\u003cli\u003e\u003ccode\u003eNimbleZTA.Cloudflare.authenticate/3\u003c/code\u003e returns the claims of the forged token as the authenticated identity, with the \u003ccode\u003estrategy\u003c/code\u003e field set to \u003ccode\u003eservice_token\u003c/code\u003e.\u003c/li\u003e\n\u003c/ol\u003e"
},
{
"base64": false,
"type": "text/markdown",
"value": "1. Build a JWT payload that carries the `aud`, `common_name`, `exp`, `iat`, `iss`, `sub` and `type` claims. Use the `iss` the application expects, set `exp` to a future timestamp, and set `common_name` to the service token to impersonate.\n2. Append any signature segment. The segment must be present, because `JOSE.JWT.verify/2` needs three segments to parse the token. The signature does not need to verify against the Cloudflare keys.\n3. Send a request to the application with the forged JWT in the `cf-access-jwt-assertion` header.\n4. `NimbleZTA.Cloudflare.authenticate/3` returns the claims of the forged token as the authenticated identity, with the `strategy` field set to `service_token`."
}
],
"value": "* Build a JWT payload that carries the aud, common_name, exp, iat, iss, sub and type claims. Use the iss the application expects, set exp to a future timestamp, and set common_name to the service token to impersonate.\n* Append any signature segment. The segment must be present, because JOSE.JWT.verify/2 needs three segments to parse the token. The signature does not need to verify against the Cloudflare keys.\n* Send a request to the application with the forged JWT in the cf-access-jwt-assertion header.\n* NimbleZTA.Cloudflare.authenticate/3 returns the claims of the forged token as the authenticated identity, with the strategy field set to service_token."
}
]
}
},
"cveMetadata": {
"assignerOrgId": "6b3ad84c-e1a6-4bf7-a703-f496b71e49db",
"assignerShortName": "EEF",
"cveId": "CVE-2026-91187",
"datePublished": "2026-09-24T13:20:52.974Z",
"dateReserved": "2026-09-15T15:30:01.892Z",
"dateUpdated": "2026-09-24T14:47:30.520Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
CVE-2026-86698 (GCVE-0-2026-86698)
Vulnerability from cvelistv5 – Published: 2026-09-22 15:51 – Updated: 2026-09-22 18:09
VLAI
EPSS
VEX
Title
Refresh tokens accepted as private repository credentials at the CDN
Summary
Insufficient Session Expiration vulnerability in OAuth token issuance in hexpm hexpm allows a user whose organization membership or session has ended to keep reading the organization's private packages and their documentation tarballs via a retained refresh token.
generate_refresh_token/4 in lib/hexpm/oauth/jwt.ex signs the refresh token with the same iss, aud and scope claims as the access token, so it carries the same repository:<org> scopes. The CDN service that serves private repositories verifies the signature and time claims and then authorizes from the scope claim, with no database lookup and no way to tell the two token kinds apart. Removing a member or revoking a session therefore takes effect at the CDN only when the 30 day refresh token expires, instead of after the 30 minute access token lifetime. Access is read-only and limited to organizations the account belonged to when the token was granted.
This issue affects hex.pm: from 2025-10-10 before 2026-09-22.
Severity
SSVC
Exploitation: poc
Automatable: no
Technical Impact: partial
CISA Coordinator · CISA-ADP (v2.0.3)
Decision recorded 2026-09-22 18:05 UTC
CWE
- CWE-613 - Insufficient Session Expiration
Assigner
References
5 references
| URL | Tags |
|---|---|
| https://github.com/hexpm/hexpm/security/advisorie… | vendor-advisoryrelated |
| https://cna.erlef.org/cves/CVE-2026-86698.html | related |
| https://osv.dev/vulnerability/EEF-CVE-2026-86698 | related |
| https://github.com/hexpm/hexpm/commit/650faa03af5… | related |
| https://github.com/hexpm/hexpm/commit/db58cf3a86c… | patch |
Impacted products
{
"containers": {
"adp": [
{
"metrics": [
{
"other": {
"content": {
"id": "CVE-2026-86698",
"options": [
{
"Exploitation": "poc"
},
{
"Automatable": "no"
},
{
"Technical Impact": "partial"
}
],
"role": "CISA Coordinator",
"timestamp": "2026-09-22T18:05:56.100145Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"providerMetadata": {
"dateUpdated": "2026-09-22T18:09:08.676Z",
"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"shortName": "CISA-ADP"
},
"references": [
{
"tags": [
"exploit"
],
"url": "https://github.com/hexpm/hexpm/security/advisories/GHSA-vmw7-7g2w-gw2f"
}
],
"title": "CISA ADP Vulnrichment"
}
],
"cna": {
"affected": [
{
"collectionURL": "https://hex.pm",
"cpes": [
"cpe:2.3:a:hexpm:hexpm:*:*:*:*:*:*:*:*"
],
"defaultStatus": "unaffected",
"modules": [
"\u0027Elixir.Hexpm.OAuth.JWT\u0027",
"\u0027Elixir.Hexpm.OAuth.Tokens\u0027"
],
"packageName": "hex.pm",
"product": "hexpm",
"programFiles": [
"lib/hexpm/oauth/jwt.ex",
"lib/hexpm/oauth/tokens.ex"
],
"programRoutines": [
{
"name": "\u0027Elixir.Hexpm.OAuth.JWT\u0027:generate_refresh_token/4"
},
{
"name": "\u0027Elixir.Hexpm.OAuth.Tokens\u0027:create_for_user/6"
}
],
"vendor": "hexpm",
"versions": [
{
"lessThan": "2026-09-22",
"status": "affected",
"version": "2025-10-10",
"versionType": "date"
}
]
},
{
"collectionURL": "https://github.com",
"cpes": [
"cpe:2.3:a:hexpm:hexpm:*:*:*:*:*:*:*:*"
],
"defaultStatus": "unaffected",
"modules": [
"\u0027Elixir.Hexpm.OAuth.JWT\u0027",
"\u0027Elixir.Hexpm.OAuth.Tokens\u0027"
],
"packageName": "hexpm/hexpm",
"packageURL": "pkg:github/hexpm/hexpm",
"product": "hexpm",
"programFiles": [
"lib/hexpm/oauth/jwt.ex",
"lib/hexpm/oauth/tokens.ex"
],
"programRoutines": [
{
"name": "\u0027Elixir.Hexpm.OAuth.JWT\u0027:generate_refresh_token/4"
},
{
"name": "\u0027Elixir.Hexpm.OAuth.Tokens\u0027:create_for_user/6"
}
],
"repo": "https://github.com/hexpm/hexpm",
"vendor": "hexpm",
"versions": [
{
"lessThan": "db58cf3a86c7639708ef52ff86de0b4f938e6360",
"status": "affected",
"version": "650faa03af511e74c1b3b49ec12d35666b6984c4",
"versionType": "git"
}
]
}
],
"credits": [
{
"lang": "en",
"type": "finder",
"value": "Peter Ullrich"
},
{
"lang": "en",
"type": "analyst",
"value": "Jonatan M\u00e4nnchen / EEF"
},
{
"lang": "en",
"type": "remediation developer",
"value": "Eric Meadows-J\u00f6nsson"
}
],
"dateAssigned": "2026-09-21T12:06:25.000Z",
"descriptions": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003eInsufficient Session Expiration vulnerability in OAuth token issuance in hexpm hexpm allows a user whose organization membership or session has ended to keep reading the organization\u0027s private packages and their documentation tarballs via a retained refresh token.\u003c/p\u003e\n\u003cp\u003e\u003ccode\u003egenerate_refresh_token/4\u003c/code\u003e in \u003ccode\u003elib/hexpm/oauth/jwt.ex\u003c/code\u003e signs the refresh token with the same \u003ccode\u003eiss\u003c/code\u003e, \u003ccode\u003eaud\u003c/code\u003e and \u003ccode\u003escope\u003c/code\u003e claims as the access token, so it carries the same \u003ccode\u003erepository:\u0026lt;org\u0026gt;\u003c/code\u003e scopes. The CDN service that serves private repositories verifies the signature and time claims and then authorizes from the \u003ccode\u003escope\u003c/code\u003e claim, with no database lookup and no way to tell the two token kinds apart. Removing a member or revoking a session therefore takes effect at the CDN only when the 30 day refresh token expires, instead of after the 30 minute access token lifetime. Access is read-only and limited to organizations the account belonged to when the token was granted.\u003c/p\u003e\n\u003cp\u003eThis issue affects hex.pm: from 2025-10-10 before 2026-09-22.\u003c/p\u003e"
},
{
"base64": false,
"type": "text/markdown",
"value": "Insufficient Session Expiration vulnerability in OAuth token issuance in hexpm hexpm allows a user whose organization membership or session has ended to keep reading the organization\u0027s private packages and their documentation tarballs via a retained refresh token.\n\n`generate_refresh_token/4` in `lib/hexpm/oauth/jwt.ex` signs the refresh token with the same `iss`, `aud` and `scope` claims as the access token, so it carries the same `repository:\u003corg\u003e` scopes. The CDN service that serves private repositories verifies the signature and time claims and then authorizes from the `scope` claim, with no database lookup and no way to tell the two token kinds apart. Removing a member or revoking a session therefore takes effect at the CDN only when the 30 day refresh token expires, instead of after the 30 minute access token lifetime. Access is read-only and limited to organizations the account belonged to when the token was granted.\n\nThis issue affects hex.pm: from 2025-10-10 before 2026-09-22."
}
],
"value": "Insufficient Session Expiration vulnerability in OAuth token issuance in hexpm hexpm allows a user whose organization membership or session has ended to keep reading the organization\u0027s private packages and their documentation tarballs via a retained refresh token.\n\ngenerate_refresh_token/4 in lib/hexpm/oauth/jwt.ex signs the refresh token with the same iss, aud and scope claims as the access token, so it carries the same repository:\u003corg\u003e scopes. The CDN service that serves private repositories verifies the signature and time claims and then authorizes from the scope claim, with no database lookup and no way to tell the two token kinds apart. Removing a member or revoking a session therefore takes effect at the CDN only when the 30 day refresh token expires, instead of after the 30 minute access token lifetime. Access is read-only and limited to organizations the account belonged to when the token was granted.\n\nThis issue affects hex.pm: from 2025-10-10 before 2026-09-22."
}
],
"impacts": [
{
"capecId": "CAPEC-60",
"descriptions": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003eA user removed from an organization, or anyone holding a copy of a revoked session\u0027s refresh token, can keep downloading that organization\u0027s private packages and their documentation tarballs for up to 30 days after access was withdrawn.\u003c/p\u003e"
},
{
"base64": false,
"type": "text/markdown",
"value": "A user removed from an organization, or anyone holding a copy of a revoked session\u0027s refresh token, can keep downloading that organization\u0027s private packages and their documentation tarballs for up to 30 days after access was withdrawn."
}
],
"value": "A user removed from an organization, or anyone holding a copy of a revoked session\u0027s refresh token, can keep downloading that organization\u0027s private packages and their documentation tarballs for up to 30 days after access was withdrawn."
}
]
}
],
"metrics": [
{
"cvssV4_0": {
"Automatable": "NOT_DEFINED",
"Recovery": "NOT_DEFINED",
"Safety": "NOT_DEFINED",
"attackComplexity": "LOW",
"attackRequirements": "PRESENT",
"attackVector": "NETWORK",
"baseScore": 2.3,
"baseSeverity": "LOW",
"privilegesRequired": "LOW",
"providerUrgency": "NOT_DEFINED",
"subAvailabilityImpact": "NONE",
"subConfidentialityImpact": "LOW",
"subIntegrityImpact": "NONE",
"userInteraction": "NONE",
"valueDensity": "NOT_DEFINED",
"vectorString": "CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:N/VC:L/VI:N/VA:N/SC:L/SI:N/SA:N",
"version": "4.0",
"vulnAvailabilityImpact": "NONE",
"vulnConfidentialityImpact": "LOW",
"vulnIntegrityImpact": "NONE",
"vulnerabilityResponseEffort": "NOT_DEFINED"
},
"format": "CVSS",
"scenarios": [
{
"lang": "en",
"value": "GENERAL"
}
]
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-613",
"description": "CWE-613 Insufficient Session Expiration",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-09-22T15:51:57.998Z",
"orgId": "6b3ad84c-e1a6-4bf7-a703-f496b71e49db",
"shortName": "EEF"
},
"references": [
{
"name": "Refresh tokens are accepted as private repository credentials at the CDN",
"tags": [
"vendor-advisory",
"related"
],
"url": "https://github.com/hexpm/hexpm/security/advisories/GHSA-vmw7-7g2w-gw2f"
},
{
"name": "EEF CNA record for CVE-2026-86698",
"tags": [
"related"
],
"url": "https://cna.erlef.org/cves/CVE-2026-86698.html"
},
{
"name": "OSV record EEF-CVE-2026-86698",
"tags": [
"related"
],
"url": "https://osv.dev/vulnerability/EEF-CVE-2026-86698"
},
{
"name": "Introducing commit 650faa0 in hexpm/hexpm",
"tags": [
"related"
],
"url": "https://github.com/hexpm/hexpm/commit/650faa03af511e74c1b3b49ec12d35666b6984c4"
},
{
"name": "Fix commit db58cf3 in hexpm/hexpm",
"tags": [
"patch"
],
"url": "https://github.com/hexpm/hexpm/commit/db58cf3a86c7639708ef52ff86de0b4f938e6360"
}
],
"source": {
"discovery": "EXTERNAL"
},
"title": "Refresh tokens accepted as private repository credentials at the CDN",
"x_proofOfConcept": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003col\u003e\n\u003cli\u003eAuthenticate a CLI session with \u003ccode\u003emix hex.user auth\u003c/code\u003e for an account that is a member of an organization with private packages. \u003ccode\u003e~/.hex/hex.config\u003c/code\u003e then holds an access token and a refresh token.\u003c/li\u003e\n\u003cli\u003eCopy the refresh token out of that file.\u003c/li\u003e\n\u003cli\u003eRemove the account from the organization, or revoke the session.\u003c/li\u003e\n\u003cli\u003eRequest \u003ccode\u003ehttps://repo.hex.pm/repos/\u0026lt;org\u0026gt;/tarballs/\u0026lt;package\u0026gt;-\u0026lt;version\u0026gt;.tar\u003c/code\u003e with the header \u003ccode\u003eAuthorization: Bearer \u0026lt;refresh token\u0026gt;\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eThe CDN serves the tarball until the refresh token\u0027s 30 day expiry, while the access token from the same file stops working within 30 minutes.\u003c/li\u003e\n\u003c/ol\u003e"
},
{
"base64": false,
"type": "text/markdown",
"value": "1. Authenticate a CLI session with `mix hex.user auth` for an account that is a member of an organization with private packages. `~/.hex/hex.config` then holds an access token and a refresh token.\n2. Copy the refresh token out of that file.\n3. Remove the account from the organization, or revoke the session.\n4. Request `https://repo.hex.pm/repos/\u003corg\u003e/tarballs/\u003cpackage\u003e-\u003cversion\u003e.tar` with the header `Authorization: Bearer \u003crefresh token\u003e`.\n5. The CDN serves the tarball until the refresh token\u0027s 30 day expiry, while the access token from the same file stops working within 30 minutes."
}
],
"value": "* Authenticate a CLI session with mix hex.user auth for an account that is a member of an organization with private packages. ~/.hex/hex.config then holds an access token and a refresh token.\n* Copy the refresh token out of that file.\n* Remove the account from the organization, or revoke the session.\n* Request https://repo.hex.pm/repos/\u003corg\u003e/tarballs/\u003cpackage\u003e-\u003cversion\u003e.tar with the header Authorization: Bearer \u003crefresh token\u003e.\n* The CDN serves the tarball until the refresh token\u0027s 30 day expiry, while the access token from the same file stops working within 30 minutes."
}
],
"x_technicalAnalysis": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003e\u003cstrong\u003e1. Token issuance\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003e\u003ccode\u003eHexpm.OAuth.JWT.generate_refresh_token/4\u003c/code\u003e builds its claim set from the same template as \u003ccode\u003egenerate_access_token/4\u003c/code\u003e, changing only \u003ccode\u003eexp\u003c/code\u003e, so a refresh token carries the \u003ccode\u003escope\u003c/code\u003e claim of the access token it is issued with. hexpm itself never reads that claim: the refresh grant resolves scopes from the database, and \u003ccode\u003eHexpm.OAuth.Tokens.lookup/3\u003c/code\u003e matches an access token on the \u003ccode\u003ejti\u003c/code\u003e column and a refresh token on \u003ccode\u003erefresh_jti\u003c/code\u003e, so hexpm\u0027s API rejects a refresh token presented as a bearer credential.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e2. Edge authorization\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003eThe CDN service in front of private repositories consults no database. It verifies the ES256 signature, \u003ccode\u003eiss\u003c/code\u003e, \u003ccode\u003eaud\u003c/code\u003e, \u003ccode\u003enbf\u003c/code\u003e and \u003ccode\u003eexp\u003c/code\u003e, then grants access when \u003ccode\u003escope\u003c/code\u003e contains \u003ccode\u003erepository:\u0026lt;org\u0026gt;\u003c/code\u003e. A refresh token sent as \u003ccode\u003eAuthorization: Bearer\u003c/code\u003e passes every check and is authorized like an access token.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e3. Effect\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003eMember removal, session revocation and an organization single sign-on session lapsing rely on the 30 minute access token lifetime to take effect at the CDN, because the CDN has no revocation list. A copy of the refresh token extends that window to its 30 day lifetime.\u003c/p\u003e"
},
{
"base64": false,
"type": "text/markdown",
"value": "**1. Token issuance**\n\n`Hexpm.OAuth.JWT.generate_refresh_token/4` builds its claim set from the same template as `generate_access_token/4`, changing only `exp`, so a refresh token carries the `scope` claim of the access token it is issued with. hexpm itself never reads that claim: the refresh grant resolves scopes from the database, and `Hexpm.OAuth.Tokens.lookup/3` matches an access token on the `jti` column and a refresh token on `refresh_jti`, so hexpm\u0027s API rejects a refresh token presented as a bearer credential.\n\n**2. Edge authorization**\n\nThe CDN service in front of private repositories consults no database. It verifies the ES256 signature, `iss`, `aud`, `nbf` and `exp`, then grants access when `scope` contains `repository:\u003corg\u003e`. A refresh token sent as `Authorization: Bearer` passes every check and is authorized like an access token.\n\n**3. Effect**\n\nMember removal, session revocation and an organization single sign-on session lapsing rely on the 30 minute access token lifetime to take effect at the CDN, because the CDN has no revocation list. A copy of the refresh token extends that window to its 30 day lifetime."
}
],
"value": "1. Token issuance\n\nHexpm.OAuth.JWT.generate_refresh_token/4 builds its claim set from the same template as generate_access_token/4, changing only exp, so a refresh token carries the scope claim of the access token it is issued with. hexpm itself never reads that claim: the refresh grant resolves scopes from the database, and Hexpm.OAuth.Tokens.lookup/3 matches an access token on the jti column and a refresh token on refresh_jti, so hexpm\u0027s API rejects a refresh token presented as a bearer credential.\n\n2. Edge authorization\n\nThe CDN service in front of private repositories consults no database. It verifies the ES256 signature, iss, aud, nbf and exp, then grants access when scope contains repository:\u003corg\u003e. A refresh token sent as Authorization: Bearer passes every check and is authorized like an access token.\n\n3. Effect\n\nMember removal, session revocation and an organization single sign-on session lapsing rely on the 30 minute access token lifetime to take effect at the CDN, because the CDN has no revocation list. A copy of the refresh token extends that window to its 30 day lifetime."
}
]
}
},
"cveMetadata": {
"assignerOrgId": "6b3ad84c-e1a6-4bf7-a703-f496b71e49db",
"assignerShortName": "EEF",
"cveId": "CVE-2026-86698",
"datePublished": "2026-09-22T15:51:57.998Z",
"dateReserved": "2026-09-17T14:30:02.046Z",
"dateUpdated": "2026-09-22T18:09:08.676Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
CVE-2026-87119 (GCVE-0-2026-87119)
Vulnerability from cvelistv5 – Published: 2026-09-22 11:16 – Updated: 2026-09-22 12:02
VLAI
EPSS
VEX
Title
mpp Tempo subscription key authorization is not bound to the issuing challenge, allowing a captured activation credential to be replayed
Summary
Authentication Bypass by Capture-replay in ZenHive mpp allows an attacker holding a captured subscription activation credential to charge the payer repeatedly.
The payer signs a Tempo KeyAuthorization over the chain id, key type, key id, expiry, limits and scopes only, with nothing tying it to the challenge that prompted it. MPP.Methods.Tempo.KeyAuthorization.verify/3 in lib/mpp/methods/tempo/key_authorization.ex pins each of those signed fields against the subscription request, and the access key it pins is a static per-endpoint server key, so one signed authorization verifies against every challenge the server issues for the same subscription terms. MPP.Methods.Tempo.Subscription.activate/4 deduplicates activations by challenge id, so presenting the captured credential under a fresh challenge produces a different dedup key, claim_activation succeeds, and the subscription transaction is built and broadcast again. Each replay charges the payer's wallet a new first-period settlement and re-authorizes the server key, bounded only by the subscription expiry and the chain's own semantics for re-installing an existing key.
This issue affects mpp: from 0.14.0 before 0.16.2.
Severity
SSVC
Exploitation: none
Automatable: no
Technical Impact: partial
CISA Coordinator · CISA-ADP (v2.0.3)
Decision recorded 2026-09-22 12:02 UTC
CWE
- CWE-294 - Authentication Bypass by Capture-replay
Assigner
References
5 references
| URL | Tags |
|---|---|
| https://github.com/ZenHive/mpp/security/advisorie… | relatedvendor-advisory |
| https://cna.erlef.org/cves/CVE-2026-87119.html | related |
| https://osv.dev/vulnerability/EEF-CVE-2026-87119 | related |
| https://github.com/ZenHive/mpp/commit/db464dfa9a8… | related |
| https://github.com/ZenHive/mpp/commit/4b6eaec02af… | patch |
Impacted products
{
"containers": {
"adp": [
{
"metrics": [
{
"other": {
"content": {
"id": "CVE-2026-87119",
"options": [
{
"Exploitation": "none"
},
{
"Automatable": "no"
},
{
"Technical Impact": "partial"
}
],
"role": "CISA Coordinator",
"timestamp": "2026-09-22T12:02:12.184296Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"providerMetadata": {
"dateUpdated": "2026-09-22T12:02:31.484Z",
"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"shortName": "CISA-ADP"
},
"title": "CISA ADP Vulnrichment"
}
],
"cna": {
"affected": [
{
"collectionURL": "https://repo.hex.pm",
"cpes": [
"cpe:2.3:a:ZenHive:mpp:*:*:*:*:*:*:*:*"
],
"defaultStatus": "unaffected",
"modules": [
"\u0027Elixir.MPP.Methods.Tempo.KeyAuthorization\u0027",
"\u0027Elixir.MPP.Methods.Tempo.Subscription\u0027"
],
"packageName": "mpp",
"packageURL": "pkg:hex/mpp",
"product": "mpp",
"programFiles": [
"lib/mpp/methods/tempo/key_authorization.ex",
"lib/mpp/methods/tempo/subscription.ex"
],
"programRoutines": [
{
"name": "\u0027Elixir.MPP.Methods.Tempo.KeyAuthorization\u0027:verify/3"
},
{
"name": "\u0027Elixir.MPP.Methods.Tempo.KeyAuthorization\u0027:wallet_params/2"
},
{
"name": "\u0027Elixir.MPP.Methods.Tempo.KeyAuthorization\u0027:from_rpc/1"
},
{
"name": "\u0027Elixir.MPP.Methods.Tempo.Subscription\u0027:verify/2"
}
],
"repo": "https://github.com/ZenHive/mpp",
"vendor": "ZenHive",
"versions": [
{
"lessThan": "0.16.2",
"status": "affected",
"version": "0.14.0",
"versionType": "semver"
}
]
},
{
"collectionURL": "https://github.com",
"cpes": [
"cpe:2.3:a:ZenHive:mpp:*:*:*:*:*:*:*:*"
],
"defaultStatus": "unaffected",
"modules": [
"\u0027Elixir.MPP.Methods.Tempo.KeyAuthorization\u0027",
"\u0027Elixir.MPP.Methods.Tempo.Subscription\u0027"
],
"packageName": "zenhive/mpp",
"packageURL": "pkg:github/zenhive/mpp",
"product": "mpp",
"programFiles": [
"lib/mpp/methods/tempo/key_authorization.ex",
"lib/mpp/methods/tempo/subscription.ex"
],
"programRoutines": [
{
"name": "\u0027Elixir.MPP.Methods.Tempo.KeyAuthorization\u0027:verify/3"
},
{
"name": "\u0027Elixir.MPP.Methods.Tempo.KeyAuthorization\u0027:wallet_params/2"
},
{
"name": "\u0027Elixir.MPP.Methods.Tempo.KeyAuthorization\u0027:from_rpc/1"
},
{
"name": "\u0027Elixir.MPP.Methods.Tempo.Subscription\u0027:verify/2"
}
],
"repo": "https://github.com/ZenHive/mpp",
"vendor": "ZenHive",
"versions": [
{
"lessThan": "4b6eaec02af0e8485cfb4ff68f467d075ed5dd6f",
"status": "affected",
"version": "db464dfa9a86ccda58f0827101f6da6bd8aafa78",
"versionType": "git"
}
]
}
],
"configurations": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003eOnly deployments offering Tempo subscriptions are affected, which requires \u003ccode\u003esubscription_access_key_private_key\u003c/code\u003e in the Tempo \u003ccode\u003emethod_config\u003c/code\u003e. Exploitation further requires the attacker to have obtained a payer\u0027s signed activation credential, in transit over a hop that is not TLS-protected or at rest in a log, an intermediary, or a client retry buffer.\u003c/p\u003e"
},
{
"base64": false,
"type": "text/markdown",
"value": "Only deployments offering Tempo subscriptions are affected, which requires `subscription_access_key_private_key` in the Tempo `method_config`. Exploitation further requires the attacker to have obtained a payer\u0027s signed activation credential, in transit over a hop that is not TLS-protected or at rest in a log, an intermediary, or a client retry buffer."
}
],
"value": "Only deployments offering Tempo subscriptions are affected, which requires subscription_access_key_private_key in the Tempo method_config. Exploitation further requires the attacker to have obtained a payer\u0027s signed activation credential, in transit over a hop that is not TLS-protected or at rest in a log, an intermediary, or a client retry buffer."
}
],
"cpeApplicability": [
{
"nodes": [
{
"cpeMatch": [
{
"criteria": "cpe:2.3:a:ZenHive:mpp:*:*:*:*:*:*:*:*",
"versionEndExcluding": "0.16.2",
"versionStartIncluding": "0.14.0",
"vulnerable": true
}
],
"negate": false,
"operator": "OR"
}
],
"operator": "AND"
}
],
"credits": [
{
"lang": "en",
"type": "finder",
"value": "E.FU"
},
{
"lang": "en",
"type": "remediation developer",
"value": "E.FU"
},
{
"lang": "en",
"type": "coordinator",
"value": "Jonatan M\u00e4nnchen / EEF"
}
],
"dateAssigned": "2026-09-15T15:20:31.000Z",
"descriptions": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003eAuthentication Bypass by Capture-replay in ZenHive mpp allows an attacker holding a captured subscription activation credential to charge the payer repeatedly.\u003c/p\u003e\n\u003cp\u003eThe payer signs a Tempo \u003ccode\u003eKeyAuthorization\u003c/code\u003e over the chain id, key type, key id, expiry, limits and scopes only, with nothing tying it to the challenge that prompted it. \u003ccode\u003eMPP.Methods.Tempo.KeyAuthorization.verify/3\u003c/code\u003e in \u003ccode\u003elib/mpp/methods/tempo/key_authorization.ex\u003c/code\u003e pins each of those signed fields against the subscription request, and the access key it pins is a static per-endpoint server key, so one signed authorization verifies against every challenge the server issues for the same subscription terms. \u003ccode\u003eMPP.Methods.Tempo.Subscription.activate/4\u003c/code\u003e deduplicates activations by challenge id, so presenting the captured credential under a fresh challenge produces a different dedup key, \u003ccode\u003eclaim_activation\u003c/code\u003e succeeds, and the subscription transaction is built and broadcast again. Each replay charges the payer\u0027s wallet a new first-period settlement and re-authorizes the server key, bounded only by the subscription expiry and the chain\u0027s own semantics for re-installing an existing key.\u003c/p\u003e\n\u003cp\u003eThis issue affects mpp: from 0.14.0 before 0.16.2.\u003c/p\u003e"
},
{
"base64": false,
"type": "text/markdown",
"value": "Authentication Bypass by Capture-replay in ZenHive mpp allows an attacker holding a captured subscription activation credential to charge the payer repeatedly.\n\nThe payer signs a Tempo `KeyAuthorization` over the chain id, key type, key id, expiry, limits and scopes only, with nothing tying it to the challenge that prompted it. `MPP.Methods.Tempo.KeyAuthorization.verify/3` in `lib/mpp/methods/tempo/key_authorization.ex` pins each of those signed fields against the subscription request, and the access key it pins is a static per-endpoint server key, so one signed authorization verifies against every challenge the server issues for the same subscription terms. `MPP.Methods.Tempo.Subscription.activate/4` deduplicates activations by challenge id, so presenting the captured credential under a fresh challenge produces a different dedup key, `claim_activation` succeeds, and the subscription transaction is built and broadcast again. Each replay charges the payer\u0027s wallet a new first-period settlement and re-authorizes the server key, bounded only by the subscription expiry and the chain\u0027s own semantics for re-installing an existing key.\n\nThis issue affects mpp: from 0.14.0 before 0.16.2."
}
],
"value": "Authentication Bypass by Capture-replay in ZenHive mpp allows an attacker holding a captured subscription activation credential to charge the payer repeatedly.\n\nThe payer signs a Tempo KeyAuthorization over the chain id, key type, key id, expiry, limits and scopes only, with nothing tying it to the challenge that prompted it. MPP.Methods.Tempo.KeyAuthorization.verify/3 in lib/mpp/methods/tempo/key_authorization.ex pins each of those signed fields against the subscription request, and the access key it pins is a static per-endpoint server key, so one signed authorization verifies against every challenge the server issues for the same subscription terms. MPP.Methods.Tempo.Subscription.activate/4 deduplicates activations by challenge id, so presenting the captured credential under a fresh challenge produces a different dedup key, claim_activation succeeds, and the subscription transaction is built and broadcast again. Each replay charges the payer\u0027s wallet a new first-period settlement and re-authorizes the server key, bounded only by the subscription expiry and the chain\u0027s own semantics for re-installing an existing key.\n\nThis issue affects mpp: from 0.14.0 before 0.16.2."
}
],
"impacts": [
{
"capecId": "CAPEC-60",
"descriptions": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003eAn attacker who obtains a payer\u0027s subscription activation credential (from a non-TLS hop, a log, a compromised intermediary, or the client\u0027s own retry buffer) can present it under fresh challenges to settle repeated first-period charges against that payer\u0027s wallet and re-authorize the server\u0027s access key. The payer bears the on-chain cost, limited only by the per-period subscription limit and the subscription expiry.\u003c/p\u003e"
},
{
"base64": false,
"type": "text/markdown",
"value": "An attacker who obtains a payer\u0027s subscription activation credential (from a non-TLS hop, a log, a compromised intermediary, or the client\u0027s own retry buffer) can present it under fresh challenges to settle repeated first-period charges against that payer\u0027s wallet and re-authorize the server\u0027s access key. The payer bears the on-chain cost, limited only by the per-period subscription limit and the subscription expiry."
}
],
"value": "An attacker who obtains a payer\u0027s subscription activation credential (from a non-TLS hop, a log, a compromised intermediary, or the client\u0027s own retry buffer) can present it under fresh challenges to settle repeated first-period charges against that payer\u0027s wallet and re-authorize the server\u0027s access key. The payer bears the on-chain cost, limited only by the per-period subscription limit and the subscription expiry."
}
]
}
],
"metrics": [
{
"cvssV4_0": {
"Automatable": "NOT_DEFINED",
"Recovery": "NOT_DEFINED",
"Safety": "NOT_DEFINED",
"attackComplexity": "HIGH",
"attackRequirements": "PRESENT",
"attackVector": "NETWORK",
"baseScore": 8.2,
"baseSeverity": "HIGH",
"privilegesRequired": "NONE",
"providerUrgency": "NOT_DEFINED",
"subAvailabilityImpact": "NONE",
"subConfidentialityImpact": "NONE",
"subIntegrityImpact": "NONE",
"userInteraction": "NONE",
"valueDensity": "NOT_DEFINED",
"vectorString": "CVSS:4.0/AV:N/AC:H/AT:P/PR:N/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N",
"version": "4.0",
"vulnAvailabilityImpact": "NONE",
"vulnConfidentialityImpact": "NONE",
"vulnIntegrityImpact": "HIGH",
"vulnerabilityResponseEffort": "NOT_DEFINED"
},
"format": "CVSS",
"scenarios": [
{
"lang": "en",
"value": "GENERAL"
}
]
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-294",
"description": "CWE-294 Authentication Bypass by Capture-replay",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-09-22T11:16:56.232Z",
"orgId": "6b3ad84c-e1a6-4bf7-a703-f496b71e49db",
"shortName": "EEF"
},
"references": [
{
"name": "GitHub Advisory",
"tags": [
"related",
"vendor-advisory"
],
"url": "https://github.com/ZenHive/mpp/security/advisories/GHSA-p9fv-9w58-95x2"
},
{
"name": "EEF CNA record for CVE-2026-87119",
"tags": [
"related"
],
"url": "https://cna.erlef.org/cves/CVE-2026-87119.html"
},
{
"name": "OSV record EEF-CVE-2026-87119",
"tags": [
"related"
],
"url": "https://osv.dev/vulnerability/EEF-CVE-2026-87119"
},
{
"name": "Introducing commit db464df in ZenHive/mpp",
"tags": [
"related"
],
"url": "https://github.com/ZenHive/mpp/commit/db464dfa9a86ccda58f0827101f6da6bd8aafa78"
},
{
"name": "Fix commit 4b6eaec in ZenHive/mpp",
"tags": [
"patch"
],
"url": "https://github.com/ZenHive/mpp/commit/4b6eaec02af0e8485cfb4ff68f467d075ed5dd6f"
}
],
"source": {
"discovery": "INTERNAL"
},
"title": "mpp Tempo subscription key authorization is not bound to the issuing challenge, allowing a captured activation credential to be replayed"
}
},
"cveMetadata": {
"assignerOrgId": "6b3ad84c-e1a6-4bf7-a703-f496b71e49db",
"assignerShortName": "EEF",
"cveId": "CVE-2026-87119",
"datePublished": "2026-09-22T11:16:56.232Z",
"dateReserved": "2026-09-11T18:00:02.032Z",
"dateUpdated": "2026-09-22T12:02:31.484Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
CVE-2026-89420 (GCVE-0-2026-89420)
Vulnerability from cvelistv5 – Published: 2026-09-22 11:16 – Updated: 2026-09-22 12:04
VLAI
EPSS
VEX
Title
Session voucher adding no new funds is accepted without a charge in mpp, serving paid resources for free
Summary
Improper Validation of Specified Quantity in Input in ZenHive mpp allows a client holding an open payment channel to obtain paid resources without being charged.
MPP.Session.Actions.accept_voucher/3 in lib/mpp/session/actions.ex treats a voucher whose cumulativeAmount equals the channel's already-accepted cumulative amount as an idempotent success, returning the channel unchanged without calling maybe_spend/2. The credential verifies, the protected resource is served, and spent and units stay where they were. Because the server issues a fresh challenge per request and the credential replay store keys on challenge id and payload, the same signed voucher can be re-presented under every new challenge, so one paid voucher yields an unbounded number of paid units. The path is reachable from any method built on MPP.Session.Method through the Plug, MCP, JSON-RPC and WebSocket transports.
This issue affects mpp: from 0.14.0 before 0.16.2.
Severity
SSVC
Exploitation: poc
Automatable: no
Technical Impact: partial
CISA Coordinator · CISA-ADP (v2.0.3)
Decision recorded 2026-09-22 12:03 UTC
CWE
- CWE-1284 - Improper Validation of Specified Quantity in Input
Assigner
References
5 references
| URL | Tags |
|---|---|
| https://github.com/ZenHive/mpp/security/advisorie… | relatedvendor-advisory |
| https://cna.erlef.org/cves/CVE-2026-89420.html | related |
| https://osv.dev/vulnerability/EEF-CVE-2026-89420 | related |
| https://github.com/ZenHive/mpp/commit/82df569c898… | related |
| https://github.com/ZenHive/mpp/commit/7270edc1dcf… | patch |
Impacted products
{
"containers": {
"adp": [
{
"metrics": [
{
"other": {
"content": {
"id": "CVE-2026-89420",
"options": [
{
"Exploitation": "poc"
},
{
"Automatable": "no"
},
{
"Technical Impact": "partial"
}
],
"role": "CISA Coordinator",
"timestamp": "2026-09-22T12:03:58.968313Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"providerMetadata": {
"dateUpdated": "2026-09-22T12:04:43.291Z",
"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"shortName": "CISA-ADP"
},
"references": [
{
"tags": [
"exploit"
],
"url": "https://github.com/ZenHive/mpp/security/advisories/GHSA-8c63-r789-xrrf"
}
],
"title": "CISA ADP Vulnrichment"
}
],
"cna": {
"affected": [
{
"collectionURL": "https://repo.hex.pm",
"cpes": [
"cpe:2.3:a:ZenHive:mpp:*:*:*:*:*:*:*:*"
],
"defaultStatus": "unaffected",
"modules": [
"\u0027Elixir.MPP.Session.Actions\u0027"
],
"packageName": "mpp",
"packageURL": "pkg:hex/mpp",
"product": "mpp",
"programFiles": [
"lib/mpp/session/actions.ex"
],
"programRoutines": [
{
"name": "\u0027Elixir.MPP.Session.Actions\u0027:dispatch/2"
},
{
"name": "\u0027Elixir.MPP.Session.Actions\u0027:handle/2"
}
],
"repo": "https://github.com/ZenHive/mpp",
"vendor": "ZenHive",
"versions": [
{
"lessThan": "0.16.2",
"status": "affected",
"version": "0.14.0",
"versionType": "semver"
}
]
},
{
"collectionURL": "https://github.com",
"cpes": [
"cpe:2.3:a:ZenHive:mpp:*:*:*:*:*:*:*:*"
],
"defaultStatus": "unaffected",
"modules": [
"\u0027Elixir.MPP.Session.Actions\u0027"
],
"packageName": "zenhive/mpp",
"packageURL": "pkg:github/zenhive/mpp",
"product": "mpp",
"programFiles": [
"lib/mpp/session/actions.ex"
],
"programRoutines": [
{
"name": "\u0027Elixir.MPP.Session.Actions\u0027:dispatch/2"
},
{
"name": "\u0027Elixir.MPP.Session.Actions\u0027:handle/2"
}
],
"repo": "https://github.com/ZenHive/mpp",
"vendor": "ZenHive",
"versions": [
{
"lessThan": "7270edc1dcfb58250cc5ee812876609206564165",
"status": "affected",
"version": "82df569c898be1137189e3648e1edb4af6363651",
"versionType": "git"
}
]
}
],
"cpeApplicability": [
{
"nodes": [
{
"cpeMatch": [
{
"criteria": "cpe:2.3:a:ZenHive:mpp:*:*:*:*:*:*:*:*",
"versionEndExcluding": "0.16.2",
"versionStartIncluding": "0.14.0",
"vulnerable": true
}
],
"negate": false,
"operator": "OR"
}
],
"operator": "AND"
}
],
"credits": [
{
"lang": "en",
"type": "finder",
"value": "E.FU"
},
{
"lang": "en",
"type": "remediation developer",
"value": "E.FU"
},
{
"lang": "en",
"type": "coordinator",
"value": "Jonatan M\u00e4nnchen / EEF"
}
],
"dateAssigned": "2026-09-15T15:23:05.000Z",
"descriptions": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003eImproper Validation of Specified Quantity in Input in ZenHive mpp allows a client holding an open payment channel to obtain paid resources without being charged.\u003c/p\u003e\n\u003cp\u003e\u003ccode\u003eMPP.Session.Actions.accept_voucher/3\u003c/code\u003e in \u003ccode\u003elib/mpp/session/actions.ex\u003c/code\u003e treats a voucher whose \u003ccode\u003ecumulativeAmount\u003c/code\u003e equals the channel\u0027s already-accepted cumulative amount as an idempotent success, returning the channel unchanged without calling \u003ccode\u003emaybe_spend/2\u003c/code\u003e. The credential verifies, the protected resource is served, and \u003ccode\u003espent\u003c/code\u003e and \u003ccode\u003eunits\u003c/code\u003e stay where they were. Because the server issues a fresh challenge per request and the credential replay store keys on challenge id and payload, the same signed voucher can be re-presented under every new challenge, so one paid voucher yields an unbounded number of paid units. The path is reachable from any method built on \u003ccode\u003eMPP.Session.Method\u003c/code\u003e through the Plug, MCP, JSON-RPC and WebSocket transports.\u003c/p\u003e\n\u003cp\u003eThis issue affects mpp: from 0.14.0 before 0.16.2.\u003c/p\u003e"
},
{
"base64": false,
"type": "text/markdown",
"value": "Improper Validation of Specified Quantity in Input in ZenHive mpp allows a client holding an open payment channel to obtain paid resources without being charged.\n\n`MPP.Session.Actions.accept_voucher/3` in `lib/mpp/session/actions.ex` treats a voucher whose `cumulativeAmount` equals the channel\u0027s already-accepted cumulative amount as an idempotent success, returning the channel unchanged without calling `maybe_spend/2`. The credential verifies, the protected resource is served, and `spent` and `units` stay where they were. Because the server issues a fresh challenge per request and the credential replay store keys on challenge id and payload, the same signed voucher can be re-presented under every new challenge, so one paid voucher yields an unbounded number of paid units. The path is reachable from any method built on `MPP.Session.Method` through the Plug, MCP, JSON-RPC and WebSocket transports.\n\nThis issue affects mpp: from 0.14.0 before 0.16.2."
}
],
"value": "Improper Validation of Specified Quantity in Input in ZenHive mpp allows a client holding an open payment channel to obtain paid resources without being charged.\n\nMPP.Session.Actions.accept_voucher/3 in lib/mpp/session/actions.ex treats a voucher whose cumulativeAmount equals the channel\u0027s already-accepted cumulative amount as an idempotent success, returning the channel unchanged without calling maybe_spend/2. The credential verifies, the protected resource is served, and spent and units stay where they were. Because the server issues a fresh challenge per request and the credential replay store keys on challenge id and payload, the same signed voucher can be re-presented under every new challenge, so one paid voucher yields an unbounded number of paid units. The path is reachable from any method built on MPP.Session.Method through the Plug, MCP, JSON-RPC and WebSocket transports.\n\nThis issue affects mpp: from 0.14.0 before 0.16.2."
}
],
"impacts": [
{
"capecId": "CAPEC-212",
"descriptions": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003eA client that has opened and funded a payment channel once can re-present the same signed voucher indefinitely and receive paid resources without any further charge. Operators running mpp as paid-API middleware lose revenue in proportion to how much the client consumes, with nothing in the channel state recording the usage.\u003c/p\u003e"
},
{
"base64": false,
"type": "text/markdown",
"value": "A client that has opened and funded a payment channel once can re-present the same signed voucher indefinitely and receive paid resources without any further charge. Operators running mpp as paid-API middleware lose revenue in proportion to how much the client consumes, with nothing in the channel state recording the usage."
}
],
"value": "A client that has opened and funded a payment channel once can re-present the same signed voucher indefinitely and receive paid resources without any further charge. Operators running mpp as paid-API middleware lose revenue in proportion to how much the client consumes, with nothing in the channel state recording the usage."
}
]
}
],
"metrics": [
{
"cvssV4_0": {
"Automatable": "NOT_DEFINED",
"Recovery": "NOT_DEFINED",
"Safety": "NOT_DEFINED",
"attackComplexity": "LOW",
"attackRequirements": "NONE",
"attackVector": "NETWORK",
"baseScore": 7.1,
"baseSeverity": "HIGH",
"privilegesRequired": "LOW",
"providerUrgency": "NOT_DEFINED",
"subAvailabilityImpact": "NONE",
"subConfidentialityImpact": "NONE",
"subIntegrityImpact": "NONE",
"userInteraction": "NONE",
"valueDensity": "NOT_DEFINED",
"vectorString": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N",
"version": "4.0",
"vulnAvailabilityImpact": "NONE",
"vulnConfidentialityImpact": "NONE",
"vulnIntegrityImpact": "HIGH",
"vulnerabilityResponseEffort": "NOT_DEFINED"
},
"format": "CVSS",
"scenarios": [
{
"lang": "en",
"value": "GENERAL"
}
]
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-1284",
"description": "CWE-1284 Improper Validation of Specified Quantity in Input",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-09-22T11:16:29.573Z",
"orgId": "6b3ad84c-e1a6-4bf7-a703-f496b71e49db",
"shortName": "EEF"
},
"references": [
{
"name": "GitHub Advisory",
"tags": [
"related",
"vendor-advisory"
],
"url": "https://github.com/ZenHive/mpp/security/advisories/GHSA-8c63-r789-xrrf"
},
{
"name": "EEF CNA record for CVE-2026-89420",
"tags": [
"related"
],
"url": "https://cna.erlef.org/cves/CVE-2026-89420.html"
},
{
"name": "OSV record EEF-CVE-2026-89420",
"tags": [
"related"
],
"url": "https://osv.dev/vulnerability/EEF-CVE-2026-89420"
},
{
"name": "Introducing commit 82df569 in ZenHive/mpp",
"tags": [
"related"
],
"url": "https://github.com/ZenHive/mpp/commit/82df569c898be1137189e3648e1edb4af6363651"
},
{
"name": "Fix commit 7270edc in ZenHive/mpp",
"tags": [
"patch"
],
"url": "https://github.com/ZenHive/mpp/commit/7270edc1dcfb58250cc5ee812876609206564165"
}
],
"source": {
"discovery": "INTERNAL"
},
"title": "Session voucher adding no new funds is accepted without a charge in mpp, serving paid resources for free"
}
},
"cveMetadata": {
"assignerOrgId": "6b3ad84c-e1a6-4bf7-a703-f496b71e49db",
"assignerShortName": "EEF",
"cveId": "CVE-2026-89420",
"datePublished": "2026-09-22T11:16:29.573Z",
"dateReserved": "2026-09-11T19:00:02.531Z",
"dateUpdated": "2026-09-22T12:04:43.291Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
CVE-2026-65634 (GCVE-0-2026-65634)
Vulnerability from cvelistv5 – Published: 2026-09-22 08:49 – Updated: 2026-09-24 20:06
VLAI
EPSS
VEX
Title
Superlinear CPU denial of service in Erlang/OTP ASN.1 OBJECT IDENTIFIER decoder
Summary
Inefficient algorithmic complexity in the Erlang/OTP asn1 OBJECT IDENTIFIER decoder allows a remote unauthenticated attacker to cause denial of service by sending a crafted OID during the TLS handshake.
The BER OID decoder asn1rtt_ber:dec_subidentifiers/3 in lib/asn1/src/asn1rtt_ber.erl and the equivalent PER helper asn1rtt_per_common:dec_subidentifiers/3 in lib/asn1/src/asn1rtt_per_common.erl accumulate a base-128 subidentifier into an unbounded integer using (Av bsl 7) + H per continuation byte. Each shift and addition on the growing accumulator is linear in the number of bits already accumulated, giving quadratic total work in the size of a single subidentifier. The JER helper asn1rtt_jer:json2oid/1 in lib/asn1/src/asn1rtt_jer.erl exhibits the same class of unbounded-integer parsing when decoding a dot-separated OID from JSON. A DER-encoded OBJECT IDENTIFIER with one very large arc (approximately 262 KB of continuation bytes) consumes roughly 13 seconds of CPU on typical hardware.
The vulnerable decoder is generated into every ASN.1 module that contains an OBJECT IDENTIFIER, including OTP-PUB-KEY which is reached during X.509 certificate parsing via public_key:pkix_decode_cert/2. This decoder runs before any signature or trust chain verification, so any Erlang service that parses peer TLS certificates is exposed: the default for TLS clients (which always parse the server certificate) and for mutual-TLS servers (which parse client certificates).
This vulnerability is associated with program files lib/asn1/src/asn1rtt_ber.erl, lib/asn1/src/asn1rtt_per_common.erl and lib/asn1/src/asn1rtt_jer.erl and program routines asn1rtt_ber:dec_subidentifiers/3, asn1rtt_per_common:dec_subidentifiers/3 and asn1rtt_jer:json2oid/1.
This issue affects OTP from OTP 17.0 before OTP 27.3.4.18, OTP 28.5.0.7, and OTP 29.1.1, corresponding to asn1 from 3.0 before 5.3.4.3, 5.4.3.1, and 5.5.2. Whether OTP before OTP 17.0, corresponding to asn1 before 3.0, is affected is unknown.
Severity
SSVC
Exploitation: none
Automatable: yes
Technical Impact: partial
CISA Coordinator · CISA-ADP (v2.0.3)
Decision recorded 2026-09-22 10:12 UTC
CWE
- CWE-407 - Inefficient Algorithmic Complexity
Assigner
References
5 references
| URL | Tags |
|---|---|
| https://github.com/erlang/otp/security/advisories… | relatedvendor-advisory |
| https://cna.erlef.org/cves/CVE-2026-65634.html | related |
| https://osv.dev/vulnerability/EEF-CVE-2026-65634 | related |
| https://www.erlang.org/doc/system/versions.html#o… | x_version-scheme |
| https://github.com/erlang/otp/commit/0fe2c02fdc06… | patch |
Impacted products
3 products
| Vendor | Product | Version | |
|---|---|---|---|
| Erlang | OTP |
Affected:
17.0 , < *
(otp)
cpe:2.3:a:erlang:erlang\/otp:*:*:*:*:*:*:*:* |
|
| Erlang | OTP |
Affected:
3.0 , < *
(otp)
cpe:2.3:a:erlang:erlang\/otp:*:*:*:*:*:*:*:* |
|
| Erlang | OTP |
Affected:
84adefa331c4159d432d22840663c38f155cd4c1 , < 0fe2c02fdc06fab1c63be9db1a7456993d20f838
(git)
Unaffected: 0fe2c02fdc06fab1c63be9db1a7456993d20f838 , < * (git) cpe:2.3:a:erlang:erlang\/otp:*:*:*:*:*:*:*:* |
Date Public
2026-09-22 08:49
{
"containers": {
"adp": [
{
"metrics": [
{
"other": {
"content": {
"id": "CVE-2026-65634",
"options": [
{
"Exploitation": "none"
},
{
"Automatable": "yes"
},
{
"Technical Impact": "partial"
}
],
"role": "CISA Coordinator",
"timestamp": "2026-09-22T10:12:07.686442Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"providerMetadata": {
"dateUpdated": "2026-09-22T10:15:28.691Z",
"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"shortName": "CISA-ADP"
},
"title": "CISA ADP Vulnrichment"
}
],
"cna": {
"affected": [
{
"cpes": [
"cpe:2.3:a:erlang:erlang\\/otp:*:*:*:*:*:*:*:*"
],
"defaultStatus": "unknown",
"modules": [
"asn1rtt_ber",
"asn1rtt_per_common",
"asn1rtt_jer"
],
"packageName": "otp",
"packageURL": "pkg:software-id/erlang.org/otp",
"product": "OTP",
"programFiles": [
"lib/asn1/src/asn1rtt_ber.erl",
"lib/asn1/src/asn1rtt_per_common.erl",
"lib/asn1/src/asn1rtt_jer.erl"
],
"programRoutines": [
{
"name": "asn1rtt_ber:dec_subidentifiers/3"
},
{
"name": "asn1rtt_per_common:dec_subidentifiers/3"
},
{
"name": "asn1rtt_jer:json2oid/1"
}
],
"vendor": "Erlang",
"versions": [
{
"changes": [
{
"at": "27.3.4.18",
"status": "unaffected"
},
{
"at": "28.5.0.7",
"status": "unaffected"
},
{
"at": "29.1.1",
"status": "unaffected"
}
],
"lessThan": "*",
"status": "affected",
"version": "17.0",
"versionType": "otp"
}
]
},
{
"cpes": [
"cpe:2.3:a:erlang:erlang\\/otp:*:*:*:*:*:*:*:*"
],
"defaultStatus": "unknown",
"modules": [
"asn1rtt_ber",
"asn1rtt_per_common",
"asn1rtt_jer"
],
"packageName": "asn1",
"packageURL": "pkg:otp/asn1",
"product": "OTP",
"programFiles": [
"src/asn1rtt_ber.erl",
"src/asn1rtt_per_common.erl",
"src/asn1rtt_jer.erl"
],
"programRoutines": [
{
"name": "asn1rtt_ber:dec_subidentifiers/3"
},
{
"name": "asn1rtt_per_common:dec_subidentifiers/3"
},
{
"name": "asn1rtt_jer:json2oid/1"
}
],
"repo": "https://github.com/erlang/otp",
"vendor": "Erlang",
"versions": [
{
"changes": [
{
"at": "5.3.4.3",
"status": "unaffected"
},
{
"at": "5.4.3.1",
"status": "unaffected"
},
{
"at": "5.5.2",
"status": "unaffected"
}
],
"lessThan": "*",
"status": "affected",
"version": "3.0",
"versionType": "otp"
}
]
},
{
"collectionURL": "https://github.com",
"cpes": [
"cpe:2.3:a:erlang:erlang\\/otp:*:*:*:*:*:*:*:*"
],
"defaultStatus": "unknown",
"modules": [
"asn1rtt_ber",
"asn1rtt_per_common",
"asn1rtt_jer"
],
"packageName": "erlang/otp",
"packageURL": "pkg:github/erlang/otp",
"product": "OTP",
"programFiles": [
"lib/asn1/src/asn1rtt_ber.erl",
"lib/asn1/src/asn1rtt_per_common.erl",
"lib/asn1/src/asn1rtt_jer.erl"
],
"programRoutines": [
{
"name": "asn1rtt_ber:dec_subidentifiers/3"
},
{
"name": "asn1rtt_per_common:dec_subidentifiers/3"
},
{
"name": "asn1rtt_jer:json2oid/1"
}
],
"repo": "https://github.com/erlang/otp",
"vendor": "Erlang",
"versions": [
{
"lessThan": "0fe2c02fdc06fab1c63be9db1a7456993d20f838",
"status": "affected",
"version": "84adefa331c4159d432d22840663c38f155cd4c1",
"versionType": "git"
},
{
"lessThan": "*",
"status": "unaffected",
"version": "0fe2c02fdc06fab1c63be9db1a7456993d20f838",
"versionType": "git"
}
]
}
],
"cpeApplicability": [
{
"nodes": [
{
"cpeMatch": [
{
"criteria": "cpe:2.3:a:erlang:erlang\\/otp:*:*:*:*:*:*:*:*",
"versionEndExcluding": "27.3.4.18",
"vulnerable": true
},
{
"criteria": "cpe:2.3:a:erlang:erlang\\/otp:*:*:*:*:*:*:*:*",
"versionEndExcluding": "28.5.0.7",
"versionStartIncluding": "28.0",
"vulnerable": true
},
{
"criteria": "cpe:2.3:a:erlang:erlang\\/otp:*:*:*:*:*:*:*:*",
"versionEndExcluding": "29.1.1",
"versionStartIncluding": "29.0",
"vulnerable": true
}
],
"negate": false,
"operator": "OR"
}
],
"operator": "AND"
}
],
"credits": [
{
"lang": "en",
"type": "reporter",
"value": "tynus2"
},
{
"lang": "en",
"type": "reporter",
"value": "Lukas Backstr\u00f6m"
},
{
"lang": "en",
"type": "remediation developer",
"value": "John H\u00f6gberg"
}
],
"datePublic": "2026-09-22T08:49:25.000Z",
"descriptions": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003eInefficient algorithmic complexity in the Erlang/OTP asn1 OBJECT IDENTIFIER decoder allows a remote unauthenticated attacker to cause denial of service by sending a crafted OID during the TLS handshake.\u003c/p\u003e\n\u003cp\u003eThe BER OID decoder \u003ccode\u003easn1rtt_ber:dec_subidentifiers/3\u003c/code\u003e in \u003ccode\u003elib/asn1/src/asn1rtt_ber.erl\u003c/code\u003e and the equivalent PER helper \u003ccode\u003easn1rtt_per_common:dec_subidentifiers/3\u003c/code\u003e in \u003ccode\u003elib/asn1/src/asn1rtt_per_common.erl\u003c/code\u003e accumulate a base-128 subidentifier into an unbounded integer using \u003ccode\u003e(Av bsl 7) + H\u003c/code\u003e per continuation byte. Each shift and addition on the growing accumulator is linear in the number of bits already accumulated, giving quadratic total work in the size of a single subidentifier. The JER helper \u003ccode\u003easn1rtt_jer:json2oid/1\u003c/code\u003e in \u003ccode\u003elib/asn1/src/asn1rtt_jer.erl\u003c/code\u003e exhibits the same class of unbounded-integer parsing when decoding a dot-separated OID from JSON. A DER-encoded OBJECT IDENTIFIER with one very large arc (approximately 262 KB of continuation bytes) consumes roughly 13 seconds of CPU on typical hardware.\u003c/p\u003e\n\u003cp\u003eThe vulnerable decoder is generated into every ASN.1 module that contains an OBJECT IDENTIFIER, including \u003ccode\u003eOTP-PUB-KEY\u003c/code\u003e which is reached during X.509 certificate parsing via \u003ccode\u003epublic_key:pkix_decode_cert/2\u003c/code\u003e. This decoder runs before any signature or trust chain verification, so any Erlang service that parses peer TLS certificates is exposed: the default for TLS clients (which always parse the server certificate) and for mutual-TLS servers (which parse client certificates).\u003c/p\u003e\n\u003cp\u003eThis vulnerability is associated with program files \u003ccode\u003elib/asn1/src/asn1rtt_ber.erl\u003c/code\u003e, \u003ccode\u003elib/asn1/src/asn1rtt_per_common.erl\u003c/code\u003e and \u003ccode\u003elib/asn1/src/asn1rtt_jer.erl\u003c/code\u003e and program routines \u003ccode\u003easn1rtt_ber:dec_subidentifiers/3\u003c/code\u003e, \u003ccode\u003easn1rtt_per_common:dec_subidentifiers/3\u003c/code\u003e and \u003ccode\u003easn1rtt_jer:json2oid/1\u003c/code\u003e.\u003c/p\u003e\n\u003cp\u003eThis issue affects OTP from OTP\u0026nbsp;17.0 before OTP\u0026nbsp;27.3.4.18, OTP\u0026nbsp;28.5.0.7, and OTP\u0026nbsp;29.1.1, corresponding to asn1 from 3.0 before 5.3.4.3, 5.4.3.1, and 5.5.2. Whether OTP before OTP\u0026nbsp;17.0, corresponding to asn1 before 3.0, is affected is unknown.\u003c/p\u003e"
},
{
"base64": false,
"type": "text/markdown",
"value": "Inefficient algorithmic complexity in the Erlang/OTP asn1 OBJECT IDENTIFIER decoder allows a remote unauthenticated attacker to cause denial of service by sending a crafted OID during the TLS handshake.\n\nThe BER OID decoder `asn1rtt_ber:dec_subidentifiers/3` in `lib/asn1/src/asn1rtt_ber.erl` and the equivalent PER helper `asn1rtt_per_common:dec_subidentifiers/3` in `lib/asn1/src/asn1rtt_per_common.erl` accumulate a base-128 subidentifier into an unbounded integer using `(Av bsl 7) + H` per continuation byte. Each shift and addition on the growing accumulator is linear in the number of bits already accumulated, giving quadratic total work in the size of a single subidentifier. The JER helper `asn1rtt_jer:json2oid/1` in `lib/asn1/src/asn1rtt_jer.erl` exhibits the same class of unbounded-integer parsing when decoding a dot-separated OID from JSON. A DER-encoded OBJECT IDENTIFIER with one very large arc (approximately 262 KB of continuation bytes) consumes roughly 13 seconds of CPU on typical hardware.\n\nThe vulnerable decoder is generated into every ASN.1 module that contains an OBJECT IDENTIFIER, including `OTP-PUB-KEY` which is reached during X.509 certificate parsing via `public_key:pkix_decode_cert/2`. This decoder runs before any signature or trust chain verification, so any Erlang service that parses peer TLS certificates is exposed: the default for TLS clients (which always parse the server certificate) and for mutual-TLS servers (which parse client certificates).\n\nThis vulnerability is associated with program files `lib/asn1/src/asn1rtt_ber.erl`, `lib/asn1/src/asn1rtt_per_common.erl` and `lib/asn1/src/asn1rtt_jer.erl` and program routines `asn1rtt_ber:dec_subidentifiers/3`, `asn1rtt_per_common:dec_subidentifiers/3` and `asn1rtt_jer:json2oid/1`.\n\nThis issue affects OTP from OTP\u00a017.0 before OTP\u00a027.3.4.18, OTP\u00a028.5.0.7, and OTP\u00a029.1.1, corresponding to asn1 from 3.0 before 5.3.4.3, 5.4.3.1, and 5.5.2. Whether OTP before OTP\u00a017.0, corresponding to asn1 before 3.0, is affected is unknown."
}
],
"value": "Inefficient algorithmic complexity in the Erlang/OTP asn1 OBJECT IDENTIFIER decoder allows a remote unauthenticated attacker to cause denial of service by sending a crafted OID during the TLS handshake.\n\nThe BER OID decoder asn1rtt_ber:dec_subidentifiers/3 in lib/asn1/src/asn1rtt_ber.erl and the equivalent PER helper asn1rtt_per_common:dec_subidentifiers/3 in lib/asn1/src/asn1rtt_per_common.erl accumulate a base-128 subidentifier into an unbounded integer using (Av bsl 7) + H per continuation byte. Each shift and addition on the growing accumulator is linear in the number of bits already accumulated, giving quadratic total work in the size of a single subidentifier. The JER helper asn1rtt_jer:json2oid/1 in lib/asn1/src/asn1rtt_jer.erl exhibits the same class of unbounded-integer parsing when decoding a dot-separated OID from JSON. A DER-encoded OBJECT IDENTIFIER with one very large arc (approximately 262 KB of continuation bytes) consumes roughly 13 seconds of CPU on typical hardware.\n\nThe vulnerable decoder is generated into every ASN.1 module that contains an OBJECT IDENTIFIER, including OTP-PUB-KEY which is reached during X.509 certificate parsing via public_key:pkix_decode_cert/2. This decoder runs before any signature or trust chain verification, so any Erlang service that parses peer TLS certificates is exposed: the default for TLS clients (which always parse the server certificate) and for mutual-TLS servers (which parse client certificates).\n\nThis vulnerability is associated with program files lib/asn1/src/asn1rtt_ber.erl, lib/asn1/src/asn1rtt_per_common.erl and lib/asn1/src/asn1rtt_jer.erl and program routines asn1rtt_ber:dec_subidentifiers/3, asn1rtt_per_common:dec_subidentifiers/3 and asn1rtt_jer:json2oid/1.\n\nThis issue affects OTP from OTP\u00a017.0 before OTP\u00a027.3.4.18, OTP\u00a028.5.0.7, and OTP\u00a029.1.1, corresponding to asn1 from 3.0 before 5.3.4.3, 5.4.3.1, and 5.5.2. Whether OTP before OTP\u00a017.0, corresponding to asn1 before 3.0, is affected is unknown."
}
],
"impacts": [
{
"capecId": "CAPEC-229",
"descriptions": [
{
"lang": "en",
"value": "CAPEC-229 Serialized Data Parameter Blowup"
}
]
}
],
"metrics": [
{
"cvssV4_0": {
"Automatable": "NOT_DEFINED",
"Recovery": "NOT_DEFINED",
"Safety": "NOT_DEFINED",
"attackComplexity": "LOW",
"attackRequirements": "PRESENT",
"attackVector": "NETWORK",
"baseScore": 8.2,
"baseSeverity": "HIGH",
"privilegesRequired": "NONE",
"providerUrgency": "NOT_DEFINED",
"subAvailabilityImpact": "NONE",
"subConfidentialityImpact": "NONE",
"subIntegrityImpact": "NONE",
"userInteraction": "NONE",
"valueDensity": "NOT_DEFINED",
"vectorString": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N",
"version": "4.0",
"vulnAvailabilityImpact": "HIGH",
"vulnConfidentialityImpact": "NONE",
"vulnIntegrityImpact": "NONE",
"vulnerabilityResponseEffort": "NOT_DEFINED"
},
"format": "CVSS",
"scenarios": [
{
"lang": "en",
"value": "GENERAL"
}
]
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-407",
"description": "CWE-407 Inefficient Algorithmic Complexity",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-09-24T20:06:38.007Z",
"orgId": "6b3ad84c-e1a6-4bf7-a703-f496b71e49db",
"shortName": "EEF"
},
"references": [
{
"name": "GitHub Advisory",
"tags": [
"related",
"vendor-advisory"
],
"url": "https://github.com/erlang/otp/security/advisories/GHSA-qghx-23m5-r55m"
},
{
"name": "EEF CNA record for CVE-2026-65634",
"tags": [
"related"
],
"url": "https://cna.erlef.org/cves/CVE-2026-65634.html"
},
{
"name": "OSV record EEF-CVE-2026-65634",
"tags": [
"related"
],
"url": "https://osv.dev/vulnerability/EEF-CVE-2026-65634"
},
{
"name": "Erlang/OTP version ordering",
"tags": [
"x_version-scheme"
],
"url": "https://www.erlang.org/doc/system/versions.html#order-of-versions"
},
{
"name": "Fix commit 0fe2c02 in erlang/otp",
"tags": [
"patch"
],
"url": "https://github.com/erlang/otp/commit/0fe2c02fdc06fab1c63be9db1a7456993d20f838"
}
],
"source": {
"discovery": "EXTERNAL"
},
"title": "Superlinear CPU denial of service in Erlang/OTP ASN.1 OBJECT IDENTIFIER decoder"
}
},
"cveMetadata": {
"assignerOrgId": "6b3ad84c-e1a6-4bf7-a703-f496b71e49db",
"assignerShortName": "EEF",
"cveId": "CVE-2026-65634",
"datePublished": "2026-09-22T08:49:24.743Z",
"dateReserved": "2026-07-22T13:58:26.233Z",
"dateUpdated": "2026-09-24T20:06:38.007Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
CVE-2026-68956 (GCVE-0-2026-68956)
Vulnerability from cvelistv5 – Published: 2026-09-22 08:49 – Updated: 2026-09-24 20:07
VLAI
EPSS
VEX
Title
SSH daemon allocates unbounded idle session channels, bypassing max_channels
Summary
Allocation of Resources Without Limits or Throttling vulnerability in Erlang/OTP ssh allows an authenticated remote attacker to exhaust node memory by repeatedly opening session channels that are never assigned a handler.
The "session" clause of ssh_connection:handle_msg/4 checks only minimal_remote_max_packet_size before calling setup_session/5, which unconditionally builds a #channel{} record and stores it in the ETS channel cache. The max_channels daemon option is consulted only by ssh_channel_sup:max_num_channels_not_exceeded/2, which counts supervisor children, so a channel that never gets a shell, exec, or subsystem handler is invisible to the limit and setting the option to a finite value does not mitigate the attack. RFC 4254 section 5.1 permits many session channels per connection, and each record costs only a few hundred bytes, so a single authenticated connection can accumulate channels until the node runs out of memory and the emulator terminates, affecting every application on it. No file contents, credentials, or write access are obtainable.
This issue affects OTP from OTP 18.1.2 before OTP 27.3.4.18, OTP 28.5.0.7, and OTP 29.1.1, corresponding to ssh from 4.1.1 before 5.2.11.13, 5.5.2.6, and 6.0.6. Whether OTP before OTP 18.1.2, corresponding to ssh before 4.1.1, is affected is unknown.
Severity
SSVC
Exploitation: none
Automatable: no
Technical Impact: partial
CISA Coordinator · CISA-ADP (v2.0.3)
Decision recorded 2026-09-22 10:12 UTC
CWE
- CWE-770 - Allocation of Resources Without Limits or Throttling
Assigner
References
8 references
Impacted products
3 products
| Vendor | Product | Version | |
|---|---|---|---|
| Erlang | OTP |
Affected:
18.1.2 , < *
(otp)
cpe:2.3:a:erlang:erlang\/otp:*:*:*:*:*:*:*:* |
|
| Erlang | OTP |
Affected:
4.1.1 , < *
(otp)
cpe:2.3:a:erlang:erlang\/otp:*:*:*:*:*:*:*:* |
|
| Erlang | OTP |
Affected:
84df3d4d0278e21a36a453bfee94799f0df67c2a , < *
(git)
Unaffected: 79c2d2be17d902c5f53969b5806b725efda831be , < * (git) Unaffected: e18100975f0e5a8d59d02de00df12247a91b443b , < * (git) Unaffected: e2bbad0107bba41491a4d549686fd023db8740da , < * (git) cpe:2.3:a:erlang:erlang\/otp:*:*:*:*:*:*:*:* |
Date Public
2026-09-22 08:49
{
"containers": {
"adp": [
{
"metrics": [
{
"other": {
"content": {
"id": "CVE-2026-68956",
"options": [
{
"Exploitation": "none"
},
{
"Automatable": "no"
},
{
"Technical Impact": "partial"
}
],
"role": "CISA Coordinator",
"timestamp": "2026-09-22T10:12:21.867151Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"providerMetadata": {
"dateUpdated": "2026-09-22T10:25:30.750Z",
"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"shortName": "CISA-ADP"
},
"title": "CISA ADP Vulnrichment"
}
],
"cna": {
"affected": [
{
"cpes": [
"cpe:2.3:a:erlang:erlang\\/otp:*:*:*:*:*:*:*:*"
],
"defaultStatus": "unknown",
"modules": [
"ssh_connection",
"ssh_channel_sup"
],
"packageName": "otp",
"packageURL": "pkg:software-id/erlang.org/otp",
"product": "OTP",
"programFiles": [
"lib/ssh/src/ssh_connection.erl",
"lib/ssh/src/ssh_channel_sup.erl"
],
"programRoutines": [
{
"name": "ssh_connection:handle_msg/4"
},
{
"name": "ssh_connection:setup_session/5"
},
{
"name": "ssh_channel_sup:max_num_channels_not_exceeded/2"
}
],
"vendor": "Erlang",
"versions": [
{
"changes": [
{
"at": "27.3.4.18",
"status": "unaffected"
},
{
"at": "28.5.0.7",
"status": "unaffected"
},
{
"at": "29.1.1",
"status": "unaffected"
}
],
"lessThan": "*",
"status": "affected",
"version": "18.1.2",
"versionType": "otp"
}
]
},
{
"cpes": [
"cpe:2.3:a:erlang:erlang\\/otp:*:*:*:*:*:*:*:*"
],
"defaultStatus": "unknown",
"modules": [
"ssh_connection",
"ssh_channel_sup"
],
"packageName": "ssh",
"packageURL": "pkg:otp/ssh",
"product": "OTP",
"programFiles": [
"src/ssh_connection.erl",
"src/ssh_channel_sup.erl"
],
"programRoutines": [
{
"name": "ssh_connection:handle_msg/4"
},
{
"name": "ssh_connection:setup_session/5"
},
{
"name": "ssh_channel_sup:max_num_channels_not_exceeded/2"
}
],
"repo": "https://github.com/erlang/otp",
"vendor": "Erlang",
"versions": [
{
"changes": [
{
"at": "5.2.11.13",
"status": "unaffected"
},
{
"at": "5.5.2.6",
"status": "unaffected"
},
{
"at": "6.0.6",
"status": "unaffected"
}
],
"lessThan": "*",
"status": "affected",
"version": "4.1.1",
"versionType": "otp"
}
]
},
{
"collectionURL": "https://github.com",
"cpes": [
"cpe:2.3:a:erlang:erlang\\/otp:*:*:*:*:*:*:*:*"
],
"defaultStatus": "unknown",
"modules": [
"ssh_connection",
"ssh_channel_sup"
],
"packageName": "erlang/otp",
"packageURL": "pkg:github/erlang/otp",
"product": "OTP",
"programFiles": [
"lib/ssh/src/ssh_connection.erl",
"lib/ssh/src/ssh_channel_sup.erl"
],
"programRoutines": [
{
"name": "ssh_connection:handle_msg/4"
},
{
"name": "ssh_connection:setup_session/5"
},
{
"name": "ssh_channel_sup:max_num_channels_not_exceeded/2"
}
],
"repo": "https://github.com/erlang/otp",
"vendor": "Erlang",
"versions": [
{
"changes": [
{
"at": "79c2d2be17d902c5f53969b5806b725efda831be",
"status": "unaffected"
},
{
"at": "e18100975f0e5a8d59d02de00df12247a91b443b",
"status": "unaffected"
},
{
"at": "e2bbad0107bba41491a4d549686fd023db8740da",
"status": "unaffected"
}
],
"lessThan": "*",
"status": "affected",
"version": "84df3d4d0278e21a36a453bfee94799f0df67c2a",
"versionType": "git"
},
{
"lessThan": "*",
"status": "unaffected",
"version": "79c2d2be17d902c5f53969b5806b725efda831be",
"versionType": "git"
},
{
"lessThan": "*",
"status": "unaffected",
"version": "e18100975f0e5a8d59d02de00df12247a91b443b",
"versionType": "git"
},
{
"lessThan": "*",
"status": "unaffected",
"version": "e2bbad0107bba41491a4d549686fd023db8740da",
"versionType": "git"
}
]
}
],
"cpeApplicability": [
{
"nodes": [
{
"cpeMatch": [
{
"criteria": "cpe:2.3:a:erlang:erlang\\/otp:*:*:*:*:*:*:*:*",
"versionEndExcluding": "27.3.4.18",
"vulnerable": true
},
{
"criteria": "cpe:2.3:a:erlang:erlang\\/otp:*:*:*:*:*:*:*:*",
"versionEndExcluding": "28.5.0.7",
"versionStartIncluding": "28.0",
"vulnerable": true
},
{
"criteria": "cpe:2.3:a:erlang:erlang\\/otp:*:*:*:*:*:*:*:*",
"versionEndExcluding": "29.1.1",
"versionStartIncluding": "29.0",
"vulnerable": true
}
],
"negate": false,
"operator": "OR"
}
],
"operator": "AND"
}
],
"credits": [
{
"lang": "en",
"type": "remediation developer",
"value": "Micha\u0142 W\u0105sowski / Ericsson"
},
{
"lang": "en",
"type": "remediation reviewer",
"value": "Jakub Witczak / Ericsson"
}
],
"datePublic": "2026-09-22T08:49:22.000Z",
"descriptions": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003eAllocation of Resources Without Limits or Throttling vulnerability in Erlang/OTP ssh allows an authenticated remote attacker to exhaust node memory by repeatedly opening session channels that are never assigned a handler.\u003c/p\u003e\n\u003cp\u003eThe \u003ccode\u003e\"session\"\u003c/code\u003e clause of \u003ccode\u003essh_connection:handle_msg/4\u003c/code\u003e checks only \u003ccode\u003eminimal_remote_max_packet_size\u003c/code\u003e before calling \u003ccode\u003esetup_session/5\u003c/code\u003e, which unconditionally builds a \u003ccode\u003e#channel{}\u003c/code\u003e record and stores it in the ETS channel cache. The \u003ccode\u003emax_channels\u003c/code\u003e daemon option is consulted only by \u003ccode\u003essh_channel_sup:max_num_channels_not_exceeded/2\u003c/code\u003e, which counts supervisor children, so a channel that never gets a shell, exec, or subsystem handler is invisible to the limit and setting the option to a finite value does not mitigate the attack. RFC 4254 section 5.1 permits many session channels per connection, and each record costs only a few hundred bytes, so a single authenticated connection can accumulate channels until the node runs out of memory and the emulator terminates, affecting every application on it. No file contents, credentials, or write access are obtainable.\u003c/p\u003e\n\u003cp\u003eThis issue affects OTP from OTP\u0026nbsp;18.1.2 before OTP\u0026nbsp;27.3.4.18, OTP\u0026nbsp;28.5.0.7, and OTP\u0026nbsp;29.1.1, corresponding to ssh from 4.1.1 before 5.2.11.13, 5.5.2.6, and 6.0.6. Whether OTP before OTP\u0026nbsp;18.1.2, corresponding to ssh before 4.1.1, is affected is unknown.\u003c/p\u003e"
},
{
"base64": false,
"type": "text/markdown",
"value": "Allocation of Resources Without Limits or Throttling vulnerability in Erlang/OTP ssh allows an authenticated remote attacker to exhaust node memory by repeatedly opening session channels that are never assigned a handler.\n\nThe `\"session\"` clause of `ssh_connection:handle_msg/4` checks only `minimal_remote_max_packet_size` before calling `setup_session/5`, which unconditionally builds a `#channel{}` record and stores it in the ETS channel cache. The `max_channels` daemon option is consulted only by `ssh_channel_sup:max_num_channels_not_exceeded/2`, which counts supervisor children, so a channel that never gets a shell, exec, or subsystem handler is invisible to the limit and setting the option to a finite value does not mitigate the attack. RFC 4254 section 5.1 permits many session channels per connection, and each record costs only a few hundred bytes, so a single authenticated connection can accumulate channels until the node runs out of memory and the emulator terminates, affecting every application on it. No file contents, credentials, or write access are obtainable.\n\nThis issue affects OTP from OTP\u00a018.1.2 before OTP\u00a027.3.4.18, OTP\u00a028.5.0.7, and OTP\u00a029.1.1, corresponding to ssh from 4.1.1 before 5.2.11.13, 5.5.2.6, and 6.0.6. Whether OTP before OTP\u00a018.1.2, corresponding to ssh before 4.1.1, is affected is unknown."
}
],
"value": "Allocation of Resources Without Limits or Throttling vulnerability in Erlang/OTP ssh allows an authenticated remote attacker to exhaust node memory by repeatedly opening session channels that are never assigned a handler.\n\nThe \"session\" clause of ssh_connection:handle_msg/4 checks only minimal_remote_max_packet_size before calling setup_session/5, which unconditionally builds a #channel{} record and stores it in the ETS channel cache. The max_channels daemon option is consulted only by ssh_channel_sup:max_num_channels_not_exceeded/2, which counts supervisor children, so a channel that never gets a shell, exec, or subsystem handler is invisible to the limit and setting the option to a finite value does not mitigate the attack. RFC 4254 section 5.1 permits many session channels per connection, and each record costs only a few hundred bytes, so a single authenticated connection can accumulate channels until the node runs out of memory and the emulator terminates, affecting every application on it. No file contents, credentials, or write access are obtainable.\n\nThis issue affects OTP from OTP\u00a018.1.2 before OTP\u00a027.3.4.18, OTP\u00a028.5.0.7, and OTP\u00a029.1.1, corresponding to ssh from 4.1.1 before 5.2.11.13, 5.5.2.6, and 6.0.6. Whether OTP before OTP\u00a018.1.2, corresponding to ssh before 4.1.1, is affected is unknown."
}
],
"impacts": [
{
"capecId": "CAPEC-125",
"descriptions": [
{
"lang": "en",
"value": "CAPEC-125 Flooding"
}
]
}
],
"metrics": [
{
"cvssV4_0": {
"Automatable": "NOT_DEFINED",
"Recovery": "NOT_DEFINED",
"Safety": "NOT_DEFINED",
"attackComplexity": "LOW",
"attackRequirements": "NONE",
"attackVector": "NETWORK",
"baseScore": 7.1,
"baseSeverity": "HIGH",
"privilegesRequired": "LOW",
"providerUrgency": "NOT_DEFINED",
"subAvailabilityImpact": "NONE",
"subConfidentialityImpact": "NONE",
"subIntegrityImpact": "NONE",
"userInteraction": "NONE",
"valueDensity": "NOT_DEFINED",
"vectorString": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N",
"version": "4.0",
"vulnAvailabilityImpact": "HIGH",
"vulnConfidentialityImpact": "NONE",
"vulnIntegrityImpact": "NONE",
"vulnerabilityResponseEffort": "NOT_DEFINED"
},
"format": "CVSS",
"scenarios": [
{
"lang": "en",
"value": "GENERAL"
}
]
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-770",
"description": "CWE-770 Allocation of Resources Without Limits or Throttling",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-09-24T20:07:42.062Z",
"orgId": "6b3ad84c-e1a6-4bf7-a703-f496b71e49db",
"shortName": "EEF"
},
"references": [
{
"name": "GitHub Advisory",
"tags": [
"related",
"vendor-advisory"
],
"url": "https://github.com/erlang/otp/security/advisories/GHSA-qhcm-px9c-rvfh"
},
{
"name": "EEF CNA record for CVE-2026-68956",
"tags": [
"related"
],
"url": "https://cna.erlef.org/cves/CVE-2026-68956.html"
},
{
"name": "OSV record EEF-CVE-2026-68956",
"tags": [
"related"
],
"url": "https://osv.dev/vulnerability/EEF-CVE-2026-68956"
},
{
"name": "Erlang/OTP version ordering",
"tags": [
"x_version-scheme"
],
"url": "https://www.erlang.org/doc/system/versions.html#order-of-versions"
},
{
"name": "Introducing commit 84df3d4 in erlang/otp",
"tags": [
"related"
],
"url": "https://github.com/erlang/otp/commit/84df3d4d0278e21a36a453bfee94799f0df67c2a"
},
{
"name": "Fix commit 79c2d2b in erlang/otp",
"tags": [
"patch"
],
"url": "https://github.com/erlang/otp/commit/79c2d2be17d902c5f53969b5806b725efda831be"
},
{
"name": "Fix commit e181009 in erlang/otp",
"tags": [
"patch"
],
"url": "https://github.com/erlang/otp/commit/e18100975f0e5a8d59d02de00df12247a91b443b"
},
{
"name": "Fix commit e2bbad0 in erlang/otp",
"tags": [
"patch"
],
"url": "https://github.com/erlang/otp/commit/e2bbad0107bba41491a4d549686fd023db8740da"
}
],
"source": {
"discovery": "INTERNAL"
},
"title": "SSH daemon allocates unbounded idle session channels, bypassing max_channels",
"workarounds": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003eNo option bounds the number of idle session channels, so the following reduce exposure without eliminating the issue.\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003eRestrict network access to the SSH daemon to trusted clients. Exploitation requires a successfully authenticated session, so limiting who can authenticate is the most effective control available.\u003c/li\u003e\n\u003cli\u003eSet the \u003ccode\u003emax_sessions\u003c/code\u003e daemon option to a finite value to bound the number of concurrent connections. This limits how many connections can mount the attack in parallel, though a single connection still suffices to exhaust memory.\u003c/li\u003e\n\u003cli\u003eApply operating-system or firewall connection-rate and connection-count limits per source address.\u003c/li\u003e\n\u003cli\u003eMonitor node memory externally and restart the emulator when it exceeds a threshold.\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003eSetting \u003ccode\u003emax_channels\u003c/code\u003e is not a workaround: idle session channels bypass that check entirely.\u003c/p\u003e"
},
{
"base64": false,
"type": "text/markdown",
"value": "No option bounds the number of idle session channels, so the following reduce exposure without eliminating the issue.\n\n* Restrict network access to the SSH daemon to trusted clients. Exploitation requires a successfully authenticated session, so limiting who can authenticate is the most effective control available.\n* Set the `max_sessions` daemon option to a finite value to bound the number of concurrent connections. This limits how many connections can mount the attack in parallel, though a single connection still suffices to exhaust memory.\n* Apply operating-system or firewall connection-rate and connection-count limits per source address.\n* Monitor node memory externally and restart the emulator when it exceeds a threshold.\n\nSetting `max_channels` is not a workaround: idle session channels bypass that check entirely."
}
],
"value": "No option bounds the number of idle session channels, so the following reduce exposure without eliminating the issue.\n\n* Restrict network access to the SSH daemon to trusted clients. Exploitation requires a successfully authenticated session, so limiting who can authenticate is the most effective control available.\n* Set the max_sessions daemon option to a finite value to bound the number of concurrent connections. This limits how many connections can mount the attack in parallel, though a single connection still suffices to exhaust memory.\n* Apply operating-system or firewall connection-rate and connection-count limits per source address.\n* Monitor node memory externally and restart the emulator when it exceeds a threshold.\n\nSetting max_channels is not a workaround: idle session channels bypass that check entirely."
}
]
}
},
"cveMetadata": {
"assignerOrgId": "6b3ad84c-e1a6-4bf7-a703-f496b71e49db",
"assignerShortName": "EEF",
"cveId": "CVE-2026-68956",
"datePublished": "2026-09-22T08:49:21.760Z",
"dateReserved": "2026-08-17T13:30:02.155Z",
"dateUpdated": "2026-09-24T20:07:42.062Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}