خادم Argo CD MCP — argocd-mcp، المنشور تحت argoproj-labs — تلقّى CVE-2026-82456 في 29 أغسطس 2026 عند 15:30:21 UTC، وصُنّف بدرجة 10.0 في كلٍّ من CVSS 3.1 وCVSS 4.0. وهذه هي الدرجة القصوى التي يسمح بها المقياس. وهي أيضًا، من حيث الجوهر، ليست جديدة.
الإصلاح سبق CVE بـ18 يومًا
نشر القائمون على الصيانة تنبيههم الخاص عن النتيجة نفسها في 11 أغسطس عند 15:47:14 UTC، مع وسم "No known CVE"، وأصدروا الرقعة في v0.9.0 قبل ذلك بخمس عشرة دقيقة، عند 15:32:50 UTC في اليوم نفسه. وقد صنّفوه هم أنفسهم بدرجة 10.0. وسجل 29 أغسطس هو مجرد لحاق نظام الترقيم في الصناعة بإصلاح كان علنيًا منذ أكثر من أسبوعين.
ما لا تقوله الدرجة
هنا يصبح الرقم في العنوان مضللًا. الثغرة — المصنفة CWE-1327، والمرتبطة بالاستماع على عنوان غير مقيّد — تنطبق على الإصدار 0.8.0 عند تشغيله مع HTTP أو SSE transport: إذ كان المستمع يرتبط بجميع الواجهات ويقبل جلسات MCP من دون مصادقة. لكن هذا النقل ليس الخيار الافتراضي الذي يُوجَّه إليه أي مستخدم. أمثلة التثبيت في المشروع تضبط stdio، وهو غير قابل للوصول عبر الشبكة أصلًا. درجة 10.0 تصف أسوأ حالة لتكوين لا تقودك إليه الوثائق.
المشكلة التصميمية الأساسية هي الأهم
يفعل إصدار 0.9.0 ثلاثة أشياء: يربط مستمع HTTP وSSE افتراضيًا بـ 127.0.0.1، ويضيف MCP_AUTH_TOKEN منفصلًا لمصادقة المتصلين الواردين، ويتوقف عن التعامل مع وجود اعتماد خاص بـ Argo CD بوصفه شكلًا من أشكال التحكم في الوصول. وهذه النقطة الأخيرة هي الدرس الحقيقي. إن ARGOCD_API_TOKEN اعتماد صادر — فهو يصادق الخادم إلى Argo CD. ولم يكن يومًا يصادق أي شخص يتصل بالخادم. وقد صدر الإصدار 0.8.0 في 11 يونيو، لذا كان لدى المشغّلين الذين يستخدمون النقل الشبكي 61 يومًا من التعرض.
والسجل مرة أخرى غير قابل للقراءة آليًا
تمامًا كما في تنبيه Skyvern المنشور قبل أربع دقائق، يحمل سجل التنبيه في GitHub الخاص بـ CVE-2026-82456 مصفوفة ثغرات منظمة فارغة — بلا نطاق حزمة، ولا أول إصدار مصحح. وهكذا هبطت في ظهيرة اليوم نفسه نتيجتان بالغة الخطورة أو شبه بالغة الخطورة على بنية وكلاء، ولا يمكن مطابقتها تلقائيًا مع lockfile.