2026年10月21日、世界中のWebサイトや業務システムで広く利用されているプログラミング言語「PHP」に、極めて深刻な2件の脆弱性が公表されました。
今回の脆弱性は 「PHP2Shell」 と呼ばれ、攻撃者がログイン認証を行わずに、Webサーバー上で不正なプログラムを実行できる可能性があります。
しかも、比較的新しいPHPだけでなく、10年以上前の古いPHPにも影響が及ぶことが確認されています。
📢 ただし、一般のインターネット利用者が慌てて何かをする必要は基本的にありません。
今回の問題は、主にWebサイトやサービスを提供する企業、サーバー管理者、システム開発者が対応すべきものです。
この記事では、一般の方にも分かるように説明しながら、企業のシステム担当者向けに技術的な対策まで詳しく解説します。
📌 1. 今回の脆弱性の概要
| 項目 | 内容 |
|---|---|
| 📅 公表日 | 2026年10月21日 |
| 🏷️ 通称 | PHP2Shell |
| 🔴 CVE番号① | CVE-2026-109618 |
| 🔴 CVE番号② | CVE-2026-109619 |
| 🚨 深刻度 | Critical（緊急） |
| 📊 CVSS v4.0 | 9.2 / 10.0（両方） |
| 🌐 攻撃経路 | ネットワーク経由 |
| 🔓 認証 | 不要で成立する攻撃経路あり |
| 💻 想定被害 | 任意コード実行、情報漏えい、サービス停止 |
| 🛠️ 根本対策 | 修正版PHPへの更新 |
今回の問題は、特定のWebサイトやWordPressプラグインに限定されたものではありません。
PHPというプログラムの実行エンジンそのものに問題があります。
そのため、PHPを利用する幅広いWebサービスが調査対象になります。
🤔 2. そもそもPHPって何？
PHPは、Webサイトの裏側で動くプログラミング言語です。
例えば、ネットショップで商品を検索したり、会員サイトにログインしたり、予約サイトで予約したりするときに、サーバー側でPHPが動いていることがあります。
身近な例としては、次のようなサービスがあります。
- 🛒 ネットショップ
- 📝 WordPressなどのブログ
- 🏢 企業のホームページ
- 🔐 会員制サイト
- 📅 予約システム
- 📧 Webメール
- 🖥️ 社内業務システム
- ☁️ ファイル共有サービス
利用者はPHPを意識する必要がありません。
普段の操作を裏側で支えている技術の一つです。
🏠 身近なものに例えると？
Webサイトをお店に例えてみましょう。
- 🏬 Webサイト：お店
- 👤 利用者：お客さん
- ⚙️ PHP：お店の裏側で働くスタッフ
- 🗄️ データベース：商品の在庫や顧客情報を管理する倉庫
今回の脆弱性は、お店の裏側で働くスタッフの仕事の仕組みに問題が見つかったようなものです。
悪意のある人物がその問題を悪用すると、本来は触れないはずの情報や機能にアクセスできる可能性があります。
👨👩👧 3. 一般ユーザーへの影響は？何か対策が必要？
結論：一般ユーザーが自分のスマートフォンやパソコンでPHPを更新する必要は、基本的にありません。
今回の問題は、サービスを提供するサーバー側の問題です。
例えば、ネットショップを利用している人がスマートフォンを更新しても、ネットショップ側のPHPは修正されません。
対応するのは、そのショップを運営する企業やシステム管理者です。
🙆 一般ユーザーが知っておきたいこと
- 📱 スマートフォンの設定変更は基本的に不要
- 💻 パソコンにPHPが入っていなければ直接の更新対象ではない
- 🔑 今回の脆弱性だけを理由に、すべてのパスワードを変更する必要はない
- 📩 利用サービスからセキュリティに関する案内が届いた場合は内容を確認する
- ⚠️ 脆弱性に便乗した偽メールや不審な更新案内には注意する
ただし、利用しているWebサービスが攻撃を受けた場合には、個人情報の流出やサービス停止などの間接的な影響を受ける可能性があります。
つまり、一般ユーザーは過度に心配せず、企業側が適切に対応することが重要という問題です。
なお、自宅でPHPを使ったWebサーバーやNASのWebアプリを運用している方は、管理者として確認が必要です。
🚨 4. 影響を受けるPHPのバージョン一覧
今回のPHP2Shellは、PHP 5.4からPHP 8.5.11までの広い範囲に影響することが報告されています。
🔴 PHP本体の影響バージョン
| PHPバージョン | 影響範囲 | 修正・対応 |
|---|---|---|
| PHP 8.5 | 8.5.0～8.5.11 | ✅ 8.5.12 |
| PHP 8.4 | 8.4.0～8.4.26 | ✅ 8.4.27 |
| PHP 8.3 | 8.3.0～8.3.35 | ✅ 8.3.36 |
| PHP 8.2 | 8.2.0～8.2.34 | ✅ 8.2.35 |
| PHP 8.1 | 8.1.x全般 | ⚠️ 公式サポート終了 |
| PHP 8.0 | 8.0.x全般 | ⚠️ 公式サポート終了 |
| PHP 7.4 | 7.4.x全般 | ⚠️ 公式サポート終了 |
| PHP 7.3 | 7.3.x全般 | ⚠️ 公式サポート終了 |
| PHP 7.2 | 7.2.x全般 | ⚠️ 公式サポート終了 |
| PHP 7.1 | 7.1.x全般 | ⚠️ 公式サポート終了 |
| PHP 7.0 | 7.0.x全般 | ⚠️ 公式サポート終了 |
| PHP 5.6 | 5.6.x全般 | ⚠️ 公式サポート終了 |
| PHP 5.5 | 5.5.x全般 | ⚠️ 公式サポート終了 |
| PHP 5.4 | 5.4.x全般 | ⚠️ 公式サポート終了 |
PHP 5.3以前は今回の確認済み影響範囲には含めていません。ただし、サポート終了による別のセキュリティリスクがあります。
⚠️ 古いPHPを使っている企業は特に注意
PHP 8.1以前は、PHP公式プロジェクトによる通常のセキュリティ更新が終了しています。
一部のOSメーカーや長期サポートベンダーは、古いPHPに独自の修正を提供する場合があります。
また、PHP公式は今回の問題に対して、PHP 7.4、8.0、8.1向けの最小限のソースコード修正も公開しています。
ただし、これらは通常の公式リリースとは異なります。
🔎 PHPの表示バージョンが古いからといって、必ず未修正とは限りません。
Linuxなどでは、OSメーカーがセキュリティ修正だけを古いバージョンへ適用する「バックポート」という仕組みがあります。
そのため、製品メーカーやOSベンダーの修正情報まで確認する必要があります。
📦 5. PHPを内蔵する製品・パッケージにも注意！
今回の脆弱性で見落としやすいのが、PHPを直接インストールしていなくても、別の製品の内部でPHPが利用されているケースです。
🌐 Webサーバー・実行環境
- Apache + mod_php
- Nginx + PHP-FPM
- Microsoft IIS + PHP FastCGI
- LiteSpeed / LSAPI
- FrankenPHP
- XAMPP
- WampServer
- MAMP
特にApache + mod_phpは、PHP公式が高いリスクを指摘している構成です。
🖥️ Webアプリケーション・管理ツール
- 📝 WordPress
- 📝 Drupal
- 📝 Joomla!
- 🛒 Magento / Adobe Commerce
- 🛒 EC-CUBE
- 🗄️ phpMyAdmin
- 🗄️ Adminer
- ☁️ Nextcloud
- ☁️ ownCloudのPHPベース構成
- 📧 Roundcube
- 📊 Zabbix Web UI
- 🛠️ GLPI
- 🌐 phpIPAM
- 🎓 Moodle
- 📚 MediaWiki
- 🎫 osTicket
WordPress、Drupal、JoomlaなどのPHPを利用するアプリケーションでも、研究者による攻撃の実証が報告されています。
ただし、これらのアプリケーション自体に今回の脆弱性が存在するという意味ではありません。
実際に使用しているPHPのバージョンと実行環境が重要です。
🐳 Docker・Linux・クラウド環境
- Docker公式PHPイメージ
- PHPを含むDockerコンテナ
- Kubernetes上のPHPアプリケーション
- BitnamiなどのPHP同梱イメージ
- Ubuntu / DebianのPHPパッケージ
- RHEL系LinuxのPHPパッケージ
- Google Cloud RunのPHPランタイム
- Google App EngineのPHPランタイム
コンテナの場合、ホストOSのPHPだけを更新しても、コンテナ内部のPHPが古いまま残ることがあります。
そのため、修正済みイメージを利用してコンテナを再構築・再デプロイする必要があります。
クラウドサービスでは、自動更新される構成と利用者による更新が必要な構成があります。
🏢 アプライアンス・組み込み機器
以下も、PHPを内蔵している場合には調査対象です。
- 💾 NAS・ファイルサーバー
- 🔐 ファイアウォール・VPN装置
- 🌐 ネットワーク管理機器
- 📊 監視アプライアンス
- 🗄️ バックアップ管理製品
- 🖥️ ストレージ管理製品
- ⚙️ Web管理画面を搭載する業務用機器
これらの機器がすべて脆弱であると確認されたわけではありません。
各メーカーのセキュリティ情報を確認し、内蔵PHPの有無と修正状況を調べる必要があります。
💥 6. 攻撃者はどのように脆弱性を悪用するのか？
今回の脆弱性は、一般的なパスワードの総当たり攻撃やSQLインジェクションとは異なります。
PHPの内部で行われるメモリ管理の問題を悪用します。
🔴 CVE-2026-109618：メモリ不足を利用した攻撃
PHPはプログラムを実行するとき、必要なデータをメモリ上に保存します。
しかし、メモリ不足が発生した際の一部の内部処理に問題がありました。
攻撃者は、特殊なHTTPリクエストを送信してメモリ処理の異常を誘発します。
その結果、PHPが不完全な状態のメモリ情報を正しいデータとして扱い、任意コード実行につながる可能性があります。
🔴 CVE-2026-109619：古いメモリ情報の再利用
PHPはWebサイトへのリクエストを処理する際、さまざまな内部情報をメモリに保存します。
通常、処理が終われば不要になったメモリ情報は解放されます。
しかし、今回の脆弱性では、解放済みのメモリへの参照が残り、後続のリクエストで利用される場合があります。
攻撃者はこの問題を利用して、メモリ破損や任意コード実行を引き起こす可能性があります。
🚨 攻撃が成功するとどうなる？
- 🔓 サーバー上で不正なプログラムを実行される
- 🗄️ データベースの情報を取得される
- 📝 Webサイトを改ざんされる
- 💾 サーバー内部のファイルを読み取られる
- ⛔ サービスを停止させられる
- 🌐 他の社内システムへの侵入に利用される
ただし、実際にどこまで被害が及ぶかは、PHPを実行するアカウントの権限やネットワーク構成などによって異なります。
🛡️ 7. 企業が実施すべき緩和策
今回の脆弱性に対する最も確実な対策は、修正版PHPへの更新です。
PHP公式も、暫定的な緩和策だけでは完全に防御できないと説明しています。
ただし、業務システムではすぐにPHPを更新できない場合もあるため、以下の対策を検討します。
🔧 対策① セッションアップロード進捗機能を無効化
PHPの設定ファイル（php.ini）で以下を設定します。
session.upload_progress.enabled = 0CVE-2026-109619の確認済み攻撃経路の一部を防ぐための設定です。
設定後は、PHPワーカーの再起動が必要です。
また、リクエストの解析前に設定が適用される必要があるため、PHP-FPMの管理者設定やサーバー設定などで適切に管理してください。
🔧 対策② PHPのメモリ設定を見直す
memory_limit = -1PHPのメモリ使用量制限を解除する設定です。
CVE-2026-109618において、PHP側のメモリ上限到達を利用する攻撃経路を減らす目的があります。
ただし、この設定には重大な注意点があります。
⚠️ メモリ使用量の制限がなくなるため、サーバー全体のメモリ枯渇やサービス停止につながる可能性があります。
そのため、OSやコンテナ側でリソースを管理することが重要です。
また、実際のメモリ確保失敗まで防げるわけではありません。
本番環境では十分な検証が必要です。
🔧 対策③ HTTPリクエストサイズを制限
PHP公式は、不要に大きなHTTPリクエストを受け付けない設定も案内しています。
ファイルアップロードが不要な環境の例：
post_max_size = 8Mファイルアップロードが必要な環境の例：
post_max_size = 32Mこれらは公式が示す設定例であり、すべてのシステムに適した値ではありません。
また、upload_max_filesize は post_max_size より小さく設定します。
Webサーバーやリバースプロキシ側でも、リクエストサイズ、multipartの項目数、ヘッダー数などを制限することが推奨されます。
🔧 対策④ PHP 8.5のエラー処理設定を変更
fatal_error_backtraces = 0PHP 8.5において、CVE-2026-109619の特定の攻撃経路を緩和する設定です。
設定後はPHPワーカーの再起動が必要です。
🔐 対策⑤ Webサーバーへのアクセスを制限
- 必要な端末からのみアクセスを許可する
- 不要なネットワークからの通信を遮断する
- 管理画面へのアクセス元を制限する
- 不要なファイルアップロード機能を停止する
- Webサーバーから重要DBへの接続を必要最小限にする
- PHP実行アカウントの権限を制限する
🧱 対策⑥ WAFによる防御
WAF（Web Application Firewall）は、不審なWeb通信を検知・遮断する仕組みです。
Cloudflareは今回のPHP2Shellに対して、2026年10月21日の公表前から防御ルールを展開したと発表しています。
ただし、WAFはすべての攻撃方法を遮断できるわけではありません。
WAFだけで安全になったと判断せず、PHP本体の修正も必要です。
📊 対策⑦ ログ監視を強化
以下のような異常を確認します。
- PHPのメモリ不足エラー
- Fatal errorの急増
- HTTP 500エラーの増加
- PHPワーカーの異常終了
- 不自然なファイルアップロード通信
- Webサーバーからの不審な外部通信
- Webサーバーが起動した見覚えのないプロセス
これらは攻撃以外でも発生するため、単独で侵害を断定することはできません。
Webアクセスログ、PHPログ、OSログ、EDRなどを組み合わせて確認することが重要です。
🏢 8. 社内LAN限定のシステムなら安全？
企業の中には、インターネットに公開せず、社内LANだけで利用する業務システムがあります。
このような環境では、インターネット公開サイトと比較して、外部から直接攻撃されるリスクは低くなります。
📊 公開範囲によるリスクの違い
| システム構成 | 攻撃リスクの目安 |
|---|---|
| 🌐 インターネット公開 | 🔴 高い |
| 🔐 VPN経由で利用可能 | 🟠 高め |
| 🏢 社内LAN限定 | 🟡 条件によって低減 |
| 🖥️ 特定端末のみアクセス可能 | 🟢 比較的限定的 |
| 🔒 完全隔離ネットワーク | 🟢 外部からの攻撃経路が限定的 |
※これは公開範囲による攻撃可能性の目安であり、脆弱性そのものの深刻度ではありません。
⚠️ 社内LAN限定でも攻撃される可能性はある
例えば、社員のパソコンがマルウェアに感染した場合、その端末を経由して社内システムに攻撃される可能性があります。
また、社内ネットワークに侵入された場合、攻撃者が内部のPHPサーバーを標的にすることも考えられます。
そのため、社内LAN限定という理由だけで対策不要とは判断できません。
ただし、アクセス元が厳しく制限され、重要情報も扱っていないシステムであれば、外部公開サーバーより更新の優先順位を下げる判断は考えられます。
📋 9. 企業のシステム管理者向けチェックリスト
今回の脆弱性について、企業では以下を確認することが重要です。
- 🔎 PHPを利用しているサーバーを洗い出したか
- 📦 PHP内蔵製品・パッケージを確認したか
- 🐳 Docker・コンテナ内部のPHPを確認したか
- 🖥️ Webサーバーが実際に利用するPHPのバージョンを確認したか
- 🌐 インターネット公開の有無を確認したか
- 🔐 社内LAN・VPN・アクセス元制限を確認したか
- 🗄️ 重要DBや他サーバーへの接続権限を確認したか
- 🛠️ メーカーの修正パッチ提供状況を確認したか
- 🛡️ 暫定的な緩和策を検討したか
- 📊 不審なアクセスやエラーログを確認したか
- 🔄 修正版への更新計画を作成したか
- ✅ 更新後の動作確認を実施したか
💻 PHPバージョンの確認方法
Linux：
php -vWindows：
php -vDocker：
docker ps --format "table {{.Names}}\t{{.Image}}"ただし、php -v で表示されるのはCLI版PHPです。
Webサーバーが実際に使用しているPHPのバージョンとは異なる場合があります。
PHP-FPM、Apacheモジュール、コンテナ内部なども個別に確認する必要があります。
🚨 10. 実際に攻撃は始まっているのか？
2026年10月21日時点で、セキュリティ研究者による攻撃の実証が報告されています。
また、Cloudflareは今回の脆弱性を狙った攻撃通信を観測したと発表しています。
つまり、単なる理論上の問題ではありません。
ただし、攻撃通信が観測されたことと、実際に企業のサーバーが侵害されたことは別です。
現時点で、すべてのPHPサイトが攻撃されているという意味ではありません。
企業側では、修正パッチの適用とあわせて、不審なアクセスやサーバー内部の異常がないか確認することが重要です。
📝 11. まとめ：一般ユーザーは慌てず、企業側は早急な確認を！
今回のPHP2Shellは、PHPの内部処理に存在する重大な脆弱性です。
認証なしで任意のコードを実行できる攻撃経路が確認されており、インターネット公開サイトを中心に早急な対応が求められます。
👨👩👧 一般ユーザーの方へ
今回の問題は、基本的にサービスを運営する企業やサーバー管理者が対応するものです。
自分のスマートフォンやパソコンで、特別な設定変更をする必要は通常ありません。
ただし、利用サービスからセキュリティに関する案内が届いた場合は確認してください。
🏢 企業・システム管理者の方へ
PHP本体だけでなく、PHPを内蔵するソフトウェアや管理ツール、コンテナ、アプライアンスなども調査対象になります。
特に古いPHPを利用している場合は、修正パッチが提供されない可能性があるため注意が必要です。
社内LAN限定のシステムでは、インターネット公開サイトより外部からの直接攻撃リスクを低く評価できる場合があります。
しかし、社内ネットワークからの攻撃経路は残るため、対策が不要になるわけではありません。
最も重要なのは、PHPの利用状況を正確に把握し、修正版への更新を進めることです。
暫定的な緩和策やアクセス制限を組み合わせながら、システムの重要度や公開範囲に応じて対応を進めましょう。
📚 12. 参考情報・公式URL
🔹 PHP公式：2026年10月21日 セキュリティ勧告
https://www.php.net/archive/2026.php#2026-10-21-5
🔹 CVE-2026-109618：公式アドバイザリ
https://github.com/php/php-src/security/advisories/GHSA-w8hw-w9fx-j79w
🔹 CVE-2026-109619：公式アドバイザリ
https://github.com/php/php-src/security/advisories/GHSA-6wmf-4rv5-p3rp
🔹 Google Cloud：PHP脆弱性への対応
https://cloud.google.com/blog/products/identity-security/responding-to-core-php-vulnerabilities-cve-2026-109618-cve-2026-109619
🔹 Cloudflare：PHP2Shellに対するWAF防御
https://blog.cloudflare.com/php-vulnerabilities-waf-protection/
🔹 英国NCSC：PHPの重大セキュリティ問題
https://www.ncsc.gov.uk/news/critical-security-issue-affecting-php
🔹 カナダサイバーセキュリティセンター：影響バージョンと対応
https://www.cyber.gc.ca/en/alerts-advisories/al26-026-critical-vulnerabilities-impacting-php-cve-2026-109618-cve-2026-109619
🔹 PHP公式ダウンロード
https://www.php.net/downloads.php
📅 記事作成日：2026年10月22日
※本記事は公開時点の公式情報およびセキュリティ機関の発表をもとに作成しています。影響範囲や修正状況は変更される可能性があるため、最新情報をご確認ください。
コメント