CVE-2026-42945: NGINX Rift — באג בן 18 שנה שמנוצל עכשיו נגד שרתי Web

דמיינו שמנגנון נעילה שהותקן ב-2008 בכל בניין ציבורי בארץ הכיל פגם נסתר שמאפשר פריצה בכלי פשוט — ואחרי 18 שנה מישהו מגלה זאת, מפרסם הוכחת ניצול, וכעבור שלושה ימים כבר יש ניסיונות פריצה פעילים. בשרתי ה-Web של העולם, בדיוק זה קרה השבוע.

CVE-2026-42945, המוכרת בשם NGINX Rift, היא חולשת הצפת מאגר ב-Heap שנחשפה ב-13 במאי 2026 ודווחה כמנוצלת בפועל רק שלושה ימים לאחר מכן. הבאג קיים בקוד מאז 2008 ומשפיע על כל גרסאות NGINX 0.6.27 עד 1.30.0. ציון ה-CVSS שלה עומד על 9.2 — קריטי.

מה זה NGINX ולמה הסיפור הזה רלוונטי לכולם?

NGINX הוא שרת Web שמפעיל כ-32% מכלל אתרי האינטרנט — מאפליקציות ענק כמו Netflix ו-Cloudflare ועד לשרתים קטנים שמארחים אתרים פשוטים. תפקידיו כוללים הגשת קבצים סטטיים, שימוש כ-Reverse Proxy לאפליקציות, ואיזון עומסים (Load Balancing). רכיב בסיסי ונפוץ כל כך הופך כל פגיעות בו לאירוע שמשפיע על היקף עצום של שרתים — ואדמינים שמפעילים NGINX צריכים לקרוא את הפוסט הזה עכשיו.

הפגיעות הטכנית: שתי מדידות שלא מסכימות

כדי להבין את הבאג, צריך להכיר את מודול ה-Rewrite של NGINX. מודול זה מאפשר להגדיר כללים שמשנים כתובות URL תוך כדי פעולת השרת — לדוגמה, הפניית /products/123 לנתיב פנימי אחר. הכללים משתמשים ב-Regex (ביטויים רגולריים) ומוגדרים בקובץ הקונפיגורציה של NGINX.

הבאג שוכן בתוך מנגנון דו-שלבי שבו NGINX מחשב כמה זיכרון הוא צריך — ואז מעתיק לתוכו:

שלב א׳ — חישוב האורך

כאשר הוראת rewrite כוללת שאלתית (?) בתוצאה, NGINX מסמן דגל פנימי בשם is_args = 1. שלב חישוב האורך מריץ מנוע משנה נפרד — שבו הדגל הזה לא מועתק ונשאר אפס. לכן, חישוב האורך מודד את ה-URI הגולמי כפי שמגיע מהבקשה.

שלב ב׳ — העתקה בפועל

המנוע הראשי, שעדיין זוכר ש-is_args = 1, מבצע URI Encoding על כל תו מיוחד בתוכן שנלכד מה-Regex: כל %, + או & הופך מבייט אחד לשלושה (%25, %2B, %26).

התוצאה: הבאפר הוקצה לפי אורך הנתונים הגולמיים, אבל בפועל נכתבים אליו נתונים שיכולים להיות גדולים פי שלוש — כתיבה מחוץ לגבולות הבאפר על ה-Heap. תוקף שמכניס לבקשה URL עם מספר גדול של תווים מיוחדים (כמו %25%25%25%25) יכול לשלוט בגודל הגלישה.

אילו קונפיגורציות פגיעות?

הפגיעות מתממשת רק כאשר מתקיימים שלושה תנאים בקונפיגורציה בו-זמנית:

1. הוראת rewrite שמשתמשת בלכידת Regex לא-מוכתרת כגון $1 או $2
2. מחרוזת ה-Replacement כוללת שאלתית (?)
3. אחרי אותה הוראה מופיעה הוראת rewrite, if או set נוספת באותו תחום

