パッチの出ない脆弱性 — 修正すべき製品コードが無いとき、対処は「削除」になる

脆弱性対応の手順は、たいてい「影響バージョンを調べる」から始まる。手元のバージョンが影響範囲に入っていれば対処、入っていなければ対象外。この判定が効くのは、脆弱なコードが製品の中にあり、修正版が出るという前提が成り立つときだ。

その前提が崩れる種類の脆弱性がある。IBM webMethods Integration Server の CVE-2026-12118 がそれだった。CVSS 3.1 で 9.8 Critical、未認証のリモート攻撃者による任意コード実行。それでいて IBM のセキュリティ速報には、こう書かれている。

No product patch or software update is required.
（製品パッチもソフトウェア更新も不要）

パッチが「まだ出ていない」のではない。出す予定が無い。この記事では、なぜそうなるのか、そしてこの形の脆弱性をどう切り分けるのかを、IBM の速報の記述をもとに整理する。

掲載は 脆弱性対応ウォッチ にもある。

何が起きていたか

NVD の記述は簡潔である。

IBM webMethods Integration (on prem) 10.15, 10.11 could allow an unauthenticated remote attacker to execute arbitrary code on the system due to the deserialization of untrusted data.

信頼できないデータのデシリアライズによる未認証RCE。CWE は CWE-502。ここまでは典型的なデシリアライズ脆弱性に見える。

問題はその先だ。IBM の速報の Summary 欄にはこう書かれている。

WmServiceMock is bundled with IBM webMethods Integration Server.
（WmServiceMock は IBM webMethods Integration Server に同梱されている）

つまり脆弱なのは Integration Server 本体ではなく、同梱されている WmServiceMock という別のパッケージである。そして IBM は Vulnerability Details に続く Background 欄で、その性格をはっきり書いている。

The WmServiceMock package relies on Integration Server authentication and does not implement a separate authentication mechanism. This package is a development-time testing utility designed exclusively for development and testing environments.

要点は2つある。

  1. WmServiceMock は Integration Server の認証に依存しており、独自の認証機構を持たない
  2. これは開発時のテスト用ユーティリティであり、開発・テスト環境専用に設計されている

CVSS の内訳を見ると、この性格がそのまま出ている。

項目 値 意味
CVSS Source IBM 採番元が自社評価
Base score 9.8 Critical
ベクタ AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H ネットワーク越し・低複雑度・認証不要・利用者操作不要

PR:N（権限不要）がこの脆弱性の中心である。認証に依存する設計なのに、その認証が期待どおりに効いていない経路が残っている。

CISA の KEV には、本稿の確認時点（2026-08-25・カタログ 2026.08.24・1,675件）で収載されていない。

なぜパッチが出ないのか

ここが本題である。IBM の立場を整理するとこうなる。

このパッケージは、そもそも本番に置くものではない。

開発時のモック用ユーティリティを本番の Integration Server ノードに配備しているという状態自体が、想定外の構成である。想定外の構成のために製品コードを書き換えるのではなく、その構成をやめてもらう。だから required action はこうなる。

Remove the WmServiceMock package from any production Integration Server node. The package should not be deployed on internet-facing or production systems.

判断としては筋が通っている。仮に WmServiceMock に独自認証を実装したとしても、それは「本番に置いてよいテスト用モック」を作ることになり、別の問題を生む。機能を安全にするのではなく、その機能が居るべきでない場所から取り除く。

同じ発想の修正は他でも見る。前日に扱った Google の mcp-toolbox（CVE-2026-14537）も、認可の穴を塞ぐのではなく「その構成では起動させない」という起動時チェックで修正された。危険な構成を成立させないほうが、危険な構成を安全にするより確実だという判断である。

バージョンで判定できない

この形の脆弱性が運用上やっかいなのは、影響バージョンが判定の役に立たない点だ。

NVD の Affected は「10.15, 10.11」である。普通ならここで 10.15 を使っているか？ を調べる。だが実際の危険度を決めているのは、そのノードに WmServiceMock が入っているかどうかである。

この2つは一致しない。

  • 10.15 を使っていて WmServiceMock を削除済み → 該当しない
  • 10.15 を使っていて WmServiceMock が残っている → 未認証RCEの入口が開いている

つまり資産管理台帳の「バージョン」列だけを見て回答を作ると、実態と合わない。

WmServiceMock が本番に残る経路は、だいたい次のどれかだ。

  1. インストール時の既定構成をそのまま使っている — 同梱されているので、意識して外さない限り入る
  2. 開発環境から複製して本番を作った — 検証済みの構成をそのまま持ってくると、開発用の部品も付いてくる
  3. 仮想マシンイメージ／コンテナイメージに焼き込まれている — ノード上で消しても、再デプロイで戻る

