PHPの脆弱性「php2shell」とは?WordPressとレンタルサーバーに何が起きているのか

php2shell(CVE-2026-109618、CVE-2026-109619)を示す文字画像
「php2shell」とは何か——PHPの脆弱性で、国内の主要サービスが止まった理由 | AI Global Times

「php2shell」とは何か——PHPの脆弱性で、国内の主要サービスが止まった理由

独自分析

PHPに見つかった重大な脆弱性「php2shell」への対応で、2026年10月21日は、国内のサービスが次々と止まった。ゲーム、通販、行政のシステム、レンタルサーバーまで、止まった範囲は広い。いま分かっていること、まだ分からないこと、そしてサイトを運営している人が確認しておきたいことを、順番に整理する。

php2shellとは何か

php2shellは、PHPのエンジン部分に見つかった2件の重大な脆弱性につけられた通称だ。識別番号はCVE-2026-109618とCVE-2026-109619。深刻度の目安であるCVSS v4.0は、2件とも9.2で、最も重い「Critical」に入る。

PHP Foundationの説明を、できるだけ平たく言い直すとこうなる。

CVE-2026-109618

メモリの上限に、ちょうど悪いタイミングで達すると、PHPの内部に「中途半端な状態のデータ」が残る。PHPはそれを正しいものと思い込み、メモリを壊してしまう。Apache + mod_phpの環境では、ログインなどの認証なしで送れるリクエストでも、アプリのプログラムが動き出す前に引き起こせると説明されている。

CVE-2026-109619

致命的なエラーが起きたとき、内部の記録が、すでに片づけたはずの前のリクエストのメモリを指したまま残る。次のリクエストがそれを使うと、メモリの「使い終わった場所」を触ってしまう(use-after-free)。研究者は、実際のアプリケーションに対する任意コードの実行を実演したという。

ポイント

たとえるなら、混雑した店で店員がメモを取り違え、前のお客さんのメモを今のお客さんの対応に使ってしまうようなものだ。これは分かりやすくするためのたとえで、仕組みそのものとは違う。大事なのは、WordPressなどのアプリに落ち度はなく、問題はその下で動くPHP自体にある、という点だ。

修正版は次のとおり。

01
PHP 8.5系 → 8.5.12 8.5系を使っている場合の修正版。
02
PHP 8.4系 → 8.4.27 8.4系を使っている場合の修正版。
03
PHP 8.3系 → 8.3.36 8.3系を使っている場合の修正版。
04
PHP 8.2系 → 8.2.35 8.2系を使っている場合の修正版。

古い版については、公式の発表と報道で少し食い違う。SecurityWeekは、7.4、8.0、8.1にも最小限の修正(バックポート)が出たと伝えている。ただ、私が今回確認できた範囲では、PHP Foundation自身のページには「サポート中のすべてのブランチ」としか書かれていなかった。一方、エックスサーバーは22日の告知で、公式修正版がない古いPHPには、独自の修正を作って、検証が済んだものから順に適用していると案内している。古い版の扱いは会社ごとに違うと思ったほうがいい。古いPHPで動かしているサイトは、サーバー会社や公式の案内を直接確認してほしい。

なぜ止まる前に騒ぎになったのか

今回の特徴は、修正版が出る前に、情報が漏れ始めたことだ。修正が出る前の数時間は、守る側にとって、いちばん手を打ちにくい時間になる。

01
21日 午前0時ごろ(日本時間):番号だけが先に出回る CVE番号が、掲示板やSNSに出回った。時刻は本来の予定と食い違い、深刻度も実際より高い「10.0」と書かれていた。この時点では、技術的な中身はまだ漏れていなかったという(PHP Foundation)。
02
21日 早朝:攻撃の実証動画が誤って公開される 研究者のCalifが、攻撃が動く様子の動画を誤って公開した。コピーがSNSに広がり、攻撃コードづくりを早めたとPHP Foundationは説明している。
03
21日 夕方:修正入りのイメージが先に出る Chainguardが、修正を取り込んだイメージを、正式リリースの6時間以上前に公開した。公開日を揃えて守る「エンバーゴ」が破られた形だ。
04
21日 23時:修正版が公開される 当初の予定は22日だったが、情報漏れを受けて前倒しされた。ここまでの時刻は、報告の協定世界時(UTC)を日本時間に直したものだ。

独自考察

脆弱性の修正は、攻撃者に知られないよう、日付を揃えて静かに配る約束で進められる。今回はその約束が、番号の流出、動画、先出しのイメージと、三段階で崩れた。守る側が準備する時間は、予定よりかなり短くなったと思う。これは今回に限らず、次の大きな脆弱性でも起こりうる。

