2026年10月21日、PHPの重大な脆弱性2件（CVE-2026-109618、CVE-2026-109619）が公表され、修正版が公開されました。「PHPって何？」「うちのWordPressは大丈夫？」「Microsoft 365やExchange管理センターにも影響があるの？」といった疑問を持った方も多いと思います。
この記事では、初心者の方にもわかるように、PHPの基礎から今回の脆弱性の内容、確認方法、そしてMicrosoft 365への影響について整理します。
- この記事の結論（先に知りたい方へ）
- そもそもPHPとは？
- 今回の脆弱性は何がそんなに危ないのか？
- Microsoft 365は影響を受けるのか？
- WordPressを最新版にすれば大丈夫？
- 修正版のバージョン
- 「脆弱性がある」＝「すでに侵入された」ではない
- サーバー管理者向け：自社環境の確認手順
- まとめ
この記事の結論（先に知りたい方へ）
- 今回の脆弱性は、条件がそろうとログインしていない外部の攻撃者がサーバー上でコードを実行できる可能性がある（RCE）重大なものです。
- 問題があるのはWordPressなどのアプリではなく、PHP本体です。WordPressを最新にしただけでは対策になりません。
- Microsoftは今回のPHP脆弱性への業界共同対応に参加しており、PHP環境の修正版への更新を優先的に進めています。
- 一方で、Microsoft 365やExchange管理センター（EAC）など個々のサービスがPHPを使っているかどうかは公開情報からは確認できません。したがって、影響の有無は公開情報だけでは判断できません。
- Microsoftが管理するクラウドサービス内部の部品については、利用者側でPHPを更新する作業はありません。
そもそもPHPとは？
PHPは、Webサイトの裏側（サーバー側）で動くプログラム言語です。ログイン処理、商品情報の表示、問い合わせフォームなど、「動きのあるWebサイト」の多くを支えています。
あなた（ブラウザ） ↓ Webサイト ↓ PHP（サーバー側で処理） ↓ データベース
特に有名なのがWordPressです。WordPressはPHPで動いているため、WordPressを使った企業サイトやブログも、今回の問題と無関係ではありません。
今回の脆弱性は何がそんなに危ないのか？
家にたとえてみましょう。
普通なら、「玄関 → 鍵を確認 → 家に入る」という流れです。ところが今回の脆弱性では、条件がそろうと「攻撃者が鍵を開けなくても、家の中に命令を送り込める可能性がある」というイメージになります。これが認証なしのリモートコード実行（RCE）です。
| 脆弱性 | ざっくり説明 |
|---|---|
| CVE-2026-109618 | メモリ不足が発生した際の内部データ処理に問題がある |
| CVE-2026-109619 | 解放したメモリに関係する内部状態が後続処理に残る問題 |
どちらもPHP本体のメモリ処理に関する問題です。「SQLインジェクション対策をしているから大丈夫」という話とは別で、アプリの下で動いているPHP自体に穴があるのがポイントです。
Microsoft 365は影響を受けるのか？
ここが今回いちばん気になる方が多いポイントだと思います。公開情報から言えることは次のとおりです。
- Microsoftは、PHPの利用者であり、PHP環境について修正版への更新を優先的に進めています。
- 一方で、Exchange管理センター（EAC）を含む、個々のMicrosoftサービスがPHPを利用しているかどうかは公開情報からは確認できません。
- そのため、Microsoft 365やEACが今回の脆弱性の影響を受けるかどうかを、公開情報だけで個別に判断することはできません。
- Microsoftが管理するクラウドサービス内部のコンポーネントについては、利用者側でPHPの更新作業を行うものではありません。
「影響なし」と断言できる情報も、「影響あり」と断定できる情報も、現時点では見当たらないという状況です。社内で報告する場合は、次のような表現が無難です。
Microsoftは今回のPHP脆弱性への対応は優先的に進めていますが、Exchange管理センターを含む各サービスでPHPが使用されているかは公開されていません。そのため、個別の影響有無については公開情報からは判断できない状況です。
なお、自社で運用しているWebサーバー上にPHPがある場合（社内ポータル、WordPress、Microsoft 365と連携する自社開発のWebアプリなど）は、Microsoft側の対応とは関係なく、自社側でPHPの更新が必要です。
ここは混同しないように注意してください。
WordPressを最新版にすれば大丈夫？
いいえ、WordPressの更新だけでは今回のPHP脆弱性への対応にはなりません。
WordPress ↓ PHP ← 今回問題になっているのはここ ↓ Linuxなどの OS
WordPress本体が最新でも、サーバー上のPHPが未修正ということはあり得ます。
修正版のバージョン
2026年10月21日に公開された修正版は次のとおりです。
| PHP系列 | 修正を含む公式リリース |
|---|---|
| PHP 8.5 | 8.5.12 |
| PHP 8.4 | 8.4.27 |
| PHP 8.3 | 8.3.36 |
| PHP 8.2 | 8.2.35 |
PHP公式は、完全な緩和策はなく、更新が唯一の安全な選択肢としています。また、PHP 8.1以前はPHPプロジェクトから今回の通常更新を受けられません。一部のLinux／LTSベンダーがバックポートを提供する場合があるため、ベンダーへの確認、またはサポート中のPHPへの移行が必要です。
「脆弱性がある」＝「すでに侵入された」ではない
ここは分けて考える必要があります。
PHPに脆弱性がある ↓ 攻撃可能な条件がそろっている ↓ 攻撃を受ける ↓ 攻撃が成功する ↓ 侵害・情報漏えいなどが発生する
脆弱性が存在することと、実際にサイトが侵害されたことは別問題です。たとえば企業のWebサイトがメンテナンス表示になっていても、それだけで「ハッキングされた」と断定することはできません。
サーバー管理者向け：自社環境の確認手順
PHP公式は、PHP-FPM、Apache mod_php、php-cgi、FrankenPHP、LiteSpeedなど、Webリクエストを処理するPHP環境全般をリスク対象として挙げています。特にApacheのmod_phpはリスクが高いとされています。
① PHPを使っているか ↓ ② WebサーバーがどのPHPを使っているか ↓ ③ PHPのバージョンを確認 ↓ ④ OSベンダーによるバックポート修正の有無を確認 ↓ ⑤ 修正済み → OK ／ 未修正 → 更新
1. PHPのバージョンを確認する
php -v
ただし、php -vが示すCLI版PHPと、Webサーバーが実際に使っているPHP（PHP-FPMやコンテナ内のPHP）は別物のことがあります。あくまで入口の確認と考えてください。
2. Webサーバーと実行方式を確認する
systemctl list-units --type=service | grep -Ei 'apache|httpd|nginx|php|litespeed' ps -ef | grep '[p]hp-fpm' apachectl -M
apachectl -Mでphp_moduleが見つかれば、mod_phpを使っている可能性があります。
3. 「番号が古い＝脆弱」と即断しない
Red Hat系などのLinuxディストリビューションは、バージョン番号を変えずに脆弱性の修正だけを取り込む（バックポート）ことがあります。PHP公式も、ディストリビューションやLTSベンダーは事前にパッチを受け取っているので、ベンダーの更新パッケージを確認するよう案内しています。
cat /etc/os-release rpm -qa | grep -i php # RHEL系 dpkg -l | grep -i php # Debian / Ubuntu系
確認したパッケージの正確なバージョンをもとに、OSベンダーのセキュリティアドバイザリで、CVE-2026-109618とCVE-2026-109619が修正済みかを確認します。
4. Docker／コンテナも忘れずに
ホストOSのPHPが修正版でも、Webアプリがコンテナ内の別のPHPで動いていることがあります。判断基準は「実際にWebリクエストを処理しているPHP」です。
5. 判定のポイント
「php -vが修正版だからOK」「表示バージョンが古いからNG」のどちらも避け、そのサーバーで稼働しているPHPパッケージに修正が入っているかを最終判定にします。
まとめ
- PHPは、WordPressをはじめ多くのWebサイトを支えるサーバー側のプログラム言語。
- 2026年10月21日に、認証なしでコード実行（RCE）につながり得る重大な脆弱性2件が公表され、PHP 8.5.12／8.4.27／8.3.36／8.2.35で修正された。
- WordPressの更新だけでは対策にならず、PHP本体の更新（またはOSベンダーの修正パッケージ適用）が必要。
- 確認はバージョン番号だけでなく、実際にWebリクエストを処理しているPHPとバックポートの有無まで見る。
- Microsoft 365やEACについては、PHPの利用有無が非公開のため、公開情報だけでは影響の有無を判断できない。Microsoft管理のクラウド側は利用者の更新作業の対象外。
自社でPHPを使ったサーバーを運用している方は、まず今日中に「どのサーバーでPHPが動いているか」の棚卸しから始めてみてください。
