新着情報 News
PHPの重大な脆弱性「php2shell」とは？CVE-2026-109618／109619の影響とWordPressサイトで今すぐ確認すべき対策
2026年10月21日夜、日本時間23時ごろ、PHP開発チームは2件の重大な脆弱性を修正したセキュリティアップデートを公開しました。
対象はCVE-2026-109618とCVE-2026-109619。いずれもPHP本体のメモリ処理に関わる問題で、条件がそろうと、ログインしていない第三者がインターネット越しにサーバー上で不正なコードを実行できる可能性があります。PHP公式の評価は、CVSS v4.0で9.2の「Critical」です。
WordPressをはじめ、多くのWebサイトやWebシステムはPHPを利用しています。そのため今回の問題は、特定のWordPressプラグインだけの話ではなく、Webサイトを動かしている基盤そのものを確認する必要がある問題です。
結論｜「サイトが普通に表示されている」だけでは、安全確認にはなりません
まず確認すべきなのは、利用しているPHPが今回の脆弱性に対して修正済みか、またはサーバー・OSベンダーから同等の修正パッチが提供されているかです。
WAFなどの防御は重要ですが、PHP公式は「完全な緩和策はなく、更新が安全な選択」としています。修正適用後も、サイトの表示・フォーム・管理画面・ログ等を確認し、異常が疑われる場合はパッチ適用だけで終わらせず、侵害調査まで行う必要があります。
※本記事は2026年10月22日18時時点のPHP公式、IPA、ENISA、Google Cloud、Cloudflare等の公開情報を基にしています。脆弱性情報は更新される可能性があるため、運用時は必ずPHP公式・IPA・利用中のサーバー事業者やOSベンダーの最新情報も確認してください。
出典・参考資料（公式・一次情報）「Security advisory: Critical remote code execution vulnerabilities, update now｜PHP」「PHPの脆弱性に関する注意喚起｜IPA」「【事前準備のお願い】PHPのセキュリティリリース公開予定について｜IPA」
今回のPHP脆弱性「php2shell」で何が起きたのか
今回公表された2件は、PHPがWebリクエストを処理する際のメモリ管理に関する脆弱性です。セキュリティ業界では2件をまとめて「php2shell」と呼ぶ例があります。
PHP公式・Google Cloud等の公表情報では、PHP 5.4以降の広い範囲が影響対象です。
2件ともCritical。認証なしでのリモートコード実行につながる可能性があります。
PHP公式が2026年10月21日に公開した修正版です。
Cloudflareは、公開後に悪用を試みる通信が急増したと報告しています。
PHPがメモリ不足（OOM）の状態を処理する際、内部データが十分に初期化されないまま処理が中断され、後続のクリーンアップ処理が不正な状態のメモリを扱う可能性があります。条件がそろうと、リモートコード実行につながるおそれがあります。
1回のリクエストで使った内部状態が、関連するメモリの解放後も残ることがあり、同じPHPプロセスが後続リクエストを処理した際に古い状態を参照する可能性があります。これも条件次第でリモートコード実行や情報露出につながるおそれがあります。
重要なのは、これは「特定のWordPressテーマの欠陥」や「特定プラグインの脆弱性」ではなく、PHPランタイム本体の問題だという点です。そのため、WordPress本体やプラグインだけを更新しても、今回の2件への直接的な修正にはなりません。
PHP公式は、PHP-FPM、Apacheのmod_php、php-cgi、FrankenPHP、LiteSpeedなど、Webリクエストを処理するPHP環境を対象として挙げています。特にmod_phpについては、認証前・アプリケーションコード実行前に攻撃が成立する実証例があるとして、リスクが高い構成として説明しています。
出典・参考資料（公式・一次情報）「PHP Security Advisory」「Responding to core PHP vulnerabilities CVE-2026-109618 and CVE-2026-109619｜Google Cloud」
何が危険なのか？起こり得るリスクを整理
「リモートコード実行」と聞いても、具体的な影響が分かりにくいかもしれません。簡単に言えば、脆弱なサーバーに対して外部から細工した通信を送り、サーバー側で攻撃者の意図する処理を実行される可能性がある、ということです。
攻撃が成功し、実行権限の範囲でファイル操作が可能になれば、Webページや設定ファイル等を改変される可能性があります。
PHPプロセスがアクセスできる情報や、アプリケーションの設定・認証情報等が攻撃経路から利用された場合、情報流出へつながるおそれがあります。
侵害後に継続的なアクセス手段を残されると、PHPを更新しただけでは安全な状態へ戻らない場合があります。
異常終了やサーバー負荷、攻撃後の不正操作によって、Webサイトやサービスが停止する可能性があります。
ただし、脆弱性が存在することと、実際に侵害されたことは同じではありません。また、攻撃試行の件数と、侵害されたWebサイト数も同じではありません。この区別は非常に重要です。
攻撃はすでに始まっている。公表後は数百万件規模の悪用試行へ
今回の脆弱性が特に警戒された理由の一つは、修正版の公開前後から、実際に悪用を試みる通信が観測されていることです。
Cloudflareは、脆弱性の公表前から実際に攻撃トラフィックを観測していたと公表しています。さらにReutersが報じたCloudflareのMatthew Prince CEOの発言によると、同社ネットワークで観測した悪用試行は、公表前10時間の数千件から、公表後45分で数万件、2時間以内に数十万件、その後は数百万件規模へ増加しました。
「数百万件」は被害サイト数ではありません
この数字はCloudflareが観測した「脆弱性を悪用しようとした通信・試行」の規模です。数百万のWebサイトが侵害されたという意味ではありません。攻撃試行、攻撃成功、実際の情報漏えい・改ざんは分けて考える必要があります。
CloudflareはWAFルールを配布していますが、同社自身もWAFを「追加の防御」と位置づけ、PHP本体の更新を推奨しています。つまり、WAFがあるから更新しなくてよい、という問題ではありません。
出典・参考資料「Cloudflare deploys protections against php2shell vulnerability｜Cloudflare」「Millions of hacking attempts as companies, governments rush to patch PHP flaws｜Reuters」「Joint statement on critical PHP vulnerabilities｜ENISA」
2026年10月20日〜22日、何がどの順番で起きたのか
PHPチームがCriticalな2件の修正を翌日に公開すると事前告知
2件はいずれもCVSS v4.0 9.2。全PHP利用者に対し、修正版公開後すぐに更新できるよう準備が呼びかけられました。
IPAや海外の公的機関が事前準備を呼びかけ
IPAはPHPを利用していると分かっている製品・サービスについて、提供元の情報を確認し、影響や対策の公表後すぐ対応できるよう準備を促しました。
午後10時前
高市総理がXで「大至急のお願い」と対応を呼びかけ
修正パッチを速やかに適用できるよう準備すること、難しい場合はWebサイト等の一時停止もリスク低減策の一つになるとして対応を求めました。
22時40分頃（日本時間）
PHPセキュリティチームが修正情報を公開
ENISAによると13時40分（UTC）にセキュリティ更新が公開され、PHP 8.5.12、8.4.27、8.3.36、8.2.35が順次公開されました。CVE-2026-109618 / CVE-2026-109619の詳細も明らかになりました。
22日（木）
各社・各組織が緊急メンテナンスや予防的停止を実施
国内外でWebサイトやオンラインサービスを一時停止し、パッチ適用や安全確認を優先する動きが相次ぎました。停止は「侵害されたから」とは限らず、予防措置として実施されたケースもあります。
悪用試行が急増。更新と侵害確認の重要性がさらに高まる
Cloudflareでは大量の悪用試行が観測され、ニュージーランドNCSCも「active exploitation（実際の悪用）」に関する報告を認識していると公表しました。修正版の適用に加え、不正アクセスや侵害の痕跡を確認する重要性が高まっています。
高市総理もXで「大至急のお願い」と対応を呼びかけ
今回の問題では、2026年10月21日（水）午後10時前、高市早苗総理も自身のXで「皆様に、今夜に対応して頂きたい大至急のお願いです」と投稿しました。公開中のWebサイトでPHPを利用しているか確認し、同日午後11時ごろに公開予定だった修正パッチを可及的速やかに適用できるよう準備すること、すぐに適用することが難しい場合はWebサイト等の一時停止もリスク低減策の一つになると呼びかけています。
個別のソフトウェア脆弱性について首相が自身のSNSから直接対応を求めることは、ITmedia NEWSが「異例の要請」、TBS NEWS DIGも「総理も異例の呼びかけ」と報じています。政府の国家サイバー統括室も同様に、修正パッチの速やかな適用や、対応が難しい場合の一時停止を含む注意喚起を行いました。今回が単なる技術者向けの更新情報ではなく、企業や組織の経営判断にも関わる緊急性の高い問題だったことが分かります。
参考報道・政府発信「高市総理「大至急、PHPパッチ適用を」Xで異例の要請｜ITmedia NEWS」「PHPに重大欠陥 WEB停止相次ぐ 総理も異例の呼びかけ｜TBS NEWS DIG」「国家サイバー統括室」
影響を受けるPHPバージョンと修正版
PHP公式が今回の脆弱性を修正したバージョンは、次のとおりです。
古いPHPでも、サーバー会社が修正パッチを適用しているケースがあります
PHP公式が新しいバージョンとして修正版を公開したのは8.2〜8.5系ですが、PHP 8.1以前を利用しているサイトが、すべて未対策という意味ではありません。レンタルサーバー会社やOSベンダーが、古いPHPのバージョン番号を維持したまま脆弱性修正だけを取り込む「バックポート」や、独自の修正パッチを適用する場合があります。
2026年10月22日の公式Xで、PHP 7.4〜8.1について対象となるすべてのサーバーへの修正パッチ適用完了を公表。その後、PHP 5.6〜7.3についても適用完了を発表し、PHP 5.5以前についても修正パッチの準備・検証を進めていると案内しています。
公式の案内では、コントロールパネルで選択できる過去のPHPについても独自にバックポートを行い、サポート終了（EOL）を迎えたPHPを含めて対策したとしています。同時に、古いPHPを使い続けるのではなく、最新のサポート対象バージョンへの移行も呼びかけています。
パッチ適用済みでも、古いPHPを使い続けてよいという意味ではありません
今回の脆弱性に対するバックポートや独自パッチが適用されていても、EOLとなったPHPでは今後のすべての脆弱性について継続的な修正が保証されるわけではありません。緊急対策が済んだことと、長期的に安全な運用状態であることは分けて考え、サイト側の互換性を確認しながらサポート中のPHPへ移行することが重要です。
ここで注意したいのが、画面に表示されるPHPのバージョン番号だけでは、修正済みか判断できないケースがあることです。LinuxディストリビューションやLTSベンダー、レンタルサーバー事業者が、古いバージョン番号を維持したまま脆弱性修正だけをバックポートする場合があります。たとえばPHP 7.3.xと表示されたままでも、サーバー会社が今回の脆弱性修正をバックポート済みであれば、単純にバージョン番号だけを見て「未対策」とは判断できません。
逆に、「サーバー会社が対策しているはず」と推測するだけでも不十分です。利用しているサービスの公式告知やサポート情報で、今回のCVEに対する対応状況を確認してください。
今すぐ何をすべきか？Webサイト管理者向けの対応手順
緊急時ほど、いきなりPHPのメジャーバージョンを切り替えるのではなく、対象確認・修正適用・動作確認・侵害確認を分けて進めることが重要です。
管理対象サイトとPHP利用状況を洗い出す
本番、ステージング、旧サイト、サブドメイン、管理画面、API等を含め、外部公開されているPHP環境を確認します。サーバーやサービス内でPHPの利用有無が分からない場合は、提供元の告知を確認します。
サーバー・OS・ホスティング事業者の対応状況を確認する
公式PHPの修正版へ更新するのか、ベンダーが修正をバックポートするのかを確認します。独自ビルドやコンテナの場合は、利用者側で再ビルド・再デプロイが必要なケースがあります。
修正版または提供元の修正パッチを適用する
PHP公式は完全な代替緩和策はないとしているため、根本対応は更新です。WAF等は防御層として活用しつつ、修正適用を優先します。
サイト・システムの互換性を確認する
PHPの更新によって古いWordPressテーマ、プラグイン、独自PHPコード等が動かなくなる可能性があります。表示、フォーム、ログイン、検索、決済、メール送信、バッチ処理等を実機で確認します。
攻撃・侵害の痕跡を確認する
WebサーバーやWAFのログ、ファイル更新、未知の管理者アカウント、不審な外部通信、Webサーバープロセスからの異常な子プロセス等を確認します。異常が疑われる場合はパッチだけで終わらせません。
バックアップと復旧経路を確認する
バックアップが存在するだけでなく、必要な世代が残っているか、侵害前の状態へ戻せるか、復元手順が分かるかを確認します。バックアップ先が本番環境と同時に侵害されない設計も重要です。
侵害が疑われる場合は「更新したから終わり」にしない
攻撃者がすでにWebシェルや不正アカウント、認証情報等を残している場合、PHPを修正版へ更新しても侵害状態が続く可能性があります。異常が確認された場合は、影響範囲の特定、隔離、ログ保全、認証情報の変更、復旧、再発防止まで含むインシデント対応が必要です。
WordPressサイトは何を確認すればよい？
WordPressはPHP上で動作するCMSです。そのため今回の問題では、WordPressのバージョンだけでなく、WordPressを実行しているPHP環境を確認する必要があります。
WordPressサイトで確認したい項目
- 利用中のPHPが今回の脆弱性に対して修正済みか
- ホスティング会社が独自パッチ・バックポートを適用しているか
- PHP更新後にWordPress本体・テーマ・プラグインが正常動作するか
- お問い合わせフォームやメール送信が正常か
- 管理画面へのログイン・更新・メディアアップロードが正常か
- 独自テーマや古いPHPコードでFatal Errorが出ていないか
- Webサーバー・WAF・WordPress側に不審なログやファイル変更がないか
- バックアップが取得でき、復旧手順が確認できているか
ここで実務上難しいのは、セキュリティ上はPHPを早く更新したい一方、古いサイトではPHPを上げるとサイト側が動かなくなることがあるという点です。
だからこそ、日頃からWordPress本体、テーマ、プラグイン、独自コードを更新可能な状態へ保ち、PHPのサポート終了に合わせて段階的に移行しておくことが重要です。重大な脆弱性が出てから、初めて数年分の互換性問題を一度に解消しようとすると、緊急時の選択肢が狭くなります。
「サーバー会社が対策した」場合でも確認は必要
レンタルサーバーやクラウドサービスでは、事業者側がPHPパッケージやWAF等へ緊急対策を実施する場合があります。これは大きな安心材料ですが、「サーバー側で対応済み＝自社サイト側は何も確認しなくてよい」とは限りません。
- 対策対象が自分の利用しているPHP系列・サーバー環境まで含まれているか
- パッチ適用後にサイトの表示やフォーム等へ影響が出ていないか
- 古い独自コードやプラグインが更新後の環境と互換するか
- 対策前の時間帯に不審なアクセスがなかったか
- サーバー側のWAF対応とPHP本体の修正を混同していないか
また、PHP 8.1以前のようなEOLバージョンでも、サーバー会社やOSベンダーが独自に脆弱性修正をバックポートすることがあります。今回も、エックスサーバーやさくらインターネットなどが古いPHP系列への修正対応を公表しています。そのため、単純に「バージョン番号が古いから未対策」とは断定できません。利用中のサーバー会社の公式サイト、障害・メンテナンス情報、公式SNSを確認し、自分の契約サーバーとPHP系列が対応対象に含まれているかで判断することが重要です。
今回の件が示した「Webサイトは作って終わりではない」という現実
Webサイトは、一度完成させれば何年も同じ状態で安全に使い続けられる「完成品」ではありません。
たとえば自動車は、購入した瞬間に役割が終わるわけではありません。オイル、タイヤ、ブレーキ、車検など、使い続けるための点検と整備が必要です。Webサイトも同じで、サーバー、OS、PHP、CMS、テーマ、プラグイン、外部サービス、SSL、メールなど、複数の部品が時間とともに更新されます。
普段は問題なく表示されていても、その裏側ではサポート終了や脆弱性の公表、外部サービスの仕様変更が進んでいることがあります。「昨日まで普通に動いていた」と「今日も安全に運用できる」は、同じ意味ではありません。
月額の保守費を払っていれば、今回のような対応も全部含まれる？
これは契約内容によります。月額数千円の保守契約であっても、制作会社によって対応範囲は大きく異なります。
つまり、「保守契約があるか・ないか」だけでなく、何を監視し、何が起きたとき、どこまで対応する契約なのかを確認することが重要です。
安い保守費が悪いという話ではありません。サイトの規模や重要度によっては、最低限の更新支援だけで十分なケースもあります。ただし、事業上重要なサイトや個人情報を扱うシステムであれば、価格だけでなく、障害・脆弱性・復旧まで含めたリスクで判断する必要があります。
建物の管理で、日常清掃と設備故障への緊急対応が別料金になることがあるのと同じです。「管理費を払っているから、どんな事故でもすべて含まれる」と思い込まず、対応範囲をあらかじめ確認しておくことが、いざというときの差になります。
ニューズコムの顧客サイトについて｜2026年10月22日時点
当社では、管理・保守に関わる顧客サイトを順次確認・対応しています
2026年10月22日現在、当社で確認している顧客サイトについては、利用サーバー事業者側の対策適用後も、現在はサイトが表示されないといった継続的な問題は確認していません。個別の状況を確認しながら、必要な対応を順次進めています。
今回のような問題では、「PHPを更新する」だけではなく、更新によるサイト側への影響、WordPressや独自プログラムとの互換性、表示・フォーム等の動作、ログやセキュリティ状態まで見て判断する必要があります。
今回、緊急のご相談から当日中に対応した事例もありました
2026年10月22日には、当社が通常の保守管理を担当していないWebサイトから、今回のPHP脆弱性についてご相談をいただいたケースもありました。
そのサイトでは、本番環境をいきなり変更するのではなく、まず検証環境を用意して既存データを移設し、PHP、WordPress、プラグインのバージョンアップを実施。表示や主要機能への影響を確認したうえで、本番環境へ反映しました。
結果として、ご相談を受けた当日中に検証から本番反映まで完了しています。もちろん、すべてのWebサイトで同じ時間内に対応できるとは限りません。サイトの規模、独自システム、利用中のテーマ・プラグイン、サーバー環境などによって必要な作業は変わります。
ただ、緊急時ほど重要なのは、単に「PHPを上げる」ことではなく、安全に試せる環境を用意し、互換性を確認し、問題がないことを確かめてから本番へ反映できる体制です。日頃からこうした対応経路を持っておくことが、障害やセキュリティリスクを抑えることにつながります。
ニューズコムはXserver ビジネスパートナーであり、社内に複数のエンジニアが在籍しています。Webサイト制作でも、見た目や公開時の完成度だけでなく、サーバー、CMS、PHP、バックアップ、セキュリティ、将来の更新まで含めて運用しやすい構成を意識しています。
もちろん、どの環境でもトラブルを完全にゼロにできるわけではありません。だからこそ、問題が起きたときに「誰が状況を確認し、どこまで判断し、どう復旧するか」を事前に決めておくことが重要です。
ニューズコムのWeb制作・運用保守では、サイト公開後のセキュリティ対策、サーバー管理、更新、改善までを支援しています。詳しくは「Web制作・運用保守」をご覧ください。
よくある質問
WordPressを使っていれば、必ず今回の脆弱性の影響を受けますか？
「WordPressだから必ず未対策」という意味ではありません。WordPressはPHP上で動作するため確認対象ですが、実際のリスクはPHPのバージョン、サーバー構成、ホスティング会社・OSベンダーによるパッチ状況等で変わります。利用中のサーバー事業者の公式情報を確認してください。
WordPressやプラグインを最新版にすれば今回の問題は直りますか？
今回の2件はPHP本体の脆弱性なので、WordPressやプラグインの更新だけでは直接の修正になりません。PHPランタイム側の修正版・ベンダーパッチが必要です。ただし、PHP更新後の互換性や、別の脆弱性への対応という意味ではWordPress・テーマ・プラグインの適切な更新も重要です。
Webサイトが普通に表示されていれば、安全と考えてよいですか？
いいえ。表示が正常でも、脆弱なPHPを利用している可能性や、表面上は分からない侵害が発生している可能性はあります。PHPの修正状況とログ等を別に確認する必要があります。
WAFを導入していれば、PHPを更新しなくても大丈夫ですか？
推奨されません。WAFは攻撃を遮断する追加防御として有効ですが、PHP本体の脆弱性を修正するものではありません。CloudflareもWAFを防御の追加層と位置づけ、PHPの更新を推奨しています。
古いPHPを使っています。すぐ最新PHPへ切り替えればよいですか？
緊急性は高いですが、古いWordPress、テーマ、プラグイン、独自システムでは、新しいPHPへ切り替えることでエラーになる場合があります。サーバー事業者のバックポート状況を確認しつつ、バックアップ、検証環境、互換性確認を行い、安全にサポート中のPHPへ移行する計画を立ててください。
サーバー会社から「対策済み」と案内があれば、それで終わりですか？
脆弱性への根本的なサーバー対策としては重要ですが、サイト側の動作確認や、対策前の不審アクセスの有無まで自動的に保証するものではありません。少なくとも主要画面、フォーム、管理機能、ログ等を確認することをおすすめします。
攻撃が数百万件ということは、数百万サイトが被害に遭ったのですか？
違います。公開されている数百万件という数字は、Cloudflareが観測した悪用試行の規模です。試行数と侵害されたサイト数は別です。現時点で、数百万サイトが侵害されたと示す信頼できる公表情報は確認していません。
まとめ｜緊急対応だけでなく、「次の脆弱性に備えられるサイト運用」へ
今回のCVE-2026-109618 / CVE-2026-109619は、PHP本体に存在する重大な脆弱性であり、公開直後から大規模な悪用試行が観測されています。
- PHP公式の修正版、またはベンダーが提供する修正パッチを適用する
- WAFだけで安心せず、PHP本体の修正状況を確認する
- 更新後にWordPressや独自システムの動作確認を行う
- 攻撃・侵害の痕跡をログやファイル変更等から確認する
- 異常が疑われる場合は、パッチ適用だけでなく侵害調査・復旧まで行う
- 今後のために、PHP・CMS・プラグインを更新できる状態を維持する
- 保守契約の「緊急時にどこまで対応されるか」を確認する
Webサイトの保守は、普段何も起きていないときほど価値が見えにくいものです。しかし重大な脆弱性が公表されたとき、数時間〜数日の初動の差がリスクの差になります。
サイト制作では、公開日の見栄えや機能だけでなく、数年後も安全に更新できるか、問題が起きたときに復旧できるかまで含めて設計することが大切です。
PHP脆弱性・WordPressサイトの対応でお困りなら、お気軽にご相談ください
「自社サイトが今回の対象か分からない」「PHPの更新が必要と言われたが、壊れないか不安」「サーバー会社の対策後に何を確認すればよいか分からない」など、少しでも判断に迷うことがあればお気軽にご相談ください。
状況がまだ整理できていなくても問題ありません。分かる範囲の情報からサーバー環境やサイト構成を確認し、必要な対応を一緒に整理します。
今回のような緊急対応はもちろん、今後のPHP・WordPress更新、バックアップ、セキュリティ、運用保守まで含めて、サイトを安全に維持していく方法をご案内します。
出典・参考資料（公式・一次情報）「PHP Security Advisory」「PHPの脆弱性に関する注意喚起｜IPA」「PHPのセキュリティリリース公開予定について｜IPA」「Joint statement on critical PHP vulnerabilities｜ENISA」「Responding to core PHP vulnerabilities｜Google Cloud」「Cloudflare deploys protections against php2shell vulnerability｜Cloudflare」「エックスサーバー【公式】｜X」「PHPのバージョンについて｜エックスサーバー」「カスタマーセンターからのお知らせ｜さくらインターネット」「まりな🌸さくらインターネット公式｜X」「高市総理「大至急、PHPパッチ適用を」Xで異例の要請｜ITmedia NEWS」「PHPに重大欠陥 WEB停止相次ぐ 総理も異例の呼びかけ｜TBS NEWS DIG」