セキュリティパッチが攻撃者にとっての「地図」になりつつあります。公開された修正のうち、後から不完全だったりバイパス可能だったりすると判明するものの割合が増えているためです。
Terra Securityのセキュリティ研究者Oren Yomtov氏は、過去1年間、自社チームの業務で不完全な修正に繰り返し遭遇したことをきっかけに、この問題の追跡を始めました。
「修正が公開されるとバイパスが見つかり、さらに別の修正が出る、という繰り返しでした。サンプルの偏りではないかと考え、公開されているすべてのCVEレコードと、GitHubがレビュー済みのすべてのアドバイザリを調べました。注目したのは、修正が公開された後に、後続のアドバイザリで『不完全だった』『バイパスできる』と指摘されたケースです」
「データは私たちの見立てを裏付けました」と、同氏はブログで述べています。「不完全な修正の報告は、長年にわたり低い水準で安定して推移していました。ところが2026年には、GitHub上のオープンソースの修正のうち、後から不完全と報告されたものの割合が約8倍に跳ね上がりました」
悪用された脆弱性とブロックリスト型の修正ほど破られやすい
CISAの「Known Exploited Vulnerabilities（既知の悪用された脆弱性）」カタログに載っている脆弱性の修正は、同じベンダーの他の脆弱性と比べて、後から不完全と報告される頻度が約4倍に上ります。Yomtov氏は、その理由を注目度の高さにあるとみています。悪用された脆弱性はパッチを解析する人が増え、修正の見落としも見つかりやすくなるということです。
サーバサイドリクエストフォージェリ（SSRF）やプロトタイプ汚染など、典型的な修正が「ブロックする入力のリスト」になる種類のバグは、CVE全体と比べて、不完全な修正の中ではるかに多く見られます。ブロックリストがあらゆる形式の不正な入力を想定していなければ、攻撃者は通り抜けられる入力を1つ見つけるだけで済むと、Yomtov氏は説明しています。
オープンソースのWebメールソフトウェアであるRoundcubeが一例です。2026年3月、開発者はSSRFの脆弱性（CVE-2026-35540）に対し、プライベートアドレスへのリンクをブロックすることで対処しました。しかし、このチェックは同じアドレスの別の表記や、そのアドレスに名前解決されるドメイン名を見逃していました。この抜け穴をふさぐために、5月、7月、8月と、さらに3件のCVEが公開されています。
Microsoftは2026年2月、APT28グループが実環境で悪用していたWindowsシェルの脆弱性CVE-2026-21510にパッチを適用しました。その後Akamaiは、細工したコントロールパネル項目を使うとこのパッチをバイパスでき、Windowsが攻撃者のサーバに接続してユーザーのNTLMハッシュが漏えいすることを発見しました。Microsoftは4月、このバイパスをCVE-2026-32202として修正しましたが、この脆弱性もCISAの悪用リストに加わりました。新しいアドバイザリには、以前のCVEへの言及がありません。
開発者と防御側へのアドバイス
報告された入力だけをブロックするパッチは、バグが対処済みであるかのように見せかけながら、根本のコードには問題を残したままにしかねないと、Yomtov氏は指摘します。しかも、そのパッチは攻撃者に、脆弱なコードと、防御側がバグをどう捉えていたかの両方を示してしまいます。
「修正を公開する前に、自分でその差分を攻撃者の目線で調べてください。攻撃者より先にやることが肝心です」と同氏は助言し、開発者に対して、修正が根本原因に対処できているか、そしてバグのクラス全体をカバーしているかを確認するよう促しています。
パッチを適用する組織に対しては、ベンダーが悪用された脆弱性を修正すれば、そのパッチを読み解いて回避方法を探す人が必ずいると想定するよう勧めています。また、スキャナが問題なしと報告した後も、テストを続けるべきだとしています。
翻訳元: https://www.helpnetsecurity.com/2026/10/20/ncomplete-security-patches-broken-fixes-rise/
