ثغرة Kyverno CVE-2026-124440: حين يصبح محرك السياسات طريقًا للالتفاف إلى صلاحيات مسؤول العنقود

في Kyverno 1.19.1 يمكن لمستأجر مسموح له بكتابة السياسات في مساحة أسماء واحدة الوصول إلى صلاحيات مسؤول العنقود. كيف يعمل الالتفاف وما الذي يجب فحصه قبل الترقية.

تستخدم فرق كثيرة Kyverno للفصل بين مستأجري Kubernetes. فهو يفحص كل كائن وفق السياسات قبل أن يخزّنه خادم API، ويمكنه أن يسمح لمالكي مساحات الأسماء بكتابة سياساتهم الخاصة لمساحات أسمائهم. وتبيّن الثغرة CVE-2026-124440، المنشورة في 8 نوفمبر 2026، كيف يمكن لهذا التفويض أن يفشل. ففي Kyverno 1.19.1، يستطيع مستأجر لا يُسمح له إلا بإنشاء السياسات في مساحة أسمائه أن يجعل Kyverno يعمل خارج تلك المساحة، ثم يصل خطوة بعد خطوة إلى صلاحيات مسؤول العنقود.

الإصلاح متاح منذ 20 أكتوبر في Kyverno 1.19.2، وما زالت العناقيد التي لم تثبّت هذا الإصدار معرّضة للخطر. يشرح هذا المقال ما الخلل الذي وقع، وكيف يجري تصعيد الصلاحيات، وما الذي ينبغي فحصه في عناقيدك.

ما الذي كان يُفترض أن يفعله قيد مساحة الأسماء

تستطيع سياسات Kyverno جلب بيانات من Kubernetes API أثناء تقييم الطلب. وتُسمّى هذه الميزة apiCall: تحدد القاعدة مسارًا في urlPath، فيستدعي Kyverno خادم API، وتدخل النتيجة في القاعدة. ويُجرى الاستدعاء بحساب ServiceAccount الخاص بـ Kyverno، لا بصلاحيات الشخص الذي كتب السياسة.

هذا متوقع في سياسات ClusterPolicy على مستوى العنقود، التي يكتبها مسؤولو المنصة. أما في سياسات Policy على مستوى مساحة الأسماء، التي قد يُسمح للمستأجرين بكتابتها، فهو خطر. وقد أظهرت تنبيهات سابقة (GHSA-c5qq-7g2q-cpqp وGHSA-5qq8-67g6-4h2w) أن Policy على مستوى مساحة الأسماء يمكنها استخدام apiCall لقراءة مساحات أسماء أخرى أو كتابة كائنات على مستوى العنقود. فأضاف Kyverno 1.19.1، الصادر في 10 سبتمبر 2026، “قيدًا لمساحة الأسماء” (namespace clamp): قبل تنفيذ الاستدعاء، يتحقق Kyverno من أن المسار يبقى داخل مساحة أسماء السياسة نفسها.

حيث يفترق الفحص عن التنفيذ

لم يكن القيد في 1.19.1 يفحص السلسلة التي يرسلها فعلًا. فبحسب التنبيه، كان يفك ترميز النسبة المئوية (percent-encoding) في urlPath، ثم يوحّد النتيجة (بحيث تُحلّ مقاطع ..)، ويتحقق من مساحة الأسماء في هذه النسخة المنقّحة. ثم يُرسل الطلب نفسه بالمسار الأصلي الخام.

ينجح ذلك ما دام فك الترميز ناجحًا. لكن إذا احتوى المسار على تسلسل ترميز نسبة مئوية غير صالح، مثل علامة % منفردة في سلسلة استعلام في نهاية المسار، يفشل فك الترميز. وفي هذه الحالة كانت شيفرة 1.19.1 تلجأ إلى فحص السلسلة الخام التي لا تزال مرمّزة. أما خادم API فليس لديه مثل هذا البديل؛ إذ يفك ترميز المسار بالكامل ويوجّه الطلب. وهكذا يرى القيد مساحة أسماء المستأجر نفسه، بينما يرى خادم API مقاطع .. مرمّزة تصعد خارجها، إلى مساحة أسماء أخرى أو إلى مجموعة موارد على مستوى العنقود.

