オープンソースで不完全なセキュリティパッチが急増

セキュリティパッチは脆弱性を無力化する一方で、次の攻撃への道筋を直接示してしまうことがあります。サイバーセキュリティ企業の Terra Security は最近、セキュリティパッチが攻撃者にとっての「地図」になった経緯を調査しました。研究者らは公開されているCVEレコードとGitHubのセキュリティアドバイザリを調べ、繰り返し発生する欠陥を追跡しました。その結果、オープンソースのバグ修正に対して、さらなる修正が必要になるケースが増えていることが明らかになりました。

不完全な脆弱性修正が急増

2019年から2025年にかけて、GitHubのセキュリティアドバイザリのうち、90日以内に二次的な警告が出されたものは約0.2%でした。しかし、この割合は2026年に2.3%へと急上昇しました。測定の基準によって異なりますが、8倍から11倍に増えた計算です。開発者が意図せず、重要なソフトウェアリポジトリに脆弱性の名残を残していることになります。

Linuxカーネルでも二次的な欠陥が発生

Linuxカーネルでは、この問題は設計面での微妙なリグレッション（退行）として現れています。2026年10月までのテレメトリによると、新たにカタログ化されたカーネルの脆弱性のうち3.2%が、過去のバグ修正に起因していました。さらに、fs/smbやnet/schedなど開発が活発なサブシステムでは、その割合が約10%に達しています。

Unixソケットの脆弱性が連鎖

一例が、LinuxのUnixドメインソケットをめぐる一連の欠陥です。2023年のコード変更により、特殊なメッセージ転送時のファイルディスクリプタの管理が乱れました。その結果、最初のパッチは高負荷時にカーネルのハングを引き起こしました。続く修正もリストの順序に関する問題があり、不完全でした。最終的にメンテナーは、本質的には一つの設計上の欠陥であるにもかかわらず、複数のCVE識別子を登録せざるを得なくなりました。

Webアプリケーション防御で繰り返される回避

攻撃者が最も頻繁に回避するのは、サーバーサイドリクエストフォージェリ（SSRF）とJavaScriptのプロトタイプ汚染に対する修正です。実際、これらの脆弱性では、不完全な修正が想定の4.6倍と11倍の頻度で発生しています。入力検証が限定的であることが、こうした再発の原因になるケースが多くあります。

限定的な入力検証が容易な回避を招く

プログラマーが特定の悪意あるIPアドレス1つだけを遮断し、同等の別表記を見落とすことがよくあります。Roundcubeウェブメールでは、セキュリティ更新で127.0.0.1は遮断されましたが、127.1や16進数表記などの形式は見落とされていました。その結果、メンテナーは問題を解決するために3回連続で更新を配布する必要がありました。同様に、研究者らはPaperCutの更新を、最初のリリースから24時間以内に回避しました。

自動監査でパッチ解析が加速

Terraは、実際に悪用されているバグでは、その後のパッチ回避が4倍に増えていることを突き止めました。一方で、人工知能（AI）ツールがリバースエンジニアリングを加速させています。9月には、研究者らがAIモデルを使い、複雑なMikroTikのパッチを1時間以内に逆アセンブルしました。ただしアナリストは、アルゴリズムによるツールだけでは、欠陥のある更新が全体的に増えている理由を説明できないと指摘しています。

そのためTerraは、ソフトウェアチームに対し、配布前に別のエクスプロイト手法でもパッチをテストするよう勧めています。開発者は、表面的なフィルターで済ませるのではなく、根本原因に対処しなければなりません。さらにネットワーク管理者は、パッチを適用したからといって安全が完全に保証されるとは考えるべきではありません。回避経路がすべて確実に塞がれていることを、厳密なリグレッションテストで確認する必要があります。