זוהי תבנית קונפיגורציה לגיטימית ושגרתית — אין שום דרך לדעת ממבט ראשון שהיא מסוכנת. ב-NGINX היא נראית כך:

location /api/ {
    rewrite ^/api/(.*)$ /backend?path=$1? break;
    set $x 1;
}

שלב אחר שלב: איך המתקפה עובדת

1. סריקת קונפיגורציה

התוקף אינו צריך לדעת מראש שהשרת פגיע. הוא שולח בקשות בדיקה לנתיבים שגרתיים ומחפש כל קריסה של NGINX Worker כסימן לפגיעות.

2. עיצוב הבקשה הזדונית

ה-ניצול מבוצע על ידי URL שמכיל כמות גדולה של תווים שמקבלים URI Encoding — כל % בקלט הופך ל-%25 בפלט, כלומר כפולת שלוש. זה מגדיל את הנתונים שנכתבים הרבה מעבר למה שהוקצה.

3. הצפת ה-Heap

הכתיבה מחוץ לגבול גורמת לקריסת תהליך ה-Worker של NGINX — ה-Worker מריץ כל בקשה בפועל. כשהוא קורס, המאסטר-פרוסס של NGINX מעלה Worker חדש, אך הבקשות בזמן הקריסה נכשלות.

4. מה קורה אחר כך (בסביבות ללא ASLR)

ASLR (Address Space Layout Randomization) הוא מנגנון הגנה שמשבש ניצול של Heap Overflow על ידי רנדומיזציה של כתובות הזיכרון. ברוב ההפצות המודרניות הוא מופעל כברירת מחדל — אבל שרתים ישנים, Containers שהוגדרו בצורה לא נכונה ומכשירים Embedded עשויים לפעול בלעדיו. בסביבות כאלה, חוקרי DepthFirst הדגימו הרצת קוד מרחוק מלאה — כלומר ביצוע פקודות שרירותיות על השרת, ללא אימות זהות כלל.

גרסאות מושפעות ותיקון

גרסה	מושפעת	תיקון
NGINX Open Source 0.6.27–1.30.0	כן	עדכנו ל-1.30.1 או 1.31.0
NGINX Plus R32–R36	כן	עדכנו ל-R32 P6 / R36 P4

ניתן לאמת את גרסת NGINX הנוכחית עם:

nginx -v

מה לעשות עכשיו

עדכון מיידי — זה הדבר החשוב ביותר

# Debian / Ubuntu
sudo apt update && sudo apt install nginx

# RHEL / AlmaLinux / Rocky Linux
sudo dnf update nginx

לאחר העדכון, אמתו שה-Worker עלה מחדש בהצלחה:

sudo systemctl status nginx

ביקורת קונפיגורציה

חפשו קונפיגורציות שמשלבות rewrite עם Regex captures, שאלתית, ו-set / if אחריהן. גם לפני העדכון — שינוי הכתיבה כדי להימנע מהתבנית הפגיעה מצמצם את שטח ההתקפה.

ניטור Worker Crashes

Worker של NGINX שקורס ומאתחל שוב ושוב הוא סימן אזהרה ברור. בדקו:

sudo journalctl -u nginx --since "24 hours ago" | grep -i "worker process"

ארגז חול

הריצו NGINX בתוך Container מבודד. גם אם תוקף מצליח להריץ קוד בתוך Worker — הבידוד מגביל את יכולת התנועה שלו ממנו הלאה אל שאר המערכת.

סיכום

NGINX Rift ממחישה עיקרון שחוזר על עצמו: קוד ישן שמעולם לא נבדק מחדש ממשיך לרוץ בייצור עשרות שנים — ורק פרסום מחקר או פריצה ממוקדת חושפים מה הכיל. 18 שנים. 32% מהאינטרנט. שלושה ימים מגילוי לניצול פעיל.

הצעד הראשון ברור: עדכנו ל-1.30.1. זה צריך לקרות עכשיו — לא בסוף השבוע, לא בעדכון הבא המתוכנן.

---

מקורות: The Hacker News | Help Net Security | DepthFirst Research | AlmaLinux Blog