2026年10月21日、プログラミング言語PHPに深刻度「緊急」の脆弱性が2件公表されました。米国家安全保障局(NSA)が国内の全組織に直ちに対応するよう求め、欧州では政府系サイトが一時停止するなど、世界的な対応が続いています。
PHPは、世界のウェブサイトの裏側で当たり前のように動いている言語です。自社サイトが対象かどうかを把握していない企業も少なくありません。この記事では、何が起きたのか、どんなリスクがあるのか、そして何をすればよいのかを、技術者でない方にも分かるようにまとめます。
2026年10月21日に何が公表されたのか
PHPの開発チームは10月21日、認証なしでリモートコード実行(RCE)につながりうる脆弱性2件を修正したバージョンを公開しました。「認証なし」とは、IDやパスワードを持たない第三者が、外部から直接攻撃できるという意味です。
| CVE番号 | 内容 | 深刻度(CVSS v4.0) |
|---|---|---|
| CVE-2026-109618 | メモリ不足(OOM)時の処理中断により、リクエストのデータが中途半端な状態で残る。その後の後始末処理が不正なデータを有効なものとして扱ってしまう | 9.2(Critical) |
| CVE-2026-109619 | リクエストが持っていた内部状態が、メモリ解放後も残る。同じワーカーで処理される次のリクエストが、その古い状態を使ってしまう | 9.2(Critical) |
CVSSは10点満点で危険度を表す国際的な指標です。9.2は最上位の「緊急(Critical)」にあたります。
修正されたバージョン
PHP公式は、以下のバージョンへの即時アップデートを全利用者に強く推奨しています。
- PHP 8.5.12
- PHP 8.4.27
- PHP 8.3.36
- PHP 8.2.35
PHP 8.1以前はすでに開発チームからの更新提供が終了しています。PHP 7.4、8.0、8.1については、ソースからビルドする利用者向けに最小限のバックポートが用意されました。Linuxディストリビューションやサーバー事業者が独自にパッチを配布している場合もあるため、利用中のサーバーの案内を確認してください。
影響を受ける構成
ウェブからのリクエストを処理しているPHP環境はすべて対象です。PHP-FPM、Apache mod_php、php-cgi、FrankenPHP、LiteSpeedなどが該当し、とくにmod_php構成のリスクが最も高いとされています。
世界はどう動いたか
今回の件は、一企業のシステム障害ではなく国家レベルの対応に発展しています。報道されている動きは次のとおりです。
- 米国家安全保障局(NSA)が10月21日、国内の全組織に直ちに対応するよう求めた(共同通信)
- FBIも注意喚起を出した(朝日新聞)
- 欧州各国で政府系サイトが一時停止。パリ警視庁のサイトも障害が発生し、対応に追われた(朝日新聞、FNNプライムオンライン)
- 日本国内でもホームページの緊急メンテナンスが相次いだ(FNNプライムオンライン)
脆弱性の公表から24時間以内に、各国でサイトを意図的に遮断する判断が取られました。更新作業が終わるまでサイトを止めたほうが安全だと判断されるほど、深刻度が高いということです。
そもそもPHPとは何か
PHPは、ウェブサイトの裏側でページを組み立てるためのプログラミング言語です。ブラウザに表示されるHTMLを、アクセスのたびにサーバー側で生成する役割を担っています。
W3Techsの調査(2026年10月21日時点)では、サーバーサイドの言語が判明しているサイトのうち69.3%がPHPを使用しています。WordPressをはじめとする主要なCMS、ECサイトの構築システム、会員サイト、問い合わせフォームなど、その利用範囲は非常に広いものです。
「自社サイトがPHPで動いているか分からない」という場合でも、WordPressで作られているなら確実にPHPが動いています。制作会社に任せきりで構成を把握していない場合も、対象である可能性は高いと考えてください。
バージョン別の利用状況
同じ調査でのPHP利用サイトの内訳は次のとおりです。
| 系統 | シェア | 状況 |
|---|---|---|
| PHP 8系 | 65.2% | 今回の修正版が提供されている |
| PHP 7系 | 27.0% | 公式サポート終了。バックポートまたは事業者のパッチが必要 |
| PHP 5系 | 7.7% | 公式サポート終了。今回以前から危険な状態 |
約35%のサイトが、公式のサポートが終了したバージョンで動いています。この層が今回最も対応に困る部分です。
なぜ見つかったのか
報道によれば、今回の脆弱性は10年以上にわたって気付かれないまま放置されていたもので、最先端のAIによって発見されました(朝日新聞)。ITmedia NEWSは、OpenAIのAIが発見したこと、そして「同様の発見が今後数カ月で急増する」との見方を伝えています。
長年多くの技術者が目を通してきたコードの中から、人間が見落としていた欠陥をAIが掘り起こしたかたちです。これは防御側にとって良いニュースであると同時に、攻撃側も同じ手法を使えることを意味します。今後、既存のソフトウェアから重大な脆弱性が見つかる頻度は上がる可能性があります。
この脆弱性で何が起きうるのか
リモートコード実行の脆弱性を悪用されると、攻撃者はサーバー上で任意のプログラムを動かせます。具体的には次のような被害につながります。
- サイトの改ざん。表示内容を書き換えられる、別サイトへ強制的に転送される
- 情報の持ち出し。データベースに保存された会員情報、問い合わせ内容、注文履歴などが抜き取られる
- 踏み台にされる。自社サーバーが他社への攻撃や迷惑メールの送信元として使われる
- ランサムウェアの侵入口。サーバー内のファイルを暗号化され、業務が停止する
- 検索順位の下落。改ざんを検知されると検索結果に警告が表示され、流入が消える
最後の点は見落とされがちですが、実務上の影響は大きい部分です。Googleに「このサイトは危険です」と判定されると、復旧後も信頼が戻るまで時間がかかります。
いま何をすればよいか
1. 使っているPHPのバージョンを確認する
レンタルサーバーの管理画面、またはサーバー事業者のコントロールパネルで確認できます。社内に技術担当がいない場合は、制作を依頼した会社に「PHPのバージョンと、今回の脆弱性への対応状況」を問い合わせてください。
2. 修正版へ更新する
8.5.12 / 8.4.27 / 8.3.36 / 8.2.35 のいずれかへ更新します。更新だけが完全な解決策です。PHP公式も、後述の緩和策は攻撃経路を減らすだけで安全にはならないと明言しています。
更新後は、サイトが正常に表示されるか、フォームや決済などの機能が動作するかを必ず確認してください。メジャーバージョンをまたぐ更新では、古いプログラムが動かなくなる場合があります。
3. すぐに更新できない場合の緩和策
PHP公式が示している暫定的な設定です。あくまで時間稼ぎであり、更新の代わりにはなりません。
session.upload_progress.enabled=0を設定し、すべてのワーカーを再起動するpost_max_sizeを小さくする(ファイルアップロードが不要なら8M、必要なら32Mが目安)upload_max_filesizeはpost_max_sizeより小さくする- PHP 8.5の場合は
fatal_error_backtraces=0も設定する RLIMIT_ASやRLIMIT_DATAは使用しない(脆弱なメモリ確保の失敗を誘発するため)
設定を変更したら、必ずすべてのワーカーを再起動してください。
4. レンタルサーバーを使っている場合
多くの共用レンタルサーバーでは、事業者側がPHPを更新します。契約しているサーバー会社のお知らせページを確認し、対応予定が告知されているかを見てください。自分でバージョンを選択できる契約の場合は、管理画面から更新版を選ぶ必要があります。
5. 更新後に改ざんがないかを確認する
公表前から攻撃を受けていた可能性を考え、更新後はサイトの表示、管理画面のユーザー一覧、サーバー上の不審なファイルの有無を確認してください。アクセスログに不自然なリクエストが残っていないかの確認も有効です。
弊社サービスの対応状況
リサーチ合同会社が提供するRekam、Rekam-AI、スマL(スワイプLP作成ツール)については、対応が完了しています。スマLではLPを公開しているサーバーのPHPを8.3.36へ更新し、攻撃に利用されうる機能を無効化したうえで、表示およびアクセス状況に問題がないことを確認済みです。お客様側でご対応いただく作業はありません。
まとめ
今回のPHPの脆弱性は、深刻度が最上位、攻撃に認証が不要、そして対象が世界のウェブサイトの約7割という条件がそろっています。各国政府が動いているのは、この3つが重なっているためです。
やるべきことは明確で、PHPのバージョンを確認し、修正版へ更新することに尽きます。自社サイトの構成が分からない、更新してよいか判断できない、更新したらサイトが壊れないか不安、といった場合は、放置せずに制作会社やサーバー会社へ確認してください。
サイトの構成確認や対応の進め方についてのご相談は、お問い合わせフォームよりお気軽にご連絡ください。