攻撃は始まっているのか

ここは、情報源によって見方が分かれる。どちらか一方だけを見ると、実態を読み違えるので、並べて書く。

攻撃の兆候を報告する側

SecurityWeekによると、watchTowrは、修正版が出るころに、自社のセンサーへ最初の攻撃の試みが来たと報告した。Hadrianは「大規模に悪用されているのを確認した」と書いている。PatchstackとCloudflareも、公開日の早い時間に攻撃の試みを観測したという。Patchstackのページでは「複数の悪用を確認」とも書かれている。

成功は確認していないとする側

watchTowr自身は、成功した攻撃はまだ見ていないと話している。PHP Foundationも、公開の時点で実際に動く攻撃コードは見つけていないとしつつ、実証コードが出回っていることは認めている。日本のIPAやHuntressなども、悪用は確認していないとされる(piyologの整理による)。

まとめると、「攻撃の試みは始まっている」ことは、ほぼ共通している。一方で、「実際に乗っ取られた例が出ているか」は、まだはっきりしない。試みと成功は別のものだ。ただ、時間がたつほど、成功の報告が増える可能性は高いと思う。

国内で何が止まったのか

piyologの集計では、21日の22時台までに、国内の54組織がサービスの停止や緊急メンテナンスを告知したという。確認できた例は次のとおり。なお、停止の理由にPHPを明記していない組織もある。

01
行政・生活まわり 厚生労働省の「介護サービス情報公表システム」が、21日16時から22日12時まで停止。保育園向けのコドモンは全サービスを止め、22日早朝の再開を見込んでいた。
02
ネットサービス・ゲーム BASEが、21日15時50分から22日7時までの予定でメンテナンス。Cygamesの「グランブルーファンタジー」なども、21日23時から22日7時までの予定。「ウマ娘」も21日23時ごろから止まり、運営は、この脆弱性を悪用した被害やデータ流出は確認していないとした(電撃オンライン)。
03
鉄道・大学など 阪神電気鉄道のウェブサイトは再開未定とされた。筑波大学は、問い合わせフォームなどを21日20時から止めた。

どの組織も、現時点で「被害が出たから止めた」とは言っていない。修正版が出る前に、念のため止めたケースが多い。

WordPressとレンタルサーバーへの影響

WordPressで動くサイトは、PHPの上に乗っている。GMO Flatt Securityは、WordPress、Laravel、Symfonyなどの構成で攻撃が再現したと書いている。つまり、WordPressも影響を受ける側に入る。

ここで間違えやすい点がある。WordPress本体やプラグインを最新にしても、今回の穴はふさがらない。直すべき場所は、WordPressより下のPHPだ。

レンタルサーバー各社の動きは、21日夕方の時点で、次のとおりだった(21日の状況はskypenguin.netの調査による)。

01
エックスサーバー 21日16時から、公式サイトや管理画面などへのアクセスを一時停止。予防的な安全対策で、不正アクセスによるものではないと説明している。利用者のサーバー自体は動き続け、サイトの表示やメールの送受信はできるという。再開は22日未明の見込みで、状況により前後するとされた。22日1時10分時点の告知では、公式修正版が出たPHP 8.2〜8.5から順次、修正の適用を始めたとし、公式修正版のない古いPHPは独自の修正づくりに着手したと案内していた。続く6時45分時点の告知では、PHP 8.2〜8.5について、対象となるすべてのサーバーへの修正パッチの適用が完了したという。旧バージョンは、一部で修正パッチの準備が整い、検証と確認が済んだものから順次適用を始めていて、残りも引き続き対応中とのことだ。
02
さくらインターネット 21日13時から22日8時ごろまで、レンタルサーバやVPSなど複数のサービスで緊急メンテナンス。PHPへの対応だとは、記事の時点では明記されていなかった。
03
そのほかの会社 ロリポップ!、ConoHa WING、mixhostは、17時35分の時点で一般向けの発表が見つからなかった。ただ、契約者にだけ連絡している可能性もあり、「対応していない」という意味ではない。

他社の情報は21日夕方のもので、22日になって状況は変わっているはずだ。契約しているサーバー会社の最新のお知らせを、必ず見てほしい。

サイト運営者が今できる備え

特別な道具がなくても、今日から確認できることを選んだ。

