Strapi is an open source headless content management system. In Strapi versions prior to 5.33.3, changing or resetting a user's password did not invalidate the user's existing refresh-token sessions by default. The refresh-token invalidation step in the users-permissions and admin authentication controllers was conditional on a caller-supplied `deviceId`. When a password change or reset request did not include a `deviceId`, no refresh tokens were revoked, leaving every prior session active. An attacker who had previously obtained a refresh token could continue minting new access tokens after the legitimate user reset their password, allowing persistent unauthorized access for the lifetime of the refresh token (up to 30 days by default). Rotating credentials no longer terminated an active attacker session, defeating password reset as a containment measure. The patch in version 5.33.3 invalidates all refresh tokens associated with the user on every password change and password reset, regardless of whether a `deviceId` is supplied. A new device-scoped session is then issued to the caller as part of the response.
Strapi versions prior to 5.33.3 fail to invalidate refresh tokens when users change or reset passwords if no deviceId is supplied, allowing attackers with previously obtained refresh tokens to maintain unauthorized access for up to 30 days. This critical authentication bypass defeats password reset as a containment measure and enables persistent unauthorized access even after credential rotation. Organizations using Strapi for content management should immediately assess their deployment and implement compensating controls.
IMMEDIATE ACTIONS:
1. Identify all Strapi deployments in your environment and document their versions
2. Isolate or restrict access to Strapi instances running versions prior to 5.33.3
3. Force logout all active user sessions immediately
4. Require all users to change passwords and enable multi-factor authentication
5. Review authentication logs for suspicious refresh token usage patterns
PATCHING GUIDANCE:
1. Upgrade Strapi to version 5.33.3 or later immediately
2. Test upgrades in non-production environments first
3. After patching, invalidate all existing refresh tokens by forcing re-authentication
4. Implement automated patching procedures for future releases
COMPENSATING CONTROLS (if immediate patching not possible):
1. Reduce refresh token lifetime from default 30 days to maximum 7 days in Strapi configuration
2. Implement mandatory re-authentication for sensitive operations
3. Deploy API gateway with token validation and revocation checks
4. Monitor and alert on refresh token usage anomalies
5. Implement IP-based session binding to detect token reuse from different locations
DETECTION RULES:
1. Alert on refresh token usage after password change events
2. Monitor for multiple access tokens generated from single refresh token
3. Track refresh token usage from different IP addresses within short timeframes
4. Alert on refresh token usage beyond 7-day window
5. Monitor authentication logs for password reset events not followed by session termination
الإجراءات الفورية:
1. حدد جميع نشرات Strapi في بيئتك وقثّق إصداراتها
2. عزل أو تقييد الوصول إلى مثيلات Strapi التي تعمل بإصدارات سابقة للإصدار 5.33.3
3. فرض تسجيل الخروج لجميع جلسات المستخدم النشطة فوراً
4. طلب من جميع المستخدمين تغيير كلمات المرور وتفعيل المصادقة متعددة العوامل
5. مراجعة سجلات المصادقة للكشف عن أنماط استخدام رموز التحديث المريبة
إرشادات التصحيح:
1. ترقية Strapi إلى الإصدار 5.33.3 أو أحدث فوراً
2. اختبر الترقيات في بيئات غير الإنتاج أولاً
3. بعد التصحيح، أبطل جميع رموز التحديث الموجودة بفرض إعادة المصادقة
4. تنفيذ إجراءات التصحيح الآلية للإصدارات المستقبلية
عناصر التحكم التعويضية (إذا لم يكن التصحيح الفوري ممكناً):
1. تقليل مدة صلاحية رمز التحديث من 30 يوماً افتراضياً إلى 7 أيام كحد أقصى
2. تنفيذ إعادة مصادقة إلزامية للعمليات الحساسة
3. نشر بوابة API مع التحقق من الرموز والتحقق من الإلغاء
4. مراقبة والتنبيه على شذوذ استخدام رموز التحديث
5. تنفيذ ربط الجلسة القائم على IP للكشف عن إعادة استخدام الرموز من مواقع مختلفة
قواعد الكشف:
1. التنبيه على استخدام رموز التحديث بعد أحداث تغيير كلمة المرور
2. مراقبة توليد رموز وصول متعددة من رمز تحديث واحد
3. تتبع استخدام رموز التحديث من عناوين IP مختلفة في فترات زمنية قصيرة
4. التنبيه على استخدام رموز التحديث بعد نافذة 7 أيام
5. مراقبة سجلات المصادقة لأحداث إعادة تعيين كلمة المرور التي لا تتبعها إنهاء الجلسة