PHP叩きで終わらせない。
今回の脆弱性が教えてくれた「サイトの主治医」の重要性
2026年10月、PHPの重大な脆弱性が公表され、国内でも多くのWebサービスが緊急メンテナンスを実施しました。
ニュースを見て、「PHPは危険なのか」と不安になった方もいるでしょう。報道の見出しが続くと、PHPそのものが批判されているようにも感じられます。
今回の問題は、軽視できるものではありません。しかし、そこから「PHPは危険な言語だから使うべきではない」と決めつけるのは間違いです。
PHPは、Web制作の裾野を広げてきた技術
PHPは、ホームページ制作の需要が拡大した1990年代後半から2000年代に、Web開発に適した技術として広まりました。
HTMLに処理を組み込み、簡単な動的ページなら少ないコードから作り始められること。データベースとの連携を組み込みやすいこと。こうした特徴が、個人や小規模な制作会社にとっての使いやすさにつながりました。PHP公式の歴史でも、その発展の経緯を確認できます。
その後、WordPressなどのCMSが普及し、企業サイトから予約・会員管理を備えたサイトまで、PHPの活用範囲が広がりました。こうしたサイトを安定して運営するには、画面の制作だけでなく、データベースとの連携、アクセス権限の設定、セキュリティ更新、各機能の動作確認まで、一貫した設計と管理が必要です。弊社は、その技術的な基盤から運用・保守までを担当しています。
PHPが支えてきたのは、企業のホームページだけではありません。Wikipediaや、ネットショップ構築のEC-CUBEなど、幅広い分野で使われています。
今回の問題が大きく取り上げられた背景には、それだけ多くのサービスを支えているという事情もあります。
今回必要だったのは、PHP本体への修正
脆弱性は、アプリケーションやフレームワーク、言語の実行環境、サーバーOSなど、さまざまな場所で見つかります。今回は、WordPressなどをサーバー上で動かす「PHP本体」のメモリ管理に不備が見つかりました。実行環境本体の脆弱性は過去にもあり、PHPだけに起こる問題ではありません。弊社では、問題の箇所と影響範囲を確認し、必要な修正を適用します。
条件によっては、管理画面へのログインを経由せず、不正なコードを実行される可能性がありました。サイトの文章や利用者が書いたプログラムを直すだけでは対処できず、PHP実行環境への修正が必要でした。詳しくはPHP公式発表をご覧ください。
一方で、「PHPを使っている」「未修正である」「実際に侵入された」は、それぞれ別の状態です。
サービスを予防的に停止したことも、被害が発生したことを意味するわけではありません。危険性と対応状況を分けて見る必要があります。
「修正パッチ公開」は、大掛かりな作り直しを意味しません
「修正パッチの適用」と言われると、難しい作業に聞こえるかもしれません。しかし、今回の主要な対策は、PHPを修正版へバージョンアップすることです。例えば、8.3.35から8.3.36への更新です。専門用語だけでなく、何を更新するのかまで伝えれば、必要な対応は理解しやすくなります。
弊社では、この更新作業に加え、必要な設定の確認とサイトの動作確認まで担当します。お客様ご自身で難しい作業をしていただく必要はありません。
その対応を支えるのが、日頃の保守です。更新できる状態を維持していれば、緊急時にも修正版の適用と確認を進めやすくなります。
提供元によっては、既存のバージョンに修正部分だけを取り込む場合もあります。弊社では、提供元の案内と実際の適用状況を確認して対応します。
ただし、更新版が公開されただけで、すべてのサイトへの適用が完了するわけではありません。弊社は、必要な更新の反映と動作確認、続報への対応まで一貫して担当します。
実際、PHP公式は10月23日に、特殊な構成向けの追加対策も案内しています。PHP公式の追加案内のように、更新後の情報も弊社が確認し、管理しているサイトへの影響を判断して必要な対応を行います。
サーバー会社側で、すでに対応が進んでいた例もあります
Xserverは、レンタルサーバーのPHP 8.2〜8.5について、10月22日午前6時45分までに対象全サーバーへの修正適用を完了したと報告しています。
同社は、利用者サイトを稼働させたまま対策を進めたと説明しています。
Xserverに加え、さくらインターネットやGMOペパボのロリポップ！なども、PHPの修正適用や対応完了を報告しています。対応中に一部サービスを予防的に停止した例もありますが、それ自体が被害の発生を意味するわけではありません。
こうしたサーバー会社の対応についても、弊社が公式情報と保守対象サイトへの適用状況を確認し、必要な作業と動作確認まで担当します。お客様ご自身で各社の技術情報を調べたり、更新作業を行ったりする必要はありません。
出典：
Xserver公式の対応報告、
さくらインターネット公式の対応報告、
ロリポップ！公式の対応報告
今回の脆弱性への対策が確認できたサイトまで、未対応のサイトと一律に危険視する必要はありません。
言語を変えても、保守の必要性はなくなりません
PHPだけでなく、Ruby、Python、Node.jsなどの実行環境や、その周辺のライブラリ・フレームワークにも脆弱性は見つかります。
もちろん、すべての問題が同じ深刻度や影響範囲というわけではありません。しかし、「別の言語へ変えれば、今後はセキュリティ更新が不要になる」とは考えられません。
LinuxなどのサーバーOSを土台に、Webサーバー、言語の実行環境、アプリ、追加部品が重なってサイトは動いています。弊社では、保守対象となる構成を把握し、提供元の対応確認と弊社による更新・設定作業を通じて管理します。
特定の言語への不信だけでは、安全な運用体制は作れないのです。
無償で使える技術は、多くの人の努力で支えられています
PHPなどのオープンソース技術は、無償で利用できる一方、維持に労力がかからないわけではありません。
不具合の調査、修正、テスト、文書の整備。その積み重ねによって、私たちは便利な技術を使い続けられています。
支えているのは、個人のボランティアだけではありません。企業や財団の支援、有給の開発者による保守もあります。PHP Foundationも、開発者への資金支援やセキュリティ改善の体制を説明しています。
不備に対する検証や改善要求は必要です。それと同時に、問題を修正して届ける人々の仕事にも目を向けたいものです。
本当に避けたいのは、「更新できない状態」の放置
日頃から更新していたサイトでも、新しい脆弱性への対応は必要になります。それでも、普段の保守には大きな意味があります。
例えば、PHP 7系などの古い環境を長く使い続けてきた場合、今回を機に新しい系列へ更新しようとして、大幅な修正や見直しが必要になることがあります。これまで何とか動いていたプログラムが更新後に動かなくなり、表示や予約機能の復旧に追われ、慌てている方もいるかもしれません。緊急時にまとめて対応する負担を減らすためにも、日頃から点検と更新を積み重ねておくことが大切です。
「昨日まで動いていた」ことは、「これからも安全に使える」ことの保証にはなりません。弊社では、日頃の点検と更新によって、こうした状態を防ぎます。必要な更新の判断から作業、動作確認まで弊社が担当し、お客様のホームページを継続して運営できるよう管理します。
保守の目的は、バージョン番号を上げることだけではなく、「必要なときに更新できる状態」を維持することです。
ホームページにも「主治医」が必要です
会社は営業しているのに、ホームページが突然見られなくなる。お客様には事情が分からず、「営業をやめたのだろうか」「予約は受け付けているのだろうか」と不安を与える可能性があります。
ホームページの保守は、会社の信用と、問い合わせ・予約の窓口を守る仕事でもあります。
普段の構成や更新履歴、業務上欠かせない機能を把握している管理先がいれば、異変が起きた際にも判断しやすくなります。
弊社が定期検査を行い、状態に合わせたメンテナンスを続ける。私たちは、それを「サイトの主治医」の役割だと考えています。
弊社は、緊急対応も想定して日頃の保守を行います
弊社では、バージョン管理と定期的なメンテナンスによって、「いざというときに更新できない状態」を防ぎます。
必要なセキュリティ更新は、あらかじめお任せいただいている保守範囲で、お客様への都度の確認を待たずに実施します。
掲載内容や予約システムなどの機能を維持し、可能な限り業務への影響を抑えながら、更新と動作確認を行うところまでが、弊社の保守です。
また、月額料金には今回のような事態を想定した保守費用も含まれています。保守対象のセキュリティ対応について、緊急作業を理由に突然の追加料金をご請求することはありません。
PHPを責めるだけでは、ホームページは守れません。守るために必要なのは、日頃から状態を把握し、問題が見つかったときに対応する仕組みです。
技術的な判断や思いがけない出費に悩まず、本業に専念していただくために。ホームページの制作から運用・保守まで、サイトの主治医として弊社にお任せください。
後書き――緊急対応を支えたエンジニアの皆さんへ
今回、Laravelなどを使ったWebシステムや、そのサーバーの運用・保守を担当していた方々は、対応に追われたのではないでしょうか。急な連絡を受け、更新の準備やメンテナンス、動作確認に時間を割いた方もいたと思います。
とくに、予約・決済・会員管理などの機能を持つシステムでは、PHPを更新するだけでなく、利用しているフレームワークや関連部品との互換性を確認し、業務機能が正常に動くかを検証する必要があります。更新の操作そのものよりも、その判断と確認に神経を使う場面もあるでしょう。
ニュースで、パソコンに向かって対応を続けるエンジニアの姿を見た方もいると思います。その映像だけで担当業務は分かりませんが、PHP本体を書き直していたとは限りません。管理するシステムへの修正版の適用や、設定の確認、更新後の検証に取り組んでいた可能性もあります。
これはLaravelだけに限った話ではありません。「バージョンを更新する」という短い言葉の裏には、サービスを支える人たちの判断と確認作業があります。今回の出来事を、言語への批判だけで終わらせず、その対応を担ったエンジニアの仕事にも目を向けたいと思います。
本記事は2026年10月28日時点の情報に基づいています。