Squidbleed（CVE-2026-47729）――Squid ProxyのFTPパーサーに約29年潜伏したヒープオーバーリード

この記事は約12分で読めます。

2026年6月、オープンソースのWebプロキシであるSquidに、ヒープバッファのオーバーリードを引き起こす脆弱性が公表されました。識別子はCVE-2026-47729、通称Squidbleedです。発見元のCalif.ioによれば、原因となるコードは1997年1月のコミットに端を発しており、約29年にわたってSquidのコードベースに潜在していたものとされています。本稿では、この脆弱性の攻撃チェーン、技術的な根本原因、修正リリースをめぐる公式情報の整理、対処を解説します。

Squidbleedの全体像

Squidbleedは、Squid ProxyのFTPゲートウェイ実装（src/clients/FtpGateway.cc）に存在するヒープバッファのオーバーリードです。攻撃者は同じSquidプロキシを使用できる「trusted client」（共有ネットワークの別ユーザー）として、自身が制御するFTPサーバー（ポート21）へSquid経由で接続し、巧妙に構成されたFTPディレクトリ一覧応答を返すことで、Squidに他ユーザーのHTTPリクエストを含むヒープメモリーを誤って読み出させます。Squidは内部メモリプールで解放済みバッファをゼロクリアせずに再利用するため、被害者のAuthorizationヘッダー、Cookie、APIキーなどがディレクトリ一覧の「ファイル名」として攻撃者へ返されます。

項目 内容
CVE CVE-2026-47729
命名 Squidbleed（Heartbleedからの命名）
脆弱性種別 Heap buffer over-read（CWE-126）
CVSS v3.1 6.5 Medium（SUSE評価）
影響範囲 Calif.ioによれば、Squid Proxyの全バージョンが既定構成で影響を受ける可能性。ディストリビューションごとの修正状況は各ベンダーのアドバイザリを確認
起源 1997年1月18日のcommit bb97dd37a（NetWare FTPサーバー対応）
発見者 Lam Jun Rong（Calif.io）+ Claude Mythos Preview（Anthropic Project Glasswing）

攻撃成立の条件

攻撃の成立には、次の条件がすべて揃う必要があります。

  • 攻撃者が、被害者と同じSquidプロキシに対して送信権限を持つ「信頼されたクライアント」であること。学校、企業、公共Wi-Fiなど、共有プロキシ環境が典型例です。
  • 攻撃者制御のFTPサーバー（21/TCP）にSquidから接続できること。FTPサポートはデフォルトで有効であり、ポート21は標準の Safe_ports ACLに含まれています。
  • 被害者の通信が、Squidから内容を観測できる状態にあること。具体的には平文HTTP（cleartext HTTP）、またはSquidがTLSを終端して復号するSSLインスペクション構成です。通常のHTTPS（CONNECTトンネル）の中身はSquidからは不透明であり、影響を受けません。

漏えいしうるデータには、被害者のHTTPリクエストに含まれるAuthorizationヘッダー、セッションCookie、APIキーなどの認証情報が含まれます。Squidのメモリプールはバッファを再利用する際にゼロクリアを行わないため、解放されたバッファに残存していた被害者のHTTPリクエストデータが、攻撃者のFTPディレクトリ一覧応答に紛れ込む形で返されます。

1997年に紛れ込んだNetWare対応コード

Calif.ioによれば、原因となるコードはSquidのGitHubリポジトリで参照できる最古のコミット履歴より前、1997年1月18日のコミット bb97dd37a に遡ります。チェンジログには「Fixed ftpget to recognize ‘NetWare’ servers and skip whitespace before filenames」とあり、当時普及していたNetWareのFTPサーバーが、変更日時とファイル名の間に4個のスペースを返す挙動への対応として導入されたものでした。

該当ロジックは src/clients/FtpGateway.cc に現存しており、空白文字を読み飛ばすwhileループとして次のように実装されています。w_space は compat/compat_shared.h で " \t\n\r" と定義された空白文字集合です。

copyFrom = buf + tokens[i + 2].pos + strlen(tokens[i + 2].token);
if (flags.skip_whitespace) {
    while (strchr(w_space, *copyFrom))
        ++copyFrom;
} else {
    if (strchr(w_space, *copyFrom))
        ++copyFrom;
}
p->name = xstrdup(copyFrom);

