「被害未確認」でも安心できない――PHP脆弱性でサイト停止、いま何が起きているのか

いつも使っているサイトが突然開かなくなった。だが、その理由がサイバー攻撃による破壊ではなく、攻撃から守るための一時停止だったとしたら、どう受け止めるだろうか。

ウェブサイトやウェブアプリケーションを支えるプログラミング言語PHPで重大な脆弱性が明らかになり、ドイツでは行政機関などが予防的にサイトを停止した。

BUSINESS-PANORAMAが掲載した10月22日のAFP記事によると、ドイツ連邦情報セキュリティ庁（BSI）は、この脆弱性を悪用した事例を、その時点では確認していないと説明した。ただし、攻撃が成功していた可能性まで排除したわけではない。

このニュースを読むうえで重要なのは、「被害を確認していない」と「安全が確認された」は同じではないという点だ。

BSIの発表は「終息宣言」ではない

元記事によると、BSIは10月21日午後、PHPの脆弱性について警告し、同日16時にセキュリティ更新が予定されていることを案内した。

警戒されたのは、更新内容の公開後に攻撃が広がる可能性だった。修正によって問題の所在が明らかになれば、攻撃者がその情報を分析し、未修正のシステムを狙うことも考えられる。記事では、その分析がAIによって容易になることへの懸念も伝えられている。

翌22日、BSIは予防的に停止された連邦行政機関のサイトの大半が復旧したと説明。侵害されたシステムの報告がない状況について、多くの運営者が推奨に従って更新を済ませた可能性があるとの見方を示した。

ただし、これは把握できた情報に基づく評価だ。すべてのサイトについて調査を終え、侵入がなかったと保証したものではない。

サイトの復旧は利用者にとって朗報だが、それだけを理由に問題全体が解決したと判断するのは早い。

問題はウェブサイトの「土台」にある

今回、PHP側が修正したのは、「PHP2Shell」と呼ばれる2つの重大な脆弱性だ。識別番号はCVE-2026-109618とCVE-2026-109619。深刻度を示すCVSS v4.0の評価はいずれも9.2で、「Critical」に分類されている。

PHP Foundationは10月21日、条件がそろうと、認証されていない攻撃者がPHPを実行するサーバー上でコードを動かせる問題を修正したと発表した。

一般の利用者にとってPHPは、普段は意識しない存在だ。画面のデザインや記事そのものではなく、その裏側で処理を担っている。

そのため、今回の対応を考える際には、サイトの見た目や管理画面だけに目を向けても足りない。アプリケーションを動かす基盤の修正状況を確認する必要がある。

PHP Foundationが公表した修正版は、PHP 8.2.35、8.3.36、8.4.27、8.5.12。運営者は、自分の環境を提供する事業者の案内も含めて、修正の適用状況を確かめることになる。

「攻撃の試み」と「侵入成功」を混同しない

BSIに関する元記事と併せて押さえておきたいのが、AWSによる観測報告だ。

AWSは、攻撃を観測するための仕組み「MadPot」で、10月17日にさかのぼるPHP2Shellの悪用の試みを確認したと公表した。これは、脆弱性の詳細公開より前の時点に当たる。

一方、AWSは、観測した試みが実際のシステムで成功したかどうかは不明としている。

つまり、BSIに関する「悪用事例を確認していない」という報道と、AWSの「攻撃の試みを観測した」という報告は、対象も確認内容も異なる。片方だけを取り上げて「攻撃はなかった」、あるいは「大規模な侵入被害が確定した」と結論づけることはできない。

利用者としても運営者としても、脆弱性の存在、攻撃の観測、侵入の成功、情報流出の確認を分けて読む必要がある。

SNSでは、迅速な修正を評価する声も

SNSやオンラインコミュニティでは、危機感だけでなく、報道の受け止め方をめぐる意見も見られる。

RedditのPHPコミュニティに投稿された「Has PHP2Shell borne fruit?」では、恐怖をあおるような記事やPHPへの批判に触れながら、修正や主要Linuxディストリビューションの対応が迅速だった点を評価する意見が確認できた。

これは、脆弱性の深刻さとは別に、開発者や配布元の対応も見てほしいという受け止め方だ。ただし、投稿者による被害状況の評価が、そのまま世界全体の安全性を示すわけではない。

一方、メールエイリアスサービスaddy.ioに関するReddit投稿では、PHP2Shellへの対応としてウェブシステムを一時停止したことが共有された。そこでは、メール配送は継続すると説明され、その後、修正を適用して復旧したという案内も掲載されている。

「サービスが使えない」という一言で終わらせず、どこが停止し、何が利用でき、いつ復旧したのかを伝える。こうした情報共有は、利用者の不安を減らすうえで参考になる。

なお、ここで紹介したのは確認できた個別の投稿であり、SNS全体の多数意見や世論調査を示すものではない。

サイトを止める判断にも、説明が必要になる

予防的な停止は、利用者に不便をもたらす。問い合わせができない、手続きが進まない、商品を購入できないといった影響が出れば、運営側にも負担がかかる。

それでも、修正が済むまで外部からのアクセスを制限することには、攻撃への露出を減らす意味がある。CERT-EUも、直ちに修正できない場合には、インターネットに公開されたアプリケーションを公共ネットワークから隔離することを検討するよう案内している。