ويؤكد التنبيه أن الأمر يتعلق بفئة من المدخلات، لا بحمولة واحدة. فحظر سلسلة حرفية واحدة لن يسد الثغرة. والإصلاح الدائم هو التحقق من المسار نفسه تمامًا الذي يُنفَّذ.

وهذا ما يفعله 1.19.2. فبحسب قراءتنا لشيفرة 1.19.2 المصدرية، يبني Kyverno الآن صيغة قياسية واحدة للمسار، ويرفض المسارات التي يتعذر تحويلها إلى هذه الصيغة، ويتحقق من مساحة الأسماء على هذه الصيغة، ثم يرسل الصيغة ذاتها إلى خادم API. وهناك مشكلة شقيقة أُصلحت في الإصدار نفسه، هي CVE-2026-122310 (GHSA-3xfv-vq8x-qhg4)، استغلت الانفصال نفسه بين فحص النسخة المنقّحة والطلب الخام عبر إخفاء مقاطع ../ خلف # أو ?. وهي ثغرة CVE مستقلة لها سجلها الخاص.

سلسلة التصعيد خطوة بخطوة

عرض مكتشف الثغرة السلسلة على Kubernetes 1.31 مع Kyverno 1.19.1 المثبّت من مخطط Helm القياسي بالقيم الافتراضية.

1. إنشاء Policy على مستوى مساحة الأسماء. الصلاحية الوحيدة لدى المستأجر هي إنشاء policies.kyverno.io في مساحة أسمائه. وتحتوي السياسة على apiCall يجتاز مساره القيد لكنه يُوجَّه إلى مكان آخر.
2. تفعيلها. إنشاء أي كائن عادي تنطبق عليه السياسة، مثل ConfigMap في مساحة أسماء المستأجر، يجعل Kyverno يقيّم القاعدة وينفّذ الاستدعاء بهوية ServiceAccount التابع لوحدة التحكم في القبول.
3. القراءة عبر مساحات الأسماء. تتيح التقنية نفسها قراءة كائنات في مساحات أسماء أخرى، بما فيها Secrets إذا كان نشر Kyverno مسموحًا له بقراءتها.
4. كتابة webhook على مستوى العنقود. يستطيع ServiceAccount إنشاء MutatingWebhookConfigurations وValidatingWebhookConfigurations، لذا يمكن للمستأجر تسجيل webhook خاص به، يعترض بعد ذلك طلبات القبول ويعيد كتابتها في كل مساحات الأسماء.
5. الوصول إلى صلاحيات مسؤول العنقود. يصف التنبيه استخدام webhook كهذا لتعديل الـ pods المنشأة في kube-system، ومن هناك منح المستأجر صلاحيات cluster-admin. والنتيجة فقدان كامل للسرية والسلامة والتوافر.

لا يلزم أي تفاعل من المستخدم، إذ يعمل الـ webhook مع النشاط العادي للعنقود.

من المتأثر

يذكر سجل CVE أن Kyverno 1.19.1 متأثر وأن 1.19.2 غير متأثر. أما الإصدارات السابقة لـ 1.19.1 فلا تحتوي على هذا الالتفاف تحديدًا، لأنها لا تحتوي على القيد أصلًا. لكنها متأثرة بالتنبيهات السابقة التي كان القيد يهدف إلى معالجتها، ولذلك فإن البقاء على إصدار أقدم ليس بديلًا آمنًا. ويبلغ الخطر ذروته حيث يُسمح لمالكي مساحات الأسماء أو لخطوط CI أو لبوابات الخدمة الذاتية بإنشاء Kyverno Policies.

صدر Kyverno 1.19.2 في 20 أكتوبر 2026، وتسرد ملاحظات إصداره 24 تنبيهًا أمنيًا على GitHub: 9 حرجة و14 عالية الخطورة و1 متوسطة. ويتعلق عدد منها بالتحقق من مسارات API وحصر العمليات داخل مساحة الأسماء. ونُشر هذا التنبيه بعد ثلاثة أيام، في 23 أكتوبر، لكن التنبيه وسجل CVE كليهما يحددان 1.19.2 بوصفه الإصدار المُصلِح. ولكل تنبيه معرّفه الخاص، لذا طابِقها واحدًا تلو الآخر بدلًا من معاملة المجموعة كلها على أنها CVE واحدة.

ما الذي ينبغي فحصه في عناقيدك

أولًا، حدّد إصدار Kyverno الذي يعمل فعليًا، لا الإصدار المذكور في مستودع Git لديك:

