{
  "containers": {
    "adp": [
      {
        "metrics": [
          {
            "other": {
              "content": {
                "id": "CVE-2026-65633",
                "options": [
                  {
                    "Exploitation": "poc"
                  },
                  {
                    "Automatable": "no"
                  },
                  {
                    "Technical Impact": "total"
                  }
                ],
                "role": "CISA Coordinator",
                "timestamp": "2026-08-25T19:49:03.433221Z",
                "version": "2.0.3"
              },
              "type": "ssvc"
            }
          }
        ],
        "providerMetadata": {
          "dateUpdated": "2026-08-25T19:49:22.437Z",
          "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_bearer/3"
            }
          ],
          "repo": "https://github.com/team-alembic/ash_authentication",
          "vendor": "team-alembic",
          "versions": [
            {
              "lessThan": "4.14.2",
              "status": "affected",
              "version": "3.10.5",
              "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.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_bearer/3"
            }
          ],
          "repo": "https://github.com/team-alembic/ash_authentication",
          "vendor": "team-alembic",
          "versions": [
            {
              "changes": [
                {
                  "at": "8cf8b2d4426172be0900a3505e9491800b951750",
                  "status": "unaffected"
                },
                {
                  "at": "124eddd1bbeb40289c3fe8831ac10677a19fcf09",
                  "status": "unaffected"
                }
              ],
              "lessThan": "*",
              "status": "affected",
              "version": "eca8cadea0f1595ed2c10a0c177b1da9aa9e5269",
              "versionType": "git"
            }
          ]
        }
      ],
      "configurations": [
        {
          "lang": "en",
          "supportingMedia": [
            {
              "base64": false,
              "type": "text/html",
              "value": "\u003cp\u003eThe bypass is reachable only when a resource uses stateless bearer-token verification, i.e. \u003ccode\u003erequire_token_presence_for_authentication?\u003c/code\u003e is \u003ccode\u003efalse\u003c/code\u003e (the DSL default). In that mode \u003ccode\u003evalidate_token/3\u003c/code\u003e returns \u003ccode\u003e{:ok, nil}\u003c/code\u003e without consulting the token resource, so the JWT\u0027s \u003ccode\u003epurpose\u003c/code\u003e claim is the only remaining scoping signal at the bearer boundary and it is never checked. When \u003ccode\u003erequire_token_presence_for_authentication?\u003c/code\u003e is \u003ccode\u003etrue\u003c/code\u003e, \u003ccode\u003evalidate_token/3\u003c/code\u003e looks the token up with \u003ccode\u003eget_token(%{\"jti\" =\u0026gt; jti, \"purpose\" =\u0026gt; \"user\"})\u003c/code\u003e; purpose-limited tokens are stored under their own purpose (\u003ccode\u003esign_in\u003c/code\u003e, \u003ccode\u003eremember_me\u003c/code\u003e, ...), so that lookup fails and those tokens are rejected. Applications scaffolded by the Igniter installer since v4.5.0 default to \u003ccode\u003erequire_token_presence_for_authentication?: true\u003c/code\u003e and are therefore not exposed as generated; applications configured manually or that deliberately opt into stateless JWT verification are.\u003c/p\u003e\n\u003cp\u003eExploitation additionally requires the host application to wire up \u003ccode\u003eAshAuthentication.Plug.Helpers.retrieve_from_bearer/3\u003c/code\u003e on a route the attacker can reach, and to use a strategy that issues purpose-limited JWTs carrying a resolvable \u003ccode\u003esub\u003c/code\u003e claim: either the WebAuthn strategy (sign-in tokens are always emitted, no opt-in required) or the Password strategy with \u003ccode\u003esign_in_tokens_enabled?: true\u003c/code\u003e. The session-based path (\u003ccode\u003eauthenticate_resource_from_session/4\u003c/code\u003e) already enforces \u003ccode\u003epurpose == \"user\"\u003c/code\u003e against the token resource and is not affected.\u003c/p\u003e"
            },
            {
              "base64": false,
              "type": "text/markdown",
              "value": "The bypass is reachable only when a resource uses stateless bearer-token verification, i.e. `require_token_presence_for_authentication?` is `false` (the DSL default). In that mode `validate_token/3` returns `{:ok, nil}` without consulting the token resource, so the JWT\u0027s `purpose` claim is the only remaining scoping signal at the bearer boundary and it is never checked. When `require_token_presence_for_authentication?` is `true`, `validate_token/3` looks the token up with `get_token(%{\"jti\" =\u003e jti, \"purpose\" =\u003e \"user\"})`; purpose-limited tokens are stored under their own purpose (`sign_in`, `remember_me`, ...), so that lookup fails and those tokens are rejected. Applications scaffolded by the Igniter installer since v4.5.0 default to `require_token_presence_for_authentication?: true` and are therefore not exposed as generated; applications configured manually or that deliberately opt into stateless JWT verification are.\n\nExploitation additionally requires the host application to wire up `AshAuthentication.Plug.Helpers.retrieve_from_bearer/3` on a route the attacker can reach, and to use a strategy that issues purpose-limited JWTs carrying a resolvable `sub` claim: either the WebAuthn strategy (sign-in tokens are always emitted, no opt-in required) or the Password strategy with `sign_in_tokens_enabled?: true`. The session-based path (`authenticate_resource_from_session/4`) already enforces `purpose == \"user\"` against the token resource and is not affected."
            }
          ],
          "value": "The bypass is reachable only when a resource uses stateless bearer-token verification, i.e. require_token_presence_for_authentication? is false (the DSL default). In that mode validate_token/3 returns {:ok, nil} without consulting the token resource, so the JWT\u0027s purpose claim is the only remaining scoping signal at the bearer boundary and it is never checked. When require_token_presence_for_authentication? is true, validate_token/3 looks the token up with get_token(%{\"jti\" =\u003e jti, \"purpose\" =\u003e \"user\"}); purpose-limited tokens are stored under their own purpose (sign_in, remember_me, ...), so that lookup fails and those tokens are rejected. Applications scaffolded by the Igniter installer since v4.5.0 default to require_token_presence_for_authentication?: true and are therefore not exposed as generated; applications configured manually or that deliberately opt into stateless JWT verification are.\n\nExploitation additionally requires the host application to wire up AshAuthentication.Plug.Helpers.retrieve_from_bearer/3 on a route the attacker can reach, and to use a strategy that issues purpose-limited JWTs carrying a resolvable sub claim: either the WebAuthn strategy (sign-in tokens are always emitted, no opt-in required) or the Password strategy with sign_in_tokens_enabled?: true. The session-based path (authenticate_resource_from_session/4) already enforces purpose == \"user\" against the token resource and is not affected."
        }
      ],
      "cpeApplicability": [
        {
          "nodes": [
            {
              "cpeMatch": [
                {
                  "criteria": "cpe:2.3:a:team-alembic:ash_authentication:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "4.14.2",
                  "versionStartIncluding": "3.10.5",
                  "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": "EQSTLab"
        },
        {
          "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 Authentication vulnerability in team-alembic AshAuthentication allows purpose-limited JWTs to be replayed as full bearer API credentials when a resource uses stateless bearer-token verification.\u003c/p\u003e\n\u003cp\u003eThe bearer-token authentication helper \u003ccode\u003eAshAuthentication.Plug.Helpers.retrieve_from_bearer/3\u003c/code\u003e verifies an \u003ccode\u003eAuthorization: Bearer\u003c/code\u003e JWT\u0027s signature and rejects tokens containing an \u003ccode\u003eact\u003c/code\u003e claim, but performs no check that the token\u0027s \u003ccode\u003epurpose\u003c/code\u003e claim equals \u003ccode\u003euser\u003c/code\u003e at the bearer boundary. When the resource is configured with \u003ccode\u003erequire_token_presence_for_authentication?: false\u003c/code\u003e (the DSL default), the follow-on \u003ccode\u003evalidate_token/3\u003c/code\u003e helper returns \u003ccode\u003e{:ok, nil}\u003c/code\u003e without consulting the token resource, so no downstream check on \u003ccode\u003epurpose\u003c/code\u003e takes place either. As a result, any valid, non-expired JWT the library itself issued for a narrow, single-purpose flow (most notably the \u003ccode\u003epurpose: sign_in\u003c/code\u003e token that WebAuthn always emits during sign-in, and that the Password strategy emits when sign-in tokens are enabled) is accepted directly as a general-purpose bearer credential and resolves to a full \u003ccode\u003ecurrent_user\u003c/code\u003e assignment.\u003c/p\u003e\n\u003cp\u003eThis bypasses the library\u0027s intended token-exchange contract, in which the \u003ccode\u003esign_in\u003c/code\u003e token is meant to be presented exactly once to a preparation that validates the \u003ccode\u003epurpose\u003c/code\u003e claim and immediately revokes the token. The first use of a still-valid sign-in token presented directly in the \u003ccode\u003eAuthorization\u003c/code\u003e header succeeds because the stateless bearer path never scopes it to \u003ccode\u003epurpose == \"user\"\u003c/code\u003e.\u003c/p\u003e\n\u003cp\u003eAn attacker who obtains a not-yet-exchanged sign-in token for a target subject (for example via log or referrer leakage, an intercepted magic-link delivery channel, or a partially compromised intermediary) can present it as a bearer token and be authenticated as that subject, fully bypassing the intended one-time-use and revocation semantics. Exploitation additionally requires that the host application wire up \u003ccode\u003eretrieve_from_bearer/3\u003c/code\u003e on a reachable route and uses either WebAuthn (sign-in tokens are always issued) or the Password strategy with \u003ccode\u003esign_in_tokens_enabled?: true\u003c/code\u003e. Resources configured with \u003ccode\u003erequire_token_presence_for_authentication?: true\u003c/code\u003e (including applications scaffolded by the Igniter installer since v4.5.0) and the session-based path (\u003ccode\u003eauthenticate_resource_from_session/4\u003c/code\u003e) enforce \u003ccode\u003epurpose == \"user\"\u003c/code\u003e against the stored token record and are not affected.\u003c/p\u003e\n\u003cp\u003eThis issue affects ash_authentication: from 3.10.5 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 Authentication vulnerability in team-alembic AshAuthentication allows purpose-limited JWTs to be replayed as full bearer API credentials when a resource uses stateless bearer-token verification.\n\nThe bearer-token authentication helper `AshAuthentication.Plug.Helpers.retrieve_from_bearer/3` verifies an `Authorization: Bearer` JWT\u0027s signature and rejects tokens containing an `act` claim, but performs no check that the token\u0027s `purpose` claim equals `user` at the bearer boundary. When the resource is configured with `require_token_presence_for_authentication?: false` (the DSL default), the follow-on `validate_token/3` helper returns `{:ok, nil}` without consulting the token resource, so no downstream check on `purpose` takes place either. As a result, any valid, non-expired JWT the library itself issued for a narrow, single-purpose flow (most notably the `purpose: sign_in` token that WebAuthn always emits during sign-in, and that the Password strategy emits when sign-in tokens are enabled) is accepted directly as a general-purpose bearer credential and resolves to a full `current_user` assignment.\n\nThis bypasses the library\u0027s intended token-exchange contract, in which the `sign_in` token is meant to be presented exactly once to a preparation that validates the `purpose` claim and immediately revokes the token. The first use of a still-valid sign-in token presented directly in the `Authorization` header succeeds because the stateless bearer path never scopes it to `purpose == \"user\"`.\n\nAn attacker who obtains a not-yet-exchanged sign-in token for a target subject (for example via log or referrer leakage, an intercepted magic-link delivery channel, or a partially compromised intermediary) can present it as a bearer token and be authenticated as that subject, fully bypassing the intended one-time-use and revocation semantics. Exploitation additionally requires that the host application wire up `retrieve_from_bearer/3` on a reachable route and uses either WebAuthn (sign-in tokens are always issued) or the Password strategy with `sign_in_tokens_enabled?: true`. Resources configured with `require_token_presence_for_authentication?: true` (including applications scaffolded by the Igniter installer since v4.5.0) and the session-based path (`authenticate_resource_from_session/4`) enforce `purpose == \"user\"` against the stored token record and are not affected.\n\nThis issue affects ash_authentication: from 3.10.5 before 4.14.2 and from 5.0.0-rc.0 before 5.0.0-rc.13."
            }
          ],
          "value": "Improper Authentication vulnerability in team-alembic AshAuthentication allows purpose-limited JWTs to be replayed as full bearer API credentials when a resource uses stateless bearer-token verification.\n\nThe bearer-token authentication helper AshAuthentication.Plug.Helpers.retrieve_from_bearer/3 verifies an Authorization: Bearer JWT\u0027s signature and rejects tokens containing an act claim, but performs no check that the token\u0027s purpose claim equals user at the bearer boundary. When the resource is configured with require_token_presence_for_authentication?: false (the DSL default), the follow-on validate_token/3 helper returns {:ok, nil} without consulting the token resource, so no downstream check on purpose takes place either. As a result, any valid, non-expired JWT the library itself issued for a narrow, single-purpose flow (most notably the purpose: sign_in token that WebAuthn always emits during sign-in, and that the Password strategy emits when sign-in tokens are enabled) is accepted directly as a general-purpose bearer credential and resolves to a full current_user assignment.\n\nThis bypasses the library\u0027s intended token-exchange contract, in which the sign_in token is meant to be presented exactly once to a preparation that validates the purpose claim and immediately revokes the token. The first use of a still-valid sign-in token presented directly in the Authorization header succeeds because the stateless bearer path never scopes it to purpose == \"user\".\n\nAn attacker who obtains a not-yet-exchanged sign-in token for a target subject (for example via log or referrer leakage, an intercepted magic-link delivery channel, or a partially compromised intermediary) can present it as a bearer token and be authenticated as that subject, fully bypassing the intended one-time-use and revocation semantics. Exploitation additionally requires that the host application wire up retrieve_from_bearer/3 on a reachable route and uses either WebAuthn (sign-in tokens are always issued) or the Password strategy with sign_in_tokens_enabled?: true. Resources configured with require_token_presence_for_authentication?: true (including applications scaffolded by the Igniter installer since v4.5.0) and the session-based path (authenticate_resource_from_session/4) enforce purpose == \"user\" against the stored token record and are not affected.\n\nThis issue affects ash_authentication: from 3.10.5 before 4.14.2 and from 5.0.0-rc.0 before 5.0.0-rc.13."
        }
      ],
      "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": "HIGH",
            "attackRequirements": "PRESENT",
            "attackVector": "NETWORK",
            "baseScore": 7.6,
            "baseSeverity": "HIGH",
            "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: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-08-25T08:03:51.846Z",
        "orgId": "6b3ad84c-e1a6-4bf7-a703-f496b71e49db",
        "shortName": "EEF"
      },
      "references": [
        {
          "tags": [
            "vendor-advisory",
            "related"
          ],
          "url": "https://github.com/team-alembic/ash_authentication/security/advisories/GHSA-6vcj-3h59-rrc3"
        },
        {
          "tags": [
            "related"
          ],
          "url": "https://cna.erlef.org/cves/CVE-2026-65633.html"
        },
        {
          "tags": [
            "related"
          ],
          "url": "https://osv.dev/vulnerability/EEF-CVE-2026-65633"
        },
        {
          "tags": [
            "patch"
          ],
          "url": "https://github.com/team-alembic/ash_authentication/commit/8cf8b2d4426172be0900a3505e9491800b951750"
        },
        {
          "tags": [
            "patch"
          ],
          "url": "https://github.com/team-alembic/ash_authentication/commit/124eddd1bbeb40289c3fe8831ac10677a19fcf09"
        }
      ],
      "source": {
        "discovery": "EXTERNAL"
      },
      "title": "Purpose-limited JWT accepted as full bearer authentication in AshAuthentication"
    }
  },
  "cveMetadata": {
    "assignerOrgId": "6b3ad84c-e1a6-4bf7-a703-f496b71e49db",
    "assignerShortName": "EEF",
    "cveId": "CVE-2026-65633",
    "datePublished": "2026-08-25T08:03:51.846Z",
    "dateReserved": "2026-07-22T13:58:26.233Z",
    "dateUpdated": "2026-08-25T19:49:22.437Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2"
}

