PHPにリモートコード実行の弱点、修正版が公開
PHP 8.2から8.5の各系統に、メモリ不足の処理の不備から外部の第三者がサーバー上で任意のコードを実行できる可能性のある弱点が見つかり、修正版が公開されました。PHPでWebアプリケーションを動かしている組織が対象で、深刻度はCVSS v4で9.2(critical)です。まず自社のPHPの版を洗い出し、8.2.35、8.3.36、8.4.27、8.5.12以降へ更新してください。
急ぎ度: 早めに
認証なしでネットワーク越しに悪用でき、成功すればコード実行に至る深刻な弱点ですが、攻撃成立に条件が必要とされ、実際の攻撃での悪用は現時点で明らかになっていないためです。
関係があるか
PHP 8.2から8.5の修正前の版を、Webサーバー(PHP-FPM、Apacheモジュールなど)として外部や社内向けに動かしている環境が当てはまります。OS付属のパッケージやコンテナイメージの中のPHPも対象になりえます。
| 製品 | 影響を受ける版 | 修正版 |
|---|---|---|
| PHP 8.2系 | 8.2.0以上、8.2.35未満 | 8.2.35 |
| PHP 8.3系 | 8.3.0以上、8.3.36未満 | 8.3.36 |
| PHP 8.4系 | 8.4.0以上、8.4.27未満 | 8.4.27 |
| PHP 8.5系 | 8.5.0以上、8.5.12未満 | 8.5.12 |
確かめ方
- 1サーバーやコンテナで
php -vを実行し、版が上の表の「影響を受ける版」に入るか確認します。Webを処理するPHP-FPMやApacheモジュールの版が、コマンドラインのPHPと別のこともあるため、php-fpm -vなども併せて確認してください。 - 2Debian系のOSでは
apt list --installed 2>/dev/null | grep -i phpで導入済みのパッケージを確認します。ディストリビューションは修正を元の版番号のまま取り込むことがあるため、版の数字だけで判断せず、Debianの告知DSA-6574-1に書かれた対応版と照らし合わせてください。 - 3コンテナを使っている場合は、ベースイメージに含まれるPHPの版も確認します。イメージを作り直していなければ、古い版のまま動き続けます。
- 48.1以前など、上の表にない版が影響を受けるかどうかは公表されていません。該当する版を使っている場合は、PHPの公式告知やディストリビューションの案内で確かめてください。
何が起きたか
PHPで、メモリが足りなくなったときの後始末の処理に不備が見つかりました。PHPはメモリ不足に陥ると、いま実行中の処理を途中で打ち切り、そのリクエストの処理をやめる仕組みを持っています。ところが、打ち切られる場面によっては、リクエスト用のメモリが初期化されないまま残ってしまうことがあります。その状態で後始末が走ると、中身の定まらないメモリを読んだり、それをもとに処理を分岐させたりします。結果として、外部の第三者にサーバー上で任意のコードを実行される可能性があります。
技術的には、PHPがメモリ不足(OOM)の際に longjmp() で現在の処理から抜け出す設計になっていることが背景です。一部の処理がこの抜け方を想定しておらず、メモリ確保の前に初期化されない領域を残します。後続のリクエスト終了処理がその領域を読むのが問題で、複数のOOMの起こし方で安定して再現できると説明されています。弱点の分類はCWE-416(解放後のメモリ使用)、CWE-755(例外的な状況の不適切な扱い)、CWE-824(未初期化ポインタへのアクセス)、CWE-1325(連続したメモリ確保の不適切な制御)です。
識別番号はCVE-2026-109618で、別の識別番号CVE-2026-109619も関連付けられています。両者の違いは明らかになっていません。2026年10月21日にPHPプロジェクトの告知が出ており、DebianもDSA-6574-1として告知しています。
攻撃の流れ
-
1
大量メモリ要求
外部の第三者が、PHPにメモリ不足を起こさせるような要求をWebアプリケーションへ送ります。
-
2
処理の途中打切り
PHPはメモリ不足を検知し、実行中の処理を途中で抜けてリクエストの処理を中止します。
-
3
未初期化メモリ
処理が抜けた場面によっては、リクエスト用のメモリが初期化されないまま残ります。
-
4
後始末で誤動作
終了処理がその中身の定まらないメモリを読み、想定外の動きをします。
-
5
コード実行
条件がそろうと、攻撃者の意図したコードがサーバー上で動く可能性があります。
どう悪用されるか
CVSS v4のベクターでは、攻撃元の区分がネットワーク、必要な権限がなし、利用者の操作がなしです。ログインしていない外部の第三者が、PHPで動くアプリケーションに要求を送るだけで試みられる性質です。一方で、攻撃の複雑さは高、攻撃の前提条件ありとされています。どのアプリケーションでも簡単に成立するわけではなく、PHPの設定や環境、アプリケーションの作りによって成否が変わると考えられます。具体的な条件の詳細は公表されていません。
悪用された場合、機密性・完全性・可用性のいずれにも大きな影響が出る想定です(いずれも高)。具体的には、サーバー上の情報の閲覧や改ざん、サービス停止、そこを足がかりにした社内ネットワークへの侵入が懸念されます。実際の攻撃で悪用されたかどうかは、現時点で明らかになっていません。
今すぐやること
-
1
PHPを使っている機器を洗い出す
Webサーバー、バッチ用サーバー、コンテナイメージ、開発・検証環境まで含めて、PHPの版を一覧にします。インターネットに公開している系統を先に確認してください。
php -v -
2
Webを処理するPHPの版も確認する
PHP-FPMを使っている場合、コマンドラインのPHPとは別の版が動いていることがあります。実際にリクエストを処理している側の版を確かめます。
php-fpm -v -
3
修正版へ更新する
8.2系は8.2.35、8.3系は8.3.36、8.4系は8.4.27、8.5系は8.5.12以降に更新します。公開系のサーバーを優先し、検証環境で動作を確かめたうえで本番に反映してください。更新後はPHP-FPMやWebサーバーを再起動し、新しい版で動いていることを確認します。
-
4
OSのパッケージは配布元の更新を使う
DebianではDSA-6574-1が出ています。ディストリビューションのパッケージを使っている場合は、PHPを自前でビルドし直さず、配布元の更新を適用するのが基本です。導入済みのPHP関連パッケージは次のコマンドで確認できます。
apt list --installed 2>/dev/null | grep -i php -
5
コンテナイメージを作り直す
コンテナで運用している場合は、修正版を含むベースイメージに切り替えて再ビルドし、稼働中のコンテナを入れ替えます。
-
6
更新が済むまで異常を監視する
PHPのエラーログやWebサーバーのログで、メモリ不足のエラーやプロセスの異常終了が急に増えていないかを確認します。特定の接続元から不自然なリクエストが続いていないかも見ておきます。
すぐ更新できないとき
公式な回避策は公表されていません。更新できるまでの間は、公開が不要なPHPアプリケーションを閉じる、管理画面などへのアクセス元を制限する、といった一般的な露出の削減と監視を行ってください。これらは根本的な対策ではないため、修正版への更新を優先します。
背景
PHPは、WordPressをはじめ多くのCMSやWebアプリケーション、社内の業務システムの土台として使われています。Webサーバーの内側で外部からの入力を直接処理するため、PHP本体に弱点があると、個々のアプリケーションを丁寧に作っていても影響を受けます。インターネットに公開されたサーバーが多いことも、PHPの弱点が注目されやすい理由です。
PHPはC言語で書かれた処理系で、メモリの扱いに起因する弱点は、この種のソフトウェアで繰り返し問題になってきました。今回のように、初期化されていないメモリや解放済みのメモリの扱いを誤ると、プログラムの動きを乱され、最悪の場合は外部からコードを実行されます。通常の入力検査では防ぎにくく、処理系そのものを更新することが対策の中心になります。
よくある質問
Q.自社のWebサイトがPHPで動いていれば必ず危ないのですか。
Q.すでに攻撃は始まっていますか。
Q.OSの更新を適用すれば、PHPの版番号が上の表の数字と違っても大丈夫ですか。
Q.PHP 8.1以前を使っていますが影響はありますか。
まだ分かっていないこと
- 攻撃が成立するための具体的な前提条件(PHPの設定や、影響を受けやすいアプリケーションの特徴)は公表されていません。
- 実際の攻撃での悪用や、攻撃手法の公開状況は現時点で明らかになっていません。
- CVE-2026-109619とCVE-2026-109618の関係や違い、8.1以前の版への影響は公表されていません。
この記事は、取得元の公開情報をもとに、人が監修しながらAIを活用して執筆しています。執筆と監修は佐々木 航が担い、公開したあとも人が内容を確認しています。誤りに気づいたときは直し、記事の末尾に訂正の行を残します。対応を決める前に、下の原文と参照先も確認してください。
影響パッケージ
| パッケージ | 影響を受ける版 → 修正版 | |
|---|---|---|
| PHP GroupPHP |
8.2.0 以上 8.2.35 未満→ 8.2.35 8.3.0 以上 8.3.36 未満→ 8.3.36 8.4.0 以上 8.4.27 未満→ 8.4.27 8.5.0 以上 8.5.12 未満→ 8.5.12 |
8.2.35 8.3.36 8.4.27 8.5.12 |
| Bitnamiphp-min |
7.3.0 以上 8.2.35 未満→ 8.2.35 8.3.0 以上 8.3.36 未満→ 8.3.36 8.4.0 以上 8.4.27 未満→ 8.4.27 8.5.0 以上 8.5.12 未満→ 8.5.12 |
8.2.35 8.3.36 8.4.27 8.5.12 |
| Bitnamilibphp |
7.3.0 以上 8.2.35 未満→ 8.2.35 8.3.0 以上 8.3.36 未満→ 8.3.36 8.4.0 以上 8.4.27 未満→ 8.4.27 8.5.0 以上 8.5.12 未満→ 8.5.12 |
8.2.35 8.3.36 8.4.27 8.5.12 |
| Bitnamiphp |
7.3.0 以上 8.2.35 未満→ 8.2.35 8.3.0 以上 8.3.36 未満→ 8.3.36 8.4.0 以上 8.4.27 未満→ 8.4.27 8.5.0 以上 8.5.12 未満→ 8.5.12 |
8.2.35 8.3.36 8.4.27 8.5.12 |
ディストリビューション別の修正状況
各ディストリビューションが公開している、この CVE の記録です。修正版は配布版ごとに違うので、リンク先で確かめてください。
- Alpine Linux ALPINE-CVE-2026-109618 php85, php84, php83 ほか 1 件 修正版あり
- BellSoft Alpaquita BELL-CVE-2026-109618 php83, php81 修正版あり
- Debian DEBIAN-CVE-2026-109618 php8.4, php8.2 修正版あり
- Ubuntu UBUNTU-CVE-2026-109618 php8.5, php8.3, php8.1 ほか 4 件 修正版あり
原文の説明 取得元が公開している説明をそのまま載せています (多くは英語)。
PHP uses longjmp() for out-of-memory (OOM) errors to exit the current context and abort handling of the request. Some contexts may not properly account for this scenario and leave request memory in an uninitialized state before performing an allocation. The subsequent request cleanup procedure may read or branch on this memory. Multiple OOM strategies can consistently trigger this condition and lead to remote code execution (RCE).
出典: NIST National Vulnerability Database NVD GitHub Advisory CISA KEV
参照URL
- advisory github.com
- advisory wiz.io
- advisory nvd.nist.gov
- advisory arcticwolf.com
- advisory php2shell.delftintellab.com
- advisory github.com
- AWS aws.amazon.com
- CISCO sec.cloudapps.cisco.com
- CISCO sec.cloudapps.cisco.com
- DSA DSA-6574-1
- ICSA cisa.gov
- ICSA cisa.gov
- JVN JVNVU99905564
- JVN JVNDB-2026-039073
- POC EDB-52704
- REDHAT Red Hat
- web openwall.com
- web cert-portal.siemens.com
- web openwall.com
- web cisa.gov
- web seclists.org
- web cert-portal.siemens.com
- web cert-portal.siemens.com