Hacktoberfest 2026：メンテナが10月に向けて印を付けた、オープンで初心者向けの issue。 Hacktoberfest の issue を見る

fetch: SSRF guard misses RFC 6052 Well-Known NAT64 prefix (64:ff9b::/96) and ::/96

オープン 初心者向け
  • 何か問題がありますか？
#5,181 コメント 1 件 リアクション 0 件 担当者 0 名 GitHub で見る

メンテナーはふだん 1 日以内に返信

まだ誰も着手していません。

評価

難易度
2/5
見積もり時間
1〜3時間
初心者へのやさしさ
75/100
issue の種類
バグ
明瞭さ
明確に書かれている
活発さ
活発
技術スタック
python
領域
backend, security

調査の方向性

src/fetch/src/mcp_server_fetch/server.pyから始めて、_NON_PUBLIC_NETWORKSと_is_public_address()を読みます。既存のIPv4-mappedおよびLocal-Use NAT64エントリがどのようにテストされているかを確認し、報告された2つのプレフィックスと、それらに埋め込まれたプライベートIPv4アドレスを対象とするテストを追加します。これらのアドレスが拒否され、パブリックな宛先では引き続き期待どおりに動作すれば完了です。

索引モデルが issue の本文から書いたものです。

説明

bug server-fetch v2
Which server?

fetch (mcp-server-fetch)

Server version

latest (post PR #5033 / v2/main)

How did you run the server?

uvx or pip (PyPI package)

Transport

stdio

Protocol era

Modern (2026-07-28)

MCP client and version

Claude Desktop / MCP Inspector

Operating system and runtime

Linux / macOS / Windows, Python 3.10+

Steps to reproduce

Following the merge of PR #5033 ("fix(fetch): refuse private, loopback and metadata addresses by default (#4838)"), _is_public_address() in src/fetch/src/mcp_server_fetch/server.py checks IP addresses against _NON_PUBLIC_NETWORKS.

  1. Start mcp-server-fetch.
  2. Request fetching a target whose resolved IPv6 address maps to an internal IPv4 address using RFC 6052 Well-Known Prefix NAT64 (64:ff9b::/96) or deprecated IPv4-compatible IPv6 (::/96, RFC 4291).
    Examples:
    • 64:ff9b::127.0.0.1 (hex 64:ff9b::7f00:1)
    • 64:ff9b::169.254.169.254 (hex 64:ff9b::a9fe:a9fe)
    • ::127.0.0.1
  3. _is_public_address(ipaddress.ip_address("64:ff9b::127.0.0.1")) is evaluated.
Expected behavior

Under defense-in-depth egress filtering, addresses that translate/embed loopback, RFC 1918, link-local, or cloud metadata IPv4 addresses should be rejected by default, in the same manner as IPv4-mapped IPv6 (::ffff:0:0/96) and Local-Use NAT64 (64:ff9b:1::/48).

Actual behavior

In src/fetch/src/mcp_server_fetch/server.py, _NON_PUBLIC_NETWORKS includes:

  • ipaddress.ip_network("64:ff9b:1::/48") (RFC 8215 Local-Use IPv4/IPv6 Translation)
  • ipaddress.ip_network("::ffff:0:0/96") (RFC 4291 IPv4-mapped IPv6)

However, it omits:

  1. 64:ff9b::/96 (RFC 6052 Well-Known Prefix for IPv4/IPv6 translation)
  2. ::/96 (RFC 4291 IPv4-compatible IPv6)

Because standard Python ipaddress.IPv6Address("64:ff9b::127.0.0.1").is_global evaluates to True, _is_public_address() returns True, allowing the request to bypass the private destination refusal guard in dual-stack / NAT64 environments.

Logs or error output
>>> import ipaddress
>>> from mcp_server_fetch.server import _is_public_address
>>> 
>>> # Currently blocked:
>>> _is_public_address(ipaddress.ip_address("127.0.0.1"))
False
>>> _is_public_address(ipaddress.ip_address("::ffff:127.0.0.1"))
False
>>> 
>>> # Currently bypasses filter:
>>> _is_public_address(ipaddress.ip_address("64:ff9b::127.0.0.1"))
True
>>> _is_public_address(ipaddress.ip_address("64:ff9b::169.254.169.254"))
True
>>> _is_public_address(ipaddress.ip_address("::127.0.0.1"))
True
Already prototyped a fix?

Add both prefixes to _NON_PUBLIC_NETWORKS in src/fetch/src/mcp_server_fetch/server.py:

_NON_PUBLIC_NETWORKS: tuple[ipaddress.IPv4Network | ipaddress.IPv6Network, ...] = (
    # ... existing networks ...
    ipaddress.ip_network("64:ff9b::/96"),  # Well-Known NAT64 Prefix (RFC 6052)
    ipaddress.ip_network("64:ff9b:1::/48"),  # Local-Use IPv4/IPv6 Translation (RFC 8215)
    ipaddress.ip_network("::ffff:0:0/96"),  # IPv4-mapped IPv6 (RFC 4291)
    ipaddress.ip_network("::/96"),  # IPv4-compatible IPv6 (RFC 4291)
)

(Or inspect the embedded 32-bit IPv4 address for any address falling into /96 translation scopes to re-verify against IPv4 private definitions).

Before you submit
  • I searched existing issues and this is not a duplicate.
  • This is not a security vulnerability report (those go through the private advisory form).
主要言語
TypeScript
スター
91.4k
フォーク
11.8k
平均マージ
7時間 36分
マージ済み PR（30日）
126

環境構築

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

modelcontextprotocol/servers のほかの issue

modelcontextprotocol/servers の issue をすべて見る

似ている issue

TypeScript の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。