שני CVEs שפורסמו לאחרונה — CVE-2025-55182 ב-React Server Components ו-CVE-2025-29927 ב-Next.js middleware — פותחים נתיב להרצת קוד מרחוק (remote-code execution) ועקיפת אימות (authentication bypass) במחסניות JavaScript מודרניות. בקשה בודדת יכולה להפעיל את הפגמים; הגדרה (configuration) לבדה אינה יכולה לעצור אותם. צוותים המסתמכים על React Server Components או על Next.js middleware חייבים להתייחס לבאגים הללו כדחופים ולדחוף תיקונים (patches) באופן מיידי.

למה הרעש בלוגים מטעה

משכנו חודש של לוגי edge מאתר Next.js בסביבת ייצור (production). המערך הכיל 8,900 בקשות שסומנו כזדוניות. כמעט כולן נכשלו כבר בקפיצה הראשונה. ה-URL הנפוץ ביותר היה /wp-admin/install.php, שהופיע 518 פעמים, למרות שהאתר אינו מריץ WordPress, אינו משתמש ב-PHP ואין בו קבצי WordPress.

סורקים אוטומטיים מייצרים את התעבורה הזו. הם מתיזים על האינטרנט ניחושים, כשהם מחפשים:

  • סודות וקבצי הגדרה – 64% מהניסיונות
  • פאנלים ו-shells של PHP – 22%
  • נתיבי WordPress – 11%
  • כלי מסד נתונים – 1%

מספר גבוה של בקשות חסומות רק אומר לכם שאתם לא מריצים את התוכנה שהבוטים מצפים לה. זה לא מבטיח שהאפליקציה שאתם כן מריצים בטוחה.

ההתקפות השקטות ברמת ה-framework

כאשר תוקף מכוון לאפליקציית Next.js, התעבורה נראית כמו בקשות משתמש רגילות, תוך שימוש במנגנונים של ה-framework עצמו נגדו.

React2Shell (CVE-2025-55182)

פגם ב-React Server Components מאפשר לתוקף להזריק payload שעוצב במיוחד, שהשרת מעבד כקוד. התוצאה היא הרצת קוד מרחוק מלאה ללא צורך בעקיפת חומת אש או מסנן אפליקציות ווב (WAF). הפגיעות נמצאת בתוך ה-framework; התיקון היחיד הוא שדרוג לגרסה המכילה את התיקון.

Middleware Authorization Bypass (CVE-2025-29927)

Next.js middleware יכול לאכוף בדיקות אבטחה המבוססות על כותרות בקשה (request headers). CVE זה מראה שתוקף יכול לספק כותרת פנימית מסוימת ולגרום ל-middleware לדלג על הבדיקות הללו לחלוטין. מבחוץ, הבקשה נראית רגילה, מה שמקשה על הזיהוי.

שני הבאגים מראים שהתעבורה המסוכנת ביותר יכולה להתמזג עם תעבורה יומיומית, תוך התחמקות מההתראות שתופסות סריקות WordPress רועשות.

מהם הסיכונים

  • מפתחים המתייחסים לעדכוני framework כאל אופציונליים מסכנים השתלטות מלאה על השרתים שלהם.
  • צוותי אופרציה המסתמכים על הגדרה סטטית כדי להקשיח מחסנית (stack) אינם יכולים להתגונן מפני קוד שרץ בתוך ה-framework עצמו.

צ'קליסט הגנה מעשי

  1. היגיינת פריסה (Deployment hygiene) – אל תשלחו סודות בקבצים כמו .env. שמרו אותם במשתני סביבה (environment variables) המסופקים בזמן ריצה (runtime) או במערכת ייעודית לניהול סודות.
  2. שטח תקיפה מינימלי – כבו תכונות framework שאינכם משתמשים בהן. אכפו Content-Security-Policy קשיח שחוסם טעינה של סקריפטים לא מורשים.
  3. תיקון מהיר (Rapid patching) – אוטומטו את תהליך ה-build כך שניתן יהיה לבדוק ולפרוס גרסה חדשה של ה-framework תוך שעות מרגע השחרור. התייחסו לעדכוני אבטחה כחלק קבוע מקצב שחרור הגרסאות, ולא כמחשבה מאוחרת.

מה כדאי לעקוב אחריו בהמשך

  • הירשמו לפידים הרשמיים של הודעות אבטחה עבור React, Next.js וכל ספריית runtime אחרת שעליה אתם מסתמכים.
  • שלבו סורקי פגיעויות שמבינים מטא-דאטה של חבילות JavaScript, כך ש-CVE שפורסם לאחרונה יפעיל התראה אוטומטית.
  • בנו תהליך פריסה התומך ב-rollback; אם תיקון גורם לרגרסיות, תוכלו לחזור אחורה במהירות מבלי להשאיר את המערכת חשופה.

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