{"answers":{"affected":"1 open source package ship an affected version, including ash_authentication.","exploited":"There is no known exploitation of CVE-2026-80218 in the wild and no public exploit code.","fix":"Upgrade ash_authentication to a fixed version for your release line: 4.15.0 or 5.0.0-rc.14.","what":"CVE-2026-80218 is a high-severity authentication bypass vulnerability in team-alembic ash_authentication, published on 17 Sep 2026. Any signed-in user can exploit it over the network, with no action from the victim."},"fix_prompt":"Check this codebase for CVE-2026-80218 and fix it if it is affected.\n\nWhat it is: CVE-2026-80218 is a high-severity authentication bypass vulnerability in team-alembic ash_authentication, published on 17 Sep 2026. Any signed-in user can exploit it over the network, with no action from the victim.\nExploitation: There is no known exploitation of CVE-2026-80218 in the wild and no public exploit code.\n\nAffected packages and fixed versions:\n- ash_authentication (Hex): affected from 3.10.5; fixed in 4.15.0, 5.0.0-rc.14\n\nTask:\n1. Search the dependency manifests and lockfiles (for example package.json, package-lock.json, requirements.txt, poetry.lock, uv.lock, pom.xml, build.gradle, go.mod, Cargo.lock, Gemfile.lock) and any Dockerfiles for the affected packages, including transitive dependencies.\n2. If an affected version is in use, upgrade it to the fixed version for its release line with the project's package manager, so the lockfile is regenerated. Prefer the smallest upgrade that fixes it.\n3. If there is no fix, or the upgrade would break the build, do not guess: explain the risk and the safest workaround instead.\n4. Run the tests and summarise what changed and why.\n5. If nothing in the project is affected, say so and change nothing.\n\nReference: https://insights.sbomify.com/CVE-2026-80218/ (Markdown: https://insights.sbomify.com/CVE-2026-80218/index.md)","id":"CVE-2026-80218","markdown":"https://insights.sbomify.com/CVE-2026-80218/index.md","name":"CVE-2026-80218","record":{"aliases":["EEF-CVE-2026-80218","GHSA-3pr8-f99q-86hp"],"analysis":{"component_type":"library","fix_type":"upgrade","impacts":["account_takeover"],"network_reachable":"yes","non_default_config":false,"product_category":"Elixir authentication library","requires_auth":"low_privilege","summary":"Attackers can use a sign-in token from one resource to authenticate as a user on a different resource due to improper JWT subject validation.","user_interaction":"not_required","vuln_class":"auth_bypass"},"analysis_generated_by":"qwen3.8-flash-next","assigner":"EEF","cpe":[],"cvss":{"score":7.6,"severity":"high","source":"cna","vector":"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"},"cwes":[{"id":"CWE-287","name":"Improper Authentication"}],"description":"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.","ecosystems":["Hex"],"exploits":{"exploitdb":0,"first_seen":null,"github_poc":0,"max_poc_stars":null,"metasploit":0,"nuclei":0,"refs":[],"tier":"none_known"},"has_fix":true,"headline":"Sign-in token minted for one resource accepted by another in AshAuthentication","id":"CVE-2026-80218","indexable":true,"kev":null,"kind":"cve","links":{"ecosystem":"Hex","product":null,"products":[],"type":"auth_bypass","year":"2026"},"n_packages":1,"n_references":6,"next":{"headline":"Red Hat Product Security has come to the conclusion that this CVE is not needed.","id":"CVE-2026-80219"},"packages":[{"ecosystem":"Hex","fixed":["4.15.0","5.0.0-rc.14"],"introduced":["3.10.5","5.0.0-rc.0"],"last_affected":[],"package":"ash_authentication","purl":"pkg:hex/ash_authentication","source":"EEF-CVE-2026-80218"}],"prev":{"headline":"Command injection in FF-RFI078I4","id":"CVE-2026-80217"},"products":["ash_authentication"],"published":"2026-09-17","related":[],"sources":[{"class":"attribution","licence":"CVE Terms of Use (MITRE)","name":"CVE List","prefix":"CVE"},{"class":"attribution","licence":"CC BY 4.0","name":"Erlang Ecosystem Foundation","prefix":"EEF"},{"class":"attribution","licence":"CWE Terms of Use","name":"CWE (MITRE)"},{"class":"attribution","licence":"FIRST CVSS licence","name":"CVSS (FIRST)"}],"ssvc":{"automatable":"no","exploitation":"none","technical_impact":"total"},"state":"PUBLISHED","updated":"2026-09-17","vendors":["team-alembic"]},"summary":"Attackers can use a sign-in token from one resource to authenticate as a user on a different resource due to improper JWT subject validation.","url":"https://insights.sbomify.com/CVE-2026-80218/"}