InfraAcademy Blog

PHPの緊急脆弱性「php2shell」とは？仕組みとインフラエンジニアが今すぐ確認・対応すべきこと

公開日: 2026-10-22 更新日: 2026-10-22 著者: ryu | #Linux #apache #php

Linuxをブラウザで試してみる

Linux・ネットワーク・AWSを、環境構築なしで実践学習できます

こんにちは、インフラエンジニアのryuです。

2026年10月21日、PHPに関する重大なセキュリティアップデートが公開されました。

今回見つかったのは、「php2shell」と呼ばれる2件の脆弱性です。条件がそろうと、攻撃者がログインせずにWebサーバー上で不正なコードを実行できる可能性があります。

PHPはWordPressをはじめ、企業のWebサイトや業務システムなど、さまざまな場所で使われています。そのため、PHPを利用しているシステムを管理するインフラエンジニアにとって、見過ごせないニュースです。

「PHPを使っているサーバーはすべて危険なのか？」「自社のサーバーが該当するか、どうやって調べればいいのか？」「アップデートすれば、それだけで大丈夫なのか？」

今回は、そんな疑問を整理していきます。

この記事では、脆弱性が発生する仕組みを確認したあと、Linuxサーバーでの調査方法、アップデートの進め方、不正アクセスの痕跡を調べるポイントまで解説します。

今回のPHP脆弱性で何が起きたのか？¶

2026年10月21日、PHPの開発チームは2件の重大な脆弱性に対応する修正版を公開しました。

対象となる脆弱性は、次の2つです。

CVE番号	内容	深刻度
CVE-2026-109618	メモリ不足時の不適切な処理によるメモリ破壊	9.2
CVE-2026-109619	古い内部状態の参照によるUse-After-Free	9.2

深刻度は、いずれもCVSS v4.0で9.2です。

CVSSは、脆弱性の重大さを数値で表す仕組みです。0〜10の範囲で評価され、9.0以上は「Critical（緊急）」に分類されます。

今回の脆弱性が深刻なのは、攻撃者が認証を突破しなくても、サーバー上で任意のコードを実行できる可能性があることです。

これをRCE（Remote Code Execution：リモートコード実行）と呼びます。

RCEが成立すると、Webサーバーの実行ユーザーが持つ権限の範囲で、ファイルの読み取りや変更、不正なプログラムの実行などが可能になるおそれがあります。

データベースの接続情報やクラウドの認証情報にアクセスできる環境なら、被害がサーバー内部だけで終わらない可能性もあります。

そのため、PHP公式は対象システムの速やかなアップデートを呼びかけています。

参考：PHP公式セキュリティ情報

2件の脆弱性はどのような仕組みなのか？¶

ここからは、少し技術的な話をします。

今回の2件に共通しているのは、PHP内部のメモリ管理に問題があることです。

CVE-2026-109618：メモリ不足がきっかけで不正な状態になる¶

PHPでは、プログラムを実行するときにメモリを使用します。

例えば、ファイルをアップロードしたり、大量のデータを処理したりする場合です。

通常、メモリの上限を超えると処理を中断します。しかし、今回の脆弱性では、その中断処理に問題がありました。

PHP内部のデータが完全に初期化される前にメモリ確保に失敗すると、不正な状態が残ることがあります。その後の終了処理が、そのデータを正常なものとして扱ってしまうのです。

攻撃者は、細工したHTTPリクエストによって、この状況を引き起こす可能性があります。

特に問題になるのが、Apacheのmod_phpを利用している構成です。

mod_phpは、Apacheのプロセス内でPHPを動かす仕組みです。この構成では、PHPアプリケーションのコードが実行される前に、脆弱性を悪用できることが実証されています。

つまり、アプリケーション側で入力チェックや認証処理を正しく実装していても、それだけでは防げない可能性があります。

参考：CVE-2026-109618 技術情報

CVE-2026-109619：解放したメモリを再び参照してしまう¶

もう一つは、Use-After-Free（UAF）と呼ばれる問題です。

通常、プログラムは不要になったメモリを解放します。ところが、メモリを解放したあとも、その場所を指す情報が残ってしまうことがあります。

