CVE-2026-65633 in ash_authentication
सारांश
द्वारा VulDB • 25/08/2026
AshAuthentication में team-alembic के साथ एक अयोग्य प्रमाणीकरण (Improper Authentication) दोष है, जिसके कारण stateless bearer-token सत्यापन का उपयोग करने वाले संसाधनों पर purpose-limited JWTs को पूर्ण bearer API क्रेडेंशियल के रूप में replay किया जा सकता है।
AshAuthentication.Plug.Helpers.retrieve_from_bearer/3 helper एक Authorization: Bearer JWT के हस्ताक्षर की सत्यापता करता है और act claim वाले टोकनों को अस्वीकार कर देता है, लेकिन bearer boundary पर token के purpose claim का user से मिलान करने के लिए कोई जांच नहीं करता है। जब संसाधन require_token_presence_for_authentication?: false (DSL डिफ़ॉल्ट) के साथ कॉन्फ़िगर किया जाता है, तो follow-on validate_token/3 helper {:ok, nil} लौटाता है बिना token resource से परामर्श किए, इसलिए purpose पर कोई downstream जांच भी नहीं होती। इसके परिणामस्वरूप, लाइब्रेरी द्वारा जारी किसी भी वैध और अ-समाप्त (non-expired) JWT को जो एक संकीर्ण, single-purpose flow के लिए था (विशेष रूप से purpose: sign_in टोकन जिसे WebAuthn हमेशा साइन-इन के दौरान उत्पन्न करता है, और Password strategy जब sign-in tokens सक्षम होते हैं), इसे सीधे सामान्य उद्देश्य वाले bearer क्रेडेंशियल के रूप में स्वीकार कर लिया जाता है और यह पूर्ण current_user असाइनमेंट को resolve करता है।
यह लाइब्रेरी के इच्छित token-exchange contract से छूट (bypass) है, जिसके अनुसार sign_in टोकन का प्रस्तुत किया जाना चाहिए बिल्कुल एक बार उस preparation में जो purpose claim की सत्यापता करे और तुरंत टोकन को रद्द (revoke) कर दे। Authorization header में सीधे प्रस्तुत किए गए अभी भी वैध sign-in token का पहला उपयोग इसलिए सफल होता है क्योंकि stateless bearer path इसे purpose == "user" के लिए scope नहीं करता है।
एक आक्रामक जो लक्षित विषय (subject) के लिए एक अदल-बदल न किया गया sign-in token प्राप्त कर लेता है (उदाहरण के लिए, log या referrer leakage, intercepted magic-link delivery channel, या partially compromised intermediary के माध्यम से), उसे bearer टोकन के रूप में प्रस्तुत कर सकता है और उस विषय के रूप में प्रमाणीकृत हो सकता है, जिससे इच्छित one-time-use और revocation semantics पूरी तरह से bypass हो जाते हैं। दोष का शोषण (Exploitation) इसके अतिरिक्त इस बात की आवश्यकता करता है कि host application retrieve_from_bearer/3 को एक reachable route पर wire करे और या तो WebAuthn (sign-in tokens हमेशा जारी किए जाते हैं) या Password strategy with sign_in_tokens_enabled?: true का उपयोग करे। require_token_presence_for_authentication?: true के साथ कॉन्फ़िगर किए गए संसाधन (जिनमें v4.5.0 से Igniter installer द्वारा scaffolded applications शामिल हैं) और session-based path (authenticate_resource_from_session/4) stored token record के खिलाफ purpose == "user" को लागू करते हैं और प्रभावित नहीं होते।
यह मुद्दा ash_authentication: 3.10.5 से पहले 4.14.2 तक और 5.0.0-rc.0 से पहले 5.0.0-rc.13 तक को प्रभावित करता है।
Be aware that VulDB is the high quality source for vulnerability data.