PHP・Linuxの脆弱性から考える：ECサイトの安全は誰が守る？

ECサイトを運営していると、最近の「PHPのリモートコード実行」や「長いパスワードによるLinuxへのログイン」といったニュースを見て、自分のショップにも関係があるのか気になるかもしれません。

答えは、サイトの構築方法、稼働環境、そして誰が保守しているかによって変わります。WordPressを使う事業者は、PHP環境やプラグインの状態を確認する必要があるかもしれません。サーバーを自社で管理している場合は、サーバーへのログイン経路も確認対象です。Shopifyのようなホスティング型プラットフォームでは、通常、事業者自身がプラットフォームのサーバーにパッチを適用する必要はありませんが、スタッフのアカウントや外部アプリ、ドメインの管理は引き続き重要です。

今回の2つの脆弱性は、異なるソフトウェアの層で発生しています。それでも、どの事業者にも共通する問いがあります。ショップが依存するシステムに問題が見つかったとき、誰が発見し、誰が修正し、その修正が適用されたことをどう確認するのでしょうか。

この記事の情報は、2026年11月7日時点のものです。脆弱性の詳細やベンダーの対応状況は変わる可能性があるため、実際に対応する際は公式の最新情報を確認してください。

何が起きたのか：2つの脆弱性と異なるセキュリティ境界

PHPの脆弱性：サイトが動いていても、基盤にリスクがあるかもしれない

2026年10月、PHPプロジェクトはCVE-2026-109618とCVE-2026-109619という2件の深刻な脆弱性を公表しました。いずれもPHPの実行環境内部のメモリや状態の処理に関する問題で、一定の条件下では、認証されていない第三者によるリモートコード実行につながる可能性があります。簡単に言えば、攻撃者がネットワーク経由のリクエストを通じて、影響を受けるサーバー上でWebサービスのプロセス権限によるコード実行を引き起こすおそれがあります。PHP公式セキュリティ告知

これはWordPressのプラグイン固有の問題ではなく、PHP自体の脆弱性です。PHPを使うコンテンツ管理システム、ECシステム、独自開発サイトなどは、それぞれの環境に基づいて影響を確認する必要があります。公式告知ではPHP-FPMやApacheのmod_phpなど、複数のWeb提供方式が対象として挙げられていますが、実際の悪用条件や難易度は設定やビルドなどによって異なります。

PHPプロジェクトが告知で挙げた修正済みバージョンには、8.2.35、8.3.36、8.4.27、8.5.12が含まれ、完全な修正には更新が必要とされています。Linuxディストリビューションのパッケージを使っている場合は、その提供元や長期サポート事業者の告知も確認してください。古いバージョンのパッケージにセキュリティ修正をバックポートしている場合があるため、PHP本体のバージョン番号だけでは判断できません。CERT-EUのセキュリティ通告

WordPressの運営者が見落としやすいのは、管理画面でWordPress本体、プラグイン、テーマがすべて更新済みと表示されても、PHPの実行環境まで修正済みとは限らないことです。逆に、PHPを更新しても、プラグインやテーマの保守が不要になるわけではありません。

OpenSSHの長いパスワードに関する問題：すべてのLinuxサーバーが対象ではない

2026年11月、Alpine LinuxはOpenSSHの認証回避に関する告知を公開しました。この問題には後にCVE-2026-123158という番号が付けられています。「長いパスワードを入力するだけでLinuxにログインできる」と要約したニュースもありますが、この表現には重要な前提が欠けています。Alpine Linux公式告知

リスクが生じるのは、複数の条件が同時に満たされる環境です。例えば、システムがmusl libcを使用し、OpenSSHがPAMを介さずに認証し、SSHのパスワード認証が有効で、パスワード欄が*の対象アカウントが存在し、さらに特定の種類のパスワードハッシュを持つ別のローカルアカウントが存在する場合です。攻撃者はSSHサービスにアクセスでき、対象のアカウント名も知っている必要があります。

これらの条件下では、極端に長いパスワードによってエラー処理とパスワード欄の照合に問題が生じ、本来パスワード認証を受け付けないはずのアカウントにログインされる可能性があります。強力なパスワードが危険という意味でも、すべてのLinux、Alpineコンテナ、SSHサーバーが影響を受けるという意味でもありません。 例えば、glibcを使用する一般的なDebianやUbuntuのシステムは、この特定の脆弱性の対象ではありません。コンテナについても、SSHが稼働し外部に公開されているかなどの条件を確認する必要があります。

