PHP開発チームは2026年10月21日、認証なしで外部から任意のコードを実行される恐れがある2件の重大な脆弱性、通称「PHP2Shell」を修正した。しかし、Amazonの脅威インテリジェンス部門は、その4日前の10月17日にすでに悪用の試みを観測している。通常のWebサーバーであれば管理者がPHPを更新できるが、NAS（ネットワーク接続ストレージ）ではPHPがOSに組み込まれており、所有者が直接更新できない場合がある。こうしたNASでは、脆弱性が解消される時期を左右するのはPHP本体の修正日ではなく、メーカーによる更新プログラムの配布日だ。実際、OSのWeb関連機能にPHPを使用するQNAPは、Amazonが確認した最も早い悪用試行から6日が経過した10月23日時点でも、修正版の公開日を示していない。

この問題を理解するには、PHPがNASのどこで使われているのか、メーカーごとにどのような更新手段が用意されているのかを区別する必要がある。各社のセキュリティ情報と対応時期を比較すると、同じ脆弱性でも所有者が取れる対策に大きな違いがあることが分かる。

AD

PHPがNASのどこに組み込まれているかで、修正方法が変わる

今回修正されたのは、CVE-2026-109618とCVE-2026-109619の2件で、修正版はPHP 8.5.12、8.4.27、8.3.36、8.2.35だ。QNAPやAsustorのセキュリティ情報では、いずれもCVSS v4.0で9.2という重大な脆弱性に分類されている。PHP開発チームの公式発表によると、設定変更によって一部の攻撃経路を制限することは可能だが、脆弱性を完全に解消するには修正版への更新が必要になる。米国のサイバーセキュリティ・インフラストラクチャー安全保障庁（CISA）も10月21日、速やかな更新を呼びかけ、更新できないシステムについてはオフラインにするよう勧告した。

2件の脆弱性はいずれも、PHPがWebリクエストを処理する際のメモリ管理に関係している。CVE-2026-109618では、メモリ不足によって処理が中断されると、リクエストに関する内部データの初期化が完了しないまま後始末が始まり、不正なデータが有効なものとして扱われる可能性がある。CVE-2026-109619では、解放済みのメモリを参照する内部状態が残り、同じワーカー（PHPの処理プロセス）が次のリクエストでその状態を使用してしまう。いずれもアプリケーション側の認証処理より前に悪用が成立する場合があり、ログイン機能だけでは防げない。オランダの国家サイバーセキュリティセンター（NCSC）も、PHPが機器や管理画面に組み込まれ、管理者が直接更新できない製品への影響を指摘している。

NASでは、PHPの組み込まれ方がメーカーによって異なる。Synologyのセキュリティ情報では、影響を受ける製品としてPHP 7.3〜8.4のパッケージや、Mail Station、Synology Calendarなどが挙げられている。一方、OSに内蔵されたPHPは外部からアクセスできる機能を持たないため、悪用されるリスクは非常に低いというのが同社の評価だ。Synologyは影響を受けるパッケージ向けの修正版を公開しており、所有者はパッケージセンターなどから更新できる。ただし、サポートが終了したPHP 7.3については修正版を提供しないとしている。

Asustorのセキュリティ情報「AS-2026-023」では、OSのADMにPHPを追加導入した製品が影響を受けると説明している。同社は修正版が提供されるまでWeb Serverを停止するよう推奨しており、利用者側で攻撃経路を減らす手段が示されている。こうした構成では、影響を受けるWebサービスを停止することで、少なくともそのサービスを経由する攻撃を抑えられる。

これに対してQNAPは、PHPがOSのWeb関連機能と複数のアプリケーションで使用されていると明記している。同社のセキュリティ情報「QSA-26-18」では、内蔵Webサーバーを停止してもWeb管理画面は保護されないと注意を促している。つまり、所有者が追加のWebサービスを停止しても、OS側のPHPに関係する攻撃経路が残る可能性がある。このため、修正版が提供されるまでの最も効果的な対策は、NASをインターネットに直接公開しないことだ。QNAPは不要なアプリやWebサーバーの停止も追加の緩和策として推奨しているが、それだけでは管理画面を保護できないため、ネットワーク側でのアクセス制限を優先するよう求めている。

さらにQNAPは、Container Station上で動作するコンテナや、サードパーティー製アプリケーションに含まれるPHPは、自社の更新プログラムの対象外だと説明している。OSの修正版を適用しても、コンテナ内のPHPまで自動的に修正されるわけではない。こうした環境では、コンテナイメージやアプリケーションの提供元が公開する修正版を別途適用する必要がある。

10月17日の悪用試行から見る、NASメーカーの対応の差