その情報を使って再びメモリにアクセスすると、予期しない動作が起きます。

今回のPHPでは、あるHTTPリクエストの処理中に使われた内部状態が、正しくリセットされない場合があります。

その後、同じワーカープロセスが別のリクエストを処理するときに、古い情報を参照してしまう可能性があります。

これが悪用されると、メモリ内の情報が漏れたり、任意のコードを実行されたりするおそれがあります。

PHP公式の技術情報では、mod_phpに加え、一部の攻撃経路についてPHP-FPMでも悪用が検証されています。

PHP-FPMは、NginxやApacheなどと組み合わせてPHPを実行するための仕組みです。

「Apacheのmod_phpを使っていないから安全」と判断するのは誤りです。

参考：CVE-2026-109619 技術情報

どのようなシステムが影響を受けるのか？¶

今回の脆弱性は、WordPressなど特定のアプリケーションだけで発生する問題ではありません。

PHP自体に存在する脆弱性のため、PHPを利用してWebリクエストを処理するシステムが確認対象になります。

PHP公式が挙げている主な構成は、次のとおりです。

構成	確認するポイント
Apache + mod_php	特にリスクが高い構成
Nginx + PHP-FPM	影響を受ける可能性がある
Apache + PHP-FPM	影響を受ける可能性がある
php-cgi	影響を受ける可能性がある
FrankenPHP・LiteSpeed	影響を受ける可能性がある

ApacheでPHPを動かす構成そのものを確認したい方は、Apacheでphpを動作させる環境の構築方法も参考にしてください。

WordPress、Laravel、Drupalなどを利用している場合も、PHPの実行環境を確認する必要があります。

また、Webサーバーに直接PHPをインストールしていなくても、Dockerコンテナや外部製品の内部でPHPが動いていることがあります。

ここで大切なのは、アプリケーション名ではなく、実際に何が動いているかを確認することです。

PythonやNode.jsなどで構築され、PHPを一切使用していないシステムであれば、今回のPHP本体の脆弱性による直接的な影響はありません。

ただし、別の管理ツールや関連サービスでPHPを使用していないかは確認しておきましょう。

修正済みの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 8.1以前は、PHP開発元による通常のサポートが終了しています。

ただし、Linuxディストリビューションや長期サポートを提供する事業者が、独自に修正を適用している場合があります。PHP公式もPHP 7.4、8.0、8.1向けに、ソースコードへ適用する最小限の修正を提供しています。

そのため、古いバージョン番号という理由だけで、ディストリビューション提供の修正まで未適用と断定することはできません。

重要なのは、利用しているPHPに今回の修正が適用されているかという点です。

なお、PHP 8.2は2026年12月31日に公式サポートが終了する予定です。現在8.2を利用している場合は、今回の対応とあわせて今後の更新計画も考えておきましょう。移行の進め方はPHP 8.2のセキュリティサポート終了と8.4への移行準備で解説しています。

インフラエンジニアが最初にやること：影響範囲の調査¶

ここからは、実際のサーバー運用を想定して確認していきます。

最初に行うのは、自分が管理している環境でPHPが使われているかを調べることです。

1. PHPのバージョンを確認する¶

LinuxサーバーにSSH接続したら、次のコマンドを実行します。

php -v

PHPがインストールされ、CLIから実行できる場合は、バージョン情報が表示されます。

ただし、このコマンドで分かるのは、基本的にコマンドライン用PHPの情報です。

Webサーバーで使われているPHP-FPMなどが別のバージョンで動いている場合もあります。

例えば、UbuntuでPHP 8.3のPHP-FPMを使用しているなら、次のコマンドも確認します。

php-fpm8.3 -v

バージョンが異なる環境やコマンドが存在しない環境もあるため、実際の構成に合わせて確認してください。

2. 動いているプロセスを確認する¶

次は、PHPやWebサーバーのプロセスを確認します。

ps aux | grep -E '[p]hp-fpm|[a]pache2|[h]ttpd'

PHP-FPMやApacheのプロセスが動いている場合は、一覧に表示されます。

Apacheを利用している場合は、モジュールも確認できます。

apachectl -M | grep php