Alpineは、影響を受けるユーザーに関連パッケージを更新し、sshdを再起動するよう勧めています。パッケージを更新するだけでは、実行中のプロセスが置き換わらないためです。すぐに更新できない場合は、公式告知に従ってSSHのパスワード認証を無効にする方法があります。変更前に鍵認証でログインできることを確認し、新しいログインのテストが終わるまで現在のセッションを維持してください。

事業者が技術的な条件をすべて覚える必要はありません。ただし、セキュリティの境界はWebページや管理画面だけではない、という点は重要です。サイトを動かすサーバー、保守用アカウント、遠隔アクセスの経路もショップに影響します。

ECサイトのセキュリティ問題は、何に影響する？

脆弱性の告知が出たからといって、ショップがすでに攻撃を受けたとは限りません。実際のリスクは、対象ソフトウェアの使用状況、悪用条件、修正の適用状況、該当サービスへのアクセス可否などによって変わります。

一方、脆弱性が悪用された場合の影響は、サーバーの修理だけにとどまらない可能性があります。

• **販売の中断：**サイト、カート、注文処理が利用できなくなる可能性があります。
• **ページの改ざん：**商品情報、転送先リンク、ショップのページが変更されるおそれがあります。
• **機密情報の流出：**権限や保存方法によっては、顧客情報、注文情報、システムの認証情報が危険にさらされる可能性があります。
• **復旧コストの増加：**調査、修正、データの確認に加え、必要に応じて顧客への連絡や法令上の対応も求められます。

特に繁忙期には、サイトの復旧と顧客対応を同時に進めなければならないこともあります。システムの確認に加え、繁忙期のカスタマーサポート実践ガイドも参考に、問い合わせや有人対応の流れを準備しておきましょう。

サイトの構築方法によって、セキュリティ責任はどう変わる？

この表は責任分担を考えるための出発点であり、すべての契約に当てはまるわけではありません。特に、WordPressはソフトウェアであって、単一のホスティング形態ではありません。 自分でクラウドサーバーにWordPressを導入する場合と、マネージドWordPressを契約する場合では、日常の保守責任が大きく異なることがあります。

構築方法を比較している方は、ShopifyとWordPressのサイト構築比較も参考にしてください。セキュリティの観点での大きな違いは、どちらかが絶対的な安全を保証できることではなく、どの部分を誰が管理し、保守するかにあります。

自社構築サイト：自由度が高い分、確認すべき保守事項も増える

自社構築サイトでは、事業の要件に合わせてサーバーやデータベース、アプリを選び、細かくカスタマイズできます。一方で、サーバーを自社管理するなら、OSからアプリまで、全体を継続的に保守する担当者が必要です。

今回の2件を例にすると、技術担当者は次のような点を確認する必要があります。本番サーバーやコンテナは何のシステムを使っているか。どの環境でPHPが稼働しているか。SSHはインターネットからアクセスできるか。パッケージやイメージに修正は含まれているか。更新後にサービスの再起動やコンテナの再デプロイは行われたか。

これらを事業者自身がすべて操作する必要はありませんが、担当者を明確にすることは欠かせません。まずは技術チームや保守事業者に、次の情報を確認しましょう。

1. **資産一覧：**本番・テスト環境、サーバー、ドメイン、重要な外部サービスの所在。
2. **保守の分担：**OS、アプリ、データベース、セキュリティ通知を誰が担当するか。
3. **更新手順：**重要な告知の把握、影響評価、修正、適用確認をどう行うか。
4. **復旧計画：**バックアップの保存場所、復元テストの頻度、障害時の連絡先。

「定期的に保守しています」という回答だけでは、状況が分かりません。前回の更新日、緊急の脆弱性が出た際の連絡方法、修正完了を示す記録の有無まで確認するとよいでしょう。

クラウドサーバーを契約していても、その中のすべてのソフトウェアを提供事業者が自動で更新するとは限りません。例えば、Google Cloudの今回のPHP脆弱性に関する案内では、製品ごとに対応が異なります。一部のサポート対象マネージド実行環境は自動更新されますが、独自コンテナの一部では利用者がイメージを更新して再デプロイする必要があります。実際に利用しているサービスと設定を確認してください。

