PHP2Shellは、PHPに見つかった2つの重大な脆弱性の呼び名で、攻撃者がパスワードを知らなくてもサーバー上でコードを実行できる可能性があります。WordPressなどPHPで動くシステムを使っているサイトは危険にさらされているかもしれません。対策はWordPressの更新ではなく、サーバー上のPHPを8.5.12、8.4.27、8.3.36、8.2.35以降に更新し、それをホスティング会社に確認してもらうことです。
この2日間、「PHP」という言葉がニュースをにぎわせています。オランダでは行政サービスのログインであるDigiDが停止し、フィンランドでは一部の政府サイトが予防措置として止められました。アメリカではFBIとNSAが、パッチを適用できないならサーバーをオフラインにするよう呼びかけました。日本でも首相がPHPを使うWebサイトに修正の適用を求め、トルコでは大統領府サイバーセキュリティ局が全国規模のスキャンを始めました。
この記事では、専門的な話に深入りせずに何が起きたのかを説明します。そのうえで、ツアー事業者が自社サイトへの影響をどう確認するか、今日やるべきこと、そして次に備えて何をしておくべきかを順番に見ていきます。
まず基本から:PHPとは?
PHPは、多くのWebサイトの裏側で動いているプログラミング言語です。訪問者がサイトを開いたときにページを組み立てたり、お問い合わせフォームをメールに変えたり、予約をデータベースに保存したりするコードの多くはPHPで書かれています。
名前を聞いたことがなくても、どこかで使っている可能性が高いでしょう。WordPress、WooCommerce、Joomla、Drupal、そして多くの予約プラグインはPHPで動いています。FBIによると、世界のWebサイトのおよそ70%がPHPを使っています。
何が起きたのか
2026年10月20〜21日、PHPチームは2つの重大なセキュリティ脆弱性に対する緊急アップデートを公開しました。識別番号はCVE-2026-109618とCVE-2026-109619で、まとめて「PHP2Shell」と呼ばれています。どちらも深刻度は10点中9.2です。
深刻な理由は、特定の条件下で、攻撃者がユーザー名もパスワードもなしに、インターネット経由でサーバー上の任意のコードを実行できてしまうことです。セキュリティの分野ではリモートコード実行(RCE)と呼ばれます。簡単に言えば、鍵がなくても玄関から入れてしまう状態です。
Qualysの分析によると、一方はサーバーのメモリが不足したときにデータが中途半端なまま残ることで、もう一方はエラーの後、次の訪問者のリクエストがすでに解放されたメモリを読み直すことで発生します。研究者たちは、パスワードやセッション情報、APIキーといったデータがサーバーのメモリから漏れる可能性も示しました。
アナドル通信によると、この脆弱性は8月にセキュリティ企業CalifがAIの助けを借りて発見しました。修正は約2か月かけて非公開で準備されましたが、パッチ公開の前日に報道機関へ情報が漏れました。
なぜこれほど大きな問題なのか
- 規模が非常に大きい:Palo Alto Networksは、インターネットに公開され脆弱な可能性があるシステムを2,260万件以上確認しました。
- 古いバージョンがあふれている:Qualysのデータでは、バージョンが判明しているPHPの71%がサポート終了済みのバージョンで、通常のパッチが提供されません。
- 攻撃はすでに始まっている:Cloudflareはこの脆弱性を狙った攻撃トラフィックを報告しており、悪用に使えるコードも出回っています。
- パッチ適用が遅い:公開から12時間で、Qualysが把握する1億6,700万件のうち更新されたのは約19万9,000件にとどまりました。
各国政府がサイトを止めたのはこのためです。パッチが当たるまでは、攻撃者が入ってこられる扉を閉じておくのが最も安全です。トルコではサイバーセキュリティ局が公的機関に緊急通知を送り、民間企業にもPHP環境の確認を求めました。国の行政ポータルe-Devletについては、サービスに影響する問題は見つかっていないと発表しています。
ツアー事業者にとってのリスク
侵入した攻撃者に何ができるかは、サイトに何を保存しているかによります。起こりやすいのは次のようなケースです。
- 顧客データの漏えい:予約フォームの氏名、電話番号、メールアドレス、パスポート情報など。事業の所在地やお客様の居住地によっては、個人情報保護法やGDPRなどにより報告が必要になる場合があります。
- パスワードやキーの盗難:データベースのパスワード、決済サービス、サイトコントローラー、メール配信サービスのAPIキーなど。
- サイトへの有害コンテンツの埋め込み:隠しスパムページや、訪問者を別のサイトへ転送するコード。Googleに検知されると警告付きで表示され、何か月もかけたSEOの成果が損なわれることがあります。
- サーバーの悪用:仮想通貨のマイニング、スパム送信、ほかのサイトへの攻撃など。
- 売上の損失:予防のためにサイトを止めれば、繁忙期でも予約を受けられなくなります。
自社サイトは影響を受ける?まずバージョンを確認
最初のステップは、サイトがPHPで動いているか、どのバージョンかを確認することです。WordPressなら管理画面の「ツール → サイトヘルス → 情報 → サーバー」でPHPのバージョンを確認できます。ホスティングの管理パネル(cPanel、Pleskなど)でも、たいてい「PHPバージョン」の項目に表示されています。
脆弱性が修正されたバージョンは次のとおりです。
- PHP 8.5の場合:8.5.12以降
- PHP 8.4の場合:8.4.27以降
- PHP 8.3の場合:8.3.36以降
- PHP 8.2の場合:8.2.35以降
- PHP 8.1以前:通常の公式アップデートはありません。ホスティング会社が特別なパッチを当てていない限り、新しいバージョンへの移行が必要です。
補足:一部のLinuxディストリビューションは、古いバージョン番号のまま修正を配布しています。そのため、番号が古く見えても必ずしも脆弱とは限りません。最も確実なのは、ホスティング会社に直接確認することです。
今日やるべきこと
- ホスティング会社に「私のサーバーのPHPは、PHP2Shell(CVE-2026-109618とCVE-2026-109619)への対策として更新済みですか?」と問い合わせましょう。「ファイアウォールのルールを追加しました」という回答だけでは不十分です。PHP本体が更新されたことを確認してください。
- WordPressを更新しても解決しないことを知っておきましょう。脆弱性はWordPressではなく、その下で動くPHPにあります。プラグインやテーマの更新、セキュリティプラグイン、メンテナンスモードでは防げません。攻撃はWordPressが読み込まれる前に実行される可能性があるからです。
- 自社サーバー(VPS)の場合:PHPのパッケージを更新し、その後PHP-FPMまたはApacheを必ず再起動してください。再起動しないと、サーバーは古い脆弱なコードを動かし続けます。Dockerの場合は新しいイメージを取得し、コンテナを作り直しましょう。
- 古いバージョンを使っている場合:サーバーの外に完全なバックアップを取ってから、PHP 8.3または8.4に移行します。その後、トップページ、ツアーページ、お問い合わせフォーム、予約の流れを一つずつ確認しましょう。
- すぐにパッチを当てられない場合:Cloudflareなどのファイアウォールの背後にサイトを置くと、一時的な防御になります。技術担当者がいれば、PHPが推奨する暫定設定(例:session.upload_progress.enabled=0)を適用できます。これは完全な解決策ではなく、時間を稼ぐための手段です。
すでに侵入されていないか?確認すべきサイン
パッチを当てた後は、脆弱性がふさがれる前に誰かが侵入していないかも確認しておきましょう。
- WordPressに見覚えのない管理者アカウントはありませんか?
- 自分でインストールしていないプラグインはありませんか?
- 画像を保存するwp-content/uploadsフォルダに.phpファイルはありませんか?ここにPHPファイルがあるべきではありません。
- Googleで「site:自社ドメイン.jp」と検索したとき、書いた覚えのないページが表示されませんか?
- Google Search Consoleの「セキュリティの問題」に警告はありませんか?
- ホスティング会社から、マルウェア、スパム、異常なリソース使用に関する警告は届いていませんか?
どれかに当てはまる場合は、ホスティング会社にサーバーのスキャンと、不審な動きが始まる前のクリーンなバックアップへの復元を依頼してください。そのうえで、WordPress、ホスティング、データベース、メール、決済や販売チャネルの連携など、すべてのパスワードとAPIキーを変更しましょう。顧客データが漏れた可能性がある場合は、法的な義務について専門家に相談してください。
これから:継続的な対策
PHP2Shellが最後の脆弱性になることはありません。本当に大切なのは、次のときにどれだけ備えられているかです。おすすめの習慣は次のとおりです。
- サポート中のバージョンを使う:サポートが終わったソフトウェアにはパッチが届きません。現時点ではPHP 8.3または8.4がよい選択です。
- 更新の担当者を決める:誰が、どのくらいの頻度でサイトを更新しているのか、明確に答えられる状態にしましょう。マネージドホスティングや保守契約を使えば、これを契約として明文化できます。
- 持っているものを把握する:メインサイト、古いキャンペーンページ、テスト環境、忘れられたサブドメイン……。それぞれのサーバーとバージョンを一覧にしておきましょう。攻撃者は忘れられたサイトを好みます。
- 不要なものは削除する:使っていないプラグイン、テーマ、古いサイトは削除しましょう。余計な部品が一つ増えるごとに、脆弱性が開けうる扉も一つ増えます。
- サイトをファイアウォールの背後に置く:Cloudflareのようなサービスは、新しい脆弱性が発表されたとき、パッチを当てるまでの最初の防衛線になります。
- パスワードとキーを分けて管理する:APIキーをコードに書き込まず、各サービスには必要な権限だけを与え、キーは定期的に変更しましょう。
- バックアップはサーバーの外に保管し、復元を試す:一度も復元したことのないバックアップは、本当に使えるかわからないバックアップです。
- サイトを監視する:稼働監視、Search Consoleの通知、ファイル変更のアラートがあれば、お客様より先に問題に気づけます。
- 簡単なインシデント対応計画を書く:何かあったときに誰に連絡するか、サイトを一時的に止める方法、お客様への知らせ方を事前に決めておきましょう。
大きな流れ:脆弱性はますます速く見つかる
今回の件で最も注目すべきなのは、脆弱性がAIの助けで見つかったことです。同じツールは悪意のある人も使えます。これからは脆弱性がより速く見つかり、より速く悪用されるようになるでしょう。
つまり「手が空いたら更新しよう」という時代は終わりました。ツアー事業者にとって、Webサイトはもはや単なるショーウィンドウではありません。予約を受け付け、顧客データを保管するビジネスの道具です。その安全を守ることは、事業を止めないことの一部なのです。
Monotimでは、この種のサーバー言語の脆弱性から直接影響を受けない、モダンな基盤でサイトを構築しています。とはいえ、永遠に安全な技術はありません。本当の差を生むのは、サイトを継続的に見守り、問題が起きたときにすばやく対応できることです。
自社サイトがPHP2Shellの影響を受けているかわからない場合や、ホスティング会社から明確な回答が得られない場合は、一緒に確認しましょう。
参考資料
- PHP Announces Critical Security Release for Two Vulnerabilities (PHP2Shell), Qualys (blog.qualys.com)
- Threat Brief: Critical Vulnerabilities in PHP, Palo Alto Networks Unit 42 (unit42.paloaltonetworks.com)
- Responding to core PHP vulnerabilities CVE-2026-109618 and CVE-2026-109619, Google Cloud (cloud.google.com)
- Hundreds of websites taken offline as concern grows over two PHP vulnerabilities, The Record (therecord.media)
- Dünya çapında PHP kaynaklı güvenlik açığının giderilmesi için çok sayıda internet sitesi erişime kapatıldı, Anadolu Ajansı (aa.com.tr)
- PHP2Shell: what it is, and what to do on your WordPress site, Meow Apps (meowapps.com)
更新履歴
- 最新
初回公開。