はじめに
2026年10月、PHPにかなり深刻な脆弱性が見つかりました。巷では「PHP2Shell」と呼ばれている脆弱性です。公式発表の前日から騒がれ始めた状況等をふまえて嫌な予感しかしません。
私は普段、IBM i（旧AS/400）を中心としたシステム開発に携わっています。また、株式会社中部システムで、IBM i向けPHPソリューション「CS^2」の提供にも関わっています。
今回のPHP2Shellでは、パートナーである米国企業と会話をしながら、セキュリティアップデートへの対応を進めることになりました。
せっかくなので、今回の経験を何回かに分けて記事にしてみようと思います。
第1回は、そもそもPHP2Shellとは何なのか、IBM iでPHPを使っている場合にどんな影響があるのか、という話です。
PHP2Shellって何？
今回発見されたのは、以下の2つの脆弱性です。
| CVE番号 | 内容 |
|---|---|
| CVE-2026-109618 | メモリ不足（OOM）時のエラー処理に関する問題 |
| CVE-2026-109619 | リクエスト処理に関連する内部状態の問題 |
どちらもCVSS v4.0で9.2という、かなり高い深刻度が付けられています。
問題なのは、条件がそろうと、外部から認証なしで任意のコードを実行される可能性があることです。
所謂 RCE（Remote Code Execution：リモートコード実行） です。
しかも、今回の脆弱性はPHPで作成したアプリケーションの不具合ではありません。
PHPの実行エンジン自体の問題です。
つまり、どれだけ丁寧にPHPのプログラムを作っていても、使用しているPHPバージョン自体に問題があれば影響を受ける可能性があります。
ちなみに、2026年10月26日には米国CISAのKEVカタログにも登録されました。つまり、実際に悪用が確認された脆弱性ということです。プラットフォームによっては、単なる可能性の話ではなくなっています。
どのPHPバージョンが対象なのか？
2026年10月21日、PHP公式から修正版が公開されました。
| 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 7.4や7.3は関係ないの？」残念ながら、そういうわけではありません。今回の脆弱性は、さらに古いPHPにも影響があることが報告されています。（※公式でも PHP 7.4 までバックポートされました）
PHP 5.4以降は今回の2つの脆弱性の少なくとも一方の影響を受けるとされています。IBM iでは、今でもPHP 7.3や7.4で動いているシステムがあります。また、古いZend Server系を利用し続けている場合は、5.x 系のユーザーも存在しています。
これは私たちが普段お客様の環境に接していても感じることです。「PHPの最新版にすればいいじゃないか」と言うのは簡単ですが、実際の業務システムでは、そう簡単にいかないこともあります。
まず、IBM i 向けPHPビルドがそもそも一般的では無いことに加えて、PHPのバージョンアップによって、これまで安定稼働していたアプリケーションが動かなくなる可能性もあるからです。
特にメージャーバージョンアップの場合、長年運用している基幹システムでは、互換性の検証だけでも相当な作業になります。そんな事情もあり、IBM iでは旧バージョンのPHPをどう維持するかという問題があります。
ただ私自身は、今後安定稼働を目指す上でIBM iユーザは、別のフェーズに来たとも考えております。
従来の IBM i界隈の常識は...
安定稼働＝長い間アプリを触らない→リプレイスで見直し
だったのが
安定稼働＝毎年など適切なサイクルでアプリを触っていく
にならざるを得ない状況だと考えます。
話を戻します。なお、今回中部システムが提供する、CS^2においても、サポートが終了している PHP 7.3、7.4、8.0、8.1 に対しても、セキュリティ修正のバックポートを提供しています。
バックポートとは、新しいバージョンで修正された内容を、古いバージョンへ移植することです。
IBM iでも影響するのか？
IBM iだからといって今回の問題と無関係ではありません。
IBM iでPHPを利用する場合、例えば次のような構成がよくあります。
Webブラウザー
|
v
IBM HTTP Server for i
(Apache)
|
v
FastCGI
|
v
PHP
|（このプロセス権限での脆弱性 RCE ）
v
Db2 for i
IBM iでは、ApacheとFastCGIを組み合わせてPHPを動作させる構成が利用されています。
今回の脆弱性はPHP自体の問題なので、このような構成でも注意が必要です。
PHP公式からも、Apacheのmod_phpだけでなく、PHP-FPMやphp-cgiなどの実行方式が影響対象として案内されています。
ただし、すべての実行方式で攻撃の成立条件や危険度が同じというわけではありません。
実際のリスクは、PHPのバージョンや実行方式、Webサーバーの設定などによって変わります。
そのため、IBM iの場合も、自分たちの環境でどのPHPが、どのように動いているのかを確認することが大切です。
社内システムだから大丈夫？
IBM iでPHPを使用しているお客様の場合、インターネットへ直接公開していないシステムも少なくありません。
例えば、
- 社内LANからしかアクセスできない
- VPN経由でしかアクセスできない
- 特定のIPアドレスからしかアクセスできない
- 完全な閉域ネットワークで運用している
といった環境です。
こうした構成であれば、インターネットに直接公開しているシステムと比べて、外部から攻撃されるリスクは低くなります。ただし、「社内システムだから絶対安全」とは言えません。
例えば、VPNの認証情報が盗まれたり、社内のPCがマルウェアに感染したりすれば、攻撃者がWebサーバーへアクセスできる可能性があります。
さらに、今回の脆弱性はアプリケーションの認証処理に到達する前に悪用されるケースもあります。そのため、ログイン画面があるから大丈夫、という話でもありません。
ネットワークによるアクセス制限は有効な対策の一つですが、PHPそのものの脆弱性が解消されるわけではないので、やはりセキュリティ更新が基本になります。
まず何を確認すればいいの？
IBM iでPHPを利用している場合、まずは現状を把握するところからだと思います。
1. PHPのバージョンを確認する
PASE環境で、例えば次のコマンドを実行します。
# パスがとおっているなら
php -v
# フルパス
/QOpenSys/pkgs/bin/php -v
ただし、注意点があります。
IBM iでは複数バージョンのPHPを共存させている場合があります。
そのため、このコマンドで表示されたPHPが、実際にWebサーバーで使用されているとは限りません。Apacheの設定も含め、どのPHPを呼び出しているのか確認してください。
また、古いPHPにセキュリティ修正がバックポートされている場合、PHPのバージョン番号だけでは修正済みか判断できないこともあります。
2. PHPの提供元を確認する
IBM iでは、PHPの提供元によってセキュリティ更新の提供方法が異なります。
現在利用しているPHPについて、今回のPHP2Shellに対応した修正版が提供されているか確認しましょう。
3. Webサーバーの公開範囲を確認する
インターネットへ公開しているのか、社内のみなのか、VPN経由なのか。この違いによって、対応の緊急度も変わってきます。もちろん、外部公開している場合は優先的な対応が必要です。特に今回のケースでは、Webサーバーやサービスを停止させる企業も多数ありました。
4. 更新前にはバックアップを
PHPの更新作業では、事前のバックアップを忘れないようにしたいところです。IBM i のバックアップ機能はシンプル且つ優秀なので、そこは IBM iユーザーとしての恩恵にあずかることができます。また、更新後にアプリケーションが正常に動くかどうかも確認する必要があります。
セキュリティの問題を解決したものの、業務システムが正常稼働しないと、今度は別の混乱を生むことになります。特にIBM iでは、長年稼働しているアプリケーションも多いため、この点は慎重に考える必要があります。
今回の件で改めて感じたこと
IBM iは非常に安定したプラットフォームです。私自身、長年IBM iに関わってきましたが、その安定性には何度も助けられてきました。
ただ、その安定性があるからこそ、一度構築したシステムを長期間そのまま運用することも珍しくありません。PHPのようなオープンソースのソフトウェアは、IBM iとは異なるサイクルで進化しています。
IBM i本体はまだまだ元気でも、その上で動いているPHPがサポート終了になっている、ということもあります。今回のPHP2Shellは、そうした環境について改めて考えるきっかけになりました。
また、先に言ったとおり、急速なAIの発達などを鑑みると、アプリケーション保全は定期的に行うという、IBM iユーザーにとっては意識改革の時期が来ていると考えます。
今回の様な、メモリに対して直接操作する脆弱性の場合は、相対的に ppc64 が影響を受けにくい事もありますが、健全なのは常にソフトウェアを最新バージョンに保つ事だと考えます。
セキュリティ更新が継続的に提供されること。そして、必要なときに迅速に更新できること。当たり前のようですが、業務システムではなかなか難しい問題です。
おわりに
今回はPHP2Shellの概要と、IBM iへの影響について書いてみました。今回の脆弱性は深刻なものでしたが、IBM iでPHPを利用しているからといって、すべての環境で同じリスクがあるわけではありません。自分たちの環境を正しく把握し、適切な対策を進めることが大切だと思います。そして今回、CS^2を提供する立場として、普段とは少し違った緊張感のある対応を経験しました。
米国パートナーとのやり取りや、古いPHPへの対応、セキュリティアップデートの提供など、いろいろと考えることもありました。
次回は、そのあたりの実際の対応について書いてみようと思います。
参考情報
- IPA：PHPの脆弱性対策について（PHP2Shell）
- Seiden Group：Critical php2shell Security Update Available in Seiden PHP+ Server
- PHP公式：サポート対象バージョン
- 株式会社中部システム - INFO -
※この記事は2026年11月3日時点の公開情報をもとに書いています。最新のセキュリティ情報はPHP公式や利用しているPHP提供元の案内をご確認ください。