PHPの深刻な脆弱性「php2shell」は古いPHPにも存在、速やかにアップデートを

予防的に多くのサービスで事前にシャットダウン、日本時間21日22時35分頃に修正バージョンが公開済み / 2026年10月21日

WordPressやMediaWikiに留まらず、様々な場所で使用されているプログラミング言語である「PHP」に関して、日本時間21日23時に修正バージョンが公開されると予告されました。この脆弱性は「 php2shell 」と呼ばれており、Webからのリクエストを取り扱う場合、 認証無しでのリモートコード実行 につながりうるとされています。

この記事では現状の分かっている「php2shell」の概要と、その影響について簡単にまとめます。この記事の情報はあくまで21日23時10分現在の情報となりますので、その点を考慮して読み進めていただきたく思います。

結論

  1. PHP財団が事前にアップデートを予告
  2. 古いPHPにも存在する脆弱性、提供されているセキュリティーリリースは 8.5.12 ・ 8.4.27 ・ 8.3.36 ・ 8.2.35
  3. 複数の著名サービスが予防的にオフラインに

脆弱性の事前予告

PHP開発者に資金援助を行うなどの形でプログラミング言語PHPの開発等を推進するPHP財団は、2026年10月21日4時51分頃に以下の投稿を行いました。この投稿は、 現状のPHPにはCVSSスコアv4で9.2 となる2つの脆弱性が存在しており、修正版を約18時間後である日本時間21日23時に公開することを予告していました。

Post by @[email protected]
View on Mastodon

PHP財団は同投稿において、修正を行う前に脆弱性の詳細等が公表されたり脆弱性を突いた攻撃が実際に行われたりした場合において、アップデートの公開を早める可能性があるとしていました。

この公表に伴って、世界的にアップデートに向けた準備が取られることとなりました。日本においてはIPAが「【事前準備のお願い】PHPのセキュリティリリース公開予定について」と題した注意喚起を行ったほか、国家サイバー統括室が言及する事態となっています。

イギリスにおいては国家サイバーセキュリティーセンターがアラートを発出し、リリースされ次第可能な限り速やかにアップデートするべきであるとしています。

Remi's RPM repositoryの場合は注意

また、PHP財団は「Remi's RPM repository（remirepo、 rpms.remirepo.net ）」を使用している場合は、設定変更を行った上でアップデートを行うようアナウンスを行っています。remirepoはFedora系（RHEL系）のLinuxディストリビューションで使用可能なリポジトリであり、最新のPHPやその関連ソフトウェアを使用出来るようにしているリポジトリです。

Post by @[email protected]
View on Mastodon

これは、Remi's RPM repositoryの管理者（Remi Colletさん）が一時的にオフラインであることを宣言しているためです。記事公開時点でRemi ColletさんはBluesky上で新たな投稿を行っていないことを確認しています。

ℹ️ I'm going offline for a few days, so don't expect any updates in the repository.

— Remi's RPM repository (@remirepo.net) 2026年10月16日 23:27

脆弱性の概要

PHP財団によるリリースノートのスクリーンショット

日本時間21日22時35分頃、PHPの 8.5.12 ・ 8.4.27 ・ 8.3.36 ・ 8.2.35 がリリースされました。これらは脆弱性が修正されたバージョンだとされています。

この修正版公開に伴って、脆弱性の概要も公開されました。CVE番号はそれぞれCVE-2026-109618・CVE-2026-109619です。

CVE-2026-109618 は、メモリ不足（OOM）時の処理に起因する脆弱性です（詳細: GHSA-w8hw-w9fx-j79w ）。PHPの実行時、メモリ不足が発生すると、内部のリクエストデータが部分的にしか初期化されていない状態でPHPの処理が中断されることが考えられます。その後のリクエストにおけるクリーンアップ処理が、初期化されてない不正な状態のデータを誤って有効なものとして扱ってしまうことで、リモートコード実行につながる可能性があるとされています。PHP公式は、特に mod_php での危険性が高いとしており、認証無しのリクエストによって、アプリケーションのコードが実行されるよりも前に攻撃を引き起こせることが、実証されたエクスプロイトで確認されているとのことです。

CVE-2026-109619 は、古くなったグローバルな状態が残り続けることに起因する脆弱性です（詳細: GHSA-6wmf-4rv5-p3rp ）。本来はリクエストごとに保持される内部状態が、その裏付けとなるメモリが解放された後も残ってしまうことがあります。同じワーカーが後続のリクエストを処理する際に、通常の初期化によってリセットされる前の古い状態が使われてしまい、リモートコード実行につながる可能性があります。セッションのアップロード進捗（ session.upload_progress ）に関する経路や、PHP 8.5における致命的エラーのバックトレースに関する経路などが、攻撃経路の例として挙げられていますが、これらに限りません。

いずれも、 認証無しでリモートコード実行が可能になり得る という点で極めて深刻な脆弱性です。PHP-FPM・Apacheのmod_php・php-cgi・FrankenPHP・LiteSpeedなどに限らず、 Webリクエストを処理するPHP環境の全てが対象 となるとしています。

PHP8.1以前の場合正式なアップデートの提供は無し、公知の攻撃手法に脆弱な状況に

PHPは2026年10月21日時点で、PHP8.2以降のみをセキュリティーアップデートの対象としています。このため、PHP8.1以前、例えば PHP7やPHP5などを使用している場合 は、23時以降 攻撃方法が公知となっている「php2shell」に対して無防備な状態 となってしまっていると言えます。今回に関しては、