php_moduleが表示されるなら、ApacheにPHPモジュールが読み込まれています。

ただし、表示されないからといってPHPを使用していないとは限りません。PHP-FPMを別プロセスとして利用している構成もあるためです。

3. Dockerやクラウド環境も確認する¶

Dockerを使用している場合は、ホスト側ではなく、コンテナ内でPHPが動いている可能性があります。

docker ps

表示されたコンテナのイメージや構成を確認してください。

コンテナ内でバージョンを確認する場合は、次のように実行できます。

docker exec コンテナ名 php -v

CLIがないコンテナもあるため、その場合はイメージやパッケージ情報から確認します。

AWSなどのクラウド環境でも同様です。EC2、ECS、EKS、各種マネージドサービスなど、PHPがどこで実行されているかを整理する必要があります。

自社でPHPを管理していない場合は、サービス提供事業者の対応状況を確認しましょう。

脆弱性が見つかったら、どう対応する？¶

影響を受けるPHPが見つかった場合、基本となる対応はアップデートです。

PHP公式は、設定変更などの一時的な対策だけでは完全に防げないと説明しています。

1. 本番環境の前にアップデートを検証する¶

PHPの更新によって、既存アプリケーションの動作が変わることがあります。

そのため、可能であれば検証環境でアップデートを実施し、ログイン、データ登録、ファイルアップロード、外部API連携などの主要機能を確認します。

ただし、今回のように重大な脆弱性では、検証を理由に対応を長期間先延ばしにしないことも大切です。

インターネットに公開されているシステムから優先して対応しましょう。

2. PHPをアップデートする¶

UbuntuやDebian系では、APTを使って更新できます。

sudo apt update
apt list --upgradable

まず更新可能なパッケージを確認し、対象PHPパッケージをアップデートします。

RHEL系の場合は、DNFなどを使用します。

実際の更新コマンドやパッケージ名は、OSのバージョン、追加リポジトリ、利用中のPHPの系統によって異なります。

ディストリビューションの修正では、バージョン番号がPHP公式の修正版と一致しないこともあります。パッケージの変更履歴やベンダーのセキュリティ情報で修正の適用状況を確認してください。

Dockerの場合は、修正済みのベースイメージを使って再ビルドし、新しいコンテナへ切り替えます。

古いコンテナを再起動するだけでは、PHP本体は更新されません。

3. ワーカープロセスを入れ替えて確認する¶

更新したパッケージがディスク上に存在していても、古いPHPのプロセスが動いたままでは十分ではありません。

PHP-FPMやApacheを適切な手順で再起動・再デプロイし、実際のWebリクエストを処理するプロセスが修正済みのものへ切り替わったことを確認します。

更新後は主要画面やAPIを動作確認し、エラーログも確認してください。

ロードバランサー配下に複数台のサーバーがある場合は、一部のサーバーだけが古いPHPのままになっていないかも重要です。

すぐにアップデートできない場合は？¶

業務システムでは、互換性の問題などですぐにアップデートできないこともあります。

その場合は、一時的に攻撃を受ける可能性を下げる対策を検討します。

例えば、PHP公式は攻撃経路に応じて、次のような対策を案内しています。

不要なsession.upload_progress機能を無効化する
HTTPリクエストのサイズやアップロード数などを制限する
不適切なPHP設定や、処理中の致命的なエラーを見直す
アクセス制御によって外部からの接続を制限する
必要に応じてWebサービスを一時的に停止する

ただし、これらはすべての攻撃を防ぐものではありません。

memory_limit=-1など、特定の攻撃経路に対する暫定設定も公式から案内されていますが、メモリ使用量の管理に影響するため、十分な検証が必要です。

また、WAF（Web Application Firewall）は不審なHTTPリクエストを遮断するための対策ですが、PHP内部の脆弱性そのものを修正するわけではありません。

一時的な緩和策を導入しただけで、対応完了と判断しないようにしましょう。

アップデートだけでなく、不正アクセスの痕跡も調べよう¶

今回の対応で忘れてはいけないのが、ログの確認です。

例えば、PHPがメモリ不足になった場合、次のようなエラーが記録されることがあります。

