Traefik מנתב בקשות אל שרתי האפליקציה שמאחוריו, ובדרך הוא מוסיף לבקשה כותרות משלו, ובהן הזהות של המשתמש שאימת. חולשה באופן שבו הוא משווה שמות של כותרות מאפשרת ללקוח לשתול כותרת נוספת בשם דומה, שהשרת שמאחור יעדיף על פני זו של Traefik. משתמש בעל הרשאות נמוכות יכול כך להיקרא אצל השרת כמשתמש אחר לגמרי. הציון הוא 5.3, ויש כאן פרט שחובה לשים לב אליו: התיקון אינו נכנס לתוקף מעצמו.
מה החולשה?
שמות של כותרות HTTP אינם רגישים לאותיות גדולות וקטנות, ולכן כל תוכנה מנרמלת אותם לצורה אחידה לפני שהיא משווה ביניהם. השאלה היא אילו תווים נכללים בנרמול הזה, ובדיוק שם נפער הפער.
Traefik מנרמל את השמות סביב מקפים בלבד. מבחינתו X-Auth-User, X_Auth_User ו-X.Auth.User הם שלוש כותרות נפרדות. אבל שרתים שגוזרים שמות של משתנים משמות של כותרות, וכך עובדים CGI, WSGI, PHP ו-NGINX, מאחדים את שלושתם למשתנה אחד.
עכשיו אפשר לראות את ההתקפה עצמה. נניח ש-Traefik מריץ אימות דרך ForwardAuth וכותב את הזהות שאימת בכותרת X-Authenticated-User. הלקוח שולח יחד עם הבקשה גם כותרת בשם X.Authenticated.User עם ערך משלו. Traefik אינו מזהה אותה ככותרת שהוא מנהל, ולכן אינו מוחק אותה ומעביר אותה הלאה. השרת שמאחור מאחד את שתיהן לאותו משתנה, ולפי הבדיקה שמתוארת ברשומה, בתצורה שנבדקה הערך של הלקוח הוא זה שמנצח באופן עקבי.
הרשומה מדגישה עוד שני דברים. הראשון, זה אינו מוגבל ל-ForwardAuth: כל כותרת ש-Traefik מגדיר חשופה לאותו טריק. השני, מדובר בתיקון לא שלם של חולשה קודמת, שחסמה רק את הצורה עם הקו התחתון והשאירה את הצורה עם הנקודות פתוחה.
מי מושפע?
Traefik בענף 1 כולו, בענף 2 עד 2.11.55, ובענף 3 מ-3.0.0 עד 3.7.11. הגרסאות המתקנות הן 2.11.56 ו-3.7.12.
יש כאן תנאי שני, והוא השרת שמאחור. החולשה מתממשת כשהשירות שמקבל את הבקשה גוזר שמות של משתנים משמות של כותרות, כמו ב-CGI, ב-WSGI, ב-PHP וב-NGINX. הבדיקה שמתוארת ברשומה נעשתה על PHP 8.2 מול שרת HTTP/1.
ומי שמריץ ענף ישן צריך לדעת עוד דבר אחד: לפי הרשומה, ענפי גרסאות שאינם מתוחזקים עוד לא יקבלו תיקון כלל.
האם מנוצלת בפועל?
לא ידוע על כך. נכון לעדכון האחרון, החולשה אינה רשומה בקטלוג ה-KEV של סוכנות הסייבר האמריקאית CISA, שמונה חולשות שיש עליהן עדות לניצול. הרשומה פורסמה ב-10 בספטמבר 2026, ולצידה פרסמה חברת VulnCheck התראה משלה, המקושרת במידע הטכני שבתחתית העמוד.
הציון 5.3 נמוך יחסית, והוא משקף בעיקר את זה שהתוקף צריך להיות כבר מוכר למערכת ברמת הרשאה כלשהי. הוא אינו משקף את מה שקורה בארגון שבו הכותרת הזאת היא בדיוק מה שמפריד בין משתמש רגיל למנהל.
מה עושים?
עדכנו ל-2.11.56 או ל-3.7.12 לפי הענף שלכם, ואז עשו את הצעד השני, שבלעדיו העדכון אינו מספיק. התיקון מוסיף אפשרות הגדרה בשם aliasHeadersStrategy ברמת ה-entry point, וברירת המחדל שלה היא keep, כלומר בדיוק ההתנהגות שהייתה קודם. כך נשמרת תאימות לאחור, וכך נשמרת גם החולשה אצל מי שרק עדכן והמשיך הלאה.
כדי שהתיקון יפעל צריך להגדיר את aliasHeadersStrategy במפורש לערך delete או reject, לפי מה שמתאים לכם: delete מסיר את הכותרות החריגות ומעביר את הבקשה, reject דוחה את הבקשה כולה. זו שורת הגדרה אחת, והיא ההבדל בין להיות מעודכן לבין להיות מוגן.
אם אתם מריצים ענף שאינו מתוחזק עוד ולא יקבל תיקון, המסקנה שונה: שם צריך לתכנן מעבר לענף נתמך. עד שזה קורה, ודאו לפחות שהשירותים שמאחורי ה-proxy אינם סומכים בעיניים עצומות על כותרת זהות שמגיעה אליהם, אלא מאמתים אותה בעצמם.