Kyverno הוא הרכיב שאוכף מדיניות באשכולות Kubernetes. בגרסה 1.19.1 יש בו חולשה שמאפשרת למשתמש שהרשאותיו מוגבלות ל-namespace אחד להגיע דרכו אל כל האשכול, ולפי הרשומה להשיג הרשאות של cluster admin. הציון הוא 9.4, והגרסה המתקנת היא 1.19.2.

מה החולשה?

ב-Kubernetes, namespace הוא החלוקה שמפרידה בין צוותים או בין סביבות שיושבים על אותו אשכול: למשתמש יש הרשאות בתוך ה-namespace שלו ולא מחוצה לו. ההפרדה הזאת היא כל ההגנה בסביבה שמשותפת לכמה גורמים.

Kyverno עצמו, לעומת זה, צריך הרשאות רחבות כדי לעשות את עבודתו, ולכן הוא מחזיק ServiceAccount חזק. וכאן נפתח הפער: מדיניות ב-Kyverno יכולה לכלול קריאה ל-API של Kubernetes, בשדה context.apiCall, והקריאה הזאת יוצאת בהרשאות של Kyverno ולא בהרשאות של מי שכתב את המדיניות.

הכשל עצמו הוא אי התאמה בין שני רכיבים שקוראים את אותו נתיב אחרת. לפי הרשומה, Kyverno מנקה את הנתיב שבשדה urlPath ובודק את התוצאה, אבל מריץ בפועל את הנתיב המקורי. הלקוח של Kubernetes, מצידו, מתעלם ממה שמופיע אחרי הסימן # או ?. כלומר מי שכותב מדיניות יכול להסתיר סגמנטים של .. מאחורי אחד הסימנים האלה: הבדיקה רואה נתיב תקין, וההרצה בפועל יוצאת למקום אחר. לסוג הכשל הזה קוראים אי התאמה בפרשנות בין רכיבים, והסיווג שניתן לו הוא CWE-436.

התוצאה היא פנייה אל endpoints ברמת האשכול, בהרשאות של Kyverno. מי שהיה מוגבל ל-namespace אחד מגיע לשליטה בכולם.

מי מושפע?

הרשומה מגדירה טווח צר: מגרסה 1.19.1 ועד לפני 1.19.2. מי שעל 1.19.2 או מאוחרת ממנה אינו בטווח, ומי שעל גרסה שקודמת ל-1.19.1 אינו בטווח של החולשה הזאת.

התנאי המקדים הוא מה שקובע כאן מי חשוף בפועל: צריך להיות משתמש שיכול ליצור Policy. אשכול שבו רק צוות התשתית כותב מדיניות מציב בפני התוקף דרישה נוספת. אשכול שמשותף לכמה צוותים, ושבו לכל צוות יש הרשאה לכתוב מדיניות ב-namespace שלו, הוא בדיוק המצב שהחולשה בנויה עליו.

בישראל זה נוגע לחברות שמריצות Kubernetes בעצמן, בעיקר חברות תוכנה וספקי שירות, ולא למשתמש פרטי. מה שכן, ההפרדה בין namespace-ים היא לעיתים ההנחה שעליה נשענת גם ההפרדה בין לקוחות, וחולשה שמבטלת אותה נוגעת בסוף גם למי שהנתונים שלו יושבים שם.

האם מנוצלת בפועל?

לא ידוע על ניצול. קטלוג ה-KEV של סוכנות הסייבר האמריקאית CISA, שמרכז את החולשות שתוקפים נצפו משתמשים בהן, אינו כולל אותה לפי העדכון האחרון של הרשומה ב-5 בנובמבר 2026.

הרשומה פורסמה באותו יום עצמו, 5 בנובמבר 2026. בחולשה בגיל כזה להיעדר ניצול ידוע אין משמעות רבה.

מה שכן מופיע ברשומה הוא הודעת אבטחה של פרויקט Kyverno ב-GitHub ופרסום של VulnCheck שמתאר את הנתיב. ההסבר הטכני פומבי, והוא מפורט דיו כדי להבין ממנו מה צריך לכתוב בשדה.

מה עושים?

1. עדכנו את Kyverno ל-1.19.2 או מאוחרת ממנה. זאת הגרסה שהרשומה מסמנת כגבול העליון של הטווח הפגיע, וההודעה המלאה נמצאת בהודעת האבטחה של הפרויקט.

2. בדקו מי באשכול יכול ליצור Policy. ההרשאה הזאת היא התנאי המקדים לחולשה, ואם היא נתונה למשתמשים שאינם צוות התשתית, זה המקום לצמצם עד שתעדכנו.

3. עברו על המדיניות שמוגדרת כבר באשכול וחפשו בשדה context.apiCall נתיבים שמכילים .. או את הסימנים # ו-?. הרשומה מתארת בדיוק את הצורה הזאת, ולכן מדיניות שנראית כך היא מה שצריך לבדוק מקרוב.

4. ובדקו את התיעוד של ה-ServiceAccount של Kyverno. אם החולשה נוצלה, הפניות אל endpoints ברמת האשכול יצאו ממנו ולא מהמשתמש שיזם אותן, ולכן זה המקום שבו הפעולה תיראה.