בהיררכיה של פגיעויות האינטרנט המודרניות, הזרקת תלות (DI) הזרקת מכולה נמצא בראש שרשרת המזון. הוא קשה יותר לאיתור מאשר הזרקת SQL, אלגנטי יותר משחיתות זיכרון, והשפעתו הרסנית.
הגילוי האחרון של CVE-2025-32432 מיקוד Craft CMS—ובהרחבה, הבסיס מסגרת Yii2—מהווה תזכורת אכזרית: כאשר קלט המשתמש שולט ביצירת מופעים של מחלקות, היישום שייך לתוקף. בעוד סורקים אוטומטיים רבים סיווגו בתחילה את התופעה כ"הקצאה המונית" או "בעיית תצורה" בדרגת חומרה נמוכה, מהנדסי אבטחה מובחרים מזהים אותה כמות שהיא באמת: ביצוע קוד מרחוק (RCE) באמצעות לוגיקת דה-סריאליזציה של אובייקטים לא מאובטחים.
מאמר זה מבצע ניתוח טכני של הפגיעות. נלך מעבר להודעת הספק כדי לשחזר את שרשרת הגאדג'טים, לנתח את שיטות ה-PHP הקסומות שבבסיסן ולהדגים מדוע ניתוח סמנטי מבוסס בינה מלאכותית הוא הדרך היחידה האפשרית לאתר פגמים לוגיים אלה בקנה מידה נרחב.

ארכיטקטורת הכישלון: מבט מבפנים על מאתר השירותים של Yii2
כדי להבין את CVE-2025-32432, עליך להבין תחילה את ליבת הארכיטקטורה של מסגרת Yii2: yii\\di\\מכל.
Craft CMS מסתמך במידה רבה על תבנית Service Locator של Yii2 ומכל Dependency Injection לניהול תלות בין מחלקות. כדי להפוך את הפיתוח לגמיש, המכל מאפשר למפתחים להגדיר אובייקטים באמצעות מערך תצורה. תכונה זו היא הגורם העיקרי לפגיעות.
ה-Sink "CreateObject"
הנקודה הקריטית בפגיעות מסוג זה היא Yii::createObject(). שיטה זו מקבלת מערך תצורה שבו כיתה המפתח קובע איזה מחלקה PHP ליצור, והמפתחות הבאים מגדירים את המאפיינים הציבוריים של אותו מופע.
PHP
// שימוש לגיטימי בקוד האחורי של Craft CMS $object = Yii::createObject([ 'class' => 'app\\models\\User', 'username' => 'admin', 'role' => 'superuser' ]);
הפגיעות (CVE-2025-32432) נובעת מכך שפעולות בקר ספציפיות ב-Craft CMS (הקשורות לעתים קרובות לשמירת תצורת תוספים או לטיפול בטיוטות) מקבלות קלט JSON גולמי מבקשת HTTP ומעבירות אותו באופן עיוור למאגר זה.
הפגם הלוגי:
- מקור: המשתמש שולח
POST /api/v1/plugin-configעם גוף JSON. - זרימה: הבקר מפענח את ה-JSON למערך PHP.
- כיור: המערך מועבר ל
Yii::createObject($requestData). - תוצאה: התוקף מגדיר את
כיתה, הממיר הזרקת נתונים ל הזרקת אובייקטים.

