【2026年10月】PHPの脆弱性php2shellとは？企業サイトへの影響の確認方法と対応手順

PHPの緊急の脆弱性「php2shell」のニュースを見て、自社のホームページやネットショップは大丈夫なのか、何をすればよいのかわからず困っていませんか。

結論として、php2shellはPHPそのものの欠陥のため、WordPressやプラグインを最新にしても解消されず、サーバー上のPHPを修正版へ更新する必要があります。PHP 8.1以前を使っている場合は、サポート中のバージョンへの移行も必要です。本記事の手順に沿って、影響の確認、担当と期限の決定、バックアップ、更新と動作確認を進めれば、対応を漏れなく進められ、今後の管理体制も見直せます。

※本記事は2026年10月23日時点の情報をもとに作成しています。対象バージョンや対策は更新される可能性があるため、最新情報はPHP公式サイトやIPA（独立行政法人情報処理推進機構）の発表をご確認ください。

PHPの脆弱性php2shellとは｜10月21日から何が起きたか

php2shellとは、Webサイトを動かすプログラミング言語PHPに見つかった、深刻な脆弱性2件の通称です。外部から認証なしでサーバー上の任意のプログラムを実行されるおそれがあり、2026年10月21日22時40分ごろ（日本時間）にPHPの開発チームが修正版を公開しました。脆弱性とは、プログラムの不具合や設計上のミスによって生じる、情報セキュリティ上の欠陥のことです。

修正版の公開前後から、国内でもネットショップやレンタルサーバー、行政機関などが予防的にサービスを止める事態となりました。まずは、PHPの役割と、今回の脆弱性の全体像を整理します。

PHPとは？企業サイトの裏側で動くプログラミング言語

PHP（ピーエイチピー）とは、Webサーバーの上で動き、アクセスに応じてページの内容をその場で作るためのプログラミング言語です。企業のWebサイトでは、見た目の部分ではなく、裏側の処理で広く使われています。

企業サイトでPHPが使われている主な場面は、下表のとおりです。

管理画面から記事を更新できるサイトや、フォームで入力を受け付けるサイトの多くは、裏側でPHPが動いています。自社でPHPを使っている意識がなくても、影響を受けている可能性がある点に注意してください。

php2shellの概要（深刻度・件数・影響範囲）

今回修正された脆弱性は2件で、深刻度を示す国際的な指標CVSS v4.0では、どちらも10点満点中9.2の「緊急（Critical）」と評価されています。概要は下表のとおりです。

専門家の解説では、問題はWordPressなど特定のソフトではなく、PHPそのものにあるとされています。そのため、WordPressのほか、LaravelやSymfonyといったPHPの開発フレームワークで作ったサイトでも攻撃が再現したと報告されています。管理画面に複雑なパスワードを設定していても、それだけでは防げません。

悪用された場合に想定される被害は、下表のとおりです。

修正版の公開までと、その後の時系列

今回は、修正版の公開前から脆弱性の情報が出回り、修正版の公開と同時に各社が対応に追われました。10月21日から23日までの主な動きは、下表のとおりです。

あるセキュリティ企業は、影響を受けうる外部公開のサーバーが2,260万件を超えると発表しています（侵害された数ではなく、影響を受ける可能性のある数）。悪用がすでに観測されている以上、「まだ被害は出ていないから様子を見る」という判断は危険です。

国内で相次いだサービスの一時停止

今回の特徴は、被害が確認される前に、多くの組織が予防的にサービスを止めたことです。報道や各社の発表によると、10月21日から22日にかけて、次のような分野でサービスの一時停止や緊急メンテナンスが行われました。

共用のレンタルサーバー（1台のサーバーを複数の契約者で共有するサービス）では事業者がPHPを更新しますが、その影響で、サーバーを借りている企業のネットショップが一時的に受注できなくなった例もあります。一方、自社でサーバーを構築している場合や、VPS・クラウドサーバーを使っている場合は、自社で更新しなければ脆弱性は解消されません。

自社サイトは影響を受ける？確認すべきポイント

自社サイトが影響を受けるかどうかは、サイトでPHPが動いているか、動いているならどのバージョンかという2点で判断できます。PHPはサイトの裏側で動いているため、見た目だけでは判断できません。まずはサイトの作り方とバージョンの確認から始めてください。

WordPressで作ったサイトは確認の対象