このループは、攻撃者制御のFTPサーバーが「タイムスタンプの直後でファイル名なしに行を終端させた応答」を返した場合に破綻します。copyFrom が文字列終端のNULバイトを指した状態で strchr(w_space, '\0') が呼ばれると、C11 §7.24.5.2の定義により終端NULは探索対象文字列の一部とみなされるため、strchr はNULLではなくNULバイト自身へのポインターを返します。結果としてwhileループは終端で停止せず、++copyFrom を繰り返してバッファ境界を越え、その先のヒープ領域を読み続けます。最終的に xstrdup がオーバーリード結果を「ファイル名」として複製し、FTPディレクトリ一覧のHTML出力に組み込んで攻撃者へ返します。

ここで漏えいデータとしてHTTPリクエストが乗りやすい理由は、Squidのメモリプール設計にあります。Squidは malloc の上にサイズ別のfreelistを持ち、解放されたバッファをシステムへ返却せず再利用します。FTPディレクトリ一覧の解析バッファは MEM_4K_BUF プールから取られ、Squid 7.x系では CLIENT_REQ_BUF_SZ が4,096バイトに設定されているため、受信したHTTPリクエストの多くも同じプールに収容されます。プールはバッファをゼロクリアせずに再割り当てするため、直前までHTTPリクエストを保持していたバッファがFTP解析用に再利用されると、短いFTP行で先頭数十バイトのみが上書きされ、残りの領域に被害者データが温存された状態となります。

修正コミットと公式情報の食い違い

パッチ自体はごく小さなものです。strchr を呼ぶ前にNULバイトをガードする1行の変更で、コミット 865a131c7d557e68c965043d98c2eccae26deef8 として公開されています。

     if (flags.skip_whitespace) {
-        while (strchr(w_space, *copyFrom))
+        while (*copyFrom && strchr(w_space, *copyFrom))
             ++copyFrom;
     } else {
-        if (strchr(w_space, *copyFrom))
+        if (*copyFrom && strchr(w_space, *copyFrom))
             ++copyFrom;
     }

ところが、修正リリースに関する公式情報には現時点で食い違いがあります。oss-securityメーリングリストにおけるSquid Software FoundationのAmos Jeffries氏の投稿を時系列で追うと、状況は次のように推移しています。

  • 2026-06-08：Squid 7.6リリース
  • 2026-06-12：Amos Jeffries氏がoss-secで「Squid 7.6がCVE-2026-47729とCVE-2026-50012の両方の修正を含む」と告知（embargo解除）
  • 2026-06-15：Amos Jeffries氏が同スレッドで訂正「CVE-2026-47729のembargoは終了したが、修正は実際にはSquid 7.7で出荷される」
  • 2026-06-21：DebianがDSA-6360-1で4件のCVE（CVE-2026-33515、CVE-2026-33526、CVE-2026-47729、CVE-2026-50012）に対するセキュリティ更新パッケージ「squid 6.13-2+deb13u2」（stable trixie向け）をリリース
  • 2026-06-22：DebianのSalvatore Bonaccorso氏がoss-secで再質問「参照されている修正コミット 865a131c はSquid 7.6に含まれているように見える。7.7における正しい修正コミットを示してほしい」

つまり、上流のSquidメンテナーによる「修正バージョン」のアナウンスと、Debianを含む下流の認識との間に齟齬が残った状態で本稿執筆時点を迎えています。Squid公式の正式アドバイザリは、6月12日時点の同投稿で「Formal Advisory are still awaiting text polish」と明記されており、本稿執筆時点でも未発行です。

同スレッドでもう1件案内されているCVE-2026-50012は、cache_digest応答処理のヒープバッファオーバーフローで、こちらはSquid 7.6が修正を含むと案内されています。ただし、--enable-cache-digests を付けてビルドした場合にのみ影響するニッチな脆弱性です。

このため、運用上は「Squid 7.6を当てたから安全」「7.7まで待たないと駄目」と単純に判断するのではなく、自環境のSquidビルドに修正コミット 865a131c の内容（*copyFrom && のNULガード）が反映されているかをソースレベルで確認する方が確実です。

CVSSスコアと深刻度の現状

CVE-2026-47729のCVSSスコアについては、本稿執筆時点で公開されている評価としてSUSEが付与した値があります。CVSS v3.1のベーススコアは6.5（Medium）、ベクター文字列は CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N です。SUSEはこれを「moderate severity、overall stateはPending」として公開しており、SUSE Linux Enterprise Server関連の多くの製品で「Affected」状態（修正パッケージ未配布）と整理されています。