בניית שרשרת ההרג: ציד הגאדג'טים
בניצול PHP, היכולת ליצור מופע של מחלקה היא חסרת תועלת, אלא אם כן אותה מחלקה עושה משהו מעניין במהלך מחזור החיים שלו. אנו זקוקים ל גאדג'ט.
גאדג'ט הוא מחלקה המבצעת פעולות רגישות (כתיבת קבצים, ביצוע פקודות, שאילתות מסד נתונים) בשיטות הקסם שלה (__construct, __destruct, __wakeup, __toString) או שיטות אתחול (init). מכיוון ש-Craft CMS כולל את כל מערכת האקולוגיות של Yii2 וספריות ספקים ענקיות (Guzzle, Monolog וכו'), שדה הגאדג'טים הוא פורה.
הגאדג'ט העיקרי: yii\\rest\\IndexAction
בהקשר של CVE-2025-32432, שרשרת הגאדג'טים האמינה ביותר מנצלת yii\\rest\\IndexAction. מחלקה זו נועדה לרשום מודלים עבור REST API, אך יש לה מאפיין ספציפי: בדוק גישה.
ה בדוק גישה המאפיין נועד להכיל פונקציה הניתנת להפעלה לבדיקת הרשאות. עם זאת, מכיוון שאנו שולטים בערכי המאפיין באמצעות מיכל DI, אנו יכולים להפוך זאת ל- פרימיטיב ביצוע החזרה.
המטען המשמש כנשק (PoC)
להלן מטען Proof of Concept (PoC) משוחזר. מבנה JSON זה, כאשר הוא מעובד על ידי נקודת הקצה הפגיעה, מפעיל RCE.
JSON
{ "action": "save-config", "config": { "class": "yii\\\\rest\\\\IndexAction", "id": "rce_trigger", "controller": { "class": "yii\\\\web\\\\Controller", "id": "dummy_controller" }, "modelClass": "yii\\\\base\\\\Model", "checkAccess": "system", "run": "id; uname -a; cat /etc/passwd" } }
זרימת ביצוע שלב אחר שלב:
- יישום: מכל ה-DI רואה
class: yii\\rest\\IndexAction. הוא משתמש ב-Reflection כדי ליצור מופע של מחלקה זו. - אוכלוסיית הנכס: המכל חוזר על המפתחות.
- זה קובע
$indexAction->checkAccess = 'system'. - הוא מייצר באופן רקורסיבי מופע של
בקר דמה(נדרש על ידיאינדקס פעולה).
- זה קובע
- הפעלת המלכודת: רוב רכיבי Yii2 קוראים
init()אוהפעל()במהלך מחזור החיים שלהם. בנתיב ניצול ספציפי זה, הלוגיקה של היישום בסופו של דבר מפעילה את הפעולה. - ביצוע החזרה: בתוך
IndexAction::run(), הקוד בודק אםבדוק גישההוגדר.PHP// לוגיקה פנימית של yii\\rest\\IndexAction if ($this->checkAccess) { call_user_func($this->checkAccess, $this->id, $params); } - RCE: PHP מבצע
system('rce_trigger', ...)? לא, התוקף חייב ליישר את הארגומנטים. על ידי מניפולציה של מאפיינים פנימיים המועברים כארגומנטים לפונקציית הקריאה החוזרת, התוקף משיגsystem('id; ...').
הערה: תוקפים מתקדמים ישלבו זאת עם yii\\caching\\FileCache גאדג'טים לכתיבת מעטפת אינטרנט PHP קבועה (לדוגמה, shell.php) ל-webroot הציבורי (/web/assets/), תוך עקיפת מגבלות ביצוע זמניות.
מדוע סורקים ישנים נכשלים
איתור CVE-2025-32432 הוא סיוט עבור כלי בדיקת אבטחת יישומים דינמית (DAST) מסורתיים.
- עיוורון תחבירי: המטען הוא JSON תקין מבחינה תחבירית. הוא אינו מכיל אסימוני SQL (
' או 1=1) או וקטורי XSS (<script>). WAFs המוגדרות כברירת מחדל ל-OWASP Top 10 בדרך כלל יאפשרו זאת. - עיוורון קונטקסטואלי: סורק רואה אובייקט JSON. הוא אינו מבין שהמפתח
כיתהיש משמעות סמנטית למסגרת ה-PHP האחורית. עבור סורק,כיתההוא רק שדה נתונים נוסף כמושם משתמשאודוא"ל. הוא אינו יכול להסיק את הפעלת אובייקט תופעת לוואי.
זיהוי מבוסס בינה מלאכותית: היתרון של Penligent
זה המקום שבו Penligent.ai מייצג שינוי פרדיגמה בבדיקות אבטחה התקפיות. Penligent חורג מהתאמת תבניות כדי להשתמש ב ניתוח סמנטי המותאם להקשר.
- טביעת אצבע של מסגרת ומיפוי לוגי
סוכני ה-AI של Penligent מזהים תחילה את מערך הטכנולוגיה הבסיסי (Craft CMS / Yii2). חשוב לציין שה-AI "מכיר" את נקודות התורפה המסוכנות הספציפיות למסגרת זו. הוא מבין שב-Yii2, Yii::createObject הוא נקודת בקרה קריטית, בדיוק כמו pickle.load ב-Python או unserialize ב-PHP גנרי.
- בדיקה חכמה (Fuzzing with Intent)
במקום לרסס באופן עיוור תווים אקראיים, Penligent בונה בדיקות לוגיות.
- בדיקה 1: להזריק
{"class": "yii\\\\helpers\\\\VarDumper"}. - תצפית: האם זמן התגובה משתנה? האם הודעת השגיאה מתייחסת ל-"VarDumper"?
- הסקת מסקנות: אם היישום מנסה לטעון את המחלקה, ה-AI מאשר שה-
כיתההפרמטר מפורש על ידי מיכל ה-DI.
- אימות לא הרסני
לאחר אימות וקטור ההזרקה, Penligent אינו צריך לבצע rm -rf / כדי להוכיח את הפגיעות. הוא יכול ליצור שרשרת גאדג'טים תמימה (למשל, כזו שמבצעת פשוט חיפוש DNS למאזין מחוץ לתחום) כדי להוכיח את יכולת ה-RCE בוודאות של 100% וללא סיכון לתשתית הייצור. כך צוותי האבטחה יכולים לאמת את התיקונים CVE-2025-32432 מבלי לשבש את פעילות העסק.
פגיעויות בעלות השפעה רבה
כדי להבין היטב את תמונת האיומים, מהנדסי אבטחה צריכים לקשר בין CVE-2025-32432 לבין תקדימים היסטוריים. המכניקה של הזרקת מיכלים אינם ייחודיים ל-Craft CMS.
| מזהה CVE | תוכנת Target | מנגנון טכני |
|---|---|---|
| CVE-2023-41892 | Craft CMS | RCE באמצעות ImageMagick לוגיקת יצירת מופעים של אובייקטים ב- תנאים פרמטר. |
| CVE-2019-15488 | מסגרת Yii2 | אי-אבטחת דה-סריאליזציה ב- yii\\db\\BatchQueryResult __wakeup שיטה. |
לפגיעות אלה יש מכנה משותף: האמון בסוגי הקלט.
תיקון והגנה מעמיקה
הפחתת CVE-2025-32432 דורשת גישה רב-שכבתית הכוללת תיקוני קוד, חיזוק תצורה והגנה בזמן ריצה.
1. תיקון ברמת הקוד (הגורם השורשי)
הפתרון הסופי הוא לאכוף בדיקת סוג קפדנית. מפתחים לעולם אינם רשאים להעביר מערכים של קלט משתמש גולמי ישירות ל- Yii::createObject.
- רשימת החסימות: בטל במפורש את ההגדרה
כיתהמפתח ממערך הקלט לפני העיבוד. - רשימת ההיתרים: אם יש צורך ביצירת מופעים דינמיים, יש לאמת את המחלקה המבוקשת מול רשימה קבועה ומוגדרת מראש של מחלקות בטוחות.
PHP
// יישום מאובטח $config = json_decode($json, true); unset($config['class']); // מניעת הזרקת אובייקטים $object = Yii::createObject(array_merge(['class' => SafeClass::class], $config));
2. חיזוק זמן ריצה (php.ini)
גם אם תוקף יוצר מופע של מחלקה, RCE אינו אפשרי אם פונקציות המערכת הבסיסיות מנוטרלות. קבע את התצורה של php.ini כדי להשבית פונקציות ביצוע מסוכנות:
Ini, TOML
disable_functions = system, exec, shell_exec, passthru, proc_open, popen, pcntl_exec
3. תיקון מיידי
החל מיד את העדכון האחרון של Craft CMS. התיקון של הספק עבור CVE-2025-32432 מכניס ככל הנראה מסנן ברמת המסגרת המונע את כיתה פרמטר מלהיות מכובד בפעולות בקר ספציפיות.
סיכום
CVE-2025-32432 מזכיר לנו בבירור שככל שמסגרות הופכות למופשטות וחזקות יותר, הן מציגות משטחי התקפה לוגיים מורכבים. הזרקת קונטיינר היא "הזרקת SQL של שנות ה-2020"—פגם שלא נמצא בקוד שאתה כותב, אלא באופן שבו אתה מגדיר את הקסם של המסגרת.
עבור מהנדס אבטחה קשוח, הלקח ברור: אימות קלט חייב להתרחב מעבר לערכי נתונים לנתונים סוגים ו מבנים. אם אתה מאפשר למשתמש להגדיר את מבנה של אובייקט, כבר הפסדת במשחק.

