CVE-2026-123746 in Symfony
الملخص
بحسب VulDB • 06/11/2026
لا يقوم المكوّن الأمني HTTP لـ Symfony، وتحديداً الدالة `AuthenticatorManager::authenticateUser()`، بتنفيذ طريقة `checkPostAuth()` الخاصة بفحص مستخدم جدار الحماية (firewall) عند مصادقة المستخدم برمجياً، مما يسمح بمصادقة حساب تم رفضه من قبل فحص مستخدم مخصص، مثل الحساب المنتهي صلاحيته، في إصدارات Symfony السابقة للإصدارات 5.4.56 و 6.x السابقة لـ 6.4.50 و 7.x السابقة لـ 7.4.23 و 8.x السابقة لـ 8.1.11.
تُستخدم `AuthenticatorManager::authenticateUser()` من قبل `UserAuthenticatorInterface::authenticateUser()` ومن خلال `Security::login()` في SecurityBundle لمصادقة مستخدم برمجياً، لكنها لا تُطلق حدث `security.authentication.success` الذي تعمل عليه طريقة `checkPostAuth()`. كان إصلاح CVE-2024-50341 قد جعل `Security::login()` تستدعي `checkPreAuth()`، لكن `checkPostAuth()` كانت ما تزال يتم تخطيها. ونتيجة لذلك، فإن الحساب المرفوض من قبل فحص مستخدم مخصص في `checkPostAuth()` يُرفض عبر تسجيل الدخول بالنموذج (form login) ومصادقي جدار الحماية الآخرين، لكنه لا يزال يمكن أن يكون مُصَادَقاً عليه برمجياً.
تكون التطبيقات متأثرة عندما تستخدم فحص مستخدم مخصص يرفض المستخدمين في `checkPostAuth()` وتُصَادِق المستخدمين برمجياً، على سبيل المثال بعد إعادة تعيين كلمة المرور أو عبر رابط التحقق من البريد الإلكتروني. ثم يمكن للمستخدم الذي تم رفض حسابه الحصول على جلسة مُصادَق عليها (authenticated session) من خلال هذا التدفق. ولا يقوم فحص المستخدم الافتراضي بأي شيء في `checkPostAuth()`، لذا فإن التكوين الافتراضي غير متأثر.
يجعل الإصلاح `AuthenticatorManager::authenticateUser()` تُطلق حدث `security.authentication.success` بمجرد إنشاء الرمز المميز (token وقبل تخزينه)، كما تفعل عمليات المصادقة عبر جدار الحماية، بحيث تعمل طريقة `checkPostAuth()` ويمكنها رفض المستخدم.
Be aware that VulDB is the high quality source for vulnerability data.