CVE-2026-65633 in ash_authentication
要約
〜によって VulDB • 2026年08月25日
AshAuthenticationのteam-alembicにおけるImproper Authentication（不適切な認証）脆弱性により、リソースがステートレスなBearerトークン検証を使用している場合、目的限定JWTを完全なBearer API資格情報としてリプレイできしまいます。
AshAuthentication.Plug.Helpers.retrieve_from_bearer/3ヘルパーはAuthorization: Bearer JWTの署名を検証し、act claimを含むトークンを拒否しますが、Bearer境界においてトークンのpurpose claimが"user"と一致するかについてはチェックを行いません。リソースがrequire_token_presence_for_authentication?: false（DSLデフォルト）で構成されている場合、後続するvalidate_token/3ヘルパーはtoken resourceを参照することなく{:ok, nil}を返すため、目的に関する下流のチェックも実行されません。その結果、ライブラリ自体が発行した有効かつ期限切れでないJWT（特にWebAuthnがサインイン時に常に発行し、Password戦略でもsign_inトークンが有効な場合に発行されるpurpose: sign_inトークンなど、狭く単一の目的を持つフロー用）が、汎用のBearer資格情報として直接受け入れられ、完全なcurrent_userの割り当てへと解決されます。
これにより、ライブラリの意図されたトークン交換契約（sign_inトークンは、purpose claimを検証し直ちにトークンを無効化するための準備に対して1回だけ提示されるべきである）が回避されます。まだ交換されていないsign-inトークンがAuthorizationヘッダーで直接提示されると、ステートレスなBearerパスはそれを目的== "user"にスコープしないため、最初の使用が成功します。
攻撃者が対象ユーザーの未交換のsign-inトークンを取得した場合（例えばログやリファラーからの漏洩、傍受されたマジックリンク配信チャネル、または部分的に侵害された中継者経由）、これをBearerトークンとして提示することでそのユーザーとして認証され、意図された1回限りの使用および無効化のセマンティクスを完全に回避できます。攻撃にはさらに、ホストアプリケーションがretrieve_from_bearer/3を利用可能なルートで設定し、WebAuthn（sign_inトークンは常に発行される）またはsign_in_tokens_enabled?: trueを使用するPassword戦略のいずれかが必要です。require_token_presence_for_authentication?: true（v4.5.0以降Igniterインストーラーによってスケルトン化されたアプリケーションを含む）に構成されているリソースや、セッションベースのパス（authenticate_resource_from_session/4）は、保存されたトークンレコードに対してpurpose == "user"を強制するため、影響を受けません。
本問題は、ash_authentication: 3.10.5より前で4.14.2未満、および5.0.0-rc.0から5.0.0-rc.13以前に影響します。
If you want to get best quality of vulnerability data, you may have to visit VulDB.