PHP2Shellへの緊急対応─Kinstaのセキュリティ対策の舞台裏

2026年10月21日、PHPの2つの重大な脆弱性「PHP2Shell」を悪用しようとする攻撃が、すでに複数のサイトに対して行われていました。この時点では公式のセキュリティパッチはまだ公開されていませんでしたが、Kinstaのエンジニアリング部門およびセキュリティ部門は、お客様のサイトを保護するための対応を進めていました。

今回の対応は多岐にわたり、緊急措置としてCloudflareのファイアウォールルールを有効化し、PHPの設定を調整するとともに、公式パッチの公開後すぐに数十万のコンテナへ適用できるよう準備を進めました。同時に、カスタマーサポート部門には、サイトの安全性を心配するお客様から多くのお問い合わせが寄せられ、その対応にあたっていました。

10月23日までに、Cloudflareによる保護機能で、これらの脆弱性を狙った55万件以上のリクエストをブロックしました。また、サーバー基盤全体に必要なPHPのセキュリティアップデートを適用し、攻撃による侵害の痕跡も確認されませんでした。

以下、脆弱性を悪用した攻撃が確認されてから、セキュリティパッチの適用、そしてその後の対応まで、Kinstaがどのように対処したのかを時系列でご紹介します。

公式パッチ公開前から進めていたPHP2Shellへの対応

10月20日、PHPのセキュリティチームは、翌21日に重大な脆弱性に対するセキュリティアップデートを公開する予定であると発表しました。同発表では、CVSS 4.0で深刻度9.2（Critical）と評価された2つの脆弱性について警告し、パッチが公開され次第、速やかにPHPを更新できるよう準備することを推奨していました。

これらの脆弱性は、後にCVE-2026-109618およびCVE-2026-109619として特定されています。いずれもPHP内部のメモリ処理に関する問題で、特定の条件下では、攻撃者が認証を経ずにリモートからコードを実行できるおそれがあります。

WordPressはPHPで動作しているため、今回の脆弱性はWordPressサイトにとっても重大な問題でした。WordPressのプラグインやテーマを更新しても解決できず、PHP自体にセキュリティ修正を適用する必要がありました。

Kinstaのようなサーバーサービス事業者にとって、最初の課題は、公式パッチが公開されるまでの間、いかにお客様のサイトを保護するかという点でした。Kinstaではアップデートに向けた準備を進めていましたが、その時点ですでに脆弱性を悪用しようとする攻撃が確認され始めていました。

Kinstaのエンジニアリング部門責任者であるLaszlo Farkasによると、10月21日の早朝には、今回の脆弱性を狙ったリクエストが確認され始めていました。エンジニアは攻撃対象となったサイトを手動で調査し、実際に侵害が発生していないか、その後も継続して監視を行いました。

この時点で、Kinstaではすでにお客様のサイトを保護するための対策を講じています。

Cloudflareの緊急WAFルールを有効化

Kinstaでホストするすべてのお客様のサイトは、本番環境とステージング環境の両方を含め、Cloudflareによって保護されています。これにより、お客様が個々のサイトでファイアウォールルールを設定することなく、Kinstaのエンジニアリング部門がサーバー基盤全体にセキュリティ対策を適用できます。

PHP2Shellの脆弱性が一般公開される前、Cloudflareは攻撃を検出するための緊急のWebアプリケーションファイアウォール（WAF）ルールを導入しました。Kinstaのエンジニアリング部門は、CloudflareのWAF変更履歴を継続的に監視し、新しいルールが公開されるたびに内容を確認して、速やかにアクションを「ブロック」に設定しました。

全サイトへのCloudflare導入により、お客様側で特別な対応を行う必要はなく、本番環境とステージング環境の両方に対して、これらの保護機能を一括で適用できました。

今回のPHP2Shellは、一般的なアプリケーションレベルの脆弱性とは異なり、PHP自体を標的とするものです。そのため、WordPressのセキュリティアップデートやプラグインによる保護だけでは、根本的な問題を解決できません。この点で、サーバー基盤全体に適用できる保護機能が重要な役割を果たしました。

WAFルールによって既知の攻撃をブロックし、その間にPHPのセキュリティパッチを適用する準備を進めることができました。攻撃者が手法を変えるのに応じて、Cloudflareも保護機能を継続的に更新しました。CloudflareのPHP2Shellに関する技術レポートでは、攻撃者が既存の検出ルールを回避するために、攻撃用のペイロードをどのように変更していたかが説明されています。

