【コラム】PHPの緊急対応から考える、生成AI時代の中小企業の備え

自社のWebサービス、どこまで把握できていますか?

2026年10月、PHPの重大な脆弱性(セキュリティ上の弱点)への対応として、Webサイトや管理画面を一時停止する動きが相次ぎました。サーバー会社からの案内を見て、「自社のホームページは大丈夫だろうか」と気になった方もいらっしゃるのではないでしょうか。

PHPを自分で使ったことがなくても、WordPressで作られたホームページや、ネットショップ、会員向けサービスなどを利用していれば、関係する可能性があります。同じ時期には、国内企業から個人情報流出の公表も続きました。

何が起きているのか。その背景に、生成AIはどう関わっているのか。そして、中小企業の経営者やIT担当者は何を確かめればよいのか。今回は、身近なWebサービスを入口に考えてみたいと思います。

1.今回見つかったのは、Webサービスを動かす「土台」の弱点

PHPは、Webサイトを動かすサーバー上で、ページの表示やデータの処理を担うプログラミング言語です。例えば、入力フォームの内容を受け取ったり、保存された情報を取り出して画面に表示したりする処理に使われます。今回注目された「PHP2Shell」は、PHP本体のメモリ管理やエラー処理に関する二つの脆弱性の通称です。条件がそろうと、外部の攻撃者がログインせずに、サーバー上でプログラムを実行することなどにつながります。[1]

この問題は、PHPを共通の基盤として使う、さまざまなWebサイトやサービスに関係します。特定のWebサイトや追加機能(プラグイン)だけに限った不具合ではありません。

PHPの開発元は10月21日に修正版を公開しました。WordPressを最新にすることと、その下で動くPHPを修正することは、別の対応です。 WordPress公式も、サーバー会社の案内を確認し、PHPを更新するよう呼びかけています。[2]

修正の対象を確認するために
今回の共通識別番号はCVE-2026-109618、CVE-2026-109619です。CVEは、どの脆弱性の話かを特定するための番号です。PHP本家がサポートする系列の修正版は、PHP 8.2.35/8.3.36/8.4.27/8.5.12です。PHP 8.1以前は本家のサポートが終了しています。ただし、サーバー会社やOS提供元が独自に修正を提供する場合もあります。表示番号だけでなく、利用中の環境に対する修正の有無を確認します。[1][3][13]

IPAは10月27日、二つの脆弱性が、前日の26日(現地時間)に米CISAの「実際に悪用された脆弱性の一覧(KEV)」へ登録されたと追記しました。一方、同日のIPAの案内では、国内の攻撃被害事例は把握していないとしています。「悪用され得る」という段階から、実際の悪用を踏まえた対応が必要な段階に進んでいます。[1]

2.PHPは、ECサイトやさまざまなWebサービスにも使われている

PHPで作られたソフトウェアの代表例が、ホームページやブログを管理するWordPressです。ただし、PHPの用途はホームページ制作に限りません。ECサイト(ネットショップ)を構築するソフトウェアや、会員・予約サービス、問い合わせフォーム、Webメール、ファイル共有などにも使われています。

こうした仕組みは、ソースコードが公開され、ライセンスに従って利用・改変・再配布できる「オープンソース」のソフトウェアだけでなく、商用のパッケージ製品や、月額などで利用するクラウドサービスとしても提供されています。PHPは、こうした異なる提供形態の製品・サービスの開発に使われています。[10][11]

なお、「オープンソースかどうか」と「無料か有料か」は別の区分です。 オープンソースを使う製品・サービスでも、利用や保守に料金がかかる場合があります。[10]

自社でプログラムを書いていなくても、購入したソフトウェアや契約中のサービスの内部でPHPが動いていることがあります。一方、同じ用途でもPHPを使わない製品・サービスもあるため、用途名だけで影響を判断せず、自社の環境を提供元に確認します。

図1:WordPressのホームページ、ECサイト、会員・予約サービス、Webメール、ファイル共有などの下でPHPが使われることがある。アプリの更新とPHPの修正は分けて確認する。

 

