PHPとは？2026年の重大脆弱性2件、F12での見分け方と危険度・対策をやさしく解説

PHPは何をする言語？ F12で見える？ WordPressや社内LANの危険度、認証回避との違い、確認・更新・被害調査まで初心者向けに解説。「今夜23時」の正体 2026年10月21日23時（日本時間）。

約16分PR

読書機能の使い方

聴く：本文を読み上げます。速読：語句を順に表示し、速さを調整できます。語学練習：別の言語版と対訳を読み比べます。保存：このブラウザーにブックマークし、プレイヤーの保存済み一覧から開けます。ブロック崩しで読む：記事の文字そのものを的にして、ブロック崩しで遊べます。

この記事をシェア

LINEで共有（新しいタブで開きます）Xで共有（新しいタブで開きます）

PHPとは？2026年の重大脆弱性2件、F12での見分け方と危険度・対策をやさしく解説 — AI生成イメージ

説明: PHPは何をする言語？ F12で見える？ WordPressや社内LANの危険度、認証回避との違い、確認・更新・被害調査まで初心者向けに解説。

「今夜23時」の正体

2026年10月21日23時（日本時間）。「PHPの重大な脆弱性2件のパッチが出る」と警告され、管理者が冷や汗をかいたあの時間は、攻撃開始のカウントダウンではなく、修理部品が届く時刻だった。そして部品は予定どおり公開された。ここからは「準備してください」ではなく、「実際に更新してください」の段階だ。

PHP公式は、ログインしていない外部の人間がサーバーで不正な処理を実行できる二つの欠陥を確認した。WordPress本体の更新ボタンを押すだけでは、サーバー側のPHPは必ずしも更新されない。一般の閲覧者は管理対象外のサーバーを直せないので、便乗した「緊急本人確認」メールを開かないこと。スマホをアルミホイルで包んでも修正版はインストールされない。

そもそもPHPって何？スーパーのレジで考える

PHPは、Webサイトの裏方で仕事をするプログラミング言語。お客さんが「購入」を押したとき、店の裏では「ログインは正しい？」「在庫はある？」「値段はいくら？」「注文を記録する？」といった仕事が必要だ。PHPはその仕事を受け持てる。ブログのWordPressもPHPを使う。会社のお知らせページ、問い合わせ窓口、会員サイト、通販などでも使われる。

例えば注文の流れは「スマホの購入ボタン → WebサーバーのPHP → データベースから在庫・価格を取得 → 注文を保存 → 結果を画面に返す」。実際の決済は専用サービスなどが担当する場合もある。PHPがすべてのサイトに必要なわけではないが、あると便利な裏方だ。「重要な仕事を任せたのに、お客さんには姿が見えない」タイプの有能な店員である。

F12キーでPHPが見える？ HTML・CSS・JavaScriptとの違い

パソコンのChromeなどでF12を押すと開発者ツールを開ける。HTMLは文章やボタンの構造、CSSは色や配置、JavaScriptは画面上の動きなどを担当する。一方、PHPはサーバーで実行された結果をブラウザに送る。だから普通はF12でPHPの中身そのものを読めない。厨房は見えず、料理だけ運ばれてくる仕組みだ。

F12 → Network（ネットワーク）→ ページを再読み込み → ページ本体をクリック → Headers（ヘッダー）を開く。もし応答に「X-Powered-By: PHP/...」があればPHP利用の手掛かり。ただし表示を消す設定もできるため、見つからなくてもPHP不使用の証明にはならない。URL末尾の「.php」も手掛かりにすぎない。F12だけで脆弱性の有無は判定できない。 サイトの持ち主ならサーバー管理画面から調べる。

名前	主な担当	PHPとの違い
HTML	ページの構造	画面に見える内容を組み立てる
CSS	見た目	色や余白を決める
JavaScript	画面の操作、サーバー処理も可能	ブラウザでも動ける
PHP	サーバーのWeb処理	ログイン、情報取得、記録など
Python / Java / Go	Web処理やほかの用途	PHPと仕事が重なる別の言語
SQL	データベースへの問い合わせ	PHPからSQLを使うこともある
P2P	端末同士がつながる通信方式	言語ではなく、今回の欠陥の名前でもない

HTML/CSSとPHPは競争相手というより担当が違う。SQLはPHPへの乗り換え先ではなく、PHPなどがデータベースに質問するときに使う言葉だ。

確定した数字と未発表の部分