さらにCloudflareは、HTTPリクエストだけでなく、サーバーからのレスポンスも分析するフルトランザクション検出機能を導入。これにより、不審なリクエストを特定するための情報が増え、検出条件に一致したレスポンスがリクエスト元に返されるのを防ぐことも可能になりました。

Kinstaのエンジニアも、新しいルールが公開されるにつれて、攻撃のパターンが変化していく様子を確認していました。

10月23日までに、Kinstaのサイトに適用されたCloudflareの保護機能は、PHP2Shellを狙った55万件以上のリクエストをブロックしています。

なおこの数字は、今回の脆弱性に関連してブロックされたリクエストの総数であり、実際に侵害されたサイトの数や攻撃者の人数を示すものではありません。PHPのセキュリティ修正を適用するまでの間、ファイアウォールがどれだけの不審なアクセスを遮断していたかを示しています。

PHPの設定変更による一時的なセキュリティ対策

Kinstaでは、Cloudflareによる保護だけに頼らず、追加の対策も実施しています。セキュリティ修正済みのPHPパッケージが公開されるまでの間、エンジニアリング部門はサーバー環境全体にPHPの設定変更を適用し、既知の攻撃手法によるリスクの軽減を図りました。

その一つが、session.upload_progress.enabledの設定を変更し、PHPのセッションアップロード進捗機能を無効化することです。

PHPの公式セキュリティ勧告でも、この設定の変更が一部の攻撃手法に対する緩和策として挙げられています。この機能を無効にすることで、PHPのセッションアップロード進捗処理を悪用する攻撃を防ぐことができます。ただし、今回の脆弱性を悪用するすべての攻撃を防げるわけではありません。

ファイアウォールルールとPHPの設定変更は、公式パッチの公開前や適用作業中のサイトを保護するための追加対策として有効でしたが、脆弱性を根本的に解消するには、PHP自体のアップデートが必要です。

10月23日、PHPの開発部門は追加の勧告を公開し、次のバグ修正版がリリースされるまで、セッションアップロード進捗機能を無効にしておくことを推奨しました。これは、Kinstaのエンジニアリングチームがすでに実施していた予防措置の妥当性を裏付けるものでした。

Kinstaでは、各環境へのPHPアップデートの適用状況にかかわらず、パッチの展開が完了するまで、CloudflareのファイアウォールルールとPHPの設定変更による保護を継続しました。

数十万のコンテナへのPHPセキュリティパッチの適用

10月21日にPHPの開発チームがセキュリティアップデートを公開すると、次の課題は、サーバー基盤全体に修正を適用することでした。

公式にリリースされたのは、PHP 8.2.35、8.3.36、8.4.27、8.5.12です。一方、Kinstaではこれらより古いバージョンのPHPもサポートしているため、サードパーティのメンテナーが提供するセキュリティ修正も必要でした。

そこで、PHPパッケージの提供元であるFreexianと連携し、長期サポート対象の旧バージョンを含め、サーバー基盤で使用されている各PHPバージョンの修正済みパッケージを入手しました。

修正済みパッケージは、すべて同時に公開されたわけではなく、順次提供されました。エンジニアリング部門は、各パッケージがKinstaのパッケージミラーに届くたびに検証を行い、すべてのPHPバージョンが揃うのを待たずに適用作業を開始しました。

以下は、PHPのセキュリティアップデートを適用した際の時系列です。

今回の対応で特に重要だったのは、これほど大規模な環境に対して、短時間で変更を適用できる体制が整っていたことです。

エンジニアリング部門責任者のFarkasは、Kinstaのサーバー基盤全体に迅速に変更を展開できる点について、「今回の対応で最も誇りに思っているのはこの点です。変更内容の検証が完了し、問題が発生しないことを確認できれば、わずか数時間でサーバー基盤全体に展開できます」と述べています。

この仕組みにより、エンジニアリング部門は数十万のコンテナに対して、わずか数時間で修正済みのPHPパッケージを適用することができました。

また、PHPのアップデートにあたって、お客様に個別に対応をお願いする必要もありませんでした。KinstaではPHPをサーバー基盤側で一元管理しているため、エンジニアリングチームが修正済みパッケージの検証を終えれば、お客様側で更新作業を行うことなく、対象となるすべての環境に適用できます。