NAS所有者が確認すべき期間は、PHPの修正版が公開された10月21日ではなく、それ以前に悪用が試みられた10月17日から始まる。Amazonの調査報告によると、同社のハニーポット「MadPot」は10月17日、PHP2Shellの悪用を試みる通信を観測した。これは脆弱性が公表される4日前であり、Amazonは少なくとも同日までさかのぼって不審な通信を調べるよう勧めている。この日を起点に、PHP開発チームとNASメーカーの対応を時系列で比較すると、次のようになる。

日付 出来事 出典
10月17日 AmazonのハニーポットMadPotが、同社として最も早いPHP2Shellの悪用試行を観測 Amazon
10月21日 PHP開発チームが14時（UTC、日本時間23時）に4系列の修正版を公開 PHP、Amazon
10月22日 Synologyがセキュリティ情報を公開し、PHPパッケージなどの修正版を案内 Synology
10月22日 QNAPがセキュリティ情報を公開。対象製品の修正状況は「Fixing」で、修正版の公開日は未定 QNAP
10月22日 Asustorがセキュリティ情報を公開。ADM 4.1〜4.3および5.0・5.1の対応状況は「Ongoing」 Asustor

※2026年10月23日時点で確認した各社の公開情報に基づく。

Amazonが確認した最も早い悪用試行から、Synologyが修正版を案内した10月22日までは5日間だった。QNAPとAsustorも同日にセキュリティ情報を公開したが、10月23日時点では修正版の公開日を明らかにしていない。QNAPが影響を認めた製品には、QTS、QuTS hero、QuTScloudなどのOSに加え、複数のアプリケーションが含まれる。告知対象として列挙された製品の修正状況はいずれも「Fixing」で、修正版の欄は「To be announced」となっている。PHP本体の修正版が公開されても、NAS所有者がメーカーの更新を待たなければならない状況が続いている。

3社のセキュリティ情報は同じ10月22日に公開されたが、修正版の提供状況と回避策には違いがある。Synologyは対象パッケージ向けの修正版を案内し、AsustorはWeb Serverを停止するよう推奨している。一方、QNAPでは内蔵Webサーバーを停止してもWeb管理画面を保護できず、ネットワーク経由のアクセス制限が重要になる。いずれも脆弱性への対応という点では共通するものの、所有者自身が攻撃経路をどこまで減らせるかは異なる。

影響が懸念されるのは、この3社だけではない。AppleInsiderの報道によると、TerraMasterも10月22日、Reddit上で問題を調査し、修正を進めていると回答した。これは、F2-425のWeb管理画面でPHP 7.4.33が動作しているという所有者の報告を受けたものだ。ただし、この構成で実際にPHP2Shellを悪用できるかどうかは確認されておらず、古いPHPが動作しているという情報だけで侵害可能と断定することはできない。

日本国内のレンタルサーバー事業者と比較すると、対応の違いがより明確になる。さくらインターネットの公式メンテナンス記録によると、同社は10月21日23時からPHPの更新作業を実施し、翌22日6時30分に完了した。PHPの修正版が公開された日本時間23時から、7時間30分後である。同社は別途、レンタルサーバーなどの管理画面から選択できるすべてのPHPバージョンについて脆弱性への対応を完了したと発表している。事業者がPHPを管理するサービスでは、事業者側の更新によって利用者の環境も修正できるのに対し、NASではメーカーによる更新プログラムの公開と、所有者による適用という段階が必要になる。

Amazonは、インターネットに公開されたシステムの重大な脆弱性について、修正や緩和策の適用までの時間を日単位ではなく時間単位で考えるべきだと指摘する。7日や30日という従来の対応期限では、攻撃者の動きに追いつけない可能性があるためだ。QNAP製品の所有者も、インターネットからの直接アクセスを遮断するなどの緩和策であれば、修正版の公開を待たずに実施できる。しかし、OSに組み込まれたPHPそのものの修正はメーカーの対応に依存しており、公開日が示されていない以上、更新完了までの期間を具体的に見積もることはできない。

AD

悪用が確認されていなくても、NASの管理画面を公開すべきでない理由

もっとも、PHP2Shellの深刻度が高いからといって、影響を受けるすべてのNASが容易に乗っ取られるわけではない。QNAPは、自社製品を標的とした悪用の報告は受けていないと説明している。また、SecurityWeekの報道によると、セキュリティ企業watchTowrの脅威インテリジェンス責任者Jake Knott氏は、公開後に広く流通していた攻撃コードについて、正常に動作しないものや、応答時間の違いを調べるだけのもの、対象システムをクラッシュさせるだけのものがあると指摘した。同社が確認したこれらのコードでは、リモートコード実行（RCE）に至っていなかったという。Amazonも、ハニーポットで観測した悪用試行が実際のシステムで成功するかどうかは不明としている。

