תפעול אבטחה · 12 בנובמבר 2026
עדכון Tunnel של Cloudflare מ־12 בנובמבר מוסיף בגרסת cloudflared 2026.11.0 טיפול בפרמטרים בנתיב המופרדים בנקודה־פסיק. הוא גם דוחה את הפעלת הנרמול כברירת מחדל בגרסאות חדשות ל־8 בפברואר 2027, ומחליף במפורש את 25 בינואר. כרגע ההגדרה עדיין כבויה כברירת מחדל. תצורות שאין בהן כללי כניסה המחייבים אימות Access אינן מושפעות.
הצעד המעשי למפעילים הוא בדיקת ניתוב עם תוצאה צפויה ברורה לכל נתיב מוגן. המועד המעודכן הוא גבול לתכנון, ולא הוכחה שהתנהגותה של מנהרה קיימת כבר השתנתה.
מפרידים בין התאמה לכלל לבין הבקשה לשרת המקור
תיעוד כללי הכניסה מסביר שהנרמול מסיר מקטעי נקודה, ממיר לוכסנים הפוכים ומאחד לוכסנים חוזרים. בגרסה 2026.11.0 מוסרים גם פרמטרים המופרדים בנקודה־פסיק לצורך ההתאמה. הנתיב המקורי עדיין מועבר לשרת המקור. הכללים נבדקים לפי הסדר, וההתאמה הראשונה קובעת.
ההבחנה חשובה כאשר המנהרה והיישום מפרשים את אותו הנתיב בצורה שונה. לפני שינוי ההגדרה, הכינו רשימה קצרה של יעדי הניתוב ודרישות ההגנה. כללו נתיבים של היישום שמכילים נקודה־פסיק, נתיבים רגילים, נתיבים מקוננים ובקשות שאין להן התאמה. רשמו בנפרד את שרת המקור הצפוי ואת תוצאת האימות הצפויה.
מפעילים במכוון בסביבת בדיקה מורשית
תיעוד פרמטרי ההרצה משתמש בדגל בעל משמעות הפוכה: --disable-path-normalization=false מפעיל את הנרמול. משתנה הסביבה המקביל הוא TUNNEL_DISABLE_PATH_NORMALIZATION=false. בהודעת Cloudflare נאמר להגדיר אותו בכל מופע מקביל ולהפעיל אותו מחדש. לבדיקת ההתנהגות המורחבת השתמשו בגרסה 2026.11.0 ומעלה.
תעדו את הגרסה וההגדרה בפועל בכל מופע. בקשה מוצלחת דרך מופע אחד אינה ראיה מספקת לגבי כל המערך. בדקו רק מערכות שבניהולכם או שקיבלתם הרשאה לבדוק, באמצעות בקשות סינתטיות וחשבונות בדיקה ללא מידע רגיש. הפרידו את הניסוי משינויים בייצור ופעלו לפי תהליך אישור השינויים הרגיל שלכם.
בודקים הרשאה, ולא רק תשובה מוצלחת
כאשר היא מופעלת, הגדרת Access לשרת המקור מחייבת את cloudflared לבדוק JWT של Access לפני העברת התעבורה. בבדיקות הקבלה השוו משתמש מורשה לבקשה ללא אימות ולזהות שלא אמורה לקבל גישה. ודאו את שרת המקור שנבחר, את התנהגות היישום ואת תוצאת הדחייה, במקום לראות בקוד HTTP מוצלח הוכחה להגנה תקינה.
לפני הפריסה הגדירו אחראי לשינוי ותנאי עצירה: יעד בלתי צפוי, בקשה שנדחתה בעבר וכעת מתקבלת, או תהליך עבודה תקין שנכשל. שמרו תצורה ידועה כתקינה במערכת ניהול השינויים הקיימת שלכם, והסכימו כיצד להשיב את השירות בלי להסיר בשקט את הגנת Access. בדקו שוב את לוח הזמנים של הספק כשמתזמנים את השינוי בייצור.
איזה תאריך לרשום בכרטיס השינוי?
הפרסום מ־22 באוקטובר עדיין מציג את 25 בינואר 2027. העדכון מ־12 בנובמבר מחליף אותו במפורש ב־8 בפברואר. צרפו את ההודעה החדשה לכרטיס, כדי שבודק נוסף לא יחשוב שהעמוד הישן מציג את המועד העדכני.
היקף: זהו סיכום של מקורות ציבוריים ותוכנית בדיקה מוצעת. SysSeder לא בדקה פריסה ולא קבעה שקיים ניצול או CVE. ברירת המחדל שהוכרזה חלה על גרסאות חדשות מהמועד שצוין; ההודעה אינה אומרת שכל התקנה פעילה משתנה אוטומטית באותו יום.