WordPressで作った企業サイトは、原則として今回の脆弱性の確認対象です。WordPress本体やテーマ、プラグインはすべてPHPで書かれており、サーバー上でPHPが動くことを前提にしているためです。

サイトの作り方ごとの影響の目安は、下表のとおりです。

管理画面にログインして記事を更新している、またはURLの末尾が「.php」のページがある場合は、PHPが動いていると考えてください。

WordPressやプラグインの更新では直らない理由

今回の脆弱性は、WordPress本体やプラグインを最新にするだけでは解消されません。原因がWordPressではなく、それを動かしている土台のPHPにあるためです。

Webサイトの仕組みを階層で見ると、下表のようになります。WordPressの管理画面から行う普段の更新は、一番上の階層だけを直す作業です。

WordPressの管理画面で「すべて最新です」と表示されていても、それはWordPressとプラグインの状態にすぎません。PHPのバージョンは、サーバーの管理画面などで別に確認する必要があります。

PHPのバージョンを確認する方法

自社サイトのPHPのバージョンは、WordPressの管理画面か、サーバーの管理画面で確認できます。社内のWeb担当者でも数分で確認できるので、委託先に連絡する前に把握しておくと、その後のやり取りがスムーズです。

確認したバージョンを、下表の修正版と比べてください。修正版以上であれば、今回の脆弱性への対応は済んでいます。

PHP 8.1以前を使っているサイトは特に注意

PHP 8.1以前（8.1、8.0、7.4など）を使っている場合は、サポート中のバージョンへの移行が必要です。これらのバージョンはすでに公式のサポートが終わっており、今回も通常の修正版は公開されていません。

今回に限り、PHP 7.4、8.0、8.1向けに最小限の修正を加えたソースコードは提供されていますが、通常のリリースではありません。専門家は、PHP 8.1以前は安全とは判断できないとして、移行を強く勧めています。一部のサーバー会社やOSの提供元が独自に修正を提供している場合もあるため、利用中のサーバー会社の案内も確認してください。

各バージョンのサポートの状況と、必要な対応は下表のとおりです。

PHPのサポート期間は、新しい版の公開から通常のバグ修正が2年、その後のセキュリティ修正が2年の、合わせて4年が基本です。サポートが切れた版を使い続けると、今回のような緊急の脆弱性が見つかっても修正を受けられません。PHP公式のサポート期間の一覧も確認してください。

企業サイトの対応手順

自社サイトが影響を受けるとわかったら、案内の確認、担当と期限の決定、バックアップ、更新と動作確認の4段階で進めてください。準備を省いていきなりPHPを更新すると、サイトの表示崩れやフォームの停止といった二次被害を招くおそれがあります。

手順1　サーバー会社・制作会社からの案内を確認する

最初に、契約しているサーバー会社のメンテナンス情報と、制作会社との保守契約の範囲を確認してください。サーバーの種類や契約の形によって、自社で作業すべきか、事業者の対応を待てばよいかが変わるためです。

共用のレンタルサーバーでは、同じ系列内の修正（たとえば8.3系の修正版への更新）は事業者が順次適用するのが一般的です。一方、8.1以前から8.3以降へ切り替えるような系列をまたぐ変更は、サイトの動作に影響するため、管理画面から自分で切り替える必要があります。

手順2　更新する担当者と期限を決める

状況がわかったら、実際に作業する担当者と、更新を終える期限をはっきり決めてください。担当と期限があいまいなままだと、社内と委託先の間で「相手が対応しているだろう」という思い込みが生まれ、脆弱性が放置される原因になります。

関係者とすり合わせておく項目は次のとおりです。

アクセスが多い時間帯の作業は、一時的なエラーで問い合わせや注文を逃す原因になります。ただし、今回はすでに悪用が観測されているため、作業時間の調整を理由に更新を先延ばしにしないでください。

手順3　更新前にバックアップを取る

PHPを更新する直前に、サイトのファイル一式とデータベースのバックアップを取ってください。更新によって既存のプログラムが動かなくなっても、バックアップがあれば元の状態に戻しやすくなります。

バックアップの対象は次の2つです。

サーバーの自動バックアップを使っていても、直前の変更が含まれていないことがあります。作業の直前に手動で書き出し、サーバーの外（社内のパソコンやクラウドストレージ）にも保管しておくと安心です。