図1 PHPが使われている身近な用途の例。すべてのECサイトやWebメールがPHP製という意味ではありません。

ここで大切なのが、「どの製品か」に加えて、「誰が、その環境のPHPを管理しているか」です。

同じWordPressでも、サーバー会社が提供するPHPを使う場合と、VPS(仮想専用サーバー)などで自社や運用会社がOS・ソフトウェアを管理する場合では、更新する担当が異なります。制作会社に構築を頼んだサイトも、納品後の保守まで契約に含まれているとは限りません。

3.各社の「対応完了」は、対象サービスとセットで読む

最初に確かめたいのは、レンタルサーバー会社が提供するPHPを使っているのか、VPSなどで自社・運用会社がPHPを管理しているのかです。会社名が同じでも、サービスによって担当は異なります。

レンタルサーバー会社が提供するPHPで、自社の契約プランが修正の対象に含まれ、適用完了と利用者の追加作業不要が案内されていれば、今回のPHP修正については利用者側の操作が不要なケースがあります。 まずは、公式のパッチ適用案内と、自社向けの個別連絡を確認しましょう。[3]

サービス公表された対応利用企業が確認したい点
ConoHa WING10月22日、提供する全PHPへ修正を適用この対策のためのPHPバージョン変更は不要。表示番号が変わらない修正もある
さくらのレンタルサーバ管理画面から選択できるPHPへの対応を完了対象のPHPは利用者の作業不要。独自にインストールしたPHPは対象外
エックスサーバー/XServerビジネス/XServer for WordPress対象のPHP 5.1〜8.5への対応を10月26日までに完了本件のために急いでPHPバージョンを変更する必要はない。VPSは利用者側で別途対応

表1 各社の公式案内に基づく対応例(2026年10月27日確認)。個別の追加案内がある場合は、そちらも確認してください。[3]

一方、VPSや独自に導入したPHPでは、サーバー会社が今回の修正まで代行するとは限りません。自社や契約した運用会社が、OS提供元の修正情報と、実際にWebサイトで稼働しているPHPへの適用を確認します。OSのパッケージではPHPの基本番号を保ったまま修正される場合もあります。必要なサービス再起動など、修正を稼働中の処理へ反映する作業も含めて確認します。[13]

PHP本家は、サポートが終わったPHP 7.4・8.0・8.1向けにも、今回の問題に対する最小限の修正コードを公開しています。ただし、通常サポートが再開したわけではありません。提供元の修正が受けられるか、誰が適用するかを確認し、修正が提供されない環境では、サポート中のPHPや対策済みサービスへの移行を検討します。[1][3][15]

また、PHP 8.2の本家によるセキュリティサポートは、2026年12月31日に終了予定です。今回の修正が済んでいても、継続的に保守できる環境への移行計画は、別に進めておく必要があります。[15]

図2:PHPを使うサービスと更新担当の違い。提供会社のPHPは対象プランの対応案内を確認し、VPSや独自PHPは管理担当が対応する。修正適用と侵害の確認は分けて扱う。

 

図2 利用環境によるPHPの管理担当の違い。修正の適用と、適用前の侵害の確認は分けて扱います。[3][12]

修正の適用と、適用前の侵害の確認を分ける

パッチは弱点をふさぐもので、すでに起きた侵害を取り消すものではありません。AWSは、公表前の10月17日に悪用の試みを観測し、侵害の調査は少なくとも同日まで遡るよう勧めています。[12]

影響を受けるPHPを公開していた場合は、修正済みでも、少なくとも10月17日以降、修正が反映されるまでの期間について、ファイルの改ざんや不審なアクセスなどを確認することが大切です。 これは、すべてのサイトが侵入されたという意味でも、17日より前は安全だという意味でもありません。[12]

JPCERT/CCも、修正の適用と侵害有無の調査を勧めています。攻撃手法や記録の状況によっては痕跡が残らない場合もあるため、点検で異常が見つからなかったことだけで、攻撃を受けていないと断定することはできません。[14]

