PHPの脆弱性（PHP2Shell）と会社サイト｜静的なページで足りるなら移行を進める

結論から書きます。会社概要やサービス紹介のように、静的なページで足りる会社サイトは、移行を進めてよいと考えます。一方、裏側でプログラムがデータベースを呼び出すサイトは、移してもプログラムの脆弱性のリスクが残ります。この記事では、その分け方をまとめます。

10月21日夜〜22日に起きたこと

10月21日夜から22日にかけて、PHPの重大な脆弱性「PHP2Shell」が報じられました。PHPは、WordPressの下で動くプログラム言語です。外から勝手にプログラムを動かされる種類の欠陥で、PHP公式の深刻度は10点満点で9.2でした。

修正版は21日夜に公開され、22日に IPA と JPCERT/CC が注意喚起を出しました。首相もXで対応を呼びかけています。攻撃の試みは大量に観測されましたが、侵入に成功した被害は、22日時点で公には確認されていません。

レンタルサーバーの利用者は、待つしかなかった

PHP本体の欠陥なので、WordPressやプラグインを更新しても直りません。共用レンタルサーバーでは、PHPを管理しているのは事業者です。利用者は、事業者の修正を待つしかありませんでした。

Xserver は管理画面を止め、22日朝までに PHP 8.2〜8.5 の修正を終えました。さくらインターネットも21日夜から緊急メンテナンスに入っています。

当社の実例：11日前に移っていたのは、半分が偶然

当社の公式サイトは、ニュースの11日前の10月10日に、Xserver＋WordPress から Cloudflare Pages へ移っていました。ページは作り置きの静的なHTMLで、PHPは使っていません。今回の件で、私がサイトに対してすることはありませんでした。21日夜から22日にかけては、XとFacebookで注意喚起を投稿しました。

移した理由は、「AIで攻撃が速くなる」という話を、複数の記事や動画で繰り返し目にしていたからです。英国の国家サイバーセキュリティセンター（NCSC）も、「公表から悪用までは数日に縮んでおり、AIでさらに縮む」と書いています。実際、今回の欠陥は複数の研究者がAIを使って見つけました。

ただし、私が心配していたのは WordPress の管理画面とプラグインでした。PHP本体の欠陥は、まったく予想していません。入口を減らす方針が、想定外の入口までふさいでいた。これが正直なところです。

見直す物差しは「その夜、自分の手で直せるか」

静的なページにすると、なくなる入口と、残る入口があります。

残る側は、どれも自社のアカウントと設定の話です。2段階認証を入れ、誰が持っているかを決めれば、自社の手で備えられます。メールの備えは構成に関係なく必要です。

静的なページで足りるなら、移行を進める

分かれ目は、「サイトの裏側で、プログラムがデータベースを呼び出す必要があるか」です。

多くの会社サイトは、見せるだけのページで足ります。WordPressで作っていても、中身が会社概要とお知らせだけなら、PHPもデータベースも本来は要りません。静的なページに移せば、今回のような欠陥を待つ側から抜けられます。

裏側でデータベースを使うサイトは、話が違います。プログラムを動かす限り、PHPでも別の言語でも、脆弱性のリスクは残ります。移しても消えません。この場合に確かめるのは、プログラムの更新を誰が続けているか、サーバー事業者の告知を誰が受け取っているか、の2点です。

費用や機能の比較は、以前の記事にまとめています。

まとめ

• PHP本体の欠陥は、WordPressを更新しても直らず、レンタルサーバーでは事業者を待つしかなかった
• 静的なページで足りるサイトは、移行を進める。今回のような欠陥を待つ側から抜けられる
• 裏側でデータベースを使うサイトは、移してもプログラムの脆弱性のリスクが残る。更新を続ける体制を保つ
• どちらの構成でも、アカウント・DNS・メールの守りは自社で備える

自社のサイトが静的なページで足りるのか分からない場合は、お問い合わせからご相談ください。

お問い合わせはこちら