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