2026年10月21日、PHPの重大な脆弱性「php2shell」が公表され、国内外のWebサービスやレンタルサーバー会社が緊急対応に追われた。
高市早苗首相までXで「大至急のお願い」と呼びかける騒ぎになったわけだ。
PHPはWordPressを動かすためにも使われているので、当然、俺が運営しているこのブログも無関係ではない。
実際に調べてみたところ、幸いにも利用しているエックスサーバーが修正対応を行ってくれていた。
そのあたりは前回の記事にまとめている。
ただ、調べている最中から、ずっと引っかかっていたことがある。
そもそも個人ブログなんてハッキングして何になるんだ？
企業なら分かる。
顧客情報、クレジットカード情報、企業秘密。盗み出して金になるものはいくらでもあるだろう。
でも、俺のブログにあるのは映画の感想やガジェットのレビュー、それから日常のどうでもいい話くらいだ。
そんなものを盗んでどうする。犯人も困るだろう。
ところが、気になって自分のブログのアクセスログを調べてみたら、どうもそんな悠長なことを言っていられる話でもなかった。
しかも今回のPHPの脆弱性は、AIを活用した研究によって、長年存在した欠陥の危険性が明らかになったという。
攻撃する側も、守る側もAIを使うようになったら、一体どうなるんだろうか。
今回はそんな疑問について、実際のアクセスログとセキュリティ企業の調査をもとに考えてみたい。
そもそもハッカーは個人ブログを狙うのか？
まず、ここが一番の疑問だった。
わざわざ手間をかけて小さな個人ブログに侵入しても、得られるものなんてほとんどないはずだ。
しかし、調べてみると、俺は攻撃者の仕事を少し勘違いしていたらしい。
ハッカーはいちいちサイトを選んでいない
もちろん、特定の企業や組織を狙う攻撃もある。
しかし、それとは別に、インターネット上のサイトを自動的に巡回して弱点を探す攻撃も存在する。
例えば、WordPressの特定のプラグインに脆弱性が見つかったとする。
攻撃者は、そのプラグインを使っている可能性があるサイトをプログラムで大量に探せる。
そこで侵入できそうなサイトが見つかれば、攻撃を試みる。
相手が大企業なのか、個人ブログなのかは必ずしも関係ない。
要するに、価値があるから攻撃されるのではなく、侵入できそうだから攻撃される。
泥棒が高級住宅街だけを狙っていると思っていたら、実際には鍵の開いている家を片っ端から探しているような話だ。
WordPressのセキュリティ企業Wordfenceも、2018年に「自分のような取るに足らないサイトがなぜ攻撃されるのか？」という、まさに俺が抱いた疑問に答える記事を公開している。
ちなみに、こうした自動巡回はAIが登場するずっと前から存在している。
だから、AIによって突然個人ブログが狙われ始めた、という話ではない。
個人ブログを乗っ取って、いったい何に使うのか？
では、実際に個人ブログへの侵入に成功したとして、攻撃者は何をするのか。
調べてみると、これが案外いろいろある。
① 勝手に怪しいページや広告を設置される
例えば、俺が書いた映画レビューの裏で、まったく関係のない通販サイトや詐欺サイトへの誘導ページが作られる。
あるいは、ブログを訪れた読者が別のサイトへ勝手に飛ばされる。
もちろん、ブログの管理者である俺はそんなページを作った覚えがない。
それでも訪問者からすれば、怪しいサイトに誘導してきたのは俺のブログということになる。
これは厄介だ。
被害が確認されれば、Googleの検索結果やブラウザに警告が表示される場合もある。
読者の信用を失うだけでなく、検索からのアクセスにも影響する可能性があるわけだ。
② SEOスパムに利用される
SEOスパムというのは、検索エンジンを悪用して不正に集客しようとする行為のこと。
乗っ取ったサイトに大量のスパムページを設置したり、怪しいサイトへのリンクを仕込んだりする手口がある。
俺はGoogleの検索順位を上げるために、記事をリライトしたり、検索結果の数字を眺めたりしている。
それなのに、知らないところで怪しいページを大量生産されたらたまったものじゃない。
Wordfenceも、正規のWordPressサイトにスパムページや不正なリンクを設置する事例を紹介している。
攻撃者にとっては、すでに検索エンジンから認識されているサイトを悪用できることに意味があるらしい。
俺が何年もかけて積み上げるつもりの信用を、知らない誰かが勝手に利用するわけだ。
なかなか腹の立つ話である。
③ 他のサイトを攻撃するための踏み台にされる
これが個人的には一番意外だった。
攻撃者は、必ずしも俺のブログそのものに興味があるわけではない。
欲しいのは、自由に使えるサーバーの処理能力や通信環境なのかもしれない。
実際、Wordfenceは過去に、侵入したWordPressサイトを利用して他のサイトを攻撃しながら、暗号資産のマイニングまで行っていた事例を紹介している。
ほかにも、スパムメールの送信や不正ファイルの保管場所として使われることがあるという。
つまり、俺のブログは最終目的ではなく、単なる道具になる。
これなら、サイトの知名度もアクセス数も大して関係ない。
盗むものがなくても、勝手に使える場所があるだけで価値になる。
どうやら、そういう世界らしい。
もし企業が同じ攻撃を受けたらどうなる？
では、個人ブログと企業のサイトでは何が違うのだろう。
もちろん企業でも、単純にサイトが改ざんされるだけで終わる場合はある。
反対に、個人ブログでも問い合わせフォームなどで情報を扱っていれば、情報流出の危険性はある。
ただ、企業の場合はサイトの役割が大きく、被害が顧客や取引先にまで広がる可能性がある。
| 被害の種類 | 個人ブログ | 企業サイト・システム |
|---|---|---|
| サイト改ざん | 怪しい広告やページを設置される | 偽の企業情報や詐欺ページを掲載される |
| 情報流出 | 管理者情報や問い合わせ内容など | 顧客・従業員・取引先の情報など |
| 金銭的被害 | 復旧費用、広告収益の減少 | 復旧費用、売上損失、対応費用など |
| 業務への影響 | ブログの停止、更新不能 | 予約、販売、決済、社内業務の停止 |
| 信用への影響 | 読者や検索エンジンからの信頼低下 | 顧客・取引先・社会からの信用低下 |
※実際の被害は、侵入された範囲やシステムの構成によって異なる。
企業の場合、被害が自社だけでは済まない
例えば、ネットショップを運営している企業が攻撃されたとする。
顧客情報が流出すれば、被害に遭うのはその企業だけではない。
顧客への説明や調査、場合によってはサービスの停止も必要になる。
さらに、企業のシステムが取引先などのシステムとつながっていれば、被害が広がるおそれもある。
ただし、ホームページが乗っ取られたからといって、自動的に社内のすべての情報へアクセスできるわけではない。
そこは区別して考える必要がある。
企業ではランサムウェアも大きな問題
ランサムウェアは、データを暗号化したり盗み出したりして、金銭を要求する攻撃に使われる不正プログラムだ。
IPA（情報処理推進機構）が発表した「情報セキュリティ10大脅威2026」では、組織向けの脅威として「ランサム攻撃による被害」が1位になっている。
さらに、サプライチェーンや委託先を狙った攻撃が2位。
そして、今回の記事にも関係する「AIの利用をめぐるサイバーリスク」が初めて3位に入り、「システムの脆弱性を悪用した攻撃」は4位だった。
もちろん、今回のPHP脆弱性がそのままランサムウェア被害につながったという意味ではない。
ただ、Webサイトやシステムの欠陥が、より大きな攻撃の入り口になる可能性はある。
しかも、今回のPHPは世界中の非常に多くのWebサイトで使われている。
そう考えると、首相まで緊急対応を呼びかけた理由も少し分かる気がする。
じゃあ、実際に俺のブログにも攻撃は来ているのか？
ここまで調べて、今度は自分のブログが気になってきた。
実は少し前、Googleアナリティクスでアメリカからのアクセスが急に増えたことがあった。
どうも普通の読者ではなく、自動アクセスらしい。
そこで今回は、エックスサーバーのアクセスログを実際に調べてみることにした。
10月11日のアクセスログを確認してみた
調べたのは、2026年10月11日3時47分から翌12日3時37分ごろまでの記録（日本時間）。
すると、こんな数字が出てきた。
| 調査項目 | 確認できた数 |
|---|---|
| HTTPリクエスト | 15,231件 |
| 異なるアクセス元IP | 787 |
| 404（ページが見つからない） | 612件 |
| 403（アクセス拒否） | 218件 |
※エックスサーバーのアクセスログを集計。リクエスト数は人間の訪問回数やPV数とは異なる。
画像・CSS・JavaScriptなどの取得も含まれる。
この数字だけなら、必ずしも異常ではない。
例えば記事を1ページ開いただけでも、画像やプログラムを読み込むために複数の通信が発生する。
問題は、その中身だった。
わずか23秒間に253件のアクセス
ログを詳しく見てみると、10月11日の午前6時11分ごろ、同じIPアドレスからわずか23秒間で253件ものリクエストが記録されていた。
1秒あたり約11件。
そのうち、403（アクセス拒否）が113件、404（ページが見つからない）が101件。
さらに、要求の形式が不正だったことを示す400も14件あった。
アクセス先を調べてみると、例えば次のようなものがあった。
.envなどの設定ファイル.git/configなどの開発環境に関係するファイル- 通常のブログ記事とは関係のない管理用URL
- 存在しないPHPファイル
こうしたファイルには、環境によって設定情報や認証情報などが含まれる場合がある。
直接確認した .env や .git/config への要求は403で拒否されており、これらのファイルが正常に取得された記録はなかった。
ちなみに、200（正常応答）になった25件は、主にトップページや公開されているJavaScriptなどだった。
しかし、普通の読者が映画レビューを読むために、こんなファイルを片っ端から探すだろうか。
少なくとも俺はやらない。
これはWordPressやサーバーの弱点を探す、自動スキャンと考えるのが自然だろう。
ただし、ハッキングに成功した証拠はない
ここは誤解のないように書いておきたい。
今回確認できたのは、不審な探索行為と考えられるアクセスだ。
実際に管理画面へ侵入されたとか、ファイルを書き換えられたという証拠が見つかったわけではない。
また、このログは今回のPHP脆弱性が公表された10月21日より前のものなので、php2shellを狙った攻撃だと結びつける根拠もない。
以前のアメリカからのアクセス急増と同じ原因だったかどうかも、現時点では分かっていない。
そもそもGoogleアナリティクスは、サーバーのアクセスログとは計測方法が違う。JavaScriptを実行しない単純なスキャナーなら、アナリティクスには記録されないこともある。
ただ、少なくとも一つ分かったことがある。
個人ブログだからといって、インターネット上の自動スキャンから無視されるわけではない。
俺が映画の感想を書いている間にも、どこかのプログラムがサーバーの中身を探ろうとしていたわけだ。
なかなか気味の悪い話である。
今回のPHP脆弱性は、AIを使って発見されていた
ここから、今回のPHP騒動でもう一つ気になった話をしたい。
実は、今回の重大な脆弱性は、複数の研究チームがAIを利用して調査していた。
対象となったのは次の2件だ。
- CVE-2026-109618
- CVE-2026-109619
今回の修正版が公開されたのは10月21日だが、問題が発見されたのはもっと前になる。
PHP開発側は2024年から問題の兆候を把握していた
PHP Foundationの発表によると、今回の脆弱性につながるメモリ管理上の問題は、2024年のセキュリティ監査をきっかけに、その兆候が把握されていたという。
しかし、当時は具体的な攻撃方法が分かっておらず、修正による互換性への影響なども大きな課題だった。
そして2026年8月11日、セキュリティ企業Califの研究者が、OpenAIの取り組み「Patch the Planet」の一環として重大な欠陥を報告した。同日にはOpenAIからも独立して同じ根本原因について報告があった。
さらに8月19日、Wiz ResearchもAIを活用して独立に脆弱性を発見。
Wizはその後、WordPressやDrupal、Joomlaなどに対して、ログインなしで不正なプログラムを実行できることまで実証した。
つまり、単にAIが突然バグを見つけたというより、以前から問題の兆候が知られていたPHPの欠陥について、AIを活用した研究が実際の危険性を明らかにしたという話だ。
AIは単に間違いを見つけただけではない
今回の研究で驚いたのは、AIの役割が脆弱性の発見だけではなかったことだ。
Wizの研究チームは、AIを活用しながら複雑な欠陥を分析し、実際に攻撃が成立するか検証した。
さらに、修正内容の検証にもAIを利用していた。
もちろん、これは研究者が管理された環境で検証したもので、実際のサイトを無差別に攻撃したという話ではない。
それでも、これまで高度な専門知識と時間が必要だった作業の一部を、AIが支援できるようになっている。
Wizは、一人の研究者が1週間で、従来なら高度な専門チームが数か月かけていたような作業を進められたと説明している。
研究企業自身による評価なので、そのまますべての開発現場に当てはめることはできない。
それでも、研究の進め方が変わってきていることは感じる。
ここで一つ疑問が出てくる。
これだけのことがAIでできるなら、攻撃する側だって同じようにAIを利用できるんじゃないのか？
AIが攻撃して、AIが防御する。イタチごっこは終わらない？
個人的には、今回のPHP騒動で一番興味を持ったのがここだった。
AIによって、今まで発見するのが難しかった脆弱性が見つかる。
開発者がそれを修正する。
ところが、攻撃する側もAIを使って別の欠陥を探したり、攻撃の方法を検証したりする。
そして、防御する側がまたAIを使う。
これ、永遠に続くんじゃないのか。
攻撃者にとってAIは何を変えるのか？
これまで、高度なサイバー攻撃には専門知識や長い調査時間が必要だった。
もちろん、AIがあれば誰でも簡単にハッキングできるというわけではない。
ただ、プログラムの解析や問題の発見など、一部の作業をAIが支援できるようになることで、攻撃準備の負担が下がる可能性がある。
攻撃者が一人だったとしても、これまでより多くの調査を短い時間で行えるかもしれない。
小さなサイトまで狙う無差別攻撃とも、相性がよさそうな話だ。
ただし、今回俺のブログに来ていた自動スキャンがAIを使っていたという証拠はない。
そこは別の話として考える必要がある。
守る側もAIで対抗している
一方で、AIの進化が攻撃者だけに有利になるとも限らない。
今回のPHPの件では、まさに防御する側の研究者がAIを活用していた。
Cloudflareも、今回のPHP脆弱性に対して、修正版の公表前からWAFによる防御を準備していた。
しかも、実際に攻撃通信を観測し、攻撃者が防御を回避しようと通信内容を変えていたことも報告している。
ただし、この攻撃の変更にAIが使われていたと確認されたわけではない。
それでも、攻撃する側が手を変えれば、防御する側も対策を更新する必要がある。
まさにイタチごっこだ。
しかも、修正版の公開前から攻撃の試みがあった
ここでもう一つ気になるのが、攻撃の速さだ。
今回のPHP脆弱性では、修正版の公表より前から悪用の試みが観測されていたという報告がある。
修正を準備する側と、攻撃方法を探す側。
双方が同じ時間の中で動いている。
WAFによる防御が先に用意されていても、すべての攻撃を止められるとは限らない。
ましてや、世の中にあるすべてのサーバーが、同じ瞬間に修正版へ更新できるわけでもない。
穴を塞ぐ側と、その穴を突こうとする側の競争は、すでに始まっているわけだ。
でも、AIが攻撃を減らす可能性もある
ここで少し考え方を変えてみたい。
AIが重大な脆弱性を見つけられるということは、攻撃者より先に防御側が問題を発見できる可能性もある。
ソフトウェアが公開される前に欠陥を見つけ、修正することができれば、そもそも攻撃できる場所を減らせる。
つまり、AIの進化は必ずしも悪い話ばかりではない。
ただし、プログラムからすべての欠陥がなくなるとも考えにくい。
新しい機能が追加されれば、新しい問題が生まれるかもしれない。
そして、AIがそれを見つける。
結局のところ、イタチごっこ自体は今後も続くんだろう。
問題は、AIがどこまで賢くなるかよりも、攻撃者と防御側のどちらが先に欠陥を発見して行動できるか、なのかもしれない。
じゃあ、個人ブロガーはどうすればいいのか？
ここまで調べておいてなんだけど、正直なところ、個人ブロガーが世界中のハッカーやAIに技術力で対抗するなんて無理な話だ。
少なくとも俺にはできない。
だからこそ、レンタルサーバー会社などが提供するセキュリティ対策に頼る部分も大きい。
実際に今回のPHP脆弱性では、俺が何かする前にエックスサーバーが修正を適用してくれていた。
ただ、サーバー会社に任せれば何もしなくていいというわけでもない。
自分のWAF設定を確認してみたら、全部OFFだった
今回、アクセスログを調べた流れで、エックスサーバーのWAF設定も確認してみた。
WAFは、サイトに対する不審な通信を検知・遮断するための仕組みだ。
ところが、俺のブログでは次の6項目がすべてOFFになっていた。
- XSS対策
- SQL対策
- ファイル対策
- メール対策
- コマンド対策
- PHP対策
どうして全部OFFだったのかは分からない。
少なくとも、これまで俺が積極的に設定を見直してこなかったのは確かだ。
そこで今回は、6項目すべてをONへ変更した。
設定が反映されたことも管理画面で確認できた。
ただし、WAFを有効化したからといって、あらゆる攻撃を防げるわけではない。
また、WAFによって正常な通信までブロックされる場合もあるので、WordPressの編集機能や問い合わせフォームなどの動作確認は必要になる。
ちなみに、Cloudflareが今回導入した専用の防御ルールと、俺が設定したエックスサーバーのWAFは別の仕組みだ。
WAFは攻撃を受けないようにする魔法ではなく、攻撃に備えるための防御の一つということだ。
WAFをONにすればphp2shellも防げる？
ここは明確に分けておきたい。
今回のphp2shellはPHP本体の欠陥なので、WAFをONにするだけでは根本的な解決にならない。
10月21日に公開された修正版は、PHP 8.5.12、8.4.27、8.3.36、8.2.35の4つ。
利用しているバージョンやサーバー会社の修正対応を確認し、必要なアップデートを適用することが基本になる。
古いPHPに独自修正が適用されている場合もあるので、表示されたバージョン番号だけで判断できないケースもある。
また、WordPress本体やプラグインの更新は重要だが、それだけでPHP本体の脆弱性が修正されるわけではない。
一般的なWordPressのセキュリティ対策と、今回のPHP本体への対策は別物として考える必要がある。
詳しい確認方法は前回の記事にまとめているので、そちらを参考にしてほしい。
10月23日には、さらに別のPHP脆弱性も公表された
なお、10月23日には、PHPのセッション機能に関する別の脆弱性「CVE-2026-115560」についても公式から注意喚起が出ている。
これは10月21日の修正版でも解消されていない問題だが、悪用には通常とは異なる特定の設定とプログラムの組み合わせが必要とされている。
PHP開発チームは、該当する環境への暫定対策を案内し、次の定期リリースで修正する方針を示している。
すべてのWordPressサイトが直ちに危険という話ではないものの、今回の騒動が一度のアップデートで完全に終わるとは限らないことも分かる。
個人ブログのセキュリティで気になる疑問
不審なアクセスがあったら、ハッキングされたということ？
不審なアクセスがあったことと、実際に侵入されたことは別の話だ。
今回の俺のブログでも、設定ファイルを探すようなアクセスは確認できたが、侵入成功を示す証拠は見つからなかった。
ただし、アクセスログだけで完全に安全だと証明できるわけでもない。
サイトが改ざんされていないか確認するには？
WordPress内に覚えのない管理者アカウントが追加されていないか、知らないプラグインや記事が増えていないかなどを確認する方法がある。
また、Google Search Consoleの「セキュリティの問題」レポートでは、Googleが検出した不正なコンテンツなどを確認できる。
ただし、このレポートで問題が検出されていなくても、すべての侵害が否定されるわけではない。
実際に被害が見つかったら？
まずはサーバー会社に連絡し、状況の確認と被害拡大を防ぐ対応について相談する。
必要に応じてサイトの公開を一時的に制限したり、管理者アカウントの保護、ログの保存、不正なファイルの調査などを行う。
原因を調べずにバックアップだけ戻しても、同じ弱点が残っていれば再び侵入される可能性がある。
無理に一人で解決しようとせず、サーバー会社や専門家に相談するのが現実的だろう。
まとめ｜小さな個人ブログも、攻撃者から見ればインターネット上の一つのサーバー
今回のPHP脆弱性のニュースを見たとき、正直、最初は自分にどれほど関係がある話なのか疑問だった。
企業ならともかく、個人ブログなんて攻撃しても仕方ないだろうと。
でも、調べてみると少し違った。
攻撃者は必ずしも俺のブログそのものに価値を感じているわけではない。
使えるサーバーが一つ増えれば、それでいい場合もある。
実際にアクセスログを確認すると、短時間に大量のファイルを探る不審な通信が記録されていた。
幸い、今回の調査で侵入成功を示す証拠は見つからなかった。
それでも、小さな個人ブログだから誰にも狙われない、という考えは改める必要がありそうだ。
さらに、今後はAIによって脆弱性の発見や攻撃方法の研究が効率化されていく可能性もある。
もちろん、守る側もAIを使える。
攻撃と防御の競争はこれまで以上に速くなるのかもしれないし、反対に、AIによって重大な問題を事前に解決できる機会が増えるのかもしれない。
俺には、その未来がどうなるかまでは分からない。
ただ、一つ言えるのは、インターネット上にサイトを公開している以上、その規模に関係なく、こうした問題と無関係ではいられないということだ。
映画を見て感想を書いて、気に入ったガジェットをレビューする。
ただそれだけのつもりだったんだけどな。
ずいぶん物騒な世界に店を構えてしまったらしい。
ちなみに、俺が使っているエックスサーバーはどう対応した？
【PR】この章にはアフィリエイト広告を含みます。
最後に、俺が実際にブログ運営で利用しているエックスサーバーの話をしておきたい。
今回のPHPの重大脆弱性では、エックスサーバーも緊急対応に追われることになった。
公式発表によると、修正版が公開される前から予防的な対策を進め、10月21日16時には管理画面などを一時停止。
一方で、利用者が公開しているWebサイトは稼働を継続していた。
そして、修正版が公開された翌22日には、PHPの各バージョンへの修正適用を進めている。
| 日時 | エックスサーバーの対応 |
|---|---|
| 10月21日12時まで | 修正版公開前の予防的対策を実施 |
| 10月21日16時 | 管理画面などを一時停止 |
| 10月22日6時45分 | PHP 8.2〜8.5の修正適用完了 |
| 10月22日12時 | PHP 7.4〜8.1の修正適用完了 |
| 10月22日14時 | PHP 5.6〜7.3の修正適用完了 |
さらに、古いPHP 5.1〜5.5についても独自の修正パッチの適用を進めていた。
※上記は一般的なレンタルサーバーサービスについての対応。VPSなど、自分でPHPを管理するサービスは対応方法が異なる。
何もしないうちに修正されていた
俺の場合、PHPの脆弱性が話題になってから自分のブログを調べたところ、すでにエックスサーバー側で修正が適用されていた。
管理画面で確認したPHPのバージョンは8.2.35。
今回の脆弱性に対応した修正版だ。
もちろん、今回の対応が早かったからといって、今後すべての問題を自動的に解決してくれるとは限らない。
実際にWAFの設定を確認してみると、俺のブログでは6項目すべてがOFFになっていた。
そこは今回、自分でONに変更している。
サーバー会社が対応してくれる部分と、自分で管理しなければならない部分は別ということだ。
それでも、今回のような重大な問題が発生したときに、利用者側でPHPの修正作業をしなくても対応してもらえたのはありがたかった。
正直、俺が自力でPHPの修正パッチを当てろと言われても困る。
ブログを書きたいのであって、サーバーの保守を仕事にしたいわけではないからだ。
これからWordPressを始めるなら
今回の一件で、レンタルサーバー選びは料金や速度だけではないんだなと改めて思った。
何か問題が発生したとき、運営会社がどう動くのか。
普段はあまり意識しない部分だけど、長くブログを続けるなら無視できないポイントだろう。
もちろん、エックスサーバーを使えば絶対に安全ということではない。
それでも、今回の具体的な対応を見た限り、俺はこれからも使い続けるつもりだ。
これからWordPressを始める人や、レンタルサーバーの乗り換えを考えている人は、候補の一つとして確認してみてもいいと思う。