古いPHPバージョンにも追加の修正が必要だった理由

今回のアップデートでは、PHPの公式サポート対象バージョンと、サードパーティによって保守されている旧バージョンの違いも考慮する必要がありました。

PHPの開発チームがセキュリティアップデートを公開したのは、PHP 8.2〜8.5です。PHP 7.4、8.0、8.1などの旧バージョンは、すでにPHPの開発元による通常のセキュリティサポートが終了していました。ただし、長期サポートを提供するサードパーティを通じて、修正を適用することは可能です。

これを実現するのが「バックポート」と呼ばれる手法です。新しいPHPバージョンにアップグレードすることなく、セキュリティ修正を古いバージョンにも適用できます。

Kinstaではこの仕組みを利用し、Freexianから修正済みパッケージが提供されるたびに、旧バージョンのPHPを使用している環境にもセキュリティアップデートを適用しました。

また、PHPのバージョン番号だけでは、特定のセキュリティ修正が適用されているかどうかを判断できない場合があります。サードパーティが保守するPHPパッケージには、公式リリースと同じバージョン番号でなくても、必要なセキュリティ修正が組み込まれていることがあるためです。

Kinstaでは、ファイアウォールルールとPHPの設定変更による追加の保護を維持しながら、すべての対象環境へのアップデートを進めました。

攻撃の監視と侵害の痕跡の調査

セキュリティパッチの適用だけで、今回の対応が完了したわけではありません。確認された攻撃が実際に成功していないかを調査することも重要でした。

10月21日の早朝、Kinstaでホストされているサイトを狙った不審なアクセスが初めて確認されると、攻撃対象となったサイトを手動で調査しました。

その後もインシデントへの対応期間を通じて、不審なトラフィックの監視とサーバー環境の抜き取り調査を継続し、脆弱性が悪用され、実際にサイトが侵害された形跡がないかを確認しました。

Cloudflareのセキュリティイベントからは、攻撃対象や、新しいルールの導入に伴う攻撃パターンの変化を把握できました。しかし、ブロックされたリクエストの件数だけでは、攻撃が成功したかどうかまでは判断できません。

そのため、エンジニアによる手動調査が重要な役割を果たしました。また、Kinstaの脆弱性対策機能のパートナーであるPatchstackとも緊密に連携し、双方が確認した脅威や攻撃パターンについて情報を共有。さらに、PHPコミュニティ全体で対応が進む中、他のサーバーサービス事業者とも情報交換を行い、効果的な対策やベストプラクティスを共有しました。

こうした取り組みは、CloudflareやFreexianとの連携を補完するものです。Cloudflareが脆弱性を悪用した攻撃への防御機能を提供し、Freexianが修正済みのPHPパッケージを提供する一方、セキュリティパートナーとの情報共有によって、エンジニアは脅威の動向をより詳しく把握することができました。

今回のインシデントへの対応を通じて、PHP2Shellを悪用した攻撃による侵害の痕跡は確認されませんでした。

これは、対応期間中に実施した監視と調査に基づく結果です。ファイアウォールのデータが示すとおり、攻撃自体が発生しなかったという意味ではありません。実際に攻撃は確認されていましたが、調査の結果、侵害が成功したことを示す証拠は見つからなかったということです。

インシデントの解決とその後の検証

10月22日17時26分（日本時間）、KinstaはPHPのセキュリティインシデントが解決したことを公式ステータスページで発表しました。

この時点で、サーバー基盤全体へのセキュリティアップデートの適用が進み、すべてのサイトがパッチと追加のセキュリティ対策によって保護されている状態でした。

ただし、インシデントの解決を発表した後も、確認作業を終了したわけではなく、エンジニアリング部門は引き続き、各環境の安全性を検証し、保護機能が正常に動作しているかを監視しました。

今回のように、複数のPHPバージョンと数十万のコンテナを対象とする大規模なアップデートでは、こうした確認作業が特に重要です。同日13時31分（日本時間）の時点では、約0.5%のコンテナに追加の対応が必要でした。エンジニアは残りの環境への対応と検証を続け、修正済みパッケージが利用可能になっただけで、すべての環境への更新が完了したとは判断しませんでした。

また、この検証作業の間も、CloudflareのファイアウォールルールとPHPの設定変更による保護を継続しました。

