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

SSRF guard re-resolves DNS at connect time, so rebinding is still possible

オープン
  • 何か問題がありますか？
#515 コメント 0 件 リアクション 0 件 担当者 0 名 GitHub で見る

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

@sparkysolutions10-pixel がすでに取り組んでいます。

2026年10月19日 から。

  • #578 @sparkysolutions10-pixel による — オープン

評価

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

調査の方向性

Start with src/net/ssrf.ts and trace how its lookup, fetchImpl, and redirect handling work; then read the existing tests that exercise those injectable dependencies. Run those tests before making changes. Done means the connected address is one that was validated, TLS verification and redirect checks remain intact, the injections still work, a rebinding test passes, and the module comment accurately states the guarantee.

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

説明

area:security help wanted

Follow-up to #407, which was closed by #488. That PR is a thorough guard and removed the whole easy attack surface — this is the residue it deliberately left.

Not a Wave issue right now. The repo's Wave budget for this round is exhausted, so this is filed for tracking rather than for points. It will be labelled for the Wave when the next round opens.

The gap

src/net/ssrf.ts validates and then fetches:

let url = await assertUrlSafe(target, opts)
const response = await fetchImpl(url.toString(), { ...init, redirect: 'manual' })

assertUrlSafe resolves the hostname and checks every returned address. fetchImpl is then given the hostname, and Node resolves it again when it opens the connection.

An attacker who controls a DNS zone can serve a short-TTL record that answers the first query with a public address and the second with 169.254.169.254. The check passes, the connection goes somewhere else. This is DNS rebinding, and it is the specific thing a post-resolution check is otherwise meant to defeat.

It matters here because the MCP server takes its target URL from an agent, and agents routinely read attacker-influenced text.

What to build

Pin the connection to an address that was actually validated.

  • An undici dispatcher with a custom connect or lookup is the usual route: resolve once, validate, and hand the chosen address to the connector so no second resolution happens.
  • Or connect by IP with the Host header preserved — be careful, this breaks TLS SNI and certificate verification unless servername is set explicitly, so it is not the simpler option it appears to be.
  • Re-validate on every redirect hop, as the current code already does.
  • The existing injectable lookup and fetchImpl should stay injectable, because that is what makes the current tests possible.
Also

Correct the module comment. It currently reads:

to decide that after resolving the hostname, because a public-looking name can resolve to a private address — the classic way this check is bypassed.

True of a static name, not of an attacker-controlled one. Say plainly that connect-time resolution is not yet pinned, so nobody reads it as a guarantee it does not make.

Acceptance criteria
  • The address connected to is one that was validated
  • A test proves a hostname resolving differently on the second lookup does not reach the second address
  • TLS verification still works against the original hostname
  • Redirect hops remain validated
  • lookup and fetchImpl stay injectable and the existing tests still pass
  • The module comment states what is and is not guaranteed
主要言語
TypeScript
スター
4
フォーク
71
平均マージ
1日 5時間
マージ済み PR（30日）
59

環境構築

はじめの一歩

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

Divinity-Labs/Lens のほかの issue

Divinity-Labs/Lens の issue をすべて見る

似ている issue

TypeScript の issue をもっと見る

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

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