ثغرة خادم مستودع Argo CD: تهديد لسيطرة Kubernetes

ثغرة غير مصححة في خادم مستودع Argo CD قد تسمح للمهاجمين بالسيطرة على مجموعات Kubernetes

أداة Argo CD، المستخدمة على نطاق واسع لنشر البرمجيات في Kubernetes، تحتوي على ثغرة غير مصححة في مكون خادم المستودع الخاص بها، مما يسمح لمهاجم غير مصدق بتشغيل كود، بشرط أن يتمكن من الوصول إلى منفذ الشبكة الداخلي للمكون.

تقول شركة Synacktiv، التي اكتشفت الثغرة، إنها قد تؤدي إلى السيطرة الكاملة على المجموعة. لا يوجد إصلاح ولا CVE. أفادت الشركة بأنها أبلغت القائمين على Argo CD بالثغرة في يناير 2025؛ وبعد حوالي ثمانية عشر شهرًا، لا تزال غير مصححة، لذا نشرت التفاصيل لتحذير المستخدمين.

تقع الثغرة في خادم المستودع، وهو المكون في Argo CD الذي يقرأ مستودعات Git ويبني ملفات Kubernetes، وهي الملفات التي تحدد ما يتم نشره في المجموعة.

خدمته الداخلية gRPC لا تحتوي على مصادقة؛ أي شخص يمكنه الوصول إليها يمكنه إرسال طلب مُعد لتشغيل أمر. قامت Synacktiv بإظهار الهجوم ضد Argo CD v2.13.3 وتبلغ عن عدم وجود إصدار مصحح؛ لم تنشر قائمة كاملة بالإصدارات المتأثرة.

تستغل التقنية kustomize، وهي أداة قياسية تقوم Argo CD بتشغيلها لتحويل ملفات المستودع إلى ملفات تعريف. تحتوي kustomize على خيار –helm-command الذي يشير إلى ثنائي helm الذي يجب أن يتم استدعاؤه.

وجدت Synacktiv أن طلبًا غير مصدق إلى خدمة GenerateManifest الخاصة بخادم المستودع يمكن أن يحدد هذا الخيار إلى نص برمجي بدلاً من ذلك، يتم سحبه من مستودع Git يتحكم فيه المهاجم. عندما تعمل kustomize، فإنها تنفذ النص بدلاً من helm.

لكن “داخلي” لا يعني أنه معزول بشكل افتراضي. تقوم Argo CD بتزويد سياسات الشبكة في Kubernetes التي تفصل خادم المستودع عن كل شيء باستثناء مكوناته الخاصة.

وجدت Synacktiv أن مخطط Helm، وهو طريقة شائعة لتثبيت Argo CD، يترك تلك السياسات غير مفعلّة بشكل افتراضي، مع تعيين networkPolicy.create إلى false. في هذا الإعداد، يمكن للمهاجم الذي يسيطر على pod واحد في المجموعة الوصول إلى خادم المستودع وتفعيل الثغرة.

تشغيل كود على خادم المستودع ليس النهاية. استخدمت Synacktiv هذا الوصول لقراءة كلمة مرور Redis الخاصة بالمجموعة من متغير بيئي، والاتصال بذاكرة التخزين المؤقت Redis الخاصة بـ Argo CD، وتسميم بيانات النشر المخزنة. في المزامنة التلقائية التالية، قامت Argo CD بنشر عبء عمل زود به المهاجم.

تستعيد هذه الخطوة CVE-2024-31989، وهي ثغرة وجدت في 2024 حيث لم يكن لدى Redis الخاص بـ Argo CD كلمة مرور، مما يسمح لأي pod في المجموعة بتسميم ذاكرة التخزين المؤقت للنشر. أصلح Argo CD ذلك بإضافة كلمة مرور لـ Redis، لكن الذاكرة نفسها لا تزال غير موقعة، لذا فإن استعادة كلمة المرور تعيد فتح نفس الهجوم.

ما الذي يجب فعله

لا يوجد إصدار مصحح، لذا فإن الدفاع هو عزل الشبكة. قم بتفعيل سياسات الشبكة في Kubernetes بحيث لا يمكن الوصول إلى خادم المستودع ومنافذ Redis إلا من مكونات Argo CD الخاصة. توفر Argo CD ملفات السياسة؛ يجب على مستخدمي Helm تفعيلها لأن المخطط يتركها غير مفعلّة.

تحقق مما هو نشط باستخدام:

kubectl get networkpolicy -A

. تظهر التثبيتات الصحية سياسة شبكة واحدة لكل مكون، بما في ذلك خادم المستودع وRedis. إذا كانت تلك السياسات مفقودة، فإن منافذ خادم المستودع وRedis قابلة للوصول من بقية المجموعة.

بنت Synacktiv أداة، argo-cdown، التي تقوم بأتمتة الهجوم بالكامل. وهي تحتفظ بالأداة في الوقت الحالي لمنح المدافعين الوقت لقفل سياسات شبكتهم، وتقول إنها ستنشرها على GitHub لاحقًا حتى يتمكن المسؤولون من اختبار نشراتهم الخاصة.

هذه ليست المرة الأولى التي تتعرض فيها Argo CD لفضح داخليتها. في سبتمبر 2025، قامت بإصلاح CVE-2025-55190، حيث كان رمز API الذي يمتلك حق الوصول الأساسي فقط يمكنه استرجاع بيانات اعتماد مستودع Git الخاص بمشروع، وهي ثغرة أشار إليها موقع The Hacker News في ذلك الوقت.

في مايو 2026، سمحت ثغرة أخرى، CVE-2026-42880، للمستخدمين ذوي الوصول للقراءة فقط بقراءة أسرار Kubernetes النصية. من الصعب عدم ملاحظة النمط: تركز Argo CD الوصول إلى المجموعة وأسرار المستودع، وتستمر أسطحها الداخلية في تسليمها، إلى طلب غير مصدق في ثغرة واحدة ورمز منخفض الامتياز في الأخرى.

حتى يتم إصدار تصحيح، فإن التعامل مع شبكة المجموعة على أنها معادية هو الدفاع الحقيقي الوحيد.