手順4　更新後にサイトの表示とフォームを確認する

PHPを更新したら、トップページだけでなく、主なページとフォームなどの機能が正常に動くかを確認してください。更新の影響は、ページを開いたときではなく、フォームの送信など特定の操作をしたときに初めて表に出ることがあります。

VPSやクラウドサーバーを自社で管理している場合は、PHPを更新したあとにPHP-FPMやWebサーバーを再起動しないと、新しいPHPが読み込まれないことがあります。作業の担当者に、再起動まで終えたかを確認してください。

更新後に優先して確認する項目は次のとおりです。

画面が真っ白になる、エラーが表示されるといった不具合が出た場合は、手順3のバックアップで元に戻し、原因のプログラムやプラグインを直してください。ただし、脆弱性のある古いバージョンに戻したまま公開を続けることは避け、次の暫定的な対策もあわせて検討してください。

すぐに更新できない場合の考え方

独自のシステムを組み込んでいるなどの理由で、すぐに更新できない場合は、リスクを下げる暫定的な対策を検討してください。ただし、PHPの開発チームは、設定の変更だけでは脆弱性を完全には塞げないとしています。暫定的な対策は、あくまで更新までのつなぎです。

主な暫定的な対策は、下表のとおりです。

これらの対策をとっても、PHP自体の脆弱性がなくなるわけではありません。対策をとっている間に、更新やサーバーの移行の計画を進めてください。具体的な設定方法は、サーバー会社や保守会社にご相談ください。

今回の件で見えた、自社でサーバーを管理するリスク

自社でサーバーやPHPを管理している企業は、緊急の脆弱性が見つかったときにすぐ更新できず、攻撃を受ける危険が高まります。普段の業務と並行してセキュリティ情報を追い、サイトを壊さずにPHPを更新するには、専門の知識とはっきりした役割分担が必要だからです。

IPAが公開している情報セキュリティ10大脅威 2026でも、システムの脆弱性を悪用した攻撃が組織向けの脅威の一つに挙げられています。サイトが改ざんされたり、フォームから個人情報が漏えいしたりすれば、企業の信用は大きく損なわれます。今回の件から見えた3つの課題を解説します。

「誰が更新するか」が決まっていないと対応が遅れる

緊急の対応が遅れる大きな原因は、社内と委託先の間で、PHPを更新する責任の所在があいまいになっていることです。サイトを立ち上げるときに、記事を更新する担当は決めても、サーバーの中のソフトを誰が更新するかまでは決めていないことが多いためです。

サーバー会社は「環境の提供まで」、制作会社は「頼まれた制作の範囲まで」と考えている場合、PHPの更新はどの担当からも漏れてしまいます。緊急時に誰が作業するかが決まっていないと、社内の稟議や見積もりのやり取りに時間をとられ、更新が大きく遅れます。

サポートが切れたPHPを放置しているサイトは少なくない

サイトが問題なく表示されていることを理由に、サポートが切れた古いPHPを使い続けている企業は少なくありません。PHPを大きく更新すると、古いテーマやプラグインが新しい版に対応できず、画面が真っ白になったり、フォームが送れなくなったりするおそれがあるためです。

古い版を使い続けているサイトが直面する問題は、次のとおりです。

日頃から計画的に版を上げていないサイトほど、緊急時にすぐ更新に踏み切れず、無防備な状態が続きます。

Web担当者が一人の企業ほど負担が大きい

専任のシステム部門がなく、Web担当者が一人でサイトを運用している企業ほど、緊急の脆弱性対応は大きな負担になります。中小企業では、Web担当者が広報や営業企画、アクセス解析やサイトの改善などを兼ねていることが多いためです。

サーバーの専門知識がない担当者が緊急の対応を迫られると、通常業務を止めて次の作業をこなさなければなりません。

これらを一人に任せる体制は、対応の遅れによる事故のリスクを高めるだけでなく、集客や売上のための本来の仕事が止まる原因にもなります。属人化した管理の限界を認識し、専門知識がなくても安全を保ちやすい仕組みへの見直しを検討してください。

今後のセキュリティ管理を見直す選択肢

緊急の対応で生じる担当者の負担や、対応の遅れを減らすには、自社の予算と体制に合わせてサイトの管理の仕方を見直すことが有効です。選択肢は、保守契約の見直し、サーバー管理がいらない仕組みへの移行、サイトのリニューアルの3つに分けられます。