WordPress / WooCommerce：依存する各コンポーネントを更新する

WordPressの強みは柔軟性です。テーマ、プラグイン、WooCommerce拡張機能を組み合わせ、必要なショップを構築できます。その一方で、コンポーネントが増えるたびに、バージョン、権限、互換性を確認する対象も増えます。

管理画面の通知だけを見るのではなく、次の層に分けて確認しましょう。

• **サーバーとPHP：**自社、ホスティング事業者、保守事業者の誰が更新するか。適用をどう確認するか。
• **WordPress本体：**自動更新は想定どおり動作しているか。失敗時の通知はあるか。
• **プラグインとテーマ：**現在使っているものはどれか。更新、置き換え、削除が必要なものはあるか。
• **独自機能：**更新後も決済、カート、配送、注文通知が正常に動くか。
• **バックアップと復元：**必要なデータベースとファイルが含まれ、正常に使える状態へ復元できるか。

WordPressではプラグインやテーマごとに自動更新を有効にできますが、すべてのサイトのすべてのコンポーネントが自動更新されるわけではありません。ホスティング事業者やプラグインが設定を変更している場合もあり、自動更新自体が失敗することもあります。WordPress公式ドキュメントでは、更新状況に注意を払い、互換性の問題に備えてバックアップを準備することも検討するよう案内しています。

決済に影響する重要な更新は、技術担当者がテスト環境で検証したうえで速やかに本番適用する方法があります。ただし、悪用が進んでいる深刻な脆弱性への対応を、理想的なテストの機会が来るまで無期限に待つこともできません。担当者がリスクを踏まえ、緊急修正、暫定的な防御、業務テストの順序を判断する必要があります。

マネージドWordPressを利用しているなら、PHPのセキュリティ更新、プラグインやテーマの更新を誰が担当するか、バックアップの保管期間や復元の追加料金について、サービス事業者に直接確認しましょう。「セキュリティは任せられますか」だけでなく、具体的な範囲を聞くことが大切です。

ホスティング型サービス：サーバー管理が減っても、安全管理は残る

ShopifyのようなSaaSでは、事業者がプラットフォームのサーバーにログインし、PHPやOSを更新したり、SSHを再起動したりする必要は通常ありません。専任の運用チームがいないECサイトにとって、基盤保守の負担を減らせます。

ただし、スタッフのアカウントやアプリへの権限付与が自社にとって適切かどうかは、プラットフォーム任せにはできません。日常的に次の点を確認しましょう。

• **アカウントの安全性：**オーナーとスタッフが個別のアカウントを使い、2段階認証やその他の対応する安全なログイン方法を有効にしているか。
• **スタッフ権限：**カスタマーサポート、運営、開発者、外部委託先に必要な権限だけを付与し、契約終了時に削除しているか。
• **外部アプリ：**注文、顧客、その他のデータへのアクセスがなぜ必要か。利用終了後に追加の認可を取り消す必要はないか。
• **ドメインと関連アカウント：**ドメイン登録事業者、メール、決済サービスなどの重要アカウントも保護されているか。
• **データと復旧：**何をエクスポートでき、何がプラットフォームやアプリに保存されるか。障害時に顧客と連絡を取り、注文をどう処理するか。

Shopifyの公式ガイドでも、スタッフ権限、ショップのアクティビティ、インストール済みアプリの確認や、アカウントの保護を勧めています。Shopifyのアカウントセキュリティに関するベストプラクティス

外部アプリは、単に数を減らせばよいわけではありません。それぞれの役割とアクセス範囲を把握することが大切です。使わなくなったマーケティング、サポート、データ関連のツールは定期的に整理し、付与した権限を確認しましょう。必要に応じて、アプリ事業者のデータ保管・削除方法も確認します。

チームに共有したいECサイトのセキュリティチェックリスト

どの構築方法を選んでいても、次の項目から始められます。技術的な作業をすべて自分で行う必要はありませんが、明確に回答できる担当者を見つけておくことが大切です。

ステップ1：資産と担当者を確認する

• ショップ管理画面、ドメイン、サーバー、ホスティング事業者、決済サービス、重要な外部アプリを一覧にする。
• 各サービスの担当者、緊急連絡先、アカウントの所有者を記録する。
• 外部委託や保守契約に、どの更新、監視、緊急対応が含まれるか確認する。

