php2shellで一番ヤバかったのは性癖や出会い系履歴の流出では？PHP脆弱性のよもやま話

どうもカッツプロダクション代表のカッツです！今週はPHPの脆弱性のニュースで、Web界隈がずっとザワザワしてましたね、、、

今回は、2026年10月21日に公開されたPHPの脆弱性、通称「php2shell」について、Web屋の目線でつらつら考えたことを書くよもやま話です。結論から言うと、PHPが動いてるサーバーなら、細工したリクエストを1発送るだけで乗っ取られうる、というかなりヤバいやつでした。

そもそも何が起きたのか

PHPの開発チームが、10月21日の22時40分頃（日本時間）に、重大な脆弱性2件を修正したセキュリティリリースを出しました。

• CVE-2026-109618 と CVE-2026-109619 の2件。どちらもリモートコード実行（RCE＝外から好きなプログラムを動かされる）につながる
• 深刻度はCVSS v4.0で9.2（緊急）
• 認証なしで攻撃できる
• PHP-FPM、Apacheのmod_php、php-cgiなど、Webリクエストを処理する構成が軒並み対象。古いPHP 5系・7系まで影響があるとされてます
• 修正版は 8.2.35 / 8.3.36 / 8.4.27 / 8.5.12

しかも公開前から情報が漏れて、悪用の試行まで観測されてたらしいです。国内でも省庁、自治体、銀行、航空会社、ゲーム会社、ECなどが予防的にサービスを止める事態に。まとめサイトのpiyologさんによると、確認できただけで211組織が停止や対応をしてます。地味にBASEも緊急メンテしてました。

首相までXで対応を呼びかけてたので、「PHPの脆弱性で首相が出てくるの！？」って驚きました。

正直セキュリティは専門外で、普段そこまでキャッチアップしてないんですが、そんな自分でも「これはヤバい」と分かるレベルの騒ぎでした(笑)

ざっくり言うと「リクエスト1発で乗っ取り」

自分なりにざっくりまとめると、PHPで動いてるサイトに、細工したHTTPリクエストを送るだけで、ほぼ乗っ取れるという脆弱性です。

ポイントは、自分が書いたPHPのコードが1行も動く前にやられること。PHPがリクエストを受け取って解析する段階で発動するので、

• アップロード機能を作ってなくても
• $_POSTを一切使ってなくても
• 中身が <?php echo "hello"; ?> だけのファイルでも

PHPエンジンにリクエストが渡った時点でアウト、という理解です（厳密には攻撃が成立する条件があるみたいですが、アプリの中身とは関係なく狙われる、という意味で）。攻撃経路の1つとして、初期設定でオンになってる「セッションのアップロード進捗」機能（session.upload_progress）が使われることも、被害範囲が広がった理由みたいです。

SQLインジェクションみたいに「プログラムの書き方が悪い」話じゃなくて、PHPのエンジンそのものの問題なので、アプリ側ではどうしようもないんですよね。

余談でアダルト系サイトの心配をしてみる

話が横道に逸れますが、、、ニュースを見てて真っ先に思ったのが、アダルト系の動画サイトとか、アダルトグッズ系のECとか、出会い系とか、PHPで作られてるところ多そうだよなってことです。

そういうサイトのDBから政治家のデートクラブ利用履歴なんかが引っこ抜かれて、美人局みたいなゆすりのネタにされたら大変ですもんね。自分ごとだと仕事が早い、、、おっと失礼しました(笑)

もちろん他人事じゃなくて、DBに入られたら自分も含めあなたの性癖がバレるかもって脆弱性だったわけで(笑)。首相がわざわざXで呼びかけたのも、国民の性癖を守るためだったのでは、、、なんて一瞬思いました（笑）。

真面目な話をすると、あのジャンルは決済の与信が通りにくかったり、SaaS型のECやサービスで利用NGだったりすることが多いです。技術者の調達も難しいとなると、必然的に自前のPHPで組む選択肢になりやすいんじゃないかなと（Web業界にいると、そういう話はよく耳にします）。

静的HTMLだけなら関係ない、WordPressは直撃

で、自分がまず気になったのは「レンタルサーバーで静的な.htmlだけ置いてるサイトはどうなの？」ってことでした。