保守契約を見直して、更新を任せる

今のサイトを残したままリスクを下げるには、制作会社や保守会社との契約を見直し、PHPの更新まで含めて任せるのが有力な方法です。保守契約の作業範囲が、ドメインやサーバーの契約の維持、定期的なバックアップだけになっていることは少なくありません。

契約を見直すときは、次の項目が含まれているかを確認します。

これらを毎月の保守に組み込んでおけば、緊急時にも社内の稟議を待たずに、専門家に更新を頼みやすくなります。

サーバー管理がいらないクラウド型のCMSへ移行する

サーバーやPHPの管理そのものを減らすには、提供会社がサーバーの保守を担うクラウド型のCMSへの移行が適しています。自社で借りたサーバーにWordPressを置く形は自由度が高い反面、サーバーやPHPを管理する責任はサイトの運営者にあります。クラウド型のCMSでは、サーバーの脆弱性対応やシステムの更新は原則として提供会社が行います。

主な選択肢は次のとおりです。

ただし、会員ページや社内システムとの複雑な連携をPHPで独自に作っている場合は、移行先で同じ機能を作れないことがあります。移行を検討するときは、今使っている機能を洗い出し、移行先の標準機能で代わりになるかを先に確認してください。

サイトのリニューアルを検討するタイミング

PHPの更新に伴う改修の範囲が広く、費用が大きくなる場合は、今のサイトを延命するより、リニューアルを検討したほうがよいタイミングです。古いテーマやプラグインを新しいPHPに対応させるために作り直す作業は、新しく作るのと同じくらいの手間と費用がかかることもあります。

次の条件に複数当てはまる場合は、部分的な改修ではなくリニューアルを検討してください。

セキュリティを保つためだけに高い改修費を払うより、問い合わせを増やすといった目的もあわせたリニューアルとして予算を組み直すほうが、投資の効果を高めやすくなります。

PHPの脆弱性php2shellに関するよくある質問

レンタルサーバーなら自動で更新されますか？

同じ系列内の修正は、サーバー会社が順次適用するのが一般的です。ただし、8.1以前から8.3以降へ切り替えるような系列の変更は、契約者が管理画面から行う必要がある場合が多くあります。VPSやクラウドサーバーを自社で管理している場合は、原則として自動では更新されません。サーバー会社のメンテナンス情報で、自社のサーバーが更新済みかを確認してください。

HTMLだけで作ったサイトでも影響はありますか？

ページがHTMLでも、お問い合わせフォームや一部のページでPHPを使っていれば影響を受けます。また、過去に置いたテスト用のPHPファイルがサーバーに残っていると、そこが攻撃の入り口になるおそれがあります。PHPを使っていないことが確認できたら、不要なPHPファイルを削除し、サーバーの管理画面でPHPを無効にしておくと安心です。

WordPressを最新にしていれば大丈夫ですか？

大丈夫ではありません。今回の問題はWordPressではなく、その土台のPHPにあります。WordPressの管理画面とは別に、サーバーの管理画面などでPHPのバージョンを確認し、修正版へ更新してください。

すでに攻撃されているか確認する方法はありますか？

サーバーのアクセスログやエラーログに不審な記録がないか、見覚えのないファイルや管理者アカウントが作られていないかを確認します。専門家は、更新とあわせてログによる侵害の調査も勧めています。自社で判断が難しい場合は、サーバー会社や保守会社、セキュリティの専門会社に相談してください。

BASEやStudioなどのサービスで作ったサイトはどうすればよいですか？

サーバーやPHPの管理は提供会社が行っているため、利用者がPHPを更新する必要は基本的にありません。各社のお知らせで、対応の状況や、利用者への依頼がないかを確認してください。

php2shellは「PHPの更新」が唯一の確実な対策

2026年10月21日に修正版が公開されたPHPの脆弱性php2shellに対して、企業のWeb担当者には自社サイトのPHPのバージョンを確認し、速やかに修正版へ更新する対応が求められます。本記事のポイントは次のとおりです。

管理の状況ごとの優先アクションは、下表のとおりです。

目の前の脆弱性への対応を終えたら、社内の体制に合わせて保守契約やサイトの管理の仕組みを見直し、特定の担当者に負担が集中しない管理体制を整えてください。