Blog
サイトの中身は全部 HTML で作ってあるから PHP の脆弱性は関係ない——そう考えたくなります。ところが問い合わせフォームが1つあるだけで話が変わります。
サイトの中身は全部 HTML で作ってあるから PHP の脆弱性は関係ない——そう考えたくなります。ところが問い合わせフォームが1つあるだけで話が変わります。
2026年10月21日、PHP に認証なしでサーバー上のプログラムを実行できる脆弱性が2件公表されました（CVE-2026-109618 / CVE-2026-109619、深刻度は10点満点で9.2）。同じ日に修正版の PHP 8.5.12 / 8.4.27 / 8.3.36 / 8.2.35 が公開されています。
この2件が厄介なのは、成立する場所がアプリケーションのコードより手前だという点です。自分が書いた PHP が丁寧に書けているかどうかは関係ありません。PHP が外からの要求を受け取って処理し始める段階で成立します。
ですから「自分のコードには穴がない」は防御になりません。PHP が動いているという事実だけで対象になります。
よくある構成を思い浮かべてください。ページは全部 HTML で、PHP を使っているのは問い合わせフォームのメール送信だけ。資料請求のフォームがあれば、もう1本増えます。古いサイトから引き継いだ郵便番号の検索やメールアドレスの確認が残っていれば、さらに増えます。
ここで効いてくるのが、さきほどの性質です。この5本が何をするプログラムかは問題になりません。配信されるディレクトリに PHP が置かれていて、サーバーがそれを実行する設定になっている——そこまでで条件が揃います。
もうひとつ厄介なのは、どこからも呼ばれていない PHP が残りがちだということです。作り直したときに古い処理を消し忘れる。昔使っていた機能のファイルだけが残る。使っていないので誰も気にしません。それでも配信される場所に置かれていれば、外からは実行できます。
つまりフォーム1本のために、サイト全体が「PHP が動いているサーバー」になります。守る対象は1本ではなく、サーバー全体です。
こういうとき、取れる道は2つあります。修正版へ更新して PHP を使い続けるか、PHP そのものを無くすかです。
更新は当然やるべきことですが、これは同じことがまた起きるという前提の付き合い方になります。PHP に限った話ではありません。外から実行できるものを1つ置いておく限り、公表のたびに同じ作業が発生します。
当社は無くす方を選びました。会社サイトで PHP が使われていたのはフォームの送信処理だけだったので、受付の処理を別の場所へ移して、配信されるディレクトリに PHP を置かない形へ作り替えました。フォームの見た目と使い勝手は変わりません。変わるのは PHP を使わない方法に変えること、ただそれだけです。
この作り替えは、当社の業務の仕組みの中で働く AI がやりました。もとの PHP を読んで、同じ動きをする受付の処理を用意し、試験を書いて動かすところまでが AI の仕事です。人の仕事は、できあがったものを実際に触って、フォームから資料請求とメールの送信を試し、問題がないかを確かめることだけです。ここがいちばん大きいところだと思っています。直すべきだと分かっていても、作り替える手が無ければ、セキュリティ対策をした版への更新でしのぐしかありません。もちろんセキュリティ対策版に更新するのが正解の場合もあります。当社の場合は問い合わせフォームだけのためにPHPのセキュリティを維持し続けるのは割に合わないと判断したということです。
当社でこのように状況に合わせて柔軟に対応できるのは、業務の仕組みそのものが自社の製品 miraiGen.™Cube だからです。社内のサーバーの中で AI が働いているので、サイトの中身もプログラム自体の作り替えも同じ場所で扱えます。とても便利だと感じているところです。まだまだこのサーバーは AI とともに成長していくと思います。
無くしてしまえば、次に同じ種類の公表があっても自分には関係がないと1行で判断できます。この「関係がないと判断できる状態」は、対策そのものより大きいと思っています。緊急の脆弱性でいちばんこたえるのは作業そのものではなく、調べて判断して段取りするところですから。
静的なサイトなら、PHP を置かない形にできることが案外あります。一度数えてみる価値はあると思います。