結論、静的HTMLだけなら影響はありません。Webサーバーが.htmlをそのまま返すだけで、PHPエンジンが起動しないからです。

逆に、.phpファイルが1つでも置いてあって、外からアクセスできるなら危ないです。昔設置したお問い合わせフォームや、消し忘れたテスト用の.phpなんかも要注意ですね。

mod_rewriteでindex.phpに集まる構成がクリティカル

じゃあ存在しない xxxx.php を狙われたらどうなるかというと、普通はWebサーバーが「そんなファイルない」と404を返して終わります（サーバーの設定次第ですが）。

ところがWordPress、Laravel、CakePHPみたいに、mod_rewriteでどんなURLでも全部index.phpに流す構成だと話が変わります。適当なURLを叩かれても、親切なルーティングのおかげで全部PHPエンジンまで届いちゃうんですよね。

まさしく「index.phpがあって、不正なリクエストを送られたら終わり」なんじゃん！という感じで、WordPressサイトが大騒ぎになってたのはこれが理由です。

パッチ待ちの間にできること

レンタルサーバーの共有プランだと、PHP本体を直すのはサーバー会社の仕事なので、基本はサーバー側がパッチを当てるのを待つしかありません。ちなみにpiyologさんのまとめによると、さくらインターネットは10月22日の朝6時30分にはPHPの更新を完了してたそうです。早い！

待ってる間に不安なら、PHPにリクエストが届く手前のWebサーバー（Apache）の段階で止めるのが考え方の基本です。

• 公開ディレクトリを空にして、静的なindex.htmlだけ置く（バックアップは必ず取ってから）
• .htaccessで全部403にする（自分のIPだけ通す形にもできる）
• .htaccessでBasic認証をかける（Apacheが認証で弾くので、PHPまで届かない）
• アップロード機能を止めてもいいなら、multipart（ファイル送信形式）のリクエストを.htaccessで弾く

# 既存のWordPressのルールより「上」に書く
RedirectMatch 403 .*

AIさんに聞いたら混ざってた

今回の件、最初はGoogleのAIモードで質問しながら理解していきました。仕組みの説明はかなり分かりやすかったんですが、ファクトチェックしたら混ざってるところがありました。

• 発見の経緯：AIさんは「GPT-5.6 Solが発見した」と言ってたんですが、それは7月に話題になったWordPressの別の脆弱性「wp2shell」の話でした。php2shellは、セキュリティ企業のCalifさんとOpenAIさんがそれぞれ独立して報告していて、発見側が「AIモデルを使った」と説明している、というのが正確なところです
• Basic認証：最初は「Basic認証は完全に無意味」と言い切ったので、ん？！と思い「.htaccessのBasic認証なら？」と聞き返したら「100%防げます、失礼しました」と手のひら返し(笑)
• あと、こちらが何か言うたびに「100%完璧な理解です！」と褒めてくれるのも、ちょっと怪しいポイントです

AIの説明は仮説として読んで、一次情報で裏を取るのが大事ですな〜！！

野良LLMなら攻撃リクエストも作れちゃう？

ついでに「これ、野良のLLMなら攻撃用のリクエストも作れちゃうよね？」とも思いました。大手のAIモデルは、攻撃コードを作ってと頼んでも断るようになってますが、安全対策を外したローカルのモデルなら、、、という話は普通にありえそうです。

今回の脆弱性自体も、AIを使った監査で見つかったと言われてます。AIで見つけるのも速くなったけど、攻撃するのも速くなる。パッチを当てるスピードがこれまで以上に大事になりそうです。

まとめ

• php2shellは、認証なし・リクエスト1発でサーバーを乗っ取られうるPHPエンジン自体の脆弱性
• 静的HTMLだけのサイトは影響なし。.phpが1つでもあれば要注意
• WordPressやLaravel、EC-CUBEなど全部index.phpに流す構成はどこを叩かれても届くのでクリティカル
• パッチ待ちの間は、.htaccessの403やBasic認証でPHPの手前で止める。プラグインのメンテナンスモードでは防げない
• AIさんの説明は分かりやすいけど、混ざってることもあるので裏取り必須

なんとなく気づいてたけど、「index.phpに全部集まる」って便利な仕組みが、こういうときは一番の弱点になるんだなと。体感的にはわかってたんですが文章にして体系化するとスッキリ！