ל-Fetch יש עכשיו מחסום. הוא עדיין לא חומת אש.
מהדורת MCP מ-11 באוקטובר חוסמת כברירת מחדל יעדים לא ציבוריים. DNS rebinding ושמות שרק פרוקסי פותר נשארים מחוץ להבטחה.
עובדות נבדקו ב-12 באוקטובר 2026
מהדורת MCP מ-11 באוקטובר חוסמת כברירת מחדל יעדים לא ציבוריים. DNS rebinding ושמות שרק פרוקסי פותר נשארים מחוץ להבטחה. PR #5033
הבקשה יוצאת ממקום אחר
כתובת URL מגיעה לשיחה עם בינה מלאכותית. נדמה שזו בקשה לקרוא דף ציבורי. אבל החיבור יוצא מהמכונה שמריצה את שרת Fetch, לא מהאדם שמקליד את הכתובת. זו כל הבעיה: הכלי מקבל את טווח הגישה לרשת של המארח. הקריאה שלי במהדורה החדשה של שרתי הייחוס של MCP היא שברירת מחדל שימושית השתנתה, אבל המכונה עדיין צריכה גבול משלה.
מה יצא, ומה לא הפך להבטחה
רשומת המהדורה הרשמית, שפורסמה ב-11 באוקטובר ב-02:40 UTC, כוללת את mcp-server-fetch 2026.10.10 בין שבע חבילות ייחוס שפורסמו. רשימת השינויים כוללת את PR #5033: סירוב כברירת מחדל לכתובות פרטיות, loopback ומטא-נתונים. הבקשה מוזגה ב-5 באוקטובר. זו מהדורת חבילה, לא טענה שכל פריסת MCP קיבלה את המחסום. תהליך ישן לא מקבל מדיניות חדשה בגלל קיומו של דף מהדורה.
היכן מתבצעת הבדיקה
המתחזקים מתארים hook לבקשות HTTP שפותר את שם המארח לפני כל בקשה. אם אחת הכתובות שהתקבלו אינה ציבורית, הבקשה נדחית. אותה בדיקה מכסה את robots.txt, את הדף ואת כל קפיצות ההפניה, במסלול הכלי ובמסלול prompt. לכן URL ציבורי ראשון אינו היתר להפניה מאוחרת לכתובת פנימית. דגל ההפעלה המתועד --allow-private-ips מכבה את המחסום. זו הגדרת מארח, לא ארגומנט שהמודל יכול להוסיף לקריאת Fetch אחת.
שני גבולות מאחורי משפט פשוט
המקור מציין שני גבולות. ה-hook פותר שם, ואז חיבור HTTP פותר אותו שוב. DNS rebinding יכול לתת תשובות שונות בין השלבים: בדיקת כתובת ציבורית אינה זהה להתחברות לאותה כתובת. בנוסף, שם שהשרת אינו מצליח לפתור מועבר לשכבת התעבורה. פרוקסי עשוי לפתור אותו במקום אחר. בדיקת השרת אינה מאשרת יעד שמעולם לא פתר. אלה גבולות מתועדים, לא תקלות ששחזרתי. לא התקנתי ולא הרצתי את החבילה.
ניתוח: להצמיד את ההבטחה לחיבור
המסקנה שלי צרה מ״גלישה בטוחה לסוכנים״: המחסום סוגר נתיבים חשובים לכתובות לא ציבוריות בברירת המחדל, אבל מדיניות יציאה נפרדת צריכה להגביל את החיבור בפועל. בבדיקת פריסה הייתי שואל איזה resolver, פרוקסי וכלל רשת קובעים את היעד הסופי. רשימת URL מותרת לבדה לא עונה על כך. גם תווית read-only לא: קריאה יכולה לשלוח שאילתה רגישה, והתשובה יכולה להכיל הוראות עוינות. טקסט שהוחזר הוא ראיה, לא הרשאה לשנות את המשימה.
תוכנית קבלה ניתנת לשחזור, לא דוח בדיקה
לפני פריסה השתמשו במארח זמני ללא סודות ובנקודת קצה ציבורית בשליטתכם. בדקו דף ציבורי רגיל, URL ישיר ל-loopback, הפניה ציבורית ל-loopback ושם שרק הפרוקסי המוגדר פותר. רשמו גרסה מדויקת, דגלים, פרוקסי והיעד שהתבקש. צפו לסירובים המתועדים כשהמחסום מסוגל לפתור את הכתובת; אל תתארו את המקרה proxy-only כמוגן. ל-DNS rebinding בדקו או חקרו בנפרד את גבול המחבר. אל תפנו לשירות פנימי של מישהו אחר או לנקודת מטא-נתונים אמיתית.
מה הייתי משאיר בכרטיס המהדורה
התוצר השימושי הוא יומן קטן: גרסת שרת שנצפתה; היעדר דגל עקיפה; ראיות לסירוב הפניות; מדיניות הרשת בחיבור; ושני הגבולות שנותרו. הפרידו בין ״המתחזקים מדווחים״ לבין ״אנחנו ראינו״. ה-PR מדווח על בדיקות פרוטוקול וניסוי Inspector, אבל אומר שלא נבדק שם לקוח LLM. זו ראיה שימושית עם גבול מוצהר. מספר גרסה מזהה מהדורה; הוא לא מחליף ראיות מהפריסה.
יומן החלטה להמחשה, לא קוד אבטחה בר-הרצה
בקשה ← פתרון שם ← סירוב לכתובת לא ציבורית
↓
חיבור HTTP פותר את השם שוב
↓
היעד בפועל זקוק למדיניות יציאה