CVE-2026-66882 (GCVE-0-2026-66882)
Vulnerability from cvelistv5
Published
2026-08-25 08:03
Modified
2026-08-25 19:51
Severity ?
VLAI Severity ?
EPSS score ?
CWE
- CWE-79 - Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')
Summary
Improper Neutralization of Input During Web Page Generation (XSS) vulnerability in team-alembic AshAuthentication allows reflected cross-site scripting via the confirmation and magic link interaction forms.
When a strategy is configured with require_interaction? set to true, AshAuthentication serves an intermediate HTML page asking the user to confirm the action by submitting a form. Both such pages embed a request parameter directly into a hidden input's value attribute without HTML escaping: lib/ash_authentication/add_ons/confirmation/confirmation_form.html.eex interpolates the confirm parameter, and lib/ash_authentication/strategies/magic_link/sign_in_form.html.eex interpolates the magic link token parameter. These templates are compiled with EEx.function_from_file/3 using plain <%= %> expressions, which perform no escaping, so the parameter is reflected verbatim.
Neither accept handler validates the value before rendering it. AshAuthentication.AddOn.Confirmation.Plug.accept/2 only checks that a confirm key is present, and AshAuthentication.Strategy.MagicLink.Plug.accept/2 reads the parameter directly, so no token signature is verified at this stage and arbitrary attacker-supplied text reaches the template. An unauthenticated attacker can therefore craft a URL whose parameter terminates the attribute and injects markup, for example a quote followed by a <script> element. Because the accept phase is served over GET, loading the crafted link is sufficient; no form submission or prior authentication is required.
The injected script executes in the origin of the application embedding AshAuthentication, giving it access to that origin's cookies, session, and same-origin responses. Since these pages are part of the authentication flow, a victim following what appears to be a legitimate confirmation or sign-in link is a plausible target.
This issue affects ash_authentication: from 4.8.0 before 4.14.2 and from 5.0.0-rc.0 before 5.0.0-rc.13.
References
Impacted products
| Vendor | Product | Version | |||||||
|---|---|---|---|---|---|---|---|---|---|
| team-alembic | ash_authentication |
Version: 4.8.0 ≤ Version: 5.0.0-rc.0 ≤ cpe:2.3:a:team-alembic:ash_authentication:*:*:*:*:*:*:*:* |
|||||||
|
|||||||||
{
"containers": {
"adp": [
{
"metrics": [
{
"other": {
"content": {
"id": "CVE-2026-66882",
"options": [
{
"Exploitation": "poc"
},
{
"Automatable": "no"
},
{
"Technical Impact": "partial"
}
],
"role": "CISA Coordinator",
"timestamp": "2026-08-25T19:50:10.506279Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"providerMetadata": {
"dateUpdated": "2026-08-25T19:51:21.332Z",
"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"shortName": "CISA-ADP"
},
"references": [
{
"tags": [
"exploit"
],
"url": "https://github.com/team-alembic/ash_authentication/security/advisories/GHSA-54fc-x3hv-ffhw"
}
],
"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.Plug\u0027",
"\u0027Elixir.AshAuthentication.AddOn.Confirmation.Plug\u0027"
],
"packageName": "ash_authentication",
"packageURL": "pkg:hex/ash_authentication",
"product": "ash_authentication",
"programFiles": [
"lib/ash_authentication/strategies/magic_link/sign_in_form.html.eex",
"lib/ash_authentication/strategies/magic_link/plug.ex",
"lib/ash_authentication/add_ons/confirmation/confirmation_form.html.eex",
"lib/ash_authentication/add_ons/confirmation/plug.ex"
],
"programRoutines": [
{
"name": "\u0027Elixir.AshAuthentication.Strategy.MagicLink.Plug\u0027:accept/2"
},
{
"name": "\u0027Elixir.AshAuthentication.AddOn.Confirmation.Plug\u0027:accept/2"
}
],
"repo": "https://github.com/team-alembic/ash_authentication",
"vendor": "team-alembic",
"versions": [
{
"lessThan": "4.14.2",
"status": "affected",
"version": "4.8.0",
"versionType": "semver"
},
{
"lessThan": "5.0.0-rc.13",
"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.Plug\u0027",
"\u0027Elixir.AshAuthentication.AddOn.Confirmation.Plug\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_form.html.eex",
"lib/ash_authentication/strategies/magic_link/plug.ex",
"lib/ash_authentication/add_ons/confirmation/confirmation_form.html.eex",
"lib/ash_authentication/add_ons/confirmation/plug.ex"
],
"programRoutines": [
{
"name": "\u0027Elixir.AshAuthentication.Strategy.MagicLink.Plug\u0027:accept/2"
},
{
"name": "\u0027Elixir.AshAuthentication.AddOn.Confirmation.Plug\u0027:accept/2"
}
],
"repo": "https://github.com/team-alembic/ash_authentication",
"vendor": "team-alembic",
"versions": [
{
"changes": [
{
"at": "62719710790a150a9eacab9c0a066e0d122d15be",
"status": "unaffected"
},
{
"at": "0bd5199db066be22b2ca1ec8bc6109e5d62e6070",
"status": "unaffected"
}
],
"lessThan": "*",
"status": "affected",
"version": "fe0b4558dbe852fee5d81a460a8355577618a8c8",
"versionType": "git"
}
]
}
],
"configurations": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003eOnly strategies configured with \u003ccode\u003erequire_interaction?\u003c/code\u003e set to \u003ccode\u003etrue\u003c/code\u003e are affected. This option defaults to \u003ccode\u003efalse\u003c/code\u003e, and when it is disabled the vulnerable accept route is not registered at all, so the affected pages cannot be reached.\u003c/p\u003e\n\u003cp\u003eThe option is not obscure: AshAuthentication\u0027s own documentation for the confirmation add-on advises that applications using AshAuthenticationPhoenix should enable it, so the affected configuration is a documented and recommended deployment rather than an unusual one.\u003c/p\u003e\n\u003cp\u003eAt least one of the following must be configured with \u003ccode\u003erequire_interaction? true\u003c/code\u003e:\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003ethe \u003ccode\u003econfirmation\u003c/code\u003e add-on, which serves the affected confirmation accept form; or\u003c/li\u003e\n\u003cli\u003ethe \u003ccode\u003emagic_link\u003c/code\u003e strategy, which serves the affected sign-in accept form.\u003c/li\u003e\n\u003c/ul\u003e"
},
{
"base64": false,
"type": "text/markdown",
"value": "Only strategies configured with `require_interaction?` set to `true` are affected. This option defaults to `false`, and when it is disabled the vulnerable accept route is not registered at all, so the affected pages cannot be reached.\n\nThe option is not obscure: AshAuthentication\u0027s own documentation for the confirmation add-on advises that applications using AshAuthenticationPhoenix should enable it, so the affected configuration is a documented and recommended deployment rather than an unusual one.\n\nAt least one of the following must be configured with `require_interaction? true`:\n\n- the `confirmation` add-on, which serves the affected confirmation accept form; or\n- the `magic_link` strategy, which serves the affected sign-in accept form."
}
],
"value": "Only strategies configured with require_interaction? set to true are affected. This option defaults to false, and when it is disabled the vulnerable accept route is not registered at all, so the affected pages cannot be reached.\n\nThe option is not obscure: AshAuthentication\u0027s own documentation for the confirmation add-on advises that applications using AshAuthenticationPhoenix should enable it, so the affected configuration is a documented and recommended deployment rather than an unusual one.\n\nAt least one of the following must be configured with require_interaction? true:\n\n* the confirmation add-on, which serves the affected confirmation accept form; or\n* the magic_link strategy, which serves the affected sign-in accept form."
}
],
"cpeApplicability": [
{
"nodes": [
{
"cpeMatch": [
{
"criteria": "cpe:2.3:a:team-alembic:ash_authentication:*:*:*:*:*:*:*:*",
"versionEndExcluding": "4.14.2",
"versionStartIncluding": "4.8.0",
"vulnerable": true
},
{
"criteria": "cpe:2.3:a:team-alembic:ash_authentication:*:*:*:*:*:*:*:*",
"versionEndExcluding": "5.0.0-rc.13",
"versionStartIncluding": "5.0.0-rc.0",
"vulnerable": true
}
],
"negate": false,
"operator": "OR"
}
],
"operator": "AND"
}
],
"credits": [
{
"lang": "en",
"type": "finder",
"value": "Arpit Jain"
},
{
"lang": "en",
"type": "remediation developer",
"value": "James Harton"
},
{
"lang": "en",
"type": "coordinator",
"value": "Jonatan M\u00e4nnchen / EEF"
}
],
"descriptions": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003eImproper Neutralization of Input During Web Page Generation (XSS) vulnerability in team-alembic AshAuthentication allows reflected cross-site scripting via the confirmation and magic link interaction forms.\u003c/p\u003e\n\u003cp\u003eWhen a strategy is configured with \u003ccode\u003erequire_interaction?\u003c/code\u003e set to \u003ccode\u003etrue\u003c/code\u003e, AshAuthentication serves an intermediate HTML page asking the user to confirm the action by submitting a form. Both such pages embed a request parameter directly into a hidden input\u0027s \u003ccode\u003evalue\u003c/code\u003e attribute without HTML escaping: \u003ccode\u003elib/ash_authentication/add_ons/confirmation/confirmation_form.html.eex\u003c/code\u003e interpolates the \u003ccode\u003econfirm\u003c/code\u003e parameter, and \u003ccode\u003elib/ash_authentication/strategies/magic_link/sign_in_form.html.eex\u003c/code\u003e interpolates the magic link token parameter. These templates are compiled with \u003ccode\u003eEEx.function_from_file/3\u003c/code\u003e using plain \u003ccode\u003e\u0026lt;%= %\u0026gt;\u003c/code\u003e expressions, which perform no escaping, so the parameter is reflected verbatim.\u003c/p\u003e\n\u003cp\u003eNeither accept handler validates the value before rendering it. \u003ccode\u003eAshAuthentication.AddOn.Confirmation.Plug.accept/2\u003c/code\u003e only checks that a \u003ccode\u003econfirm\u003c/code\u003e key is present, and \u003ccode\u003eAshAuthentication.Strategy.MagicLink.Plug.accept/2\u003c/code\u003e reads the parameter directly, so no token signature is verified at this stage and arbitrary attacker-supplied text reaches the template. An unauthenticated attacker can therefore craft a URL whose parameter terminates the attribute and injects markup, for example a quote followed by a \u003ccode\u003e\u0026lt;script\u0026gt;\u003c/code\u003e element. Because the accept phase is served over GET, loading the crafted link is sufficient; no form submission or prior authentication is required.\u003c/p\u003e\n\u003cp\u003eThe injected script executes in the origin of the application embedding AshAuthentication, giving it access to that origin\u0027s cookies, session, and same-origin responses. Since these pages are part of the authentication flow, a victim following what appears to be a legitimate confirmation or sign-in link is a plausible target.\u003c/p\u003e\n\u003cp\u003eThis issue affects ash_authentication: from 4.8.0 before 4.14.2 and from 5.0.0-rc.0 before 5.0.0-rc.13.\u003c/p\u003e"
},
{
"base64": false,
"type": "text/markdown",
"value": "Improper Neutralization of Input During Web Page Generation (XSS) vulnerability in team-alembic AshAuthentication allows reflected cross-site scripting via the confirmation and magic link interaction forms.\n\nWhen a strategy is configured with `require_interaction?` set to `true`, AshAuthentication serves an intermediate HTML page asking the user to confirm the action by submitting a form. Both such pages embed a request parameter directly into a hidden input\u0027s `value` attribute without HTML escaping: `lib/ash_authentication/add_ons/confirmation/confirmation_form.html.eex` interpolates the `confirm` parameter, and `lib/ash_authentication/strategies/magic_link/sign_in_form.html.eex` interpolates the magic link token parameter. These templates are compiled with `EEx.function_from_file/3` using plain `\u003c%= %\u003e` expressions, which perform no escaping, so the parameter is reflected verbatim.\n\nNeither accept handler validates the value before rendering it. `AshAuthentication.AddOn.Confirmation.Plug.accept/2` only checks that a `confirm` key is present, and `AshAuthentication.Strategy.MagicLink.Plug.accept/2` reads the parameter directly, so no token signature is verified at this stage and arbitrary attacker-supplied text reaches the template. An unauthenticated attacker can therefore craft a URL whose parameter terminates the attribute and injects markup, for example a quote followed by a `\u003cscript\u003e` element. Because the accept phase is served over GET, loading the crafted link is sufficient; no form submission or prior authentication is required.\n\nThe injected script executes in the origin of the application embedding AshAuthentication, giving it access to that origin\u0027s cookies, session, and same-origin responses. Since these pages are part of the authentication flow, a victim following what appears to be a legitimate confirmation or sign-in link is a plausible target.\n\nThis issue affects ash_authentication: from 4.8.0 before 4.14.2 and from 5.0.0-rc.0 before 5.0.0-rc.13."
}
],
"value": "Improper Neutralization of Input During Web Page Generation (XSS) vulnerability in team-alembic AshAuthentication allows reflected cross-site scripting via the confirmation and magic link interaction forms.\n\nWhen a strategy is configured with require_interaction? set to true, AshAuthentication serves an intermediate HTML page asking the user to confirm the action by submitting a form. Both such pages embed a request parameter directly into a hidden input\u0027s value attribute without HTML escaping: lib/ash_authentication/add_ons/confirmation/confirmation_form.html.eex interpolates the confirm parameter, and lib/ash_authentication/strategies/magic_link/sign_in_form.html.eex interpolates the magic link token parameter. These templates are compiled with EEx.function_from_file/3 using plain \u003c%= %\u003e expressions, which perform no escaping, so the parameter is reflected verbatim.\n\nNeither accept handler validates the value before rendering it. AshAuthentication.AddOn.Confirmation.Plug.accept/2 only checks that a confirm key is present, and AshAuthentication.Strategy.MagicLink.Plug.accept/2 reads the parameter directly, so no token signature is verified at this stage and arbitrary attacker-supplied text reaches the template. An unauthenticated attacker can therefore craft a URL whose parameter terminates the attribute and injects markup, for example a quote followed by a \u003cscript\u003e element. Because the accept phase is served over GET, loading the crafted link is sufficient; no form submission or prior authentication is required.\n\nThe injected script executes in the origin of the application embedding AshAuthentication, giving it access to that origin\u0027s cookies, session, and same-origin responses. Since these pages are part of the authentication flow, a victim following what appears to be a legitimate confirmation or sign-in link is a plausible target.\n\nThis issue affects ash_authentication: from 4.8.0 before 4.14.2 and from 5.0.0-rc.0 before 5.0.0-rc.13."
}
],
"impacts": [
{
"capecId": "CAPEC-591",
"descriptions": [
{
"lang": "en",
"value": "CAPEC-591 Reflected XSS"
}
]
}
],
"metrics": [
{
"cvssV4_0": {
"Automatable": "NOT_DEFINED",
"Recovery": "NOT_DEFINED",
"Safety": "NOT_DEFINED",
"attackComplexity": "LOW",
"attackRequirements": "PRESENT",
"attackVector": "NETWORK",
"baseScore": 2.1,
"baseSeverity": "LOW",
"privilegesRequired": "NONE",
"providerUrgency": "NOT_DEFINED",
"subAvailabilityImpact": "NONE",
"subConfidentialityImpact": "LOW",
"subIntegrityImpact": "LOW",
"userInteraction": "ACTIVE",
"valueDensity": "NOT_DEFINED",
"vectorString": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:A/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-08-25T08:03:47.721Z",
"orgId": "6b3ad84c-e1a6-4bf7-a703-f496b71e49db",
"shortName": "EEF"
},
"references": [
{
"tags": [
"vendor-advisory",
"related"
],
"url": "https://github.com/team-alembic/ash_authentication/security/advisories/GHSA-54fc-x3hv-ffhw"
},
{
"tags": [
"related"
],
"url": "https://cna.erlef.org/cves/CVE-2026-66882.html"
},
{
"tags": [
"related"
],
"url": "https://osv.dev/vulnerability/EEF-CVE-2026-66882"
},
{
"tags": [
"patch"
],
"url": "https://github.com/team-alembic/ash_authentication/commit/62719710790a150a9eacab9c0a066e0d122d15be"
},
{
"tags": [
"patch"
],
"url": "https://github.com/team-alembic/ash_authentication/commit/0bd5199db066be22b2ca1ec8bc6109e5d62e6070"
}
],
"source": {
"discovery": "EXTERNAL"
},
"title": "Reflected XSS in AshAuthentication confirmation and magic link interaction forms"
}
},
"cveMetadata": {
"assignerOrgId": "6b3ad84c-e1a6-4bf7-a703-f496b71e49db",
"assignerShortName": "EEF",
"cveId": "CVE-2026-66882",
"datePublished": "2026-08-25T08:03:47.721Z",
"dateReserved": "2026-07-28T04:15:10.240Z",
"dateUpdated": "2026-08-25T19:51:21.332Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2",
"vulnerability-lookup:meta": {
"vulnrichment": {
"containers": "{\"adp\": [{\"title\": \"CISA ADP Vulnrichment\", \"metrics\": [{\"other\": {\"type\": \"ssvc\", \"content\": {\"id\": \"CVE-2026-66882\", \"role\": \"CISA Coordinator\", \"options\": [{\"Exploitation\": \"poc\"}, {\"Automatable\": \"no\"}, {\"Technical Impact\": \"partial\"}], \"version\": \"2.0.3\", \"timestamp\": \"2026-08-25T19:50:10.506279Z\"}}}], \"references\": [{\"url\": \"https://github.com/team-alembic/ash_authentication/security/advisories/GHSA-54fc-x3hv-ffhw\", \"tags\": [\"exploit\"]}], \"providerMetadata\": {\"orgId\": \"134c704f-9b21-4f2e-91b3-4a467353bcc0\", \"shortName\": \"CISA-ADP\", \"dateUpdated\": \"2026-08-25T19:51:13.735Z\"}}], \"cna\": {\"title\": \"Reflected XSS in AshAuthentication confirmation and magic link interaction forms\", \"source\": {\"discovery\": \"EXTERNAL\"}, \"credits\": [{\"lang\": \"en\", \"type\": \"finder\", \"value\": \"Arpit Jain\"}, {\"lang\": \"en\", \"type\": \"remediation developer\", \"value\": \"James Harton\"}, {\"lang\": \"en\", \"type\": \"coordinator\", \"value\": \"Jonatan M\\u00e4nnchen / EEF\"}], \"impacts\": [{\"capecId\": \"CAPEC-591\", \"descriptions\": [{\"lang\": \"en\", \"value\": \"CAPEC-591 Reflected XSS\"}]}], \"metrics\": [{\"format\": \"CVSS\", \"cvssV4_0\": {\"Safety\": \"NOT_DEFINED\", \"version\": \"4.0\", \"Recovery\": \"NOT_DEFINED\", \"baseScore\": 2.1, \"Automatable\": \"NOT_DEFINED\", \"attackVector\": \"NETWORK\", \"baseSeverity\": \"LOW\", \"valueDensity\": \"NOT_DEFINED\", \"vectorString\": \"CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:A/VC:N/VI:N/VA:N/SC:L/SI:L/SA:N\", \"providerUrgency\": \"NOT_DEFINED\", \"userInteraction\": \"ACTIVE\", \"attackComplexity\": \"LOW\", \"attackRequirements\": \"PRESENT\", \"privilegesRequired\": \"NONE\", \"subIntegrityImpact\": \"LOW\", \"vulnIntegrityImpact\": \"NONE\", \"subAvailabilityImpact\": \"NONE\", \"vulnAvailabilityImpact\": \"NONE\", \"subConfidentialityImpact\": \"LOW\", \"vulnConfidentialityImpact\": \"NONE\", \"vulnerabilityResponseEffort\": \"NOT_DEFINED\"}, \"scenarios\": [{\"lang\": \"en\", \"value\": \"GENERAL\"}]}], \"affected\": [{\"cpes\": [\"cpe:2.3:a:team-alembic:ash_authentication:*:*:*:*:*:*:*:*\"], \"repo\": \"https://github.com/team-alembic/ash_authentication\", \"vendor\": \"team-alembic\", \"modules\": [\"\u0027Elixir.AshAuthentication.Strategy.MagicLink.Plug\u0027\", \"\u0027Elixir.AshAuthentication.AddOn.Confirmation.Plug\u0027\"], \"product\": \"ash_authentication\", \"versions\": [{\"status\": \"affected\", \"version\": \"4.8.0\", \"lessThan\": \"4.14.2\", \"versionType\": \"semver\"}, {\"status\": \"affected\", \"version\": \"5.0.0-rc.0\", \"lessThan\": \"5.0.0-rc.13\", \"versionType\": \"semver\"}], \"packageURL\": \"pkg:hex/ash_authentication\", \"packageName\": \"ash_authentication\", \"programFiles\": [\"lib/ash_authentication/strategies/magic_link/sign_in_form.html.eex\", \"lib/ash_authentication/strategies/magic_link/plug.ex\", \"lib/ash_authentication/add_ons/confirmation/confirmation_form.html.eex\", \"lib/ash_authentication/add_ons/confirmation/plug.ex\"], \"collectionURL\": \"https://repo.hex.pm\", \"defaultStatus\": \"unaffected\", \"programRoutines\": [{\"name\": \"\u0027Elixir.AshAuthentication.Strategy.MagicLink.Plug\u0027:accept/2\"}, {\"name\": \"\u0027Elixir.AshAuthentication.AddOn.Confirmation.Plug\u0027:accept/2\"}]}, {\"cpes\": [\"cpe:2.3:a:team-alembic:ash_authentication:*:*:*:*:*:*:*:*\"], \"repo\": \"https://github.com/team-alembic/ash_authentication\", \"vendor\": \"team-alembic\", \"modules\": [\"\u0027Elixir.AshAuthentication.Strategy.MagicLink.Plug\u0027\", \"\u0027Elixir.AshAuthentication.AddOn.Confirmation.Plug\u0027\"], \"product\": \"ash_authentication\", \"versions\": [{\"status\": \"affected\", \"changes\": [{\"at\": \"62719710790a150a9eacab9c0a066e0d122d15be\", \"status\": \"unaffected\"}, {\"at\": \"0bd5199db066be22b2ca1ec8bc6109e5d62e6070\", \"status\": \"unaffected\"}], \"version\": \"fe0b4558dbe852fee5d81a460a8355577618a8c8\", \"lessThan\": \"*\", \"versionType\": \"git\"}], \"packageURL\": \"pkg:github/team-alembic/ash_authentication\", \"packageName\": \"team-alembic/ash_authentication\", \"programFiles\": [\"lib/ash_authentication/strategies/magic_link/sign_in_form.html.eex\", \"lib/ash_authentication/strategies/magic_link/plug.ex\", \"lib/ash_authentication/add_ons/confirmation/confirmation_form.html.eex\", \"lib/ash_authentication/add_ons/confirmation/plug.ex\"], \"collectionURL\": \"https://github.com\", \"defaultStatus\": \"unaffected\", \"programRoutines\": [{\"name\": \"\u0027Elixir.AshAuthentication.Strategy.MagicLink.Plug\u0027:accept/2\"}, {\"name\": \"\u0027Elixir.AshAuthentication.AddOn.Confirmation.Plug\u0027:accept/2\"}]}], \"references\": [{\"url\": \"https://github.com/team-alembic/ash_authentication/security/advisories/GHSA-54fc-x3hv-ffhw\", \"tags\": [\"vendor-advisory\", \"related\"]}, {\"url\": \"https://cna.erlef.org/cves/CVE-2026-66882.html\", \"tags\": [\"related\"]}, {\"url\": \"https://osv.dev/vulnerability/EEF-CVE-2026-66882\", \"tags\": [\"related\"]}, {\"url\": \"https://github.com/team-alembic/ash_authentication/commit/62719710790a150a9eacab9c0a066e0d122d15be\", \"tags\": [\"patch\"]}, {\"url\": \"https://github.com/team-alembic/ash_authentication/commit/0bd5199db066be22b2ca1ec8bc6109e5d62e6070\", \"tags\": [\"patch\"]}], \"descriptions\": [{\"lang\": \"en\", \"value\": \"Improper Neutralization of Input During Web Page Generation (XSS) vulnerability in team-alembic AshAuthentication allows reflected cross-site scripting via the confirmation and magic link interaction forms.\\n\\nWhen a strategy is configured with require_interaction? set to true, AshAuthentication serves an intermediate HTML page asking the user to confirm the action by submitting a form. Both such pages embed a request parameter directly into a hidden input\u0027s value attribute without HTML escaping: lib/ash_authentication/add_ons/confirmation/confirmation_form.html.eex interpolates the confirm parameter, and lib/ash_authentication/strategies/magic_link/sign_in_form.html.eex interpolates the magic link token parameter. These templates are compiled with EEx.function_from_file/3 using plain \u003c%= %\u003e expressions, which perform no escaping, so the parameter is reflected verbatim.\\n\\nNeither accept handler validates the value before rendering it. AshAuthentication.AddOn.Confirmation.Plug.accept/2 only checks that a confirm key is present, and AshAuthentication.Strategy.MagicLink.Plug.accept/2 reads the parameter directly, so no token signature is verified at this stage and arbitrary attacker-supplied text reaches the template. An unauthenticated attacker can therefore craft a URL whose parameter terminates the attribute and injects markup, for example a quote followed by a \u003cscript\u003e element. Because the accept phase is served over GET, loading the crafted link is sufficient; no form submission or prior authentication is required.\\n\\nThe injected script executes in the origin of the application embedding AshAuthentication, giving it access to that origin\u0027s cookies, session, and same-origin responses. Since these pages are part of the authentication flow, a victim following what appears to be a legitimate confirmation or sign-in link is a plausible target.\\n\\nThis issue affects ash_authentication: from 4.8.0 before 4.14.2 and from 5.0.0-rc.0 before 5.0.0-rc.13.\", \"supportingMedia\": [{\"type\": \"text/html\", \"value\": \"\u003cp\u003eImproper Neutralization of Input During Web Page Generation (XSS) vulnerability in team-alembic AshAuthentication allows reflected cross-site scripting via the confirmation and magic link interaction forms.\u003c/p\u003e\\n\u003cp\u003eWhen a strategy is configured with \u003ccode\u003erequire_interaction?\u003c/code\u003e set to \u003ccode\u003etrue\u003c/code\u003e, AshAuthentication serves an intermediate HTML page asking the user to confirm the action by submitting a form. Both such pages embed a request parameter directly into a hidden input\u0027s \u003ccode\u003evalue\u003c/code\u003e attribute without HTML escaping: \u003ccode\u003elib/ash_authentication/add_ons/confirmation/confirmation_form.html.eex\u003c/code\u003e interpolates the \u003ccode\u003econfirm\u003c/code\u003e parameter, and \u003ccode\u003elib/ash_authentication/strategies/magic_link/sign_in_form.html.eex\u003c/code\u003e interpolates the magic link token parameter. These templates are compiled with \u003ccode\u003eEEx.function_from_file/3\u003c/code\u003e using plain \u003ccode\u003e\u0026lt;%= %\u0026gt;\u003c/code\u003e expressions, which perform no escaping, so the parameter is reflected verbatim.\u003c/p\u003e\\n\u003cp\u003eNeither accept handler validates the value before rendering it. \u003ccode\u003eAshAuthentication.AddOn.Confirmation.Plug.accept/2\u003c/code\u003e only checks that a \u003ccode\u003econfirm\u003c/code\u003e key is present, and \u003ccode\u003eAshAuthentication.Strategy.MagicLink.Plug.accept/2\u003c/code\u003e reads the parameter directly, so no token signature is verified at this stage and arbitrary attacker-supplied text reaches the template. An unauthenticated attacker can therefore craft a URL whose parameter terminates the attribute and injects markup, for example a quote followed by a \u003ccode\u003e\u0026lt;script\u0026gt;\u003c/code\u003e element. Because the accept phase is served over GET, loading the crafted link is sufficient; no form submission or prior authentication is required.\u003c/p\u003e\\n\u003cp\u003eThe injected script executes in the origin of the application embedding AshAuthentication, giving it access to that origin\u0027s cookies, session, and same-origin responses. Since these pages are part of the authentication flow, a victim following what appears to be a legitimate confirmation or sign-in link is a plausible target.\u003c/p\u003e\\n\u003cp\u003eThis issue affects ash_authentication: from 4.8.0 before 4.14.2 and from 5.0.0-rc.0 before 5.0.0-rc.13.\u003c/p\u003e\", \"base64\": false}, {\"type\": \"text/markdown\", \"value\": \"Improper Neutralization of Input During Web Page Generation (XSS) vulnerability in team-alembic AshAuthentication allows reflected cross-site scripting via the confirmation and magic link interaction forms.\\n\\nWhen a strategy is configured with `require_interaction?` set to `true`, AshAuthentication serves an intermediate HTML page asking the user to confirm the action by submitting a form. Both such pages embed a request parameter directly into a hidden input\u0027s `value` attribute without HTML escaping: `lib/ash_authentication/add_ons/confirmation/confirmation_form.html.eex` interpolates the `confirm` parameter, and `lib/ash_authentication/strategies/magic_link/sign_in_form.html.eex` interpolates the magic link token parameter. These templates are compiled with `EEx.function_from_file/3` using plain `\u003c%= %\u003e` expressions, which perform no escaping, so the parameter is reflected verbatim.\\n\\nNeither accept handler validates the value before rendering it. `AshAuthentication.AddOn.Confirmation.Plug.accept/2` only checks that a `confirm` key is present, and `AshAuthentication.Strategy.MagicLink.Plug.accept/2` reads the parameter directly, so no token signature is verified at this stage and arbitrary attacker-supplied text reaches the template. An unauthenticated attacker can therefore craft a URL whose parameter terminates the attribute and injects markup, for example a quote followed by a `\u003cscript\u003e` element. Because the accept phase is served over GET, loading the crafted link is sufficient; no form submission or prior authentication is required.\\n\\nThe injected script executes in the origin of the application embedding AshAuthentication, giving it access to that origin\u0027s cookies, session, and same-origin responses. Since these pages are part of the authentication flow, a victim following what appears to be a legitimate confirmation or sign-in link is a plausible target.\\n\\nThis issue affects ash_authentication: from 4.8.0 before 4.14.2 and from 5.0.0-rc.0 before 5.0.0-rc.13.\", \"base64\": false}]}], \"problemTypes\": [{\"descriptions\": [{\"lang\": \"en\", \"type\": \"CWE\", \"cweId\": \"CWE-79\", \"description\": \"CWE-79 Improper Neutralization of Input During Web Page Generation (\u0027Cross-site Scripting\u0027)\"}]}], \"configurations\": [{\"lang\": \"en\", \"value\": \"Only strategies configured with require_interaction? set to true are affected. This option defaults to false, and when it is disabled the vulnerable accept route is not registered at all, so the affected pages cannot be reached.\\n\\nThe option is not obscure: AshAuthentication\u0027s own documentation for the confirmation add-on advises that applications using AshAuthenticationPhoenix should enable it, so the affected configuration is a documented and recommended deployment rather than an unusual one.\\n\\nAt least one of the following must be configured with require_interaction? true:\\n\\n* the confirmation add-on, which serves the affected confirmation accept form; or\\n* the magic_link strategy, which serves the affected sign-in accept form.\", \"supportingMedia\": [{\"type\": \"text/html\", \"value\": \"\u003cp\u003eOnly strategies configured with \u003ccode\u003erequire_interaction?\u003c/code\u003e set to \u003ccode\u003etrue\u003c/code\u003e are affected. This option defaults to \u003ccode\u003efalse\u003c/code\u003e, and when it is disabled the vulnerable accept route is not registered at all, so the affected pages cannot be reached.\u003c/p\u003e\\n\u003cp\u003eThe option is not obscure: AshAuthentication\u0027s own documentation for the confirmation add-on advises that applications using AshAuthenticationPhoenix should enable it, so the affected configuration is a documented and recommended deployment rather than an unusual one.\u003c/p\u003e\\n\u003cp\u003eAt least one of the following must be configured with \u003ccode\u003erequire_interaction? true\u003c/code\u003e:\u003c/p\u003e\\n\u003cul\u003e\\n\u003cli\u003ethe \u003ccode\u003econfirmation\u003c/code\u003e add-on, which serves the affected confirmation accept form; or\u003c/li\u003e\\n\u003cli\u003ethe \u003ccode\u003emagic_link\u003c/code\u003e strategy, which serves the affected sign-in accept form.\u003c/li\u003e\\n\u003c/ul\u003e\", \"base64\": false}, {\"type\": \"text/markdown\", \"value\": \"Only strategies configured with `require_interaction?` set to `true` are affected. This option defaults to `false`, and when it is disabled the vulnerable accept route is not registered at all, so the affected pages cannot be reached.\\n\\nThe option is not obscure: AshAuthentication\u0027s own documentation for the confirmation add-on advises that applications using AshAuthenticationPhoenix should enable it, so the affected configuration is a documented and recommended deployment rather than an unusual one.\\n\\nAt least one of the following must be configured with `require_interaction? true`:\\n\\n- the `confirmation` add-on, which serves the affected confirmation accept form; or\\n- the `magic_link` strategy, which serves the affected sign-in accept form.\", \"base64\": false}]}], \"cpeApplicability\": [{\"nodes\": [{\"negate\": false, \"cpeMatch\": [{\"criteria\": \"cpe:2.3:a:team-alembic:ash_authentication:*:*:*:*:*:*:*:*\", \"vulnerable\": true, \"versionEndExcluding\": \"4.14.2\", \"versionStartIncluding\": \"4.8.0\"}, {\"criteria\": \"cpe:2.3:a:team-alembic:ash_authentication:*:*:*:*:*:*:*:*\", \"vulnerable\": true, \"versionEndExcluding\": \"5.0.0-rc.13\", \"versionStartIncluding\": \"5.0.0-rc.0\"}], \"operator\": \"OR\"}], \"operator\": \"AND\"}], \"providerMetadata\": {\"orgId\": \"6b3ad84c-e1a6-4bf7-a703-f496b71e49db\", \"shortName\": \"EEF\", \"dateUpdated\": \"2026-08-25T08:03:47.721Z\"}}}",
"cveMetadata": "{\"cveId\": \"CVE-2026-66882\", \"state\": \"PUBLISHED\", \"dateUpdated\": \"2026-08-25T19:51:21.332Z\", \"dateReserved\": \"2026-07-28T04:15:10.240Z\", \"assignerOrgId\": \"6b3ad84c-e1a6-4bf7-a703-f496b71e49db\", \"datePublished\": \"2026-08-25T08:03:47.721Z\", \"assignerShortName\": \"EEF\"}",
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
}
}
Loading…
Loading…
Sightings
| Author | Source | Type | Date |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or seen somewhere by the user.
- Confirmed: The vulnerability is confirmed from an analyst perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: This vulnerability was exploited and seen by the user reporting the sighting.
- Patched: This vulnerability was successfully patched by the user reporting the sighting.
- Not exploited: This vulnerability was not exploited or seen by the user reporting the sighting.
- Not confirmed: The user expresses doubt about the veracity of the vulnerability.
- Not patched: This vulnerability was not successfully patched by the user reporting the sighting.
Loading…
Loading…