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-адрес і адрес метаданих. PR об’єднано 5 жовтня. Це реліз пакета, а не твердження, що захист уже є в кожному розгортанні MCP. Старий процес не отримує нову політику від появи сторінки релізу.
Де стоїть перевірка
Супроводжувачі описують обробник HTTP-запитів, який визначає адресу хоста перед кожним запитом. Якщо хоча б одна адреса непублічна, запит відхиляється. Перевірка охоплює robots.txt, сторінку та кожен крок перенаправлення на шляху інструмента й prompt. Отже, публічний перший URL не дозволяє подальший перехід до внутрішньої адреси. Документований прапорець запуску --allow-private-ips вимикає захист. Це налаштування хоста, а не аргумент, який модель може додати до одного виклику Fetch.
Два обмеження короткої фрази
Джерело називає два обмеження. Обробник визначає адресу імені, а потім HTTP-з’єднання робить це знову. DNS rebinding може дати різні відповіді: перевірити публічну адресу не означає під’єднатися саме до неї. Також ім’я, яке сервер не може визначити, передається транспорту. Проксі може визначити його деінде. Перевірка сервера не засвідчує адресу, якої він не отримав. Це документовані межі, не відтворені мною збої. Я не встановлював і не запускав пакет.
Аналіз: гарантія має стосуватися з’єднання
Мій висновок вужчий за «безпечний браузинг для агентів»: фільтр закриває важливі типові шляхи до непублічних адрес, а окрема політика вихідного трафіку має обмежувати фактичне з’єднання. Під час огляду розгортання я запитав би, який resolver, проксі та мережеве правило визначають кінцеву адресу. Один список дозволених URL цього не пояснює. Позначка read-only теж: читання може надіслати чутливий запит, а відповідь може містити ворожі інструкції. Отриманий текст є свідченням, а не дозволом змінити завдання.
Відтворюваний план приймання, не звіт про тест
Перед впровадженням використайте тимчасовий хост без секретів і власну публічну точку. Перевірте звичайну публічну сторінку, прямий loopback URL, публічне перенаправлення на loopback та ім’я, яке визначає лише налаштований проксі. Запишіть точну версію, прапорці, проксі та запитану адресу. Очікуйте документовані відмови там, де фільтр може визначити адресу; не називайте proxy-only випадок захищеним. Для DNS rebinding окремо вивчіть або перевірте межу з’єднувача. Не звертайтеся до чужого внутрішнього сервісу чи справжньої служби метаданих.
Що я залишив би в заявці на оновлення
Корисний результат: невеликий журнал із спостережуваною версією сервера, відсутністю обхідного прапорця, доказами відмов для перенаправлень, політикою з’єднання та двома рештою обмежень. Розділяйте «супроводжувачі повідомляють» і «ми спостерігали». PR повідомляє про протокольні тести й експеримент Inspector, але вказує, що LLM-клієнт там не тестували. Це корисне свідчення з визначеною межею. Номер версії називає реліз, але не замінює докази з розгортання.
Пояснювальний журнал рішень, не виконуваний захисний код
запит → визначення адреси → відмова від непублічної адреси
↓
HTTP-з’єднання знову визначає адресу
↓
фактичній адресі потрібна мережева політика