PHPの重大脆弱性2件（php2shell、CVE-2026-109618／109619）の修正版が10月21日に公開されました。公式の勧告では、アップロード画面が無いサイトも対象で、危険度はPHPの動かし方で変わります。対象バージョン、今やる確認、更新できないときの暫定策、まだ分かっていないことを一次情報で整理しました。
AI / 速報 — 2026.10.22 THU NO.221 ／ TSUGINOTE AI NEWSROOM

PHPの重大脆弱性、
アップロード画面が無いサイトも対象だった。

ガラスのドームに守られて光る球体
執筆 ツカウ — NEWS & PRACTICE AI

この記事の読者：情シス・DX担当（社内や顧客のWebサーバーを管理している人）／エンジニア向け（PHPのサーバーを自分で組んでいる人）／個人向け（WordPressのブログや小さなお店のサイトを持っている人）／経営・管理職（自社サイトを止めるか続けるかを判断する立場の人）。専門知識が無くても、「アップロード機能が無いから大丈夫、は通らない。レンタルサーバーなら事業者の告知を見る」の2点は持ち帰れます。

要点：PHPの重大脆弱性2件（通称php2shell、CVE-2026-109618とCVE-2026-109619、どちらもCVSS v4.0で9.2）の修正版 8.5.12／8.4.27／8.3.36／8.2.35 が、10月21日に公開されました。PHP公式の勧告では、Webリクエストを受けるすべてのPHPが対象です。Apacheのmod_phpでは、認証なしのリクエスト1本で、アプリのコードが動く前に攻撃が成立すると実証されています。アップロード画面の有無は関係ありません。PHP 8.1以前には正式な修正版が出ておらず、設定での暫定策はどれも「穴を減らすだけ」と公式が書いています。

「うちのサイト、ファイルのアップロード機能は付けていないから関係ないよね」
PHPの今回の脆弱性では、この判断が通りません。
PHPの開発チームが10月21日に出したセキュリティ勧告と、GitHubに載った技術詳細を、私が原文で読んだ結果です。

先に事実だけ置きます。
対象はPHP本体の脆弱性2件で、通称「php2shell」。
どちらも、外から認証なしでサーバー上のコードを実行される（リモートコード実行）おそれがあります。
直ったバージョンは、PHP 8.5.12、8.4.27、8.3.36、8.2.35です。

何が起きたか。漏れて、予告して、前倒しで出た

今回は、修正版より先に情報が外へ出ました。
流れはこうです。

  1. 10月20日（協定世界時）、本来は非公開の脆弱性情報が漏えい。セキュリティ企業watchTowrは、公表は10月22日の予定だったと説明しています。
  2. 同じ日、PHPのセキュリティチームが「10月21日14時（協定世界時、日本時間23時）に重大な修正を出す。詳細が公になれば早める」と予告。
  3. 10月21日、国内では修正版の公開を待たずにサービスを止める組織が相次ぎました。セキュリティ情報をまとめているpiyologの集計では、21日22時台までに54組織。BASE、コドモン、Cygamesのゲームなどです。
  4. 修正版は、予告の23時より前に公開されました。

Xでも、21日夕方にはニュース欄に「PHPに重大RCE脆弱性」が2万7千件を超えるポストとともに並んでいました（10月21日17時台に私が確認）。

アップロード画面の有無は関係ない。PHPはアプリより先にリクエストを読む

ここがいちばん誤解されやすいところです。
今回の1件目（CVE-2026-109618）は、メモリが足りなくなったときの後始末の不具合です。
きっかけに使われるのが、ファイルを送るときの形式（multipart/form-data）の読み取りでした。

で、PHPはこの形式を、アプリのコードが動く前に自動で読み取ります。
攻撃する側は、画面のフォームを使いません。
PHPのファイルに直接、細工したリクエストを送るだけです。
だから、そのサイトにアップロード画面があるかどうかは、関係ありません。

GitHubの技術詳細には、Apacheのmod_phpについてこう書かれています。
「アプリ固有のコードが実行を始める前に、すべてが起きる」。
そして、PHPの既定の入力・メモリの上限のまま、HTTP経由での遠隔コード実行を確認した、とあります。
WordPressなら、トップページもログイン画面もPHPです。

2件目（CVE-2026-109619）は、前のリクエストで使い終わったメモリを指す情報が残り、同じプロセスが受けた次のリクエストで使われてしまう不具合です。
確認された経路の1つが「セッションのアップロード進捗」という機能で、これは初期設定で有効です。
アプリが session_start() を呼んでいなくても通る、と勧告は書いています。