今回のPHPセキュリティアップデートに関して、お客様側でパッチを適用したり、PHPのバージョンを切り替えたりする必要はありませんでした。

追加の予防措置を講じたお客様への対応

PHP2Shellへの対応は、サーバーサービス事業者だけにとどまりませんでした。脆弱性に関する情報が広まるにつれ、世界各国の政府機関や組織でも、セキュリティアップデートの準備を進める間、サイトを一時的に停止する動きが見られました。

オランダでは、国家サイバーセキュリティセンター（NCSC）が予防措置として自らのサイトを一時停止。ドイツ、フランス、ベルギー、フィンランドでも、政府機関のサイトが一時的に停止されています。日本では、高市首相がXで緊急の注意喚起を行い、サイト運営者に対して、速やかにセキュリティパッチを適用するか、すぐに更新できない場合はサービスを一時停止するよう呼びかけました。

Kinstaのお客様の間でも、同様の懸念が広がっていました。カスタマーサポートチームにはPHP2Shellに関するお問い合わせが急増し、サイトを保護するために追加の予防措置を講じるお客様もいらっしゃいました。

具体的には、MyKinstaの環境停止機能を使ってサイトを一時的にオフラインにしたり、ボット対策でサイト全体に検証を適用したり、サーバーレベルでのアクセス遮断をサポートに依頼したりするケースなどです。今回のインシデントでは、お客様の判断によって約3,000サイトが一時停止されていました。

脆弱性の深刻さや、世界各国で講じられていた予防措置を考えれば、こうした判断も無理のないものですが、Kinstaのエンジニアリング部門から、お客様にサイトの停止を推奨することはありませんでした。これは、すでにCloudflareの緊急WAFルールをサーバー基盤全体に適用しており、サイトを公開したままでも、訪問者からのアクセスを妨げることなく保護を継続できる状態だったためです。

そのため、エンジニアリング部門がPHPのセキュリティパッチの適用を進める一方、カスタマーサポート部門は、必要以上にサイトを停止しないようお客様への案内を開始しました。

セキュリティアップデートの適用後には、インシデント期間中に実施されたサイトの停止操作を調査し、PHP2Shellへの予防措置として一時停止されたサイトを特定しました。

その後、該当する環境を再び有効化し、PHP2Shellとは無関係の理由で停止されていたサイトについては、そのままの状態を維持しました。単純にすべての環境を再開するのではなく、今回の脆弱性への予防措置として停止されたサイトと、別の理由で意図的に停止されたサイトを区別する必要があったためです。

今回の対応では、攻撃のブロックやセキュリティパッチの適用に加え、お客様が予防措置として停止したサイトを元の状態に戻すためのサポートも重要な作業となりました。

今回の対応がお客様にとって意味すること

PHP2Shellへの対応には、エンジニアリング部門やカスタマーサポート部門に加え、外部のセキュリティパートナーやインフラ関連企業との連携が欠かせませんでした。こうした連携のもと、セキュリティパッチの適用はすべてKinstaのサーバー基盤側で実施しました。

お客様はPHPの更新状況や必要な修正パッケージを気にすることなく、サイトを安全に運用し続けることができました。

エンジニアリング部門責任者のFarkasは、「今回の対応で何より重要だったのは、お客様に余計なご負担をかけずに済んだことです。PHPの更新内容やタイミング、作業方法などを気にすることなく、安心してサイトを運用していただけるよう、Kinsta側ですべての対応を行いました」と語っています。

また、今回のインシデントでは、実施しているセキュリティ対策をお客様に正確に伝えることの重要性も浮き彫りになりました。緊急WAFルールがすでに有効になっていたにもかかわらず、予防措置としてサイトを停止したお客様もいらっしゃいました。その後、Kinstaの各部門が連携し、今回の脆弱性を理由に停止された環境の復旧にあたりました。

その一方で、エンジニアリング部門は、数十万のコンテナへのPHPセキュリティアップデートを完了させました。

セキュリティアップデートの実施状況やインシデントの解決に至るまでの記録については、PHP脆弱性に関するステータスページをご覧ください。

また、今回の脆弱性がWordPressサイトに与える影響や、Kinstaによる保護対策については、関連記事「Kinstaが実施したPHP2Shellへのセキュリティ対策」でも詳しくご説明しています。