פורסם ב־12 בנובמבר 2026. גרסאות האבטחה של Node.js מתאריך 11 בנובמבר זמינות בענפים 22, 24 ו־26: 22.23.5, 24.22.3 ו־26.13.1. אלו עדכונים שכבר יצאו, לא הודעה על תיקון עתידי. הערות הגרסה כוללות תיקונים לבטיחות זיכרון ולזמינות ב־HTTP/2, לטיפול ב־HTTPS ולאכיפת מדיניות TLS.
למה צריך לבדוק מחדש את מדיניות התעודות
הודעת האבטחה הרשמית מציינת שלוש בעיות בגבולות האמון: משא ומתן מחדש ב־TLS 1.2 עלול להעביר אימות לקוח לשם מארח אחר (CVE-2026-123872, חומרה גבוהה); הקשר SNI שמגדיר רק CA עלול להשאיר את רשות האישורים של ברירת המחדל (CVE-2026-123867, בינונית); והתנגשות במטמון של https.Agent עלולה לאפשר שימוש חוזר בהפעלה בין מדיניות ללא ca למדיניות ca: [] (CVE-2026-123877, בינונית). שלושת הענפים הנתמכים מופיעים כמושפעים. החשיפה תלויה בתצורה; אין כאן טענה שכל יישום Node.js מקבל לקוחות לא מורשים.
תהליך עדכון מעשי, ולא רק בדיקת מספר גרסה
זו רשימת הבדיקות התפעולית שלנו, לא מעקף שהספק מציע:
- מאתרים את העותק שבאמת רץ. ממפים קונטיינרים של יישומים, תהליכי רקע, סוכני בנייה וסביבות ריצה שמגיעות כחלק ממוצר. גרסה חדשה במחשב של מפתח אינה מעידה על מה שפועל בייצור. מתעדים את הגרסה מתוך סביבת העבודה עצמה ומזהים מי אחראי לחבילה או לתמונת הקונטיינר.
- מעדכנים בתוך הענף הנתמך. משתמשים בגרסה הרשמית המתאימה, או בחבילת הפצה שהתיקונים המקבילים בה מתועדים. בונים ופורסים מחדש תמונות, במקום להסתפק בשינוי Dockerfile. מוודאים שהתהליכים החלופיים התחילו עם סביבת הריצה המתוקנת. עדכון של ספריית יישום לבדו אינו ראיה לעדכון סביבת הריצה.
- בודקים קבלה וגם דחייה. בסביבת בדיקות משתמשים בתעודות ובנתונים סינתטיים. לכל שם מארח מוגן מתעדים אילו רשויות אישורים של לקוחות צריכות להתקבל, אילו צריכות להידחות ומה אמור לקרות לבקשה ללא אימות. בודקים חיבורים חדשים וגם חידוש הפעלות. כוללים גם לקוחות יוצאים שמחליפים במכוון את מדיניות האמון הרגילה. לחיצת יד מוצלחת בתרחיש התקין היא רק חצי מהבדיקה.
- עוקבים אחר ההתנהגות אחרי הפריסה. משווים כשלי TLS, דחיות אימות, ניתוקי HTTP/2 וצריכת זיכרון למצב שלפני השינוי. אם חיבור לגיטימי נשבר, חוקרים את המדיניות הרצויה במקום לכבות אימות תעודות כדי להעלים את ההתראה.
מה נחשב לסיום העבודה
שומרים רישום פריסה קצר: בעל האחריות, הגרסה הפעילה או אסמכתה לתיקון הספק, זמן החלפת התהליכים, תוצאות מדיניות התעודות הצפויות והתוצאות שנמדדו. בסביבת ריצה מנוהלת מבקשים מהספק מצב פריסה, ולא מניחים שלוח הזמנים שלו זהה לזה של הפרויקט.
פרסום תיקון אינו הוכחה שמערכת מסוימת הותקפה. גם לוח ניטור בלי שגיאות אינו הוכחה שסביבת ריצה ישנה בטוחה. התוצאה החשובה היא תהליך מתוקן לצד ראיות שגבולות האמון הרצויים של היישום עדיין נאכפים.