Webが崩れる日 ― ここ数日の“修正ラッシュ”が示す、C言語時代の性善説の限界

「Webが崩壊するのか」と思った1週間

この1週間、運用保守の現場は修正対応に追われました。10月13日には、Microsoft製品の10月のセキュリティ更新が過去最多の1,413件、20日にOracle Javaが55件、21日にはPHPの「緊急」2件（通称PHP2Shell）が公開されました。

PHP2Shellの日は、国内の大手サービスが相次いで緊急メンテナンスに入りました。認証なしのリクエスト1つで、アプリのコードが動く前にサーバを乗っ取れるという内容です。正直、「Webそのものが崩れ始めたのか」と思いました。

私が担当するシステムはPHPを使っておらず、直接の影響はありませんでした。それでも朝10時から顧客からの問い合わせが続き、確認と説明に半日以上かかりました。そこで改めて、なぜこうも修正が続くのかを考えてみました。

この10日間に起きたこと

10月13日から22日の10日間で、主なものだけでも次のとおりです。

日付（2026年）	対象	内容
10月21日	PHP（PHP2Shell）	CVSS 9.2（v4.0）の緊急2件。認証なしで遠隔から任意のコード実行。公開4日前の17日に悪用の試みを確認
10月21日	国内の大手サービス	pixiv、DMM.com、niconico、BASEなどが緊急メンテナンスや一時停止
10月21日	Oracle Java（臨時）	CVSS 9.1（v3.1）。暗号学的に弱い鍵を使ったeMudhra関連の中間証明書の問題に対応し、偽のTLS証明書を信頼するリスクを防ぐ緊急修正が公開された。
10月20日	Oracle Java（定例）	Java SEの脆弱性55件。うち49件は認証なしでネットワーク経由で悪用できる
10月13日	Windows Update	Microsoft製品で過去最多の1,413件（初の4桁）。うち緊急76件、悪用確認済み1件

CVSSは脆弱性の深刻さを10点満点で表す指標で、9.0以上は「Critical（緊急）」に分類される深刻な水準です。実際の対応優先度は、悪用状況やシステムへの影響も踏まえて判断する必要がありますが、迅速な確認と対策が求められます。それが同じ週に2つの土台で出ました。

PHPだけではありません。Javaでは、認証局に関連する中間証明書の信頼性に問題が見つかり、定例更新の翌日に臨時の修正が公開されました。認証局は「この相手は本物だ」と保証する役割を担います。その信頼の仕組みに問題があれば、偽の証明書を使って正規のサーバーになりすまされるおそれがあります。実行環境と、通信相手を信頼する仕組み。Webを支える土台が、同じ週に2箇所で揺らいだことになります。

特にPHP2Shellの2件は、どちらもメモリの扱いの不備です。

CVE-2026-109618：メモリ不足で処理が途中で止まると、初期化しかけのデータを正しいものとして扱ってしまう。
CVE-2026-109619：解放済みのメモリを指す内部情報が残り、次のリクエストがそれを使ってしまう。

PHP本体はC言語で書かれています。PHPで書いたアプリがどれだけ丁寧に作られていても、土台となるC言語の部分に脆弱性があれば、アプリ側の対策だけですべてを防ぐことはできません。

根っこにあるのは「C言語の性善説」

C言語の特徴の一つは、メモリ管理をプログラマに大きく委ねていることです。メモリを確保する、使い終わったら解放する、配列の範囲を超えてアクセスしない。こうした管理の多くを、プログラマ自身が正しく行う必要があります。

1970年代当時は、現在のように不特定多数からの悪意ある入力に常時さらされるWeb環境が一般的ではありませんでした。限られたメモリや計算資源の中で、プログラマがメモリ管理を担う設計には合理性がありました。

ところが今は、世界中の誰からでも入力が届きます。そしてOS、ブラウザ、Webサーバ、PHPやJavaの実行環境といった土台の多くは、今もCやC++で書かれています。性善説の設計の上に、性悪説の世界が乗っているわけです。

数字もそれを裏付けています。

Chromeの開発元は、重大なセキュリティバグの約70%がC/C++のポインタの扱いの誤りだと公表しています（Chromium）。
米国CISAは、メモリ安全でない言語で報告される脆弱性の約3分の2がメモリの問題だとしています（CISA）。

もちろん、すべての脆弱性がメモリに起因するわけではありません。今回のJavaの臨時対応も、認証局に関連する暗号鍵の脆弱性が原因です。それでも、メモリ安全性の問題が深刻な脆弱性を生む大きな要因であることは確かです。

「人を信じない言語」への移行はもう始まっている

解決策ははっきりしています。メモリの扱いに関する誤りを防ぐ仕組みを備えた「メモリ安全言語」（Rust、Go、Java、C#など）に移ることです。

GoogleはAndroidの新しいコードを主にRustなどで書くようにしました。その結果、脆弱性に占めるメモリ問題の割合は、2019年の76%から2024年には24%まで下がりました（Help Net Security）。古いCのコードを全部書き換えたわけではなく、「新しく書く分だけ」を切り替えただけでこの効果です。

米国のCISAなども、ソフトウェアメーカーに「メモリ安全への移行計画を公開せよ」と求めています（CISA）。性善説から性悪説へ、設計思想そのものを切り替える流れです。

ただし、土台の入れ替えには10年単位かかります。その間、今回のような修正ラッシュは続くと覚悟したほうがよさそうです。

運用保守の現場で今できること

言語の移行を待つ間にも、現場でできることはあります。今回の対応で効いたものを挙げます。

自分たちの「土台」を一覧にしておく。OS、Webサーバ、実行環境（JavaやPHP）の種類とバージョンがすぐわかれば、「影響あり／なし」をその日のうちに答えられます。
使っていないものを残さない。使わなくなったソフトの残骸は、影響調査の手間と攻撃の入口を増やすだけです。
古いバージョンを放置しない。サポートが切れた版には修正版が出ません。PHPも今回、8.1以前は正式な修正版の対象外でした。
修正を当てる手順を決めておく。事前の影響確認、検証環境での試験、2名での作業、作業後の確認。型があれば、急な修正でも慌てずに済みます。
「新しく作るならメモリ安全言語で」を提案する。更改や新規開発のたびに、言語選びを安全性の観点からお客様と話し合います。