2026年10月22日1時26分（日本時間）時点、PHP公式発表で確定していること： 2026年10月21日に、二つの重大な脆弱性を修正したPHP 8.2.35、8.3.36、8.4.27、8.5.12が正式公開された。どちらもCVSS v4.0で9.2/10。これは攻撃成功率92%という意味ではない。ソシャゲのガチャ確率ではなく、技術的な深刻度の点数だ。

現在使っている系列	更新すべきPHPの修正版
PHP 8.2	8.2.35
PHP 8.3	8.3.36
PHP 8.4	8.4.27
PHP 8.5	8.5.12

CVE-2026-109618はメモリ不足時の後片付けが壊れて不正な動作につながる欠陥。CVE-2026-109619は前の通信の処理で使った情報が消えず、次の通信から誤って使われる欠陥。どちらも条件がそろうと、ログインなしの遠隔コード実行（RCE）につながる。とりわけApacheのmod_phpでは、サイト独自のプログラムが動く前に成立する攻撃例が示されている。PHP-FPMなどの方式にもリスクがあり、「うちはWordPressにログイン制限を掛けているから平気」は通用しない。

PHP 8.1以前はPHPプロジェクト本体の通常サポート対象外。ただしOSや長期保守の提供会社が修正を古いバージョンへ移植する場合がある。表示される番号だけで判断せず、OS・レンタルサーバー会社の修正情報を照合する。PHP 7.4、8.0、8.1には例外的なソース向けバックポートも提示された。PHP 8.2は2026年12月31日でサポート終了予定なので、その先の移行も必要だ。

意外なのは一方の問題の芽は2024年の調査で既に見つかっていたこと。PHP Foundationは、具体的な攻撃経路の発見や修正方針の調整が難航し、解消が遅れたと説明している。2026年には複数の研究者・組織による検証で危険性が明確になった。これは「AIが世界中のWebを乗っ取った」という話ではなく、欠陥の調査・修復が長期化した経緯だ。

攻撃状況の読み方： 実証実験で攻撃成立を確認したことと、不特定多数のサイトが実際に侵害されたことは別。PHP Foundationは正式公開時点で流通していた実用可能な攻撃コードを確認しなかったと説明しているが、公開後の悪用がない保証にはならない。

ログインを破るの？それとも「ログイン画面の裏」から入るの？

認証回避はログイン認証をすり抜けること。遠隔コード実行（RCE）は外部の要求によってサーバーに不正な命令を実行させること。PHP公式は今回の2件が、条件によってログインしていない攻撃者のRCEにつながると明示した。管理画面を開かずに「厨房へ直接入る」危険、と考えると分かりやすい。

PHPがApacheのmod_phpとして動く場合、CVE-2026-109618ではアプリ本体の処理開始前に攻撃を成立させた実証例がある。PHP-FPMの場合も、アプリを経由した攻撃が検証されている。PHPの実行権限でアクセスできるファイル・設定・データベースや接続先に影響が広がり得る。ただしすべてのサイトで同じ被害が必ず発生するという意味ではない。

公開Webと社内LAN、何が重なると危険？優先順位表

同じPHPでも、攻撃が届くか、何を操作できるか、修正されたかで緊急度が変わる。

状況	対応優先度	なぜ危ない？	やること
インターネット公開＋未修正＋大量の個人情報	最優先	外部から接触でき、情報漏えい時の被害が大きい	修正版適用。すぐ無理なら公開制限・停止を検討、ログ保全
インターネット公開＋未修正＋社内DBにも接続	最優先	公開ページが社内情報への入口になる恐れ	更新に加え、DB権限とネットワーク接続を絞る
インターネット公開＋未修正＋重要情報なし	高	情報がなくても改ざんや他システムへの侵入口になり得る	速やかに更新。不要な公開機能を制限
社内LAN限定＋未修正＋重要情報あり	高	社内の感染端末やVPN経由などの入口が残る	更新、アクセス経路・権限・ログを確認
社内LAN限定＋未修正＋重要情報なし	中〜高	直接の被害は小さめでも横展開の踏み台になる恐れ	更新予定を確定、到達範囲を制限
修正済み・重要情報あり	侵害調査を継続	修正前に入り込まれた場合は別問題	更新を検証し、過去ログ・不正ファイルを確認
PHP不使用を確認	今回の直接対象外	PHP自体の欠陥では攻撃されない	別サーバーや管理画面のPHP利用を確認

これは運用上の目安。重大度9.2は「92％のサイトが被害に遭う確率」ではない。公開範囲に加えて、PHPの実行権限が強い・顧客DBを読める・別サーバーへ接続できる・未修正という条件が重なるほど厄介になる。社内LANは魔法のバリアではないし、公開ブログも「個人情報ないから放置」で済まない。