ただし、流通している攻撃コードの一部が不完全だったことと、脆弱性そのものを悪用できないことは別だ。PHP開発チームは、Apacheのmod_phpを使う環境で、アプリケーションのコードが実行される前に認証不要の攻撃が成立することを実証している。一方、CVSS v4.0の評価では攻撃の複雑さが「高」、攻撃の前提条件が「あり」とされており、実際の攻撃成立には環境や条件が影響する。したがって、CVSS 9.2という数値だけで個々のNASの侵害可能性を判断することは適切ではない。

対応期間の数え方についても注意が必要だ。10月17日から21日までは、脆弱性の詳細や修正内容の公開を制限する協調開示の期間だった。PHP Foundationの説明によると、修正パッチは配布事業者などに事前提供されていたが、一般公開は10月21日14時（UTC）と取り決められていた。実際には一部の配布事業者が予定より早く修正版を公開したものの、広く利用者が修正版を入手できるようになったのは21日の正式公開以降である。10月21日を起点にすれば、Synologyの修正版案内は翌日であり、QNAPとAsustorの対応状況も10月23日時点では公開後2日目に当たる。

それでも10月17日を基準にする理由は、メーカーの対応速度を評価するためではなく、侵害の痕跡を調査すべき期間を判断するためだ。Amazonは、正式公開前にも悪用試行が存在した以上、公開日以降のログだけを確認するのでは不十分だと指摘している。したがって、10月17日から23日までの6日間は、QNAPが修正に6日間を費やしたという意味ではない。この期間に外部からアクセスできる状態だったPHP関連サービスについて、過去の通信や不審な操作を調べる必要があるという意味である。

問題は、メーカーの修正版が公開されるまで、危険な状態がいつ解消されるのか見通せないことにある。Amazonは、AIを使ったコード解析によって、修正パッチの差分やセキュリティ情報から動作する攻撃コードを作るためのコストが下がっていると指摘する。技術情報の公開から数時間、場合によっては数分で攻撃に移ることが可能になりつつあり、修正版の公開後も迅速な対応が求められる。また、SecurityWeekが引用したCensysの調査では、10月21日時点でインターネット上に存在する約258万台のホストのうち、PHPのバージョンを識別できたのは約158万台で、その約157万台が未修正のバージョンを使用していた。これは外部から確認できるバージョン情報に基づく集計であり、個々のシステムに対する攻撃の成功可能性を測定したものではないが、攻撃者が探索できる対象の多さを物語っている。

こうした状況を受け、QNAP自身も修正版の公開までに最も効果的な対策として、機器をインターネットに直接公開しないよう求めている。とりわけ危険性が問題になるのは、Web管理画面やPHPを利用するWebサービスをインターネットからアクセスできる状態にしているNASだ。LAN内からしか接続できない構成なら、外部からの直接攻撃を受ける可能性は低くなる。ただし、QNAPは、すでに侵害されたLAN内の機器を経由する攻撃までは防げないとも注意している。

QNAP製品の所有者は、同社が示した対策に従い、まずルーターのポート転送とUPnPを無効にし、不要なmyQNAPcloud Linkや公開サービスを停止する必要がある。遠隔地からNASを利用する場合はWeb管理画面を直接公開せず、VPN経由で接続することが推奨される。管理ポートは既定の8080と443に加え、変更したポートも含め、信頼できるローカルネットワークやVPNからのアクセスに制限する。不要なPHP関連アプリや内蔵Webサーバーの停止も攻撃面の縮小に役立つが、管理画面の保護にはネットワーク側の制限が引き続き必要だ。

加えて、過去の侵害の痕跡も確認したい。QNAPはQuLog Centerによる不審なログインやアクセスの確認に加え、Security CenterとMalware Removerを使用した検査を推奨している。Amazonの勧告に従うなら、調査対象のログは少なくとも10月17日までさかのぼるべきだ。万一侵害が疑われる場合、QNAPは機器をネットワークから切り離し、パスワードを変更したうえでサポートに連絡するよう案内している。

今後の判断材料となるのは、QNAPのセキュリティ情報「QSA-26-18」の更新状況だ。修正版の欄が「To be announced」から具体的なバージョン番号に変われば、所有者は更新によって脆弱性を解消できる段階に進む。また、今後の調査でWeb管理画面が攻撃経路にならないと確認されれば、同画面に関するリスク評価も変わることになる。ただし、メーカーが修正版を公開しても、所有者が適用するまでは脆弱性が残る点に変わりはない。

さらに、NAS本体の更新が完了しても、Container Station上のコンテナやサードパーティー製アプリに組み込まれたPHPは別途確認する必要がある。Synologyが修正版を提供しないPHP 7.3のように、サポート終了によって更新経路が失われた部品にも注意が必要だ。PHP2Shellへの対応を完了するには、NASのOSだけでなく、そこで動作するPHPの実体をすべて把握し、それぞれの修正状況を確認しなければならない。メーカーの更新を待つ間のアクセス制限と、更新後に残る古いPHPの洗い出しが、NASを安全に運用し続けるための重要な課題となる。