2026年10月、ウェブサイトを動かすプログラミング言語「PHP」に、重大な欠陥（脆弱性）が2件見つかりました。外部からログインなしでサーバーに不正なプログラムを実行できる、RCEと呼ばれる脆弱性です。報道では、PHPは世界のウェブサイトのおよそ7割に使われているとされ、利用する企業などに速やかな修正が呼びかけられました。エンジニアの間で「PHP2Shell」と呼ばれているのが、この2件の脆弱性です。
今回のPHPの脆弱性で、ウェブサイトの制作・運用に携わる会社は緊急対応に追われました。私たちが扱う『Concrete CMS』はPHP製のCMSですので、私たちも社員総出で対応にあたり、大変な日々でした。この記事では、私たちの「PHP2Shell」対応を振り返りつつ、気づきや今後の対応についてお伝えできればと思います。
2026年10月21日、早朝6時32分
その朝、目覚めた私がXを開くと、海外のエンジニアたちがすでに大騒ぎになっていました。PHP開発元から「深刻度の高い修正2件を公開する」という予告が発表されたのです。中身も対象バージョンも、まだ伏せられたままです。公開が予告されたのは、日本時間の同日23時。脆弱性を修正したバージョンの公開日時が予告されるのは異例のことです。
大ニュースにすっかり目が覚めた私は、6時32分に社内のBacklogで対応を管理するための作業票を作成しました。目標は「管理サイトは修正版公開から48時間以内に更新、修正が提供されない古いPHPは同じ時間内に暫定対策を適用すること」です。ホスティング先や保守契約の違いに応じて、お客様への対応方針を定め、始業時間にすぐに社員が対応に着手できるよう準備しました。
公開後の対応
23時過ぎ、修正版が公開されました（CVE-2026-109618／109619、CVSS v4.0で9.2）。その後の時系列を記録のために残しておきたいと思います。
-
10/22 04:25：amazee.io では、脆弱性の公開から4.5時間後に修正イメージが適用されました。amazee.ioでホスティングしている各社のコンテナの入れ替えが完了し、脆弱性への対応が完了。
-
10/22 06:45：対応の早かったレンタルサーバーでは、脆弱性の公開から8時間以内に対応完了が発表されました。
-
10/22 10:45：Amazon Linux 2023 で修正版がリリースされたことを確認。
-
10/22 13:55：各環境への緩和策の適用を完了
-
10/22 15:10：弊社が自社で管理しているAWS（EC2）管理の各環境のPHPの修正版への更新が完了
-
10/22 17:55：弊社が自社で管理しているRHEL環境のPHPの修正版への更新が完了
-
10/22 18:05：対応に時間がかかっていたレンタルサーバーでも、対応完了が発表されました。
-
10/23 09:45：さらに対応に時間がかかっていたレンタルサーバーでも、対応完了が発表されました。
-
10/23 19:00：弊社が管理を委託しているAWS（EC2）管理の各環境のPHPの修正版への更新が完了
-
10/23 19:15：関連する脆弱性（CVE-2026-115560）が追加公表。修正版が未提供のため、設定変更（session.upload_progress.enabled=0）で防御
-
10/24〜26：侵入の痕跡がないか、10月17日までさかのぼって調査
一連の対応は、CMSやサーバー保守契約をご契約いただいているお客様が対象となりました。レンタルサーバーでも修正が提供されなかった古いPHPのまま、CMSも古いバージョンを使い続けていたお客様や、AWSでもサーバー保守契約を結んでおらず、Amazon Linux 2のまま使われていたお客様から、脆弱性の公開後たくさんのお問い合わせをいただきました。こうしたお客様の環境では、大きな改修やサーバーの引っ越しが発生し、今も対応が続いており、まだメンテナンス中のサイトもあります。日頃からアップデートしておくことの大切さを、あらためて感じています。
見えない同僚、AIボット
今回の対応では、社内で使っているAIボット「Grok Bot」がチームの一員として働きました。お客様からも切迫したお問い合わせが次々に寄せられましたが、ボットがまとめた情報は、状況を確認し、正確な情報をお伝えするうえで大きな助けになりました。
-
情報の見張り役：PHP開発元、ホスティング各社、セキュリティ研究者、米CISAの発表を定期的に確認し、社内チャットに定時報告。
-
翻訳役：攻撃コードの公開やWAF（不正な通信を止める防御装置）のすり抜けなど、英語のニュースを「私たちの環境で何をすべきか」に置き換えて共有。
-
連絡の下書き役：社内向け、顧客向けの告知文を作成。
一方で、どのサイトを止めるか、お客様にどう伝えるかといった判断は人が行いました。調べ物と文章づくりはボットに任せて、判断は人がしました。この分担が初動の速さにつながりました。
人が1台ずつサーバーをメンテナンスする限界
弊社にAWS環境での構築をご相談いただく際、弊社では24時間365日の監視体制は持っていないため、監視とミドルウェア更新などの保守作業をAWSの上位パートナー数社に委託しています。それでも今回のように影響度も緊急性も高い脆弱性への対応となると、多くのお客様が同時に対応を求めるため、委託先のエンジニアの空き時間の順番待ちになりました。
レンタルサーバーでも、各社の緊急メンテナンスを待つしかありませんでした。お客様の不安に早く応えたいのに、自分たちでは更新を進められず、じれったい思いでした。大手は比較的早く動きましたが、それでも完了までには時間がかかった印象です。同じサーバーに古いバージョンのPHPも同居しているため、バージョンごとに対応を進める必要があったからです。古いバージョンは「暫定対応のみ」となるケースもありました。
中には、注意喚起を出しただけで対応状況が分からないレンタルサーバーもありました。あるお客様が契約されているサーバーは、全く脆弱性への対応が行われず、問い合わせて初めて「申し込めば最新版へ更新してもらえる」ことが分かりました。サーバー会社が全部やってくれるんだろう、と思わず、自分たちから対応を確かめることの大切さを示す例だと思います。こうしたサーバーをお使いのお客様とは、移転を含めて個別に相談を続けています。
保守を専門の会社に任せていても、サーバーごとの作業や申し込みを待つ運用では、一斉に更新が必要になったときに対応が滞ります。今回見えてきたのは、担当者の努力だけでは埋めきれない、人が1台ずつサーバーをメンテナンスする仕組みの限界でした。
コンテナ化と、amazee.ioの良さ
こうした行き詰まりを避けるには、サーバー管理の仕組みそのものを変える必要があります。その方法の一つが、サイトを動かすソフトウェアをまとめた実行環境「コンテナ」を使うことです。サーバーに直接PHPを入れて1台ずつ更新すると対応に時間がかかりますが、コンテナ化してあれば、修正済みの実行環境に一括で置き換えられます。今後も脆弱性への対応が増えることを考えると、コンテナ化環境が望ましい、というのが今回の実感です。
ただし、コンテナをまとめて管理する仕組み「Kubernetes」環境を、自前で維持するには費用がかかります。EC2を1台で借りるのに比較すると、AWSで使うサービスも多くなり、AWS料金もぐっと上がるだけでなく、Kubernetes自体の更新を担うエンジニアの工数と専門知識も欠かせません。
私たちマカルーデジタルは、ホスティングサービス「Macareux Aria Hosting」を提供しており、その基盤にamazee.ioを採用しています。amazee.ioは、ウェブサイトやアプリケーションを動かす環境を提供し、その基盤の運用・管理も担うマネージドホスティングサービスです。
amazee.ioなら、マネージドのKubernetes環境を手ごろな費用で使えます。お客様ごとに運用体制を一から抱えずに、基盤の保守を任せられる点も利点です。実際、今回私たちが対応したホスティング環境の中で最も早く更新を終えられ、安心しました。
加えて、amazee.ioでは普段から、週に1回のメンテナンスでコンテナを総入れ替えする運用が標準です。定期的にコンテナを入れ替える運用も、日常のセキュリティ対策の一つです。
PHPのCMSはもう古い？
今回、PHPの脆弱性が話題となり、メディアでも大きく報道されたことで、PHPは危ないのではないか、PHP製のCMSは使わない方がいいのではないか、という意見も耳にします。
では、別の言語に乗り換えればよいのか。私たちは、そうは思いません。ほかの言語やソフトウェアでも、深刻な脆弱性は何度も繰り返し発見されてきました。どの言語を選んでも、同じような脆弱性はこれからも見つかり続けるでしょう。
-
Node2Shell（2026年）：PHP2Shellと同様、リモートからの任意コード実行（RCE）につながる深刻な脆弱性がNode.jsに発見されました。Node.jsは、PHPと同様のサーバーサイド実行環境です。
-
KindaRails2Shell（2026年）：これも同様に、リモートからの任意コード実行（RCE）につながる深刻な脆弱性が、Ruby on Rails に発見されました。
-
React2Shell（2025年）：React Server Components において、リモートからの任意コード実行（RCE）につながる深刻な脆弱性が発見されました。サイバー犯罪者が攻撃に使用したことが確認され、大きな話題となりました。
-
PHP-CGI（2024年）／PHP-FPM（2019年）：PHP本体でも、これまでに同レベルの緊急修正は出ています。
-
Log4Shell（2021年）：Javaのログを記録する部品の問題で、世界中の企業が一斉に対応に追われました。
-
Apache Struts（2017年）：これもJavaの問題です。米国の大手信用調査会社Equifaxが修正を当てきれず、約1.4億人分の個人情報が漏れる大事件につながりました
今回のPHPの脆弱性が注目を集めたのには、いくつかの理由があると思います。まず、PHPを使っているサイトがとても多いこと。大企業の情報漏洩が続き、連日報道されていた時期と重なったこと。そして高市首相がXで投稿したこともありました。
本当に必要なのは、脆弱性が見つかったときに、すぐ更新できる仕組みをつくっておくことです。今回、早く対応を終えられたのは、コンテナのように更新しやすい環境に置いていた、普段から新しいPHPに更新できているサイトでした。反対に対応に苦労したのは、修正が提供されない古いPHPやOSのまま動いていたサイトです。差を生んだのは言語ではなく、日頃から最新の状態を保てていたかどうかでした。
これから
今回、私たちが驚いたことがあります。これまでもこういった深刻な脆弱性が発見されることはあっても、サイトを止めるところまでいくことはあまり見かけませんでした。ところが今回は、すぐにサイトの停止を決めた会社が相次いだのです。普段、セキュリティについてご提案しても、軽くみられがちで、お客様の動きも遅いことが多くありました。「繁忙期に、サーバーメンテナンスなんてできないよ」なんてお客様も普通だったので、世の中のセキュリティ事案に対する受け止め方が変わってきたと感じています。
そして、私たちの意識もアップデートする必要を感じています。私たちはこれまでも、CMSやサーバーの保守サービスを提供し、常に最新バージョンへのアップデートを行うように心がけてきました。一方、実際のメンテナンスはお客様のご要望を尊重し、アップデートにより不具合が出ないことを十分に確認した上で、業務に影響のない日時を調整した上で実施するという手順を踏んできました。しかし、AIにより脆弱性の発見速度がどんどん上がっており、悪用されるまでのタイムラグもどんどん短くなっています。深刻な脆弱性の場合、今回の高市首相からの呼びかけに倣い、安全のためまずはサイトを停止してから、なるべく停止時間を短く復旧することを考える、という進め方を検討していきたいと考えています。
あわせて、現在の環境や更新時の課題を確認しながら、amazee.ioを基盤とするMacareux Aria Hostingへの切り替えをご提案していきます。修正済みのイメージでコンテナを入れ替えられることは、サーバーごとに手作業で更新する負担を減らし、緊急時の対応を早める助けになります。週に1回のコンテナの総入れ替えという日常の運用も含め、脆弱性が見つかったときにすぐ更新できる環境を、お客様と一緒に考えていきたいと思います。
公表後の対応だけでなく、AIを活用した攻めのセキュリティにも取り組んでいきます。コードレビューの補助や、利用しているライブラリの更新・保守状況の確認、設定の点検などを通じて、脆弱性が見つかる前からリスクを減らす使い方を探ります。その一環として、Cloudflareが提供する Security Audit Skill も試しています（かなりいいです）。AIが挙げたセキュリティ上の懸念を人が確かめ、必要な修正や設定の見直しにつなげることで、緊急対応に追われるだけではない運用を目指します。
運用中のサイトで不安な点があれば、ぜひお気軽にご相談ください。
