悪用が確認された脆弱性に、修正版がない

#状況

これは作り話ではなく、実際に出た警告を題材にしています。「更新すれば直る」という前提が崩れたとき、運用者は判断を迫られます。このモジュールは、その判断の筋道を学ぶ手順書です。扱う機能は、パッケージの既知の脆弱性の照合、悪用される恐れの高い脆弱性の診断、脆弱性の受容 です。

#最初の 15 分で、警告を読む

あわてて動く前に、警告に出ている言葉の意味を確かめます。

読み落としやすい点が 2 つあります。

• KEV の印は、「どこかで悪用された」という意味です。あなたのサーバーが狙われている、という意味ではありません
• CVE の説明が指している製品と、あなたの入れているパッケージは、同じとは限りません。この CVE の説明は「Google Chrome の Skia の範囲外書き込み」です。WebKitGTK が実際に影響を受けるかは、説明文だけでは決まりません。Ubuntu の脆弱性の管理表では、webkit2gtk は 24.04、26.04 ともに deferred(対応を保留)です(Ubuntu CVE)

#判断の分かれ目

#外から届く経路があるかを調べる

警告が指しているパッケージが、このマシンで実際にどう使われているかを調べます。使うのは、読み取りだけのコマンドです。

# 1. 警告の内容(読み取りのみ)
sudo roamswitch scan-packages | grep -A9 "CVE-2026-3909"

# 2. そのパッケージに依存して、入っているものは何か
apt-cache rdepends --installed libwebkit2gtk-4.1-0

# 3. 今、動いているプロセスで、そのライブラリを読み込んでいるもの
sudo grep -l "libwebkit2gtk\|libwebkitgtk" /proc/[0-9]*/maps | cut -d/ -f3 | while read p; do ps -o comm= -p $p; done | sort | uniq -c

# 4. そのプロセスが、ネットワークで待ち受けているか(PID ごとの件数。すべて 0 なら待ち受けなし)
for p in $(sudo grep -l "libwebkit2gtk\|libwebkitgtk" /proc/[0-9]*/maps | cut -d/ -f3 | sort -u); do sudo ss -lntup | grep -c "pid=$p,"; done

CVE-2026-3909  [Ubuntu 26.04] webkit2gtk 2.52.6-0ubuntu0.26.04.1 (CVSS 8.8)
  KEV  米国CISAが、実際に悪用されていることを確認した脆弱性です。
  EPSS 2% (2026-11-01)
  修正版: まだありません

Reverse Depends:
  gir1.2-webkit2-4.1
  libedataserverui-1.2-4t64

      1 evolution-alarm
      1 evolution-sourc
      1 gnome-initial-s

0
0
0

#期限つきで受容する

3 つの問いに答えた結果、「使われているが、細工されたデータを開く使い方はしておらず、待ち受けもなく、今は軽減する手もない」と判断したとします。このとき、理由と期限を付けて記録するのが「受容」です。

sudo roamswitch vuln-accept Ubuntu webkit2gtk CVE-2026-3909 \
  --version 2.52.6-0ubuntu0.26.04.1 --days 30 \
  --reason 'Ubuntuが対応見送り(deferred)で修正版なし。CVEはChromeのSkia。webkit2gtkを使うのはEvolution等のみでネットワーク待ち受けなし。30日後に再評価'

Ubuntu webkit2gtk CVE-2026-3909 (2.52.6-0ubuntu0.26.04.1)
  期限: 2026-12-03 (あと29日)
  理由: Ubuntuが対応見送り(deferred)で修正版なし。CVEはChromeのSkia。(以下略)
  記録: tetsuharu (2026-11-03)

受容には、次の性質があります。

• 直ったわけではありません。 警告が「要対応」の数から外れ、「受容中」として別に数えられるだけです。一覧には残ります
• 期限があります。 既定は 90 日、最長は 365 日です。期限が来ると「要対応」に戻り、記録は残ります
• 理由が必須です。 あとから、誰が、なぜ受け入れたかを読めます
• その版にだけ効きます。 パッケージが別の脆弱な版に変わると、新しい検出として要対応になります

#期限が来たとき

期限は、見直しの予定日です。期限の日に、次の順で確かめます。

1. 修正版は出ましたか(apt-cache policy と、ベンダーの脆弱性の管理表で確かめます)
2. このパッケージは、まだ必要ですか。使わなくなっていれば、削除します
3. 状況は変わりましたか(新しい使い方が増えた、細工されたデータを開く場面が出た、など)
4. それでも受け入れるなら、新しい理由を書いて、もう一度記録します

#見えない部分