TITLE

PHPの緊急脆弱性2件(CVE-2026-109618/109619)で国内サービスが相次ぎ緊急メンテナンス——対象と今すぐの対応

投稿日：2026.10.22

二つのCVEとは何か — 二つの壊れ方が、同じ未認証RCEに合流する

今回の緊急リリースで修正されたのは、原因の異なる2つの脆弱性です。

CVE-2026-109618(GHSA-w8hw-w9fx-j79w)は、メモリ不足(OOM、Out of Memory)が起きた際にPHPの内部状態が破損することを悪用した脆弱性です。ITmediaの報道によれば、リクエストの内部データを初期化している最中に処理が中断され、終了処理の段階で不完全なデータがそのまま正常なものとして扱われてしまう不具合です。mod_php(ApacheにPHPを直接組み込む実行方式)では、アプリケーション側のコードが実行される前の段階、つまり自社で書いたコードの内容に関係なく、未認証のリクエストだけで発動することがデフォルト設定のまま実証されています。

CVE-2026-109619(GHSA-6wmf-4rv5-p3rp)は、use-after-free(解放済みメモリの再利用。ITmediaの表現では「リクエストが使ったメモリ解放後も内部状態が残り、別リクエストがそれを使ってしまう」不具合)を悪用した脆弱性です。あるリクエストの処理が終わってメモリが解放された後も、古い(stale)内部状態が残り続け、次に来た別のリクエストがその残骸を参照してしまいます。

CVE-2026-109618(メモリ不足による状態破損)とCVE-2026-109619(use-after-free)という2つの原因が、同じ「未認証のリモートコード実行(RCE)」という結果に合流する概念図

二つの脆弱性は、壊れ方そのものは別物です。一方はメモリが足りなくなった時に起きる破損、もう一方は解放済みメモリの使い回しです。しかし、どちらも「本来ならあり得ないはずの内部状態」を作り出し、そこを起点に未認証のリモートコード実行へとつながるという点で、行き着く先は同じです。ログインも、特別な設定も、プラグインの導入も要りません。メモリ不足という、アクセス集中時などに日常的に起こり得る状態だけが引き金になります。影響を受けるのはPHP-FPM、Apacheのmod_php、php-cgi、FrankenPHP、LiteSpeedで、特にmod_phpが最も危険とされています。サポート対象外の7.4・8.0・8.1向けにも、最小限の修正ソースコードが公開されました。

なぜこれほど影響が広いのか — 対象ミドルウェアと裾野の大きさ

今回の脆弱性が影響するのは、特定のCMSやフレームワークではなく、PHPを動かす実行環境そのものです。PHP-FPM・mod_php・php-cgi・FrankenPHP・LiteSpeedのいずれかでPHPを動かしているなら、その上でどんなアプリケーションを書いているかに関わらず対象になり得ます。

ITmediaの報道では、米W3Techsの調査として「サーバー側言語が判明しているWebサイトの約7割がPHPを使用している」という数字が引用されています。特定の業種やシステムに限った話ではなく、PHPという実行環境を使っているかどうかだけが条件になる点が、対象の広さにそのまま直結しています。

国内で何が止まったか — 一斉に止まった著名サービス

複数の店舗のセキュリティシャッターが高さを揃えず一斉に下りている様子を描いたフラットイラスト。国内の著名サービスが一斉に緊急メンテナンスに入った状況の比喩

ITmediaの報道によれば、コドモン・BASE・Cygames・ニコニコ・pixiv・静岡銀行・阪急電鉄などが公式サイトやWebサービスを一時停止・緊急メンテナンスとしました(pixivなどは既に再開しています)。レンタルサーバ各社でも、さくらインターネット・XServer・GMOペパボが緊急メンテナンスを実施しました。

因果関係の確度には差があります。報道の中で今回のPHPの脆弱性が原因だと明確に確認されているのは、オンラインゲーム「Shadowverse: Worlds Beyond」、法人向けサービス「キンブル」「pictSQUARE」、そして「BASE」です。一方でコドモンやさくらのレンタルサーバについては、「影響とみられる」という段階の報道にとどまっており、各社が脆弱性を名指しで原因と公表したわけではありません。自社の障害が今回の脆弱性によるものかどうかを判断するには、各社の公式発表とバージョン確認の両方を自分で照合する必要があります。

国家サイバー統括室も可及的速やかな対応を求め、高市早苗首相も公式Xアカウントで対応を呼びかけました。

今すぐやるべき対応 — 唯一の安全な選択肢はアップデート

まず、稼働中のPHPのバージョンを確認してください。8.5.12・8.4.27・8.3.36・8.2.35、またはそれ以降であれば対応済みです。未満であれば、速やかに更新してください。サポート対象外の7.4・8.0・8.1系を使っている場合も、最小限の修正ソースコードが公開されているため、適用を検討してください。

すぐにアップデートできない事情がある場合の暫定策として、ITmediaはメモリ使用量の上限を解除すること、アップロード状況をセッションに記録する機能を無効化することの2つを挙げています。前者は脆弱性の引き金になるメモリ不足の状態そのものを避ける方向の対処、後者は攻撃経路の一つを塞ぐ対処です。ただし、ITmediaが明記しているとおり、これらは完全な緩和策ではなく、唯一の安全な選択肢はアップデートです。暫定策は「今すぐ更新できない間の時間稼ぎ」であって、恒久対処の代替にはなりません。

自社でホスティング・運用を委託している場合は、委託先が今回のリリースに対応済みかどうかの確認も忘れないでください。

なぜ複数の目に同時に見つかったのか — 強化された発見体制

PHP Foundationの公式ブログによれば、今回の脆弱性はもともと2026年8月11日、研究者のRyan A氏(ハンドル名Calif)がOOM問題と、同じ根本原因から生じる無条件のリモートコード実行を報告したことから始まっています。同じ8月11日、OpenAIも独立して同じ根本原因を報告し、9月18日には追加の攻撃経路も報告しました。Wizも8月24日に別途報告しています。加えて、Trail of Bitsが現在進めているPHPの監査、そしてQuarkslabによる2024年の外部監査の最中に、コア開発者がOOM問題の初期の兆候を既に見つけていたことも明らかにされています。

複数の独立した主体が、ほぼ同じ時期に同じ根本原因へたどり着いた背景には、PHP Foundationが2026年5月に設立したEcosystem Security Teamがあります。AIセキュリティエンジニア・イン・レジデンスとしてVolker Dusch氏が参加し、7月にAlexandre Daubois氏、9月にDaniel Scherzer氏が加わりました。意思決定プロセスも、合意形成型から多数決併用へ見直しが進んでいます。OpenAIのDaybreak Redのような、AIを使った脆弱性検証やサニタイザービルドの導入も進められています。体制の強化が、発見を一度きりの偶然でなく繰り返し起こる仕組みに変えつつあることがうかがえます。

まとめ

今回の脆弱性の実体は、原因の異なる二つの不具合(OOMによる状態破損とuse-after-free)が、同じ未認証RCEという結果に合流する構造でした。条件はログインもプラグインも不要でメモリ不足というありふれた状態のみ、暫定策はあっても完全な緩和策ではなく、唯一の安全な選択肢はアップデートです。次に同種の緊急リリースが出たときに効くのは、公表を見てからPHPの実行環境を洗い出すことではなく、自社のどのサービスがPHP-FPM・mod_php・php-cgiのどの経路で動いているかを、今のうちに一覧にしておくことです。