erlang-hex — security advisory
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 verificat
- Products
- erlang-hex
- Affected versions
- 2.0.6-2, 2.4.2-1, 2.4.2-2, 2.5.1-1, 2.5.1-2, 2.5.3-1, 2.5.3-2
- Fixed versions
- 2.5.3-2
- CVEs
- CVE-2026-103502
- Confirmed fixed CVEs
- Not specified
- Updated in this feed
- 31 Oct 2026, 22:43 UTC · Revision 1
Source evidence
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 verificat
osv:DEBIAN-CVE-2026-103502
erlang-hex
Fixed versions: Not specified
erlang-hex
Fixed versions: 2.5.3-2
Complete source record
{
"id": "b863e1475665c6ae5c2093e9002e09001883e9d189d77284a4c74d40f7b5e371",
"url": "https://osv.dev/vulnerability/DEBIAN-CVE-2026-103502",
"method": "structured",
"payload": {
"kind": "advisory",
"title": "DEBIAN-CVE-2026-103502",
"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 verificat",
"evidence": "osv:DEBIAN-CVE-2026-103502",
"products": [
{
"name": {
"value": "erlang-hex",
"evidence": "/affected/0/package/name"
},
"prerequisites": [],
"fixed_versions": [],
"affected_versions": [
{
"value": "2.0.6-2",
"evidence": "/affected/0/versions"
},
{
"value": "2.4.2-1",
"evidence": "/affected/0/versions"
},
{
"value": "2.4.2-2",
"evidence": "/affected/0/versions"
},
{
"value": "2.5.1-1",
"evidence": "/affected/0/versions"
},
{
"value": "2.5.1-2",
"evidence": "/affected/0/versions"
},
{
"value": "2.5.3-1",
"evidence": "/affected/0/versions"
},
{
"value": "2.5.3-2",
"evidence": "/affected/0/versions"
}
]
},
{
"name": {
"value": "erlang-hex",
"evidence": "/affected/1/package/name"
},
"prerequisites": [],
"fixed_versions": [
{
"value": "2.5.3-2",
"evidence": "/affected/1/ranges"
}
],
"affected_versions": [
{
"value": "2.0.6-2",
"evidence": "/affected/1/versions"
},
{
"value": "2.4.2-1",
"evidence": "/affected/1/versions"
},
{
"value": "2.4.2-2",
"evidence": "/affected/1/versions"
},
{
"value": "2.5.1-1",
"evidence": "/affected/1/versions"
},
{
"value": "2.5.1-2",
"evidence": "/affected/1/versions"
},
{
"value": "2.5.3-1",
"evidence": "/affected/1/versions"
}
]
}
],
"severity": "medium",
"structured": {
"id": "DEBIAN-CVE-2026-103502",
"aliases": [
"DEBIAN-CVE-2026-103502"
],
"metrics": [
{
"type": "CVSS_V4",
"score": "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/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X"
}
],
"affected": [
{
"ranges": [
{
"type": "ECOSYSTEM",
"events": [
{
"introduced": "0"
}
]
}
],
"package": {
"name": "erlang-hex",
"purl": "pkg:deb/debian/erlang-hex?arch=source&distro=trixie",
"ecosystem": "Debian:13"
},
"versions": [
"2.0.6-2",
"2.4.2-1",
"2.4.2-2",
"2.5.1-1",
"2.5.1-2",
"2.5.3-1",
"2.5.3-2"
],
"database_specific": {
"source": "https://storage.googleapis.com/debian-osv/debian-cve-osv/DEBIAN-CVE-2026-103502.json"
},
"ecosystem_specific": {
"urgency": "unimportant"
}
},
{
"ranges": [
{
"type": "ECOSYSTEM",
"events": [
{
"introduced": "0"
},
{
"fixed": "2.5.3-2"
}
]
}
],
"package": {
"name": "erlang-hex",
"purl": "pkg:deb/debian/erlang-hex?arch=source&distro=forky",
"ecosystem": "Debian:14"
},
"versions": [
"2.0.6-2",
"2.4.2-1",
"2.4.2-2",
"2.5.1-1",
"2.5.1-2",
"2.5.3-1"
],
"database_specific": {
"source": "https://storage.googleapis.com/debian-osv/debian-cve-osv/DEBIAN-CVE-2026-103502.json"
},
"ecosystem_specific": {
"urgency": "unimportant"
}
}
],
"modified": "2026-10-23T17:47:28.961671429Z",
"provider": "osv",
"upstream": [
"CVE-2026-103502"
],
"references": [
"https://security-tracker.debian.org/tracker/CVE-2026-103502"
]
},
"related_cves": [
{
"value": "CVE-2026-103502",
"evidence": "/upstream"
}
],
"security_relevant": true,
"severity_evidence": "/severity/0/score"
},
"source_id": "core-osv",
"document_id": 417168,
"published_at": "2026-10-12T14:17:08.61+00:00"
}