Search
Find a vulnerability
Search criteria
317 vulnerabilities
CVE-2026-94194 (GCVE-0-2026-94194)
Vulnerability from cvelistv5 – Published: 2026-09-28 11:15 – Updated: 2026-09-29 10:16
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
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": {
"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-29T10:16:39.032Z",
"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-29 10:15
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
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": {
"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-29T10:15:35.604Z",
"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"
}
CVE-2026-89422 (GCVE-0-2026-89422)
Vulnerability from cvelistv5 – Published: 2026-09-22 08:49 – Updated: 2026-09-22 13:08
VLAI
EPSS
VEX
Title
TLS 1.3 client skips server authentication when ServerHello carries an unsolicited pre_shared_key extension
Summary
Key Exchange without Entity Authentication vulnerability in Erlang/OTP ssl allows a peer that answers a TLS 1.3 client connection to impersonate the intended server. A pre_shared_key extension in the ServerHello that the client never offered causes the client to complete the handshake without validating the server's certificate, so ssl:connect returns {ok, Socket} against a peer holding no certificate, no private key and no prior session.
tls_client_connection_1_3:handle_server_hello/2 passes the received extension to tls_gen_connection_1_3:handle_resumption/2, which sets resumption = true on its mere presence without checking that the client offered a PSK. tls_handshake_1_3:get_pre_shared_key/4 meanwhile falls back to the all-zero "no PSK" value and keys the handshake with the ordinary non-PSK schedule, so the attacker's own ephemeral key suffices. The resumption flag then routes maybe_resumption/1 straight to wait_finished, skipping the certificate-handling states, so certificate path validation, verify_fun, hostname verification, partial_chain, CRL checking and OCSP stapling are all bypassed. The default client configuration is affected; clients restricted to TLS 1.2 are not.
This issue affects OTP from OTP 22.2 before OTP 27.3.4.18, OTP 28.5.0.7, and OTP 29.1.1, corresponding to ssl from 9.5 before 11.2.12.13, 11.6.0.6, and 11.7.7.
Severity
SSVC
Exploitation: none
Automatable: yes
Technical Impact: total
CISA Coordinator · CISA-ADP (v2.0.3)
Decision recorded 2026-09-22 13:08 UTC
CWE
- CWE-322 - Key Exchange without Entity Authentication
Assigner
References
8 references
Impacted products
3 products
| Vendor | Product | Version | |
|---|---|---|---|
| Erlang | OTP |
Affected:
22.2 , < *
(otp)
cpe:2.3:a:erlang:erlang\/otp:*:*:*:*:*:*:*:* |
|
| Erlang | OTP |
Affected:
9.5 , < *
(otp)
cpe:2.3:a:erlang:erlang\/otp:*:*:*:*:*:*:*:* |
|
| Erlang | OTP |
Affected:
21b8a1b0ad0adf200682b3854bc50114ab2b8c62 , < *
(git)
cpe:2.3:a:erlang:erlang\/otp:*:*:*:*:*:*:*:* |
{
"containers": {
"adp": [
{
"metrics": [
{
"other": {
"content": {
"id": "CVE-2026-89422",
"options": [
{
"Exploitation": "none"
},
{
"Automatable": "yes"
},
{
"Technical Impact": "total"
}
],
"role": "CISA Coordinator",
"timestamp": "2026-09-22T13:08:04.474621Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"providerMetadata": {
"dateUpdated": "2026-09-22T13:08:15.912Z",
"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"shortName": "CISA-ADP"
},
"title": "CISA ADP Vulnrichment"
}
],
"cna": {
"affected": [
{
"cpes": [
"cpe:2.3:a:erlang:erlang\\/otp:*:*:*:*:*:*:*:*"
],
"defaultStatus": "unaffected",
"modules": [
"tls_client_connection_1_3",
"tls_gen_connection_1_3",
"tls_handshake_1_3"
],
"packageName": "otp",
"packageURL": "pkg:software-id/erlang.org/otp",
"product": "OTP",
"programFiles": [
"lib/ssl/src/tls_client_connection_1_3.erl",
"lib/ssl/src/tls_gen_connection_1_3.erl",
"lib/ssl/src/tls_handshake_1_3.erl"
],
"programRoutines": [
{
"name": "tls_client_connection_1_3:handle_server_hello/2"
},
{
"name": "tls_client_connection_1_3:handle_encrypted_extensions/2"
},
{
"name": "tls_client_connection_1_3:maybe_resumption/1"
},
{
"name": "tls_gen_connection_1_3:handle_resumption/2"
},
{
"name": "tls_handshake_1_3:get_pre_shared_key/4"
}
],
"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": "22.2",
"versionType": "otp"
}
]
},
{
"cpes": [
"cpe:2.3:a:erlang:erlang\\/otp:*:*:*:*:*:*:*:*"
],
"defaultStatus": "unaffected",
"modules": [
"tls_client_connection_1_3",
"tls_gen_connection_1_3",
"tls_handshake_1_3"
],
"packageName": "ssl",
"packageURL": "pkg:otp/ssl?repository_url=https:%2F%2Fgithub.com%2Ferlang%2Fotp\u0026vcs_url=git%2Bhttps:%2F%2Fgithub.com%2Ferlang%2Fotp.git",
"product": "OTP",
"programFiles": [
"src/tls_client_connection_1_3.erl",
"src/tls_gen_connection_1_3.erl",
"src/tls_handshake_1_3.erl"
],
"programRoutines": [
{
"name": "tls_client_connection_1_3:handle_server_hello/2"
},
{
"name": "tls_client_connection_1_3:handle_encrypted_extensions/2"
},
{
"name": "tls_client_connection_1_3:maybe_resumption/1"
},
{
"name": "tls_gen_connection_1_3:handle_resumption/2"
},
{
"name": "tls_handshake_1_3:get_pre_shared_key/4"
}
],
"repo": "https://github.com/erlang/otp",
"vendor": "Erlang",
"versions": [
{
"changes": [
{
"at": "11.2.12.13",
"status": "unaffected"
},
{
"at": "11.6.0.6",
"status": "unaffected"
},
{
"at": "11.7.7",
"status": "unaffected"
}
],
"lessThan": "*",
"status": "affected",
"version": "9.5",
"versionType": "otp"
}
]
},
{
"collectionURL": "https://github.com",
"cpes": [
"cpe:2.3:a:erlang:erlang\\/otp:*:*:*:*:*:*:*:*"
],
"defaultStatus": "unaffected",
"modules": [
"tls_client_connection_1_3",
"tls_gen_connection_1_3",
"tls_handshake_1_3"
],
"packageName": "erlang/otp",
"packageURL": "pkg:github/erlang/otp",
"product": "OTP",
"programFiles": [
"lib/ssl/src/tls_client_connection_1_3.erl",
"lib/ssl/src/tls_gen_connection_1_3.erl",
"lib/ssl/src/tls_handshake_1_3.erl"
],
"programRoutines": [
{
"name": "tls_client_connection_1_3:handle_server_hello/2"
},
{
"name": "tls_client_connection_1_3:handle_encrypted_extensions/2"
},
{
"name": "tls_client_connection_1_3:maybe_resumption/1"
},
{
"name": "tls_gen_connection_1_3:handle_resumption/2"
},
{
"name": "tls_handshake_1_3:get_pre_shared_key/4"
}
],
"repo": "https://github.com/erlang/otp",
"vendor": "Erlang",
"versions": [
{
"changes": [
{
"at": "afec5156361bb50d3607c7c1a453c19b9149b324",
"status": "unaffected"
},
{
"at": "98c66c858113949c4262d26cd7d426c4b09d2b35",
"status": "unaffected"
},
{
"at": "fd1d9d07fc92ec0d59f96dfb66182195882bb7dd",
"status": "unaffected"
}
],
"lessThan": "*",
"status": "affected",
"version": "21b8a1b0ad0adf200682b3854bc50114ab2b8c62",
"versionType": "git"
}
]
}
],
"cpeApplicability": [
{
"nodes": [
{
"cpeMatch": [
{
"criteria": "cpe:2.3:a:erlang:erlang\\/otp:*:*:*:*:*:*:*:*",
"versionEndExcluding": "27.3.4.18",
"versionStartIncluding": "22.2",
"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": "finder",
"value": "Milad Nasr / Anthropic"
},
{
"lang": "en",
"type": "finder",
"value": "Luna Tong / Anthropic"
},
{
"lang": "en",
"type": "remediation developer",
"value": "Ingela Andin"
}
],
"dateAssigned": "2026-09-16T10:27:13.000Z",
"descriptions": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003eKey Exchange without Entity Authentication vulnerability in Erlang/OTP ssl allows a peer that answers a TLS 1.3 client connection to impersonate the intended server. A \u003ccode\u003epre_shared_key\u003c/code\u003e extension in the \u003ccode\u003eServerHello\u003c/code\u003e that the client never offered causes the client to complete the handshake without validating the server\u0027s certificate, so \u003ccode\u003essl:connect\u003c/code\u003e returns \u003ccode\u003e{ok, Socket}\u003c/code\u003e against a peer holding no certificate, no private key and no prior session.\u003c/p\u003e\n\u003cp\u003e\u003ccode\u003etls_client_connection_1_3:handle_server_hello/2\u003c/code\u003e passes the received extension to \u003ccode\u003etls_gen_connection_1_3:handle_resumption/2\u003c/code\u003e, which sets \u003ccode\u003eresumption = true\u003c/code\u003e on its mere presence without checking that the client offered a PSK. \u003ccode\u003etls_handshake_1_3:get_pre_shared_key/4\u003c/code\u003e meanwhile falls back to the all-zero \"no PSK\" value and keys the handshake with the ordinary non-PSK schedule, so the attacker\u0027s own ephemeral key suffices. The resumption flag then routes \u003ccode\u003emaybe_resumption/1\u003c/code\u003e straight to \u003ccode\u003ewait_finished\u003c/code\u003e, skipping the certificate-handling states, so certificate path validation, \u003ccode\u003everify_fun\u003c/code\u003e, hostname verification, \u003ccode\u003epartial_chain\u003c/code\u003e, CRL checking and OCSP stapling are all bypassed. The default client configuration is affected; clients restricted to TLS 1.2 are not.\u003c/p\u003e\n\u003cp\u003eThis issue affects OTP from OTP\u0026nbsp;22.2 before OTP\u0026nbsp;27.3.4.18, OTP\u0026nbsp;28.5.0.7, and OTP\u0026nbsp;29.1.1, corresponding to ssl from 9.5 before 11.2.12.13, 11.6.0.6, and 11.7.7.\u003c/p\u003e"
},
{
"base64": false,
"type": "text/markdown",
"value": "Key Exchange without Entity Authentication vulnerability in Erlang/OTP ssl allows a peer that answers a TLS 1.3 client connection to impersonate the intended server. A `pre_shared_key` extension in the `ServerHello` that the client never offered causes the client to complete the handshake without validating the server\u0027s certificate, so `ssl:connect` returns `{ok, Socket}` against a peer holding no certificate, no private key and no prior session.\n\n`tls_client_connection_1_3:handle_server_hello/2` passes the received extension to `tls_gen_connection_1_3:handle_resumption/2`, which sets `resumption = true` on its mere presence without checking that the client offered a PSK. `tls_handshake_1_3:get_pre_shared_key/4` meanwhile falls back to the all-zero \"no PSK\" value and keys the handshake with the ordinary non-PSK schedule, so the attacker\u0027s own ephemeral key suffices. The resumption flag then routes `maybe_resumption/1` straight to `wait_finished`, skipping the certificate-handling states, so certificate path validation, `verify_fun`, hostname verification, `partial_chain`, CRL checking and OCSP stapling are all bypassed. The default client configuration is affected; clients restricted to TLS 1.2 are not.\n\nThis issue affects OTP from OTP\u00a022.2 before OTP\u00a027.3.4.18, OTP\u00a028.5.0.7, and OTP\u00a029.1.1, corresponding to ssl from 9.5 before 11.2.12.13, 11.6.0.6, and 11.7.7."
}
],
"value": "Key Exchange without Entity Authentication vulnerability in Erlang/OTP ssl allows a peer that answers a TLS 1.3 client connection to impersonate the intended server. A pre_shared_key extension in the ServerHello that the client never offered causes the client to complete the handshake without validating the server\u0027s certificate, so ssl:connect returns {ok, Socket} against a peer holding no certificate, no private key and no prior session.\n\ntls_client_connection_1_3:handle_server_hello/2 passes the received extension to tls_gen_connection_1_3:handle_resumption/2, which sets resumption = true on its mere presence without checking that the client offered a PSK. tls_handshake_1_3:get_pre_shared_key/4 meanwhile falls back to the all-zero \"no PSK\" value and keys the handshake with the ordinary non-PSK schedule, so the attacker\u0027s own ephemeral key suffices. The resumption flag then routes maybe_resumption/1 straight to wait_finished, skipping the certificate-handling states, so certificate path validation, verify_fun, hostname verification, partial_chain, CRL checking and OCSP stapling are all bypassed. The default client configuration is affected; clients restricted to TLS 1.2 are not.\n\nThis issue affects OTP from OTP\u00a022.2 before OTP\u00a027.3.4.18, OTP\u00a028.5.0.7, and OTP\u00a029.1.1, corresponding to ssl from 9.5 before 11.2.12.13, 11.6.0.6, and 11.7.7."
}
],
"impacts": [
{
"capecId": "CAPEC-94",
"descriptions": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003eAn attacker that answers a TLS 1.3 client connection, either as the host the client dials or as an on-path attacker, completes the handshake as the intended server and holds all traffic keys. It can read everything the application sends, including credentials, tokens and request bodies, and forge every response. Any consumer of \u003ccode\u003essl:connect\u003c/code\u003e that negotiates TLS 1.3 is affected, including \u003ccode\u003ehttpc\u003c/code\u003e over HTTPS, database and messaging client libraries, and TLS distribution clients.\u003c/p\u003e"
},
{
"base64": false,
"type": "text/markdown",
"value": "An attacker that answers a TLS 1.3 client connection, either as the host the client dials or as an on-path attacker, completes the handshake as the intended server and holds all traffic keys. It can read everything the application sends, including credentials, tokens and request bodies, and forge every response. Any consumer of `ssl:connect` that negotiates TLS 1.3 is affected, including `httpc` over HTTPS, database and messaging client libraries, and TLS distribution clients."
}
],
"value": "An attacker that answers a TLS 1.3 client connection, either as the host the client dials or as an on-path attacker, completes the handshake as the intended server and holds all traffic keys. It can read everything the application sends, including credentials, tokens and request bodies, and forge every response. Any consumer of ssl:connect that negotiates TLS 1.3 is affected, including httpc over HTTPS, database and messaging client libraries, and TLS distribution clients."
}
]
}
],
"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": "NONE",
"subIntegrityImpact": "NONE",
"userInteraction": "NONE",
"valueDensity": "NOT_DEFINED",
"vectorString": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N",
"version": "4.0",
"vulnAvailabilityImpact": "NONE",
"vulnConfidentialityImpact": "HIGH",
"vulnIntegrityImpact": "HIGH",
"vulnerabilityResponseEffort": "NOT_DEFINED"
},
"format": "CVSS",
"scenarios": [
{
"lang": "en",
"value": "GENERAL"
}
]
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-322",
"description": "CWE-322 Key Exchange without Entity Authentication",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-09-22T08:49:16.171Z",
"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-rgxr-4g4w-j875"
},
{
"name": "EEF CNA record for CVE-2026-89422",
"tags": [
"related"
],
"url": "https://cna.erlef.org/cves/CVE-2026-89422.html"
},
{
"name": "OSV record EEF-CVE-2026-89422",
"tags": [
"related"
],
"url": "https://osv.dev/vulnerability/EEF-CVE-2026-89422"
},
{
"name": "Erlang/OTP version ordering",
"tags": [
"x_version-scheme"
],
"url": "https://www.erlang.org/doc/system/versions.html#order-of-versions"
},
{
"name": "Introducing commit 21b8a1b in erlang/otp",
"tags": [
"related"
],
"url": "https://github.com/erlang/otp/commit/21b8a1b0ad0adf200682b3854bc50114ab2b8c62"
},
{
"name": "Fix commit afec515 in erlang/otp",
"tags": [
"patch"
],
"url": "https://github.com/erlang/otp/commit/afec5156361bb50d3607c7c1a453c19b9149b324"
},
{
"name": "Fix commit 98c66c8 in erlang/otp",
"tags": [
"patch"
],
"url": "https://github.com/erlang/otp/commit/98c66c858113949c4262d26cd7d426c4b09d2b35"
},
{
"name": "Fix commit fd1d9d0 in erlang/otp",
"tags": [
"patch"
],
"url": "https://github.com/erlang/otp/commit/fd1d9d07fc92ec0d59f96dfb66182195882bb7dd"
}
],
"source": {
"discovery": "EXTERNAL"
},
"title": "TLS 1.3 client skips server authentication when ServerHello carries an unsolicited pre_shared_key extension",
"workarounds": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003eRestrict affected clients to TLS 1.2 by setting \u003ccode\u003e{versions, [\u0027tlsv1.2\u0027]}\u003c/code\u003e in the client\u0027s \u003ccode\u003essl\u003c/code\u003e options. This avoids the vulnerable code path at the cost of losing TLS 1.3.\u003c/p\u003e\n\u003cp\u003eNo configuration both keeps TLS 1.3 and mitigates the issue.\u003c/p\u003e"
},
{
"base64": false,
"type": "text/markdown",
"value": "Restrict affected clients to TLS 1.2 by setting `{versions, [\u0027tlsv1.2\u0027]}` in the client\u0027s `ssl` options. This avoids the vulnerable code path at the cost of losing TLS 1.3.\n\nNo configuration both keeps TLS 1.3 and mitigates the issue."
}
],
"value": "Restrict affected clients to TLS 1.2 by setting {versions, [\u0027tlsv1.2\u0027]} in the client\u0027s ssl options. This avoids the vulnerable code path at the cost of losing TLS 1.3.\n\nNo configuration both keeps TLS 1.3 and mitigates the issue."
}
]
}
},
"cveMetadata": {
"assignerOrgId": "6b3ad84c-e1a6-4bf7-a703-f496b71e49db",
"assignerShortName": "EEF",
"cveId": "CVE-2026-89422",
"datePublished": "2026-09-22T08:49:16.171Z",
"dateReserved": "2026-09-11T18:45:01.480Z",
"dateUpdated": "2026-09-22T13:08:15.912Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
CVE-2026-82672 (GCVE-0-2026-82672)
Vulnerability from cvelistv5 – Published: 2026-09-19 17:00 – Updated: 2026-09-21 18:30
VLAI
EPSS
VEX
Title
Unvalidated chunk-size line tail in Mint HTTP/1 client enables response smuggling against strict intermediaries on pooled connections
Summary
Inconsistent Interpretation of HTTP Requests ('HTTP Request/Response Smuggling') vulnerability in elixir-mint mint allows a malicious HTTP/1 server to desynchronize a strict intermediary and the Mint client on a pooled connection, enabling response-queue poisoning against subsequent requests that share the connection.
Mint.HTTP1.Parse.chunk_size/1 in lib/mint/http1/parse.ex stops at the first non-hexadecimal byte of a chunked response's chunk-size line and returns the remainder unexamined. Mint.HTTP1.decode_body/5 in lib/mint/http1.ex then discards every byte up to the CRLF with Parse.ignore_until_crlf/1, so the accepted grammar is a run of hex digits followed by arbitrary bytes, where RFC 9112 permits only a ;-introduced chunk extension. Lines such as 5ZZZZZ and 5 9 are accepted as chunk size 5, and 0ZZZZ is accepted as the terminating chunk that ends the message body. An RFC-strict intermediary rejects such a line while Mint accepts it, so the two disagree on chunk boundaries and on where the response ends.
This issue affects mint: from 0.1.0 before 1.10.1.
Severity
SSVC
Exploitation: poc
Automatable: no
Technical Impact: partial
CISA Coordinator · CISA-ADP (v2.0.3)
Decision recorded 2026-09-21 18:29 UTC
CWE
- CWE-444 - Inconsistent Interpretation of HTTP Requests ('HTTP Request/Response Smuggling')
Assigner
References
5 references
| URL | Tags |
|---|---|
| https://github.com/elixir-mint/mint/security/advi… | relatedvendor-advisory |
| https://cna.erlef.org/cves/CVE-2026-82672.html | related |
| https://osv.dev/vulnerability/EEF-CVE-2026-82672 | related |
| https://github.com/elixir-mint/mint/commit/600895… | related |
| https://github.com/elixir-mint/mint/commit/c82377… | patch |
Impacted products
2 products
| Vendor | Product | Version | |
|---|---|---|---|
| elixir-mint | mint |
Affected:
0.1.0 , < 1.10.1
(semver)
cpe:2.3:a:elixir-mint:mint:*:*:*:*:*:*:*:* |
|
| elixir-mint | mint |
Affected:
60089586ec7adc9fddb09f69a2f5919ba9ac7f33 , < c82377838dc6e275ef40bafa664fbcdf50270c60
(git)
cpe:2.3:a:elixir-mint:mint:*:*:*:*:*:*:*:* |
{
"containers": {
"adp": [
{
"metrics": [
{
"other": {
"content": {
"id": "CVE-2026-82672",
"options": [
{
"Exploitation": "poc"
},
{
"Automatable": "no"
},
{
"Technical Impact": "partial"
}
],
"role": "CISA Coordinator",
"timestamp": "2026-09-21T18:29:40.588404Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"providerMetadata": {
"dateUpdated": "2026-09-21T18:30:02.604Z",
"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"shortName": "CISA-ADP"
},
"references": [
{
"tags": [
"exploit"
],
"url": "https://github.com/elixir-mint/mint/security/advisories/GHSA-rj5m-69wp-cxq9"
}
],
"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.Parse\u0027",
"\u0027Elixir.Mint.HTTP1\u0027"
],
"packageName": "mint",
"packageURL": "pkg:hex/mint",
"product": "mint",
"programFiles": [
"lib/mint/http1/parse.ex",
"lib/mint/http1.ex"
],
"programRoutines": [
{
"name": "\u0027Elixir.Mint.HTTP1.Parse\u0027:chunk_size/1"
},
{
"name": "\u0027Elixir.Mint.HTTP1.Parse\u0027:ignore_until_crlf/1"
},
{
"name": "\u0027Elixir.Mint.HTTP1\u0027:decode_body/5"
}
],
"repo": "https://github.com/elixir-mint/mint",
"vendor": "elixir-mint",
"versions": [
{
"lessThan": "1.10.1",
"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.Parse\u0027",
"\u0027Elixir.Mint.HTTP1\u0027"
],
"packageName": "elixir-mint/mint",
"packageURL": "pkg:github/elixir-mint/mint",
"product": "mint",
"programFiles": [
"lib/mint/http1/parse.ex",
"lib/mint/http1.ex"
],
"programRoutines": [
{
"name": "\u0027Elixir.Mint.HTTP1.Parse\u0027:chunk_size/1"
},
{
"name": "\u0027Elixir.Mint.HTTP1.Parse\u0027:ignore_until_crlf/1"
},
{
"name": "\u0027Elixir.Mint.HTTP1\u0027:decode_body/5"
}
],
"repo": "https://github.com/elixir-mint/mint",
"vendor": "elixir-mint",
"versions": [
{
"lessThan": "c82377838dc6e275ef40bafa664fbcdf50270c60",
"status": "affected",
"version": "60089586ec7adc9fddb09f69a2f5919ba9ac7f33",
"versionType": "git"
}
]
}
],
"configurations": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003eExploitation requires a deployment topology in which an RFC-strict HTTP/1 intermediary (proxy, load balancer, or WAF) sits between the Mint client and the attacker-influenced origin, and HTTP/1 connections between the client and the intermediary are reused across requests (keep-alive with connection pooling). Mint clients that talk directly to an origin without an intermediary, or that do not reuse connections, are not exploitable for response-queue poisoning even if the vulnerable parsing behavior is present.\u003c/p\u003e"
},
{
"base64": false,
"type": "text/markdown",
"value": "Exploitation requires a deployment topology in which an RFC-strict HTTP/1 intermediary (proxy, load balancer, or WAF) sits between the Mint client and the attacker-influenced origin, and HTTP/1 connections between the client and the intermediary are reused across requests (keep-alive with connection pooling). Mint clients that talk directly to an origin without an intermediary, or that do not reuse connections, are not exploitable for response-queue poisoning even if the vulnerable parsing behavior is present."
}
],
"value": "Exploitation requires a deployment topology in which an RFC-strict HTTP/1 intermediary (proxy, load balancer, or WAF) sits between the Mint client and the attacker-influenced origin, and HTTP/1 connections between the client and the intermediary are reused across requests (keep-alive with connection pooling). Mint clients that talk directly to an origin without an intermediary, or that do not reuse connections, are not exploitable for response-queue poisoning even if the vulnerable parsing behavior is present."
}
],
"cpeApplicability": [
{
"nodes": [
{
"cpeMatch": [
{
"criteria": "cpe:2.3:a:elixir-mint:mint:*:*:*:*:*:*:*:*",
"versionEndExcluding": "1.10.1",
"versionStartIncluding": "0.1.0",
"vulnerable": true
}
],
"negate": false,
"operator": "OR"
}
],
"operator": "AND"
}
],
"credits": [
{
"lang": "en",
"type": "finder",
"value": "Eurico Nicacio"
},
{
"lang": "en",
"type": "reporter",
"value": "Eurico Nicacio"
},
{
"lang": "en",
"type": "remediation developer",
"value": "Eric Meadows-J\u00f6nsson"
},
{
"lang": "en",
"type": "remediation reviewer",
"value": "Andrea Leopardi"
}
],
"dateAssigned": "2026-09-19T15:55:00.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 a strict intermediary and the Mint client on a pooled connection, enabling response-queue poisoning against subsequent requests that share the connection.\u003c/p\u003e\n\u003cp\u003e\u003ccode\u003eMint.HTTP1.Parse.chunk_size/1\u003c/code\u003e in \u003ccode\u003elib/mint/http1/parse.ex\u003c/code\u003e stops at the first non-hexadecimal byte of a chunked response\u0027s chunk-size line and returns the remainder unexamined. \u003ccode\u003eMint.HTTP1.decode_body/5\u003c/code\u003e in \u003ccode\u003elib/mint/http1.ex\u003c/code\u003e then discards every byte up to the CRLF with \u003ccode\u003eParse.ignore_until_crlf/1\u003c/code\u003e, so the accepted grammar is a run of hex digits followed by arbitrary bytes, where RFC 9112 permits only a \u003ccode\u003e;\u003c/code\u003e-introduced chunk extension. Lines such as \u003ccode\u003e5ZZZZZ\u003c/code\u003e and \u003ccode\u003e5 9\u003c/code\u003e are accepted as chunk size 5, and \u003ccode\u003e0ZZZZ\u003c/code\u003e is accepted as the terminating chunk that ends the message body. An RFC-strict intermediary rejects such a line while Mint accepts it, so the two disagree on chunk boundaries and on where the response ends.\u003c/p\u003e\n\u003cp\u003eThis issue affects mint: from 0.1.0 before 1.10.1.\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 a strict intermediary and the Mint client on a pooled connection, enabling response-queue poisoning against subsequent requests that share the connection.\n\n`Mint.HTTP1.Parse.chunk_size/1` in `lib/mint/http1/parse.ex` stops at the first non-hexadecimal byte of a chunked response\u0027s chunk-size line and returns the remainder unexamined. `Mint.HTTP1.decode_body/5` in `lib/mint/http1.ex` then discards every byte up to the CRLF with `Parse.ignore_until_crlf/1`, so the accepted grammar is a run of hex digits followed by arbitrary bytes, where RFC 9112 permits only a `;`-introduced chunk extension. Lines such as `5ZZZZZ` and `5 9` are accepted as chunk size 5, and `0ZZZZ` is accepted as the terminating chunk that ends the message body. An RFC-strict intermediary rejects such a line while Mint accepts it, so the two disagree on chunk boundaries and on where the response ends.\n\nThis issue affects mint: from 0.1.0 before 1.10.1."
}
],
"value": "Inconsistent Interpretation of HTTP Requests (\u0027HTTP Request/Response Smuggling\u0027) vulnerability in elixir-mint mint allows a malicious HTTP/1 server to desynchronize a strict intermediary and the Mint client on a pooled connection, enabling response-queue poisoning against subsequent requests that share the connection.\n\nMint.HTTP1.Parse.chunk_size/1 in lib/mint/http1/parse.ex stops at the first non-hexadecimal byte of a chunked response\u0027s chunk-size line and returns the remainder unexamined. Mint.HTTP1.decode_body/5 in lib/mint/http1.ex then discards every byte up to the CRLF with Parse.ignore_until_crlf/1, so the accepted grammar is a run of hex digits followed by arbitrary bytes, where RFC 9112 permits only a ;-introduced chunk extension. Lines such as 5ZZZZZ and 5 9 are accepted as chunk size 5, and 0ZZZZ is accepted as the terminating chunk that ends the message body. An RFC-strict intermediary rejects such a line while Mint accepts it, so the two disagree on chunk boundaries and on where the response ends.\n\nThis issue affects mint: from 0.1.0 before 1.10.1."
}
],
"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 RFC-strict intermediary can make the intermediary and the Mint client disagree on chunk boundaries and on where the response body ends. On a pooled keep-alive connection that disagreement lets bytes from one response be attributed to the next, poisoning the responses returned to unrelated requests that share the connection.\u003c/p\u003e"
},
{
"base64": false,
"type": "text/markdown",
"value": "A malicious or attacker-influenced HTTP/1 origin behind an RFC-strict intermediary can make the intermediary and the Mint client disagree on chunk boundaries and on where the response body ends. On a pooled keep-alive connection that disagreement lets bytes from one response be attributed to the next, poisoning the responses returned to unrelated requests that share the connection."
}
],
"value": "A malicious or attacker-influenced HTTP/1 origin behind an RFC-strict intermediary can make the intermediary and the Mint client disagree on chunk boundaries and on where the response body ends. On a pooled keep-alive connection that disagreement lets bytes from one response be attributed to the next, poisoning the responses returned to unrelated requests that share the connection."
}
]
}
],
"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-19T17:00:31.648Z",
"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-rj5m-69wp-cxq9"
},
{
"name": "EEF CNA record for CVE-2026-82672",
"tags": [
"related"
],
"url": "https://cna.erlef.org/cves/CVE-2026-82672.html"
},
{
"name": "OSV record EEF-CVE-2026-82672",
"tags": [
"related"
],
"url": "https://osv.dev/vulnerability/EEF-CVE-2026-82672"
},
{
"name": "Introducing commit 6008958 in elixir-mint/mint",
"tags": [
"related"
],
"url": "https://github.com/elixir-mint/mint/commit/60089586ec7adc9fddb09f69a2f5919ba9ac7f33"
},
{
"name": "Fix commit c823778 in elixir-mint/mint",
"tags": [
"patch"
],
"url": "https://github.com/elixir-mint/mint/commit/c82377838dc6e275ef40bafa664fbcdf50270c60"
}
],
"source": {
"discovery": "EXTERNAL"
},
"title": "Unvalidated chunk-size line tail in Mint HTTP/1 client enables response smuggling against strict intermediaries on pooled connections",
"x_proofOfConcept": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003col\u003e\n\u003cli\u003eStart a loopback TCP server that serves one \u003ccode\u003eHTTP/1.1 200 OK\u003c/code\u003e response with \u003ccode\u003etransfer-encoding: chunked\u003c/code\u003e and controls the chunk-size line byte for byte.\u003c/li\u003e\n\u003cli\u003eConnect with \u003ccode\u003eMint.HTTP1\u003c/code\u003e (mint 1.10.0 from Hex), send a request and stream the response.\u003c/li\u003e\n\u003cli\u003ePositive controls: chunk-size lines \u003ccode\u003e+5\u003c/code\u003e, \u003ccode\u003eZ5\u003c/code\u003e and \u003ccode\u003e00000000000000005\u003c/code\u003e are refused with \u003ccode\u003e:invalid_chunk_size\u003c/code\u003e, confirming the build carries the earlier chunk-size fixes.\u003c/li\u003e\n\u003cli\u003eBaseline: \u003ccode\u003e5\u003c/code\u003e and \u003ccode\u003e5;name=value\u003c/code\u003e are accepted with body \u003ccode\u003ehello\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eFinding: \u003ccode\u003e5ZZZZZ\u003c/code\u003e, \u003ccode\u003e5 anything at all\u003c/code\u003e, \u003ccode\u003e5\u0026lt;TAB\u0026gt;foo\u003c/code\u003e, \u003ccode\u003e5 9\u003c/code\u003e and \u003ccode\u003e5}~!\u003c/code\u003e are each accepted as chunk size 5 with body \u003ccode\u003ehello\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eTerminator: \u003ccode\u003e0ZZZZ\u003c/code\u003e and \u003ccode\u003e0 9\u003c/code\u003e in place of the final \u003ccode\u003e0\u003c/code\u003e chunk are accepted and end the body.\u003c/li\u003e\n\u003cli\u003eContrast: \u003ccode\u003eContent-Length: +5\u003c/code\u003e, \u003ccode\u003eContent-Length: 5ZZZ\u003c/code\u003e and \u003ccode\u003eContent-Length: 5 9\u003c/code\u003e are refused with \u003ccode\u003e:invalid_content_length_header\u003c/code\u003e in the same run.\u003c/li\u003e\n\u003c/ol\u003e\n\u003cp\u003eThe reporter ran this on Elixir 1.18 / OTP 27 and Elixir 1.18.4 / OTP 28 with identical results.\u003c/p\u003e"
},
{
"base64": false,
"type": "text/markdown",
"value": "1. Start a loopback TCP server that serves one `HTTP/1.1 200 OK` response with `transfer-encoding: chunked` and controls the chunk-size line byte for byte.\n2. Connect with `Mint.HTTP1` (mint 1.10.0 from Hex), send a request and stream the response.\n3. Positive controls: chunk-size lines `+5`, `Z5` and `00000000000000005` are refused with `:invalid_chunk_size`, confirming the build carries the earlier chunk-size fixes.\n4. Baseline: `5` and `5;name=value` are accepted with body `hello`.\n5. Finding: `5ZZZZZ`, `5 anything at all`, `5\u003cTAB\u003efoo`, `5 9` and `5}~!` are each accepted as chunk size 5 with body `hello`.\n6. Terminator: `0ZZZZ` and `0 9` in place of the final `0` chunk are accepted and end the body.\n7. Contrast: `Content-Length: +5`, `Content-Length: 5ZZZ` and `Content-Length: 5 9` are refused with `:invalid_content_length_header` in the same run.\n\nThe reporter ran this on Elixir 1.18 / OTP 27 and Elixir 1.18.4 / OTP 28 with identical results."
}
],
"value": "* Start a loopback TCP server that serves one HTTP/1.1 200 OK response with transfer-encoding: chunked and controls the chunk-size line byte for byte.\n* Connect with Mint.HTTP1 (mint 1.10.0 from Hex), send a request and stream the response.\n* Positive controls: chunk-size lines +5, Z5 and 00000000000000005 are refused with :invalid_chunk_size, confirming the build carries the earlier chunk-size fixes.\n* Baseline: 5 and 5;name=value are accepted with body hello.\n* Finding: 5ZZZZZ, 5 anything at all, 5\u003cTAB\u003efoo, 5 9 and 5}~! are each accepted as chunk size 5 with body hello.\n* Terminator: 0ZZZZ and 0 9 in place of the final 0 chunk are accepted and end the body.\n* Contrast: Content-Length: +5, Content-Length: 5ZZZ and Content-Length: 5 9 are refused with :invalid_content_length_header in the same run.\n\nThe reporter ran this on Elixir 1.18 / OTP 27 and Elixir 1.18.4 / OTP 28 with identical results."
}
],
"x_technicalAnalysis": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003e\u003cstrong\u003e1. Chunk-size parsing.\u003c/strong\u003e \u003ccode\u003eMint.HTTP1.Parse.chunk_size/1\u003c/code\u003e in \u003ccode\u003elib/mint/http1/parse.ex\u003c/code\u003e folds leading hexadecimal digits into an accumulator through \u003ccode\u003eparse_hex_prefix/3\u003c/code\u003e and, on the first byte that is not a hex digit, returns \u003ccode\u003e{:ok, size, rest}\u003c/code\u003e with \u003ccode\u003erest\u003c/code\u003e unexamined. The sign and digit-count checks added by earlier fixes constrain only the digits.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e2. Tail skipping.\u003c/strong\u003e The caller, \u003ccode\u003eMint.HTTP1.decode_body/5\u003c/code\u003e in \u003ccode\u003elib/mint/http1.ex\u003c/code\u003e, hands \u003ccode\u003erest\u003c/code\u003e to \u003ccode\u003eParse.ignore_until_crlf/1\u003c/code\u003e, which advances over any byte until it finds CRLF. Nothing between the last hex digit and the CRLF is validated, so the accepted grammar is \u003ccode\u003e1*HEXDIG *OCTET CRLF\u003c/code\u003e, where RFC 9112 section 7.1 allows only an optional \u003ccode\u003e;\u003c/code\u003e-introduced \u003ccode\u003echunk-ext\u003c/code\u003e. The same tolerance applies to the terminating zero-length chunk, which is the token that ends the message body.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e3. Parser disagreement.\u003c/strong\u003e The sibling \u003ccode\u003eContent-Length\u003c/code\u003e parser, \u003ccode\u003eMint.HTTP1.Parse.content_length_header/1\u003c/code\u003e, trims trailing whitespace and requires the whole remaining value to be digits, rejecting anything else. An RFC-strict intermediary that rejects or reframes a chunk-size line with a non-extension tail, on a connection where Mint accepts it, yields a framing disagreement about chunk length and, through the terminating chunk, about where the message ends.\u003c/p\u003e"
},
{
"base64": false,
"type": "text/markdown",
"value": "**1. Chunk-size parsing.** `Mint.HTTP1.Parse.chunk_size/1` in `lib/mint/http1/parse.ex` folds leading hexadecimal digits into an accumulator through `parse_hex_prefix/3` and, on the first byte that is not a hex digit, returns `{:ok, size, rest}` with `rest` unexamined. The sign and digit-count checks added by earlier fixes constrain only the digits.\n\n**2. Tail skipping.** The caller, `Mint.HTTP1.decode_body/5` in `lib/mint/http1.ex`, hands `rest` to `Parse.ignore_until_crlf/1`, which advances over any byte until it finds CRLF. Nothing between the last hex digit and the CRLF is validated, so the accepted grammar is `1*HEXDIG *OCTET CRLF`, where RFC 9112 section 7.1 allows only an optional `;`-introduced `chunk-ext`. The same tolerance applies to the terminating zero-length chunk, which is the token that ends the message body.\n\n**3. Parser disagreement.** The sibling `Content-Length` parser, `Mint.HTTP1.Parse.content_length_header/1`, trims trailing whitespace and requires the whole remaining value to be digits, rejecting anything else. An RFC-strict intermediary that rejects or reframes a chunk-size line with a non-extension tail, on a connection where Mint accepts it, yields a framing disagreement about chunk length and, through the terminating chunk, about where the message ends."
}
],
"value": "1. Chunk-size parsing. Mint.HTTP1.Parse.chunk_size/1 in lib/mint/http1/parse.ex folds leading hexadecimal digits into an accumulator through parse_hex_prefix/3 and, on the first byte that is not a hex digit, returns {:ok, size, rest} with rest unexamined. The sign and digit-count checks added by earlier fixes constrain only the digits.\n\n2. Tail skipping. The caller, Mint.HTTP1.decode_body/5 in lib/mint/http1.ex, hands rest to Parse.ignore_until_crlf/1, which advances over any byte until it finds CRLF. Nothing between the last hex digit and the CRLF is validated, so the accepted grammar is 1*HEXDIG *OCTET CRLF, where RFC 9112 section 7.1 allows only an optional ;-introduced chunk-ext. The same tolerance applies to the terminating zero-length chunk, which is the token that ends the message body.\n\n3. Parser disagreement. The sibling Content-Length parser, Mint.HTTP1.Parse.content_length_header/1, trims trailing whitespace and requires the whole remaining value to be digits, rejecting anything else. An RFC-strict intermediary that rejects or reframes a chunk-size line with a non-extension tail, on a connection where Mint accepts it, yields a framing disagreement about chunk length and, through the terminating chunk, about where the message ends."
}
]
}
},
"cveMetadata": {
"assignerOrgId": "6b3ad84c-e1a6-4bf7-a703-f496b71e49db",
"assignerShortName": "EEF",
"cveId": "CVE-2026-82672",
"datePublished": "2026-09-19T17:00:31.648Z",
"dateReserved": "2026-09-17T05:30:01.748Z",
"dateUpdated": "2026-09-21T18:30:02.604Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
CVE-2026-86688 (GCVE-0-2026-86688)
Vulnerability from cvelistv5 – Published: 2026-09-17 21:58 – Updated: 2026-09-18 14:31
VLAI
EPSS
VEX
Title
Session id is not renewed on authentication in ash_authentication, allowing session fixation
Summary
Session Fixation vulnerability in team-alembic ash_authentication allows an attacker who can plant a session identifier in a victim's browser to hold an authenticated session once that victim signs in.
AshAuthentication.Plug.Helpers.store_in_session/2 writes the authenticated subject into the existing session with Plug.Conn.put_session/3 and never calls Plug.Conn.configure_session(renew: true), so the identifier the visitor arrived with carries into their authenticated session. Every authentication event reaches this one function: the default success/4 injected by AshAuthentication.Phoenix.Controller.__using__/1, the AuthController emitted by mix ash_authentication_phoenix.install, and remember-me auto-login. AshAuthentication.Phoenix.Plug.store_in_session/2 is a defdelegate to it. Logout does not close the window either, because clear_session/2 ends with Plug.Conn.clear_session/1, which clears session contents but leaves the identifier intact, so a planted identifier survives a logout-then-login cycle.
This issue affects ash_authentication: from 0.2.0 before 4.15.0 and from 5.0.0-rc.0 before 5.0.0-rc.14.
Severity
SSVC
Exploitation: none
Automatable: no
Technical Impact: total
CISA Coordinator · CISA-ADP (v2.0.3)
Decision recorded 2026-09-18 14:24 UTC
CWE
- CWE-384 - Session Fixation
Assigner
References
6 references
Impacted products
2 products
| Vendor | Product | Version | |
|---|---|---|---|
| team-alembic | ash_authentication |
Affected:
0.2.0 , < 4.15.0
(semver)
Affected: 5.0.0-rc.0 , < 5.0.0-rc.14 (semver) cpe:2.3:a:team-alembic:ash_authentication:*:*:*:*:*:*:*:* |
|
| team-alembic | ash_authentication |
Affected:
a939dde9b917c072cdf10c4b0913a9886a4b0231 , < *
(git)
cpe:2.3:a:team-alembic:ash_authentication:*:*:*:*:*:*:*:* |
{
"containers": {
"adp": [
{
"metrics": [
{
"other": {
"content": {
"id": "CVE-2026-86688",
"options": [
{
"Exploitation": "none"
},
{
"Automatable": "no"
},
{
"Technical Impact": "total"
}
],
"role": "CISA Coordinator",
"timestamp": "2026-09-18T14:24:09.606894Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"providerMetadata": {
"dateUpdated": "2026-09-18T14:31:41.961Z",
"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:team-alembic:ash_authentication:*:*:*:*:*:*:*:*"
],
"defaultStatus": "unaffected",
"packageName": "ash_authentication",
"packageURL": "pkg:hex/ash_authentication",
"product": "ash_authentication",
"repo": "https://github.com/team-alembic/ash_authentication",
"vendor": "team-alembic",
"versions": [
{
"lessThan": "4.15.0",
"status": "affected",
"version": "0.2.0",
"versionType": "semver"
},
{
"lessThan": "5.0.0-rc.14",
"status": "affected",
"version": "5.0.0-rc.0",
"versionType": "semver"
}
]
},
{
"collectionURL": "https://github.com",
"cpes": [
"cpe:2.3:a:team-alembic:ash_authentication:*:*:*:*:*:*:*:*"
],
"defaultStatus": "unaffected",
"packageName": "team-alembic/ash_authentication",
"packageURL": "pkg:github/team-alembic/ash_authentication",
"product": "ash_authentication",
"repo": "https://github.com/team-alembic/ash_authentication",
"vendor": "team-alembic",
"versions": [
{
"changes": [
{
"at": "872db454405ecad4fcdabd9ff3d8755d1d6a69ae",
"status": "unaffected"
},
{
"at": "3e1d452cbf1564e87f5f97be882b66fe25af7cfa",
"status": "unaffected"
}
],
"lessThan": "*",
"status": "affected",
"version": "a939dde9b917c072cdf10c4b0913a9886a4b0231",
"versionType": "git"
}
]
}
],
"configurations": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003eExploitation for account takeover requires a server-side session store (ETS, Mnesia, Redis or a database), where the cookie carries a stable session identifier, and a position from which the attacker can plant that cookie in the victim\u0027s browser: cookie tossing from a sibling subdomain, an HTTP host without HSTS, or a shared or kiosk browser.\u003c/p\u003e\n\u003cp\u003ePhoenix defaults to the signed cookie store, and neither package\u0027s installer changes it. Under that store the authenticated session lives in the re-signed cookie delivered only to the victim, so a planted pre-authentication copy does not become an authenticated session. Attacker-planted session contents, such as a \u003ccode\u003ereturn_to\u003c/code\u003e value, still survive into the authenticated session there.\u003c/p\u003e"
},
{
"base64": false,
"type": "text/markdown",
"value": "Exploitation for account takeover requires a server-side session store (ETS, Mnesia, Redis or a database), where the cookie carries a stable session identifier, and a position from which the attacker can plant that cookie in the victim\u0027s browser: cookie tossing from a sibling subdomain, an HTTP host without HSTS, or a shared or kiosk browser.\n\nPhoenix defaults to the signed cookie store, and neither package\u0027s installer changes it. Under that store the authenticated session lives in the re-signed cookie delivered only to the victim, so a planted pre-authentication copy does not become an authenticated session. Attacker-planted session contents, such as a `return_to` value, still survive into the authenticated session there."
}
],
"value": "Exploitation for account takeover requires a server-side session store (ETS, Mnesia, Redis or a database), where the cookie carries a stable session identifier, and a position from which the attacker can plant that cookie in the victim\u0027s browser: cookie tossing from a sibling subdomain, an HTTP host without HSTS, or a shared or kiosk browser.\n\nPhoenix defaults to the signed cookie store, and neither package\u0027s installer changes it. Under that store the authenticated session lives in the re-signed cookie delivered only to the victim, so a planted pre-authentication copy does not become an authenticated session. Attacker-planted session contents, such as a return_to value, still survive into the authenticated session there."
}
],
"cpeApplicability": [
{
"nodes": [
{
"cpeMatch": [
{
"criteria": "cpe:2.3:a:team-alembic:ash_authentication:*:*:*:*:*:*:*:*",
"versionEndExcluding": "4.15.0",
"versionStartIncluding": "0.2.0",
"vulnerable": true
},
{
"criteria": "cpe:2.3:a:team-alembic:ash_authentication:*:*:*:*:*:*:*:*",
"versionEndExcluding": "5.0.0-rc.14",
"versionStartIncluding": "5.0.0-rc.0",
"vulnerable": true
}
],
"negate": false,
"operator": "OR"
}
],
"operator": "AND"
}
],
"credits": [
{
"lang": "en",
"type": "reporter",
"value": "Peter Ullrich"
},
{
"lang": "en",
"type": "remediation developer",
"value": "James Harton"
},
{
"lang": "en",
"type": "coordinator",
"value": "Jonatan M\u00e4nnchen / EEF"
}
],
"dateAssigned": "2026-09-17T05:24:11.000Z",
"descriptions": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003eSession Fixation vulnerability in team-alembic ash_authentication allows an attacker who can plant a session identifier in a victim\u0027s browser to hold an authenticated session once that victim signs in.\u003c/p\u003e\n\u003cp\u003e\u003ccode\u003eAshAuthentication.Plug.Helpers.store_in_session/2\u003c/code\u003e writes the authenticated subject into the existing session with \u003ccode\u003ePlug.Conn.put_session/3\u003c/code\u003e and never calls \u003ccode\u003ePlug.Conn.configure_session(renew: true)\u003c/code\u003e, so the identifier the visitor arrived with carries into their authenticated session. Every authentication event reaches this one function: the default \u003ccode\u003esuccess/4\u003c/code\u003e injected by \u003ccode\u003eAshAuthentication.Phoenix.Controller.__using__/1\u003c/code\u003e, the \u003ccode\u003eAuthController\u003c/code\u003e emitted by \u003ccode\u003emix ash_authentication_phoenix.install\u003c/code\u003e, and remember-me auto-login. \u003ccode\u003eAshAuthentication.Phoenix.Plug.store_in_session/2\u003c/code\u003e is a \u003ccode\u003edefdelegate\u003c/code\u003e to it. Logout does not close the window either, because \u003ccode\u003eclear_session/2\u003c/code\u003e ends with \u003ccode\u003ePlug.Conn.clear_session/1\u003c/code\u003e, which clears session contents but leaves the identifier intact, so a planted identifier survives a logout-then-login cycle.\u003c/p\u003e\n\u003cp\u003eThis issue affects ash_authentication: from 0.2.0 before 4.15.0 and from 5.0.0-rc.0 before 5.0.0-rc.14.\u003c/p\u003e"
},
{
"base64": false,
"type": "text/markdown",
"value": "Session Fixation vulnerability in team-alembic ash_authentication allows an attacker who can plant a session identifier in a victim\u0027s browser to hold an authenticated session once that victim signs in.\n\n`AshAuthentication.Plug.Helpers.store_in_session/2` writes the authenticated subject into the existing session with `Plug.Conn.put_session/3` and never calls `Plug.Conn.configure_session(renew: true)`, so the identifier the visitor arrived with carries into their authenticated session. Every authentication event reaches this one function: the default `success/4` injected by `AshAuthentication.Phoenix.Controller.__using__/1`, the `AuthController` emitted by `mix ash_authentication_phoenix.install`, and remember-me auto-login. `AshAuthentication.Phoenix.Plug.store_in_session/2` is a `defdelegate` to it. Logout does not close the window either, because `clear_session/2` ends with `Plug.Conn.clear_session/1`, which clears session contents but leaves the identifier intact, so a planted identifier survives a logout-then-login cycle.\n\nThis issue affects ash_authentication: from 0.2.0 before 4.15.0 and from 5.0.0-rc.0 before 5.0.0-rc.14."
}
],
"value": "Session Fixation vulnerability in team-alembic ash_authentication allows an attacker who can plant a session identifier in a victim\u0027s browser to hold an authenticated session once that victim signs in.\n\nAshAuthentication.Plug.Helpers.store_in_session/2 writes the authenticated subject into the existing session with Plug.Conn.put_session/3 and never calls Plug.Conn.configure_session(renew: true), so the identifier the visitor arrived with carries into their authenticated session. Every authentication event reaches this one function: the default success/4 injected by AshAuthentication.Phoenix.Controller.__using__/1, the AuthController emitted by mix ash_authentication_phoenix.install, and remember-me auto-login. AshAuthentication.Phoenix.Plug.store_in_session/2 is a defdelegate to it. Logout does not close the window either, because clear_session/2 ends with Plug.Conn.clear_session/1, which clears session contents but leaves the identifier intact, so a planted identifier survives a logout-then-login cycle.\n\nThis issue affects ash_authentication: from 0.2.0 before 4.15.0 and from 5.0.0-rc.0 before 5.0.0-rc.14."
}
],
"impacts": [
{
"capecId": "CAPEC-61",
"descriptions": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003eAn attacker holding a session identifier they planted before the victim signed in gains that victim\u0027s authenticated session, and with it full account takeover, in deployments using a server-side session store.\u003c/p\u003e"
},
{
"base64": false,
"type": "text/markdown",
"value": "An attacker holding a session identifier they planted before the victim signed in gains that victim\u0027s authenticated session, and with it full account takeover, in deployments using a server-side session store."
}
],
"value": "An attacker holding a session identifier they planted before the victim signed in gains that victim\u0027s authenticated session, and with it full account takeover, in deployments using a server-side session store."
}
]
}
],
"metrics": [
{
"cvssV4_0": {
"Automatable": "NOT_DEFINED",
"Recovery": "NOT_DEFINED",
"Safety": "NOT_DEFINED",
"attackComplexity": "LOW",
"attackRequirements": "PRESENT",
"attackVector": "NETWORK",
"baseScore": 7.4,
"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:N/SC:N/SI:N/SA:N",
"version": "4.0",
"vulnAvailabilityImpact": "NONE",
"vulnConfidentialityImpact": "HIGH",
"vulnIntegrityImpact": "HIGH",
"vulnerabilityResponseEffort": "NOT_DEFINED"
},
"format": "CVSS",
"scenarios": [
{
"lang": "en",
"value": "GENERAL"
}
]
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-384",
"description": "CWE-384 Session Fixation",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-09-17T21:58:00.853Z",
"orgId": "6b3ad84c-e1a6-4bf7-a703-f496b71e49db",
"shortName": "EEF"
},
"references": [
{
"name": "GitHub Advisory",
"tags": [
"related",
"vendor-advisory"
],
"url": "https://github.com/team-alembic/ash_authentication/security/advisories/GHSA-v577-944g-7h3x"
},
{
"name": "EEF CNA record for CVE-2026-86688",
"tags": [
"related"
],
"url": "https://cna.erlef.org/cves/CVE-2026-86688.html"
},
{
"name": "OSV record EEF-CVE-2026-86688",
"tags": [
"related"
],
"url": "https://osv.dev/vulnerability/EEF-CVE-2026-86688"
},
{
"name": "Introducing commit a939dde in team-alembic/ash_authentication",
"tags": [
"related"
],
"url": "https://github.com/team-alembic/ash_authentication/commit/a939dde9b917c072cdf10c4b0913a9886a4b0231"
},
{
"name": "Fix commit 872db45 in team-alembic/ash_authentication",
"tags": [
"patch"
],
"url": "https://github.com/team-alembic/ash_authentication/commit/872db454405ecad4fcdabd9ff3d8755d1d6a69ae"
},
{
"name": "Fix commit 3e1d452 in team-alembic/ash_authentication",
"tags": [
"patch"
],
"url": "https://github.com/team-alembic/ash_authentication/commit/3e1d452cbf1564e87f5f97be882b66fe25af7cfa"
}
],
"source": {
"discovery": "EXTERNAL"
},
"title": "Session id is not renewed on authentication in ash_authentication, allowing session fixation",
"workarounds": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003eCall \u003ccode\u003ePlug.Conn.configure_session(conn, renew: true)\u003c/code\u003e in your own \u003ccode\u003esuccess/4\u003c/code\u003e before \u003ccode\u003estore_in_session/2\u003c/code\u003e. This is a one-line change in application code and closes the controller sign-in path, though not remember-me auto-login, which does not pass through application code.\u003c/p\u003e\n\u003cp\u003eAdd \u003ccode\u003ePlug.Conn.configure_session(conn, drop: true)\u003c/code\u003e at sign-out so a planted identifier does not survive a logout-then-login cycle.\u003c/p\u003e"
},
{
"base64": false,
"type": "text/markdown",
"value": "Call `Plug.Conn.configure_session(conn, renew: true)` in your own `success/4` before `store_in_session/2`. This is a one-line change in application code and closes the controller sign-in path, though not remember-me auto-login, which does not pass through application code.\n\nAdd `Plug.Conn.configure_session(conn, drop: true)` at sign-out so a planted identifier does not survive a logout-then-login cycle."
}
],
"value": "Call Plug.Conn.configure_session(conn, renew: true) in your own success/4 before store_in_session/2. This is a one-line change in application code and closes the controller sign-in path, though not remember-me auto-login, which does not pass through application code.\n\nAdd Plug.Conn.configure_session(conn, drop: true) at sign-out so a planted identifier does not survive a logout-then-login cycle."
}
]
}
},
"cveMetadata": {
"assignerOrgId": "6b3ad84c-e1a6-4bf7-a703-f496b71e49db",
"assignerShortName": "EEF",
"cveId": "CVE-2026-86688",
"datePublished": "2026-09-17T21:58:00.853Z",
"dateReserved": "2026-09-17T00:30:01.485Z",
"dateUpdated": "2026-09-18T14:31:41.961Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
CVE-2026-76949 (GCVE-0-2026-76949)
Vulnerability from cvelistv5 – Published: 2026-09-17 21:57 – Updated: 2026-09-18 14:31
VLAI
EPSS
VEX
Title
Remember-me sign-in guard reads a session key that is never written in ash_authentication, allowing session replacement
Summary
Authentication Bypass by Spoofing vulnerability in team-alembic ash_authentication allows an attacker who can plant a remember-me cookie in a victim's browser to replace that victim's authenticated session with one for the attacker's own account.
AshAuthentication.Plug.Helpers.sign_in_using_remember_me/3 skips re-authenticating an already-signed-in visitor by checking the session for "<subject_name>_token", but store_in_session/2 writes that key only when require_token_presence_for_authentication? is enabled and otherwise writes the bare subject name. At the default setting the guard therefore reads a key that is never written, its already-signed-in branch is unreachable, and the remember-me sign-in runs on every request through the per-request browser pipeline plug. A planted remember-me cookie is consequently honoured even for a visitor holding a live authenticated session, so whatever the victim enters afterwards lands in data the attacker controls. The read path in authenticate_resource_from_session/4 selects the key correctly, so the guard and the reader disagree about which key holds the session.
This issue affects ash_authentication: from 4.10.0 before 4.15.0 and from 5.0.0-rc.0 before 5.0.0-rc.14.
Severity
SSVC
Exploitation: none
Automatable: yes
Technical Impact: total
CISA Coordinator · CISA-ADP (v2.0.3)
Decision recorded 2026-09-18 14:24 UTC
CWE
- CWE-290 - Authentication Bypass by Spoofing
Assigner
References
6 references
Impacted products
2 products
| Vendor | Product | Version | |
|---|---|---|---|
| team-alembic | ash_authentication |
Affected:
4.10.0 , < 4.15.0
(semver)
Affected: 5.0.0-rc.0 , < 5.0.0-rc.14 (semver) cpe:2.3:a:team-alembic:ash_authentication:*:*:*:*:*:*:*:* |
|
| team-alembic | ash_authentication |
Affected:
3d3de314692558d06ec13945f857f00514e95a8c , < *
(git)
cpe:2.3:a:team-alembic:ash_authentication:*:*:*:*:*:*:*:* |
{
"containers": {
"adp": [
{
"metrics": [
{
"other": {
"content": {
"id": "CVE-2026-76949",
"options": [
{
"Exploitation": "none"
},
{
"Automatable": "yes"
},
{
"Technical Impact": "total"
}
],
"role": "CISA Coordinator",
"timestamp": "2026-09-18T14:24:28.652087Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"providerMetadata": {
"dateUpdated": "2026-09-18T14:31:41.806Z",
"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:team-alembic:ash_authentication:*:*:*:*:*:*:*:*"
],
"defaultStatus": "unaffected",
"modules": [
"\u0027Elixir.AshAuthentication.Plug.Helpers\u0027"
],
"packageName": "ash_authentication",
"packageURL": "pkg:hex/ash_authentication",
"product": "ash_authentication",
"programFiles": [
"lib/ash_authentication/plug/helpers.ex"
],
"programRoutines": [
{
"name": "\u0027Elixir.AshAuthentication.Plug.Helpers\u0027:sign_in_using_remember_me/3"
},
{
"name": "\u0027Elixir.AshAuthentication.Plug.Helpers\u0027:store_in_session/2"
}
],
"repo": "https://github.com/team-alembic/ash_authentication",
"vendor": "team-alembic",
"versions": [
{
"lessThan": "4.15.0",
"status": "affected",
"version": "4.10.0",
"versionType": "semver"
},
{
"lessThan": "5.0.0-rc.14",
"status": "affected",
"version": "5.0.0-rc.0",
"versionType": "semver"
}
]
},
{
"collectionURL": "https://github.com",
"cpes": [
"cpe:2.3:a:team-alembic:ash_authentication:*:*:*:*:*:*:*:*"
],
"defaultStatus": "unaffected",
"modules": [
"\u0027Elixir.AshAuthentication.Plug.Helpers\u0027"
],
"packageName": "team-alembic/ash_authentication",
"packageURL": "pkg:github/team-alembic/ash_authentication",
"product": "ash_authentication",
"programFiles": [
"lib/ash_authentication/plug/helpers.ex"
],
"programRoutines": [
{
"name": "\u0027Elixir.AshAuthentication.Plug.Helpers\u0027:sign_in_using_remember_me/3"
},
{
"name": "\u0027Elixir.AshAuthentication.Plug.Helpers\u0027:store_in_session/2"
}
],
"repo": "https://github.com/team-alembic/ash_authentication",
"vendor": "team-alembic",
"versions": [
{
"changes": [
{
"at": "b9568a53b438247238b1c5a4f49c8d84650f4bba",
"status": "unaffected"
},
{
"at": "9a34136b844abe179da1075067cf2835c64dcc12",
"status": "unaffected"
}
],
"lessThan": "*",
"status": "affected",
"version": "3d3de314692558d06ec13945f857f00514e95a8c",
"versionType": "git"
}
]
}
],
"configurations": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003eThe application must enable the \u003ccode\u003eremember_me\u003c/code\u003e strategy and run its per-request plug in the browser pipeline, with \u003ccode\u003erequire_token_presence_for_authentication?\u003c/code\u003e at its default of \u003ccode\u003efalse\u003c/code\u003e. Enabling that setting makes the guard read the key the session actually holds, which closes the issue.\u003c/p\u003e\n\u003cp\u003eThe attacker also needs a position from which to set a cookie in the victim\u0027s browser, such as cookie tossing from a sibling subdomain, an HTTP host without HSTS, or a shared or kiosk browser.\u003c/p\u003e"
},
{
"base64": false,
"type": "text/markdown",
"value": "The application must enable the `remember_me` strategy and run its per-request plug in the browser pipeline, with `require_token_presence_for_authentication?` at its default of `false`. Enabling that setting makes the guard read the key the session actually holds, which closes the issue.\n\nThe attacker also needs a position from which to set a cookie in the victim\u0027s browser, such as cookie tossing from a sibling subdomain, an HTTP host without HSTS, or a shared or kiosk browser."
}
],
"value": "The application must enable the remember_me strategy and run its per-request plug in the browser pipeline, with require_token_presence_for_authentication? at its default of false. Enabling that setting makes the guard read the key the session actually holds, which closes the issue.\n\nThe attacker also needs a position from which to set a cookie in the victim\u0027s browser, such as cookie tossing from a sibling subdomain, an HTTP host without HSTS, or a shared or kiosk browser."
}
],
"cpeApplicability": [
{
"nodes": [
{
"cpeMatch": [
{
"criteria": "cpe:2.3:a:team-alembic:ash_authentication:*:*:*:*:*:*:*:*",
"versionEndExcluding": "4.15.0",
"versionStartIncluding": "4.10.0",
"vulnerable": true
},
{
"criteria": "cpe:2.3:a:team-alembic:ash_authentication:*:*:*:*:*:*:*:*",
"versionEndExcluding": "5.0.0-rc.14",
"versionStartIncluding": "5.0.0-rc.0",
"vulnerable": true
}
],
"negate": false,
"operator": "OR"
}
],
"operator": "AND"
}
],
"credits": [
{
"lang": "en",
"type": "reporter",
"value": "Peter Ullrich"
},
{
"lang": "en",
"type": "remediation developer",
"value": "James Harton"
},
{
"lang": "en",
"type": "coordinator",
"value": "Jonatan M\u00e4nnchen / EEF"
}
],
"dateAssigned": "2026-09-17T14:23:56.000Z",
"descriptions": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003eAuthentication Bypass by Spoofing vulnerability in team-alembic ash_authentication allows an attacker who can plant a remember-me cookie in a victim\u0027s browser to replace that victim\u0027s authenticated session with one for the attacker\u0027s own account.\u003c/p\u003e\n\u003cp\u003e\u003ccode\u003eAshAuthentication.Plug.Helpers.sign_in_using_remember_me/3\u003c/code\u003e skips re-authenticating an already-signed-in visitor by checking the session for \u003ccode\u003e\"\u0026lt;subject_name\u0026gt;_token\"\u003c/code\u003e, but \u003ccode\u003estore_in_session/2\u003c/code\u003e writes that key only when \u003ccode\u003erequire_token_presence_for_authentication?\u003c/code\u003e is enabled and otherwise writes the bare subject name. At the default setting the guard therefore reads a key that is never written, its already-signed-in branch is unreachable, and the remember-me sign-in runs on every request through the per-request browser pipeline plug. A planted remember-me cookie is consequently honoured even for a visitor holding a live authenticated session, so whatever the victim enters afterwards lands in data the attacker controls. The read path in \u003ccode\u003eauthenticate_resource_from_session/4\u003c/code\u003e selects the key correctly, so the guard and the reader disagree about which key holds the session.\u003c/p\u003e\n\u003cp\u003eThis issue affects ash_authentication: from 4.10.0 before 4.15.0 and from 5.0.0-rc.0 before 5.0.0-rc.14.\u003c/p\u003e"
},
{
"base64": false,
"type": "text/markdown",
"value": "Authentication Bypass by Spoofing vulnerability in team-alembic ash_authentication allows an attacker who can plant a remember-me cookie in a victim\u0027s browser to replace that victim\u0027s authenticated session with one for the attacker\u0027s own account.\n\n`AshAuthentication.Plug.Helpers.sign_in_using_remember_me/3` skips re-authenticating an already-signed-in visitor by checking the session for `\"\u003csubject_name\u003e_token\"`, but `store_in_session/2` writes that key only when `require_token_presence_for_authentication?` is enabled and otherwise writes the bare subject name. At the default setting the guard therefore reads a key that is never written, its already-signed-in branch is unreachable, and the remember-me sign-in runs on every request through the per-request browser pipeline plug. A planted remember-me cookie is consequently honoured even for a visitor holding a live authenticated session, so whatever the victim enters afterwards lands in data the attacker controls. The read path in `authenticate_resource_from_session/4` selects the key correctly, so the guard and the reader disagree about which key holds the session.\n\nThis issue affects ash_authentication: from 4.10.0 before 4.15.0 and from 5.0.0-rc.0 before 5.0.0-rc.14."
}
],
"value": "Authentication Bypass by Spoofing vulnerability in team-alembic ash_authentication allows an attacker who can plant a remember-me cookie in a victim\u0027s browser to replace that victim\u0027s authenticated session with one for the attacker\u0027s own account.\n\nAshAuthentication.Plug.Helpers.sign_in_using_remember_me/3 skips re-authenticating an already-signed-in visitor by checking the session for \"\u003csubject_name\u003e_token\", but store_in_session/2 writes that key only when require_token_presence_for_authentication? is enabled and otherwise writes the bare subject name. At the default setting the guard therefore reads a key that is never written, its already-signed-in branch is unreachable, and the remember-me sign-in runs on every request through the per-request browser pipeline plug. A planted remember-me cookie is consequently honoured even for a visitor holding a live authenticated session, so whatever the victim enters afterwards lands in data the attacker controls. The read path in authenticate_resource_from_session/4 selects the key correctly, so the guard and the reader disagree about which key holds the session.\n\nThis issue affects ash_authentication: from 4.10.0 before 4.15.0 and from 5.0.0-rc.0 before 5.0.0-rc.14."
}
],
"impacts": [
{
"capecId": "CAPEC-21",
"descriptions": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003eAn attacker who can set a remember-me cookie in a victim\u0027s browser silently replaces the victim\u0027s authenticated session with one for the attacker\u0027s own account, so data the victim subsequently enters is written to records the attacker controls. The victim is given no indication their identity changed.\u003c/p\u003e"
},
{
"base64": false,
"type": "text/markdown",
"value": "An attacker who can set a remember-me cookie in a victim\u0027s browser silently replaces the victim\u0027s authenticated session with one for the attacker\u0027s own account, so data the victim subsequently enters is written to records the attacker controls. The victim is given no indication their identity changed."
}
],
"value": "An attacker who can set a remember-me cookie in a victim\u0027s browser silently replaces the victim\u0027s authenticated session with one for the attacker\u0027s own account, so data the victim subsequently enters is written to records the attacker controls. The victim is given no indication their identity changed."
}
]
}
],
"metrics": [
{
"cvssV4_0": {
"Automatable": "NOT_DEFINED",
"Recovery": "NOT_DEFINED",
"Safety": "NOT_DEFINED",
"attackComplexity": "LOW",
"attackRequirements": "PRESENT",
"attackVector": "NETWORK",
"baseScore": 9.1,
"baseSeverity": "CRITICAL",
"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:H/VI:H/VA:N/SC:N/SI:N/SA:N",
"version": "4.0",
"vulnAvailabilityImpact": "NONE",
"vulnConfidentialityImpact": "HIGH",
"vulnIntegrityImpact": "HIGH",
"vulnerabilityResponseEffort": "NOT_DEFINED"
},
"format": "CVSS",
"scenarios": [
{
"lang": "en",
"value": "GENERAL"
}
]
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-290",
"description": "CWE-290 Authentication Bypass by Spoofing",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-09-17T21:57:50.146Z",
"orgId": "6b3ad84c-e1a6-4bf7-a703-f496b71e49db",
"shortName": "EEF"
},
"references": [
{
"name": "GitHub Advisory",
"tags": [
"related",
"vendor-advisory"
],
"url": "https://github.com/team-alembic/ash_authentication/security/advisories/GHSA-hh34-374j-pfr5"
},
{
"name": "EEF CNA record for CVE-2026-76949",
"tags": [
"related"
],
"url": "https://cna.erlef.org/cves/CVE-2026-76949.html"
},
{
"name": "OSV record EEF-CVE-2026-76949",
"tags": [
"related"
],
"url": "https://osv.dev/vulnerability/EEF-CVE-2026-76949"
},
{
"name": "Introducing commit 3d3de31 in team-alembic/ash_authentication",
"tags": [
"related"
],
"url": "https://github.com/team-alembic/ash_authentication/commit/3d3de314692558d06ec13945f857f00514e95a8c"
},
{
"name": "Fix commit b9568a5 in team-alembic/ash_authentication",
"tags": [
"patch"
],
"url": "https://github.com/team-alembic/ash_authentication/commit/b9568a53b438247238b1c5a4f49c8d84650f4bba"
},
{
"name": "Fix commit 9a34136 in team-alembic/ash_authentication",
"tags": [
"patch"
],
"url": "https://github.com/team-alembic/ash_authentication/commit/9a34136b844abe179da1075067cf2835c64dcc12"
}
],
"source": {
"discovery": "EXTERNAL"
},
"title": "Remember-me sign-in guard reads a session key that is never written in ash_authentication, allowing session replacement",
"workarounds": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003eSet \u003ccode\u003erequire_token_presence_for_authentication? true\u003c/code\u003e on the authenticated resource\u0027s token configuration. \u003ccode\u003estore_in_session/2\u003c/code\u003e then writes the key the guard reads, so the already-signed-in branch fires and the remember-me sign-in no longer runs against a live session. Note this changes session storage semantics for the whole application and requires a token resource.\u003c/p\u003e\n\u003cp\u003eOtherwise remove the remember-me plug from the browser pipeline, which disables remember-me auto-login entirely.\u003c/p\u003e"
},
{
"base64": false,
"type": "text/markdown",
"value": "Set `require_token_presence_for_authentication? true` on the authenticated resource\u0027s token configuration. `store_in_session/2` then writes the key the guard reads, so the already-signed-in branch fires and the remember-me sign-in no longer runs against a live session. Note this changes session storage semantics for the whole application and requires a token resource.\n\nOtherwise remove the remember-me plug from the browser pipeline, which disables remember-me auto-login entirely."
}
],
"value": "Set require_token_presence_for_authentication? true on the authenticated resource\u0027s token configuration. store_in_session/2 then writes the key the guard reads, so the already-signed-in branch fires and the remember-me sign-in no longer runs against a live session. Note this changes session storage semantics for the whole application and requires a token resource.\n\nOtherwise remove the remember-me plug from the browser pipeline, which disables remember-me auto-login entirely."
}
]
}
},
"cveMetadata": {
"assignerOrgId": "6b3ad84c-e1a6-4bf7-a703-f496b71e49db",
"assignerShortName": "EEF",
"cveId": "CVE-2026-76949",
"datePublished": "2026-09-17T21:57:50.146Z",
"dateReserved": "2026-09-17T05:30:01.744Z",
"dateUpdated": "2026-09-18T14:31:41.806Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
CVE-2026-91039 (GCVE-0-2026-91039)
Vulnerability from cvelistv5 – Published: 2026-09-17 15:19 – Updated: 2026-09-17 19:40
VLAI
EPSS
VEX
Title
dynamic_oidc identities are not namespaced by connection in ash_authentication, allowing cross-connection account takeover
Summary
Authentication Bypass by Spoofing vulnerability in team-alembic ash_authentication allows an attacker who operates one identity-provider connection of a dynamic_oidc strategy to be signed in as a local user established through a different connection.
The strategy is meant to keep each connection in its own identity namespace by writing every UserIdentity row's strategy field as "<name>/<connection_id>", but that namespacing never takes effect. __connection_id__ is populated only on the ephemeral runtime struct built per request in dynamic_oidc/plug.ex, and DynamicOidc.IdentityChange.change/3 re-fetches the strategy from the compile-time DSL through Info.strategy_for_action, yielding the persisted struct whose __connection_id__ is its defstruct default of nil. OAuth2.identity_strategy_name/1 therefore falls back to the bare strategy name for both the identity write and the reads in oauth2/user_resolver.ex and oauth2/sign_in_preparation.ex. Since the identity resource's unique key is (uid, strategy), one row exists per sub across every connection, and the identity-match branch runs before any email check. Neither strategy handles iss, so nothing else distinguishes the issuers: OpenID Connect Core section 5.7 makes sub unique only within an issuer, so two connections numbering subjects independently share one subject space.
This issue affects ash_authentication: from 5.0.0-rc.10 before 5.0.0-rc.14.
Severity
SSVC
Exploitation: none
Automatable: no
Technical Impact: total
CISA Coordinator · CISA-ADP (v2.0.3)
Decision recorded 2026-09-17 19:40 UTC
CWE
- CWE-290 - Authentication Bypass by Spoofing
Assigner
References
5 references
| URL | Tags |
|---|---|
| https://github.com/team-alembic/ash_authenticatio… | relatedvendor-advisory |
| https://cna.erlef.org/cves/CVE-2026-91039.html | related |
| https://osv.dev/vulnerability/EEF-CVE-2026-91039 | related |
| https://github.com/team-alembic/ash_authenticatio… | related |
| https://github.com/team-alembic/ash_authenticatio… | patch |
Impacted products
2 products
| Vendor | Product | Version | |
|---|---|---|---|
| team-alembic | ash_authentication |
Affected:
5.0.0-rc.10 , < 5.0.0-rc.14
(semver)
cpe:2.3:a:team-alembic:ash_authentication:*:*:*:*:*:*:*:* |
|
| team-alembic | ash_authentication |
Affected:
64530644f9b37ebb76ca14aeb83a77597a0034b7 , < 73ad16e452670bbf843550a13361bd41e72ad964
(git)
cpe:2.3:a:team-alembic:ash_authentication:*:*:*:*:*:*:*:* |
{
"containers": {
"adp": [
{
"metrics": [
{
"other": {
"content": {
"id": "CVE-2026-91039",
"options": [
{
"Exploitation": "none"
},
{
"Automatable": "no"
},
{
"Technical Impact": "total"
}
],
"role": "CISA Coordinator",
"timestamp": "2026-09-17T19:40:12.687953Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"providerMetadata": {
"dateUpdated": "2026-09-17T19:40:32.068Z",
"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:team-alembic:ash_authentication:*:*:*:*:*:*:*:*"
],
"defaultStatus": "unaffected",
"packageName": "ash_authentication",
"packageURL": "pkg:hex/ash_authentication",
"product": "ash_authentication",
"repo": "https://github.com/team-alembic/ash_authentication",
"vendor": "team-alembic",
"versions": [
{
"lessThan": "5.0.0-rc.14",
"status": "affected",
"version": "5.0.0-rc.10",
"versionType": "semver"
}
]
},
{
"collectionURL": "https://github.com",
"cpes": [
"cpe:2.3:a:team-alembic:ash_authentication:*:*:*:*:*:*:*:*"
],
"defaultStatus": "unaffected",
"packageName": "team-alembic/ash_authentication",
"packageURL": "pkg:github/team-alembic/ash_authentication",
"product": "ash_authentication",
"repo": "https://github.com/team-alembic/ash_authentication",
"vendor": "team-alembic",
"versions": [
{
"lessThan": "73ad16e452670bbf843550a13361bd41e72ad964",
"status": "affected",
"version": "64530644f9b37ebb76ca14aeb83a77597a0034b7",
"versionType": "git"
}
]
}
],
"configurations": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003eOnly deployments running a \u003ccode\u003edynamic_oidc\u003c/code\u003e strategy with more than one identity-provider connection are exposed, since a single connection has no second namespace to collide with.\u003c/p\u003e\n\u003cp\u003eTwo partial mitigations exist and neither is sufficient. A \u003ccode\u003econfirmation\u003c/code\u003e add-on incidentally blocks the takeover only while the victim is unconfirmed, leaving confirmed victims and confirmation-free applications exposed. Ash multitenancy isolates only a one-connection-per-tenant topology, so non-multitenant deployments and tenants holding several connections get no isolation; connection namespacing is orthogonal to tenancy.\u003c/p\u003e"
},
{
"base64": false,
"type": "text/markdown",
"value": "Only deployments running a `dynamic_oidc` strategy with more than one identity-provider connection are exposed, since a single connection has no second namespace to collide with.\n\nTwo partial mitigations exist and neither is sufficient. A `confirmation` add-on incidentally blocks the takeover only while the victim is unconfirmed, leaving confirmed victims and confirmation-free applications exposed. Ash multitenancy isolates only a one-connection-per-tenant topology, so non-multitenant deployments and tenants holding several connections get no isolation; connection namespacing is orthogonal to tenancy."
}
],
"value": "Only deployments running a dynamic_oidc strategy with more than one identity-provider connection are exposed, since a single connection has no second namespace to collide with.\n\nTwo partial mitigations exist and neither is sufficient. A confirmation add-on incidentally blocks the takeover only while the victim is unconfirmed, leaving confirmed victims and confirmation-free applications exposed. Ash multitenancy isolates only a one-connection-per-tenant topology, so non-multitenant deployments and tenants holding several connections get no isolation; connection namespacing is orthogonal to tenancy."
}
],
"cpeApplicability": [
{
"nodes": [
{
"cpeMatch": [
{
"criteria": "cpe:2.3:a:team-alembic:ash_authentication:*:*:*:*:*:*:*:*",
"versionEndExcluding": "5.0.0-rc.14",
"versionStartIncluding": "5.0.0-rc.10",
"vulnerable": true
}
],
"negate": false,
"operator": "OR"
}
],
"operator": "AND"
}
],
"credits": [
{
"lang": "en",
"type": "reporter",
"value": "Jace"
},
{
"lang": "en",
"type": "coordinator",
"value": "Jonatan M\u00e4nnchen / EEF"
},
{
"lang": "en",
"type": "reporter",
"value": "manus-pi"
},
{
"lang": "en",
"type": "remediation developer",
"value": "James Harton"
}
],
"dateAssigned": "2026-09-17T05:25:04.000Z",
"descriptions": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003eAuthentication Bypass by Spoofing vulnerability in team-alembic ash_authentication allows an attacker who operates one identity-provider connection of a \u003ccode\u003edynamic_oidc\u003c/code\u003e strategy to be signed in as a local user established through a different connection.\u003c/p\u003e\n\u003cp\u003eThe strategy is meant to keep each connection in its own identity namespace by writing every \u003ccode\u003eUserIdentity\u003c/code\u003e row\u0027s \u003ccode\u003estrategy\u003c/code\u003e field as \u003ccode\u003e\"\u0026lt;name\u0026gt;/\u0026lt;connection_id\u0026gt;\"\u003c/code\u003e, but that namespacing never takes effect. \u003ccode\u003e__connection_id__\u003c/code\u003e is populated only on the ephemeral runtime struct built per request in \u003ccode\u003edynamic_oidc/plug.ex\u003c/code\u003e, and \u003ccode\u003eDynamicOidc.IdentityChange.change/3\u003c/code\u003e re-fetches the strategy from the compile-time DSL through \u003ccode\u003eInfo.strategy_for_action\u003c/code\u003e, yielding the persisted struct whose \u003ccode\u003e__connection_id__\u003c/code\u003e is its \u003ccode\u003edefstruct\u003c/code\u003e default of \u003ccode\u003enil\u003c/code\u003e. \u003ccode\u003eOAuth2.identity_strategy_name/1\u003c/code\u003e therefore falls back to the bare strategy name for both the identity write and the reads in \u003ccode\u003eoauth2/user_resolver.ex\u003c/code\u003e and \u003ccode\u003eoauth2/sign_in_preparation.ex\u003c/code\u003e. Since the identity resource\u0027s unique key is \u003ccode\u003e(uid, strategy)\u003c/code\u003e, one row exists per \u003ccode\u003esub\u003c/code\u003e across every connection, and the identity-match branch runs before any email check. Neither strategy handles \u003ccode\u003eiss\u003c/code\u003e, so nothing else distinguishes the issuers: OpenID Connect Core section 5.7 makes \u003ccode\u003esub\u003c/code\u003e unique only within an issuer, so two connections numbering subjects independently share one subject space.\u003c/p\u003e\n\u003cp\u003eThis issue affects ash_authentication: from 5.0.0-rc.10 before 5.0.0-rc.14.\u003c/p\u003e"
},
{
"base64": false,
"type": "text/markdown",
"value": "Authentication Bypass by Spoofing vulnerability in team-alembic ash_authentication allows an attacker who operates one identity-provider connection of a `dynamic_oidc` strategy to be signed in as a local user established through a different connection.\n\nThe strategy is meant to keep each connection in its own identity namespace by writing every `UserIdentity` row\u0027s `strategy` field as `\"\u003cname\u003e/\u003cconnection_id\u003e\"`, but that namespacing never takes effect. `__connection_id__` is populated only on the ephemeral runtime struct built per request in `dynamic_oidc/plug.ex`, and `DynamicOidc.IdentityChange.change/3` re-fetches the strategy from the compile-time DSL through `Info.strategy_for_action`, yielding the persisted struct whose `__connection_id__` is its `defstruct` default of `nil`. `OAuth2.identity_strategy_name/1` therefore falls back to the bare strategy name for both the identity write and the reads in `oauth2/user_resolver.ex` and `oauth2/sign_in_preparation.ex`. Since the identity resource\u0027s unique key is `(uid, strategy)`, one row exists per `sub` across every connection, and the identity-match branch runs before any email check. Neither strategy handles `iss`, so nothing else distinguishes the issuers: OpenID Connect Core section 5.7 makes `sub` unique only within an issuer, so two connections numbering subjects independently share one subject space.\n\nThis issue affects ash_authentication: from 5.0.0-rc.10 before 5.0.0-rc.14."
}
],
"value": "Authentication Bypass by Spoofing vulnerability in team-alembic ash_authentication allows an attacker who operates one identity-provider connection of a dynamic_oidc strategy to be signed in as a local user established through a different connection.\n\nThe strategy is meant to keep each connection in its own identity namespace by writing every UserIdentity row\u0027s strategy field as \"\u003cname\u003e/\u003cconnection_id\u003e\", but that namespacing never takes effect. __connection_id__ is populated only on the ephemeral runtime struct built per request in dynamic_oidc/plug.ex, and DynamicOidc.IdentityChange.change/3 re-fetches the strategy from the compile-time DSL through Info.strategy_for_action, yielding the persisted struct whose __connection_id__ is its defstruct default of nil. OAuth2.identity_strategy_name/1 therefore falls back to the bare strategy name for both the identity write and the reads in oauth2/user_resolver.ex and oauth2/sign_in_preparation.ex. Since the identity resource\u0027s unique key is (uid, strategy), one row exists per sub across every connection, and the identity-match branch runs before any email check. Neither strategy handles iss, so nothing else distinguishes the issuers: OpenID Connect Core section 5.7 makes sub unique only within an issuer, so two connections numbering subjects independently share one subject space.\n\nThis issue affects ash_authentication: from 5.0.0-rc.10 before 5.0.0-rc.14."
}
],
"impacts": [
{
"capecId": "CAPEC-21",
"descriptions": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003eAn attacker who can obtain or choose their \u003ccode\u003esub\u003c/code\u003e on any connection served by a \u003ccode\u003edynamic_oidc\u003c/code\u003e strategy is authenticated as the local user established through a different connection, with no interaction from the victim and no pre-existing account on the application. Token, nonce and audience validation all pass legitimately, because they only prove the assertion came from the attacker\u0027s own identity provider.\u003c/p\u003e\n\u003cp\u003eThe same collision also occurs with no attacker at all: two honest providers numbering subjects sequentially produce overlapping \u003ccode\u003esub\u003c/code\u003e values and silently merge distinct users, so this may already have happened in affected deployments.\u003c/p\u003e"
},
{
"base64": false,
"type": "text/markdown",
"value": "An attacker who can obtain or choose their `sub` on any connection served by a `dynamic_oidc` strategy is authenticated as the local user established through a different connection, with no interaction from the victim and no pre-existing account on the application. Token, nonce and audience validation all pass legitimately, because they only prove the assertion came from the attacker\u0027s own identity provider.\n\nThe same collision also occurs with no attacker at all: two honest providers numbering subjects sequentially produce overlapping `sub` values and silently merge distinct users, so this may already have happened in affected deployments."
}
],
"value": "An attacker who can obtain or choose their sub on any connection served by a dynamic_oidc strategy is authenticated as the local user established through a different connection, with no interaction from the victim and no pre-existing account on the application. Token, nonce and audience validation all pass legitimately, because they only prove the assertion came from the attacker\u0027s own identity provider.\n\nThe same collision also occurs with no attacker at all: two honest providers numbering subjects sequentially produce overlapping sub values and silently merge distinct users, so this may already have happened in affected deployments."
}
]
}
],
"metrics": [
{
"cvssV4_0": {
"Automatable": "NOT_DEFINED",
"Recovery": "NOT_DEFINED",
"Safety": "NOT_DEFINED",
"attackComplexity": "LOW",
"attackRequirements": "PRESENT",
"attackVector": "NETWORK",
"baseScore": 9.1,
"baseSeverity": "CRITICAL",
"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:H/VI:H/VA:N/SC:N/SI:N/SA:N",
"version": "4.0",
"vulnAvailabilityImpact": "NONE",
"vulnConfidentialityImpact": "HIGH",
"vulnIntegrityImpact": "HIGH",
"vulnerabilityResponseEffort": "NOT_DEFINED"
},
"format": "CVSS",
"scenarios": [
{
"lang": "en",
"value": "GENERAL"
}
]
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-290",
"description": "CWE-290 Authentication Bypass by Spoofing",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-09-17T15:19:15.994Z",
"orgId": "6b3ad84c-e1a6-4bf7-a703-f496b71e49db",
"shortName": "EEF"
},
"references": [
{
"name": "GitHub Advisory",
"tags": [
"related",
"vendor-advisory"
],
"url": "https://github.com/team-alembic/ash_authentication/security/advisories/GHSA-73j9-m294-fvv9"
},
{
"name": "EEF CNA record for CVE-2026-91039",
"tags": [
"related"
],
"url": "https://cna.erlef.org/cves/CVE-2026-91039.html"
},
{
"name": "OSV record EEF-CVE-2026-91039",
"tags": [
"related"
],
"url": "https://osv.dev/vulnerability/EEF-CVE-2026-91039"
},
{
"name": "Introducing commit 6453064 in team-alembic/ash_authentication",
"tags": [
"related"
],
"url": "https://github.com/team-alembic/ash_authentication/commit/64530644f9b37ebb76ca14aeb83a77597a0034b7"
},
{
"name": "Fix commit 73ad16e in team-alembic/ash_authentication",
"tags": [
"patch"
],
"url": "https://github.com/team-alembic/ash_authentication/commit/73ad16e452670bbf843550a13361bd41e72ad964"
}
],
"solutions": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003eUpgrading is not sufficient on its own, for two reasons.\u003c/p\u003e\n\u003cp\u003eNamespacing changes the value the identity lookup keys on, so \u003ccode\u003eUserIdentity\u003c/code\u003e rows written before the fix, all holding the bare strategy name, no longer match. Each row\u0027s \u003ccode\u003estrategy\u003c/code\u003e must be relinked in place to \u003ccode\u003e\"\u0026lt;name\u0026gt;/\u0026lt;connection_id\u0026gt;\"\u003c/code\u003e. Deleting the rows does not work: the block is the account match that follows, refused under the default \u003ccode\u003eon_untrusted_email_match :reject\u003c/code\u003e whether the row exists or not, and deleting also discards the stored refresh token. Where a deployment has one connection the mapping is unambiguous and the update is mechanical, but it must run in the same deployment as the upgrade and before users sign in, or a newly written namespaced row can collide with a surviving bare row on the \u003ccode\u003e(uid, strategy)\u003c/code\u003e index.\u003c/p\u003e\n\u003cp\u003eThe fix also cannot separate accounts already merged, and the merge is not detectable from the database, because a collision never produced two rows to compare: the second user\u0027s identity was never created and the surviving row looks legitimate. Deployments running more than one connection must audit out of band, by exporting each connection\u0027s set of \u003ccode\u003esub\u003c/code\u003e values from its identity provider and intersecting them. Any \u003ccode\u003esub\u003c/code\u003e present in more than one set identifies an account that may have been merged.\u003c/p\u003e"
},
{
"base64": false,
"type": "text/markdown",
"value": "Upgrading is not sufficient on its own, for two reasons.\n\nNamespacing changes the value the identity lookup keys on, so `UserIdentity` rows written before the fix, all holding the bare strategy name, no longer match. Each row\u0027s `strategy` must be relinked in place to `\"\u003cname\u003e/\u003cconnection_id\u003e\"`. Deleting the rows does not work: the block is the account match that follows, refused under the default `on_untrusted_email_match :reject` whether the row exists or not, and deleting also discards the stored refresh token. Where a deployment has one connection the mapping is unambiguous and the update is mechanical, but it must run in the same deployment as the upgrade and before users sign in, or a newly written namespaced row can collide with a surviving bare row on the `(uid, strategy)` index.\n\nThe fix also cannot separate accounts already merged, and the merge is not detectable from the database, because a collision never produced two rows to compare: the second user\u0027s identity was never created and the surviving row looks legitimate. Deployments running more than one connection must audit out of band, by exporting each connection\u0027s set of `sub` values from its identity provider and intersecting them. Any `sub` present in more than one set identifies an account that may have been merged."
}
],
"value": "Upgrading is not sufficient on its own, for two reasons.\n\nNamespacing changes the value the identity lookup keys on, so UserIdentity rows written before the fix, all holding the bare strategy name, no longer match. Each row\u0027s strategy must be relinked in place to \"\u003cname\u003e/\u003cconnection_id\u003e\". Deleting the rows does not work: the block is the account match that follows, refused under the default on_untrusted_email_match :reject whether the row exists or not, and deleting also discards the stored refresh token. Where a deployment has one connection the mapping is unambiguous and the update is mechanical, but it must run in the same deployment as the upgrade and before users sign in, or a newly written namespaced row can collide with a surviving bare row on the (uid, strategy) index.\n\nThe fix also cannot separate accounts already merged, and the merge is not detectable from the database, because a collision never produced two rows to compare: the second user\u0027s identity was never created and the surviving row looks legitimate. Deployments running more than one connection must audit out of band, by exporting each connection\u0027s set of sub values from its identity provider and intersecting them. Any sub present in more than one set identifies an account that may have been merged."
}
],
"source": {
"discovery": "EXTERNAL"
},
"title": "dynamic_oidc identities are not namespaced by connection in ash_authentication, allowing cross-connection account takeover"
}
},
"cveMetadata": {
"assignerOrgId": "6b3ad84c-e1a6-4bf7-a703-f496b71e49db",
"assignerShortName": "EEF",
"cveId": "CVE-2026-91039",
"datePublished": "2026-09-17T15:19:15.994Z",
"dateReserved": "2026-09-15T15:30:01.883Z",
"dateUpdated": "2026-09-17T19:40:32.068Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
CVE-2026-88952 (GCVE-0-2026-88952)
Vulnerability from cvelistv5 – Published: 2026-09-17 14:15 – Updated: 2026-09-17 19:32
VLAI
EPSS
VEX
Title
OAuth2 sign-in attached to an existing account without an email comparison in AshAuthentication
Summary
Improper Authentication vulnerability in team-alembic AshAuthentication allows an attacker to be signed in as another user by linking an OAuth2 identity to an account that is not theirs.
AshAuthentication.Strategy.OAuth2.UserResolver.resolve/3 matches an existing account using the register action's upsert_identity keys, then gates linking the incoming provider identity to it on email_trusted?/2, which reads only the provider's email_verified boolean and never compares the provider's email value with the matched account's email. That gate assumes the account was matched by its email field, so under any other upsert_identity it is vacuous and an attacker presenting their own verified email is attached to, and issued a session for, an account matched on some other attribute. The same unguarded gate applies in OAuth2.SignInPreparation on the registration_enabled? false path, where the account is matched by the sign-in action's read filter instead. The upsert also rewrites the matched account's email to the attacker's address, so later account recovery reaches the attacker rather than the owner.
This issue affects ash_authentication: from 4.14.0 before 4.15.0 and from 5.0.0-rc.10 before 5.0.0-rc.14.
Severity
SSVC
Exploitation: none
Automatable: no
Technical Impact: total
CISA Coordinator · CISA-ADP (v2.0.3)
Decision recorded 2026-09-17 19:32 UTC
CWE
- CWE-287 - Improper Authentication
Assigner
References
7 references
Impacted products
2 products
| Vendor | Product | Version | |
|---|---|---|---|
| team-alembic | ash_authentication |
Affected:
4.14.0 , < 4.15.0
(semver)
Affected: 5.0.0-rc.10 , < 5.0.0-rc.14 (semver) cpe:2.3:a:team-alembic:ash_authentication:*:*:*:*:*:*:*:* |
|
| team-alembic | ash_authentication |
Affected:
64530644f9b37ebb76ca14aeb83a77597a0034b7 , < *
(git)
Affected: 42edcd8ebb13fafbb168f12591d7518ce0611fec , < * (git) cpe:2.3:a:team-alembic:ash_authentication:*:*:*:*:*:*:*:* |
{
"containers": {
"adp": [
{
"metrics": [
{
"other": {
"content": {
"id": "CVE-2026-88952",
"options": [
{
"Exploitation": "none"
},
{
"Automatable": "no"
},
{
"Technical Impact": "total"
}
],
"role": "CISA Coordinator",
"timestamp": "2026-09-17T19:32:22.090404Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"providerMetadata": {
"dateUpdated": "2026-09-17T19:32:55.621Z",
"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:team-alembic:ash_authentication:*:*:*:*:*:*:*:*"
],
"defaultStatus": "unaffected",
"modules": [
"\u0027Elixir.AshAuthentication.Strategy.OAuth2.UserResolver\u0027",
"\u0027Elixir.AshAuthentication.Strategy.OAuth2.SignInPreparation\u0027",
"\u0027Elixir.AshAuthentication.Strategy.OAuth2.IdentityChange\u0027",
"\u0027Elixir.AshAuthentication.Strategy.DynamicOidc.IdentityChange\u0027"
],
"packageName": "ash_authentication",
"packageURL": "pkg:hex/ash_authentication",
"product": "ash_authentication",
"programFiles": [
"lib/ash_authentication/strategies/oauth2/user_resolver.ex",
"lib/ash_authentication/strategies/oauth2/sign_in_preparation.ex",
"lib/ash_authentication/strategies/oauth2/identity_change.ex",
"lib/ash_authentication/strategies/dynamic_oidc/identity_change.ex"
],
"programRoutines": [
{
"name": "\u0027Elixir.AshAuthentication.Strategy.OAuth2.UserResolver\u0027:resolve/3"
},
{
"name": "\u0027Elixir.AshAuthentication.Strategy.OAuth2.UserResolver\u0027:email_trusted?/2"
},
{
"name": "\u0027Elixir.AshAuthentication.Strategy.OAuth2.SignInPreparation\u0027:prepare/3"
},
{
"name": "\u0027Elixir.AshAuthentication.Strategy.OAuth2.IdentityChange\u0027:change/3"
},
{
"name": "\u0027Elixir.AshAuthentication.Strategy.DynamicOidc.IdentityChange\u0027:change/3"
}
],
"repo": "https://github.com/team-alembic/ash_authentication",
"vendor": "team-alembic",
"versions": [
{
"lessThan": "4.15.0",
"status": "affected",
"version": "4.14.0",
"versionType": "semver"
},
{
"lessThan": "5.0.0-rc.14",
"status": "affected",
"version": "5.0.0-rc.10",
"versionType": "semver"
}
]
},
{
"collectionURL": "https://github.com",
"cpes": [
"cpe:2.3:a:team-alembic:ash_authentication:*:*:*:*:*:*:*:*"
],
"defaultStatus": "unaffected",
"modules": [
"\u0027Elixir.AshAuthentication.Strategy.OAuth2.UserResolver\u0027",
"\u0027Elixir.AshAuthentication.Strategy.OAuth2.SignInPreparation\u0027",
"\u0027Elixir.AshAuthentication.Strategy.OAuth2.IdentityChange\u0027",
"\u0027Elixir.AshAuthentication.Strategy.DynamicOidc.IdentityChange\u0027"
],
"packageName": "team-alembic/ash_authentication",
"packageURL": "pkg:github/team-alembic/ash_authentication",
"product": "ash_authentication",
"programFiles": [
"lib/ash_authentication/strategies/oauth2/user_resolver.ex",
"lib/ash_authentication/strategies/oauth2/sign_in_preparation.ex",
"lib/ash_authentication/strategies/oauth2/identity_change.ex",
"lib/ash_authentication/strategies/dynamic_oidc/identity_change.ex"
],
"programRoutines": [
{
"name": "\u0027Elixir.AshAuthentication.Strategy.OAuth2.UserResolver\u0027:resolve/3"
},
{
"name": "\u0027Elixir.AshAuthentication.Strategy.OAuth2.UserResolver\u0027:email_trusted?/2"
},
{
"name": "\u0027Elixir.AshAuthentication.Strategy.OAuth2.SignInPreparation\u0027:prepare/3"
},
{
"name": "\u0027Elixir.AshAuthentication.Strategy.OAuth2.IdentityChange\u0027:change/3"
},
{
"name": "\u0027Elixir.AshAuthentication.Strategy.DynamicOidc.IdentityChange\u0027:change/3"
}
],
"repo": "https://github.com/team-alembic/ash_authentication",
"vendor": "team-alembic",
"versions": [
{
"changes": [
{
"at": "738bf9f32f2aa0d1bb92ce9ca5c2476cb5710459",
"status": "unaffected"
},
{
"at": "2bd630eef8b7c8ae1e90e8fd43ba12fbc7e256ba",
"status": "unaffected"
}
],
"lessThan": "*",
"status": "affected",
"version": "64530644f9b37ebb76ca14aeb83a77597a0034b7",
"versionType": "git"
},
{
"changes": [
{
"at": "738bf9f32f2aa0d1bb92ce9ca5c2476cb5710459",
"status": "unaffected"
},
{
"at": "2bd630eef8b7c8ae1e90e8fd43ba12fbc7e256ba",
"status": "unaffected"
}
],
"lessThan": "*",
"status": "affected",
"version": "42edcd8ebb13fafbb168f12591d7518ce0611fec",
"versionType": "git"
}
]
}
],
"configurations": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003eThe strategy must have \u003ccode\u003etrust_email_verified?\u003c/code\u003e enabled, and the account must be matched on something other than the email: a register action whose \u003ccode\u003eupsert_identity\u003c/code\u003e keys are not the email attribute, or, with \u003ccode\u003eregistration_enabled? false\u003c/code\u003e, a sign-in action whose read filter is not the email.\u003c/p\u003e\n\u003cp\u003e\u003ccode\u003etrust_email_verified?\u003c/code\u003e defaults to \u003ccode\u003efalse\u003c/code\u003e on the base \u003ccode\u003eoauth2\u003c/code\u003e strategy, but the \u003ccode\u003eapple\u003c/code\u003e, \u003ccode\u003eauth0\u003c/code\u003e, \u003ccode\u003egithub\u003c/code\u003e, \u003ccode\u003egoogle\u003c/code\u003e and \u003ccode\u003eslack\u003c/code\u003e strategies each set it to \u003ccode\u003etrue\u003c/code\u003e in their own DSL.\u003c/p\u003e"
},
{
"base64": false,
"type": "text/markdown",
"value": "The strategy must have `trust_email_verified?` enabled, and the account must be matched on something other than the email: a register action whose `upsert_identity` keys are not the email attribute, or, with `registration_enabled? false`, a sign-in action whose read filter is not the email.\n\n`trust_email_verified?` defaults to `false` on the base `oauth2` strategy, but the `apple`, `auth0`, `github`, `google` and `slack` strategies each set it to `true` in their own DSL."
}
],
"value": "The strategy must have trust_email_verified? enabled, and the account must be matched on something other than the email: a register action whose upsert_identity keys are not the email attribute, or, with registration_enabled? false, a sign-in action whose read filter is not the email.\n\ntrust_email_verified? defaults to false on the base oauth2 strategy, but the apple, auth0, github, google and slack strategies each set it to true in their own DSL."
}
],
"cpeApplicability": [
{
"nodes": [
{
"cpeMatch": [
{
"criteria": "cpe:2.3:a:team-alembic:ash_authentication:*:*:*:*:*:*:*:*",
"versionEndExcluding": "4.15.0",
"versionStartIncluding": "4.14.0",
"vulnerable": true
},
{
"criteria": "cpe:2.3:a:team-alembic:ash_authentication:*:*:*:*:*:*:*:*",
"versionEndExcluding": "5.0.0-rc.14",
"versionStartIncluding": "5.0.0-rc.10",
"vulnerable": true
}
],
"negate": false,
"operator": "OR"
}
],
"operator": "AND"
}
],
"credits": [
{
"lang": "en",
"type": "finder",
"value": "James Harton"
},
{
"lang": "en",
"type": "reporter",
"value": "James Harton"
},
{
"lang": "en",
"type": "remediation developer",
"value": "James Harton"
},
{
"lang": "en",
"type": "coordinator",
"value": "Jonatan M\u00e4nnchen / EEF"
}
],
"dateAssigned": "2026-09-17T00:20:23.000Z",
"descriptions": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003eImproper Authentication vulnerability in team-alembic AshAuthentication allows an attacker to be signed in as another user by linking an OAuth2 identity to an account that is not theirs.\u003c/p\u003e\n\u003cp\u003e\u003ccode\u003eAshAuthentication.Strategy.OAuth2.UserResolver.resolve/3\u003c/code\u003e matches an existing account using the register action\u0027s \u003ccode\u003eupsert_identity\u003c/code\u003e keys, then gates linking the incoming provider identity to it on \u003ccode\u003eemail_trusted?/2\u003c/code\u003e, which reads only the provider\u0027s \u003ccode\u003eemail_verified\u003c/code\u003e boolean and never compares the provider\u0027s email value with the matched account\u0027s email. That gate assumes the account was matched by its email field, so under any other \u003ccode\u003eupsert_identity\u003c/code\u003e it is vacuous and an attacker presenting their own verified email is attached to, and issued a session for, an account matched on some other attribute. The same unguarded gate applies in \u003ccode\u003eOAuth2.SignInPreparation\u003c/code\u003e on the \u003ccode\u003eregistration_enabled? false\u003c/code\u003e path, where the account is matched by the sign-in action\u0027s read filter instead. The upsert also rewrites the matched account\u0027s email to the attacker\u0027s address, so later account recovery reaches the attacker rather than the owner.\u003c/p\u003e\n\u003cp\u003eThis issue affects ash_authentication: from 4.14.0 before 4.15.0 and from 5.0.0-rc.10 before 5.0.0-rc.14.\u003c/p\u003e"
},
{
"base64": false,
"type": "text/markdown",
"value": "Improper Authentication vulnerability in team-alembic AshAuthentication allows an attacker to be signed in as another user by linking an OAuth2 identity to an account that is not theirs.\n\n`AshAuthentication.Strategy.OAuth2.UserResolver.resolve/3` matches an existing account using the register action\u0027s `upsert_identity` keys, then gates linking the incoming provider identity to it on `email_trusted?/2`, which reads only the provider\u0027s `email_verified` boolean and never compares the provider\u0027s email value with the matched account\u0027s email. That gate assumes the account was matched by its email field, so under any other `upsert_identity` it is vacuous and an attacker presenting their own verified email is attached to, and issued a session for, an account matched on some other attribute. The same unguarded gate applies in `OAuth2.SignInPreparation` on the `registration_enabled? false` path, where the account is matched by the sign-in action\u0027s read filter instead. The upsert also rewrites the matched account\u0027s email to the attacker\u0027s address, so later account recovery reaches the attacker rather than the owner.\n\nThis issue affects ash_authentication: from 4.14.0 before 4.15.0 and from 5.0.0-rc.10 before 5.0.0-rc.14."
}
],
"value": "Improper Authentication vulnerability in team-alembic AshAuthentication allows an attacker to be signed in as another user by linking an OAuth2 identity to an account that is not theirs.\n\nAshAuthentication.Strategy.OAuth2.UserResolver.resolve/3 matches an existing account using the register action\u0027s upsert_identity keys, then gates linking the incoming provider identity to it on email_trusted?/2, which reads only the provider\u0027s email_verified boolean and never compares the provider\u0027s email value with the matched account\u0027s email. That gate assumes the account was matched by its email field, so under any other upsert_identity it is vacuous and an attacker presenting their own verified email is attached to, and issued a session for, an account matched on some other attribute. The same unguarded gate applies in OAuth2.SignInPreparation on the registration_enabled? false path, where the account is matched by the sign-in action\u0027s read filter instead. The upsert also rewrites the matched account\u0027s email to the attacker\u0027s address, so later account recovery reaches the attacker rather than the owner.\n\nThis issue affects ash_authentication: from 4.14.0 before 4.15.0 and from 5.0.0-rc.10 before 5.0.0-rc.14."
}
],
"impacts": [
{
"capecId": "CAPEC-115",
"descriptions": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003eAn attacker who controls a provider account with a verified email of their own is signed in as a different local user, holding a session bearing that user\u0027s subject, with no interaction from the victim and no need to pre-register. Because the link also rewrites the matched account\u0027s email to the attacker\u0027s address, account recovery for the victim is redirected to the attacker and the compromise survives the provider identity being unlinked.\u003c/p\u003e"
},
{
"base64": false,
"type": "text/markdown",
"value": "An attacker who controls a provider account with a verified email of their own is signed in as a different local user, holding a session bearing that user\u0027s subject, with no interaction from the victim and no need to pre-register. Because the link also rewrites the matched account\u0027s email to the attacker\u0027s address, account recovery for the victim is redirected to the attacker and the compromise survives the provider identity being unlinked."
}
],
"value": "An attacker who controls a provider account with a verified email of their own is signed in as a different local user, holding a session bearing that user\u0027s subject, with no interaction from the victim and no need to pre-register. Because the link also rewrites the matched account\u0027s email to the attacker\u0027s address, account recovery for the victim is redirected to the attacker and the compromise survives the provider identity being unlinked."
}
]
}
],
"metrics": [
{
"cvssV4_0": {
"Automatable": "NOT_DEFINED",
"Recovery": "NOT_DEFINED",
"Safety": "NOT_DEFINED",
"attackComplexity": "LOW",
"attackRequirements": "PRESENT",
"attackVector": "NETWORK",
"baseScore": 9.1,
"baseSeverity": "CRITICAL",
"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:H/VI:H/VA:N/SC:N/SI:N/SA:N",
"version": "4.0",
"vulnAvailabilityImpact": "NONE",
"vulnConfidentialityImpact": "HIGH",
"vulnIntegrityImpact": "HIGH",
"vulnerabilityResponseEffort": "NOT_DEFINED"
},
"format": "CVSS",
"scenarios": [
{
"lang": "en",
"value": "GENERAL"
}
]
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-287",
"description": "CWE-287 Improper Authentication",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-09-17T14:15:19.506Z",
"orgId": "6b3ad84c-e1a6-4bf7-a703-f496b71e49db",
"shortName": "EEF"
},
"references": [
{
"name": "GitHub Advisory",
"tags": [
"related",
"vendor-advisory"
],
"url": "https://github.com/team-alembic/ash_authentication/security/advisories/GHSA-wc6x-276q-jrf9"
},
{
"name": "EEF CNA record for CVE-2026-88952",
"tags": [
"related"
],
"url": "https://cna.erlef.org/cves/CVE-2026-88952.html"
},
{
"name": "OSV record EEF-CVE-2026-88952",
"tags": [
"related"
],
"url": "https://osv.dev/vulnerability/EEF-CVE-2026-88952"
},
{
"name": "Introducing commit 6453064 in team-alembic/ash_authentication",
"tags": [
"related"
],
"url": "https://github.com/team-alembic/ash_authentication/commit/64530644f9b37ebb76ca14aeb83a77597a0034b7"
},
{
"name": "Introducing commit 42edcd8 in team-alembic/ash_authentication",
"tags": [
"related"
],
"url": "https://github.com/team-alembic/ash_authentication/commit/42edcd8ebb13fafbb168f12591d7518ce0611fec"
},
{
"name": "Fix commit 738bf9f in team-alembic/ash_authentication",
"tags": [
"patch"
],
"url": "https://github.com/team-alembic/ash_authentication/commit/738bf9f32f2aa0d1bb92ce9ca5c2476cb5710459"
},
{
"name": "Fix commit 2bd630e in team-alembic/ash_authentication",
"tags": [
"patch"
],
"url": "https://github.com/team-alembic/ash_authentication/commit/2bd630eef8b7c8ae1e90e8fd43ba12fbc7e256ba"
}
],
"solutions": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003eUpgrading prevents new links but does not unpick existing ones. An account already linked through this path stays linked, and a victim\u0027s email may already have been rewritten to the attacker\u0027s address.\u003c/p\u003e\n\u003cp\u003eOperators whose register action or sign-in action matched on anything other than the email should review their \u003ccode\u003eUserIdentity\u003c/code\u003e rows for links whose provider email does not match the linked account\u0027s email, and check affected accounts for a rewritten email address.\u003c/p\u003e"
},
{
"base64": false,
"type": "text/markdown",
"value": "Upgrading prevents new links but does not unpick existing ones. An account already linked through this path stays linked, and a victim\u0027s email may already have been rewritten to the attacker\u0027s address.\n\nOperators whose register action or sign-in action matched on anything other than the email should review their `UserIdentity` rows for links whose provider email does not match the linked account\u0027s email, and check affected accounts for a rewritten email address."
}
],
"value": "Upgrading prevents new links but does not unpick existing ones. An account already linked through this path stays linked, and a victim\u0027s email may already have been rewritten to the attacker\u0027s address.\n\nOperators whose register action or sign-in action matched on anything other than the email should review their UserIdentity rows for links whose provider email does not match the linked account\u0027s email, and check affected accounts for a rewritten email address."
}
],
"source": {
"discovery": "INTERNAL"
},
"title": "OAuth2 sign-in attached to an existing account without an email comparison in AshAuthentication",
"workarounds": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003eSet \u003ccode\u003etrust_email_verified? false\u003c/code\u003e on the affected strategy, which refuses the sign-in rather than linking it and closes both the register and the sign-in path.\u003c/p\u003e\n\u003cp\u003eAlternatively, key the register action\u0027s \u003ccode\u003eupsert_identity\u003c/code\u003e, or the sign-in action\u0027s read filter, on the email attribute, which restores the premise the gate assumes.\u003c/p\u003e"
},
{
"base64": false,
"type": "text/markdown",
"value": "Set `trust_email_verified? false` on the affected strategy, which refuses the sign-in rather than linking it and closes both the register and the sign-in path.\n\nAlternatively, key the register action\u0027s `upsert_identity`, or the sign-in action\u0027s read filter, on the email attribute, which restores the premise the gate assumes."
}
],
"value": "Set trust_email_verified? false on the affected strategy, which refuses the sign-in rather than linking it and closes both the register and the sign-in path.\n\nAlternatively, key the register action\u0027s upsert_identity, or the sign-in action\u0027s read filter, on the email attribute, which restores the premise the gate assumes."
}
]
}
},
"cveMetadata": {
"assignerOrgId": "6b3ad84c-e1a6-4bf7-a703-f496b71e49db",
"assignerShortName": "EEF",
"cveId": "CVE-2026-88952",
"datePublished": "2026-09-17T14:15:19.506Z",
"dateReserved": "2026-09-16T10:30:02.169Z",
"dateUpdated": "2026-09-17T19:32:55.621Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
CVE-2026-85500 (GCVE-0-2026-85500)
Vulnerability from cvelistv5 – Published: 2026-09-17 13:09 – Updated: 2026-09-17 18:12
VLAI
EPSS
VEX
Title
`require_confirmed_with` is not enforced on the action and fails open on an unreadable attribute in AshAuthentication
Summary
Authentication Bypass by Primary Weakness vulnerability in team-alembic AshAuthentication allows an unconfirmed user to obtain a session, defeating a mandatory email confirmation requirement.
AshAuthentication.Strategy.Password.Actions.check_user/2 decides whether the attribute named by require_confirmed_with is set using a bare is_nil(Map.get(user, value)). When that attribute is not selected on the loaded record Map.get/2 returns %Ash.NotLoaded{}, and when a field policy denies it for the current actor it returns %Ash.ForbiddenField{}. Neither is nil, so the rejection branch is skipped and sign-i
require_confirmed_with is enforced in two places, and neither holds in every configuration. sign_in_with_token and register are checked only inside AshAuthentication.Strategy.Password.Actions, not on the action itself, so any caller that invokes the action directly skips the check. An API layer such as AshGraphql or AshJsonApi invokes the action directly, so this applies to the default configuration. Where a check does run it compares the confirmation attribute against nil. That attribute holds %Ash.NotLoaded{} or %Ash.ForbiddenField{} when it sets select_by_default?: false, when an API layer narrows the read's select, or when a field policy hides it from the sign-in actor. Neither struct is nil, so those configurations read every user as confirmed.
This issue affects ash_authentication: from 4.3.8 before 4.15.0 and from 5.0.0-rc.0 before 5.0.0-rc.14.
Severity
SSVC
Exploitation: none
Automatable: yes
Technical Impact: total
CISA Coordinator · CISA-ADP (v2.0.3)
Decision recorded 2026-09-17 18:12 UTC
CWE
- CWE-305 - Authentication Bypass by Primary Weakness
Assigner
References
6 references
Impacted products
2 products
| Vendor | Product | Version | |
|---|---|---|---|
| team-alembic | ash_authentication |
Affected:
4.3.8 , < 4.15.0
(semver)
Affected: 5.0.0-rc.0 , < 5.0.0-rc.14 (semver) cpe:2.3:a:team-alembic:ash_authentication:*:*:*:*:*:*:*:* |
|
| team-alembic | ash_authentication |
Affected:
7d37bc6e4df6697b5813d2f373f0fdb08f813f98 , < *
(git)
cpe:2.3:a:team-alembic:ash_authentication:*:*:*:*:*:*:*:* |
{
"containers": {
"adp": [
{
"metrics": [
{
"other": {
"content": {
"id": "CVE-2026-85500",
"options": [
{
"Exploitation": "none"
},
{
"Automatable": "yes"
},
{
"Technical Impact": "total"
}
],
"role": "CISA Coordinator",
"timestamp": "2026-09-17T18:12:03.493938Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"providerMetadata": {
"dateUpdated": "2026-09-17T18:12:54.127Z",
"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:team-alembic:ash_authentication:*:*:*:*:*:*:*:*"
],
"defaultStatus": "unaffected",
"modules": [
"\u0027Elixir.AshAuthentication.Strategy.Password.Actions\u0027"
],
"packageName": "ash_authentication",
"packageURL": "pkg:hex/ash_authentication",
"product": "ash_authentication",
"programFiles": [
"lib/ash_authentication/strategies/password/actions.ex"
],
"programRoutines": [
{
"name": "\u0027Elixir.AshAuthentication.Strategy.Password.Actions\u0027:check_user/2"
},
{
"name": "\u0027Elixir.AshAuthentication.Strategy.Password.Actions\u0027:sign_in_with_token/3"
},
{
"name": "\u0027Elixir.AshAuthentication.Strategy.Password.Actions\u0027:register/3"
}
],
"repo": "https://github.com/team-alembic/ash_authentication",
"vendor": "team-alembic",
"versions": [
{
"lessThan": "4.15.0",
"status": "affected",
"version": "4.3.8",
"versionType": "semver"
},
{
"lessThan": "5.0.0-rc.14",
"status": "affected",
"version": "5.0.0-rc.0",
"versionType": "semver"
}
]
},
{
"collectionURL": "https://github.com",
"cpes": [
"cpe:2.3:a:team-alembic:ash_authentication:*:*:*:*:*:*:*:*"
],
"defaultStatus": "unaffected",
"modules": [
"\u0027Elixir.AshAuthentication.Strategy.Password.Actions\u0027"
],
"packageName": "team-alembic/ash_authentication",
"packageURL": "pkg:github/team-alembic/ash_authentication",
"product": "ash_authentication",
"programFiles": [
"lib/ash_authentication/strategies/password/actions.ex"
],
"programRoutines": [
{
"name": "\u0027Elixir.AshAuthentication.Strategy.Password.Actions\u0027:check_user/2"
},
{
"name": "\u0027Elixir.AshAuthentication.Strategy.Password.Actions\u0027:sign_in_with_token/3"
},
{
"name": "\u0027Elixir.AshAuthentication.Strategy.Password.Actions\u0027:register/3"
}
],
"repo": "https://github.com/team-alembic/ash_authentication",
"vendor": "team-alembic",
"versions": [
{
"changes": [
{
"at": "17f4c25a372d1778c9cc457759e6357570d83711",
"status": "unaffected"
},
{
"at": "1076639a9d40213088d110c79ba6735b8cc85b16",
"status": "unaffected"
}
],
"lessThan": "*",
"status": "affected",
"version": "7d37bc6e4df6697b5813d2f373f0fdb08f813f98",
"versionType": "git"
}
]
}
],
"cpeApplicability": [
{
"nodes": [
{
"cpeMatch": [
{
"criteria": "cpe:2.3:a:team-alembic:ash_authentication:*:*:*:*:*:*:*:*",
"versionEndExcluding": "4.15.0",
"versionStartIncluding": "4.3.8",
"vulnerable": true
},
{
"criteria": "cpe:2.3:a:team-alembic:ash_authentication:*:*:*:*:*:*:*:*",
"versionEndExcluding": "5.0.0-rc.14",
"versionStartIncluding": "5.0.0-rc.0",
"vulnerable": true
}
],
"negate": false,
"operator": "OR"
}
],
"operator": "AND"
}
],
"credits": [
{
"lang": "en",
"type": "reporter",
"value": "Peter Ullrich"
},
{
"lang": "en",
"type": "analyst",
"value": "Jonatan M\u00e4nnchen / EEF"
},
{
"lang": "en",
"type": "remediation developer",
"value": "James Harton"
}
],
"dateAssigned": "2026-09-11T18:24:17.000Z",
"descriptions": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003eAuthentication Bypass by Primary Weakness vulnerability in team-alembic AshAuthentication allows an unconfirmed user to obtain a session, defeating a mandatory email confirmation requirement.\u003c/p\u003e\n\u003cp\u003e\u003ccode\u003eAshAuthentication.Strategy.Password.Actions.check_user/2\u003c/code\u003e decides whether the attribute named by \u003ccode\u003erequire_confirmed_with\u003c/code\u003e is set using a bare \u003ccode\u003eis_nil(Map.get(user, value))\u003c/code\u003e. When that attribute is not selected on the loaded record \u003ccode\u003eMap.get/2\u003c/code\u003e returns \u003ccode\u003e%Ash.NotLoaded{}\u003c/code\u003e, and when a field policy denies it for the current actor it returns \u003ccode\u003e%Ash.ForbiddenField{}\u003c/code\u003e. Neither is \u003ccode\u003enil\u003c/code\u003e, so the rejection branch is skipped and sign-i\u003c/p\u003e\n\u003cp\u003e\u003ccode\u003erequire_confirmed_with\u003c/code\u003e is enforced in two places, and neither holds in every\nconfiguration. \u003ccode\u003esign_in_with_token\u003c/code\u003e and \u003ccode\u003eregister\u003c/code\u003e are checked only inside\n\u003ccode\u003eAshAuthentication.Strategy.Password.Actions\u003c/code\u003e, not on the action itself, so any caller\nthat invokes the action directly skips the check. An API layer such as \u003ccode\u003eAshGraphql\u003c/code\u003e or\n\u003ccode\u003eAshJsonApi\u003c/code\u003e invokes the action directly, so this applies to the default configuration.\nWhere a check does run it compares the confirmation attribute against \u003ccode\u003enil\u003c/code\u003e. That\nattribute holds \u003ccode\u003e%Ash.NotLoaded{}\u003c/code\u003e or \u003ccode\u003e%Ash.ForbiddenField{}\u003c/code\u003e when it sets\n\u003ccode\u003eselect_by_default?: false\u003c/code\u003e, when an API layer narrows the read\u0027s \u003ccode\u003eselect\u003c/code\u003e, or when a\nfield policy hides it from the sign-in actor. Neither struct is \u003ccode\u003enil\u003c/code\u003e, so those\nconfigurations read every user as confirmed.\u003c/p\u003e\n\u003cp\u003eThis issue affects ash_authentication: from 4.3.8 before 4.15.0 and from 5.0.0-rc.0 before 5.0.0-rc.14.\u003c/p\u003e"
},
{
"base64": false,
"type": "text/markdown",
"value": "Authentication Bypass by Primary Weakness vulnerability in team-alembic AshAuthentication allows an unconfirmed user to obtain a session, defeating a mandatory email confirmation requirement.\n\n`AshAuthentication.Strategy.Password.Actions.check_user/2` decides whether the attribute named by `require_confirmed_with` is set using a bare `is_nil(Map.get(user, value))`. When that attribute is not selected on the loaded record `Map.get/2` returns `%Ash.NotLoaded{}`, and when a field policy denies it for the current actor it returns `%Ash.ForbiddenField{}`. Neither is `nil`, so the rejection branch is skipped and sign-i\n\n`require_confirmed_with` is enforced in two places, and neither holds in every\nconfiguration. `sign_in_with_token` and `register` are checked only inside\n`AshAuthentication.Strategy.Password.Actions`, not on the action itself, so any caller\nthat invokes the action directly skips the check. An API layer such as `AshGraphql` or\n`AshJsonApi` invokes the action directly, so this applies to the default configuration.\nWhere a check does run it compares the confirmation attribute against `nil`. That\nattribute holds `%Ash.NotLoaded{}` or `%Ash.ForbiddenField{}` when it sets\n`select_by_default?: false`, when an API layer narrows the read\u0027s `select`, or when a\nfield policy hides it from the sign-in actor. Neither struct is `nil`, so those\nconfigurations read every user as confirmed.\n\nThis issue affects ash_authentication: from 4.3.8 before 4.15.0 and from 5.0.0-rc.0 before 5.0.0-rc.14."
}
],
"value": "Authentication Bypass by Primary Weakness vulnerability in team-alembic AshAuthentication allows an unconfirmed user to obtain a session, defeating a mandatory email confirmation requirement.\n\nAshAuthentication.Strategy.Password.Actions.check_user/2 decides whether the attribute named by require_confirmed_with is set using a bare is_nil(Map.get(user, value)). When that attribute is not selected on the loaded record Map.get/2 returns %Ash.NotLoaded{}, and when a field policy denies it for the current actor it returns %Ash.ForbiddenField{}. Neither is nil, so the rejection branch is skipped and sign-i\n\nrequire_confirmed_with is enforced in two places, and neither holds in every configuration. sign_in_with_token and register are checked only inside AshAuthentication.Strategy.Password.Actions, not on the action itself, so any caller that invokes the action directly skips the check. An API layer such as AshGraphql or AshJsonApi invokes the action directly, so this applies to the default configuration. Where a check does run it compares the confirmation attribute against nil. That attribute holds %Ash.NotLoaded{} or %Ash.ForbiddenField{} when it sets select_by_default?: false, when an API layer narrows the read\u0027s select, or when a field policy hides it from the sign-in actor. Neither struct is nil, so those configurations read every user as confirmed.\n\nThis issue affects ash_authentication: from 4.3.8 before 4.15.0 and from 5.0.0-rc.0 before 5.0.0-rc.14."
}
],
"impacts": [
{
"capecId": "CAPEC-115",
"descriptions": [
{
"lang": "en",
"value": "CAPEC-115 Authentication Bypass"
}
]
}
],
"metrics": [
{
"cvssV4_0": {
"Automatable": "NOT_DEFINED",
"Recovery": "NOT_DEFINED",
"Safety": "NOT_DEFINED",
"attackComplexity": "LOW",
"attackRequirements": "PRESENT",
"attackVector": "NETWORK",
"baseScore": 9.1,
"baseSeverity": "CRITICAL",
"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:H/VI:H/VA:N/SC:N/SI:N/SA:N",
"version": "4.0",
"vulnAvailabilityImpact": "NONE",
"vulnConfidentialityImpact": "HIGH",
"vulnIntegrityImpact": "HIGH",
"vulnerabilityResponseEffort": "NOT_DEFINED"
},
"format": "CVSS",
"scenarios": [
{
"lang": "en",
"value": "GENERAL"
}
]
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-305",
"description": "CWE-305 Authentication Bypass by Primary Weakness",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-09-17T13:09:43.000Z",
"orgId": "6b3ad84c-e1a6-4bf7-a703-f496b71e49db",
"shortName": "EEF"
},
"references": [
{
"tags": [
"vendor-advisory",
"related"
],
"url": "https://github.com/team-alembic/ash_authentication/security/advisories/GHSA-fc47-6pgw-wh22"
},
{
"name": "EEF CNA record for CVE-2026-85500",
"tags": [
"related"
],
"url": "https://cna.erlef.org/cves/CVE-2026-85500.html"
},
{
"name": "OSV record EEF-CVE-2026-85500",
"tags": [
"related"
],
"url": "https://osv.dev/vulnerability/EEF-CVE-2026-85500"
},
{
"name": "Introducing commit 7d37bc6 in team-alembic/ash_authentication",
"tags": [
"related"
],
"url": "https://github.com/team-alembic/ash_authentication/commit/7d37bc6e4df6697b5813d2f373f0fdb08f813f98"
},
{
"name": "Fix commit 17f4c25 in team-alembic/ash_authentication",
"tags": [
"patch"
],
"url": "https://github.com/team-alembic/ash_authentication/commit/17f4c25a372d1778c9cc457759e6357570d83711"
},
{
"name": "Fix commit 1076639 in team-alembic/ash_authentication",
"tags": [
"patch"
],
"url": "https://github.com/team-alembic/ash_authentication/commit/1076639a9d40213088d110c79ba6735b8cc85b16"
}
],
"source": {
"discovery": "INTERNAL"
},
"title": "`require_confirmed_with` is not enforced on the action and fails open on an unreadable attribute in AshAuthentication"
}
},
"cveMetadata": {
"assignerOrgId": "6b3ad84c-e1a6-4bf7-a703-f496b71e49db",
"assignerShortName": "EEF",
"cveId": "CVE-2026-85500",
"datePublished": "2026-09-17T13:09:43.000Z",
"dateReserved": "2026-09-07T23:45:01.895Z",
"dateUpdated": "2026-09-17T18:12:54.127Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
CVE-2026-86533 (GCVE-0-2026-86533)
Vulnerability from cvelistv5 – Published: 2026-09-17 13:09 – Updated: 2026-09-17 18:17
VLAI
EPSS
VEX
Title
Revoked session accepted because the session jti is never checked in AshAuthentication and AshAuthentication Phoenix
Summary
Insufficient Session Expiration vulnerability in team-alembic AshAuthentication and AshAuthentication Phoenix allows a revoked session to remain fully authenticated.
A resource configured with session_identifier :jti and require_token_presence_for_authentication? disabled stores its session value as <jti>:<subject>. The jti is there so that signing out can revoke that one session. Neither reader consults it: AshAuthentication.Plug.Helpers.authenticate_resource_from_session/4 and AshAuthentication.Phoenix.LiveSession.on_mount/4 both split the value with split_identifier/2, discard the jti and pass the bare subject to AshAuthentication.subject_to_user/3, which reloads the record. The token-presence branch of each function does check its token, calling AshAuthentication.TokenResource.Actions.get_token/3 with the jti and the purpose user. Because the revocation record is never read, neither its revoked state nor its expiry constrains the session, so a session captured before sign-out keeps working.
This issue affects ash_authentication: from 4.9.1 before 4.15.0 and from 5.0.0-rc.0 before 5.0.0-rc.14; ash_authentication_phoenix: from 2.10.0 before 2.17.4 and from 3.0.0-rc.0 before 3.0.0-rc.11.
Severity
SSVC
Exploitation: none
Automatable: yes
Technical Impact: total
CISA Coordinator · CISA-ADP (v2.0.3)
Decision recorded 2026-09-17 18:13 UTC
CWE
- CWE-613 - Insufficient Session Expiration
Assigner
References
10 references
Impacted products
4 products
| Vendor | Product | Version | |
|---|---|---|---|
| team-alembic | ash_authentication |
Affected:
4.9.1 , < 4.15.0
(semver)
Affected: 5.0.0-rc.0 , < 5.0.0-rc.14 (semver) cpe:2.3:a:team-alembic:ash_authentication:*:*:*:*:*:*:*:* |
|
| team-alembic | ash_authentication |
Affected:
fcaeb73f76f8f2e9aef8bf637690d2a20dd97596 , < *
(git)
cpe:2.3:a:team-alembic:ash_authentication:*:*:*:*:*:*:*:* |
|
| team-alembic | ash_authentication_phoenix |
Affected:
2.10.0 , < 2.17.4
(semver)
Affected: 3.0.0-rc.0 , < 3.0.0-rc.11 (semver) cpe:2.3:a:team-alembic:ash_authentication_phoenix:*:*:*:*:*:*:*:* |
|
| team-alembic | ash_authentication_phoenix |
Affected:
a3253fb4fc7145aeb403537af1c24d3a8d51ffb1 , < *
(git)
Affected: 0135217e34e621dac79ae3d9559aeee49304b0aa , < * (git) cpe:2.3:a:team-alembic:ash_authentication_phoenix:*:*:*:*:*:*:*:* |
Date Public
2026-09-17 13:09
{
"containers": {
"adp": [
{
"metrics": [
{
"other": {
"content": {
"id": "CVE-2026-86533",
"options": [
{
"Exploitation": "none"
},
{
"Automatable": "yes"
},
{
"Technical Impact": "total"
}
],
"role": "CISA Coordinator",
"timestamp": "2026-09-17T18:13:50.422619Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"providerMetadata": {
"dateUpdated": "2026-09-17T18:17:21.199Z",
"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:team-alembic:ash_authentication:*:*:*:*:*:*:*:*"
],
"defaultStatus": "unaffected",
"modules": [
"\u0027Elixir.AshAuthentication.Plug.Helpers\u0027"
],
"packageName": "ash_authentication",
"packageURL": "pkg:hex/ash_authentication",
"product": "ash_authentication",
"programFiles": [
"lib/ash_authentication/plug/helpers.ex"
],
"programRoutines": [
{
"name": "\u0027Elixir.AshAuthentication.Plug.Helpers\u0027:retrieve_from_session/3"
},
{
"name": "\u0027Elixir.AshAuthentication.Plug.Helpers\u0027:authenticate_resource_from_session/4"
}
],
"repo": "https://github.com/team-alembic/ash_authentication",
"vendor": "team-alembic",
"versions": [
{
"lessThan": "4.15.0",
"status": "affected",
"version": "4.9.1",
"versionType": "semver"
},
{
"lessThan": "5.0.0-rc.14",
"status": "affected",
"version": "5.0.0-rc.0",
"versionType": "semver"
}
]
},
{
"collectionURL": "https://github.com",
"cpes": [
"cpe:2.3:a:team-alembic:ash_authentication:*:*:*:*:*:*:*:*"
],
"defaultStatus": "unaffected",
"modules": [
"\u0027Elixir.AshAuthentication.Plug.Helpers\u0027"
],
"packageName": "team-alembic/ash_authentication",
"packageURL": "pkg:github/team-alembic/ash_authentication",
"product": "ash_authentication",
"programFiles": [
"lib/ash_authentication/plug/helpers.ex"
],
"programRoutines": [
{
"name": "\u0027Elixir.AshAuthentication.Plug.Helpers\u0027:retrieve_from_session/3"
},
{
"name": "\u0027Elixir.AshAuthentication.Plug.Helpers\u0027:authenticate_resource_from_session/4"
}
],
"repo": "https://github.com/team-alembic/ash_authentication",
"vendor": "team-alembic",
"versions": [
{
"changes": [
{
"at": "a3f49f758f013d2ff086dd9c5ef2d94e921711b4",
"status": "unaffected"
},
{
"at": "e28e911caa9728d76329afdb0fb26742ffe4eeef",
"status": "unaffected"
}
],
"lessThan": "*",
"status": "affected",
"version": "fcaeb73f76f8f2e9aef8bf637690d2a20dd97596",
"versionType": "git"
}
]
},
{
"collectionURL": "https://repo.hex.pm",
"cpes": [
"cpe:2.3:a:team-alembic:ash_authentication_phoenix:*:*:*:*:*:*:*:*"
],
"defaultStatus": "unaffected",
"modules": [
"\u0027Elixir.AshAuthentication.Phoenix.LiveSession\u0027"
],
"packageName": "ash_authentication_phoenix",
"packageURL": "pkg:hex/ash_authentication_phoenix",
"product": "ash_authentication_phoenix",
"programFiles": [
"lib/ash_authentication_phoenix/live_session.ex"
],
"programRoutines": [
{
"name": "\u0027Elixir.AshAuthentication.Phoenix.LiveSession\u0027:on_mount/4"
}
],
"repo": "https://github.com/team-alembic/ash_authentication_phoenix",
"vendor": "team-alembic",
"versions": [
{
"lessThan": "2.17.4",
"status": "affected",
"version": "2.10.0",
"versionType": "semver"
},
{
"lessThan": "3.0.0-rc.11",
"status": "affected",
"version": "3.0.0-rc.0",
"versionType": "semver"
}
]
},
{
"collectionURL": "https://github.com",
"cpes": [
"cpe:2.3:a:team-alembic:ash_authentication_phoenix:*:*:*:*:*:*:*:*"
],
"defaultStatus": "unaffected",
"modules": [
"\u0027Elixir.AshAuthentication.Phoenix.LiveSession\u0027"
],
"packageName": "team-alembic/ash_authentication_phoenix",
"packageURL": "pkg:github/team-alembic/ash_authentication_phoenix",
"product": "ash_authentication_phoenix",
"programFiles": [
"lib/ash_authentication_phoenix/live_session.ex"
],
"programRoutines": [
{
"name": "\u0027Elixir.AshAuthentication.Phoenix.LiveSession\u0027:on_mount/4"
}
],
"repo": "https://github.com/team-alembic/ash_authentication_phoenix",
"vendor": "team-alembic",
"versions": [
{
"changes": [
{
"at": "f7ab005a2aac09707a25521653c94893d328cc52",
"status": "unaffected"
},
{
"at": "0135217e34e621dac79ae3d9559aeee49304b0aa",
"status": "unaffected"
}
],
"lessThan": "*",
"status": "affected",
"version": "a3253fb4fc7145aeb403537af1c24d3a8d51ffb1",
"versionType": "git"
},
{
"changes": [
{
"at": "f7ab005a2aac09707a25521653c94893d328cc52",
"status": "unaffected"
},
{
"at": "0135217e34e621dac79ae3d9559aeee49304b0aa",
"status": "unaffected"
}
],
"lessThan": "*",
"status": "affected",
"version": "0135217e34e621dac79ae3d9559aeee49304b0aa",
"versionType": "git"
}
]
}
],
"cpeApplicability": [
{
"nodes": [
{
"cpeMatch": [
{
"criteria": "cpe:2.3:a:team-alembic:ash_authentication:*:*:*:*:*:*:*:*",
"versionEndExcluding": "4.15.0",
"versionStartIncluding": "4.9.1",
"vulnerable": true
},
{
"criteria": "cpe:2.3:a:team-alembic:ash_authentication:*:*:*:*:*:*:*:*",
"versionEndExcluding": "5.0.0-rc.14",
"versionStartIncluding": "5.0.0-rc.0",
"vulnerable": true
},
{
"criteria": "cpe:2.3:a:team-alembic:ash_authentication_phoenix:*:*:*:*:*:*:*:*",
"versionEndExcluding": "2.17.4",
"versionStartIncluding": "2.10.0",
"vulnerable": true
},
{
"criteria": "cpe:2.3:a:team-alembic:ash_authentication_phoenix:*:*:*:*:*:*:*:*",
"versionEndExcluding": "3.0.0-rc.11",
"versionStartIncluding": "3.0.0-rc.0",
"vulnerable": true
}
],
"negate": false,
"operator": "OR"
}
],
"operator": "AND"
}
],
"credits": [
{
"lang": "en",
"type": "reporter",
"value": "Peter Ullrich"
},
{
"lang": "en",
"type": "analyst",
"value": "Jonatan M\u00e4nnchen / EEF"
},
{
"lang": "en",
"type": "remediation developer",
"value": "James Harton"
}
],
"dateAssigned": "2026-09-11T18:52:39.000Z",
"datePublic": "2026-09-17T13:09:38.000Z",
"descriptions": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003eInsufficient Session Expiration vulnerability in team-alembic AshAuthentication and AshAuthentication Phoenix allows a revoked session to remain fully authenticated.\u003c/p\u003e\n\u003cp\u003eA resource configured with \u003ccode\u003esession_identifier :jti\u003c/code\u003e and \u003ccode\u003erequire_token_presence_for_authentication?\u003c/code\u003e disabled stores its session value as \u003ccode\u003e\u0026lt;jti\u0026gt;:\u0026lt;subject\u0026gt;\u003c/code\u003e. The \u003ccode\u003ejti\u003c/code\u003e is there so that signing out can revoke that one session. Neither reader consults it: \u003ccode\u003eAshAuthentication.Plug.Helpers.authenticate_resource_from_session/4\u003c/code\u003e and \u003ccode\u003eAshAuthentication.Phoenix.LiveSession.on_mount/4\u003c/code\u003e both split the value with \u003ccode\u003esplit_identifier/2\u003c/code\u003e, discard the \u003ccode\u003ejti\u003c/code\u003e and pass the bare subject to \u003ccode\u003eAshAuthentication.subject_to_user/3\u003c/code\u003e, which reloads the record. The token-presence branch of each function does check its token, calling \u003ccode\u003eAshAuthentication.TokenResource.Actions.get_token/3\u003c/code\u003e with the \u003ccode\u003ejti\u003c/code\u003e and the purpose \u003ccode\u003euser\u003c/code\u003e. Because the revocation record is never read, neither its revoked state nor its expiry constrains the session, so a session captured before sign-out keeps working.\u003c/p\u003e\n\u003cp\u003eThis issue affects ash_authentication: from 4.9.1 before 4.15.0 and from 5.0.0-rc.0 before 5.0.0-rc.14; ash_authentication_phoenix: from 2.10.0 before 2.17.4 and from 3.0.0-rc.0 before 3.0.0-rc.11.\u003c/p\u003e"
},
{
"base64": false,
"type": "text/markdown",
"value": "Insufficient Session Expiration vulnerability in team-alembic AshAuthentication and AshAuthentication Phoenix allows a revoked session to remain fully authenticated.\n\nA resource configured with `session_identifier :jti` and `require_token_presence_for_authentication?` disabled stores its session value as `\u003cjti\u003e:\u003csubject\u003e`. The `jti` is there so that signing out can revoke that one session. Neither reader consults it: `AshAuthentication.Plug.Helpers.authenticate_resource_from_session/4` and `AshAuthentication.Phoenix.LiveSession.on_mount/4` both split the value with `split_identifier/2`, discard the `jti` and pass the bare subject to `AshAuthentication.subject_to_user/3`, which reloads the record. The token-presence branch of each function does check its token, calling `AshAuthentication.TokenResource.Actions.get_token/3` with the `jti` and the purpose `user`. Because the revocation record is never read, neither its revoked state nor its expiry constrains the session, so a session captured before sign-out keeps working.\n\nThis issue affects ash_authentication: from 4.9.1 before 4.15.0 and from 5.0.0-rc.0 before 5.0.0-rc.14; ash_authentication_phoenix: from 2.10.0 before 2.17.4 and from 3.0.0-rc.0 before 3.0.0-rc.11."
}
],
"value": "Insufficient Session Expiration vulnerability in team-alembic AshAuthentication and AshAuthentication Phoenix allows a revoked session to remain fully authenticated.\n\nA resource configured with session_identifier :jti and require_token_presence_for_authentication? disabled stores its session value as \u003cjti\u003e:\u003csubject\u003e. The jti is there so that signing out can revoke that one session. Neither reader consults it: AshAuthentication.Plug.Helpers.authenticate_resource_from_session/4 and AshAuthentication.Phoenix.LiveSession.on_mount/4 both split the value with split_identifier/2, discard the jti and pass the bare subject to AshAuthentication.subject_to_user/3, which reloads the record. The token-presence branch of each function does check its token, calling AshAuthentication.TokenResource.Actions.get_token/3 with the jti and the purpose user. Because the revocation record is never read, neither its revoked state nor its expiry constrains the session, so a session captured before sign-out keeps working.\n\nThis issue affects ash_authentication: from 4.9.1 before 4.15.0 and from 5.0.0-rc.0 before 5.0.0-rc.14; ash_authentication_phoenix: from 2.10.0 before 2.17.4 and from 3.0.0-rc.0 before 3.0.0-rc.11."
}
],
"impacts": [
{
"capecId": "CAPEC-60",
"descriptions": [
{
"lang": "en",
"value": "CAPEC-60 Reusing Session IDs (aka Session Replay)"
}
]
}
],
"metrics": [
{
"cvssV4_0": {
"Automatable": "NOT_DEFINED",
"Recovery": "NOT_DEFINED",
"Safety": "NOT_DEFINED",
"attackComplexity": "LOW",
"attackRequirements": "PRESENT",
"attackVector": "NETWORK",
"baseScore": 9.1,
"baseSeverity": "CRITICAL",
"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:H/VI:H/VA:N/SC:N/SI:N/SA:N",
"version": "4.0",
"vulnAvailabilityImpact": "NONE",
"vulnConfidentialityImpact": "HIGH",
"vulnIntegrityImpact": "HIGH",
"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-17T14:05:29.472Z",
"orgId": "6b3ad84c-e1a6-4bf7-a703-f496b71e49db",
"shortName": "EEF"
},
"references": [
{
"tags": [
"vendor-advisory",
"related"
],
"url": "https://github.com/team-alembic/ash_authentication_phoenix/security/advisories/GHSA-m6x4-4gvp-xwjr"
},
{
"name": "EEF CNA record for CVE-2026-86533",
"tags": [
"related"
],
"url": "https://cna.erlef.org/cves/CVE-2026-86533.html"
},
{
"name": "OSV record EEF-CVE-2026-86533",
"tags": [
"related"
],
"url": "https://osv.dev/vulnerability/EEF-CVE-2026-86533"
},
{
"tags": [
"related",
"vendor-advisory"
],
"url": "https://github.com/team-alembic/ash_authentication/security/advisories/GHSA-w374-hvrx-66hg"
},
{
"name": "Introducing commit fcaeb73 in team-alembic/ash_authentication",
"tags": [
"related"
],
"url": "https://github.com/team-alembic/ash_authentication/commit/fcaeb73f76f8f2e9aef8bf637690d2a20dd97596"
},
{
"name": "Fix commit a3f49f7 in team-alembic/ash_authentication",
"tags": [
"patch"
],
"url": "https://github.com/team-alembic/ash_authentication/commit/a3f49f758f013d2ff086dd9c5ef2d94e921711b4"
},
{
"name": "Fix commit e28e911 in team-alembic/ash_authentication",
"tags": [
"patch"
],
"url": "https://github.com/team-alembic/ash_authentication/commit/e28e911caa9728d76329afdb0fb26742ffe4eeef"
},
{
"name": "Introducing commit a3253fb in team-alembic/ash_authentication_phoenix",
"tags": [
"related"
],
"url": "https://github.com/team-alembic/ash_authentication_phoenix/commit/a3253fb4fc7145aeb403537af1c24d3a8d51ffb1"
},
{
"name": "Introducing commit 0135217 in team-alembic/ash_authentication_phoenix",
"tags": [
"related"
],
"url": "https://github.com/team-alembic/ash_authentication_phoenix/commit/0135217e34e621dac79ae3d9559aeee49304b0aa"
},
{
"name": "Fix commit f7ab005 in team-alembic/ash_authentication_phoenix",
"tags": [
"patch"
],
"url": "https://github.com/team-alembic/ash_authentication_phoenix/commit/f7ab005a2aac09707a25521653c94893d328cc52"
}
],
"source": {
"discovery": "INTERNAL"
},
"title": "Revoked session accepted because the session jti is never checked in AshAuthentication and AshAuthentication Phoenix"
}
},
"cveMetadata": {
"assignerOrgId": "6b3ad84c-e1a6-4bf7-a703-f496b71e49db",
"assignerShortName": "EEF",
"cveId": "CVE-2026-86533",
"datePublished": "2026-09-17T13:09:37.963Z",
"dateReserved": "2026-09-11T18:00:02.036Z",
"dateUpdated": "2026-09-17T18:17:21.199Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
CVE-2026-81632 (GCVE-0-2026-81632)
Vulnerability from cvelistv5 – Published: 2026-09-17 13:09 – Updated: 2026-09-17 18:29
VLAI
EPSS
VEX
Title
Single-use sign-in token placed in a redirect query string in AshAuthenticationPhoenix
Summary
Use of HTTP Request With Sensitive Query String vulnerability in team-alembic AshAuthenticationPhoenix allows someone able to read access logs, proxy logs or browser history to recover a single-use sign-in token and authenticate as its owner.
After a successful password sign-in, AshAuthentication.Phoenix.Components.Password.SignInForm builds the sign_in_with_token path with the freshly issued user.__metadata__.token as a query parameter and redirects the browser to it with a GET. The token therefore travels in the request line, where web servers, reverse proxies, request telemetry and the browser's own history record it, all of which outlive the request and are ordinarily less protected than session storage. The redirect destination is restricted to a local path, so this is not an open redirect; the exposure is the retention of a live credential.
This issue affects ash_authentication_phoenix: from 1.7.0 before 2.17.4 and from 3.0.0-rc.0 before 3.0.0-rc.11; ash_authentication: from 3.10.5 before 4.15.0 and from 5.0.0-rc.0 before 5.0.0-rc.14.
Severity
SSVC
Exploitation: none
Automatable: no
Technical Impact: total
CISA Coordinator · CISA-ADP (v2.0.3)
Decision recorded 2026-09-17 18:29 UTC
CWE
- CWE-598 - Use of HTTP Request With Sensitive Query String
Assigner
References
10 references
Impacted products
4 products
| Vendor | Product | Version | |
|---|---|---|---|
| team-alembic | ash_authentication_phoenix |
Affected:
1.7.0 , < 2.17.4
(semver)
Affected: 3.0.0-rc.0 , < 3.0.0-rc.11 (semver) cpe:2.3:a:team-alembic:ash_authentication_phoenix:*:*:*:*:*:*:*:* |
|
| team-alembic | ash_authentication_phoenix |
Affected:
903f3a386e1aba2f7b070187ef6f31215a92bdfd , < *
(git)
cpe:2.3:a:team-alembic:ash_authentication_phoenix:*:*:*:*:*:*:*:* |
|
| team-alembic | ash_authentication |
Affected:
3.10.5 , < 4.15.0
(semver)
Affected: 5.0.0-rc.0 , < 5.0.0-rc.14 (semver) cpe:2.3:a:team-alembic:ash_authentication:*:*:*:*:*:*:*:* |
|
| team-alembic | ash_authentication |
Affected:
eca8cadea0f1595ed2c10a0c177b1da9aa9e5269 , < *
(git)
cpe:2.3:a:team-alembic:ash_authentication:*:*:*:*:*:*:*:* |
{
"containers": {
"adp": [
{
"metrics": [
{
"other": {
"content": {
"id": "CVE-2026-81632",
"options": [
{
"Exploitation": "none"
},
{
"Automatable": "no"
},
{
"Technical Impact": "total"
}
],
"role": "CISA Coordinator",
"timestamp": "2026-09-17T18:29:05.558007Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"providerMetadata": {
"dateUpdated": "2026-09-17T18:29:20.271Z",
"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:team-alembic:ash_authentication_phoenix:*:*:*:*:*:*:*:*"
],
"defaultStatus": "unaffected",
"modules": [
"\u0027Elixir.AshAuthentication.Phoenix.Components.Password.SignInForm\u0027"
],
"packageName": "ash_authentication_phoenix",
"packageURL": "pkg:hex/ash_authentication_phoenix",
"product": "ash_authentication_phoenix",
"programFiles": [
"lib/ash_authentication_phoenix/components/password/sign_in_form.ex"
],
"programRoutines": [
{
"name": "\u0027Elixir.AshAuthentication.Phoenix.Components.Password.SignInForm\u0027:handle_event/3"
},
{
"name": "\u0027Elixir.AshAuthentication.Phoenix.Components.Password.SignInForm\u0027:get_redirect_path/3"
},
{
"name": "\u0027Elixir.AshAuthentication.Phoenix.Components.Password.SignInForm\u0027:get_auth_path_params/2"
}
],
"repo": "https://github.com/team-alembic/ash_authentication_phoenix",
"vendor": "team-alembic",
"versions": [
{
"lessThan": "2.17.4",
"status": "affected",
"version": "1.7.0",
"versionType": "semver"
},
{
"lessThan": "3.0.0-rc.11",
"status": "affected",
"version": "3.0.0-rc.0",
"versionType": "semver"
}
]
},
{
"collectionURL": "https://github.com",
"cpes": [
"cpe:2.3:a:team-alembic:ash_authentication_phoenix:*:*:*:*:*:*:*:*"
],
"defaultStatus": "unaffected",
"modules": [
"\u0027Elixir.AshAuthentication.Phoenix.Components.Password.SignInForm\u0027"
],
"packageName": "team-alembic/ash_authentication_phoenix",
"packageURL": "pkg:github/team-alembic/ash_authentication_phoenix",
"product": "ash_authentication_phoenix",
"programFiles": [
"lib/ash_authentication_phoenix/components/password/sign_in_form.ex"
],
"programRoutines": [
{
"name": "\u0027Elixir.AshAuthentication.Phoenix.Components.Password.SignInForm\u0027:handle_event/3"
},
{
"name": "\u0027Elixir.AshAuthentication.Phoenix.Components.Password.SignInForm\u0027:get_redirect_path/3"
},
{
"name": "\u0027Elixir.AshAuthentication.Phoenix.Components.Password.SignInForm\u0027:get_auth_path_params/2"
}
],
"repo": "https://github.com/team-alembic/ash_authentication_phoenix",
"vendor": "team-alembic",
"versions": [
{
"changes": [
{
"at": "920257d0460b9c7cbb42a83d0888c10f4eeeb88a",
"status": "unaffected"
},
{
"at": "ff5ad8737748afed9cdfde3ec3a05b8a4702a742",
"status": "unaffected"
}
],
"lessThan": "*",
"status": "affected",
"version": "903f3a386e1aba2f7b070187ef6f31215a92bdfd",
"versionType": "git"
}
]
},
{
"collectionURL": "https://repo.hex.pm",
"cpes": [
"cpe:2.3:a:team-alembic:ash_authentication:*:*:*:*:*:*:*:*"
],
"defaultStatus": "unaffected",
"packageName": "ash_authentication",
"packageURL": "pkg:hex/ash_authentication",
"product": "ash_authentication",
"repo": "https://github.com/team-alembic/ash_authentication",
"vendor": "team-alembic",
"versions": [
{
"lessThan": "4.15.0",
"status": "affected",
"version": "3.10.5",
"versionType": "semver"
},
{
"lessThan": "5.0.0-rc.14",
"status": "affected",
"version": "5.0.0-rc.0",
"versionType": "semver"
}
]
},
{
"collectionURL": "https://github.com",
"cpes": [
"cpe:2.3:a:team-alembic:ash_authentication:*:*:*:*:*:*:*:*"
],
"defaultStatus": "unaffected",
"packageName": "team-alembic/ash_authentication",
"packageURL": "pkg:github/team-alembic/ash_authentication",
"product": "ash_authentication",
"repo": "https://github.com/team-alembic/ash_authentication",
"vendor": "team-alembic",
"versions": [
{
"changes": [
{
"at": "bbf345c1bb7aa28bce5dd856ac0ed2427f103859",
"status": "unaffected"
},
{
"at": "8d8ddd25c69b669a92a701af74bff42e1aada998",
"status": "unaffected"
}
],
"lessThan": "*",
"status": "affected",
"version": "eca8cadea0f1595ed2c10a0c177b1da9aa9e5269",
"versionType": "git"
}
]
}
],
"cpeApplicability": [
{
"nodes": [
{
"cpeMatch": [
{
"criteria": "cpe:2.3:a:team-alembic:ash_authentication_phoenix:*:*:*:*:*:*:*:*",
"versionEndExcluding": "2.17.4",
"versionStartIncluding": "1.7.0",
"vulnerable": true
},
{
"criteria": "cpe:2.3:a:team-alembic:ash_authentication_phoenix:*:*:*:*:*:*:*:*",
"versionEndExcluding": "3.0.0-rc.11",
"versionStartIncluding": "3.0.0-rc.0",
"vulnerable": true
},
{
"criteria": "cpe:2.3:a:team-alembic:ash_authentication:*:*:*:*:*:*:*:*",
"versionEndExcluding": "4.15.0",
"versionStartIncluding": "3.10.5",
"vulnerable": true
},
{
"criteria": "cpe:2.3:a:team-alembic:ash_authentication:*:*:*:*:*:*:*:*",
"versionEndExcluding": "5.0.0-rc.14",
"versionStartIncluding": "5.0.0-rc.0",
"vulnerable": true
}
],
"negate": false,
"operator": "OR"
}
],
"operator": "AND"
}
],
"credits": [
{
"lang": "en",
"type": "reporter",
"value": "Peter Ullrich"
},
{
"lang": "en",
"type": "analyst",
"value": "Jonatan M\u00e4nnchen / EEF"
},
{
"lang": "en",
"type": "remediation developer",
"value": "James Harton"
}
],
"dateAssigned": "2026-09-11T18:51:56.000Z",
"descriptions": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003eUse of HTTP Request With Sensitive Query String vulnerability in team-alembic AshAuthenticationPhoenix allows someone able to read access logs, proxy logs or browser history to recover a single-use sign-in token and authenticate as its owner.\u003c/p\u003e\n\u003cp\u003eAfter a successful password sign-in, \u003ccode\u003eAshAuthentication.Phoenix.Components.Password.SignInForm\u003c/code\u003e builds the \u003ccode\u003esign_in_with_token\u003c/code\u003e path with the freshly issued \u003ccode\u003euser.__metadata__.token\u003c/code\u003e as a query parameter and redirects the browser to it with a GET. The token therefore travels in the request line, where web servers, reverse proxies, request telemetry and the browser\u0027s own history record it, all of which outlive the request and are ordinarily less protected than session storage. The redirect destination is restricted to a local path, so this is not an open redirect; the exposure is the retention of a live credential.\u003c/p\u003e\n\u003cp\u003eThis issue affects ash_authentication_phoenix: from 1.7.0 before 2.17.4 and from 3.0.0-rc.0 before 3.0.0-rc.11; ash_authentication: from 3.10.5 before 4.15.0 and from 5.0.0-rc.0 before 5.0.0-rc.14.\u003c/p\u003e"
},
{
"base64": false,
"type": "text/markdown",
"value": "Use of HTTP Request With Sensitive Query String vulnerability in team-alembic AshAuthenticationPhoenix allows someone able to read access logs, proxy logs or browser history to recover a single-use sign-in token and authenticate as its owner.\n\nAfter a successful password sign-in, `AshAuthentication.Phoenix.Components.Password.SignInForm` builds the `sign_in_with_token` path with the freshly issued `user.__metadata__.token` as a query parameter and redirects the browser to it with a GET. The token therefore travels in the request line, where web servers, reverse proxies, request telemetry and the browser\u0027s own history record it, all of which outlive the request and are ordinarily less protected than session storage. The redirect destination is restricted to a local path, so this is not an open redirect; the exposure is the retention of a live credential.\n\nThis issue affects ash_authentication_phoenix: from 1.7.0 before 2.17.4 and from 3.0.0-rc.0 before 3.0.0-rc.11; ash_authentication: from 3.10.5 before 4.15.0 and from 5.0.0-rc.0 before 5.0.0-rc.14."
}
],
"value": "Use of HTTP Request With Sensitive Query String vulnerability in team-alembic AshAuthenticationPhoenix allows someone able to read access logs, proxy logs or browser history to recover a single-use sign-in token and authenticate as its owner.\n\nAfter a successful password sign-in, AshAuthentication.Phoenix.Components.Password.SignInForm builds the sign_in_with_token path with the freshly issued user.__metadata__.token as a query parameter and redirects the browser to it with a GET. The token therefore travels in the request line, where web servers, reverse proxies, request telemetry and the browser\u0027s own history record it, all of which outlive the request and are ordinarily less protected than session storage. The redirect destination is restricted to a local path, so this is not an open redirect; the exposure is the retention of a live credential.\n\nThis issue affects ash_authentication_phoenix: from 1.7.0 before 2.17.4 and from 3.0.0-rc.0 before 3.0.0-rc.11; ash_authentication: from 3.10.5 before 4.15.0 and from 5.0.0-rc.0 before 5.0.0-rc.14."
}
],
"impacts": [
{
"capecId": "CAPEC-150",
"descriptions": [
{
"lang": "en",
"value": "CAPEC-150 Collect Data from Common Resource Locations"
}
]
}
],
"metrics": [
{
"cvssV4_0": {
"Automatable": "NOT_DEFINED",
"Recovery": "NOT_DEFINED",
"Safety": "NOT_DEFINED",
"attackComplexity": "LOW",
"attackRequirements": "PRESENT",
"attackVector": "LOCAL",
"baseScore": 7.2,
"baseSeverity": "HIGH",
"privilegesRequired": "LOW",
"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:L/UI:N/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N",
"version": "4.0",
"vulnAvailabilityImpact": "NONE",
"vulnConfidentialityImpact": "HIGH",
"vulnIntegrityImpact": "HIGH",
"vulnerabilityResponseEffort": "NOT_DEFINED"
},
"format": "CVSS",
"scenarios": [
{
"lang": "en",
"value": "GENERAL"
}
]
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-598",
"description": "CWE-598 Use of HTTP Request With Sensitive Query String",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-09-17T13:09:31.601Z",
"orgId": "6b3ad84c-e1a6-4bf7-a703-f496b71e49db",
"shortName": "EEF"
},
"references": [
{
"tags": [
"vendor-advisory",
"related"
],
"url": "https://github.com/team-alembic/ash_authentication_phoenix/security/advisories/GHSA-8jh5-339h-mqx9"
},
{
"name": "EEF CNA record for CVE-2026-81632",
"tags": [
"related"
],
"url": "https://cna.erlef.org/cves/CVE-2026-81632.html"
},
{
"name": "OSV record EEF-CVE-2026-81632",
"tags": [
"related"
],
"url": "https://osv.dev/vulnerability/EEF-CVE-2026-81632"
},
{
"tags": [
"vendor-advisory",
"related"
],
"url": "https://github.com/team-alembic/ash_authentication/security/advisories/GHSA-j726-59hm-r46r"
},
{
"name": "Introducing commit 903f3a3 in team-alembic/ash_authentication_phoenix",
"tags": [
"related"
],
"url": "https://github.com/team-alembic/ash_authentication_phoenix/commit/903f3a386e1aba2f7b070187ef6f31215a92bdfd"
},
{
"name": "Fix commit 920257d in team-alembic/ash_authentication_phoenix",
"tags": [
"patch"
],
"url": "https://github.com/team-alembic/ash_authentication_phoenix/commit/920257d0460b9c7cbb42a83d0888c10f4eeeb88a"
},
{
"name": "Fix commit ff5ad87 in team-alembic/ash_authentication_phoenix",
"tags": [
"patch"
],
"url": "https://github.com/team-alembic/ash_authentication_phoenix/commit/ff5ad8737748afed9cdfde3ec3a05b8a4702a742"
},
{
"name": "Introducing commit eca8cad in team-alembic/ash_authentication",
"tags": [
"related"
],
"url": "https://github.com/team-alembic/ash_authentication/commit/eca8cadea0f1595ed2c10a0c177b1da9aa9e5269"
},
{
"name": "Fix commit bbf345c in team-alembic/ash_authentication",
"tags": [
"patch"
],
"url": "https://github.com/team-alembic/ash_authentication/commit/bbf345c1bb7aa28bce5dd856ac0ed2427f103859"
},
{
"name": "Fix commit 8d8ddd2 in team-alembic/ash_authentication",
"tags": [
"patch"
],
"url": "https://github.com/team-alembic/ash_authentication/commit/8d8ddd25c69b669a92a701af74bff42e1aada998"
}
],
"source": {
"discovery": "INTERNAL"
},
"title": "Single-use sign-in token placed in a redirect query string in AshAuthenticationPhoenix"
}
},
"cveMetadata": {
"assignerOrgId": "6b3ad84c-e1a6-4bf7-a703-f496b71e49db",
"assignerShortName": "EEF",
"cveId": "CVE-2026-81632",
"datePublished": "2026-09-17T13:09:31.601Z",
"dateReserved": "2026-09-11T18:45:01.476Z",
"dateUpdated": "2026-09-17T18:29:20.271Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
CVE-2026-80218 (GCVE-0-2026-80218)
Vulnerability from cvelistv5 – Published: 2026-09-17 13:09 – Updated: 2026-09-17 18:28
VLAI
EPSS
VEX
Title
Sign-in token minted for one resource accepted by another in AshAuthentication
Summary
Improper Authentication vulnerability in team-alembic AshAuthentication allows an attacker holding a sign-in token for one authenticated resource to be signed in as a user of a different resource.
AshAuthentication.Strategy.Password.SignInWithTokenPreparation.extract_primary_keys_from_subject/2 parses the JWT sub claim (for example user?id=1) with URI.parse/1 and keeps only its query string, discarding the path segment that names the subject the token was issued for. Nothing else restores that binding: AshAuthentication.Jwt.verify/3 checks the signature, exp, nbf, jti and the library-version claims, the purpose check only requires sign_in, and the remaining comparison is over primary-key field names, which are identical across resources. The WebAuthn sign-in and remember-me preparations carry copies of the same helper and drop the path in the same way. The magic link sign-in path pins the subject name against the resource and is not affected.
This issue affects ash_authentication: from 3.10.5 before 4.15.0 and from 5.0.0-rc.0 before 5.0.0-rc.14.
Severity
SSVC
Exploitation: none
Automatable: no
Technical Impact: total
CISA Coordinator · CISA-ADP (v2.0.3)
Decision recorded 2026-09-17 18:28 UTC
CWE
- CWE-287 - Improper Authentication
Assigner
References
6 references
Impacted products
2 products
| Vendor | Product | Version | |
|---|---|---|---|
| team-alembic | ash_authentication |
Affected:
3.10.5 , < 4.15.0
(semver)
Affected: 5.0.0-rc.0 , < 5.0.0-rc.14 (semver) cpe:2.3:a:team-alembic:ash_authentication:*:*:*:*:*:*:*:* |
|
| team-alembic | ash_authentication |
Affected:
eca8cadea0f1595ed2c10a0c177b1da9aa9e5269 , < *
(git)
cpe:2.3:a:team-alembic:ash_authentication:*:*:*:*:*:*:*:* |
{
"containers": {
"adp": [
{
"metrics": [
{
"other": {
"content": {
"id": "CVE-2026-80218",
"options": [
{
"Exploitation": "none"
},
{
"Automatable": "no"
},
{
"Technical Impact": "total"
}
],
"role": "CISA Coordinator",
"timestamp": "2026-09-17T18:28:40.896413Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"providerMetadata": {
"dateUpdated": "2026-09-17T18:28:47.571Z",
"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:team-alembic:ash_authentication:*:*:*:*:*:*:*:*"
],
"defaultStatus": "unaffected",
"modules": [
"\u0027Elixir.AshAuthentication.Strategy.Password.SignInWithTokenPreparation\u0027",
"\u0027Elixir.AshAuthentication.Strategy.WebAuthn.SignInWithTokenPreparation\u0027",
"\u0027Elixir.AshAuthentication.Strategy.RememberMe.SignInPreparation\u0027"
],
"packageName": "ash_authentication",
"packageURL": "pkg:hex/ash_authentication",
"product": "ash_authentication",
"programFiles": [
"lib/ash_authentication/strategies/password/sign_in_with_token_preparation.ex",
"lib/ash_authentication/strategies/webauthn/sign_in_with_token_preparation.ex",
"lib/ash_authentication/strategies/remember_me/sign_in_preparation.ex"
],
"programRoutines": [
{
"name": "\u0027Elixir.AshAuthentication.Strategy.Password.SignInWithTokenPreparation\u0027:prepare/3"
},
{
"name": "\u0027Elixir.AshAuthentication.Strategy.WebAuthn.SignInWithTokenPreparation\u0027:prepare/3"
},
{
"name": "\u0027Elixir.AshAuthentication.Strategy.RememberMe.SignInPreparation\u0027:prepare/3"
}
],
"repo": "https://github.com/team-alembic/ash_authentication",
"vendor": "team-alembic",
"versions": [
{
"lessThan": "4.15.0",
"status": "affected",
"version": "3.10.5",
"versionType": "semver"
},
{
"lessThan": "5.0.0-rc.14",
"status": "affected",
"version": "5.0.0-rc.0",
"versionType": "semver"
}
]
},
{
"collectionURL": "https://github.com",
"cpes": [
"cpe:2.3:a:team-alembic:ash_authentication:*:*:*:*:*:*:*:*"
],
"defaultStatus": "unaffected",
"modules": [
"\u0027Elixir.AshAuthentication.Strategy.Password.SignInWithTokenPreparation\u0027",
"\u0027Elixir.AshAuthentication.Strategy.WebAuthn.SignInWithTokenPreparation\u0027",
"\u0027Elixir.AshAuthentication.Strategy.RememberMe.SignInPreparation\u0027"
],
"packageName": "team-alembic/ash_authentication",
"packageURL": "pkg:github/team-alembic/ash_authentication",
"product": "ash_authentication",
"programFiles": [
"lib/ash_authentication/strategies/password/sign_in_with_token_preparation.ex",
"lib/ash_authentication/strategies/webauthn/sign_in_with_token_preparation.ex",
"lib/ash_authentication/strategies/remember_me/sign_in_preparation.ex"
],
"programRoutines": [
{
"name": "\u0027Elixir.AshAuthentication.Strategy.Password.SignInWithTokenPreparation\u0027:prepare/3"
},
{
"name": "\u0027Elixir.AshAuthentication.Strategy.WebAuthn.SignInWithTokenPreparation\u0027:prepare/3"
},
{
"name": "\u0027Elixir.AshAuthentication.Strategy.RememberMe.SignInPreparation\u0027:prepare/3"
}
],
"repo": "https://github.com/team-alembic/ash_authentication",
"vendor": "team-alembic",
"versions": [
{
"changes": [
{
"at": "2640e1872e1fef4e4606e601bf00102cff784c03",
"status": "unaffected"
},
{
"at": "7baac243ca651eee127a84d672eee3fcff42e598",
"status": "unaffected"
}
],
"lessThan": "*",
"status": "affected",
"version": "eca8cadea0f1595ed2c10a0c177b1da9aa9e5269",
"versionType": "git"
}
]
}
],
"cpeApplicability": [
{
"nodes": [
{
"cpeMatch": [
{
"criteria": "cpe:2.3:a:team-alembic:ash_authentication:*:*:*:*:*:*:*:*",
"versionEndExcluding": "4.15.0",
"versionStartIncluding": "3.10.5",
"vulnerable": true
},
{
"criteria": "cpe:2.3:a:team-alembic:ash_authentication:*:*:*:*:*:*:*:*",
"versionEndExcluding": "5.0.0-rc.14",
"versionStartIncluding": "5.0.0-rc.0",
"vulnerable": true
}
],
"negate": false,
"operator": "OR"
}
],
"operator": "AND"
}
],
"credits": [
{
"lang": "en",
"type": "reporter",
"value": "Peter Ullrich"
},
{
"lang": "en",
"type": "analyst",
"value": "Jonatan M\u00e4nnchen / EEF"
},
{
"lang": "en",
"type": "remediation developer",
"value": "James Harton"
}
],
"dateAssigned": "2026-09-11T18:34:31.000Z",
"descriptions": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003eImproper Authentication vulnerability in team-alembic AshAuthentication allows an attacker holding a sign-in token for one authenticated resource to be signed in as a user of a different resource.\u003c/p\u003e\n\u003cp\u003e\u003ccode\u003eAshAuthentication.Strategy.Password.SignInWithTokenPreparation.extract_primary_keys_from_subject/2\u003c/code\u003e parses the JWT \u003ccode\u003esub\u003c/code\u003e claim (for example \u003ccode\u003euser?id=1\u003c/code\u003e) with \u003ccode\u003eURI.parse/1\u003c/code\u003e and keeps only its query string, discarding the path segment that names the subject the token was issued for. Nothing else restores that binding: \u003ccode\u003eAshAuthentication.Jwt.verify/3\u003c/code\u003e checks the signature, \u003ccode\u003eexp\u003c/code\u003e, \u003ccode\u003enbf\u003c/code\u003e, \u003ccode\u003ejti\u003c/code\u003e and the library-version claims, the purpose check only requires \u003ccode\u003esign_in\u003c/code\u003e, and the remaining comparison is over primary-key field names, which are identical across resources. The WebAuthn sign-in and remember-me preparations carry copies of the same helper and drop the path in the same way. The magic link sign-in path pins the subject name against the resource and is not affected.\u003c/p\u003e\n\u003cp\u003eThis issue affects ash_authentication: from 3.10.5 before 4.15.0 and from 5.0.0-rc.0 before 5.0.0-rc.14.\u003c/p\u003e"
},
{
"base64": false,
"type": "text/markdown",
"value": "Improper Authentication vulnerability in team-alembic AshAuthentication allows an attacker holding a sign-in token for one authenticated resource to be signed in as a user of a different resource.\n\n`AshAuthentication.Strategy.Password.SignInWithTokenPreparation.extract_primary_keys_from_subject/2` parses the JWT `sub` claim (for example `user?id=1`) with `URI.parse/1` and keeps only its query string, discarding the path segment that names the subject the token was issued for. Nothing else restores that binding: `AshAuthentication.Jwt.verify/3` checks the signature, `exp`, `nbf`, `jti` and the library-version claims, the purpose check only requires `sign_in`, and the remaining comparison is over primary-key field names, which are identical across resources. The WebAuthn sign-in and remember-me preparations carry copies of the same helper and drop the path in the same way. The magic link sign-in path pins the subject name against the resource and is not affected.\n\nThis issue affects ash_authentication: from 3.10.5 before 4.15.0 and from 5.0.0-rc.0 before 5.0.0-rc.14."
}
],
"value": "Improper Authentication vulnerability in team-alembic AshAuthentication allows an attacker holding a sign-in token for one authenticated resource to be signed in as a user of a different resource.\n\nAshAuthentication.Strategy.Password.SignInWithTokenPreparation.extract_primary_keys_from_subject/2 parses the JWT sub claim (for example user?id=1) with URI.parse/1 and keeps only its query string, discarding the path segment that names the subject the token was issued for. Nothing else restores that binding: AshAuthentication.Jwt.verify/3 checks the signature, exp, nbf, jti and the library-version claims, the purpose check only requires sign_in, and the remaining comparison is over primary-key field names, which are identical across resources. The WebAuthn sign-in and remember-me preparations carry copies of the same helper and drop the path in the same way. The magic link sign-in path pins the subject name against the resource and is not affected.\n\nThis issue affects ash_authentication: from 3.10.5 before 4.15.0 and from 5.0.0-rc.0 before 5.0.0-rc.14."
}
],
"impacts": [
{
"capecId": "CAPEC-151",
"descriptions": [
{
"lang": "en",
"value": "CAPEC-151 Identity Spoofing"
}
]
}
],
"metrics": [
{
"cvssV4_0": {
"Automatable": "NOT_DEFINED",
"Recovery": "NOT_DEFINED",
"Safety": "NOT_DEFINED",
"attackComplexity": "LOW",
"attackRequirements": "PRESENT",
"attackVector": "NETWORK",
"baseScore": 7.6,
"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:P/PR:L/UI:N/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N",
"version": "4.0",
"vulnAvailabilityImpact": "NONE",
"vulnConfidentialityImpact": "HIGH",
"vulnIntegrityImpact": "HIGH",
"vulnerabilityResponseEffort": "NOT_DEFINED"
},
"format": "CVSS",
"scenarios": [
{
"lang": "en",
"value": "GENERAL"
}
]
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-287",
"description": "CWE-287 Improper Authentication",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-09-17T13:09:25.585Z",
"orgId": "6b3ad84c-e1a6-4bf7-a703-f496b71e49db",
"shortName": "EEF"
},
"references": [
{
"tags": [
"vendor-advisory",
"related"
],
"url": "https://github.com/team-alembic/ash_authentication/security/advisories/GHSA-3pr8-f99q-86hp"
},
{
"name": "EEF CNA record for CVE-2026-80218",
"tags": [
"related"
],
"url": "https://cna.erlef.org/cves/CVE-2026-80218.html"
},
{
"name": "OSV record EEF-CVE-2026-80218",
"tags": [
"related"
],
"url": "https://osv.dev/vulnerability/EEF-CVE-2026-80218"
},
{
"name": "Introducing commit eca8cad in team-alembic/ash_authentication",
"tags": [
"related"
],
"url": "https://github.com/team-alembic/ash_authentication/commit/eca8cadea0f1595ed2c10a0c177b1da9aa9e5269"
},
{
"name": "Fix commit 2640e18 in team-alembic/ash_authentication",
"tags": [
"patch"
],
"url": "https://github.com/team-alembic/ash_authentication/commit/2640e1872e1fef4e4606e601bf00102cff784c03"
},
{
"name": "Fix commit 7baac24 in team-alembic/ash_authentication",
"tags": [
"patch"
],
"url": "https://github.com/team-alembic/ash_authentication/commit/7baac243ca651eee127a84d672eee3fcff42e598"
}
],
"source": {
"discovery": "INTERNAL"
},
"title": "Sign-in token minted for one resource accepted by another in AshAuthentication"
}
},
"cveMetadata": {
"assignerOrgId": "6b3ad84c-e1a6-4bf7-a703-f496b71e49db",
"assignerShortName": "EEF",
"cveId": "CVE-2026-80218",
"datePublished": "2026-09-17T13:09:25.585Z",
"dateReserved": "2026-09-11T18:30:01.333Z",
"dateUpdated": "2026-09-17T18:28:47.571Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
CVE-2026-78223 (GCVE-0-2026-78223)
Vulnerability from cvelistv5 – Published: 2026-09-17 13:09 – Updated: 2026-09-17 18:28
VLAI
EPSS
VEX
Title
Token revocation record built from unverified JWT claims in AshAuthentication
Summary
Improper Verification of Cryptographic Signature vulnerability in team-alembic AshAuthentication allows a caller of the token revocation action to neutralise a revocation or write arbitrary rows into the token resource.
AshAuthentication.TokenResource.RevokeTokenChange.change/3 reads the :token argument and decodes it with AshAuthentication.Jwt.peek/1, which delegates to Joken.peek_claims/1 and performs no signature check, unlike Jwt.verify/4. The jti, exp and sub claims it returns are written straight onto the revocation record, guarded only by byte_size(token) > 0. Because expires_at derives from the attacker-chosen exp, a forged copy of a genuine token that keeps the real jti but backdates exp yields a revocation row that is already expired: expunge_expired removes it and the genuine token passes revoked? again. Arbitrary jti and sub values can be inserted the same way.
This issue affects ash_authentication: from 0.2.0 before 4.15.0 and from 5.0.0-rc.0 before 5.0.0-rc.14.
Severity
SSVC
Exploitation: none
Automatable: yes
Technical Impact: partial
CISA Coordinator · CISA-ADP (v2.0.3)
Decision recorded 2026-09-17 18:28 UTC
CWE
- CWE-347 - Improper Verification of Cryptographic Signature
Assigner
References
6 references
Impacted products
2 products
| Vendor | Product | Version | |
|---|---|---|---|
| team-alembic | ash_authentication |
Affected:
0.2.0 , < 4.15.0
(semver)
Affected: 5.0.0-rc.0 , < 5.0.0-rc.14 (semver) cpe:2.3:a:team-alembic:ash_authentication:*:*:*:*:*:*:*:* |
|
| team-alembic | ash_authentication |
Affected:
a939dde9b917c072cdf10c4b0913a9886a4b0231 , < *
(git)
cpe:2.3:a:team-alembic:ash_authentication:*:*:*:*:*:*:*:* |
{
"containers": {
"adp": [
{
"metrics": [
{
"other": {
"content": {
"id": "CVE-2026-78223",
"options": [
{
"Exploitation": "none"
},
{
"Automatable": "yes"
},
{
"Technical Impact": "partial"
}
],
"role": "CISA Coordinator",
"timestamp": "2026-09-17T18:28:12.763636Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"providerMetadata": {
"dateUpdated": "2026-09-17T18:28:20.821Z",
"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:team-alembic:ash_authentication:*:*:*:*:*:*:*:*"
],
"defaultStatus": "unaffected",
"modules": [
"\u0027Elixir.AshAuthentication.TokenResource.RevokeTokenChange\u0027"
],
"packageName": "ash_authentication",
"packageURL": "pkg:hex/ash_authentication",
"product": "ash_authentication",
"programFiles": [
"lib/ash_authentication/token_resource/revoke_token_change.ex"
],
"programRoutines": [
{
"name": "\u0027Elixir.AshAuthentication.TokenResource.RevokeTokenChange\u0027:change/3"
}
],
"repo": "https://github.com/team-alembic/ash_authentication",
"vendor": "team-alembic",
"versions": [
{
"lessThan": "4.15.0",
"status": "affected",
"version": "0.2.0",
"versionType": "semver"
},
{
"lessThan": "5.0.0-rc.14",
"status": "affected",
"version": "5.0.0-rc.0",
"versionType": "semver"
}
]
},
{
"collectionURL": "https://github.com",
"cpes": [
"cpe:2.3:a:team-alembic:ash_authentication:*:*:*:*:*:*:*:*"
],
"defaultStatus": "unaffected",
"modules": [
"\u0027Elixir.AshAuthentication.TokenResource.RevokeTokenChange\u0027"
],
"packageName": "team-alembic/ash_authentication",
"packageURL": "pkg:github/team-alembic/ash_authentication",
"product": "ash_authentication",
"programFiles": [
"lib/ash_authentication/token_resource/revoke_token_change.ex"
],
"programRoutines": [
{
"name": "\u0027Elixir.AshAuthentication.TokenResource.RevokeTokenChange\u0027:change/3"
}
],
"repo": "https://github.com/team-alembic/ash_authentication",
"vendor": "team-alembic",
"versions": [
{
"changes": [
{
"at": "344cebb12faf68e648d3283394073ba0c0f78459",
"status": "unaffected"
},
{
"at": "eb86353fe5a547c5ff5fd9af0e2c212518c31c9b",
"status": "unaffected"
}
],
"lessThan": "*",
"status": "affected",
"version": "a939dde9b917c072cdf10c4b0913a9886a4b0231",
"versionType": "git"
}
]
}
],
"cpeApplicability": [
{
"nodes": [
{
"cpeMatch": [
{
"criteria": "cpe:2.3:a:team-alembic:ash_authentication:*:*:*:*:*:*:*:*",
"versionEndExcluding": "4.15.0",
"versionStartIncluding": "0.2.0",
"vulnerable": true
},
{
"criteria": "cpe:2.3:a:team-alembic:ash_authentication:*:*:*:*:*:*:*:*",
"versionEndExcluding": "5.0.0-rc.14",
"versionStartIncluding": "5.0.0-rc.0",
"vulnerable": true
}
],
"negate": false,
"operator": "OR"
}
],
"operator": "AND"
}
],
"credits": [
{
"lang": "en",
"type": "reporter",
"value": "Peter Ullrich"
},
{
"lang": "en",
"type": "analyst",
"value": "Jonatan M\u00e4nnchen / EEF"
},
{
"lang": "en",
"type": "remediation developer",
"value": "James Harton"
}
],
"dateAssigned": "2026-09-11T18:31:49.000Z",
"descriptions": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003eImproper Verification of Cryptographic Signature vulnerability in team-alembic AshAuthentication allows a caller of the token revocation action to neutralise a revocation or write arbitrary rows into the token resource.\u003c/p\u003e\n\u003cp\u003e\u003ccode\u003eAshAuthentication.TokenResource.RevokeTokenChange.change/3\u003c/code\u003e reads the \u003ccode\u003e:token\u003c/code\u003e argument and decodes it with \u003ccode\u003eAshAuthentication.Jwt.peek/1\u003c/code\u003e, which delegates to \u003ccode\u003eJoken.peek_claims/1\u003c/code\u003e and performs no signature check, unlike \u003ccode\u003eJwt.verify/4\u003c/code\u003e. The \u003ccode\u003ejti\u003c/code\u003e, \u003ccode\u003eexp\u003c/code\u003e and \u003ccode\u003esub\u003c/code\u003e claims it returns are written straight onto the revocation record, guarded only by \u003ccode\u003ebyte_size(token) \u0026gt; 0\u003c/code\u003e. Because \u003ccode\u003eexpires_at\u003c/code\u003e derives from the attacker-chosen \u003ccode\u003eexp\u003c/code\u003e, a forged copy of a genuine token that keeps the real \u003ccode\u003ejti\u003c/code\u003e but backdates \u003ccode\u003eexp\u003c/code\u003e yields a revocation row that is already expired: \u003ccode\u003eexpunge_expired\u003c/code\u003e removes it and the genuine token passes \u003ccode\u003erevoked?\u003c/code\u003e again. Arbitrary \u003ccode\u003ejti\u003c/code\u003e and \u003ccode\u003esub\u003c/code\u003e values can be inserted the same way.\u003c/p\u003e\n\u003cp\u003eThis issue affects ash_authentication: from 0.2.0 before 4.15.0 and from 5.0.0-rc.0 before 5.0.0-rc.14.\u003c/p\u003e"
},
{
"base64": false,
"type": "text/markdown",
"value": "Improper Verification of Cryptographic Signature vulnerability in team-alembic AshAuthentication allows a caller of the token revocation action to neutralise a revocation or write arbitrary rows into the token resource.\n\n`AshAuthentication.TokenResource.RevokeTokenChange.change/3` reads the `:token` argument and decodes it with `AshAuthentication.Jwt.peek/1`, which delegates to `Joken.peek_claims/1` and performs no signature check, unlike `Jwt.verify/4`. The `jti`, `exp` and `sub` claims it returns are written straight onto the revocation record, guarded only by `byte_size(token) \u003e 0`. Because `expires_at` derives from the attacker-chosen `exp`, a forged copy of a genuine token that keeps the real `jti` but backdates `exp` yields a revocation row that is already expired: `expunge_expired` removes it and the genuine token passes `revoked?` again. Arbitrary `jti` and `sub` values can be inserted the same way.\n\nThis issue affects ash_authentication: from 0.2.0 before 4.15.0 and from 5.0.0-rc.0 before 5.0.0-rc.14."
}
],
"value": "Improper Verification of Cryptographic Signature vulnerability in team-alembic AshAuthentication allows a caller of the token revocation action to neutralise a revocation or write arbitrary rows into the token resource.\n\nAshAuthentication.TokenResource.RevokeTokenChange.change/3 reads the :token argument and decodes it with AshAuthentication.Jwt.peek/1, which delegates to Joken.peek_claims/1 and performs no signature check, unlike Jwt.verify/4. The jti, exp and sub claims it returns are written straight onto the revocation record, guarded only by byte_size(token) \u003e 0. Because expires_at derives from the attacker-chosen exp, a forged copy of a genuine token that keeps the real jti but backdates exp yields a revocation row that is already expired: expunge_expired removes it and the genuine token passes revoked? again. Arbitrary jti and sub values can be inserted the same way.\n\nThis issue affects ash_authentication: from 0.2.0 before 4.15.0 and from 5.0.0-rc.0 before 5.0.0-rc.14."
}
],
"impacts": [
{
"capecId": "CAPEC-475",
"descriptions": [
{
"lang": "en",
"value": "CAPEC-475 Signature Spoofing by Improper Validation"
}
]
}
],
"metrics": [
{
"cvssV4_0": {
"Automatable": "NOT_DEFINED",
"Recovery": "NOT_DEFINED",
"Safety": "NOT_DEFINED",
"attackComplexity": "LOW",
"attackRequirements": "NONE",
"attackVector": "NETWORK",
"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:N/AC:L/AT:N/PR:N/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-347",
"description": "CWE-347 Improper Verification of Cryptographic Signature",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-09-17T13:09:19.591Z",
"orgId": "6b3ad84c-e1a6-4bf7-a703-f496b71e49db",
"shortName": "EEF"
},
"references": [
{
"tags": [
"related",
"vendor-advisory"
],
"url": "https://github.com/team-alembic/ash_authentication/security/advisories/GHSA-mfwg-5cpf-px58"
},
{
"name": "EEF CNA record for CVE-2026-78223",
"tags": [
"related"
],
"url": "https://cna.erlef.org/cves/CVE-2026-78223.html"
},
{
"name": "OSV record EEF-CVE-2026-78223",
"tags": [
"related"
],
"url": "https://osv.dev/vulnerability/EEF-CVE-2026-78223"
},
{
"name": "Introducing commit a939dde in team-alembic/ash_authentication",
"tags": [
"related"
],
"url": "https://github.com/team-alembic/ash_authentication/commit/a939dde9b917c072cdf10c4b0913a9886a4b0231"
},
{
"name": "Fix commit 344cebb in team-alembic/ash_authentication",
"tags": [
"patch"
],
"url": "https://github.com/team-alembic/ash_authentication/commit/344cebb12faf68e648d3283394073ba0c0f78459"
},
{
"name": "Fix commit eb86353 in team-alembic/ash_authentication",
"tags": [
"patch"
],
"url": "https://github.com/team-alembic/ash_authentication/commit/eb86353fe5a547c5ff5fd9af0e2c212518c31c9b"
}
],
"source": {
"discovery": "INTERNAL"
},
"title": "Token revocation record built from unverified JWT claims in AshAuthentication"
}
},
"cveMetadata": {
"assignerOrgId": "6b3ad84c-e1a6-4bf7-a703-f496b71e49db",
"assignerShortName": "EEF",
"cveId": "CVE-2026-78223",
"datePublished": "2026-09-17T13:09:19.591Z",
"dateReserved": "2026-09-11T18:30:01.328Z",
"dateUpdated": "2026-09-17T18:28:20.821Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
CVE-2026-86522 (GCVE-0-2026-86522)
Vulnerability from cvelistv5 – Published: 2026-09-17 13:09 – Updated: 2026-09-17 18:27
VLAI
EPSS
VEX
Title
Log injection via an unescaped password reset identity in AshAuthentication
Summary
Improper Output Neutralization for Logs vulnerability in team-alembic AshAuthentication allows an unauthenticated attacker to forge application log entries by submitting a password reset identity containing newlines or control characters.
AshAuthentication.Strategy.Password.RequestPasswordReset.run/3 interpolates the identity argument, the email or username taken straight from the reset request, into its Logger.warning/1 heredocs without escaping, truncating or type-restricting it. The resource logged beside it is passed through inspect/1, which would have neutralized the value. A newline in the identity therefore ends the log record, and everything after it is written as a line of its own, so an attacker chooses the severity tag and the content of entries that appear to have come from the application.
This issue affects ash_authentication: from 4.2.0 before 4.15.0 and from 5.0.0-rc.0 before 5.0.0-rc.14.
Severity
SSVC
Exploitation: none
Automatable: no
Technical Impact: partial
CISA Coordinator · CISA-ADP (v2.0.3)
Decision recorded 2026-09-17 18:27 UTC
CWE
- CWE-117 - Improper Output Neutralization for Logs
Assigner
References
6 references
Impacted products
2 products
| Vendor | Product | Version | |
|---|---|---|---|
| team-alembic | ash_authentication |
Affected:
4.2.0 , < 4.15.0
(semver)
Affected: 5.0.0-rc.0 , < 5.0.0-rc.14 (semver) cpe:2.3:a:team-alembic:ash_authentication:*:*:*:*:*:*:*:* |
|
| team-alembic | ash_authentication |
Affected:
3954f277929712755aef57a4a3a821688f121316 , < *
(git)
cpe:2.3:a:team-alembic:ash_authentication:*:*:*:*:*:*:*:* |
{
"containers": {
"adp": [
{
"metrics": [
{
"other": {
"content": {
"id": "CVE-2026-86522",
"options": [
{
"Exploitation": "none"
},
{
"Automatable": "no"
},
{
"Technical Impact": "partial"
}
],
"role": "CISA Coordinator",
"timestamp": "2026-09-17T18:27:45.711185Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"providerMetadata": {
"dateUpdated": "2026-09-17T18:27:51.681Z",
"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:team-alembic:ash_authentication:*:*:*:*:*:*:*:*"
],
"defaultStatus": "unaffected",
"modules": [
"\u0027Elixir.AshAuthentication.Strategy.Password.RequestPasswordReset\u0027"
],
"packageName": "ash_authentication",
"packageURL": "pkg:hex/ash_authentication",
"product": "ash_authentication",
"programFiles": [
"lib/ash_authentication/strategies/password/request_password_reset.ex"
],
"programRoutines": [
{
"name": "\u0027Elixir.AshAuthentication.Strategy.Password.RequestPasswordReset\u0027:run/3"
}
],
"repo": "https://github.com/team-alembic/ash_authentication",
"vendor": "team-alembic",
"versions": [
{
"lessThan": "4.15.0",
"status": "affected",
"version": "4.2.0",
"versionType": "semver"
},
{
"lessThan": "5.0.0-rc.14",
"status": "affected",
"version": "5.0.0-rc.0",
"versionType": "semver"
}
]
},
{
"collectionURL": "https://github.com",
"cpes": [
"cpe:2.3:a:team-alembic:ash_authentication:*:*:*:*:*:*:*:*"
],
"defaultStatus": "unaffected",
"modules": [
"\u0027Elixir.AshAuthentication.Strategy.Password.RequestPasswordReset\u0027"
],
"packageName": "team-alembic/ash_authentication",
"packageURL": "pkg:github/team-alembic/ash_authentication",
"product": "ash_authentication",
"programFiles": [
"lib/ash_authentication/strategies/password/request_password_reset.ex"
],
"programRoutines": [
{
"name": "\u0027Elixir.AshAuthentication.Strategy.Password.RequestPasswordReset\u0027:run/3"
}
],
"repo": "https://github.com/team-alembic/ash_authentication",
"vendor": "team-alembic",
"versions": [
{
"changes": [
{
"at": "fd19358bf0eee53ef13dcf17cc499bd4fb393981",
"status": "unaffected"
},
{
"at": "57c7cc3236bef0fa9da19cb315414f216488866d",
"status": "unaffected"
}
],
"lessThan": "*",
"status": "affected",
"version": "3954f277929712755aef57a4a3a821688f121316",
"versionType": "git"
}
]
}
],
"cpeApplicability": [
{
"nodes": [
{
"cpeMatch": [
{
"criteria": "cpe:2.3:a:team-alembic:ash_authentication:*:*:*:*:*:*:*:*",
"versionEndExcluding": "4.15.0",
"versionStartIncluding": "4.2.0",
"vulnerable": true
},
{
"criteria": "cpe:2.3:a:team-alembic:ash_authentication:*:*:*:*:*:*:*:*",
"versionEndExcluding": "5.0.0-rc.14",
"versionStartIncluding": "5.0.0-rc.0",
"vulnerable": true
}
],
"negate": false,
"operator": "OR"
}
],
"operator": "AND"
}
],
"credits": [
{
"lang": "en",
"type": "reporter",
"value": "Peter Ullrich"
},
{
"lang": "en",
"type": "analyst",
"value": "Jonatan M\u00e4nnchen / EEF"
},
{
"lang": "en",
"type": "remediation developer",
"value": "James Harton"
}
],
"dateAssigned": "2026-09-11T18:26:23.000Z",
"descriptions": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003eImproper Output Neutralization for Logs vulnerability in team-alembic AshAuthentication allows an unauthenticated attacker to forge application log entries by submitting a password reset identity containing newlines or control characters.\u003c/p\u003e\n\u003cp\u003e\u003ccode\u003eAshAuthentication.Strategy.Password.RequestPasswordReset.run/3\u003c/code\u003e interpolates the \u003ccode\u003eidentity\u003c/code\u003e argument, the email or username taken straight from the reset request, into its \u003ccode\u003eLogger.warning/1\u003c/code\u003e heredocs without escaping, truncating or type-restricting it. The resource logged beside it is passed through \u003ccode\u003einspect/1\u003c/code\u003e, which would have neutralized the value. A newline in the identity therefore ends the log record, and everything after it is written as a line of its own, so an attacker chooses the severity tag and the content of entries that appear to have come from the application.\u003c/p\u003e\n\u003cp\u003eThis issue affects ash_authentication: from 4.2.0 before 4.15.0 and from 5.0.0-rc.0 before 5.0.0-rc.14.\u003c/p\u003e"
},
{
"base64": false,
"type": "text/markdown",
"value": "Improper Output Neutralization for Logs vulnerability in team-alembic AshAuthentication allows an unauthenticated attacker to forge application log entries by submitting a password reset identity containing newlines or control characters.\n\n`AshAuthentication.Strategy.Password.RequestPasswordReset.run/3` interpolates the `identity` argument, the email or username taken straight from the reset request, into its `Logger.warning/1` heredocs without escaping, truncating or type-restricting it. The resource logged beside it is passed through `inspect/1`, which would have neutralized the value. A newline in the identity therefore ends the log record, and everything after it is written as a line of its own, so an attacker chooses the severity tag and the content of entries that appear to have come from the application.\n\nThis issue affects ash_authentication: from 4.2.0 before 4.15.0 and from 5.0.0-rc.0 before 5.0.0-rc.14."
}
],
"value": "Improper Output Neutralization for Logs vulnerability in team-alembic AshAuthentication allows an unauthenticated attacker to forge application log entries by submitting a password reset identity containing newlines or control characters.\n\nAshAuthentication.Strategy.Password.RequestPasswordReset.run/3 interpolates the identity argument, the email or username taken straight from the reset request, into its Logger.warning/1 heredocs without escaping, truncating or type-restricting it. The resource logged beside it is passed through inspect/1, which would have neutralized the value. A newline in the identity therefore ends the log record, and everything after it is written as a line of its own, so an attacker chooses the severity tag and the content of entries that appear to have come from the application.\n\nThis issue affects ash_authentication: from 4.2.0 before 4.15.0 and from 5.0.0-rc.0 before 5.0.0-rc.14."
}
],
"impacts": [
{
"capecId": "CAPEC-93",
"descriptions": [
{
"lang": "en",
"value": "CAPEC-93 Log Injection-Tampering-Forging"
}
]
}
],
"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": "LOW",
"userInteraction": "NONE",
"valueDensity": "NOT_DEFINED",
"vectorString": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:L/VA:N/SC:N/SI:L/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-117",
"description": "CWE-117 Improper Output Neutralization for Logs",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-09-17T13:09:11.572Z",
"orgId": "6b3ad84c-e1a6-4bf7-a703-f496b71e49db",
"shortName": "EEF"
},
"references": [
{
"tags": [
"vendor-advisory",
"related"
],
"url": "https://github.com/team-alembic/ash_authentication/security/advisories/GHSA-wg7g-r393-vr3g"
},
{
"name": "EEF CNA record for CVE-2026-86522",
"tags": [
"related"
],
"url": "https://cna.erlef.org/cves/CVE-2026-86522.html"
},
{
"name": "OSV record EEF-CVE-2026-86522",
"tags": [
"related"
],
"url": "https://osv.dev/vulnerability/EEF-CVE-2026-86522"
},
{
"name": "Introducing commit 3954f27 in team-alembic/ash_authentication",
"tags": [
"related"
],
"url": "https://github.com/team-alembic/ash_authentication/commit/3954f277929712755aef57a4a3a821688f121316"
},
{
"name": "Fix commit fd19358 in team-alembic/ash_authentication",
"tags": [
"patch"
],
"url": "https://github.com/team-alembic/ash_authentication/commit/fd19358bf0eee53ef13dcf17cc499bd4fb393981"
},
{
"name": "Fix commit 57c7cc3 in team-alembic/ash_authentication",
"tags": [
"patch"
],
"url": "https://github.com/team-alembic/ash_authentication/commit/57c7cc3236bef0fa9da19cb315414f216488866d"
}
],
"source": {
"discovery": "INTERNAL"
},
"title": "Log injection via an unescaped password reset identity in AshAuthentication"
}
},
"cveMetadata": {
"assignerOrgId": "6b3ad84c-e1a6-4bf7-a703-f496b71e49db",
"assignerShortName": "EEF",
"cveId": "CVE-2026-86522",
"datePublished": "2026-09-17T13:09:11.572Z",
"dateReserved": "2026-09-07T22:30:01.279Z",
"dateUpdated": "2026-09-17T18:27:51.681Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
CVE-2026-81637 (GCVE-0-2026-81637)
Vulnerability from cvelistv5 – Published: 2026-09-17 13:09 – Updated: 2026-09-17 18:26
VLAI
EPSS
VEX
Title
Replayable OAuth2 CSRF state retained after a failed callback in AshAuthentication
Summary
Insufficient Session Expiration vulnerability in team-alembic AshAuthentication allows an attacker who obtains a victim's OAuth2 state value to replay the callback and sign that victim into an attacker-controlled account.
AshAuthentication.Strategy.OAuth2.Plug.callback/2 clears the stored session_params through a rebinding step inside its with chain, conn <- delete_session(conn, session_key). Elixir evaluates the else block in the scope enclosing the with, so every failure path (the provider returning ?error=access_denied, an invalid code, a token-exchange error, or a registration or sign-in failure) reaches store_authentication_result/2 holding the original connection and the session entry is never removed. The value the module's own comment describes as protection against a CSRF-related attack is therefore consumed only when authentication succeeds, and survives a cancelled or failed attempt until the next request phase or session expiry.
This issue affects ash_authentication: from 0.6.0 before 4.15.0 and from 5.0.0-rc.0 before 5.0.0-rc.14.
Severity
SSVC
Exploitation: none
Automatable: no
Technical Impact: partial
CISA Coordinator · CISA-ADP (v2.0.3)
Decision recorded 2026-09-17 18:26 UTC
CWE
- CWE-613 - Insufficient Session Expiration
Assigner
References
6 references
Impacted products
2 products
| Vendor | Product | Version | |
|---|---|---|---|
| team-alembic | ash_authentication |
Affected:
0.6.0 , < 4.15.0
(semver)
Affected: 5.0.0-rc.0 , < 5.0.0-rc.14 (semver) cpe:2.3:a:team-alembic:ash_authentication:*:*:*:*:*:*:*:* |
|
| team-alembic | ash_authentication |
Affected:
c5f589058e04239263f50a1430eb17ea6d5dd1a2 , < *
(git)
cpe:2.3:a:team-alembic:ash_authentication:*:*:*:*:*:*:*:* |
{
"containers": {
"adp": [
{
"metrics": [
{
"other": {
"content": {
"id": "CVE-2026-81637",
"options": [
{
"Exploitation": "none"
},
{
"Automatable": "no"
},
{
"Technical Impact": "partial"
}
],
"role": "CISA Coordinator",
"timestamp": "2026-09-17T18:26:48.969731Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"providerMetadata": {
"dateUpdated": "2026-09-17T18:26:58.389Z",
"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:team-alembic:ash_authentication:*:*:*:*:*:*:*:*"
],
"defaultStatus": "unaffected",
"modules": [
"\u0027Elixir.AshAuthentication.Strategy.OAuth2.Plug\u0027"
],
"packageName": "ash_authentication",
"packageURL": "pkg:hex/ash_authentication",
"product": "ash_authentication",
"programFiles": [
"lib/ash_authentication/strategies/oauth2/plug.ex"
],
"programRoutines": [
{
"name": "\u0027Elixir.AshAuthentication.Strategy.OAuth2.Plug\u0027:callback/2"
},
{
"name": "\u0027Elixir.AshAuthentication.Strategy.OAuth2.Plug\u0027:request/2"
}
],
"repo": "https://github.com/team-alembic/ash_authentication",
"vendor": "team-alembic",
"versions": [
{
"lessThan": "4.15.0",
"status": "affected",
"version": "0.6.0",
"versionType": "semver"
},
{
"lessThan": "5.0.0-rc.14",
"status": "affected",
"version": "5.0.0-rc.0",
"versionType": "semver"
}
]
},
{
"collectionURL": "https://github.com",
"cpes": [
"cpe:2.3:a:team-alembic:ash_authentication:*:*:*:*:*:*:*:*"
],
"defaultStatus": "unaffected",
"modules": [
"\u0027Elixir.AshAuthentication.Strategy.OAuth2.Plug\u0027"
],
"packageName": "team-alembic/ash_authentication",
"packageURL": "pkg:github/team-alembic/ash_authentication",
"product": "ash_authentication",
"programFiles": [
"lib/ash_authentication/strategies/oauth2/plug.ex"
],
"programRoutines": [
{
"name": "\u0027Elixir.AshAuthentication.Strategy.OAuth2.Plug\u0027:callback/2"
},
{
"name": "\u0027Elixir.AshAuthentication.Strategy.OAuth2.Plug\u0027:request/2"
}
],
"repo": "https://github.com/team-alembic/ash_authentication",
"vendor": "team-alembic",
"versions": [
{
"changes": [
{
"at": "bd4352303bc9d72d007f6818775267585a4bcc2f",
"status": "unaffected"
},
{
"at": "d7f939cd02bd618bcaa304631846fa75ffc419d7",
"status": "unaffected"
}
],
"lessThan": "*",
"status": "affected",
"version": "c5f589058e04239263f50a1430eb17ea6d5dd1a2",
"versionType": "git"
}
]
}
],
"cpeApplicability": [
{
"nodes": [
{
"cpeMatch": [
{
"criteria": "cpe:2.3:a:team-alembic:ash_authentication:*:*:*:*:*:*:*:*",
"versionEndExcluding": "4.15.0",
"versionStartIncluding": "0.6.0",
"vulnerable": true
},
{
"criteria": "cpe:2.3:a:team-alembic:ash_authentication:*:*:*:*:*:*:*:*",
"versionEndExcluding": "5.0.0-rc.14",
"versionStartIncluding": "5.0.0-rc.0",
"vulnerable": true
}
],
"negate": false,
"operator": "OR"
}
],
"operator": "AND"
}
],
"credits": [
{
"lang": "en",
"type": "reporter",
"value": "Peter Ullrich"
},
{
"lang": "en",
"type": "analyst",
"value": "Jonatan M\u00e4nnchen / EEF"
},
{
"lang": "en",
"type": "remediation developer",
"value": "James Harton"
}
],
"dateAssigned": "2026-09-11T18:16:32.000Z",
"descriptions": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003eInsufficient Session Expiration vulnerability in team-alembic AshAuthentication allows an attacker who obtains a victim\u0027s OAuth2 \u003ccode\u003estate\u003c/code\u003e value to replay the callback and sign that victim into an attacker-controlled account.\u003c/p\u003e\n\u003cp\u003e\u003ccode\u003eAshAuthentication.Strategy.OAuth2.Plug.callback/2\u003c/code\u003e clears the stored \u003ccode\u003esession_params\u003c/code\u003e through a rebinding step inside its \u003ccode\u003ewith\u003c/code\u003e chain, \u003ccode\u003econn \u0026lt;- delete_session(conn, session_key)\u003c/code\u003e. Elixir evaluates the \u003ccode\u003eelse\u003c/code\u003e block in the scope enclosing the \u003ccode\u003ewith\u003c/code\u003e, so every failure path (the provider returning \u003ccode\u003e?error=access_denied\u003c/code\u003e, an invalid code, a token-exchange error, or a registration or sign-in failure) reaches \u003ccode\u003estore_authentication_result/2\u003c/code\u003e holding the original connection and the session entry is never removed. The value the module\u0027s own comment describes as protection against a CSRF-related attack is therefore consumed only when authentication succeeds, and survives a cancelled or failed attempt until the next request phase or session expiry.\u003c/p\u003e\n\u003cp\u003eThis issue affects ash_authentication: from 0.6.0 before 4.15.0 and from 5.0.0-rc.0 before 5.0.0-rc.14.\u003c/p\u003e"
},
{
"base64": false,
"type": "text/markdown",
"value": "Insufficient Session Expiration vulnerability in team-alembic AshAuthentication allows an attacker who obtains a victim\u0027s OAuth2 `state` value to replay the callback and sign that victim into an attacker-controlled account.\n\n`AshAuthentication.Strategy.OAuth2.Plug.callback/2` clears the stored `session_params` through a rebinding step inside its `with` chain, `conn \u003c- delete_session(conn, session_key)`. Elixir evaluates the `else` block in the scope enclosing the `with`, so every failure path (the provider returning `?error=access_denied`, an invalid code, a token-exchange error, or a registration or sign-in failure) reaches `store_authentication_result/2` holding the original connection and the session entry is never removed. The value the module\u0027s own comment describes as protection against a CSRF-related attack is therefore consumed only when authentication succeeds, and survives a cancelled or failed attempt until the next request phase or session expiry.\n\nThis issue affects ash_authentication: from 0.6.0 before 4.15.0 and from 5.0.0-rc.0 before 5.0.0-rc.14."
}
],
"value": "Insufficient Session Expiration vulnerability in team-alembic AshAuthentication allows an attacker who obtains a victim\u0027s OAuth2 state value to replay the callback and sign that victim into an attacker-controlled account.\n\nAshAuthentication.Strategy.OAuth2.Plug.callback/2 clears the stored session_params through a rebinding step inside its with chain, conn \u003c- delete_session(conn, session_key). Elixir evaluates the else block in the scope enclosing the with, so every failure path (the provider returning ?error=access_denied, an invalid code, a token-exchange error, or a registration or sign-in failure) reaches store_authentication_result/2 holding the original connection and the session entry is never removed. The value the module\u0027s own comment describes as protection against a CSRF-related attack is therefore consumed only when authentication succeeds, and survives a cancelled or failed attempt until the next request phase or session expiry.\n\nThis issue affects ash_authentication: from 0.6.0 before 4.15.0 and from 5.0.0-rc.0 before 5.0.0-rc.14."
}
],
"impacts": [
{
"capecId": "CAPEC-60",
"descriptions": [
{
"lang": "en",
"value": "CAPEC-60 Reusing Session IDs (aka Session Replay)"
}
]
}
],
"metrics": [
{
"cvssV4_0": {
"Automatable": "NOT_DEFINED",
"Recovery": "NOT_DEFINED",
"Safety": "NOT_DEFINED",
"attackComplexity": "HIGH",
"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:H/AT:P/PR:N/UI:P/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-613",
"description": "CWE-613 Insufficient Session Expiration",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-09-17T13:09:06.571Z",
"orgId": "6b3ad84c-e1a6-4bf7-a703-f496b71e49db",
"shortName": "EEF"
},
"references": [
{
"tags": [
"vendor-advisory",
"related"
],
"url": "https://github.com/team-alembic/ash_authentication/security/advisories/GHSA-3vcj-gxx8-3p44"
},
{
"name": "EEF CNA record for CVE-2026-81637",
"tags": [
"related"
],
"url": "https://cna.erlef.org/cves/CVE-2026-81637.html"
},
{
"name": "OSV record EEF-CVE-2026-81637",
"tags": [
"related"
],
"url": "https://osv.dev/vulnerability/EEF-CVE-2026-81637"
},
{
"name": "Introducing commit c5f5890 in team-alembic/ash_authentication",
"tags": [
"related"
],
"url": "https://github.com/team-alembic/ash_authentication/commit/c5f589058e04239263f50a1430eb17ea6d5dd1a2"
},
{
"name": "Fix commit bd43523 in team-alembic/ash_authentication",
"tags": [
"patch"
],
"url": "https://github.com/team-alembic/ash_authentication/commit/bd4352303bc9d72d007f6818775267585a4bcc2f"
},
{
"name": "Fix commit d7f939c in team-alembic/ash_authentication",
"tags": [
"patch"
],
"url": "https://github.com/team-alembic/ash_authentication/commit/d7f939cd02bd618bcaa304631846fa75ffc419d7"
}
],
"source": {
"discovery": "INTERNAL"
},
"title": "Replayable OAuth2 CSRF state retained after a failed callback in AshAuthentication"
}
},
"cveMetadata": {
"assignerOrgId": "6b3ad84c-e1a6-4bf7-a703-f496b71e49db",
"assignerShortName": "EEF",
"cveId": "CVE-2026-81637",
"datePublished": "2026-09-17T13:09:06.571Z",
"dateReserved": "2026-09-11T18:15:01.808Z",
"dateUpdated": "2026-09-17T18:26:58.389Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
CVE-2026-82761 (GCVE-0-2026-82761)
Vulnerability from cvelistv5 – Published: 2026-09-17 13:09 – Updated: 2026-09-17 18:26
VLAI
EPSS
VEX
Title
Magic link single-use tokens replayable via TOCTOU race in AshAuthentication
Summary
Time-of-check Time-of-use (TOCTOU) Race Condition vulnerability in team-alembic AshAuthentication allows an attacker holding a leaked magic link to replay its single-use token and authenticate as the target subject. A magic link configured with single_use_token?, which is the default, is meant to be redeemable exactly once, but nothing serialises the token's validity check against its consumption, so concurrent redemptions of one token all succeed and each yields a full user token.
Sign-in verifies the JWT with Jwt.verify/4 and revokes it only afterwards: AshAuthentication.Strategy.MagicLink.SignInPreparation revokes in a Query.after_action callback, and AshAuthentication.Strategy.MagicLink.SignInChange in an after_transaction hook that runs once the sign-in has already committed. AshAuthentication.TokenResource.Actions.revoke/3 writes the revocation as an upsert, so a concurrent duplicate revocation silently succeeds instead of conflicting and no request ever loses the race.
This issue affects ash_authentication: from 3.9.0 before 4.15.0 and from 5.0.0-rc.0 before 5.0.0-rc.14.
Severity
SSVC
Exploitation: none
Automatable: yes
Technical Impact: total
CISA Coordinator · CISA-ADP (v2.0.3)
Decision recorded 2026-09-17 18:25 UTC
CWE
- CWE-367 - Time-of-check Time-of-use (TOCTOU) Race Condition
Assigner
References
6 references
Impacted products
2 products
| Vendor | Product | Version | |
|---|---|---|---|
| team-alembic | ash_authentication |
Affected:
3.9.0 , < 4.15.0
(semver)
Affected: 5.0.0-rc.0 , < 5.0.0-rc.14 (semver) cpe:2.3:a:team-alembic:ash_authentication:*:*:*:*:*:*:*:* |
|
| team-alembic | ash_authentication |
Affected:
cf3d227ef25912cf1b0c5fa80f20001f5c46a102 , < *
(git)
cpe:2.3:a:team-alembic:ash_authentication:*:*:*:*:*:*:*:* |
{
"containers": {
"adp": [
{
"metrics": [
{
"other": {
"content": {
"id": "CVE-2026-82761",
"options": [
{
"Exploitation": "none"
},
{
"Automatable": "yes"
},
{
"Technical Impact": "total"
}
],
"role": "CISA Coordinator",
"timestamp": "2026-09-17T18:25:13.930894Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"providerMetadata": {
"dateUpdated": "2026-09-17T18:26:08.563Z",
"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:team-alembic:ash_authentication:*:*:*:*:*:*:*:*"
],
"defaultStatus": "unaffected",
"modules": [
"\u0027Elixir.AshAuthentication.Strategy.MagicLink.SignInPreparation\u0027",
"\u0027Elixir.AshAuthentication.Strategy.MagicLink.SignInChange\u0027",
"\u0027Elixir.AshAuthentication.TokenResource.Actions\u0027"
],
"packageName": "ash_authentication",
"packageURL": "pkg:hex/ash_authentication",
"product": "ash_authentication",
"programFiles": [
"lib/ash_authentication/strategies/magic_link/sign_in_preparation.ex",
"lib/ash_authentication/strategies/magic_link/sign_in_change.ex",
"lib/ash_authentication/token_resource/actions.ex"
],
"programRoutines": [
{
"name": "\u0027Elixir.AshAuthentication.Strategy.MagicLink.SignInPreparation\u0027:prepare/3"
},
{
"name": "\u0027Elixir.AshAuthentication.Strategy.MagicLink.SignInChange\u0027:change/3"
},
{
"name": "\u0027Elixir.AshAuthentication.TokenResource.Actions\u0027:revoke/3"
}
],
"repo": "https://github.com/team-alembic/ash_authentication",
"vendor": "team-alembic",
"versions": [
{
"lessThan": "4.15.0",
"status": "affected",
"version": "3.9.0",
"versionType": "semver"
},
{
"lessThan": "5.0.0-rc.14",
"status": "affected",
"version": "5.0.0-rc.0",
"versionType": "semver"
}
]
},
{
"collectionURL": "https://github.com",
"cpes": [
"cpe:2.3:a:team-alembic:ash_authentication:*:*:*:*:*:*:*:*"
],
"defaultStatus": "unaffected",
"modules": [
"\u0027Elixir.AshAuthentication.Strategy.MagicLink.SignInPreparation\u0027",
"\u0027Elixir.AshAuthentication.Strategy.MagicLink.SignInChange\u0027",
"\u0027Elixir.AshAuthentication.TokenResource.Actions\u0027"
],
"packageName": "team-alembic/ash_authentication",
"packageURL": "pkg:github/team-alembic/ash_authentication",
"product": "ash_authentication",
"programFiles": [
"lib/ash_authentication/strategies/magic_link/sign_in_preparation.ex",
"lib/ash_authentication/strategies/magic_link/sign_in_change.ex",
"lib/ash_authentication/token_resource/actions.ex"
],
"programRoutines": [
{
"name": "\u0027Elixir.AshAuthentication.Strategy.MagicLink.SignInPreparation\u0027:prepare/3"
},
{
"name": "\u0027Elixir.AshAuthentication.Strategy.MagicLink.SignInChange\u0027:change/3"
},
{
"name": "\u0027Elixir.AshAuthentication.TokenResource.Actions\u0027:revoke/3"
}
],
"repo": "https://github.com/team-alembic/ash_authentication",
"vendor": "team-alembic",
"versions": [
{
"changes": [
{
"at": "18dfdb36c14aa6a61df8572bce2d5ec36b1d9840",
"status": "unaffected"
},
{
"at": "9ef6864b8833d3b795427a7b8dc518a4997d41ab",
"status": "unaffected"
}
],
"lessThan": "*",
"status": "affected",
"version": "cf3d227ef25912cf1b0c5fa80f20001f5c46a102",
"versionType": "git"
}
]
}
],
"cpeApplicability": [
{
"nodes": [
{
"cpeMatch": [
{
"criteria": "cpe:2.3:a:team-alembic:ash_authentication:*:*:*:*:*:*:*:*",
"versionEndExcluding": "4.15.0",
"versionStartIncluding": "3.9.0",
"vulnerable": true
},
{
"criteria": "cpe:2.3:a:team-alembic:ash_authentication:*:*:*:*:*:*:*:*",
"versionEndExcluding": "5.0.0-rc.14",
"versionStartIncluding": "5.0.0-rc.0",
"vulnerable": true
}
],
"negate": false,
"operator": "OR"
}
],
"operator": "AND"
}
],
"credits": [
{
"lang": "en",
"type": "remediation developer",
"value": "James Harton"
},
{
"lang": "en",
"type": "reporter",
"value": "Peter Ullrich"
},
{
"lang": "en",
"type": "analyst",
"value": "Jonatan M\u00e4nnchen / EEF"
}
],
"dateAssigned": "2026-09-11T18:05:13.000Z",
"descriptions": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003eTime-of-check Time-of-use (TOCTOU) Race Condition vulnerability in team-alembic AshAuthentication allows an attacker holding a leaked magic link to replay its single-use token and authenticate as the target subject. A magic link configured with \u003ccode\u003esingle_use_token?\u003c/code\u003e, which is the default, is meant to be redeemable exactly once, but nothing serialises the token\u0027s validity check against its consumption, so concurrent redemptions of one token all succeed and each yields a full user token.\u003c/p\u003e\n\u003cp\u003eSign-in verifies the JWT with \u003ccode\u003eJwt.verify/4\u003c/code\u003e and revokes it only afterwards: \u003ccode\u003eAshAuthentication.Strategy.MagicLink.SignInPreparation\u003c/code\u003e revokes in a \u003ccode\u003eQuery.after_action\u003c/code\u003e callback, and \u003ccode\u003eAshAuthentication.Strategy.MagicLink.SignInChange\u003c/code\u003e in an \u003ccode\u003eafter_transaction\u003c/code\u003e hook that runs once the sign-in has already committed. \u003ccode\u003eAshAuthentication.TokenResource.Actions.revoke/3\u003c/code\u003e writes the revocation as an upsert, so a concurrent duplicate revocation silently succeeds instead of conflicting and no request ever loses the race.\u003c/p\u003e\n\u003cp\u003eThis issue affects ash_authentication: from 3.9.0 before 4.15.0 and from 5.0.0-rc.0 before 5.0.0-rc.14.\u003c/p\u003e"
},
{
"base64": false,
"type": "text/markdown",
"value": "Time-of-check Time-of-use (TOCTOU) Race Condition vulnerability in team-alembic AshAuthentication allows an attacker holding a leaked magic link to replay its single-use token and authenticate as the target subject. A magic link configured with `single_use_token?`, which is the default, is meant to be redeemable exactly once, but nothing serialises the token\u0027s validity check against its consumption, so concurrent redemptions of one token all succeed and each yields a full user token.\n\nSign-in verifies the JWT with `Jwt.verify/4` and revokes it only afterwards: `AshAuthentication.Strategy.MagicLink.SignInPreparation` revokes in a `Query.after_action` callback, and `AshAuthentication.Strategy.MagicLink.SignInChange` in an `after_transaction` hook that runs once the sign-in has already committed. `AshAuthentication.TokenResource.Actions.revoke/3` writes the revocation as an upsert, so a concurrent duplicate revocation silently succeeds instead of conflicting and no request ever loses the race.\n\nThis issue affects ash_authentication: from 3.9.0 before 4.15.0 and from 5.0.0-rc.0 before 5.0.0-rc.14."
}
],
"value": "Time-of-check Time-of-use (TOCTOU) Race Condition vulnerability in team-alembic AshAuthentication allows an attacker holding a leaked magic link to replay its single-use token and authenticate as the target subject. A magic link configured with single_use_token?, which is the default, is meant to be redeemable exactly once, but nothing serialises the token\u0027s validity check against its consumption, so concurrent redemptions of one token all succeed and each yields a full user token.\n\nSign-in verifies the JWT with Jwt.verify/4 and revokes it only afterwards: AshAuthentication.Strategy.MagicLink.SignInPreparation revokes in a Query.after_action callback, and AshAuthentication.Strategy.MagicLink.SignInChange in an after_transaction hook that runs once the sign-in has already committed. AshAuthentication.TokenResource.Actions.revoke/3 writes the revocation as an upsert, so a concurrent duplicate revocation silently succeeds instead of conflicting and no request ever loses the race.\n\nThis issue affects ash_authentication: from 3.9.0 before 4.15.0 and from 5.0.0-rc.0 before 5.0.0-rc.14."
}
],
"impacts": [
{
"capecId": "CAPEC-29",
"descriptions": [
{
"lang": "en",
"value": "CAPEC-29 Leveraging Time-of-Check and Time-of-Use (TOCTOU) Race Conditions"
}
]
}
],
"metrics": [
{
"cvssV4_0": {
"Automatable": "NOT_DEFINED",
"Recovery": "NOT_DEFINED",
"Safety": "NOT_DEFINED",
"attackComplexity": "LOW",
"attackRequirements": "PRESENT",
"attackVector": "NETWORK",
"baseScore": 9.1,
"baseSeverity": "CRITICAL",
"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:H/VI:H/VA:N/SC:N/SI:N/SA:N",
"version": "4.0",
"vulnAvailabilityImpact": "NONE",
"vulnConfidentialityImpact": "HIGH",
"vulnIntegrityImpact": "HIGH",
"vulnerabilityResponseEffort": "NOT_DEFINED"
},
"format": "CVSS",
"scenarios": [
{
"lang": "en",
"value": "GENERAL"
}
]
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-367",
"description": "CWE-367 Time-of-check Time-of-use (TOCTOU) Race Condition",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-09-17T13:09:01.534Z",
"orgId": "6b3ad84c-e1a6-4bf7-a703-f496b71e49db",
"shortName": "EEF"
},
"references": [
{
"tags": [
"related",
"vendor-advisory"
],
"url": "https://github.com/team-alembic/ash_authentication/security/advisories/GHSA-23gr-vcp4-r27q"
},
{
"name": "EEF CNA record for CVE-2026-82761",
"tags": [
"related"
],
"url": "https://cna.erlef.org/cves/CVE-2026-82761.html"
},
{
"name": "OSV record EEF-CVE-2026-82761",
"tags": [
"related"
],
"url": "https://osv.dev/vulnerability/EEF-CVE-2026-82761"
},
{
"name": "Introducing commit cf3d227 in team-alembic/ash_authentication",
"tags": [
"related"
],
"url": "https://github.com/team-alembic/ash_authentication/commit/cf3d227ef25912cf1b0c5fa80f20001f5c46a102"
},
{
"name": "Fix commit 18dfdb3 in team-alembic/ash_authentication",
"tags": [
"patch"
],
"url": "https://github.com/team-alembic/ash_authentication/commit/18dfdb36c14aa6a61df8572bce2d5ec36b1d9840"
},
{
"name": "Fix commit 9ef6864 in team-alembic/ash_authentication",
"tags": [
"patch"
],
"url": "https://github.com/team-alembic/ash_authentication/commit/9ef6864b8833d3b795427a7b8dc518a4997d41ab"
}
],
"source": {
"discovery": "INTERNAL"
},
"title": "Magic link single-use tokens replayable via TOCTOU race in AshAuthentication"
}
},
"cveMetadata": {
"assignerOrgId": "6b3ad84c-e1a6-4bf7-a703-f496b71e49db",
"assignerShortName": "EEF",
"cveId": "CVE-2026-82761",
"datePublished": "2026-09-17T13:09:01.534Z",
"dateReserved": "2026-08-31T01:00:10.817Z",
"dateUpdated": "2026-09-17T18:26:08.563Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
CVE-2026-82685 (GCVE-0-2026-82685)
Vulnerability from cvelistv5 – Published: 2026-09-17 13:08 – Updated: 2026-09-17 18:23
VLAI
EPSS
VEX
Title
Confirmation token accepted on any record in AshAuthentication
Summary
Authorization Bypass Through User-Controlled Key vulnerability in team-alembic AshAuthentication allows an authenticated attacker to overwrite and confirm another user's email address, and so take over that account. A confirmation token issued to one user is accepted on any other user's record.
AshAuthentication.AddOn.Confirmation.ConfirmChange verifies the token's signature and its act claim, then applies the changes stored against that token to whichever record the changeset targets, never comparing the sub claim against changeset.data. An attacker who registers an account and changes their own email replays the resulting token against a victim's record id, writing in their own address with force_change_attributes/2 and stamping confirmed_at, after which an ordinary password reset yields the account. The library's own confirmation flow is unaffected, because AshAuthentication.AddOn.Confirmation.Actions.confirm/3 resolves sub to a user and targets that record.
This issue affects ash_authentication: from 0.5.0 before 4.15.0 and from 5.0.0-rc.0 before 5.0.0-rc.14.
Severity
SSVC
Exploitation: none
Automatable: no
Technical Impact: total
CISA Coordinator · CISA-ADP (v2.0.3)
Decision recorded 2026-09-17 18:23 UTC
CWE
- CWE-639 - Authorization Bypass Through User-Controlled Key
Assigner
References
6 references
Impacted products
2 products
| Vendor | Product | Version | |
|---|---|---|---|
| team-alembic | ash_authentication |
Affected:
0.5.0 , < 4.15.0
(semver)
Affected: 5.0.0-rc.0 , < 5.0.0-rc.14 (semver) cpe:2.3:a:team-alembic:ash_authentication:*:*:*:*:*:*:*:* |
|
| team-alembic | ash_authentication |
Affected:
1d4bb00617aecae85c33f2ff5bc7e094c6449a6e , < *
(git)
cpe:2.3:a:team-alembic:ash_authentication:*:*:*:*:*:*:*:* |
{
"containers": {
"adp": [
{
"metrics": [
{
"other": {
"content": {
"id": "CVE-2026-82685",
"options": [
{
"Exploitation": "none"
},
{
"Automatable": "no"
},
{
"Technical Impact": "total"
}
],
"role": "CISA Coordinator",
"timestamp": "2026-09-17T18:23:08.889793Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"providerMetadata": {
"dateUpdated": "2026-09-17T18:23:51.075Z",
"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:team-alembic:ash_authentication:*:*:*:*:*:*:*:*"
],
"defaultStatus": "unaffected",
"modules": [
"\u0027Elixir.AshAuthentication.AddOn.Confirmation.ConfirmChange\u0027"
],
"packageName": "ash_authentication",
"packageURL": "pkg:hex/ash_authentication",
"product": "ash_authentication",
"programFiles": [
"lib/ash_authentication/add_ons/confirmation/confirm_change.ex"
],
"programRoutines": [
{
"name": "\u0027Elixir.AshAuthentication.AddOn.Confirmation.ConfirmChange\u0027:change/3"
}
],
"repo": "https://github.com/team-alembic/ash_authentication",
"vendor": "team-alembic",
"versions": [
{
"lessThan": "4.15.0",
"status": "affected",
"version": "0.5.0",
"versionType": "semver"
},
{
"lessThan": "5.0.0-rc.14",
"status": "affected",
"version": "5.0.0-rc.0",
"versionType": "semver"
}
]
},
{
"collectionURL": "https://github.com",
"cpes": [
"cpe:2.3:a:team-alembic:ash_authentication:*:*:*:*:*:*:*:*"
],
"defaultStatus": "unaffected",
"modules": [
"\u0027Elixir.AshAuthentication.AddOn.Confirmation.ConfirmChange\u0027"
],
"packageName": "team-alembic/ash_authentication",
"packageURL": "pkg:github/team-alembic/ash_authentication",
"product": "ash_authentication",
"programFiles": [
"lib/ash_authentication/add_ons/confirmation/confirm_change.ex"
],
"programRoutines": [
{
"name": "\u0027Elixir.AshAuthentication.AddOn.Confirmation.ConfirmChange\u0027:change/3"
}
],
"repo": "https://github.com/team-alembic/ash_authentication",
"vendor": "team-alembic",
"versions": [
{
"changes": [
{
"at": "d7c15c21d39c009206e010cd67e2d86370fe7a28",
"status": "unaffected"
},
{
"at": "2a2396af131ab67e2f445b805fecce8e6ca86c0e",
"status": "unaffected"
}
],
"lessThan": "*",
"status": "affected",
"version": "1d4bb00617aecae85c33f2ff5bc7e094c6449a6e",
"versionType": "git"
}
]
}
],
"cpeApplicability": [
{
"nodes": [
{
"cpeMatch": [
{
"criteria": "cpe:2.3:a:team-alembic:ash_authentication:*:*:*:*:*:*:*:*",
"versionEndExcluding": "4.15.0",
"versionStartIncluding": "0.5.0",
"vulnerable": true
},
{
"criteria": "cpe:2.3:a:team-alembic:ash_authentication:*:*:*:*:*:*:*:*",
"versionEndExcluding": "5.0.0-rc.14",
"versionStartIncluding": "5.0.0-rc.0",
"vulnerable": true
}
],
"negate": false,
"operator": "OR"
}
],
"operator": "AND"
}
],
"credits": [
{
"lang": "en",
"type": "reporter",
"value": "Peter Ullrich"
},
{
"lang": "en",
"type": "remediation developer",
"value": "James Harton"
},
{
"lang": "en",
"type": "analyst",
"value": "Jonatan M\u00e4nnchen / EEF"
}
],
"dateAssigned": "2026-09-11T17:35:42.000Z",
"descriptions": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003eAuthorization Bypass Through User-Controlled Key vulnerability in team-alembic AshAuthentication allows an authenticated attacker to overwrite and confirm another user\u0027s email address, and so take over that account. A confirmation token issued to one user is accepted on any other user\u0027s record.\u003c/p\u003e\n\u003cp\u003e\u003ccode\u003eAshAuthentication.AddOn.Confirmation.ConfirmChange\u003c/code\u003e verifies the token\u0027s signature and its \u003ccode\u003eact\u003c/code\u003e claim, then applies the changes stored against that token to whichever record the changeset targets, never comparing the \u003ccode\u003esub\u003c/code\u003e claim against \u003ccode\u003echangeset.data\u003c/code\u003e. An attacker who registers an account and changes their own email replays the resulting token against a victim\u0027s record id, writing in their own address with \u003ccode\u003eforce_change_attributes/2\u003c/code\u003e and stamping \u003ccode\u003econfirmed_at\u003c/code\u003e, after which an ordinary password reset yields the account. The library\u0027s own confirmation flow is unaffected, because \u003ccode\u003eAshAuthentication.AddOn.Confirmation.Actions.confirm/3\u003c/code\u003e resolves \u003ccode\u003esub\u003c/code\u003e to a user and targets that record.\u003c/p\u003e\n\u003cp\u003eThis issue affects ash_authentication: from 0.5.0 before 4.15.0 and from 5.0.0-rc.0 before 5.0.0-rc.14.\u003c/p\u003e"
},
{
"base64": false,
"type": "text/markdown",
"value": "Authorization Bypass Through User-Controlled Key vulnerability in team-alembic AshAuthentication allows an authenticated attacker to overwrite and confirm another user\u0027s email address, and so take over that account. A confirmation token issued to one user is accepted on any other user\u0027s record.\n\n`AshAuthentication.AddOn.Confirmation.ConfirmChange` verifies the token\u0027s signature and its `act` claim, then applies the changes stored against that token to whichever record the changeset targets, never comparing the `sub` claim against `changeset.data`. An attacker who registers an account and changes their own email replays the resulting token against a victim\u0027s record id, writing in their own address with `force_change_attributes/2` and stamping `confirmed_at`, after which an ordinary password reset yields the account. The library\u0027s own confirmation flow is unaffected, because `AshAuthentication.AddOn.Confirmation.Actions.confirm/3` resolves `sub` to a user and targets that record.\n\nThis issue affects ash_authentication: from 0.5.0 before 4.15.0 and from 5.0.0-rc.0 before 5.0.0-rc.14."
}
],
"value": "Authorization Bypass Through User-Controlled Key vulnerability in team-alembic AshAuthentication allows an authenticated attacker to overwrite and confirm another user\u0027s email address, and so take over that account. A confirmation token issued to one user is accepted on any other user\u0027s record.\n\nAshAuthentication.AddOn.Confirmation.ConfirmChange verifies the token\u0027s signature and its act claim, then applies the changes stored against that token to whichever record the changeset targets, never comparing the sub claim against changeset.data. An attacker who registers an account and changes their own email replays the resulting token against a victim\u0027s record id, writing in their own address with force_change_attributes/2 and stamping confirmed_at, after which an ordinary password reset yields the account. The library\u0027s own confirmation flow is unaffected, because AshAuthentication.AddOn.Confirmation.Actions.confirm/3 resolves sub to a user and targets that record.\n\nThis issue affects ash_authentication: from 0.5.0 before 4.15.0 and from 5.0.0-rc.0 before 5.0.0-rc.14."
}
],
"impacts": [
{
"capecId": "CAPEC-21",
"descriptions": [
{
"lang": "en",
"value": "CAPEC-21 Exploitation of Trusted Identifiers"
}
]
}
],
"metrics": [
{
"cvssV4_0": {
"Automatable": "NOT_DEFINED",
"Recovery": "NOT_DEFINED",
"Safety": "NOT_DEFINED",
"attackComplexity": "LOW",
"attackRequirements": "PRESENT",
"attackVector": "NETWORK",
"baseScore": 7.6,
"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:P/PR:L/UI:N/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N",
"version": "4.0",
"vulnAvailabilityImpact": "NONE",
"vulnConfidentialityImpact": "HIGH",
"vulnIntegrityImpact": "HIGH",
"vulnerabilityResponseEffort": "NOT_DEFINED"
},
"format": "CVSS",
"scenarios": [
{
"lang": "en",
"value": "GENERAL"
}
]
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-639",
"description": "CWE-639 Authorization Bypass Through User-Controlled Key",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-09-17T13:08:56.491Z",
"orgId": "6b3ad84c-e1a6-4bf7-a703-f496b71e49db",
"shortName": "EEF"
},
"references": [
{
"tags": [
"related",
"vendor-advisory"
],
"url": "https://github.com/team-alembic/ash_authentication/security/advisories/GHSA-g636-26vf-2w63"
},
{
"name": "EEF CNA record for CVE-2026-82685",
"tags": [
"related"
],
"url": "https://cna.erlef.org/cves/CVE-2026-82685.html"
},
{
"name": "OSV record EEF-CVE-2026-82685",
"tags": [
"related"
],
"url": "https://osv.dev/vulnerability/EEF-CVE-2026-82685"
},
{
"name": "Introducing commit 1d4bb00 in team-alembic/ash_authentication",
"tags": [
"related"
],
"url": "https://github.com/team-alembic/ash_authentication/commit/1d4bb00617aecae85c33f2ff5bc7e094c6449a6e"
},
{
"name": "Fix commit d7c15c2 in team-alembic/ash_authentication",
"tags": [
"patch"
],
"url": "https://github.com/team-alembic/ash_authentication/commit/d7c15c21d39c009206e010cd67e2d86370fe7a28"
},
{
"name": "Fix commit 2a2396a in team-alembic/ash_authentication",
"tags": [
"patch"
],
"url": "https://github.com/team-alembic/ash_authentication/commit/2a2396af131ab67e2f445b805fecce8e6ca86c0e"
}
],
"source": {
"discovery": "INTERNAL"
},
"title": "Confirmation token accepted on any record in AshAuthentication"
}
},
"cveMetadata": {
"assignerOrgId": "6b3ad84c-e1a6-4bf7-a703-f496b71e49db",
"assignerShortName": "EEF",
"cveId": "CVE-2026-82685",
"datePublished": "2026-09-17T13:08:56.491Z",
"dateReserved": "2026-08-31T00:45:02.436Z",
"dateUpdated": "2026-09-17T18:23:51.075Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
CVE-2026-82760 (GCVE-0-2026-82760)
Vulnerability from cvelistv5 – Published: 2026-09-17 13:08 – Updated: 2026-09-17 18:21
VLAI
EPSS
VEX
Title
Superlinear base62 decoding exhausts CPU and memory in AshAuthentication API key sign-in
Summary
Inefficient Algorithmic Complexity vulnerability in team-alembic AshAuthentication allows an unauthenticated attacker to exhaust CPU and memory via an oversized base62 segment in a submitted API key.
AshAuthentication.Base.decode62/1 in lib/ash_authentication/base.ex splits its argument into one binary per character and folds it with charval62/2, which recomputes Integer.pow(62, index) at every position instead of accumulating by Horner's method, so cost grows roughly cubically in the input length. bindecode62/1 in the same module is quadratic through Integer.undigits/2 and Integer.digits/2. Neither function caps byte_size/1, and AshAuthentication.Strategy.ApiKey.SignInPreparation passes the underscore-separated segments of the submitted key straight into both, before any key lookup and without prior authentication. The surrounding rescue clauses catch exceptions, not CPU or memory exhaustion.
This issue affects ash_authentication: from 4.8.0 before 4.15.0 and from 5.0.0-rc.0 before 5.0.0-rc.14.
Severity
SSVC
Exploitation: none
Automatable: no
Technical Impact: partial
CISA Coordinator · CISA-ADP (v2.0.3)
Decision recorded 2026-09-17 18:21 UTC
CWE
- CWE-407 - Inefficient Algorithmic Complexity
Assigner
References
6 references
Impacted products
2 products
| Vendor | Product | Version | |
|---|---|---|---|
| team-alembic | ash_authentication |
Affected:
4.8.0 , < 4.15.0
(semver)
Affected: 5.0.0-rc.0 , < 5.0.0-rc.14 (semver) cpe:2.3:a:team-alembic:ash_authentication:*:*:*:*:*:*:*:* |
|
| team-alembic | ash_authentication |
Affected:
f3a53f480088419788d5c3934af3131fa9066773 , < *
(git)
cpe:2.3:a:team-alembic:ash_authentication:*:*:*:*:*:*:*:* |
{
"containers": {
"adp": [
{
"metrics": [
{
"other": {
"content": {
"id": "CVE-2026-82760",
"options": [
{
"Exploitation": "none"
},
{
"Automatable": "no"
},
{
"Technical Impact": "partial"
}
],
"role": "CISA Coordinator",
"timestamp": "2026-09-17T18:21:05.949151Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"providerMetadata": {
"dateUpdated": "2026-09-17T18:21:26.238Z",
"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:team-alembic:ash_authentication:*:*:*:*:*:*:*:*"
],
"defaultStatus": "unaffected",
"modules": [
"\u0027Elixir.AshAuthentication.Base\u0027",
"\u0027Elixir.AshAuthentication.Strategy.ApiKey.SignInPreparation\u0027"
],
"packageName": "ash_authentication",
"packageURL": "pkg:hex/ash_authentication",
"product": "ash_authentication",
"programFiles": [
"lib/ash_authentication/base.ex",
"lib/ash_authentication/strategies/api_key/sign_in_preparation.ex"
],
"programRoutines": [
{
"name": "\u0027Elixir.AshAuthentication.Base\u0027:decode62/1"
},
{
"name": "\u0027Elixir.AshAuthentication.Base\u0027:bindecode62/1"
},
{
"name": "\u0027Elixir.AshAuthentication.Strategy.ApiKey.SignInPreparation\u0027:prepare/3"
}
],
"repo": "https://github.com/team-alembic/ash_authentication",
"vendor": "team-alembic",
"versions": [
{
"lessThan": "4.15.0",
"status": "affected",
"version": "4.8.0",
"versionType": "semver"
},
{
"lessThan": "5.0.0-rc.14",
"status": "affected",
"version": "5.0.0-rc.0",
"versionType": "semver"
}
]
},
{
"collectionURL": "https://github.com",
"cpes": [
"cpe:2.3:a:team-alembic:ash_authentication:*:*:*:*:*:*:*:*"
],
"defaultStatus": "unaffected",
"modules": [
"\u0027Elixir.AshAuthentication.Base\u0027",
"\u0027Elixir.AshAuthentication.Strategy.ApiKey.SignInPreparation\u0027"
],
"packageName": "team-alembic/ash_authentication",
"packageURL": "pkg:github/team-alembic/ash_authentication",
"product": "ash_authentication",
"programFiles": [
"lib/ash_authentication/base.ex",
"lib/ash_authentication/strategies/api_key/sign_in_preparation.ex"
],
"programRoutines": [
{
"name": "\u0027Elixir.AshAuthentication.Base\u0027:decode62/1"
},
{
"name": "\u0027Elixir.AshAuthentication.Base\u0027:bindecode62/1"
},
{
"name": "\u0027Elixir.AshAuthentication.Strategy.ApiKey.SignInPreparation\u0027:prepare/3"
}
],
"repo": "https://github.com/team-alembic/ash_authentication",
"vendor": "team-alembic",
"versions": [
{
"changes": [
{
"at": "d5a5d4cb5cc17fbd6e2a120a6111b47accad4b8e",
"status": "unaffected"
},
{
"at": "dfb19c897853686ab481c5e773f7a1a0c74dea04",
"status": "unaffected"
}
],
"lessThan": "*",
"status": "affected",
"version": "f3a53f480088419788d5c3934af3131fa9066773",
"versionType": "git"
}
]
}
],
"cpeApplicability": [
{
"nodes": [
{
"cpeMatch": [
{
"criteria": "cpe:2.3:a:team-alembic:ash_authentication:*:*:*:*:*:*:*:*",
"versionEndExcluding": "4.15.0",
"versionStartIncluding": "4.8.0",
"vulnerable": true
},
{
"criteria": "cpe:2.3:a:team-alembic:ash_authentication:*:*:*:*:*:*:*:*",
"versionEndExcluding": "5.0.0-rc.14",
"versionStartIncluding": "5.0.0-rc.0",
"vulnerable": true
}
],
"negate": false,
"operator": "OR"
}
],
"operator": "AND"
}
],
"credits": [
{
"lang": "en",
"type": "reporter",
"value": "Peter Ullrich"
},
{
"lang": "en",
"type": "remediation developer",
"value": "James Harton"
},
{
"lang": "en",
"type": "analyst",
"value": "Jonatan M\u00e4nnchen / EEF"
}
],
"dateAssigned": "2026-09-11T17:59:54.000Z",
"descriptions": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003eInefficient Algorithmic Complexity vulnerability in team-alembic AshAuthentication allows an unauthenticated attacker to exhaust CPU and memory via an oversized base62 segment in a submitted API key.\u003c/p\u003e\n\u003cp\u003e\u003ccode\u003eAshAuthentication.Base.decode62/1\u003c/code\u003e in \u003ccode\u003elib/ash_authentication/base.ex\u003c/code\u003e splits its argument into one binary per character and folds it with \u003ccode\u003echarval62/2\u003c/code\u003e, which recomputes \u003ccode\u003eInteger.pow(62, index)\u003c/code\u003e at every position instead of accumulating by Horner\u0027s method, so cost grows roughly cubically in the input length. \u003ccode\u003ebindecode62/1\u003c/code\u003e in the same module is quadratic through \u003ccode\u003eInteger.undigits/2\u003c/code\u003e and \u003ccode\u003eInteger.digits/2\u003c/code\u003e. Neither function caps \u003ccode\u003ebyte_size/1\u003c/code\u003e, and \u003ccode\u003eAshAuthentication.Strategy.ApiKey.SignInPreparation\u003c/code\u003e passes the underscore-separated segments of the submitted key straight into both, before any key lookup and without prior authentication. The surrounding \u003ccode\u003erescue\u003c/code\u003e clauses catch exceptions, not CPU or memory exhaustion.\u003c/p\u003e\n\u003cp\u003eThis issue affects ash_authentication: from 4.8.0 before 4.15.0 and from 5.0.0-rc.0 before 5.0.0-rc.14.\u003c/p\u003e"
},
{
"base64": false,
"type": "text/markdown",
"value": "Inefficient Algorithmic Complexity vulnerability in team-alembic AshAuthentication allows an unauthenticated attacker to exhaust CPU and memory via an oversized base62 segment in a submitted API key.\n\n`AshAuthentication.Base.decode62/1` in `lib/ash_authentication/base.ex` splits its argument into one binary per character and folds it with `charval62/2`, which recomputes `Integer.pow(62, index)` at every position instead of accumulating by Horner\u0027s method, so cost grows roughly cubically in the input length. `bindecode62/1` in the same module is quadratic through `Integer.undigits/2` and `Integer.digits/2`. Neither function caps `byte_size/1`, and `AshAuthentication.Strategy.ApiKey.SignInPreparation` passes the underscore-separated segments of the submitted key straight into both, before any key lookup and without prior authentication. The surrounding `rescue` clauses catch exceptions, not CPU or memory exhaustion.\n\nThis issue affects ash_authentication: from 4.8.0 before 4.15.0 and from 5.0.0-rc.0 before 5.0.0-rc.14."
}
],
"value": "Inefficient Algorithmic Complexity vulnerability in team-alembic AshAuthentication allows an unauthenticated attacker to exhaust CPU and memory via an oversized base62 segment in a submitted API key.\n\nAshAuthentication.Base.decode62/1 in lib/ash_authentication/base.ex splits its argument into one binary per character and folds it with charval62/2, which recomputes Integer.pow(62, index) at every position instead of accumulating by Horner\u0027s method, so cost grows roughly cubically in the input length. bindecode62/1 in the same module is quadratic through Integer.undigits/2 and Integer.digits/2. Neither function caps byte_size/1, and AshAuthentication.Strategy.ApiKey.SignInPreparation passes the underscore-separated segments of the submitted key straight into both, before any key lookup and without prior authentication. The surrounding rescue clauses catch exceptions, not CPU or memory exhaustion.\n\nThis issue affects ash_authentication: from 4.8.0 before 4.15.0 and from 5.0.0-rc.0 before 5.0.0-rc.14."
}
],
"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-407",
"description": "CWE-407 Inefficient Algorithmic Complexity",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-09-17T13:08:46.382Z",
"orgId": "6b3ad84c-e1a6-4bf7-a703-f496b71e49db",
"shortName": "EEF"
},
"references": [
{
"tags": [
"related",
"vendor-advisory"
],
"url": "https://github.com/team-alembic/ash_authentication/security/advisories/GHSA-q876-xr24-2mcx"
},
{
"name": "EEF CNA record for CVE-2026-82760",
"tags": [
"related"
],
"url": "https://cna.erlef.org/cves/CVE-2026-82760.html"
},
{
"name": "OSV record EEF-CVE-2026-82760",
"tags": [
"related"
],
"url": "https://osv.dev/vulnerability/EEF-CVE-2026-82760"
},
{
"name": "Introducing commit f3a53f4 in team-alembic/ash_authentication",
"tags": [
"related"
],
"url": "https://github.com/team-alembic/ash_authentication/commit/f3a53f480088419788d5c3934af3131fa9066773"
},
{
"name": "Fix commit d5a5d4c in team-alembic/ash_authentication",
"tags": [
"patch"
],
"url": "https://github.com/team-alembic/ash_authentication/commit/d5a5d4cb5cc17fbd6e2a120a6111b47accad4b8e"
},
{
"name": "Fix commit dfb19c8 in team-alembic/ash_authentication",
"tags": [
"patch"
],
"url": "https://github.com/team-alembic/ash_authentication/commit/dfb19c897853686ab481c5e773f7a1a0c74dea04"
}
],
"source": {
"discovery": "INTERNAL"
},
"title": "Superlinear base62 decoding exhausts CPU and memory in AshAuthentication API key sign-in"
}
},
"cveMetadata": {
"assignerOrgId": "6b3ad84c-e1a6-4bf7-a703-f496b71e49db",
"assignerShortName": "EEF",
"cveId": "CVE-2026-82760",
"datePublished": "2026-09-17T13:08:46.382Z",
"dateReserved": "2026-08-31T01:00:10.817Z",
"dateUpdated": "2026-09-17T18:21:26.238Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
CVE-2026-82759 (GCVE-0-2026-82759)
Vulnerability from cvelistv5 – Published: 2026-09-17 13:08 – Updated: 2026-09-17 18:19
VLAI
EPSS
VEX
Title
Reversible IP address pseudonymisation in AshAuthentication audit log hash mode
Summary
Use of a One-Way Hash with a Predictable Salt vulnerability in team-alembic AshAuthentication allows readers of the audit store to recover the client IP addresses that the audit log add-on's :hash privacy mode is meant to pseudonymise.
AshAuthentication.AddOn.AuditLog.IpPrivacy.hash_ip/1 computes a single unkeyed :crypto.hash(:sha256, salt <> ip) and truncates the result to 16 hexadecimal characters. The salt is read from the :audit_log_ip_salt or :secret application config keys, and falls back to the constant "default-salt-change-in-production" published in the library source when neither is set, with nothing warning that the default is in use. The IPv4 space is only 2^32 values and SHA-256 is fast, so the whole hash table is precomputable and every stored value maps back to its source address. Truncating to 16 characters does not help, and even a configured salt leaves the hash cheap enough to enumerate once it leaks.
This issue affects ash_authentication: from 4.12.0 before 4.15.0 and from 5.0.0-rc.0 before 5.0.0-rc.14.
Severity
SSVC
Exploitation: none
Automatable: no
Technical Impact: partial
CISA Coordinator · CISA-ADP (v2.0.3)
Decision recorded 2026-09-17 18:19 UTC
CWE
- CWE-760 - Use of a One-Way Hash with a Predictable Salt
Assigner
References
6 references
Impacted products
2 products
| Vendor | Product | Version | |
|---|---|---|---|
| team-alembic | ash_authentication |
Affected:
4.12.0 , < 4.15.0
(semver)
Affected: 5.0.0-rc.0 , < 5.0.0-rc.14 (semver) cpe:2.3:a:team-alembic:ash_authentication:*:*:*:*:*:*:*:* |
|
| team-alembic | ash_authentication |
Affected:
255cfc9c0e511b7e0de39f8b3d676ae994fae06c , < *
(git)
cpe:2.3:a:team-alembic:ash_authentication:*:*:*:*:*:*:*:* |
{
"containers": {
"adp": [
{
"metrics": [
{
"other": {
"content": {
"id": "CVE-2026-82759",
"options": [
{
"Exploitation": "none"
},
{
"Automatable": "no"
},
{
"Technical Impact": "partial"
}
],
"role": "CISA Coordinator",
"timestamp": "2026-09-17T18:19:03.885925Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"providerMetadata": {
"dateUpdated": "2026-09-17T18:19:18.209Z",
"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:team-alembic:ash_authentication:*:*:*:*:*:*:*:*"
],
"defaultStatus": "unaffected",
"modules": [
"\u0027Elixir.AshAuthentication.AddOn.AuditLog.IpPrivacy\u0027"
],
"packageName": "ash_authentication",
"packageURL": "pkg:hex/ash_authentication",
"product": "ash_authentication",
"programFiles": [
"lib/ash_authentication/add_ons/audit_log/ip_privacy.ex"
],
"programRoutines": [
{
"name": "\u0027Elixir.AshAuthentication.AddOn.AuditLog.IpPrivacy\u0027:hash_ip/1"
},
{
"name": "\u0027Elixir.AshAuthentication.AddOn.AuditLog.IpPrivacy\u0027:apply_privacy/3"
}
],
"repo": "https://github.com/team-alembic/ash_authentication",
"vendor": "team-alembic",
"versions": [
{
"lessThan": "4.15.0",
"status": "affected",
"version": "4.12.0",
"versionType": "semver"
},
{
"lessThan": "5.0.0-rc.14",
"status": "affected",
"version": "5.0.0-rc.0",
"versionType": "semver"
}
]
},
{
"collectionURL": "https://github.com",
"cpes": [
"cpe:2.3:a:team-alembic:ash_authentication:*:*:*:*:*:*:*:*"
],
"defaultStatus": "unaffected",
"modules": [
"\u0027Elixir.AshAuthentication.AddOn.AuditLog.IpPrivacy\u0027"
],
"packageName": "team-alembic/ash_authentication",
"packageURL": "pkg:github/team-alembic/ash_authentication",
"product": "ash_authentication",
"programFiles": [
"lib/ash_authentication/add_ons/audit_log/ip_privacy.ex"
],
"programRoutines": [
{
"name": "\u0027Elixir.AshAuthentication.AddOn.AuditLog.IpPrivacy\u0027:hash_ip/1"
},
{
"name": "\u0027Elixir.AshAuthentication.AddOn.AuditLog.IpPrivacy\u0027:apply_privacy/3"
}
],
"repo": "https://github.com/team-alembic/ash_authentication",
"vendor": "team-alembic",
"versions": [
{
"changes": [
{
"at": "d8a9c4b6bde828fdc8346198d5e4f588b5937541",
"status": "unaffected"
},
{
"at": "c3a6d5fe0d4fd383ea81b0402db0a96638479478",
"status": "unaffected"
}
],
"lessThan": "*",
"status": "affected",
"version": "255cfc9c0e511b7e0de39f8b3d676ae994fae06c",
"versionType": "git"
}
]
}
],
"configurations": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003eOnly applications that enable the \u003ccode\u003eaudit_log\u003c/code\u003e add-on and set its \u003ccode\u003eip_privacy\u003c/code\u003e mode to \u003ccode\u003e:hash\u003c/code\u003e store the affected value. Other modes (\u003ccode\u003e:none\u003c/code\u003e, \u003ccode\u003e:truncate\u003c/code\u003e, \u003ccode\u003e:exclude\u003c/code\u003e) do not reach \u003ccode\u003ehash_ip/1\u003c/code\u003e.\u003c/p\u003e\n\u003cp\u003eThe complete break additionally requires the default salt, that is neither \u003ccode\u003e:audit_log_ip_salt\u003c/code\u003e nor \u003ccode\u003e:secret\u003c/code\u003e configured under the \u003ccode\u003e:ash_authentication\u003c/code\u003e application. This is the out-of-the-box state: no warning or error is raised when the hardcoded salt is in use.\u003c/p\u003e"
},
{
"base64": false,
"type": "text/markdown",
"value": "Only applications that enable the `audit_log` add-on and set its `ip_privacy` mode to `:hash` store the affected value. Other modes (`:none`, `:truncate`, `:exclude`) do not reach `hash_ip/1`.\n\nThe complete break additionally requires the default salt, that is neither `:audit_log_ip_salt` nor `:secret` configured under the `:ash_authentication` application. This is the out-of-the-box state: no warning or error is raised when the hardcoded salt is in use."
}
],
"value": "Only applications that enable the audit_log add-on and set its ip_privacy mode to :hash store the affected value. Other modes (:none, :truncate, :exclude) do not reach hash_ip/1.\n\nThe complete break additionally requires the default salt, that is neither :audit_log_ip_salt nor :secret configured under the :ash_authentication application. This is the out-of-the-box state: no warning or error is raised when the hardcoded salt is in use."
}
],
"cpeApplicability": [
{
"nodes": [
{
"cpeMatch": [
{
"criteria": "cpe:2.3:a:team-alembic:ash_authentication:*:*:*:*:*:*:*:*",
"versionEndExcluding": "4.15.0",
"versionStartIncluding": "4.12.0",
"vulnerable": true
},
{
"criteria": "cpe:2.3:a:team-alembic:ash_authentication:*:*:*:*:*:*:*:*",
"versionEndExcluding": "5.0.0-rc.14",
"versionStartIncluding": "5.0.0-rc.0",
"vulnerable": true
}
],
"negate": false,
"operator": "OR"
}
],
"operator": "AND"
}
],
"credits": [
{
"lang": "en",
"type": "analyst",
"value": "Jonatan M\u00e4nnchen / EEF"
},
{
"lang": "en",
"type": "remediation developer",
"value": "James Harton"
},
{
"lang": "en",
"type": "reporter",
"value": "Peter Ullrich"
}
],
"dateAssigned": "2026-09-11T17:53:27.000Z",
"descriptions": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003eUse of a One-Way Hash with a Predictable Salt vulnerability in team-alembic AshAuthentication allows readers of the audit store to recover the client IP addresses that the audit log add-on\u0027s \u003ccode\u003e:hash\u003c/code\u003e privacy mode is meant to pseudonymise.\u003c/p\u003e\n\u003cp\u003e\u003ccode\u003eAshAuthentication.AddOn.AuditLog.IpPrivacy.hash_ip/1\u003c/code\u003e computes a single unkeyed \u003ccode\u003e:crypto.hash(:sha256, salt \u0026lt;\u0026gt; ip)\u003c/code\u003e and truncates the result to 16 hexadecimal characters. The salt is read from the \u003ccode\u003e:audit_log_ip_salt\u003c/code\u003e or \u003ccode\u003e:secret\u003c/code\u003e application config keys, and falls back to the constant \u003ccode\u003e\"default-salt-change-in-production\"\u003c/code\u003e published in the library source when neither is set, with nothing warning that the default is in use. The IPv4 space is only 2^32 values and SHA-256 is fast, so the whole hash table is precomputable and every stored value maps back to its source address. Truncating to 16 characters does not help, and even a configured salt leaves the hash cheap enough to enumerate once it leaks.\u003c/p\u003e\n\u003cp\u003eThis issue affects ash_authentication: from 4.12.0 before 4.15.0 and from 5.0.0-rc.0 before 5.0.0-rc.14.\u003c/p\u003e"
},
{
"base64": false,
"type": "text/markdown",
"value": "Use of a One-Way Hash with a Predictable Salt vulnerability in team-alembic AshAuthentication allows readers of the audit store to recover the client IP addresses that the audit log add-on\u0027s `:hash` privacy mode is meant to pseudonymise.\n\n`AshAuthentication.AddOn.AuditLog.IpPrivacy.hash_ip/1` computes a single unkeyed `:crypto.hash(:sha256, salt \u003c\u003e ip)` and truncates the result to 16 hexadecimal characters. The salt is read from the `:audit_log_ip_salt` or `:secret` application config keys, and falls back to the constant `\"default-salt-change-in-production\"` published in the library source when neither is set, with nothing warning that the default is in use. The IPv4 space is only 2^32 values and SHA-256 is fast, so the whole hash table is precomputable and every stored value maps back to its source address. Truncating to 16 characters does not help, and even a configured salt leaves the hash cheap enough to enumerate once it leaks.\n\nThis issue affects ash_authentication: from 4.12.0 before 4.15.0 and from 5.0.0-rc.0 before 5.0.0-rc.14."
}
],
"value": "Use of a One-Way Hash with a Predictable Salt vulnerability in team-alembic AshAuthentication allows readers of the audit store to recover the client IP addresses that the audit log add-on\u0027s :hash privacy mode is meant to pseudonymise.\n\nAshAuthentication.AddOn.AuditLog.IpPrivacy.hash_ip/1 computes a single unkeyed :crypto.hash(:sha256, salt \u003c\u003e ip) and truncates the result to 16 hexadecimal characters. The salt is read from the :audit_log_ip_salt or :secret application config keys, and falls back to the constant \"default-salt-change-in-production\" published in the library source when neither is set, with nothing warning that the default is in use. The IPv4 space is only 2^32 values and SHA-256 is fast, so the whole hash table is precomputable and every stored value maps back to its source address. Truncating to 16 characters does not help, and even a configured salt leaves the hash cheap enough to enumerate once it leaks.\n\nThis issue affects ash_authentication: from 4.12.0 before 4.15.0 and from 5.0.0-rc.0 before 5.0.0-rc.14."
}
],
"impacts": [
{
"capecId": "CAPEC-112",
"descriptions": [
{
"lang": "en",
"value": "CAPEC-112 Brute Force"
}
]
}
],
"metrics": [
{
"cvssV4_0": {
"Automatable": "NOT_DEFINED",
"Recovery": "NOT_DEFINED",
"Safety": "NOT_DEFINED",
"attackComplexity": "LOW",
"attackRequirements": "PRESENT",
"attackVector": "LOCAL",
"baseScore": 1.8,
"baseSeverity": "LOW",
"privilegesRequired": "HIGH",
"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:H/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-760",
"description": "CWE-760 Use of a One-Way Hash with a Predictable Salt",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-09-17T13:08:21.929Z",
"orgId": "6b3ad84c-e1a6-4bf7-a703-f496b71e49db",
"shortName": "EEF"
},
"references": [
{
"tags": [
"related",
"vendor-advisory"
],
"url": "https://github.com/team-alembic/ash_authentication/security/advisories/GHSA-cgqj-pcpq-xhfm"
},
{
"name": "EEF CNA record for CVE-2026-82759",
"tags": [
"related"
],
"url": "https://cna.erlef.org/cves/CVE-2026-82759.html"
},
{
"name": "OSV record EEF-CVE-2026-82759",
"tags": [
"related"
],
"url": "https://osv.dev/vulnerability/EEF-CVE-2026-82759"
},
{
"name": "Introducing commit 255cfc9 in team-alembic/ash_authentication",
"tags": [
"related"
],
"url": "https://github.com/team-alembic/ash_authentication/commit/255cfc9c0e511b7e0de39f8b3d676ae994fae06c"
},
{
"name": "Fix commit d8a9c4b in team-alembic/ash_authentication",
"tags": [
"patch"
],
"url": "https://github.com/team-alembic/ash_authentication/commit/d8a9c4b6bde828fdc8346198d5e4f588b5937541"
},
{
"name": "Fix commit c3a6d5f in team-alembic/ash_authentication",
"tags": [
"patch"
],
"url": "https://github.com/team-alembic/ash_authentication/commit/c3a6d5fe0d4fd383ea81b0402db0a96638479478"
}
],
"source": {
"discovery": "INTERNAL"
},
"title": "Reversible IP address pseudonymisation in AshAuthentication audit log hash mode"
}
},
"cveMetadata": {
"assignerOrgId": "6b3ad84c-e1a6-4bf7-a703-f496b71e49db",
"assignerShortName": "EEF",
"cveId": "CVE-2026-82759",
"datePublished": "2026-09-17T13:08:21.929Z",
"dateReserved": "2026-08-31T01:00:10.817Z",
"dateUpdated": "2026-09-17T18:19:18.209Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
CVE-2026-82723 (GCVE-0-2026-82723)
Vulnerability from cvelistv5 – Published: 2026-09-17 13:08 – Updated: 2026-09-24 20:47
VLAI
EPSS
VEX
Title
Actor record with password digest stored in AshAuthentication audit log entries
Summary
Insertion of Sensitive Information into Log File vulnerability in team-alembic AshAuthentication allows disclosure of user password digests to readers of the audit store.
The audit_log add-on builds each entry's extra_data in AshAuthentication.AddOn.AuditLog.Auditor.build_extra_data/4, which takes :actor from the action callback context verbatim. Any audited action invoked with actor: set to a user record therefore deposits that record, including its hashed_password attribute, into the audit entry. The same module already collapses the audited identity to an opaque string via AshAuthentication.user_to_subject/1 and filters params against the strategy's configured allow-list, so the actor is the only stored value that reaches the audit store unfiltered. Marking the attribute sensitive?: true does not help, because that redacts inspect/1 output rather than JSON encoding or raw-term storage.
There is no attacker-controlled trigger and no network disclosure path: entries accumulate from ordinary authenticated activity, and an attacker's own requests deposit only their own digest. Exploitation requires independent read access to the audit store, such as database credentials, an audit role, a backup, or a log shipper, at which point the digests support offline password attack against every active account. Whether the material persists depends on the data layer, since raw-term stores keep it verbatim while a SQL store raises Protocol.UndefinedError and drops the entry unless the user resource derives Jason.Encoder.
This issue affects ash_authentication: from 4.12.0 before 4.15.0 and from 5.0.0-rc.0 before 5.0.0-rc.2.
Severity
SSVC
Exploitation: none
Automatable: no
Technical Impact: partial
CISA Coordinator · CISA-ADP (v2.0.3)
Decision recorded 2026-09-17 18:18 UTC
CWE
- CWE-532 - Insertion of Sensitive Information into Log File
Assigner
References
6 references
Impacted products
2 products
| Vendor | Product | Version | |
|---|---|---|---|
| team-alembic | ash_authentication |
Affected:
4.12.0 , < 4.15.0
(semver)
Affected: 5.0.0-rc.0 , < 5.0.0-rc.2 (semver) cpe:2.3:a:team-alembic:ash_authentication:*:*:*:*:*:*:*:* |
|
| team-alembic | ash_authentication |
Affected:
255cfc9c0e511b7e0de39f8b3d676ae994fae06c , < *
(git)
cpe:2.3:a:team-alembic:ash_authentication:*:*:*:*:*:*:*:* |
Date Public
2026-09-17 13:08
{
"containers": {
"adp": [
{
"metrics": [
{
"other": {
"content": {
"id": "CVE-2026-82723",
"options": [
{
"Exploitation": "none"
},
{
"Automatable": "no"
},
{
"Technical Impact": "partial"
}
],
"role": "CISA Coordinator",
"timestamp": "2026-09-17T18:18:14.370339Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"providerMetadata": {
"dateUpdated": "2026-09-17T18:18:28.208Z",
"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:team-alembic:ash_authentication:*:*:*:*:*:*:*:*"
],
"defaultStatus": "unaffected",
"modules": [
"\u0027Elixir.AshAuthentication.AddOn.AuditLog.Auditor\u0027"
],
"packageName": "ash_authentication",
"packageURL": "pkg:hex/ash_authentication",
"product": "ash_authentication",
"programFiles": [
"lib/ash_authentication/add_ons/audit_log/auditor.ex"
],
"programRoutines": [
{
"name": "\u0027Elixir.AshAuthentication.AddOn.AuditLog.Auditor\u0027:build_extra_data/4"
}
],
"repo": "https://github.com/team-alembic/ash_authentication",
"vendor": "team-alembic",
"versions": [
{
"lessThan": "4.15.0",
"status": "affected",
"version": "4.12.0",
"versionType": "semver"
},
{
"lessThan": "5.0.0-rc.2",
"status": "affected",
"version": "5.0.0-rc.0",
"versionType": "semver"
}
]
},
{
"collectionURL": "https://github.com",
"cpes": [
"cpe:2.3:a:team-alembic:ash_authentication:*:*:*:*:*:*:*:*"
],
"defaultStatus": "unaffected",
"modules": [
"\u0027Elixir.AshAuthentication.AddOn.AuditLog.Auditor\u0027"
],
"packageName": "team-alembic/ash_authentication",
"packageURL": "pkg:github/team-alembic/ash_authentication",
"product": "ash_authentication",
"programFiles": [
"lib/ash_authentication/add_ons/audit_log/auditor.ex"
],
"programRoutines": [
{
"name": "\u0027Elixir.AshAuthentication.AddOn.AuditLog.Auditor\u0027:build_extra_data/4"
}
],
"repo": "https://github.com/team-alembic/ash_authentication",
"vendor": "team-alembic",
"versions": [
{
"changes": [
{
"at": "17ea0dff3bad56a7e915e050c43ab7160b37901f",
"status": "unaffected"
},
{
"at": "f6b49cc98b9ff7c16a1aeb12e35633a8d93a211f",
"status": "unaffected"
}
],
"lessThan": "*",
"status": "affected",
"version": "255cfc9c0e511b7e0de39f8b3d676ae994fae06c",
"versionType": "git"
}
]
}
],
"cpeApplicability": [
{
"nodes": [
{
"cpeMatch": [
{
"criteria": "cpe:2.3:a:team-alembic:ash_authentication:*:*:*:*:*:*:*:*",
"versionEndExcluding": "4.15.0",
"versionStartIncluding": "4.12.0",
"vulnerable": true
},
{
"criteria": "cpe:2.3:a:team-alembic:ash_authentication:*:*:*:*:*:*:*:*",
"versionEndExcluding": "5.0.0-rc.2",
"versionStartIncluding": "5.0.0-rc.0",
"vulnerable": true
}
],
"negate": false,
"operator": "OR"
}
],
"operator": "AND"
}
],
"credits": [
{
"lang": "en",
"type": "remediation developer",
"value": "James Harton"
},
{
"lang": "en",
"type": "reporter",
"value": "Peter Ullrich"
},
{
"lang": "en",
"type": "coordinator",
"value": "Jonatan M\u00e4nnchen / EEF"
}
],
"datePublic": "2026-09-17T13:08:05.000Z",
"descriptions": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003eInsertion of Sensitive Information into Log File vulnerability in team-alembic AshAuthentication allows disclosure of user password digests to readers of the audit store.\u003c/p\u003e\n\u003cp\u003eThe \u003ccode\u003eaudit_log\u003c/code\u003e add-on builds each entry\u0027s \u003ccode\u003eextra_data\u003c/code\u003e in \u003ccode\u003eAshAuthentication.AddOn.AuditLog.Auditor.build_extra_data/4\u003c/code\u003e, which takes \u003ccode\u003e:actor\u003c/code\u003e from the action callback context verbatim. Any audited action invoked with \u003ccode\u003eactor:\u003c/code\u003e set to a user record therefore deposits that record, including its \u003ccode\u003ehashed_password\u003c/code\u003e attribute, into the audit entry. The same module already collapses the audited identity to an opaque string via \u003ccode\u003eAshAuthentication.user_to_subject/1\u003c/code\u003e and filters \u003ccode\u003eparams\u003c/code\u003e against the strategy\u0027s configured allow-list, so the actor is the only stored value that reaches the audit store unfiltered. Marking the attribute \u003ccode\u003esensitive?: true\u003c/code\u003e does not help, because that redacts \u003ccode\u003einspect/1\u003c/code\u003e output rather than JSON encoding or raw-term storage.\u003c/p\u003e\n\u003cp\u003eThere is no attacker-controlled trigger and no network disclosure path: entries accumulate from ordinary authenticated activity, and an attacker\u0027s own requests deposit only their own digest. Exploitation requires independent read access to the audit store, such as database credentials, an audit role, a backup, or a log shipper, at which point the digests support offline password attack against every active account. Whether the material persists depends on the data layer, since raw-term stores keep it verbatim while a SQL store raises \u003ccode\u003eProtocol.UndefinedError\u003c/code\u003e and drops the entry unless the user resource derives \u003ccode\u003eJason.Encoder\u003c/code\u003e.\u003c/p\u003e\n\u003cp\u003eThis issue affects ash_authentication: from 4.12.0 before 4.15.0 and from 5.0.0-rc.0 before 5.0.0-rc.2.\u003c/p\u003e"
},
{
"base64": false,
"type": "text/markdown",
"value": "Insertion of Sensitive Information into Log File vulnerability in team-alembic AshAuthentication allows disclosure of user password digests to readers of the audit store.\n\nThe `audit_log` add-on builds each entry\u0027s `extra_data` in `AshAuthentication.AddOn.AuditLog.Auditor.build_extra_data/4`, which takes `:actor` from the action callback context verbatim. Any audited action invoked with `actor:` set to a user record therefore deposits that record, including its `hashed_password` attribute, into the audit entry. The same module already collapses the audited identity to an opaque string via `AshAuthentication.user_to_subject/1` and filters `params` against the strategy\u0027s configured allow-list, so the actor is the only stored value that reaches the audit store unfiltered. Marking the attribute `sensitive?: true` does not help, because that redacts `inspect/1` output rather than JSON encoding or raw-term storage.\n\nThere is no attacker-controlled trigger and no network disclosure path: entries accumulate from ordinary authenticated activity, and an attacker\u0027s own requests deposit only their own digest. Exploitation requires independent read access to the audit store, such as database credentials, an audit role, a backup, or a log shipper, at which point the digests support offline password attack against every active account. Whether the material persists depends on the data layer, since raw-term stores keep it verbatim while a SQL store raises `Protocol.UndefinedError` and drops the entry unless the user resource derives `Jason.Encoder`.\n\nThis issue affects ash_authentication: from 4.12.0 before 4.15.0 and from 5.0.0-rc.0 before 5.0.0-rc.2."
}
],
"value": "Insertion of Sensitive Information into Log File vulnerability in team-alembic AshAuthentication allows disclosure of user password digests to readers of the audit store.\n\nThe audit_log add-on builds each entry\u0027s extra_data in AshAuthentication.AddOn.AuditLog.Auditor.build_extra_data/4, which takes :actor from the action callback context verbatim. Any audited action invoked with actor: set to a user record therefore deposits that record, including its hashed_password attribute, into the audit entry. The same module already collapses the audited identity to an opaque string via AshAuthentication.user_to_subject/1 and filters params against the strategy\u0027s configured allow-list, so the actor is the only stored value that reaches the audit store unfiltered. Marking the attribute sensitive?: true does not help, because that redacts inspect/1 output rather than JSON encoding or raw-term storage.\n\nThere is no attacker-controlled trigger and no network disclosure path: entries accumulate from ordinary authenticated activity, and an attacker\u0027s own requests deposit only their own digest. Exploitation requires independent read access to the audit store, such as database credentials, an audit role, a backup, or a log shipper, at which point the digests support offline password attack against every active account. Whether the material persists depends on the data layer, since raw-term stores keep it verbatim while a SQL store raises Protocol.UndefinedError and drops the entry unless the user resource derives Jason.Encoder.\n\nThis issue affects ash_authentication: from 4.12.0 before 4.15.0 and from 5.0.0-rc.0 before 5.0.0-rc.2."
}
],
"impacts": [
{
"capecId": "CAPEC-49",
"descriptions": [
{
"lang": "en",
"value": "CAPEC-49 Password Brute Forcing"
}
]
}
],
"metrics": [
{
"cvssV4_0": {
"Automatable": "NOT_DEFINED",
"Recovery": "NOT_DEFINED",
"Safety": "NOT_DEFINED",
"attackComplexity": "HIGH",
"attackRequirements": "PRESENT",
"attackVector": "LOCAL",
"baseScore": 1.8,
"baseSeverity": "LOW",
"privilegesRequired": "HIGH",
"providerUrgency": "NOT_DEFINED",
"subAvailabilityImpact": "NONE",
"subConfidentialityImpact": "NONE",
"subIntegrityImpact": "NONE",
"userInteraction": "NONE",
"valueDensity": "NOT_DEFINED",
"vectorString": "CVSS:4.0/AV:L/AC:H/AT:P/PR:H/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-532",
"description": "CWE-532 Insertion of Sensitive Information into Log File",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-09-24T20:47:32.536Z",
"orgId": "6b3ad84c-e1a6-4bf7-a703-f496b71e49db",
"shortName": "EEF"
},
"references": [
{
"tags": [
"related",
"vendor-advisory"
],
"url": "https://github.com/team-alembic/ash_authentication/security/advisories/GHSA-59wx-q3r8-ghv4"
},
{
"name": "EEF CNA record for CVE-2026-82723",
"tags": [
"related"
],
"url": "https://cna.erlef.org/cves/CVE-2026-82723.html"
},
{
"name": "OSV record EEF-CVE-2026-82723",
"tags": [
"related"
],
"url": "https://osv.dev/vulnerability/EEF-CVE-2026-82723"
},
{
"name": "Introducing commit 255cfc9 in team-alembic/ash_authentication",
"tags": [
"related"
],
"url": "https://github.com/team-alembic/ash_authentication/commit/255cfc9c0e511b7e0de39f8b3d676ae994fae06c"
},
{
"name": "Fix commit 17ea0df in team-alembic/ash_authentication",
"tags": [
"patch"
],
"url": "https://github.com/team-alembic/ash_authentication/commit/17ea0dff3bad56a7e915e050c43ab7160b37901f"
},
{
"name": "Fix commit f6b49cc in team-alembic/ash_authentication",
"tags": [
"patch"
],
"url": "https://github.com/team-alembic/ash_authentication/commit/f6b49cc98b9ff7c16a1aeb12e35633a8d93a211f"
}
],
"source": {
"discovery": "EXTERNAL"
},
"title": "Actor record with password digest stored in AshAuthentication audit log entries"
}
},
"cveMetadata": {
"assignerOrgId": "6b3ad84c-e1a6-4bf7-a703-f496b71e49db",
"assignerShortName": "EEF",
"cveId": "CVE-2026-82723",
"datePublished": "2026-09-17T13:08:05.355Z",
"dateReserved": "2026-08-31T00:59:08.960Z",
"dateUpdated": "2026-09-24T20:47:32.536Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
CVE-2026-86338 (GCVE-0-2026-86338)
Vulnerability from cvelistv5 – Published: 2026-09-16 08:28 – Updated: 2026-09-16 14:49
VLAI
EPSS
VEX
Title
Ash field policies do not filter-nil forbidden calculations and aggregates, enabling an information-disclosure oracle
Summary
Ash field_policies are documented to protect against filter-based information disclosure: when a field the actor may not see is referenced in a filter, it is replaced with an expression that evaluates to nil, so a filter cannot be used as a yes/no oracle to read a value the actor cannot see.
This nilling was applied to attributes but not to calculations or aggregates. A user-supplied filter reference to a calculation or aggregate carries an Ash.Query.Calculation / Ash.Query.Aggregate struct, which the authorizer's reference replacement did not match (it only matched the Ash.Resource.* structs), so the filter ran against the real value.
As a result, an actor whose field policies forbid a calculation or aggregate can still filter by it (for example filter(secret_calc == "x") or filter(comment_count == n)) and learn the value from whether rows match — an oracle that recovers field-policy-protected values one probe at a time. Filtering is commonly exposed to lower-privileged actors (for example via AshGraphql or AshJsonApi filter arguments), which is exactly the surface field policies are meant to protect.
The fix routes filter references to calculations and aggregates through the same field-policy nilling as attributes.
This issue affects ash: from 2.11.0-rc.0 before 3.33.4.
Severity
SSVC
Exploitation: none
Automatable: no
Technical Impact: partial
CISA Coordinator · CISA-ADP (v2.0.3)
Decision recorded 2026-09-16 14:49 UTC
CWE
- CWE-1220 - Insufficient Granularity of Access Control
Assigner
References
5 references
Impacted products
2 products
| Vendor | Product | Version | |
|---|---|---|---|
| ash-project | ash |
Affected:
2.11.0-rc.0 , < 3.33.4
(semver)
cpe:2.3:a:ash-project:ash:*:*:*:*:*:*:*:* |
|
| ash-project | ash |
Affected:
0b6d93c7c4637280b46ae66ea1d2eaf013701238 , < b3d4503241f3deacb5ceb955e10a4fa927da0f67
(git)
cpe:2.3:a:ash-project:ash:*:*:*:*:*:*:*:* |
{
"containers": {
"adp": [
{
"metrics": [
{
"other": {
"content": {
"id": "CVE-2026-86338",
"options": [
{
"Exploitation": "none"
},
{
"Automatable": "no"
},
{
"Technical Impact": "partial"
}
],
"role": "CISA Coordinator",
"timestamp": "2026-09-16T14:49:09.195379Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"providerMetadata": {
"dateUpdated": "2026-09-16T14:49:17.203Z",
"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.Policy.Authorizer\u0027"
],
"packageName": "ash",
"packageURL": "pkg:hex/ash",
"product": "ash",
"programFiles": [
"lib/ash/policy/authorizer/authorizer.ex"
],
"programRoutines": [
{
"name": "\u0027Elixir.Ash.Policy.Authorizer\u0027:do_replace_ref/2"
}
],
"repo": "https://github.com/ash-project/ash",
"vendor": "ash-project",
"versions": [
{
"lessThan": "3.33.4",
"status": "affected",
"version": "2.11.0-rc.0",
"versionType": "semver"
}
]
},
{
"collectionURL": "https://github.com",
"cpes": [
"cpe:2.3:a:ash-project:ash:*:*:*:*:*:*:*:*"
],
"defaultStatus": "unaffected",
"modules": [
"\u0027Elixir.Ash.Policy.Authorizer\u0027"
],
"packageName": "ash-project/ash",
"packageURL": "pkg:github/ash-project/ash",
"product": "ash",
"programFiles": [
"lib/ash/policy/authorizer/authorizer.ex"
],
"programRoutines": [
{
"name": "\u0027Elixir.Ash.Policy.Authorizer\u0027:do_replace_ref/2"
}
],
"repo": "https://github.com/ash-project/ash",
"vendor": "ash-project",
"versions": [
{
"lessThan": "b3d4503241f3deacb5ceb955e10a4fa927da0f67",
"status": "affected",
"version": "0b6d93c7c4637280b46ae66ea1d2eaf013701238",
"versionType": "git"
}
]
}
],
"configurations": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003eReachable only when an application uses \u003ccode\u003eAsh.Policy.Authorizer\u003c/code\u003e field policies to restrict a calculation or aggregate, and exposes filtering on it to an actor who is denied that field (for example an authenticated user filtering through AshGraphql or AshJsonApi).\u003c/p\u003e"
},
{
"base64": false,
"type": "text/markdown",
"value": "Reachable only when an application uses `Ash.Policy.Authorizer` field policies to restrict a calculation or aggregate, and exposes filtering on it to an actor who is denied that field (for example an authenticated user filtering through AshGraphql or AshJsonApi)."
}
],
"value": "Reachable only when an application uses Ash.Policy.Authorizer field policies to restrict a calculation or aggregate, and exposes filtering on it to an actor who is denied that field (for example an authenticated user filtering through AshGraphql or AshJsonApi)."
}
],
"cpeApplicability": [
{
"nodes": [
{
"cpeMatch": [
{
"criteria": "cpe:2.3:a:ash-project:ash:*:*:*:*:*:*:*:*",
"versionEndExcluding": "3.33.4",
"versionStartIncluding": "2.11.0-rc.0",
"vulnerable": true
}
],
"negate": false,
"operator": "OR"
}
],
"operator": "AND"
}
],
"credits": [
{
"lang": "en",
"type": "reporter",
"value": "Jesse Williams"
},
{
"lang": "en",
"type": "remediation developer",
"value": "Zach Daniel / Ash Project"
},
{
"lang": "en",
"type": "coordinator",
"value": "Jonatan M\u00e4nnchen / EEF"
},
{
"lang": "en",
"type": "finder",
"value": "Jesse Williams"
}
],
"dateAssigned": "2026-09-15T23:33:34.000Z",
"descriptions": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003eAsh \u003ccode\u003efield_policies\u003c/code\u003e are documented to protect against filter-based information disclosure: when a field the actor may not see is referenced in a filter, it is replaced with an expression that evaluates to \u003ccode\u003enil\u003c/code\u003e, so a filter cannot be used as a yes/no oracle to read a value the actor cannot see.\u003c/p\u003e\n\u003cp\u003eThis nilling was applied to attributes but not to calculations or aggregates. A user-supplied filter reference to a calculation or aggregate carries an \u003ccode\u003eAsh.Query.Calculation\u003c/code\u003e / \u003ccode\u003eAsh.Query.Aggregate\u003c/code\u003e struct, which the authorizer\u0027s reference replacement did not match (it only matched the \u003ccode\u003eAsh.Resource.*\u003c/code\u003e structs), so the filter ran against the real value.\u003c/p\u003e\n\u003cp\u003eAs a result, an actor whose field policies forbid a calculation or aggregate can still filter by it (for example \u003ccode\u003efilter(secret_calc == \"x\")\u003c/code\u003e or \u003ccode\u003efilter(comment_count == n)\u003c/code\u003e) and learn the value from whether rows match \u2014 an oracle that recovers field-policy-protected values one probe at a time. Filtering is commonly exposed to lower-privileged actors (for example via AshGraphql or AshJsonApi filter arguments), which is exactly the surface field policies are meant to protect.\u003c/p\u003e\n\u003cp\u003eThe fix routes filter references to calculations and aggregates through the same field-policy nilling as attributes.\u003c/p\u003e\n\u003cp\u003eThis issue affects ash: from 2.11.0-rc.0 before 3.33.4.\u003c/p\u003e"
},
{
"base64": false,
"type": "text/markdown",
"value": "Ash `field_policies` are documented to protect against filter-based information disclosure: when a field the actor may not see is referenced in a filter, it is replaced with an expression that evaluates to `nil`, so a filter cannot be used as a yes/no oracle to read a value the actor cannot see.\n\nThis nilling was applied to attributes but not to calculations or aggregates. A user-supplied filter reference to a calculation or aggregate carries an `Ash.Query.Calculation` / `Ash.Query.Aggregate` struct, which the authorizer\u0027s reference replacement did not match (it only matched the `Ash.Resource.*` structs), so the filter ran against the real value.\n\nAs a result, an actor whose field policies forbid a calculation or aggregate can still filter by it (for example `filter(secret_calc == \"x\")` or `filter(comment_count == n)`) and learn the value from whether rows match \u2014 an oracle that recovers field-policy-protected values one probe at a time. Filtering is commonly exposed to lower-privileged actors (for example via AshGraphql or AshJsonApi filter arguments), which is exactly the surface field policies are meant to protect.\n\nThe fix routes filter references to calculations and aggregates through the same field-policy nilling as attributes.\n\nThis issue affects ash: from 2.11.0-rc.0 before 3.33.4."
}
],
"value": "Ash field_policies are documented to protect against filter-based information disclosure: when a field the actor may not see is referenced in a filter, it is replaced with an expression that evaluates to nil, so a filter cannot be used as a yes/no oracle to read a value the actor cannot see.\n\nThis nilling was applied to attributes but not to calculations or aggregates. A user-supplied filter reference to a calculation or aggregate carries an Ash.Query.Calculation / Ash.Query.Aggregate struct, which the authorizer\u0027s reference replacement did not match (it only matched the Ash.Resource.* structs), so the filter ran against the real value.\n\nAs a result, an actor whose field policies forbid a calculation or aggregate can still filter by it (for example filter(secret_calc == \"x\") or filter(comment_count == n)) and learn the value from whether rows match \u2014 an oracle that recovers field-policy-protected values one probe at a time. Filtering is commonly exposed to lower-privileged actors (for example via AshGraphql or AshJsonApi filter arguments), which is exactly the surface field policies are meant to protect.\n\nThe fix routes filter references to calculations and aggregates through the same field-policy nilling as attributes.\n\nThis issue affects ash: from 2.11.0-rc.0 before 3.33.4."
}
],
"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-1220",
"description": "CWE-1220 Insufficient Granularity of Access Control",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-09-16T08:28:44.114Z",
"orgId": "6b3ad84c-e1a6-4bf7-a703-f496b71e49db",
"shortName": "EEF"
},
"references": [
{
"name": "GHSA-7qr8-wrvq-566q",
"tags": [
"vendor-advisory"
],
"url": "https://github.com/ash-project/ash/security/advisories/GHSA-7qr8-wrvq-566q"
},
{
"name": "EEF CNA record for CVE-2026-86338",
"tags": [
"related"
],
"url": "https://cna.erlef.org/cves/CVE-2026-86338.html"
},
{
"name": "OSV record EEF-CVE-2026-86338",
"tags": [
"related"
],
"url": "https://osv.dev/vulnerability/EEF-CVE-2026-86338"
},
{
"name": "Introducing commit 0b6d93c in ash-project/ash",
"tags": [
"related"
],
"url": "https://github.com/ash-project/ash/commit/0b6d93c7c4637280b46ae66ea1d2eaf013701238"
},
{
"name": "Fix commit b3d4503 in ash-project/ash",
"tags": [
"patch"
],
"url": "https://github.com/ash-project/ash/commit/b3d4503241f3deacb5ceb955e10a4fa927da0f67"
}
],
"source": {
"discovery": "EXTERNAL"
},
"title": "Ash field policies do not filter-nil forbidden calculations and aggregates, enabling an information-disclosure oracle"
}
},
"cveMetadata": {
"assignerOrgId": "6b3ad84c-e1a6-4bf7-a703-f496b71e49db",
"assignerShortName": "EEF",
"cveId": "CVE-2026-86338",
"datePublished": "2026-09-16T08:28:44.114Z",
"dateReserved": "2026-09-15T15:30:01.895Z",
"dateUpdated": "2026-09-16T14:49:17.203Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}