01
いま動いているPHPのバージョンを確認する WordPressなら、管理画面の「ツール」→「サイトヘルス」→「情報」→「サーバー」でPHPのバージョンが見える。サイトが複数ある場合は、1つずつ確認する。
02
サーバー会社の案内を読む PHPの更新を会社側がやってくれるのか、管理画面から自分で切り替えるのかで、やることが変わる。メンテナンス中の会社は、再開後のお知らせも見ておく。
03
自前のサーバーは、バックアップのあとに更新する VPSなどの場合は、バックアップを取ってからPHPを更新し、PHP-FPMやApacheを再起動する。再起動しないと、古いままのプログラムが動き続けることがある。
04
更新したあとに、サイトの動きを確認する 表示、ログイン、問い合わせフォーム、決済まわりのプラグインを一通り触っておく。バージョンを上げた直後は、古いプラグインが動かなくなることもある。
05
怪しい痕跡がないか見ておく 画像などを保存するフォルダに、身に覚えのないPHPファイルがないか。知らない管理者ユーザーが増えていないか。アクセスログに、おかしな連続アクセスがないか。見つけたら、自分だけで抱え込まず、サーバー会社に相談したほうがいい。

応急処置について

GMO Flatt Securityは、php.iniで「session.upload_progress.enabled=0」と「fatal_error_backtraces=0」の2つを無効にする方法を挙げている。ただ、これは実証された攻撃の一部を減らすだけで、別の経路は残る可能性があるとも書いている。PHP Foundationも、緩和策は特定の攻撃経路への露出を減らすだけで、安全にするものではないとしている。あくまで時間稼ぎとして考えたほうがいい。

止めたのは正しかったのか

今回の対応には、二つの見方があると思う。

止めて正解だったという見方

修正版が出る前は、守る手段がほとんどない。しかも実証動画が出回り、攻撃の試みも観測されていた。個人情報や決済を扱うサービスなら、数時間止めるほうが、乗っ取られたあとの対応より安く済む可能性がある。

止めすぎだったという見方

成功した攻撃が確認されていない段階で、介護情報のような生活に関わるシステムまで止まった。利用者が困る場面もあった。サービスごとに危険度を見分けて、止める範囲を絞る方法もあったのではないか、という意見は出てくるだろう。

独自考察

どちらが正しいかは、そのサービスが何を預かっているかで変わると思う。大事なのは、止めるか止めないかを、その場で慌てて決めないことだ。「PHPが動いている場所を把握しているか」「更新の担当者が決まっているか」を、普段から確認しておく。今回止まった組織の多くも、まずそこを洗い出すところから始めたはずだ。小さなサイトの運営者こそ、一度、自分のサイトのPHPがいつ誰によって更新されるのかを確かめておいたほうがいい。

今後の注目点

継続してチェックしたい点

・実際に乗っ取られた例が、国内外で確認されるか
・サーバー会社各社の、PHP更新の完了時期と利用者への案内
・古いPHP(8.1以前)を使い続けているサイトの扱い
・エックスサーバーなどが進める、古いPHP向けの独自修正がいつ全部そろうか
・同じ種類の穴が、ほかにも見つかるか(Wizは、2件の番号が、すべての変種を含むわけではないと指摘している)

よくある質問

php2shell(ピーエイチピー・ツー・シェル)とは何ですか?

PHPのエンジン部分に見つかった、重大な脆弱性2件(CVE-2026-109618とCVE-2026-109619)の通称です。外部から細工したリクエストを送られると、サーバー上で好きなコードを動かされる恐れがあります。深刻度は、2件とも9.2とされています。

WordPressを最新にすれば安全ですか?

いいえ。今回の問題はWordPressの外側、その下で動くPHPにあります。WordPress本体やプラグインを更新しても解消しません。PHPを修正版(8.5.12、8.4.27、8.3.36、8.2.35など)に上げる必要があります。

レンタルサーバーを使っている場合は何をすればよいですか?

まず、契約しているサーバー会社の案内を確認してください。PHPの更新を会社側が行うのか、利用者の操作が必要なのかで、やることが変わります。あわせて、現在のPHPのバージョンと、更新前のバックアップを確認しておくと安心です。

まとめ

php2shellは、PHPのエンジン部分に見つかった、深刻度9.2の脆弱性2件の通称だ。WordPressを含む多くのサイトが乗っているPHPの問題なので、WordPressを更新しても解消しない。攻撃の試みは観測されているが、成功した例はまだはっきりしない。まずPHPのバージョンを確認して、サーバー会社の案内に従って更新する。それだけでも、一度やっておきたい。

著者:Daisuke|確認日時:2026年10月22日 07:30 JST

著者コメント:この記事を書いている時点で、私が運営しているサイトのサーバー側にも、メンテナンスが入っていた。状況は時間単位で変わっているので、数字や対応状況は、確認できた範囲だけを書いている。新しい発表が出れば、内容を更新していく。