レンタルサーバーでは、提供会社の調査結果や追加案内を確認し、自社で確認できるアクセス記録やサイトの変更履歴を点検します。サーバー内部など利用者が確認できない範囲や、不審な点がある場合は、提供会社や保守先へ相談します。利用者全員がサーバー内部を自力で調査するのではなく、管理範囲に応じて役割を分けることが大切です。WordPress本体やプラグインの日常の保守も、今回のPHP修正とは別に続けます。

4.情報流出の公表が続く中で、押さえたい変化

同じ時期、ソースネクストは会員情報取得APIの不正利用を公表しました。APIは、アプリやシステムが情報をやり取りする窓口です。また、ネットショップ構築サービス「futureshop」は、利用する1店舗の会員情報漏えいを公表しました。ただし、同時期の出来事を、すべてPHP2Shellの被害として結び付けることはできません。[4]

実際、futureshopは10月25日の説明で、PHP2Shell対策のメンテナンス、10月21日に検知した不正アクセス、1店舗の会員情報漏えいを、それぞれ別の事象と説明しています。同社によれば、futureshop本体はPHPを使わず、サイトのコンテンツを管理する仕組み(CMS)用のサーバーオプションでPHPを提供しています。[4]

これらの事故の原因とは分けて、セキュリティを取り巻く変化として押さえたいのが生成AIです。今回の資料からは、次の三つの関わりが見えてきます。

図3:AIはソフトウェアの点検・報告の検証、攻撃への悪用、侵入の検知に関わっている。それぞれ異なる発表に基づく事例で、個別事故すべての原因をAIとするものではない。

 

図3 AIが関わる三つの場面。同じ事件の一連の経過を示す図ではありません。[5][6][7]

点検・検証を支えるAIと、それを生かす保守体制

PHP Foundationの説明では、関連する問題の兆候は2024年に把握されていました。修正には互換性などの技術的な難しさがあり、さらに意思決定の進め方と、深い知識を持つ開発者の不足が重なり、作業が停滞したと振り返っています。[6]

同団体は、PHPのスキャンや、報告・攻撃手法の検証にAIツールを取り入れているとも説明しています。ただし、この説明だけから、今回の二つの脆弱性を報告者がAIで発見したとまでは断定できません。[6]

AIで点検を支援できても、修正方針を決め、検証し、適用する人と時間は必要です。これは、中小企業が保守に必要な体制や予算を確保するうえでも、考えておきたい点です。

攻撃する側も、AIを使って調べている

サイバー攻撃への対応を支援するJPCERT/CCは10月15日、攻撃者がAIを利用し、既知の脆弱性の探索やAPI経由の攻撃などを行っていたことを確認したと公表しました。10月23日の注意喚起にも、AIを用いた攻撃基盤の悪用が追記されています。[5]

APIは、利用者が操作する画面に見えていなくても、接続先や仕組みを調べられる可能性があります。NICT(情報通信研究機構)も、公開アプリを解析してサーバーを狙う攻撃を取り上げ、AIによる解析・探索の効率化で、より多くのシステムへ攻撃が及ぶ可能性に注意を促しています。[8]

過去の侵入が、新たに見つかることもある

デジタルアーツは、AIを使った点検で、従来発見できなかった不正アクセスの痕跡を見つけたと公表しました。中には2025年7月頃に遡る痕跡も含まれていました。[7]

つまり、公表が続く背景には、攻撃の変化に加え、過去の侵入が新たに見つかる動きもあります。発生日・発見日・公表日は、分けて見る必要があります。 個々の事故へのAIの関与や、被害増加への寄与の大きさまで、この情報から断定することはできません。

5.中小企業が見直したい、四つの備え

今回の対応を一時的な作業で終わらせず、継続的な保守体制の見直しにつなげることが大切です。経営者とIT担当者が共有しておきたい点を、四つに整理します。

① 使っているシステムと、更新する担当者を明確にする

ホームページ、ECサイト、問い合わせフォーム、Webメール、会員管理、社内の管理画面を挙げ、それぞれの管理者と保守契約を確認します。「制作会社に任せている」という説明から、誰がどこまで更新するのかを確かめる一歩です。業務上必要のない管理機能などをインターネットへ公開したままにしないことも、併せて点検します。[5]