Allowed memory size exhausted

また、PHP-FPMのワーカープロセスが異常終了していたり、Apacheのプロセスが繰り返し停止していたりする場合も調査対象になります。

Ubuntuなどでは、構成に応じてWebサーバーのエラーログを確認します。

sudo tail -n 100 /var/log/nginx/error.log

Apacheなら、例えば次のパスです。

sudo tail -n 100 /var/log/apache2/error.log

実際のログの保存先は環境によって異なります。PHP-FPMのログや、コンテナ・クラウドのログ収集先も確認してください。日頃のログの見方はLinuxのログ監視でも紹介しています。

特に注目したいのは、普段とは異なる大量のPOSTリクエスト、連続したメモリエラー、同じ時間帯に集中するプロセス異常などです。

ただし、これらのログがあるだけで攻撃を受けたとは断定できません。反対に、エラーログがないことも安全の証明にはなりません。

不審なファイルの追加、想定外のプロセス起動、アカウントや定期実行設定の変更なども、あわせて確認します。

もし侵害が疑われる場合は、証拠となるログやシステムの状態を保存し、セキュリティ担当者と連携して隔離や調査を進めましょう。

なお、PHPをアップデートしても、すでに侵入された場合の被害や不正なファイルが自動的になくなるわけではありません。

今回の脆弱性からインフラエンジニアが学ぶべきこと¶

今回の問題は、PHPの更新方法だけを知っていれば解決するものではありません。

実際の現場では、脆弱性のニュースが出たときに、次のような判断が必要になります。

確認事項	インフラエンジニアが行うこと
影響範囲	PHPを使用するサーバー・コンテナ・関連製品を洗い出す
優先順位	インターネットに公開されたシステムを優先する
更新対応	修正版の適用と、稼働プロセスの入れ替えを行う
動作確認	アプリケーションやAPIが正常に動くか確認する
侵害調査	ログ・プロセス・ファイルの異常を確認する
情報共有	対象、対応状況、残っているリスクを関係者に伝える

そして、日頃からサーバーの実行ユーザーに必要以上の権限を与えないことも大切です。

例えば、PHPの実行ユーザーがデータベースの管理者権限を持っていると、万が一RCEが成立した場合、被害が大きくなる可能性があります。

クラウドのIAM権限、ファイルのパーミッション、ネットワークの通信制限なども含め、最小権限で運用することが重要です。

脆弱性を完全になくすことは難しくても、侵害された場合の被害を小さくする設計はできます。

InfraAcademyでLinuxとサーバー構築を実践してみよう¶

今回紹介したpsやtailなどのコマンド、Webサーバーの構成、パッケージ管理、ログの確認は、インフラエンジニアにとって基本となる知識です。

ただし、コマンドを暗記しているだけでは、実際の障害や脆弱性に対応するのは難しいと思います。

例えば、ApacheとPHP-FPMの違いや、プロセスがどの権限で実行されるかを理解していれば、今回のようなニュースでも何を調べるべきか考えやすくなります。

InfraAcademyでは、LinuxやWebサーバー、ネットワーク、セキュリティなどを実践形式で学習できます。

ブラウザ上でコマンドを実行できる学習環境もあるため、自分のパソコンにLinuxを構築しなくても基礎から練習できます。

特にLinux中級講座のパッケージ管理・システムログや、サーバー構築講座のApacheによるWebサーバー構築は、今回の内容と関係の深い分野です。学ぶ順番はLinuxの学習ロードマップにまとめています。

また、今回のような脆弱性のニュースを「なぜ危ないのか」から理解したい方には、セキュリティ入門講座もおすすめです。

この講座では、リスクの考え方や認証・アクセス制御といった基礎から、Webアプリケーションの脆弱性、システムへの侵入や権限昇格の手口、そして防御・検知・インシデント対応までを順番に学べます。ブラウザ上の演習環境で、攻撃の流れと対策を実際に手を動かして確認できるため、今回の記事で紹介した「影響範囲の調査」や「痕跡の確認」が、どんな攻撃を想定した作業なのかもイメージしやすくなるはずです。

詳しくはInfraAcademyの講座一覧をご覧ください。