目次（6）
CVE-2026-119760
NVD は 2026-10-30 に、TLS/HTTP のホスト名で振り分けるプロキシ sniproxy の 0.7.0 以下に、NULL ポインタ参照の脆弱性（CVE-2026-119760）を登録しました。resolv_cancel() が、DNS 問い合わせの失敗で得た NULL のハンドルをそのまま扱うため、認証なしの攻撃者が、254 文字または 255 文字のホスト名を TLS の SNI または HTTP の Host ヘッダーで送り、そのまま接続を閉じるだけで、プロキシのデーモンを異常終了させられます。登録元（CNA）は VulnCheck で、CVSS は v4.0 が 8.7（HIGH）です。影響は可用性のみで、情報の漏えいや書き換えは示されていません。
何が起きるか
- 対象は sniproxy の 0.7.0 以下です（NVD の記述。0.7.0 は 2026-11-02 時点で確認できた最新のタグ）。
- 条件は、設定の転送先（backend）にワイルドカード（*）の項目があり、そこに一致するホスト名が送られることです。ワイルドカードの転送先は、受け取ったホスト名を DNS で引いて接続先を決めます。
- ホスト名の検査は 255 文字までを通しますが、DNS の名前は文字列では 253 文字までです。DNS ライブラリが 254〜255 文字を「不正な問い合わせ」として拒否すると、問い合わせのハンドルが NULL になるのに、接続は「名前解決中」の状態に置かれます。
- クライアントが接続を閉じると、後始末の処理が NULL のハンドルで resolv_cancel() を呼び、SIGSEGV で落ちます（CWE-476）。253 文字の名前では落ちません。
- 認証は要らず、ネットワーク越しで、細工した接続を 1 本送るだけで成立します。プロキシが止まると、そのプロキシが中継する全ての通信が止まります。再起動の仕組みがなければ、落ちたままになります（推定）。
修正の状況
- 本家のリポジトリ（GitHub: dlundquist/sniproxy）には、この不具合の報告（issue #411、2026-10-23 付）があります。2026-11-02 時点で、本家で修正が取り込まれたか、修正版がリリースされたかは確認できていません。
- NVD の参照先には、派生リポジトリ（フォーク）の 2 つのコミットがあります。内容は、NULL のハンドルを resolv_cancel() に渡さないよう確認を入れること、DNS 問い合わせが全て失敗したときに NULL を返して後始末を行うことです。これが本家のリリースに入っているかは未確認です。
- Debian の sniproxy 0.7.0-1 パッケージでも再現するとの報告が issue にあります。ディストリビューションが修正を配っているかは確認していません。
数値と出典（2026-11-02 時点）
| CVE | 対象 | 必要な権限 | CVSS v4.0 | CWE | EPSS |
|---|---|---|---|---|---|
| CVE-2026-119760 | sniproxy 0.7.0 以下 | 不要 | 8.7 | CWE-476 | 0.48%（2026-11-01 付） |
- NVD の状態は Deferred（保留）で、NVD 自身の評価はありません。CVSS は VulnCheck（CNA）の v4.0 のみで、v3.1 の値は付いていません。v4.0 のベクターは AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N です。
- EPSS（FIRST）は 0.48% で、パーセンタイルは 0.41（2026-11-01 付）です。
- KEV（CISA の悪用確認済みカタログ）には掲載がありません（2026-10-30 公開の版、2026-11-02 取得）。
- 悪用の有無は確認できていません。issue には再現の手順が公開されています。
severity を high とした理由
認証不要で、ネットワーク越しに、1 本の接続でプロキシを停止できます（CVSS v4.0 は 8.7）。一方、影響は可用性のみで、データの漏えいや書き換え、コード実行は示されていません。成立にはワイルドカードの転送先が設定されていることが必要で、EPSS は 0.48% と低く、KEV にも載っておらず、悪用も確認していません。公開された再現手順があり、本家の修正版も確認できないため、該当する構成では早めの対処が望まれます。以上から high としています。
対応として考えられること
- sniproxy を使っているかを確認します。パッケージ管理（dpkg -l sniproxy など）や、稼働中のプロセスで、版が 0.7.0 以下かを見ます。
- 設定ファイルの table に、ワイルドカード（*）の転送先があるかを確認します。ないか、DNS による名前解決を使わない構成なら、この経路は成立しない可能性があります（推定）。
- 本家のリポジトリ、使っているディストリビューションの更新で、修正の取り込みや新しい版が出ていないかを確認し、出ていれば更新します。
- 修正が出るまでの間は、sniproxy の前段（ロードバランサーやファイアウォール）で、254 文字以上の SNI や Host ヘッダーを持つ接続を落とせるか検討します（推定）。
- プロセスの監督（systemd の Restart= など）で自動再起動するようにし、停止時の検知と通知を入れます（推定）。落ち続ける攻撃を受けた場合の根本的な防止にはなりません。
未確認の点
- 実際の攻撃での悪用は確認していません。
- 本家での修正の取り込み、修正版のリリース、ディストリビューションの対応は確認できていません。
- NVD 自身の評価は未実施（Deferred）です。CVSS は CNA の v4.0 のみで、v3.1 はありません。
- 0.7.0 より前の版が影響を受けるかの範囲は、NVD の記述（through 0.7.0）に従っており、個別には確認していません。
この記事について
- 執筆・編集
- World Security 編集部
