PHPの重大な脆弱性で総理も呼びかけ、大手サイトが一時停止。今、自社サイトでやるべきこととは？（php2shell CVE-2026-109618・109619）
エンジニアや運用担当者にとって、昨日は長い夜だったかもしれません。
2026年10月21日から22日にかけて、PHPの重大な脆弱性への対応で、多くのサービスが一時停止しました。
すき家の弁当予約、CoCo壱番屋や大戸屋のネット注文、りそな銀行の来店予約。普段使っているお店や銀行の名前が並ぶと、「システムの裏側の話」では済まなくなります。
高市総理もXで「大至急のお願いです」と対応を呼びかけ、自身のホームページも一時停止しました。
ネットショップのBASEは、21日15時50分から翌朝8時まで緊急メンテナンス。カラーミーショップも、ショップの表示・購入、管理画面などを21日22時から翌朝8時49分まで停止。
中小企業のネットショップに利用されているシステムが停止することで、利用されている店舗様にも売上にも影響があったはずです。
こうしてみると、非常に影響範囲が大きな問題だったんだなと感じます。
特に興味深いのは、有名な会社の名前が並んだこと以上に、「注文や予約を止める」という判断が必要になったことです。
注文や予約を止めてまで対応したPHPの脆弱性とは？
あたり前ですが、ネット注文を止めれば、その間の売上は入らず、利用者への説明や問い合わせ対応も増えます。それでも各社は、動かし続けるより、いったん止める方を選びました。
攻撃を受けたから止めた、という話ではありません。
カラーミーショップなどは、被害を防ぐための予防的な措置だったと説明しています。「次の定期更新で対応しよう」では済ませにくい問題だった、ということです。
ログインより手前で、不正な処理を実行される問題
PHPは、WordPressなどをサーバー側で動かしているプログラミング言語です。
今回は、そのPHP本体に、条件がそろうと外部の第三者がログインや認証を必要とせずに、不正なプログラムを実行できる問題がありました。
検証された構成では、サイト側のプログラムが動き始める前の、送信データを読み取る段階で攻撃が成立するようです。
公表された2件は、どちらも深刻度が10点満点中9.2の「Critical」。被害に遭う確率を示した数字ではありませんが、非常に重大な評価です。
RCE via OOM corruption・RCE via stale global state
原因は、PHPのメモリの扱い方にあった
仕組みに少しだけ触れると、どちらもPHPのメモリの扱い方に関する欠陥でした。
一つは、メモリ不足で処理が中断された際に、準備途中の内部データを後片付けの処理が使ってしまう問題。もう一つは、使い終わったメモリへの参照が残り、次の処理がそれを使ってしまう問題です。
この不整合を悪用すると、単に止まるだけでなく、攻撃者が意図した処理を動かせる可能性がある。そこが深刻でした。
自社サイトが、お客さんに被害を与える側になるかもしれない
不正なプログラムが動くといっても、必ずサーバーのすべてを自由に操作されるわけではありません。
それでも、アクセスできる場所に保存された問い合わせ情報を盗まれたり、書き換え可能なページを改ざんされたりするおそれはあります。後から侵入するための不正なプログラムを残されることも考えられます。
自社のサイトを開いたお客さんが、偽のログイン画面や決済ページに誘導される。そんな使われ方をしてしまえば、自社だけの問題では済みません。
こういう危険があるからこそ、各社は止めてでも対応したわけです。
しかも今回の脆弱性は、AIが見つけたものでした。OpenAIによると、2件のうち1件は米セキュリティ企業のCalifが同社のAIモデルを使って発見。Google傘下のWizも、AIを活用して2件を独自に見つけていたと報じられています。
PHPの「重大」脆弱性はAIが見つけた 「GPT-5.6 Solで発見」とOpenAI 「今後、AIによる脆弱性発見が急増」
AIで脆弱性を探せるのは、守る側だけではありません。AIは攻撃する側にも同じような能力を発揮することになるということです。
つまり、今後もこのような大規模な脆弱性により様々なサービスが停止する可能性があるということです。
事前に保守環境を整えていたことで慌てず対応
では、シンクではどうだったのか。
弊社で管理している公開サイトは、共用サーバーやフルマネージドのレンタルサーバーを利用しています。VPSもありますが、IP制限をかけた社内用のシステムです。
公開サイトはサーバー会社が対応する範囲が大きく、修正をすべて自分たちで行う必要はありません。それでも、サーバー会社が対応することと、自分たちのサイトが実際にどうなっているかを確かめることは別だと考えています。
管理画面に入れなくても、SSHでサーバーの状態を確かめられた
10月21日の夜は、利用しているサーバー会社の中に、管理画面が使えないところもありました。弊社が契約しているサーバーだけでなく、お客さまが契約しているサーバーを管理しているケースもあります。
普段使っている管理画面に入れない。そこから別の確認方法を探し始めるのでは、時間がかかります。
役に立ったのが、事前に準備していたSSH接続です。SSHは、サーバーに直接接続して状態を調べたり、許可された操作をしたりするための手段です。使える環境では、管理画面の復旧を待たずに確認を進められました。
たとえば弊社サイトでは、21日の23時過ぎに、実際に動いているPHPのバージョンを確かめ、まだ修正版が届いていないことを把握しています。サーバー会社の告知と照らし合わせれば、次にいつ何を確認すればよいかが分かります。
SSHは、必要になったときにすぐ使えるとは限りません。サーバーによっては、事前に機能を有効にしたり、接続用の鍵を登録したりする必要があります。どのサーバーでも同じことができるわけではなく、使える権限にも違いがあります。
それでも、確認する手段を管理画面だけにしていなかったことが、今回は役に立ちました。
AIエージェントで、全サイトを「直ったか」「異常はないか」に分けて点検
管理している全サイトとシステムの確認には、AIエージェントも使いました。
PHPのバージョンは、サーバー側だけでなくWordPress側からも確かめています。サイトが正常に動いていること、今回の修正が適用されていること、そして確認した範囲で不審なログや改ざんが見当たらないこと。それぞれを分けてチェックしました。
結果として、確認した範囲では不審な兆候は見つからず、修正の適用と正常な動作も確認できました。
WordPressではないサイトも、確認の対象から外さなかった
静的HTMLだけで作られたサイトについても、念のためPHPのバージョンアップなどを行っています。
静的HTMLそのものに今回の脆弱性がある、という話ではありません。「WordPressではないから関係ない」と最初から対象外にせず、サーバー側の状態まで確認した、ということです。
AIを使ったから安全になった、これで絶対に大丈夫、という話ではありません。よかったのは、騒ぎになってから確認方法を探すのではなく、用意していた手段とAIエージェントで、確認を素早く進められたことです。
管理画面が使えなくても、自分たちで状態を確かめられる。普段は目立たない準備ですが、こういうときに役に立ちます
自社サイトは大丈夫？ 専門知識がなくてもできる進め方
専門知識がない方が、いきなりサーバーの設定を触るのは難しいでしょう。最初にやるのは、制作会社や保守担当者、契約しているサーバー会社への確認です。
まず制作会社・保守担当者に聞く3つの質問
「うちは大丈夫ですか？」から、もう一歩だけ具体的に聞いてみてください。確認したいのは、次の3点です。
- 自社のサイトやシステムは、PHPを利用しているか。
- 今回の脆弱性に対する修正は、自社の利用環境にも適用されているか。
- 未対応なら、いつ対応できるか。それまで公開やアクセスを制限する必要があるか。
サーバー会社からお知らせが出ていても、自社が使っているサーバーまで対応済みかは分からないことがあります。聞くのは、あくまで自分たちが契約している環境についてです。
共用・フルマネージドのサーバーと、自分たちで管理するVPSでは、対応する人も範囲も違います。特に自主管理のVPSは、借りているからといって、サーバー会社がPHPまで更新してくれるケースはまれだと思います。
WordPressの更新や「メンテナンス中」表示だけでは防げない
WordPressを更新しただけで、PHP本体の問題まで直るわけではありません。よく分からないまま設定を変えるのではなく、実際にサイトを動かしているPHPに、必要な修正が適用されたかを確認することが大切です。
未修正のまま公開を続けていて、すぐに直せない場合は、アクセス制限や一時停止も管理者と相談してください。
ただ、WordPressを「メンテナンス中」の表示にしただけでは、裏でPHPが動いたままの場合があります。見た目を変えれば安全になる、という話ではないんですね。今回の問題は、PHP本体への修正適用が必要です。
「修正した」と「被害がなかった」は分けて確かめる
修正後は、サイトが正常に動くかとは別に、不審なログやファイルの変更がないかも確かめます。更新で穴をふさいでも、その前に仕込まれた不正なファイルまで自動で消えるわけではないからです。
不審なものが見つかったら、慌てて削除せず、ログなどの証拠を残したうえで、サーバー会社や専門家に相談してください。「更新しました」で終わらせず、どこまで確認できたのかを把握しておくことが大事です。
最初の一歩は、難しい操作ではありません。まず、管理している人に一本確認する。それだけでも、「よく分からないから、そのままにしておく」という状態からは抜け出せます。
サーバー会社の案内を読んでも判断できないときは？
自社に当てはまるのか判断しづらい、制作を頼んだ会社としばらく連絡を取っていない。そんなときは、弊社に声をかけていただいてもかまいません。
弊社では、無料でセキュリティの初期診断を行っています。PHP・WordPressのバージョンや更新状況、利用しているサーバー会社の対応状況などを、公開情報やご提供いただける情報から確認するものです。侵入の有無や安全性を保証するものではありませんが今後の対応範囲の特定に役に立つはずです。ログやファイルまで詳しく調べる場合は、調査範囲を決め、NDAや契約を交わしたうえで進めます。
更新や保守をまとめて任せたい場合は、サブスク型のサービスや運用サポートサービスも準備しています。
長い一日を支えた皆さんへ
最後に、今回、深夜まで対応にあたったエンジニアやサーバー会社の皆さん、サービスを止める判断をした方、利用者への案内や問い合わせ対応にあたった方々。本当にお疲れさまでした。
修正を適用するだけでなく、動作を確認し、再開できるかを判断し、その状況を伝える。普段どおりにサービスを使えるようになるまでには、表からは見えない対応がたくさんあったはずです。
その仕事に感謝しつつ、自分たちも管理しているサイトやサービスをきちんと保守していきます。