だからこそ、停止したかどうかだけで運営の良し悪しを判断するのは難しい。

むしろ問われるのは、停止の理由を説明したか、影響する機能を明示したか、次の案内をどこで確認できるようにしたかという対応だ。

何も説明せずに消えたサイトと、利用者を守るための対応を伝えたサイトでは、同じ停止でも受け止められ方が変わる。

日本の運営者にとっても「海外のニュース」ではない

PHPの問題は、ドイツ語のサイトだけに関係する話ではない。同じ技術を使う環境であれば、日本の事業者も確認が必要になる。

その際、最初の課題は、専門的な設定変更よりも、自社のサイトを誰が管理しているのかを明らかにすることかもしれない。

制作会社が担当しているのか。レンタルサーバー会社が基盤を更新するのか。それとも、自社の担当者が対応しなければならないのか。

確認したい点は、次のように整理できる。

• サイトの稼働環境で、PHPを使用しているか。
• 今回の脆弱性に対する修正が適用されているか。
• 更新の担当者と、対応完了の確認方法が決まっているか。
• すぐに修正できない場合、公開を制限する判断を誰が行うか。

「委託先が対応しているはず」と「対応済みの連絡を確認した」の間には、大きな差がある。

また、CERT-EUは、PHP 8.1以前のサポート終了済みの系列について、PHPプロジェクトから更新が提供されない点を示している。古い環境を使い続けている場合は、その環境の提供元による修正の有無と、移行の必要性を確認しなければならない。

防御策があっても、更新の代わりとは限らない

攻撃を防ぐ仕組みを導入しているから大丈夫、と考えたくなる場面もある。

しかし、AWSは今回の問題について、WAFによる対策は危険にさらされる範囲を減らす補助策であり、PHPの更新に代わるものではないと明記している。

大切なのは、何らかの防御製品を使っているという事実より、その対策が今回の問題をどこまでカバーしているかだ。

元記事では、BSIが一般利用者に対し、ルーターを外出先からアクセスできる状態にしないことや、ダウンロード、機密情報の提供に注意するよう呼びかけたことも紹介されている。

これは、すべての利用者の端末やルーターが今回の脆弱性に直接影響されるという意味ではない。運営側の対応と、利用者が日常的に行う注意は、分けて受け止めたい。

「何も起きなかった」を支える仕事がある

大きな警告のあとに目立った被害が伝えられなければ、「騒ぎすぎだったのでは」と感じる人もいるだろう。

しかし、被害が見えていない理由には、早期の更新や予防停止が働いた可能性もあれば、まだ把握できていない可能性もある。現時点の情報だけで、そのどちらかに決めつけることはできない。

今回のPHP脆弱性が示しているのは、サイトを公開し続けることだけが運営の責任ではないということだ。必要なときに止め、修正し、状態を確かめ、利用者に説明する。その一連の対応も、サービスを支える仕事である。

「被害未確認」という知らせは、対応をやめる理由にはならない。自分たちの環境はどうなっているのか。その確認まで終えて初めて、ニュースを読んだことが実際の備えにつながる。

出典

1. BUSINESS-PANORAMA／AFP（2026年10月22日）
   BSIが悪用事例を確認していないとしたこと、侵入の可能性を排除していないこと、行政サイトの復旧状況、一般利用者への注意喚起の根拠。
   https://business-panorama.de/news.php?newsid=6715602

2. PHP Foundation「Today's PHP Security Release, and How We're Strengthening PHP Security」
   10月21日の修正版公開と、脆弱性がもたらす危険についての公式説明。
   https://thephp.foundation/blog/2026/10/21/todays-php-security-release-and-how-were-strengthening-php-security/thephp.foundation

3. CERT-EU「Critical Vulnerabilities in PHP」
   CVE番号、深刻度、影響する環境、サポート終了系列、修正や隔離に関する公式助言。
   https://www.cert.europa.eu/publications/security-advisories/2026-018Critical Vulnerabilities in PHP

4. AWS Security Blog：MadPotによるPHP2Shell観測報告
   公開前の攻撃の試みと、実環境での成功については不明とする説明。「攻撃の観測」と「被害確認」を区別する根拠。
   https://aws.amazon.com/blogs/security/amazon-threat-intelligence-identifies-php2shell-exploitation-prior-to-public-disclosure-in-madpot/aws.amazon.com

5. AWS Security Blog：PHP2Shellに対するWAFの緩和策
   WAFの位置づけと、PHPの更新が必要であることを説明した公式資料。
   https://aws.amazon.com/blogs/security/using-aws-waf-to-apply-mitigations-for-php2shell-rce-vulnerabilities-cve-2026-109618-and-cve-2026-109619/aws.amazon.com

6. Reddit・r/PHP「Has PHP2Shell borne fruit?」
   報道への疑問や、迅速な修正を評価する個別の反応。投稿中の被害評価は、確認済みの事実として採用していない。
   https://www.reddit.com/r/PHP/comments/1xchgrv/has_php2shell_borne_fruit/reddit.com

7. Reddit・r/addy_io「Service Update 🚨PHP2Shell vulnerability」
   ウェブシステムの予防停止、メール配送の継続、修正後の復旧に関する情報共有の例。
   https://www.reddit.com/r/addy_io/comments/1xbkaeb/service_update_php2shell_vulnerability/