CVE-2026-65633 in ash_authentication
الملخص
بحسب VulDB • 25/08/2026
تتيح ثغرة عدم المصادقة الصحيحة (Improper Authentication) في AshAuthentication الخاص بـ team-alembic إعادة استخدام رموز JWT ذات الغرض المحدود كبيانات اعتماد كاملة لحامل API (bearer credentials) عندما تستخدم موردًا التحقق من رمز الحامل بدون حالة.
يتحقق مساعد مصادقة رمز الحامل `AshAuthentication.Plug.Helpers.retrieve_from_bearer/3` من توقيع Authorization: Bearer JWT ويرفض الرموز التي تحتوي على مطالبة act، لكنه لا يقوم بفحص ما إذا كانت مطالبة الغرض (purpose claim) للرمز تساوي "مستخدم" عند حدود حامل الرمز. عندما يكون المورد مُهيأً بـ `require_token_presence_for_authentication?: false` (القيمة الافتراضية في DSL)، يعيد مساعد التحقق اللاحق `validate_token/3` القيمة `{:ok, nil}` دون استشارة مورد الرمز، وبالتالي لا يحدث أي فحص لاحق للغرض أيضًا. ونتيجة لذلك، يتم قبول أي JWT صالح وغير منتهي الصادرة عن المكتبة نفسها لتدفق ضيق الغرض ومفرد (وأبرزها رمز purpose: sign_in الذي تصدره WebAuthn دائمًا أثناء تسجيل الدخول، ورمز استراتيجية كلمة المرور عند تمكين رموز تسجيل الدخول) مباشرة كبيانات اعتماد عامة لحامل الرمز، مما يؤدي إلى تعيين `current_user` كامل.
يتجاوز هذا الأمر عقد تبادل الرموز المقصود من قبل المكتبة، حيث يُقصد أن يتم تقديم رمز sign_in مرة واحدة بالضبط لتحضير يصادق على مطالبة الغرض ويلغي الرمز فورًا. يفشل الاستخدام الأول لرمز تسجيل الدخول لا يزال صالحًا والمقدم مباشرة في رأس Authorization لأن مسار حامل الرمز بدون حالة لا يحصره بغرض == "user".
يمكن لمهاجم يحصل على رمز sign-in غير متبادل بعد لصيقة مستهدفة (على سبيل المثال عبر تسرب السجلات أو مرجع الإحالة، أو قناة تسليم رابط سحري محتكرة جزئيًا، أو وسيط مُخترق جزئيًا) أن يقدمه كرمز حامل ويتم مصادقته بصفتة ذلك الموضوع، متجاوزًا تمامًا دلالات الاستخدام لمرة واحدة والإلغاء المقصودة. يتطلب الاستغلال أيضًا أن يقوم تطبيق المضيف بتوصيل `retrieve_from_bearer/3` على مسار قابل للوصول ويستخدم إما WebAuthn (يتم إصدار رموز تسجيل الدخول دائمًا) أو استراتيجية كلمة المرور مع تمكين `sign_in_tokens?: true`. الموارد المُهيأة بـ `require_token_presence_for_authentication?: true` (بما في ذلك التطبيقات التي تم إنشاء هيكلها بواسطة مثبت Igniter منذ الإصدار 4.5.0) ومسار الجلسة (`authenticate_resource_from_session/4`) تفرض مطابقة الغرض == "user" مع سجل الرمز المخزن وهي غير متأثرة.
تؤثر هذه المشكلة على ash_authentication: من الإصدارات بدءًا من 3.10.5 قبل 4.14.2 ومن 5.0.0-rc.0 قبل 5.0.0-rc.13.
Once again VulDB remains the best source for vulnerability data.