kubectl get deployments -n kyverno -o jsonpath='{range .items[*]}{.metadata.name}{"\t"}{.spec.template.spec.containers[*].image}{"\n"}{end}'

إذا كان وسم أي صورة هو v1.19.1، فخطّط للترقية إلى 1.19.2 الآن. ثم افحص أربعة أمور:

• من يستطيع إنشاء Policies على مستوى مساحة الأسماء. اختبر هويات المستأجرين مباشرة، وابحث عن الأدوار التي تمنح صلاحيات على policies.kyverno.io، بما فيها أدوار ClusterRole المجمّعة التي تضيف صلاحيات إلى الدورين المدمجين admin وedit.
• السياسات الحالية التي تستخدم apiCall. اسردها وراجع كل urlPath، ولا سيما المسارات التي تحتوي على % أو .. أو ? أو #.
• إعدادات الـ webhooks. قارن القائمة بما تتوقعه. ينشئ Kyverno الـ webhooks الخاصة به، لذا ركّز على الأسماء التي لا تعرفها وعلى أوقات الإنشاء الحديثة.
• سجلات التدقيق. ابحث عن طلبات صادرة من ServiceAccount التابع لوحدة التحكم في القبول في Kyverno تنشئ إعدادات webhooks أو تقرأ Secrets خارج نمطه المعتاد.

kubectl auth can-i create policies.kyverno.io -n team-a --as=system:serviceaccount:team-a:default
kubectl get policies.kyverno.io -A -o json | jq -r '.items[] | select([.spec.rules[]?.context[]? | select(.apiCall)] | length > 0) | "\(.metadata.namespace)/\(.metadata.name)"'
kubectl get mutatingwebhookconfigurations,validatingwebhookconfigurations -o custom-columns=NAME:.metadata.name,CREATED:.metadata.creationTimestamp

استبدل team-a بمساحات أسماء المستأجرين وهوياتهم لديك. وإذا وجدت webhook لا تستطيع تفسيره على عنقود كان يعمل بالإصدار 1.19.1، فتعامل معه بوصفه حادثًا أمنيًا محتملًا: احفظ سجلات التدقيق قبل أن تحذف أي شيء.

الدرس الأوسع: دقّق في أداة الإنفاذ نفسها

كثيرًا ما تكون وحدات التحكم في القبول ومحركات السياسات والمشغّلات (operators) أعلى المكونات صلاحيةً في العنقود. فهي تحتاج إلى صلاحيات واسعة لأداء عملها، ويتعامل معها المستأجرون كل يوم، مما يجعلها هدفًا مغريًا. وفي هذه الحالة كان نموذج تعدد المستأجرين قائمًا على فحص واحد، وكانت خطوة فك ترميز واحدة عالجها الفحص والطلب بطريقتين مختلفتين كافية لكسره.

في منصات Kubernetes للسحابة الخاصة والمنصات متعددة المستأجرين، تفيد ثلاث عادات. تعامل مع محركات السياسات على أنها جزء من سطح الهجوم، وتابع إصداراتها الأمنية بالدقة نفسها التي تتابع بها إصدار Kubernetes. وامنح حسابات ServiceAccount الخاصة بها الصلاحيات التي تحتاجها فقط، كألا تمنح صلاحية قراءة Secret ما لم تتطلبها سياسة ما. وراجع الميزات التي يمكن للمستأجرين الوصول إليها عبر التفويض، لأن الميزة التي تعمل بصلاحيات المنصة تحوّل مدخلات المستأجر إلى فعل تنفّذه المنصة.

المصادر

• تنبيه Kyverno الأمني GHSA-39w8-hv5g-f73w: تصعيد إلى cluster-admin عبر الالتفاف على قيد مساحة الأسماء في apiCall بالإصدار v1.19.1 باستخدام تسلسل ترميز نسبة مئوية غير صالح
• سجل CVE: CVE-2026-124440
• تنبيه VulnCheck: Kyverno 1.19.1: تصعيد الصلاحيات عبر الالتفاف على قيد مساحة الأسماء في apiCall
• إصلاح ذو صلة في الإصدار نفسه، CVE-2026-122310: تنبيه VulnCheck وGHSA-3xfv-vq8x-qhg4
• ملاحظات إصدار Kyverno v1.19.2: github.com/kyverno/kyverno/releases/tag/v1.19.2