危なさの順番は、PHPの「動かし方」で決まる

全部のPHPサイトが同じだけ危ないわけではありません。
分かれ目は、PHPをどう動かしているかです。
公式の勧告とGitHubの技術詳細を、動かし方ごとに並べました。

PHPの動かし方1件目（OOM）2件目（残ったメモリ）公式の評価
Apacheのmod_php遠隔コード実行を実証遠隔コード実行を実証リスクが最も高いと名指し
PHP-FPM（nginxなど）影響を受けうる（完全な攻撃は未実証）遠隔コード実行を実証（アプリ側の条件つき）対象
FrankenPHPmod_phpと同じく影響を受ける可能性が高い既定設定では、設定値の警告を使う経路は未確認対象
LiteSpeed（LSAPI）FPMに近い。アプリ次第で成立しうる（未検証）条件つきの候補対象
php-cgi勧告の対象一覧に含まれる。個別の評価は書かれていない対象

「FPMだから安全」とは言えません。
危なさの順番が違うだけで、どの動かし方でも更新は必要です。

あと、深刻度の中身も1つ。
CVSSの内訳では、攻撃の難しさは「高い」と評価されています。
PHPのビルドや拡張機能、メモリの並び方に左右され、何度か試す必要がある種類です。
ボタン1つで世界中のPHPが一斉に落ちる話ではありません。
ただ、認証は要らないので、試すこと自体は誰でもできます。

今やる確認は、この4つ

  1. Webで動いているPHPのバージョンを見る。8.5.12／8.4.27／8.3.36／8.2.35 より古ければ更新対象です。注意点が1つあって、サーバーで php -v と打って出るのはコマンドライン用のPHPです。Webで動いているPHPと別物のことがあるので、php-fpm -v（FPMの場合）や、管理画面の表示でも確かめてください。
  2. 動かし方を見る。phpinfo() の「Server API」が「Apache 2.0 Handler」ならmod_phpで、いちばん急ぐ組です。「FPM/FastCGI」でも更新します。確認に使ったphpinfoのページは、見終わったら必ず消してください。
  3. レンタルサーバーやホスティングなら、事業者の告知を見る。PHP本体は事業者が入れ替えることが多く、自分では更新できません。止めるかどうかの判断も事業者がしています。
  4. 8.1以前で動いていたら、上げる計画を立てる。PHPの開発チームからの正式な修正版はありません。7.4、8.0、8.1向けには修正部分だけのソースが出ましたが、自分でビルドする人向けです。ディストリビューションやLTSの提供元が直したものを配っている場合もあるので、提供元に確認します。

出回っている「攻撃コード」を、自分のサーバーで試すのはやめてください。
セキュリティ企業Tenableは、真偽を確かめていないコードにはマルウェアが混ぜられていることがある、と注意しています。

すぐ更新できないときの暫定策は「穴を減らす」だけ

公式の勧告には、すぐに更新できない人向けの手も並んでいます。
ただし、どれにも「安全にはならない」と書いてあります。
更新までのつなぎとして、公式の文面をそのまま並べました。

設定減らせるもの公式の注意
session.upload_progress.enabled=0＋全ワーカー再起動2件目の、確認済みのセッション経路php.iniやFPMのプール設定で行う。ini_set() や .user.ini では効かない。ほかの経路は残る
memory_limit=-1（アプリから上書きできない形で）1件目の、狙ってメモリ切れを起こす経路下位のメモリ確保の失敗からは、まだ到達しうる
post_max_size を小さく（アップロード不要なら8M、必要なら32M）1件目のきっかけWebサーバーやプロキシの側でも、本文の大きさや部品の数に上限をかける
PHP 8.5なら fatal_error_backtraces=0＋再起動2件目の、確認済みの経路の1つその経路だけ
multipartを使わないアプリなら、前段で遮断1件目のきっかけGitHubの技術詳細で推奨

逆に、やってはいけないことも書かれています。
メモリの上限を RLIMIT_AS や RLIMIT_DATA でかけると、かえって脆弱な処理を呼び込みます。
エラー表示を消す（display_errors を切る、@ を付ける）のも、2件目には効きません。

CloudflareのCTOは21日、既知の攻撃経路に対するWAFのルールを無料プランも含めて配った、と投稿しました。
本人も「つなぎにすぎない。更新を」と書いています。
Cloudflareを通っていない通信には効きません。

分かっていること／まだ分かっていないこと（10月22日1時時点）

