كشفت شركة الأمن Synacktiv عن ثغرة غير مُصلّحة في repo-server التابع لـ Argo CD تتيح لمهاجم غير مُوثّق تشغيل الأوامر، ومن هناك السيطرة على عنقود Kubernetes بأكمله. لا يوجد إصدار مُصحّح ولا معرّف CVE. فإذا كان بإمكان قِراب (pod) واحد في عنقودك الوصول إلى المنفذ الداخلي لـ repo-server، فتعامل معه على أنه مهاجم مُوثّق إلى أن تُطبّق العزل الشبكي. هذا هو النوع النادر من الثغرات الذي لا يكون فيه الإصلاح ترقية إصدار، بل قاعدة جدار حماية عليك كتابتها بنفسك.
يُعدّ Argo CD واحدًا من أكثر أدوات GitOps انتشارًا في العالم: فهو يراقب مستودعات Git الخاصة بك، ويبني ملفات Kubernetes التوصيفية (manifests)، ويزامنها مع عناقيدك. وتضعه هذه المهمة في قلب خط أنابيب النشر لديك، وهو بالضبط سبب خطورة ثغرة تنفيذ التعليمات البرمجية هنا.
ما هي ثغرة repo-server في Argo CD؟
تقع الثغرة في repo-server، وهو مكوّن Argo CD الذي يستنسخ مستودعات Git ويعرض الملفات التوصيفية التي تحدّد ما ينشره عنقودك. يُعرّض repo-server خدمة gRPC داخلية، ووفقًا لـ تقرير Synacktiv، فإن إحدى نقاط النهاية — /repository.RepoServerService/GenerateManifest — لا تتطلب أي توثيق على الإطلاق. فأي شخص يستطيع الوصول إلى المنفذ يمكنه إرسال طلب مُصمّم بعناية ينتهي بتنفيذ الأوامر.
الحيلة هي Kustomize. فعندما يعرض repo-server ملفًا توصيفيًا، يمكنه استدعاء Kustomize، الذي يقبل خيار --helm-command الذي يحدّد الملف التنفيذي (binary) الذي سيُشغّل من أجل مخططات Helm. وبالتحكم في حقل BuildOptions ضمن KustomizeOptions في الطلب، يوجّه المهاجم --helm-command نحو سكربته الخاص بدلًا من الملف التنفيذي الحقيقي helm. وقد أثبتت Synacktiv ذلك على Argo CD v2.13.3، بإرسال استدعاء gRPC غير مُوثّق جلب مستودع Git يتحكّم فيه المهاجم ونفّذ السكربت المزروع بامتيازات repo-server. وكما أفاد The Hacker News، فإن نقطة النهاية تُجيب على الطلبات غير المُوثّقة مباشرةً، إذ لا توجد خطوة تسجيل دخول لتجاوزها لأنه لا توجد خطوة تسجيل دخول من الأساس.
كيف يتحوّل الهجوم إلى سيطرة كاملة على العنقود
تنفيذ التعليمات البرمجية على repo-server أمر سيئ بحدّ ذاته، لكن التصعيد إلى السيطرة على العنقود هو ما يجعل هذه الثغرة حرجة. فـ repo-server يحمل REDIS_PASSWORD في بيئته، ويستخدم Argo CD خدمة Redis لتخزين الملفات التوصيفية التي يوشك على نشرها مؤقتًا. وتجري السلسلة على النحو التالي:
- إرسال استدعاء gRPC غير مُوثّق لـ
GenerateManifestمعKustomizeOptionsخبيثة للحصول على تنفيذ الأوامر على repo-server. - قراءة
REDIS_PASSWORDمن البيئة والاتصال بذاكرة التخزين المؤقت Redis التابعة لـ Argo CD. - تسميم مفتاح الملف التوصيفي المُخزّن مؤقتًا (
mfst) بملف Kubernetes توصيفي خبيث، ثم إعادة كتابة مُدخلgit-refsليشير إلى معرّف SHA لالتزام (commit) أقدم. - عندما تعمل المزامنة التلقائية (Auto Sync)، يرى Argo CD ما يظنّه التزامًا جديدًا، فيوفّق الحالة وينشر عبء عمل المهاجم داخل العنقود المستهدف.
عند الخطوة الرابعة لم يعد المهاجم يُشغّل تعليمات برمجية في قِراب واحد، بل ينشر أعباء عمل اعتباطية بأذونات المزامنة التي مُنحت لـ Argo CD، والتي تعني في معظم عمليات التثبيت سيطرة واسعة على العنقود. وتصبح المزامنة التلقائية، وهي ميزة تُفعّلها الفرق تحديدًا لأنها مريحة، آلية التوصيل.
لماذا لا يوجد تصحيح ولا معرّف CVE
هذا هو الجزء المُقلق. تقول Synacktiv إنها أبلغت القائمين على صيانة Argo CD بالثغرة في يناير 2025، وبعد نحو ثمانية عشر شهرًا، عند الكشف العلني في 1 يوليو 2026، لم يكن لدى المشروع الأساسي أي إصدار مُصحّح بعد. ولم يُخصّص أي معرّف CVE للمشكلة الأساسية أيضًا. وموقف القائمين على الصيانة هو أن الخدمة الداخلية لـ repo-server لم تُقصد أبدًا لأن تكون مُعرّضة وينبغي عزلها عبر سياسة شبكية، فمن هذه الزاوية هي فجوة تحصين لا خلل برمجي يُصحّح.
المشكلة هي الإعدادات الافتراضية. فمخطط Helm الرسمي يُشحن بتلك السياسات الشبكية معطّلة، بحيث يترك التثبيت القياسي القائم على Helm منافذ repo-server وRedis قابلة للوصول من قِبل أي قِراب في مساحة الأسماء. ويتتبّع تحذير مخطط Helm المرتبط (GHSA-47m3-95c7-g2g8) جانب التحزيم، لكن إذا نشرت Argo CD باستخدام Helm ولم تلمس السياسات الشبكية أبدًا، فأنت شبه مؤكد مُعرّض للخطر الآن.
لماذا تُعدّ بنية GitOps «المستوى صفر»
الدرس الأعمق، والسبب الذي جعل هذا يحظى بكل هذا الاهتمام، هو ماهيّة Argo CD نفسه. فلديه صلاحية القراءة لمستودعاتك الخاصة، وصلاحية الكتابة والمزامنة لعناقيدك، وهو يحمل أسرار النشر. فإن اخترقته لن تخترق تطبيقًا واحدًا فحسب، بل ستمتلك خط الأنابيب الذي يشحن كل تطبيق.
وكتب المحلل Devashri Datta في CSO Online بصراحة: «محرّكات GitOps ليست خدمات مساعِدة؛ إنها مكوّنات مستوى صفر في مستوى التحكّم»، و«أي قِراب يستطيع الوصول إليه يصبح مكافئًا لمهاجم مُوثّق». وصاغت Sakshi Grover من IDC السؤال الدفاعي على أنه سؤال عن مسارات الهجوم لا عن المحيط: احسب «أي أعباء العمل يمكنها التواصل مع مستوى تحكّم Argo CD» وما إذا كانت «توجد علاقات ثقة غير ضرورية» بين قِرابات التطبيقات العادية ومحرّك GitOps لديك. وخلاصة الأمر أن التعرّض للإنترنت لم يكن أبدًا نموذج التهديد الصحيح هنا، بل الحركة الجانبية من قِراب واحد مُخترق.
هذه العقلية — عدم الوثوق بحركة المرور الداخلية افتراضيًا، وتجزئة كل شيء — هي نفسها العقلية وراء التحوّل الذي غطّيناه في الثقة الصفرية مقابل VPN في 2026. فالسياسات الشبكية هي التجزئة الدقيقة (microsegmentation) مُطبّقة داخل العنقود.
كيف تحمي عنقودك الآن
مع عدم وجود تصحيح للتثبيت، يكون الدفاع هو العزل الشبكي. يشحن Argo CD ملفات السياسات؛ وعلى مستخدمي Helm فقط تفعيلها.
1. تحقّق مما إذا كنت مُعرّضًا. اسرد السياسات الشبكية عبر مساحة أسماء Argo CD الخاصة بك:
kubectl get networkpolicy -n argocd
إذا لم يُرجع ذلك شيئًا (أو لم تُرجع أي سياسة تغطّي argocd-repo-server)، فإن كل قِراب يستطيع التوجيه إلى مساحة الأسماء يمكنه الوصول إلى منفذ gRPC غير المُوثّق. تلك هي الحالة المُعرّضة.
2. طبّق السياسة الشبكية لـ repo-server. يوفّر Argo CD الملف argocd-repo-server-network-policy.yaml، الذي يقيّد الدخول (ingress) على المنفذ 8081 على المُستدعِين الداخليين الشرعيين فقط — خادم API، ووحدة التحكم بالتطبيقات (application controller)، ووحدة تحكم مجموعات التطبيقات (applicationset controller)، ووحدة تحكم الإشعارات (notifications controller). طبّق المجموعة الكاملة من سياسات Argo CD الشبكية (repo-server وRedis وغيرها) من الإصدار المطابق لتثبيتك، أو فعّلها في قيم Helm الخاصة بك إن كنت تنشر بتلك الطريقة.
3. تحقّق. أكّد أن السياسات باتت موجودة لكل مكوّن، بما في ذلك repo-server وRedis:
kubectl get networkpolicy -A | grep argocd
4. قلّل نطاق الضرر. تعامل مع مساحة أسماء Argo CD على أنها مستوى صفر: حُدّ من أعباء العمل التي تشاركها، وحصر أذوناتها على العنقود بما تحتاجه للمزامنة فقط، ودقّق في إمكانية الوصول إلى RepoServerService بالطريقة نفسها التي تدقّق بها في واجهة برمجة تطبيقات إدارية. وإن لم تكن بحاجة ماسّة إلى المزامنة التلقائية على التطبيقات الحسّاسة، فتعطيلها يزيل المسار المُؤتمت من تسميم ذاكرة التخزين المؤقت إلى النشر.
التعرّض في لمحة
| النشر | السياسات الشبكية | هل repo-server قابل للوصول من أي قِراب؟ | الإجراء |
|---|---|---|---|
| مخطط Helm، الإعدادات الافتراضية | معطّلة | نعم — مُعرّض | فعّل السياسات الآن |
| ملفات توصيفية، دون إضافة سياسات | معطّلة | نعم — مُعرّض | طبّق السياسات المُوفّرة |
| سياسات مُطبّقة ومُتحقّق منها | مُفعّلة | لا — مقصورة على مكوّنات Argo | أبقِها، ودقّق |
| المزامنة التلقائية على تطبيقات حسّاسة | غير منطبق | تُتيح تسميم الذاكرة ← النشر | فكّر في تعطيلها |
هذا صيانة لمستوى التحكّم أكثر منه استجابة للحوادث، وهو يقترن بأساسيات إحكام إغلاق أي جهاز تُشغّله — الانضباط نفسه المتّبع في الساعة الأولى الآمنة على خادم VPS جديد. وإن كنت تستضيف مجموعتك التقنية ذاتيًا، فإن دليل الاستضافة الذاتية خطوة بخطوة مكان جيد لبناء هذه العادات منذ البداية.
الأسئلة الشائعة
ما هو repo-server في Argo CD؟ هو مكوّن Argo CD الذي يستنسخ مستودعات Git الخاصة بك ويحوّلها إلى ملفات Kubernetes توصيفية — أي الملفات الفعلية التي تُخبر العنقود بما ينشره. يعمل كخدمة داخلية ويُعرّض واجهة gRPC على المنفذ 8081 تستدعيها مكوّنات Argo CD الأخرى؟
هل يوجد تصحيح أو معرّف CVE لهذه الثغرة؟ لا. اعتبارًا من كشف 1 يوليو 2026 لا يوجد إصدار مُصحّح من نواة Argo CD ولا معرّف CVE للمشكلة الأساسية. يتعامل القائمون على الصيانة مع الخدمة الداخلية على أنها شيء يجب عليك عزله بالسياسات الشبكية؛ ويغطّي تحذير منفصل لمخطط Helm (GHSA-47m3-95c7-g2g8) الإعدادات الافتراضية للتحزيم؟
هل أنا متأثّر إن ثبّتُّ Argo CD باستخدام Helm؟
على الأرجح، ما لم تُفعّل السياسات الشبكية صراحةً. فمخطط Helm الرسمي يُشحن وهي معطّلة، ما يترك منافذ repo-server وRedis قابلة للوصول من قِبل أي قِراب في مساحة الأسماء. شغّل kubectl get networkpolicy -n argocd للتحقق؟
هل يحتاج المهاجم إلى الوصول عبر الإنترنت إلى عنقودي؟ لا، وهذا هو بيت القصيد. فالتهديد داخلي: أي قِراب يستطيع الوصول إلى منفذ gRPC الخاص بـ repo-server يمكنه إرسال الطلب غير المُوثّق. يكفي عبء عمل واحد مُخترق أو خبيث داخل العنقود، ولذا فالإصلاح هو التجزئة، لا مجرد جدار حماية عند الحافة؟
هل Argo CD مخصّص لـ Kubernetes فقط؟ نعم. Argo CD هو أداة تسليم مستمر تعريفية قائمة على GitOps مبنية خصّيصًا لـ Kubernetes؛ فهو يوفّق حالة العنقود الحيّة مع الملفات التوصيفية المُخزّنة في Git. وهذا الاقتران الوثيق هو سبب تحوّل اختراق repo-server بهذه المباشرة إلى اختراق للعنقود؟
Sources
- Synacktiv — تنفيذ التعليمات البرمجية عن بُعد غير المُوثّق في Argo CD باستخدام CodeQL: الكشف التقني الأساسي، ونقطة النهاية، وإساءة استخدام
--helm-commandفي Kustomize، وسلسلة تسميم ذاكرة Redis المؤقتة، والتخفيف عبر السياسة الشبكية. - The Hacker News — ثغرة repo-server غير المُصلّحة في Argo CD قد تتيح للمهاجمين السيطرة على عناقيد Kubernetes: ملخّص للثغرة، ونقطة نهاية gRPC غير المُوثّقة، والجدول الزمني للكشف.
- CSO Online — ثغرة Argo CD تُظهر لماذا ينبغي التعامل مع بنية GitOps على أنها مستوى صفر: تحليل خبير عن GitOps كمستوى تحكّم صفري والتفكير القائم على مسارات الهجوم.
- GitHub — argoproj/argo-cd: مشروع Argo CD، والتحذيرات الأمنية، وملفات السياسات الشبكية المُوفّرة.
وقاص احمد وسیر
وقاص احمد وسیر مطوّر ومهندس أتمتة بخبرة تزيد على 8 سنوات في بناء أنظمة إنتاجية يستخدمها أكثر من 100 ألف شخص. يبني تطبيقات SaaS متعددة المستأجرين، وأتمتة بالذكاء الاصطناعي (n8n، تدفقات LLM، بوتات واتساب)، وبنية استضافة (WHM/cPanel، CloudLinux) — وهو صانع WaSphere وFlowMaticX وعلامة الاستضافة WaseerHost. أنجز أكثر من 100 مشروع لشركات صغيرة ومتوسطة ووكالات وشركات ناشئة ممولة.