ベクターの内訳は、攻撃元区分がネットワーク、攻撃条件が低、必要権限が低、ユーザー関与が不要、スコープ変更なし、機密性影響が高、完全性と可用性への影響はなし、というものです。攻撃成立に「同一プロキシへのアクセス権限を持つクライアント」という前提が必要であり、影響が機密性のみに限定される点が、この程度のスコアに反映されているものと考えられます。SUSEはディストリビューションベンダーであり、Squid公式ベンダーやNVDによる正式付与値ではない点には留意してください。

共有プロキシという立地上、SSLインスペクションを行う企業環境や、レガシーシステムでまだ平文HTTPが流れている内部ネットワークでは、認証情報が直接漏えいする経路として実害が出やすい構造です。スコアの数値だけで深刻度を判断するのは避け、自組織のSquid配置と通信内容に照らして評価する必要があります。

実務視点での対処

修正バージョン番号に関する公式情報の食い違いが解決していない現状では、次の順序で対処を進めるのが堅実です。

  • FTPサポートを無効化する。Calif.io自身が推奨している方法で、最も確実な緩和策です。Chromium系ブラウザは数年前にFTPサポートを廃止しており、現在の企業環境でSquid経由のFTPトラフィックが業務上必要なケースは稀です。squid.conf の Safe_ports ACLから21番ポートを除外する、またはFTPスキームへのアクセスを明示的に拒否することで、この攻撃面そのものが消えます。FTPプロキシが本当に必要な場合は、接続先FTPサーバーを既知の信頼済みリストに限定するという中間策も有効です。
  • ディストリビューションのセキュリティ更新を適用する。Debianはstable（trixie）向けに2026-06-21付でDSA-6360-1（squid 6.13-2+deb13u2）をリリース済みで、Squidbleedを含む4件のCVEを一括で対処しています。SUSE、Red Hat系、Ubuntuなど他のディストリビューションも順次対応が進む見込みのため、配布元のセキュリティ通知を直接確認するのが最も実務的です。
  • バージョン番号ではなく修正コミットの内容で判断する。上流の「Squid 7.6か7.7か」をめぐる情報には食い違いが残っているため、運用中のビルドの src/clients/FtpGateway.cc に while (*copyFrom && strchr(w_space, *copyFrom)) のNUL終端ガードが入っているかを直接確認するのが確実です。未反映の場合は、配布元のセキュリティ更新を待つか、修正コミット 865a131c を自前でバックポートする選択肢があります。
  • SSLインスペクション構成を棚卸しする。SquidがTLS終端を担っている場合、攻撃の影響範囲は平文HTTPにとどまらず、本来HTTPSで守られていたはずのリクエストにも及びます。SSLインスペクションを実施している組織は、対象範囲と必要性をあらためて見直す機会になります。

PoCコードはCalif.ioのpublicationsリポジトリで公開されています。本稿執筆時点で実環境での悪用報告は確認されていませんが、PoCが公開済みである以上、共有プロキシを運用している組織は速やかな緩和策の適用が望まれます。

AIによる脆弱性発見という文脈

Calif.ioは今回のバグの発見に、AnthropicのProject GlasswingにおけるClaude Mythos Previewを使用したと公式に明らかにしています。同社は2週間前にも、OpenAIのCodexを用いてHTTP/2関連のDoS脆弱性（HTTP/2 Bomb）を公表しており、両事例とも商用AIモデルがコードベースの状態機械を多エージェント解析することで、長年の人手レビューで見落とされてきたバグを表面化させた例として注目されています。今回の strchr とNUL終端の挙動は、C標準ライブラリの仕様を厳密に追えば自然に浮かび上がる論点ですが、人間のコードレビューでは自明のように見える1行として見過ごされやすい類のものです。

OSSの長期保守において、デフォルトで有効なまま放置されたレガシー機能のコードパスが、現代の脅威モデルでは静かなリスク源になりうる、という点も今回の事例が示唆するところです。FTPのような利用実態の薄れた機能を、必要性を再評価して無効化していく運用は、Squidbleed単体への対処を超えた一般的な対策として有効でしょう。

参考情報

コメント

タイトルとURLをコピーしました