An issue was discovered in OpenStack Keystone 13 through 29. POST /v3/credentials did not validate that the caller-supplied project_id for an EC2-type credential matched the project of the authenticating application credential. This allowed an attacker holding an unrestricted application credential for project A to create an EC2 credential targeting project B; a subsequent /v3/ec2tokens exchange would then issue a Keystone token scoped to project B while still carrying the original app_cred_id, enabling cross-project lateral movement within the credential owner's role footprint.
OpenStack Keystone versions 13-29 contain an authorization bypass vulnerability (CVE-2026-43001) allowing attackers with unrestricted application credentials to create EC2 credentials targeting arbitrary projects, enabling cross-project lateral movement and privilege escalation. This critical flaw affects cloud infrastructure deployments across Saudi Arabia's government and enterprise sectors. Immediate patching is required as exploits are publicly available.
IMMEDIATE ACTIONS:
1. Identify all OpenStack Keystone deployments (versions 13-29) in your infrastructure
2. Restrict application credential usage to essential services only
3. Implement network segmentation between projects
4. Enable comprehensive audit logging for credential creation and EC2 token exchanges
PATCHING:
1. Apply OpenStack Keystone security patches (version 30+) immediately
2. Test patches in non-production environments first
3. Coordinate patching with cloud operations teams to minimize downtime
COMPENSATING CONTROLS (if patching delayed):
1. Implement API gateway rules to block POST /v3/credentials requests with mismatched project_id values
2. Deploy WAF rules to detect and block EC2 token exchanges with suspicious project scope changes
3. Enforce strict RBAC policies limiting application credential creation permissions
4. Implement real-time monitoring for cross-project credential usage patterns
DETECTION:
1. Monitor Keystone logs for POST /v3/credentials with project_id mismatches
2. Alert on EC2 token exchanges where app_cred_id project differs from requested token scope
3. Track application credentials with unrestricted permissions
4. Implement SIEM rules: (keystone_event=credential_created AND source_project != target_project)
الإجراءات الفورية:
1. تحديد جميع نشرات OpenStack Keystone (الإصدارات 13-29) في البنية التحتية الخاصة بك
2. تقييد استخدام بيانات اعتماد التطبيق للخدمات الأساسية فقط
3. تنفيذ تقسيم الشبكة بين المشاريع
4. تفعيل تسجيل التدقيق الشامل لإنشاء بيانات الاعتماد وتبادلات رموز EC2
التصحيح:
1. تطبيق تصحيحات أمان OpenStack Keystone (الإصدار 30+) فوراً
2. اختبار التصحيحات في بيئات غير الإنتاج أولاً
3. تنسيق التصحيح مع فرق عمليات السحابة لتقليل وقت التوقف
الضوابط البديلة (إذا تأخر التصحيح):
1. تنفيذ قواعد بوابة API لحظر طلبات POST /v3/credentials بقيم project_id غير متطابقة
2. نشر قواعد WAF للكشف عن تبادلات رموز EC2 المريبة وحظرها
3. فرض سياسات RBAC صارمة تحد من أذونات إنشاء بيانات اعتماد التطبيق
4. تنفيذ المراقبة في الوقت الفعلي لأنماط استخدام بيانات الاعتماد عبر المشاريع
الكشف:
1. مراقبة سجلات Keystone لـ POST /v3/credentials مع عدم تطابق project_id
2. التنبيه على تبادلات رموز EC2 حيث يختلف project بيانات app_cred عن نطاق الرمز المطلوب
3. تتبع بيانات اعتماد التطبيق ذات الأذونات غير المقيدة
4. تنفيذ قواعد SIEM: (keystone_event=credential_created AND source_project != target_project)