{
  "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"
}

{
  "containers": {
    "adp": [
      {
        "metrics": [
          {
            "other": {
              "content": {
                "id": "CVE-2026-49757",
                "options": [
                  {
                    "Exploitation": "poc"
                  },
                  {
                    "Automatable": "yes"
                  },
                  {
                    "Technical Impact": "total"
                  }
                ],
                "role": "CISA Coordinator",
                "timestamp": "2026-06-15T12:35:13.009558Z",
                "version": "2.0.3"
              },
              "type": "ssvc"
            }
          }
        ],
        "providerMetadata": {
          "dateUpdated": "2026-06-15T12:35:41.459Z",
          "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.IdentityChange\u0027",
            "\u0027Elixir.AshAuthentication.Strategy.OAuth2.SignInPreparation\u0027"
          ],
          "packageName": "ash_authentication",
          "packageURL": "pkg:hex/ash_authentication",
          "product": "ash_authentication",
          "programFiles": [
            "lib/ash_authentication/strategies/oauth2/identity_change.ex",
            "lib/ash_authentication/strategies/oauth2/sign_in_preparation.ex"
          ],
          "programRoutines": [
            {
              "name": "\u0027Elixir.AshAuthentication.Strategy.OAuth2.IdentityChange\u0027:change/3"
            },
            {
              "name": "\u0027Elixir.AshAuthentication.Strategy.OAuth2.SignInPreparation\u0027:prepare/3"
            }
          ],
          "repo": "https://github.com/team-alembic/ash_authentication",
          "vendor": "team-alembic",
          "versions": [
            {
              "lessThan": "4.14.0",
              "status": "affected",
              "version": "0.1.0",
              "versionType": "semver"
            },
            {
              "lessThan": "5.0.0-rc.10",
              "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.IdentityChange\u0027",
            "\u0027Elixir.AshAuthentication.Strategy.OAuth2.SignInPreparation\u0027"
          ],
          "packageName": "team-alembic/ash_authentication",
          "packageURL": "pkg:github/team-alembic/ash_authentication",
          "product": "ash_authentication",
          "programFiles": [
            "lib/ash_authentication/strategies/oauth2/identity_change.ex",
            "lib/ash_authentication/strategies/oauth2/sign_in_preparation.ex"
          ],
          "programRoutines": [
            {
              "name": "\u0027Elixir.AshAuthentication.Strategy.OAuth2.IdentityChange\u0027:change/3"
            },
            {
              "name": "\u0027Elixir.AshAuthentication.Strategy.OAuth2.SignInPreparation\u0027:prepare/3"
            }
          ],
          "repo": "https://github.com/team-alembic/ash_authentication.git",
          "vendor": "team-alembic",
          "versions": [
            {
              "changes": [
                {
                  "at": "728b8d28c1b5f465fa1116ef044a815300fc733d",
                  "status": "unaffected"
                },
                {
                  "at": "64530644f9b37ebb76ca14aeb83a77597a0034b7",
                  "status": "unaffected"
                }
              ],
              "lessThan": "*",
              "status": "affected",
              "version": "c5f589058e04239263f50a1430eb17ea6d5dd1a2",
              "versionType": "git"
            }
          ]
        }
      ],
      "cpeApplicability": [
        {
          "nodes": [
            {
              "cpeMatch": [
                {
                  "criteria": "cpe:2.3:a:team-alembic:ash_authentication:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "4.14.0",
                  "versionStartIncluding": "0.1.0",
                  "vulnerable": true
                },
                {
                  "criteria": "cpe:2.3:a:team-alembic:ash_authentication:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "5.0.0-rc.10",
                  "versionStartIncluding": "5.0.0-rc.0",
                  "vulnerable": true
                }
              ],
              "negate": false,
              "operator": "OR"
            }
          ],
          "operator": "AND"
        }
      ],
      "credits": [
        {
          "lang": "en",
          "type": "finder",
          "value": "Jarl Andr\u00e9 H\u00fcbenthal"
        },
        {
          "lang": "en",
          "type": "remediation developer",
          "value": "James Harton"
        },
        {
          "lang": "en",
          "type": "analyst",
          "value": "Jonatan M\u00e4nnchen / EEF"
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "supportingMedia": [
            {
              "base64": false,
              "type": "text/html",
              "value": "Authentication Bypass by Spoofing vulnerability in team-alembic AshAuthentication allows account takeover of local users via OAuth2/OIDC sign-in.\u003cp\u003eAshAuthentication\u0027s OAuth2 and OIDC family strategies matched the local user by email address (an upsert on the email field, or a user-defined sign-in filter) rather than by the OpenID Connect \u003ctt\u003eiss\u003c/tt\u003e/\u003ctt\u003esub\u003c/tt\u003e claim combination. Per OpenID Connect Core \u00a75.7, only \u003ctt\u003eiss\u003c/tt\u003e/\u003ctt\u003esub\u003c/tt\u003e uniquely and stably identifies an end-user; other claims, including \u003ctt\u003eemail\u003c/tt\u003e, MUST NOT be used as unique identifiers.\u003c/p\u003e\u003cp\u003eA provider login presenting a victim\u0027s email, including an unverified email, a reused email, or an account with \u003ctt\u003eemail_verified: false\u003c/tt\u003e, resolved to and signed in as the victim\u0027s existing local account. An unauthenticated attacker who can register an account on any accepted OAuth provider with the victim\u0027s email (or who benefits from provider-side email reuse or reclamation) obtains the victim\u0027s full local privileges.\u003c/p\u003e\u003cp\u003eThe fix resolves users by the \u003ctt\u003e(strategy, sub)\u003c/tt\u003e identity stored in a user identity resource, and only links a new \u003ctt\u003esub\u003c/tt\u003e to an existing local account by email when the provider\u0027s \u003ctt\u003eemail_verified\u003c/tt\u003e claim is trusted (\u003ctt\u003etrust_email_verified?\u003c/tt\u003e).\u003c/p\u003e\u003cp\u003eThis issue affects ash_authentication from 0.1.0 before 4.14.0 and from 5.0.0-rc.0 before 5.0.0-rc.10.\u003c/p\u003e"
            }
          ],
          "value": "Authentication Bypass by Spoofing vulnerability in team-alembic AshAuthentication allows account takeover of local users via OAuth2/OIDC sign-in.\n\nAshAuthentication\u0027s OAuth2 and OIDC family strategies matched the local user by email address (an upsert on the email field, or a user-defined sign-in filter) rather than by the OpenID Connect iss/sub claim combination. Per OpenID Connect Core \u00a75.7, only iss/sub uniquely and stably identifies an end-user; other claims, including email, MUST NOT be used as unique identifiers.\n\nA provider login presenting a victim\u0027s email, including an unverified email, a reused email, or an account with email_verified: false, resolved to and signed in as the victim\u0027s existing local account. An unauthenticated attacker who can register an account on any accepted OAuth provider with the victim\u0027s email (or who benefits from provider-side email reuse or reclamation) obtains the victim\u0027s full local privileges.\n\nThe fix resolves users by the (strategy, sub) identity stored in a user identity resource, and only links a new sub to an existing local account by email when the provider\u0027s email_verified claim is trusted (trust_email_verified?).\n\nThis issue affects ash_authentication from 0.1.0 before 4.14.0 and from 5.0.0-rc.0 before 5.0.0-rc.10."
        }
      ],
      "impacts": [
        {
          "capecId": "CAPEC-21",
          "descriptions": [
            {
              "lang": "en",
              "value": "CAPEC-21 Exploitation of Trusted Identifiers"
            }
          ]
        }
      ],
      "metrics": [
        {
          "cvssV4_0": {
            "attackComplexity": "LOW",
            "attackRequirements": "PRESENT",
            "attackVector": "NETWORK",
            "baseScore": 9.2,
            "baseSeverity": "CRITICAL",
            "privilegesRequired": "NONE",
            "subAvailabilityImpact": "NONE",
            "subConfidentialityImpact": "NONE",
            "subIntegrityImpact": "NONE",
            "userInteraction": "NONE",
            "vectorString": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N",
            "version": "4.0",
            "vulnAvailabilityImpact": "HIGH",
            "vulnConfidentialityImpact": "HIGH",
            "vulnIntegrityImpact": "HIGH"
          },
          "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-06-15T14:14:37.882Z",
        "orgId": "6b3ad84c-e1a6-4bf7-a703-f496b71e49db",
        "shortName": "EEF"
      },
      "references": [
        {
          "tags": [
            "vendor-advisory",
            "related"
          ],
          "url": "https://github.com/team-alembic/ash_authentication/security/advisories/GHSA-777c-2fxx-qr28"
        },
        {
          "tags": [
            "related"
          ],
          "url": "https://cna.erlef.org/cves/CVE-2026-49757.html"
        },
        {
          "tags": [
            "related"
          ],
          "url": "https://osv.dev/vulnerability/EEF-CVE-2026-49757"
        },
        {
          "tags": [
            "patch"
          ],
          "url": "https://github.com/team-alembic/ash_authentication/commit/728b8d28c1b5f465fa1116ef044a815300fc733d"
        },
        {
          "tags": [
            "patch"
          ],
          "url": "https://github.com/team-alembic/ash_authentication/commit/64530644f9b37ebb76ca14aeb83a77597a0034b7"
        }
      ],
      "source": {
        "discovery": "EXTERNAL"
      },
      "title": "OAuth2/OIDC account takeover in AshAuthentication via email-based user matching",
      "x_generator": {
        "engine": "cvelib 1.8.0"
      }
    }
  },
  "cveMetadata": {
    "assignerOrgId": "6b3ad84c-e1a6-4bf7-a703-f496b71e49db",
    "assignerShortName": "EEF",
    "cveId": "CVE-2026-49757",
    "datePublished": "2026-06-15T10:07:17.781Z",
    "dateReserved": "2026-06-01T13:45:22.449Z",
    "dateUpdated": "2026-06-15T14:14:37.882Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2"
}

{
  "containers": {
    "adp": [
      {
        "metrics": [
          {
            "other": {
              "content": {
                "id": "CVE-2025-32782",
                "options": [
                  {
                    "Exploitation": "none"
                  },
                  {
                    "Automatable": "no"
                  },
                  {
                    "Technical Impact": "partial"
                  }
                ],
                "role": "CISA Coordinator",
                "timestamp": "2025-04-16T14:07:20.590187Z",
                "version": "2.0.3"
              },
              "type": "ssvc"
            }
          }
        ],
        "providerMetadata": {
          "dateUpdated": "2025-04-16T15:36:23.539Z",
          "orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
          "shortName": "CISA-ADP"
        },
        "title": "CISA ADP Vulnrichment"
      }
    ],
    "cna": {
      "affected": [
        {
          "product": "ash_authentication",
          "vendor": "team-alembic",
          "versions": [
            {
              "status": "affected",
              "version": "\u003c 4.7.0"
            }
          ]
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "value": "Ash Authentication provides authentication for the Ash framework. The confirmation flow for account creation currently uses a GET request triggered by clicking a link sent via email. Some email clients and security tools (e.g., Outlook, virus scanners, and email previewers) may automatically follow these links, unintentionally confirming the account. This allows an attacker to register an account using another user\u2019s email and potentially have it auto-confirmed by the victim\u2019s email client. This does not allow attackers to take over or access existing accounts or private data. It is limited to account confirmation of new accounts only. This vulnerability is fixed in 4.7.0."
        }
      ],
      "metrics": [
        {
          "cvssV3_1": {
            "attackComplexity": "LOW",
            "attackVector": "NETWORK",
            "availabilityImpact": "NONE",
            "baseScore": 5.3,
            "baseSeverity": "MEDIUM",
            "confidentialityImpact": "NONE",
            "integrityImpact": "LOW",
            "privilegesRequired": "NONE",
            "scope": "UNCHANGED",
            "userInteraction": "NONE",
            "vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N",
            "version": "3.1"
          }
        }
      ],
      "problemTypes": [
        {
          "descriptions": [
            {
              "cweId": "CWE-306",
              "description": "CWE-306: Missing Authentication for Critical Function",
              "lang": "en",
              "type": "CWE"
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2025-04-15T22:04:41.667Z",
        "orgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
        "shortName": "GitHub_M"
      },
      "references": [
        {
          "name": "https://github.com/team-alembic/ash_authentication/security/advisories/GHSA-3988-q8q7-p787",
          "tags": [
            "x_refsource_CONFIRM"
          ],
          "url": "https://github.com/team-alembic/ash_authentication/security/advisories/GHSA-3988-q8q7-p787"
        },
        {
          "name": "https://github.com/team-alembic/ash_authentication/commit/99ea38977fd4f421d2aaae0c2fb29f8e5f8f707d",
          "tags": [
            "x_refsource_MISC"
          ],
          "url": "https://github.com/team-alembic/ash_authentication/commit/99ea38977fd4f421d2aaae0c2fb29f8e5f8f707d"
        }
      ],
      "source": {
        "advisory": "GHSA-3988-q8q7-p787",
        "discovery": "UNKNOWN"
      },
      "title": "Ash Authentication email link auto-click account confirmation vulnerability"
    }
  },
  "cveMetadata": {
    "assignerOrgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
    "assignerShortName": "GitHub_M",
    "cveId": "CVE-2025-32782",
    "datePublished": "2025-04-15T22:04:41.667Z",
    "dateReserved": "2025-04-10T12:51:12.279Z",
    "dateUpdated": "2025-04-16T15:36:23.539Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.1"
}

{
  "containers": {
    "adp": [
      {
        "metrics": [
          {
            "other": {
              "content": {
                "id": "CVE-2025-25202",
                "options": [
                  {
                    "Exploitation": "poc"
                  },
                  {
                    "Automatable": "no"
                  },
                  {
                    "Technical Impact": "partial"
                  }
                ],
                "role": "CISA Coordinator",
                "timestamp": "2025-02-11T19:23:49.743379Z",
                "version": "2.0.3"
              },
              "type": "ssvc"
            }
          }
        ],
        "providerMetadata": {
          "dateUpdated": "2025-02-12T20:12:08.180Z",
          "orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
          "shortName": "CISA-ADP"
        },
        "title": "CISA ADP Vulnrichment"
      }
    ],
    "cna": {
      "affected": [
        {
          "product": "ash_authentication",
          "vendor": "team-alembic",
          "versions": [
            {
              "status": "affected",
              "version": "\u003e= 4.1.0, \u003c 4.4.9"
            }
          ]
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "value": "Ash Authentication is an authentication framework for Elixir applications. Applications which have been bootstrapped by the igniter installer present since AshAuthentication v4.1.0 and who have used the magic link strategy _or_ are manually revoking tokens are affected by revoked tokens being allowed to verify as valid. Unless one hase implemented any kind of custom token revocation feature in your application, then one will not be affected. The impact here for users using builtin functionality is that magic link tokens are reusable until they expire. With that said, magic link tokens are only valid for 10 minutes, so the surface area for abuse is extremely low here. The flaw is patched in version 4.4.9. Additionally a compile time warning is shown to users with remediation instructions if they upgrade. 4.4.9 ships with an upgrader, so those who use `mix igniter.upgrade ash_authentication` will have the necessary patch applied. Otherwise, one may run the upgrader manually as described in the error message. As a workaround, delete the generated `:revoked?` generic action in the token resource. This will cause it to use the one internal to Ash Authentication which has always been correct. Alternatively, manually make the changes that are included in the patch."
        }
      ],
      "metrics": [
        {
          "cvssV4_0": {
            "attackComplexity": "HIGH",
            "attackRequirements": "NONE",
            "attackVector": "NETWORK",
            "baseScore": 6.3,
            "baseSeverity": "MEDIUM",
            "privilegesRequired": "NONE",
            "subAvailabilityImpact": "NONE",
            "subConfidentialityImpact": "NONE",
            "subIntegrityImpact": "NONE",
            "userInteraction": "NONE",
            "vectorString": "CVSS:4.0/AV:N/AC:H/AT:N/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"
          }
        }
      ],
      "problemTypes": [
        {
          "descriptions": [
            {
              "cweId": "CWE-269",
              "description": "CWE-269: Improper Privilege Management",
              "lang": "en",
              "type": "CWE"
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2025-02-11T18:28:19.046Z",
        "orgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
        "shortName": "GitHub_M"
      },
      "references": [
        {
          "name": "https://github.com/team-alembic/ash_authentication/security/advisories/GHSA-qrm9-f75w-hg4c",
          "tags": [
            "x_refsource_CONFIRM"
          ],
          "url": "https://github.com/team-alembic/ash_authentication/security/advisories/GHSA-qrm9-f75w-hg4c"
        },
        {
          "name": "https://github.com/team-alembic/ash_authentication/commit/2dee55252df26fe3d990ff1199397cdcf1bfea8a",
          "tags": [
            "x_refsource_MISC"
          ],
          "url": "https://github.com/team-alembic/ash_authentication/commit/2dee55252df26fe3d990ff1199397cdcf1bfea8a"
        }
      ],
      "source": {
        "advisory": "GHSA-qrm9-f75w-hg4c",
        "discovery": "UNKNOWN"
      },
      "title": "Ash Authentication has flawed token revocation checking logic in actions generated by `mix ash_authentication.install`"
    }
  },
  "cveMetadata": {
    "assignerOrgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
    "assignerShortName": "GitHub_M",
    "cveId": "CVE-2025-25202",
    "datePublished": "2025-02-11T18:28:19.046Z",
    "dateReserved": "2025-02-03T19:30:53.401Z",
    "dateUpdated": "2025-02-12T20:12:08.180Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.1"
}