② 更新に必要な時間と予算を、平時から確保する

古いアプリが動かなくなる、担当者がいない、仕様書がない。修正版が出ても、こうした事情で適用が進まないことがあります。保守費用と移行計画を、事業を続けるための費用として扱う必要があります。

自社の環境が影響を受け、未修正のまま公開している場合は、通常の保守日を待たず、更新やアクセス制限、一時停止を判断します。その判断を技術担当者だけに背負わせず、業務への影響も含めて経営側が関わることが大切です。[1]

③ 顧客情報は、持つ理由と残す期間を確かめる

集める目的、保存期間、アクセスできる人を見直します。法令や契約で必要な保存を踏まえ、利用目的を終えたデータを不要に持ち続けないことも、被害を抑える備えになります。外部サービスを使っていても、事故時の顧客対応や、漏えい等の報告・本人通知を誰と進めるかは、確認しておきたい事項です。[5][9]

報告義務の対象となる漏えい等を知った場合、個人情報保護委員会への速報は速やかに(目安は概ね3〜5日以内)、確報は原則30日以内、不正な目的で行われたおそれがある場合は60日以内です。調査の完了を待たず、報告の要否と担当を早期に確認します。[9]

④ 異常時の連絡先と、止める判断を決める

誰に連絡し、誰が公開停止を決め、どのアクセス・操作記録を残すか。修正する作業と、すでに侵入されていないか調べる作業も分けます。異常が疑われるときは、記録を失わないよう、保守先や専門家と相談して対応します。

おわりに

PHPの更新は技術的な作業ですが、担当者や保守契約、更新予算を明確にすることは、経営上の課題でもあります。自社のサービスを誰が管理し、対応状況をどのように確認するのか。この機会に、保守会社やサービス提供会社との役割分担を確かめておくことが大切です。

まずは公式案内で自社の環境の対応を確認し、不明な点を保守先へ確かめてみてはいかがでしょうか。

当社のどの環境でPHPを使っていますか。今回の修正は、いつ、どこまで適用されましたか。適用済みと確認できる案内や記録、適用前の侵害に関する確認状況と、当社に残る作業を教えてください。

その回答を、「対象・担当・適用日・残る作業」の四つで残す。そして、必要な予算と次の更新時期まで決める。生成AIによって変わる攻撃に向き合うためにも、こうした日々の管理を経営の中へ組み込んでいきたいと思います。


参考情報

公開情報の確認基準日:2026年10月27日。各社の対応や続報は更新されるため、利用中の環境に関する最新の公式案内もご確認ください。

  1. IPA:PHPの脆弱性対策について

  2. WordPress公式:Critical PHP Security Release

  3. ConoHa WING、さくら、エックスサーバーの公式対応案内

  4. ソースネクストの発表、futureshopの10月23日発表・10月25日の説明

  5. JPCERT/CCの調査・10月23日更新の注意喚起

  6. PHP Foundation:発見・修正の経緯

  7. デジタルアーツ:不正アクセスに関する発表

  8. NICT:アプリ解析からのサーバー攻撃への注意喚起

  9. 個人情報保護委員会:漏えい等の対応

  10. Open Source Initiative:オープンソースの定義、WordPress公式:概要とライセンス

  11. Adobe Commerce公式:システム要件(商用EC製品のPHP利用例)

  12. AWS:公表前の悪用の試みと対応の勧告

  13. Ubuntu:CVE-2026-109618・CVE-2026-109619、Red Hat:PHPの脆弱性と稼働中の処理への反映

  14. JPCERT/CC:PHPにおける複数の脆弱性に関する注意喚起(JPCERT-AT-2026-0033、10月26日更新)

  15. PHP公式:サポート期間、旧版向けの最小限の修正コードに関する案内

◆ 執筆者プロフィール 

小泉 智之


ITコーディネータ京都理事

中小企業診断士、ITコーディネータ、ITストラテジスト、プロジェクトマネージャ