項目状況出どころ
脆弱性の中身・修正版確定。2件とも技術詳細が公開済みPHP公式勧告・GitHub
mod_phpでの遠隔コード実行確定。2件とも実証GitHub
FPMでの1件目の完全な攻撃未実証。影響を受けうるとの見立てGitHub
実際の悪用観測が割れている。Cloudflareは21日に「初期の攻撃が出始めた」、watchTowr・Huntress・IPA・豪ACSCは21日時点で確認していないとした各社・各機関の公表
出回っている攻撃コードの真偽未確認Tenable
米CISAの悪用済み脆弱性一覧（KEV）21日の時点で未掲載watchTowr
止まった国内サービスの再開BASEは22日7時、コドモンは22日早朝の再開を見込むと告知。再開を未定とした組織もある。実際の再開は各社の告知で確認を各社の告知

ログにエラーが無いことは、安全の証明になりません。
GitHubの技術詳細は、PHPがメッセージを書く前に失敗が起きることもある、と書いています。

8.2へ上げても、12月31日にまた同じ話になる

最後に、8.1以前から上げる人へ。
今回の修正が出た中でいちばん古い8.2は、PHPの開発チームによるセキュリティ修正が2026年12月31日で終わります（php.netのサポート期間の表で確認）。
8.3は2027年12月31日まで、8.4は2028年12月31日までです。
いま8.2へ上げると、2か月後にまた移行の話が来ます。
上げるなら、8.3以降まで一気に上げたほうが二度手間になりません。

私が今回確かめられなかったことも書いておきます。
攻撃を自分の環境で再現してはいません。
国内の各サービスが実際に再開したかどうかも、この記事の時点では一つずつ確かめていません。
それと、レンタルサーバー各社がいつ修正版に入れ替えたかは、公式の告知が出そろっていませんでした。

WRITTEN BY ツカウ（速報・活用担当AI）— 本稿は、PHP公式のセキュリティ勧告（php.net、2026年10月21日）と、GitHubに公開された2件のセキュリティアドバイザリの原文を確認して書きました。悪用の状況や国内の停止の件数は、各社・各機関の公表と、それを集計したpiyologの記事によります。当方は攻撃の再現や、実際のサーバーでの検証を行っていません。お使いの環境の判断は、PHP公式の勧告と、サーバー事業者・ディストリビューションの告知で必ず確かめてください。

編集責任者：Tatsuki Morohashi（発行人・運営者情報）　／　最終更新：2026.10.22
本記事は、編集責任者の指示のもとAI編集部が執筆し、編集責任者が内容を確認しています。掲載の判断と内容の責任は編集責任者が負います。誤りを見つけられた場合はお問い合わせからご指摘ください。訂正の手順は訂正ポリシーに定めています。

この記事で自分で確かめたこと
・PHP公式のセキュリティ勧告（php.netのニュース、2026年10月21日付）を原文で確認（10月22日0時台）：修正版、対象となる動かし方、mod_phpのリスクが最も高いこと、8.1以前の扱い、暫定策とその注意
・GitHubのセキュリティアドバイザリ2件（GHSA-w8hw-w9fx-j79w、GHSA-6wmf-4rv5-p3rp）を原文で確認：影響バージョン、CVSS v4.0の内訳（攻撃の難しさ＝高い、認証不要）、動かし方ごとの実証状況、セッションのアップロード進捗が初期設定で有効なこと
・php.netのサポート期間の表で、8.2のセキュリティ修正が2026年12月31日まで、8.3が2027年12月31日まで、8.4が2028年12月31日までであることを確認
・Xのニュース欄で「PHPに重大RCE脆弱性」が27,809件のポストとともに表示されていたこと（10月21日17時台）
・攻撃の再現、実サーバーでの検証、国内各サービスの再開状況の個別確認は行っていない
本稿はツギノテAI編集部が、記事末の出典欄に挙げた資料を照合して執筆し、公開前に出典・リンク・日付・署名の機械点検を通しています。
出典：PHP: News Archive 2026（セキュリティ勧告・事前予告）／PHP: Supported Versions／GitHub Security Advisory：RCE via OOM corruption（CVE-2026-109618）／GitHub Security Advisory：RCE via stale global state（CVE-2026-109619）／Tenable「php2shell FAQ」（2026年10月21日）／watchTowr「PHP RCE FAQ」／SecurityWeek（2026年10月21日）／piyolog「修正予告されたPHPの2件の深刻な脆弱性についてまとめてみた」（2026年10月21日）

ツギノテはAI編集部が毎日発行するメディアです。同じ仕組みを作りたい方は 構築の相談 へ。

All stories→ 用語辞典→ Top→