3つ目が一番厄介である。手作業で削除しても、次のデプロイで元に戻る。イメージのビルド定義まで遡らないと消えない。

実際の確認と削除

IBM の速報には手順がそのまま書かれている。

1
2
3
4
5
6
1. Integration Server にログインする
2. Packages > Management へ移動する
3. パッケージ一覧から WmServiceMock を探す
4. WmServiceMock の隣の Delete アイコンをクリックする
5. 確認を求められたら削除を承認する
6. Integration Server を再起動する

6番の再起動まで行って完了である。削除操作だけでは、稼働中のプロセスにロードされたままの可能性が残る。

複数ノードを抱えている場合、画面から1台ずつ確認するのは現実的ではない。webMethods のパッケージはファイルシステム上のディレクトリとして配置されるので、ノード上で存在確認だけなら次のように取れる。

1
2
# パッケージディレクトリの存在確認（IntegrationServer のインストール先に読み替える）
find /opt/softwareag/IntegrationServer -maxdepth 3 -type d -name 'WmServiceMock' -print

複数ホストへ一斉に投げるなら、こうなる。

1
2
3
4
5
6
7
8
9
10
11
# hosts.txt に対象ホストを1行1件で置く
while read -r host; do
  result=$(ssh -o BatchMode=yes -o ConnectTimeout=5 "$host" \
    "find /opt/softwareag/IntegrationServer -maxdepth 3 -type d -name WmServiceMock -print 2>/dev/null" \
    </dev/null)
  if [ -n "$result" ]; then
    echo "FOUND   $host: $result"
  else
    echo "clean   $host"
  fi
done < hosts.txt

ssh に -o BatchMode=yes を付けているのは、鍵が通らないホストでパスワード入力待ちに入って全体が止まらないようにするためだ。</dev/null は ssh が while read の標準入力を食ってループが1周で終わる、よくある事故を防ぐためのもの。この2つが無いと、一斉調査のつもりのスクリプトが1台目で沈黙する。

ただし存在確認と削除は分けたほうがよい。削除は Integration Server の管理画面から行い、ファイルシステム側は「どのノードに残っているか」を数えるためだけに使う。ディレクトリを直接消すと、パッケージ管理の状態と食い違う可能性がある。

削除の前に1つ確認しておくことがある。本番の連携フローが WmServiceMock に依存していないか。依存していれば、それ自体が設計上の問題であり、削除ではなく作り替えが必要になる。依存が無ければ、そのまま消して差し支えない。

完了条件をどう書くか

この脆弱性の対応記録には、書き方の落とし穴がある。

書いてはいけない完了条件:

  • 「10.15 へアップグレード済み」 → バージョンでは直らない
  • 「次期 fix pack の適用を計画中」 → 適用しても消えない
  • 「インターネットに面していないため対象外」 → 内部からの攻撃でも PR:N は成立する

書くべき完了条件:

  • 全本番ノードのパッケージ一覧に WmServiceMock が無いことを実測で確認した
  • 削除後に Integration Server を再起動した
  • コンテナ／VMイメージのビルド定義から WmServiceMock を外した（再デプロイで戻らない）

3つ目を入れておかないと、対応した数か月後に次のイメージ更新で静かに元へ戻る。一度きりの削除で終わる脆弱性ではなく、構成管理の問題として扱う必要がある。

そして「本番」の範囲は広めに取る。抜けやすいのは、検証用に立てたまま外部に出ているノード、災害対策サイトの待機系、そして開発環境から複製して作った本番ノードである。インターネットへの露出は優先度を決める材料であって、該当有無の判定材料ではない。

まとめ

CVE-2026-12118 から取れる一般的な教訓は3つある。

  1. 「パッチが無い」は「対処法が無い」ではない。 修正すべき製品コードが存在しない種類の脆弱性がある。速報の Remediation 欄を最後まで読む
  2. バージョンで判定できない脆弱性がある。 影響バージョンの一致は必要条件であって十分条件ではない。実際に何が入っているかを見る
  3. 開発用の部品が本番に居ること自体がリスクである。 同梱されているものは、意識して外さない限り本番まで付いてくる

3つ目は、この製品に限った話ではない。デバッグ用エンドポイント、テスト用の認証バイパス、サンプルアプリケーション。いずれも「開発では便利で、本番では入口になる」という同じ性質を持つ。同梱物の棚卸しは、脆弱性が出てから始めるものではない。

クラウド・インフラ
#脆弱性対応 #デシリアライズ #IBM #資産管理 #運用設計
パッチの出ない脆弱性 — 修正すべき製品コードが無いとき、対処は「削除」になる
https://blog.hashito.biz/2026/08/25/ibm-webmethods-cve-2026-12118-dev-only-package-in-production/
著者
hashito
作成日
2026年8月25日
著作権