Given the severity of these vulnerabilities, the PHP security team provided minimal source-backports for PHP 7.4, PHP 8.0, and PHP 8.1 to help people building from source or without access to an LTS vendor.

としており、PHP7.4・PHP8.0・PHP8.1においては最低限のバックポートが提供されてはいます。

しかしながら、この場合においては、少なくともパブリックなネットワークからは切り離すことが推奨される他、適切な対応を行う必要があるとされています。PHPの公式サイトでは問題を軽減する手法がいくつか公開されているため、アップデートが行えない環境にある場合は参考にしてください。なお、PHPは各アドバイザリにおいて、

Updating to a PHP release containing the patch to this vulnerability is the only complete mitigation.（この脆弱性のパッチが含まれたPHPリリースにアップデートすることが、 唯一 の完全な対策です）

Updating to a release containing the complete state reset patch is the only reliable mitigation. There is no complete generic configuration mitigation as an application, extension or server path may publish stale state or consume it without a predictable log entry. （完全なステートリセットパッチを含むリリースに更新することが、唯一の確実な緩和策です。アプリケーション、拡張機能、またはサーバーパスが古いステートを公開したり、予測可能なログエントリ無しにそれを消費したりする可能性があるため、汎用的な完全な構成上の緩和策は存在しません。）

としています。

また、Cloudflareは無料顧客でも使用可能なWAFルールを作成し、必要に応じて更新を行っている旨をブログで紹介しています。

対応のため事前にオフラインとなったサービスの例

この脆弱性の対応のために複数のサービスがメンテナンスなどとしてオフラインとなることが発表されました。この記事では確認できる範囲で、事前にオフラインとなったサービスをいくつか示します。

極めて多数のサービスがオフラインとなっているため完全なリストを形成することは困難であるため、安全のためにオフラインとなったサービスはこれに限りません。また、任意のサービスがオンラインになっていることが、脆弱性対応が終了したことを直接意味しないことに留意してください。

Wikimedia

Post by @[email protected]
View on Mastodon

Internet Archive

Post by @[email protected]
View on Mastodon

niconico

BASE

DMM[.]com

刀剣乱舞ONLINE

ウマ娘（ゲーム）

PHPの脆弱性対応に伴うメンテナンスのお知らせ

グランブルーファンタジー

関連リンク

最後に

直近はAI技術を悪用したサイバー攻撃、またそれに伴う個人情報漏洩が相次いでおり、本日だけでもカーセンサーの漏洩（371万件程度）や、自治体向けサービスを手掛けるアルカディアに対する攻撃の詳細が明らかになるなど、情報システムの安全性に対して極めて関心が高まっているタイミングでの脆弱性公表でした。本件は、React2shell（2025年）のような、特定のソフトウェアの脆弱性というよりは、言語処理系そのものの脆弱性である可能性が高いという点が特徴的であると思います。もちろんプログラミング言語自体もある種のソフトウェアとは言える面もありますので一概には言えませんが、 言語そのものに脆弱性がある ことが 影響範囲の不明瞭さ を浮き彫りにしたのではないかと考えています。

自らが開発しているPHPで記述されているソフトウェアや、WordPressやMediaWikiなど、PHPを使用していることが広く知られているソフトウェアを使用している場合は、23時のリリースに合わせて速やかなアップデートを施せば問題が無い場合が多いと言えます。事前にオフラインとなっているサービスは、むしろ自らの技術スタックを把握し、適切に管理できている可能性が高いサービスであると言えるでしょう。しかしながら、一部のレンタルサーバーや、PHPを使用していることが広く知られていないソフトウェアを使用している場合は、アップデートが遅れることが想定されます。真の問題は、公開されているサービス等に PHPを使用している自覚が存在しない場合 です。

この場合においては、そもそも「更新すべき対象」として認識されないため、修正版が公開されても対応が行われず、脆弱性の詳細が広く知られた後も脆弱な状態のまま残り続けてしまう可能性が存在します。例えば、過去に外部の事業者が構築したまま保守担当者が不在となっているサイトや、パッケージ製品・SaaS・業務システムの管理画面などがこれに該当し得ます。また、レンタルサーバーによっては、PHPのバージョンを利用者自身が切り替える必要がある場合もあり、事業者任せにしていると対応が漏れてしまう可能性があります。

さらに、既にサポートが終了したバージョン（PHP8.1以前）を使用している場合には、 そもそもの修正版自体が提供されていません 。そして そのようなシチュエーションはまさに「更新すべき対象」として認識されていないという形 になりますので、 何かしらの問題が発生して初めて事態の深刻さに気付く というようなこととなりかねません。

そのため、今回の件で重要なのは、修正版の公開後速やかにアップデートを行うことは当然として、自分たちがPHPを使用しているか、より一般的には 技術スタックを正しく認識出来ているか を改めて確認することだと思います。サーバー上でのバージョン確認や、Ansible等の設定の確認などに加え、アップデート等の責任境界がどこにあるのかを整理するなども、シンプルながら意味が全くないことだとは言えないと考えます。万が一迅速に修正版が適用できない場合、WAFの活用や公開範囲の縮小といった緩和策も検討すべきですが、いずれにしても、攻撃されうる箇所がどの程度あるかを見積もり、それぞれに対して適切な対応を行うべきだと思います。

前の記事

金商法改正と「NOT A HOTEL」の暗号資産NACの行方

Writer

Osumi Akari

カテゴリ

miscellaneous tech news
Creative Commons License
This work is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License.