自分のサイトは対象？見分ける順番

①PHPを使う場所 → ②PHPのバージョン → ③今回の対象バージョンとの照合 → ④修正が実際に適用されたかの順に調べる。見かけのURLだけで「安全」と決めない。

WordPress管理者： 管理画面の「ツール → サイトヘルス → 情報 → サーバー」でPHPのバージョンを確認する。WordPressそのものの更新とPHP本体の更新は別作業だ。管理を業者に任せている場合は「PHPのバージョン、修正担当、適用予定、確認方法」を質問する。

レンタルサーバー利用者： サーバー会社の管理画面と公式障害・セキュリティ案内を見る。自動適用か手動変更かを確認する。

自社サーバー管理者： コマンド「php -v」でコマンドライン用PHPを調べられる。ただしWebページを動かすPHPと別バージョンのことがあるため、WebサーバーやPHP-FPM、コンテナ、OSの配布元も確認する。アプリ・プラグイン・別サーバーが使うPHPも忘れない。

F12で知らない他人のサイトを検査しても、安全判定にはならない。自分が管理する範囲だけで確認と更新を行い、他サイトへの攻撃的なテストはしない。

WordPressは何を更新する？

公開済みの修正版：8.2.35 / 8.3.36 / 8.4.27 / 8.5.12。 WordPress更新とは別に、Webを処理するPHPを更新する。

WordPress本体やプラグインの更新と、サーバーのPHP更新は別だ。管理画面の「ツール → サイトヘルス → 情報 → サーバー」でPHPバージョンを確認できる。レンタルサーバーでは提供元の公式案内と変更手順を確認。自分でサーバーを管理するなら、PHPの使用場所、担当者、バックアップ、復旧方法を事前に整理する。

公開されたPHP修正版と運用中のWebサーバー環境を照合して適用し、ログイン・投稿・問い合わせフォームなどを検証しよう。思い付きで本番の設定を総入れ替えするのは「セキュリティ対策」ではなく、サイトを賭けた高額ガチャだ。

修正すれば終わり？攻撃される前と後では対策が違う

公開済みの修正版：8.2.35 / 8.3.36 / 8.4.27 / 8.5.12。 WordPress更新とは別に、Webを処理するPHPを更新する。

修正前： 使っているPHPと責任者を洗い出し、データ・設定・ファイルの復元可能なバックアップを用意する。修正版が公開されたので、PHP開発元とOS・ホスティング会社の案内を照合し、該当するパッケージやコンテナを更新。再起動が必要なサービスも確認する。WordPressの管理画面だけ更新して満足すると、肝心の裏方が古いままという「表札だけ新品」の事故が起こる。

更新後： 実際にWeb側のPHPが修正版になったか確認。ログイン、記事投稿、検索、問い合わせ、購入、連携APIなど重要な機能を試す。更新で壊れた機能と、攻撃による障害を区別する。

更新まで時間がかかる場合： 管理対象の公開機能やアクセス元を制限し、WAF（不審な通信をふるいにかける仕組み）などを補助的に使う。攻撃を防げると保証はできない。漏えい時の損害が大きく、暫定防御も不十分なら、一時停止・隔離を検討する。セッション設定の変更やアップロード遮断だけで今回の2件を完全に防げるとは断定しない。

すでに侵入された疑いがある場合： 先に証拠となるログ等を保全し、専門家と侵害範囲を調べる。不要なアカウント、不正ファイル、外部通信を調査。パッチ適用は「壊れた鍵を直す」行為で、すでに盗まれた名簿を取り返す魔法ではない。必要なら認証情報の無効化や関係者への通知も検討する。

AIで大量のサイトを調べる攻撃は現実的な懸念だが、脆弱性公表＝全サイトの流出確定ではない。公開、未修正、攻撃成立条件、アクセス権限、重要情報が重なるほど対応を急ぐべきだ。

PHPを使わないサイトは？

PHPを実行しない静的サイトや、JavaScript・TypeScriptだけで動くサービスなら、PHP自体の欠陥に直接は該当しない。ただし別サーバー、外部サービス、管理画面や機器内部がPHPを使う場合は確認が必要。Cloudflareを通しているだけで、背後のPHPに自動で修正パッチが入るわけではない。

チェックは「どこでPHPを使うか」「誰が更新するか」「更新後どう確かめるか」の三つ。