ステップ2：今回の2件が自社に関係するか確認する

• PHPサイトを運用している場合は、技術担当者に対象バージョン、ベンダーのパッチ、実行環境を確認してもらう。コンテナを使う場合は、イメージと実際のデプロイ状態も確認する。
• Linuxサーバーを管理している場合は、影響を受けるmusl/OpenSSHの組み合わせ、SSHの認証設定、ネットワークへの公開状況を担当者に確認してもらう。
• ホスティング型サービスでは、利用中のサービスへの影響、修正状況、利用者側の対応が必要かを事業者に問い合わせる。
• 修正後は、更新をダウンロードしただけでなく、稼働中のサービスやデプロイに修正が反映されていることを確認する。

ステップ3：アカウントと権限を確認する

• オーナー、スタッフ、保守担当者には個別のアカウントを用意し、管理者ログインを共有しない。
• 対応する高権限アカウントでは2段階認証などの安全なログイン方法を有効にし、復旧手段も適切に保管する。
• 不要になったアカウント、アプリの認可、認証情報を削除し、ドメインや決済関連のアカウントも確認する。

ステップ4：バックアップと緊急対応計画を検証する

• 業務に必要なデータやファイルがバックアップに含まれるか、保存先、保管期間、アクセス権限を確認する。
• 「バックアップ成功」の表示だけに頼らず、定期的に復元をテストする。
• 異常発生時の連絡先と対応手順、通常どおり注文を処理できない場合の顧客への連絡方法を決めておく。

見覚えのない管理者、不審なリダイレクト、疑わしいログイン記録を見つけた場合は、ソフトウェアの更新だけで終わらせないでください。経験のある技術者に速やかに連絡し、影響を受けたシステムの隔離、ログの保全、侵入範囲の調査、認証情報の変更、関係者への通知が必要か評価しましょう。対応の順序は、事象や事業への影響に応じて判断します。

よくある質問

マネージドWordPressでも、PHPの脆弱性を気にする必要はありますか？

あります。ただし、PHPを自分で更新する必要があるとは限りません。まずホスティング事業者の責任範囲を確認し、利用サービスへの影響と修正状況を問い合わせましょう。独自コンテナや別のPHPサービスも運用している場合は、それぞれ確認が必要です。

Shopifyの事業者は、プラットフォームのサーバーを自分で修正する必要がありますか？

通常はありません。プラットフォームの基盤はサービス事業者が保守します。ショップ側は公式告知を確認し、自社で管理するアカウント、アプリ、関連サービスを見直しましょう。別途、自社構築サイトや自社管理サービスを運用している場合は、それらを個別に評価する必要があります。

自動更新を有効にすれば、バックアップは不要ですか？

いいえ。自動更新は更新漏れを減らすのに役立ちますが、失敗や互換性の問題が起こることもあります。バックアップと復元テストは、障害やその他のインシデントから業務を復旧するために必要です。

技術チームがない場合は、何から始めればよいですか？

まずサイトと関連サービスの提供事業者を一覧にし、管理画面にアクセスできる人と保守担当者を確認します。そのうえで、このチェックリストをホスティング事業者、サイト制作会社、保守担当者に共有し、責任と状況を項目ごとに説明してもらいましょう。すぐに回答できない項目は、担当者と回答期限を決めます。

最後に：セキュリティは一度設定して終わりではない

今回のPHPとOpenSSHの脆弱性は、ECサイトの安全性が一つのパスワードやプラグインだけで決まるわけではないことを示しています。実行環境、遠隔アクセス、サービス事業者の責任、ショップのアカウントやアプリの権限もリスクに関わります。

自社構築サイトは自由度が高い一方、その管理範囲を保守する能力も必要です。ホスティング型サービスは基盤運用の負担を減らせますが、すべてのアカウントや業務上の権限まで事業者に代わって管理することはできません。「常に安全な構築方法」を探すよりも、まず責任範囲を把握し、問題の発見、修正、業務の復旧に向けた手順を整えましょう。

まずはこのチェックリストをショップの担当者やサービス事業者に共有し、次のことを聞いてみてください。自社のサイトは影響を受けますか？ 誰が確認しますか？ 今夜問題が起きたら、誰に連絡しますか？