「PHP2shell」素朴な疑問に答えます。Q&A編

・こちらの記事を公開してから、皆様よりメール、SNS等でいくつも質問をいただきました。そこで、実際に聞かれたことと、聞かれそうなことを一問一答にまとめます。

・加筆をくり返しているために情報量が増え、九龍城砦のようになりつつあります。

・まずはこちら（Q.今後どのようなことが起こりそうなの？）をお読みいただくとお役に立てるかもしれません。

・頭から読む必要はありません。完読すると30分弱かかると思います。気になる質問だけ拾い読みしてください。

・なお、PCブラウザからご覧いただきますと、左側にQ&Aが一覧表示されるので便利です。

・お問い合わせも引き続き承っております。こちら

・まったく「素朴」ではなく、複雑怪奇になっている部分もありますが、このまま掲載します。皆様からの真摯な質問のおかげです。ありがとうございます。

※2026年10月24日15:00最終更新

基礎編：そもそも何の話？

今回の事案の概要

2026年10月、世界中のウェブサイトの多くを動かしている「PHP」というプログラミング言語に、重大な欠陥が2件見つかりました。通称「PHP2shell」と呼ばれるものです。ログインもパスワードもなしに、外部からサーバーを乗っ取られるおそれがありました。極めて危険性の高いものです。

発表前に情報が漏れたため、国内でも10月21日午後から22日朝にかけて、銀行や鉄道、ゲームなどのサービスが、予防のために相次いで止まりました。修正版は日本時間21日の23時ごろに公開されています。実際の攻撃も観測されており、対策はPHPを修正版に更新することです。

Q.そもそもPHPってなに？

A.動的なWEBページを作り出す言語です。簡単にいうと「ホームページを、見られた瞬間に組み立てる」ためのプログラミング言語です。

ブログやネットショップの多くは、誰かがページを開いた瞬間に、サーバー（ホームページを置いておくコンピューター）が記事の文章や商品情報を取り出して、一枚のページに組み立てています。この組み立て係がPHPです。

ウェブサイトは、プログラミング言語を使って組まれます。ちなみに、Webサイトなどをコードを使って組み上げることを「書く」と表現したります。

この、書かれた言語がわかっているウェブサイトのうち、約7割がPHPで動いているとされます。WordPressなど、有名なCMS（専門知識がなくてもサイトを更新できるシステム）の多くも、このPHPで作られています。今回の騒ぎが大きくなったのは、この普及率の高さのためです。

Q.「PHP2shell」の「shell」ってなに？

A.「シェル」とは、コンピューターに直接命令を打ち込むための窓口のことです。

「2」は英語の「to」と同じ発音を利用した表記で、「PHPを入口にして、サーバーの命令窓口までたどり着ける欠陥」という意味の通称です。窓口を取られると、攻撃者はサーバー上で好きなプログラムを動かせます。専門用語では「リモートコード実行」と呼ばれ、欠陥の中でも最も重い部類に入ります。

しかも今回は、ログインもパスワードも要りませんでした。インターネットからサーバーに届きさえすれば、攻撃が成立しうる欠陥だったのです。

Q.エンジニアって、事件の名前まで小難しい暗号みたいにするよね。もっとわかりやすくできないの？

A.お気持ち、よくわかります。ただ、実は「PHP2shell」という名前そのものが、わかりやすくしようとした結果なのです。

今回の欠陥の正式な名前は、「CVE-2026-109618」と「CVE-2026-109619」です。CVEとは、世界中の欠陥（脆弱性）に割り振られる共通の管理番号のことです。番号なら、世界のどこで、どの言語で話しても取り違えません。正確ではありますが、人間が完璧に覚えるのは不可能に近いです。

そこで、深刻な欠陥には、覚えやすい通称が付けられるようになりました。2014年の「Heartbleed（ハートブリード）」や、2021年の「Log4Shell（ログフォーシェル）」が有名です。「PHP2shell」もその流れで、「PHPから、サーバーの命令窓口（シェル）までたどり着ける欠陥」という意味を、ひと言に詰め込んだものです。発見者たちは、ロゴまで作っています（しかも、これが結構カッコ良かったりします）。ふざけていると感じる方もいるかもしれませんが、この業界の人たちは、対応で疲弊しきってしまうことが多々あります。多少の遊びは、大目に見てあげてください。

とはいえ、英語とカタカナの組み合わせが、専門外の人にとって壁になっているのも事実です。その壁を越えて、意味を伝えるのが、私のような仲介役の仕事だと思っています。あえて日本語にするなら、「PHP乗っ取り欠陥」あたりでしょうか。この記事が、その翻訳の役目を少しでも果たせていればうれしいです。

Q.「CVE」とは？

CVE＝「Common Vulnerabilities and Exposures（共通脆弱性識別子）」：脆弱性はさまざまなプログラムに数多く存在します。そのため、脆弱性を混同してしまう危険性があります。脆弱性やインシデント（事象）に固有の番号を各1つだけ、共通のルールに従って割り振ることで、混同を未然に防ぐ仕組みとなっています。たとえプロであっても、こうした識別が正しく認識できていなければ、適切な対応方法がわかりません。また、これは極端な例ですが、新しいバージョンに古い対策を施してしまうことも考えられます。慣れれば、パッと見るだけで事象の発生時期、発生が起きた後なのか？これから起こりうるのか、古いのか新しいのか？…等をひと目で判別できます。

（例）CVE-2026-109618：

・「CVE」＝確定した脆弱性（可能性止まりの場合は「CAN」と表記）

・「2026」＝確定した西暦

・「109618」＝連番

Q.自分のサイトにPHPが使われているかどうか、どうやって見分ける？

A.見た目だけでは判断できません。確かめ方は次の3つです。

制作を頼んだ人や会社に聞く：いちばん確実です
CMSで更新しているか：WordPressなどで記事を更新しているなら、ほぼ確実にPHPが動いています
レンタルサーバーの管理画面を見る：「PHPのバージョン設定」といった項目があれば、PHPが使える状態です

なお、ホームページ作成サービスやネットショップ作成サービスで作ったサイトは、サーバーの管理を運営会社が担っています。利用者が自分で何かをする場面は、基本的にありません。運営会社のお知らせだけ確認しておけば十分です。

Q.サイトを所有せず「ただ利用するだけ」の人にも関係ある？

A.直接何かをする必要はありません。ただし、無関係とも言い切れません。

普段使っているサービスがPHPで動いていた場合、そこに預けた情報が盗まれた可能性はゼロではないからです。今回の欠陥では、サーバー上に残った情報、たとえばパスワードや認証情報を盗み見られるおそれも指摘されています。

できることは次の3つです。

利用しているサービスから「お知らせ」や「パスワード再設定のお願い」が届いたら、公式サイトで確かめてから従う。真偽がわからない場合、そのサービスのガイドラインをよく読むか、問い合わせる。たとえば、各社ガイドラインには「弊社からお客様に⚪︎⚪︎の情報をお送りしたり尋ねたりすることはありません」と書かれていることがあります
同じパスワードを複数のサービスで使い回しているなら、この機会に変える
便乗した詐欺メールに注意する。「脆弱性対応のため、こちらからログインしてください」といったメールのリンクは開かず、公式アプリやブックマークからログインする

騒動編：何が起きたの？

今回の騒動の流れ（日本時間）

2024年：PHPの外部監査をきっかけに、欠陥の兆候が見つかる。悪用の方法は証明されず、修正は見送られる
2026年8月：複数の研究チームが、AIも使って、実際に悪用できることを突き止め、開発チームに報告
10月21日未明：発表前に欠陥の識別番号がネットに出回る（筆者も「X」上で確認）。開発チームは修正版の公開を1日前倒しすると予告
10月21日午後：国内のサービスが、予防のために相次いで停止
10月21日 23時ごろ：修正版を公開
その後：海外のセキュリティ企業が、実際の攻撃を確認

発表前後のより詳しい経緯は、本編の時系列をご覧ください。

※協定標準時で統一するのが適当ですが、本記事の特性上、日本時間に統一します

Q.なぜ銀行や鉄道まで一斉に止まったの？被害を隠しているんじゃないの？

A.被害が出たからではなく、「やられる前に止めた」からです。

PHPはあまりに広く使われているため、大きな会社ほど、どのシステムのどこでPHPが動いているかを即座に把握しきれません。確認が終わるまで止めておくのが、いちばん確実な守り方でした。イギリスの政府機関も、すぐに更新できないシステムは更新できるまでネットから切り離すよう呼びかけています。

メンテナンス画面を見て不安になった方も多いと思いますが、あれは「店が燃えた」のではなく「消防点検のための臨時休業」に近いものです。とくに鉄道・電気・水道などのインフラや銀行は国民の生命・財産に直結するものです。彼らが予防的措置を速やかに講じることは、極めて妥当な判断だと思います。

Q.「情報が先に漏れた」とはどういうこと？

A.本来は、修正版の公開と欠陥の発表を同時に行う段取りでした。

欠陥を見つけた研究者は、まず開発チームにだけこっそり知らせます。開発チームは修正版を準備し、公開と同時に欠陥の中身を発表します。こうすれば、攻撃者が中身を知った時点で、守る側はもう直す手段を持っています。これを「協調的開示」と呼びます。

今回は、この段取りが崩れました。10月20日、発表前に欠陥の情報が外部に漏れ、攻撃用とみられる道具まで出回ったのです。守る側は、修正版が出る前から身構えるしかありませんでした。

Q.実際に被害は出たの？

A.攻撃は実際に始まっています。ただし、どれだけのサイトが被害を受けたかは、まだわかっていません。

修正版の公開前から、攻撃とみられる通信が観測されていました。公開後には、海外のセキュリティ企業が、2つの欠陥の両方を悪用した攻撃を確認したと報告しています。一方、国内で具体的な被害の発表は、10月23日朝時点で私が確認した範囲では見当たりません。

侵入されても、すぐには表に出ないことがあります。被害の全体像が見えてくるのは、これからだと考えておいたほうがいいでしょう。

Q.古いバージョンのPHPなら、攻撃対象外なの？

A.逆です。古いほど危険です。

今回の欠陥は、2012年に出たPHP 5.4以降、ほぼすべてのバージョンに潜んでいました。

しかも、8.1以前の古い系列には、PHPの公式から修正版が出ていません。専門家が自分で組み立て直すための最小限の修正は用意されましたが、レンタルサーバーで使っている一般の方には現実的ではありません。古い系列を使っているなら、修正版のある新しい系列（8.2以降）に切り替えるのが答えです。

※ただし、いきなり大幅なアップデートを行うと、機能が消えてしまったり、挙動がおかしくなることもあります。「バージョン5」から「バージョン8」へのアップデートは、相当な負荷がかかると思います。最悪、サイトがクラッシュすることも考えられます。また、「バージョン5までしか対応していません」とうたう機能を、バージョン６以上には適応することはできません。自信のない方は、まずはサイトを作った方に相談することをおすすめします。

Q.AIの発展と関係があるの？AIのせいで起きたことなの？

A.無関係ではありません。ただ、「AIの発展による影響か」と言うと、半分しか合っていません。

経緯を整理すると、こうなります。

欠陥そのものは、10年以上前からPHPの中にありました
2020年と2024年にも、関連する兆候は報告されていました。しかし、実際に悪用できるとは証明されず、修正は見送られていました
悪用するには、いくつもの欠陥を複雑に組み合わせる必要がありました。人間の研究者だけでは、ほぼ現実的ではない難しさだったのです
今回、研究チームは最先端のAIを使い、その組み合わせを実際に動く形にしてみせました。研究チームによれば、一流のチームが数か月かける作業を、1人の研究者がAIとともに1週間で終えたといいます

つまり、AIが変えた（崩した）のは「欠陥の有無」ではなく、「複雑すぎて誰も悪用できないから、事実上安全」という前提です。この前提は、もはや通用しません。攻撃する側も、同じ道具を使えるからです。

一方で、今回この欠陥を見つけ、開発チームと一緒に直したのも、AIを使った善意の研究者たちでした。AIは攻撃にも防御にも使える道具で、本編に書いたとおり、問われるのは使う側の人間です。

個人的に興味深かったのは、発見者自身の振り返りです。AIは、20年前の目立たない欠陥から探し始めるようにはできていない。その分野の過去の欠陥の歴史を知っていた人間が、探す方向を示したから見つかった、というのです。AIの時代にも、先人の仕事を知っていることの価値は消えない。むしろ増しているのかもしれません。

Q.エンジニアやセキュリティの担当者が世界中にこれだけいるのに、なぜこんな事態になったの？

A.理由は大きく3つあると思います。

1つ目は、PHPという仕組みの性質です。

PHPは、特定の大企業の製品ではありません。誰でも無料で使えるオープンソースのソフトウェアです。世界中のウェブサイトを支えている一方で、その中核部分を深く理解し、安全を守る作業は、財団に雇われた少数の開発者とわずかなボランティアが担っています。

しかも今回の欠陥は、ほぼすべての処理が通る「メモリの管理」と「エラーの処理」という、根っこの部分にありました。2024年の外部監査をきっかけに兆候は見つかっていました。しかし直し方によっては、世界中の既存のサイトや拡張機能が動かなくなるおそれがありました。少人数のチームがどの直し方を選ぶか決めきれないまま、修正は何か月も止まっていたといいます。財団はこれを「構造的な失敗」だったと率直に認めています。

使う人は世界中に数えきれないほどいても、土台を直せる人はほんの一握り。これが、オープンソースが抱える構造的な弱点です。

2つ目は、AIによる攻撃の加速が、予想を上回る速さで現実になったことです。

予兆はありました。2026年4月、Anthropicは「Claude Mythos Preview」というAIモデルを発表しました。ソフトウェアの欠陥を見つけて悪用する能力で、ごく一部の熟練者を除く人間を上回るとされ、同社は一般公開を見送りました。そのうえで、大手IT企業などと防御のための取り組み「Project Glasswing」を立ち上げています。AIを悪用した、想像を超える攻撃が起こりうる。この予測は、この時点で業界に共有されていました。

PHPの開発陣も、手をこまねいていたわけではありません。今年に入ってからAIを使ってPHPの欠陥を洗い出し、5月にはセキュリティ専門のチームを新設して、人員も増やしていました。今回の欠陥が見つかったのも、そうした取り組みの延長線上です。それでも、準備を上回る規模と速さで事態が起きた、というのが実情だと思います。

3つ目は、日本の場合、国としての備えが整いはじめたばかりだったことです。

重大なサイバー攻撃に国が先手を打って対処する「能動的サイバー防御」の法律は、2025年5月に成立しました。運用が始まったのは、今年の10月1日です。今回の騒ぎの、わずか3週間前のことでした。

しかも、この法律が主に想定しているのは、電力や通信などの基幹インフラです。地域の小さな事業者や団体のサイトは、これからも基本的には自分たちで守るしかありません。国としてサイバーセキュリティに予算と人材を割いてこなかったツケが、こうした形で表れたとも言えるでしょう。

対策編：何をすればいいの？

Q.今後、どのようなことが予想されるの？

A.不安をあおるつもりはありませんが、心の準備として、次のようなことは起こりうると考えています。それぞれ、そう考える理由と、そのときにできることを添えます。

1. いつも使っていたサイトが、突然メンテナンスに入る｜一部のサービスが使えなくなる

各社の調査や更新は、しばらく続きます。侵入の形跡が見つかったサービスは、確認のためにいったん止まることもあるでしょう。慌てずに、公式のお知らせを待ってください。なお、そのようなサイトやサービスは対策の不備があったから止まったのだ、とは必ずしもいえません。予防的措置としてサイトの一時停止やメンテナンスに入ることは、妥当な判断だと思います。

実際に、お問い合わせや商品検索などの一部機能を停止しているサイトがあるようです。

2. 被害の発表が、あとから出てくる

侵入は、気づかれるまでに時間がかかることがあります。数週間から数か月たってから、「個人情報流出のお詫び」や「パスワード再設定のお願い」が届くかもしれません。届いたら、公式サイトで確かめてから従ってください（もしくは当記事内「サイトを所有せず、ただ利用するだけの人にも関係がある？」の質問をご参照ください）。

3. 便乗した詐欺メールや偽サイトが増える

世間の騒ぎに便乗するのは、詐欺の常套手段です。「脆弱性対応のため、ログインしてください」といったメールのリンクは開かず、公式アプリやブックマークから確認してください。

4. 放っておかれたサイトが、狙われ続ける

修正版の出ていない古いPHPのまま動いているサイトは、まだ数多く残っています。こうしたサイトは乗っ取られて、訪れた人を偽サイトへ誘導する踏み台にされることもあります。自分のサイトがそうなっていないか、この機会に確かめてください。

5. 追加の修正版が出る可能性がある

発見者自身が、同じ種類の欠陥がほかにも潜んでいると書いています。今回の修正版はその根本を直したとされていますが、更新は一度で終わりとは考えず、サーバー会社や制作者からのお知らせに注意を払い続けてください。

6. 「今すぐ乗り換えを」という営業が増える

混乱は、商売の機会にもなります。急かされたら、一度立ち止まってください。乗り換えが必要かどうかは、今のサイトの手入れの状態を確かめてから判断しても遅くありません。

AIによって、欠陥が見つかる速度は確実に上がっています。こうした更新や注意喚起は、これから特別な事件ではなく、日常の一部になっていくはずです。季節の衣替えのように、慌てず、定期的に付き合っていくものだと考えておくと、少し気が楽になると思います。

Q.WordPressやプラグインを最新にすれば大丈夫？

A.いいえ。今回それでは直りません。

欠陥があったのはPHPそのものです。その上で動くWordPressやプラグインをどれだけ新しくしても、PHPの欠陥は直りません。直すべきは、PHPのバージョンです。

もちろん、CMSやプラグインを最新に保つこと自体は、普段から大切です。今回の対策とは別の話、というだけです。

Q.レンタルサーバーを借りているなら、自分は何もしなくていい？

A.PHP本体の修正は、基本的にサーバー会社の仕事です。ただ、確かめてほしいことが2つあります。

サーバー会社のお知らせを読む：対応が済んでいるか、利用者側で必要な作業があるかが書かれています
管理画面で、自分が選んでいるPHPのバージョンを見る：多くのレンタルサーバーでは、利用者がバージョンを選べます。8.1以前を選んだままなら、修正版のある8.2以降に切り替えが必要です

対応が済んでいれば、バージョンは「8.5.12」「8.4.27」「8.3.36」「8.2.35」のいずれか、またはそれ以降になっているはずです。

なお、バージョンを切り替えると、古いサイトでは表示が崩れることがあります。制作を頼んだ人がいるなら、相談してから進めると安心です。

ネット上には「設定ファイルを書き換えれば防げる」という情報も出回りました。しかし専門家は、設定の変更では攻撃を防げないと指摘しています（筆者も試しました）。確実な対策は、修正版のPHPに入れ替えることだけです。

Q.サイトがもう既に乗っ取られていないか不安。どう確かめればいい？

A.まず知っておいてほしいのは、PHPを修正しても、すでに仕込まれた裏口は消えないということです。

修正版は、これから入られないための対策です。修正前に侵入されていた場合、攻撃者が残した「裏口」はそのまま残ります。次のような兆候がないか、確認してください。

管理画面に、見覚えのない管理者アカウントが増えていないか
サーバー上に、見覚えのないファイルが増えていないか
サイトを開くと、勝手に別のページに飛ばされないか
検索結果に、身に覚えのない商品名や怪しい文言が表示されていないか
サーバー会社から、ウイルスや改ざんの警告メールが届いていないか

また、今回の欠陥ではサーバー上のパスワードを盗み見られたおそれもあります。修正が済んだら、念のため管理画面やサーバーのパスワードを変えておくと安心です。

もし怪しいものを見つけたら、自分で消そうとしないでください。何が起きたかを調べるための記録まで消えてしまうことがあります。制作を頼んだ人か、サーバー会社に相談するのが先です。

Q.個人情報が漏れてしまった場合、どう動けばいい？

こちらの回答は、お問い合わせフォームや会員登録、ネットショップなどで、お客さんの個人情報を預かっているサイトの運営者向けにお答えします。

A.大まかな流れは次の5段階です。

被害の拡大を止める：サイトを止める（メンテナンスモードではなく、サーバーの入口で止める）。管理画面やサーバーのパスワードを変える
記録を残す：いつ、誰が、何に気づいたかをメモする。サーバーを初期化したり、怪しいファイルを消したりしない
専門家に相談する：制作者やサーバー会社に連絡する。不正アクセスの場合は、IPA（情報処理推進機構）の相談窓口や警察の相談窓口も使えます
国への報告が必要か判断する：下で詳しく説明します
お客さんに知らせる：何が起きたか、どの情報が漏れたか、原因、二次被害のおそれ、問い合わせ先を伝えます。連絡先がわからない場合は、サイト上での公表と問い合わせ窓口の設置で代えることができます

国への報告について

個人情報保護法では、次の4つのどれかに当てはまる漏えいは、個人情報保護委員会への報告と、本人への通知が義務になっています（個人情報保護委員会「漏えい等の対応とお役立ち資料」）。

病歴や健康診断の結果など、特に配慮が必要な情報が含まれる
クレジットカード番号など、悪用されるとお金の被害が出るおそれがある
不正アクセスなど、悪意のある第三者の行為によるもの
漏えいした人数が1,000人を超える

大事なのは3つ目です。不正アクセスによる漏えいは、件数が1件でも報告の対象になります。しかも、漏えいが確定していなくても、「漏れたおそれがある」段階で対象です。PHP2shellで侵入された場合は、ほぼこれに当たると考えてください。

また、この義務は会社の規模を問いません。個人事業主や小さな団体でも、事業として個人情報を扱っていれば対象になります。

報告の期限は2段階です。

速報：気づいてからおおむね3〜5日以内。わかっている範囲で構いません
確報：気づいてから30日以内。不正アクセスなど悪意による場合は60日以内

報告は、個人情報保護委員会のウェブサイトにある報告フォームから行います（業種によっては、別の省庁が窓口になります）。判断に迷ったら、委員会の「個人情報保護法相談ダイヤル」（03-6457-9849）に相談できます。

なお、2026年7月に公布された改正法で、この報告や通知のルールは一部見直される予定です。ただし施行は公布から2年以内とされており、それまでは現行のルールで動く必要があります。

※私は法律の専門家ではありません。具体的な判断は、個人情報保護委員会や弁護士にご確認ください。

Q.静的サイトに乗り換えるべき？ PHPはもう使わないほうがいい？

A.事業の性格によります。PHPを捨てれば解決、という話ではありません。

更新がほとんどない会社案内や名刺代わりのサイトなら、静的サイトは合理的な選択肢です。PHPのような仕組みをそもそも動かさないので、手入れの手間もリスクも減ります。ただし、更新の手間がかかるのと、専門知識がそれなりに必要です。

一方、会員登録、予約、ネットショップのように、注文に応じて中身が変わるサイトには、その場でページを組み立てる仕組みがどのみち必要です。PHPを別の言語に替えても、どの言語にもいつか欠陥は見つかります。大事なのは、更新を続けられる体制があるかどうかです。

それに、今回PHPの開発チームは、深刻な欠陥を短期間で直してみせました。これは「PHPは危ない」ではなく、「手入れさえ続ければ守れる」ことの証拠でもあります。

「PHPは終わり」「今すぐ乗り換えないとサイトが消える」と急かす声には、少し距離を置いてください。慌てて乗り換えるより、まず今のサイトの手入れが行き届いているかを確かめるほうが先です。

Q.それなら、管理を丸ごと任せられる大手のサービスに移ったほうがいい？自分でサイトを持つのは、リスクでしかないの？

A.どちらか一方が正解、という話ではないと思います。私は「バランス」が大切だと考えています。大手のサービスも、自分のサイトも、一長一短です。

大手のサービスに任せる場合

ホームページ作成サービスやネットショップ作成サービスなどでは、サーバーの管理やセキュリティの更新を、運営会社が引き受けてくれます。今回のような欠陥が見つかっても、利用者が夜中に対応に追われることは、基本的にありません。手入れの担い手がいない小さなお店や団体にとっては、合理的な選択です。借家に例えるとわかりやすいかもしれません。

ただし、そこは、あくまでも「借りている場所」です。料金の値上げ、機能の廃止、デザインの制限、規約の変更。運営会社のルールが変われば、利用者は従うしかありません。アカウントが止められたり、サービスそのものが終わったりすることもあります。成長を求められる会社ほど、最初は使う人に優しく、やがて条件が厳しくなっていく傾向があり、「プラットフォームの劣化」と呼ばれることもあります（本当はもっと下品な表現なのですが、ここでは変えて表現します）。

自分でサイトを持つ場合

自分のサイトは、いわば「自分の家」です。ルールは自分で決められ、書いたものも預かった情報も、手元に置いておけます。長く続けるほど、資産として積み上がっていきます。

その代わり、手入れの責任も自分に返ってきます。今回の騒ぎは、まさにその責任が、一番わかりやすい形で表に出た出来事でした。

私が大事だと思っていること

つまり、どちらを選んでもリスクはゼロになりません。大手に移っても、頼る先が変わるだけです。そのうえで、私は次の2つを大切にしています。

原本は自分の手元に置き、大手のサービスは「支店」として使う：自分のサイトに原本を置き、SNSや大手のサービスには、その写しや入口を置く。海外では「POSSE（自分のサイトで発表し、ほかの場所に配る）」という考え方として知られています
データを持ち出せるかどうかを、必ず確かめる：どのサービスを使うにしても、書いたものや顧客の情報を、いつでも別の場所へ持ち出せるか。これが、いざというときの出口になります

どちらが合うかは、手入れをしてくれる人がいるか、どれくらいの頻度で更新するか、どんな情報を預かるかで変わります。大切なのは、便利さと引き換えに何を預けているのかを、わかったうえで選ぶことだと思います。本編の最後に書いた「一か所に預けすぎない」という話と、根っこは同じです。

Q.WordPressは、もうやめたほうがいいの？

A.今回の件だけを理由にやめる必要はない、と私は考えています。

まず、今回欠陥があったのはPHPであって、WordPressではありません。WordPressは、世界中のウェブサイトの4割以上で使われているとされる仕組みです。今回もWordPressを開発する会社は、修正版の準備や対策の段階から関わっていました。利用者が多いぶん狙われやすいのは事実ですが、そのぶん守る人の数も多いのです。

ただ、見直したほうがいいサイトもあります。次のような状態なら、この機会に、使い続けるか、手入れの要らない仕組みに移るかを考えてみてください。

更新や見守りをする人が、誰もいない
何年も前に入れたまま、使っていないプラグインがたくさん残っている
PHPが8.1以前の古いバージョンのまま
そもそも、ほとんど更新していない

続けるなら、大切なのは次の3つです。WordPress本体とプラグインを更新し続けること。プラグインを必要なものだけに絞ること。そして、誰がサイトを見守るのかを決めておくことです。

道具に良し悪しがあるというより、手入れできる体制に合った道具を選べているか。問われているのは、そこだと思います。

Q. わからないことは、AIに聞けばいいよね？

A.基本的には、それでも構いません。最近のAIの性能向上は目覚ましく、検索エンジンに代わる集合知として機能しているともいえます。「PHPとは何か？」「自分のサイトのバージョンをどこで確かめるか」、「制作者にどう連絡すればいいか？」。こうしたことを聞くには、AIはとても頼りになる相手です。

ただ、今回のような事態では、気をつけてほしいことが4つあります。

AIは、最新の出来事を知らないことがある：AIの知識は、ある時点で止まっています。検索機能のないAIに聞くと、今回の欠陥そのものや、修正版のバージョン番号を知らないまま、もっともらしく答えることがあります。答えの根拠になった情報源を示してもらい、公式の発表と照らし合わせてください。
AIは、自信満々に間違えることがある：今回も、「設定を書き換えれば防げる」という対策がネットで広まりました。専門家はのちに、それでは防げないと指摘しています。AIが同じ誤りを繰り返すこともあります。
AIは、あなたのサイトの中を見られない：AIが「大丈夫です」と答えても、それはあなたのサイトを実際に調べた結果ではありません。確認と作業は、最後は自分か、制作者やサーバー会社の手で行う必要があります。
パスワードや個人情報をAIに貼り付けない：サーバーのログイン情報や、お客さんの個人情報を含むファイルを、そのままAIに渡すのは避けてください。

AIは、優秀な相談相手です。ただし、判断の責任までは引き受けてくれません。特に、個人情報の報告のように法的な義務が絡む判断は、公式の情報で確かめるようにしてください。

また、凝ったプロンプトを書いている時間的猶予などないケースも今後出てくることが考えられます。最終的にはプロフェッショナルによる迅速で責任ある判断が必要とされるのは今後も揺るがないことだと思います。

現場編：制作者が今回よく現場で聞かれていること

Q.保守プランには入っていなかったけど、あなたに作ってもらったのだから、今回の対策を頼めない？

A.頼むこと自体は自由です。ただ、身も蓋もない言い方になりますが、制作者に引き受ける義務はない、というのが一般的な考え方ではないかと思います。

理由の一つは、制作と保守が別の契約だからです。制作の契約は、約束したサイトを作って納めるところまで。納品後の更新や監視、緊急時の対応は、保守契約で別に引き受ける仕事です。家を建てた工務店に、その後の点検や修理まで無償で求めることができないのと同じです。

もう一つは、今回の欠陥が、制作者の作ったものの不具合ではないことです。世界中のサイトが使っているPHPそのものに、10年以上前から潜んでいた欠陥です。納品されたサイトの出来とは関係がありません。

保守契約を結んでいる制作者は、こうした事態に備えて、日頃から時間と体制を確保しています。厳しい言い方になりますが、その費用を負担していない人が、負担している人と同じ対応を当然のように求めるのは、筋が違うと言わざるを得ません。契約のある顧客への対応が後回しになりかねず、誠実な制作者ほど板挟みになります。

もちろん、制作者が好意で、あるいは有償のスポット対応として引き受けることはありえます。その場合も「作ったのだからやってもらって当然」ではなく、改めて依頼し、費用を相談すると、建設的な関係が維持できると思います。

これからサイトを作る方は、制作を頼む段階で「納品後、誰がこのサイトを見守るのか」を決めておいてください。保守契約は、何かあったときの保険というより、見守り役を決めておくことです。

Q.制作を頼んだ人と連絡が取れない。どうすればいい？

A.まず、サーバーとドメインが「誰の名義」で契約されているかを確かめてください。

契約書や請求書、当時のメールを探す：サーバー会社とドメインの契約者が誰かがわかります
自分の名義なら：サーバー会社の管理画面に自分でログインできるか確かめ、サーバー会社のサポートに相談できます。PHPのバージョン確認や切り替えも、自分で、または別の制作者に頼んで進められます
制作者の名義なら：かなり難しくなります。サーバー会社は、原則として契約者本人以外の依頼には応じられないからです

どちらの場合も、別の制作者に相談するなら、サーバーやサイト管理画面のログイン情報が必要になります。

今回の件の教訓として、サーバーとドメインはできるだけ自分の名義で契約し、ログイン情報は自分の手元でも保管しておくことをおすすめします。サイトの鍵を制作者だけが持っている状態は、思っている以上に危ういのです。

Q.Webの現場にいて、今回の件をどう見ている？

A.筆者は40代前半です。気づけば15年以上現場にいるのですが、正直に言えば、PHPでここまでの事態（全世界規模の緊急脆弱性の発見）を実際に経験したのは初めてでした。何度もこうした危機を切り抜けてきたわけではありません。

企業在籍時、とくに新入社員時代に、過去に起きた重大インシデントや起こりうる事象、それに対するシミュレーションなどは、座学で学んでいました。しかし今回は、その想定を超える規模で、しかも対応までの時間的猶予が非常に少なかった。いちばん驚いたのはそこです。

今回、情報が漏れてから、攻撃が観測されるまで、ほとんど時間がありませんでした。これまでなら「重大な欠陥が見つかったので、週末までに更新しましょう」で間に合っていたものが、「今夜中に」になった。前のAIの質問で触れたとおり、攻撃する側の準備にかかる時間が、劇的に短くなっているからです。

良くない例え方になりますが、いきなり上空に爆撃機が出現したかのような気分でした。急いで戦闘機に飛び乗り、エンジンを回し、飛び立った…という感じでした。キャノピーは開けっぱなし。弾薬や燃料の積み込みも不十分。気付かぬうちにびっしりと汗をかいていることを認識したのは、日本時間21日午後11時前後の「運命の15分間」が過ぎて１時間ほど経った後、深夜1時ごろ。…こんな感じでした。そして結局、爆弾が落とされたのか、被害があるのか、そうしたことも、その日のうちには分からずじまい。この暗闇の中ではまったく現状が掴めない。朝日がのぼるのを待つしかない…。

ここまでの緊張感は今まで経験したことがありませんでした（現在50代以上の先輩方はおそらく何度かご経験があったかと思います。尊敬しています）。

…さて、こうなると、Webサイトは「作って終わりのもの」ではいられません。手入れし続ける前提で作り、手入れし続ける人を決めておく必要があります。

気がかりなのは、小さなお店や団体のサイトです。大企業には担当部署があります。しかし、地域の小さな事業者や団体のサイトは、作った人が離れたあと、誰も中身を見ていないことが少なくありません。今回、私自身もそうしたサイトの対応に追われました。

本編の追記でも書きましたが、これは個々の運営者の怠慢というより、社会全体で手入れの担い手を育ててこなかった結果だと思います。今回の騒ぎが、「サイトは誰が守るのか」「そもそも、ウェブサイトとは」を考えるきっかけになればと思います。

Q.こうした解説記事が積み重なると、悪意のあるAI利用者に学習されて、かえって攻撃の役に立ってしまわない？

A.非常にいい質問です。今回のような記事が攻撃者の役に立つおそれは、ほぼないと考えています。

理由は、攻撃者が欲しい情報と、この記事に書いてある情報が、まったく違うからです。攻撃者が知りたいのは、「どの処理をどの順番で突けば乗っ取れるか」といった技術の中身です。それは発見者たちがすでに、この記事とは比べものにならない深さで公開しています。一方、この記事に書いてあるのは、「PHPを更新しよう」「乗っ取られていないか確かめよう」「パスワードを変えよう」という、守る側の基本動作です。泥棒に「戸締まりをしましょう」というチラシを渡しても、泥棒が得をすることは（よほどの場合を除いて）ありません。玄関や窓の鍵がちゃんと閉まっているのを知っているからです。

セキュリティの世界でも、「どこまで情報を公開すべきか」は長く議論されてきたテーマです。戸締りの例え話で言えば、たとえば「ベストセラーの監視カメラに構造的欠陥が見つかった」とします。その事実を公表する方法や日時を間違うと、隙をつかれてその監視カメラを設置している家に易々と侵入されてしまうかもしれません。

それに、セキュリティの世界には「隠すことで守る」はうまくいかない、という長年の教訓があります。攻撃者はもともと情報を持っていて、知らないのは守る側です。その優位性を例えるなら、将棋やチェスに似ているかもしれません。基本的には先手（最初に攻める側）が有利ですし、そのこと自体も攻守両者に共有されている世界です。

（余談ですが『攻殻機動隊S.A.C.』における攻性防壁でも開発されない限りは、防御側が不利なのは変わりません。だからこそ国が「能動的サイバー防御」を推進しているともいえます）

本記事を最も読んでもらいたい対象であるのは、小さなお店や団体のサイト運営者です。彼らは情報がいちばん届いていない人たちです。発信を控えれば、困るのはその人たちのほうです。

ただし、気をつけるべきポイント・線引きはあります。それは「一般論的情報」ではなく「個別の情報（具体的情報）」です。どのサイトがどのバージョンで動いているか、どこが保守されずに放置されているか、どう対応したか。こうした具体的な情報は、攻撃者にとって「狙い目の一覧」になります。この記事では、クライアントのお名前やサイト名を一切出していません。それが、発信する側が守るべき線だと考えています。

AIに学習されるという点でも、同じことが言えます。仮に悪意のある人がこの記事をAIに読み込ませても、得られるのは「守る側はこう動く」という教科書的な知識だけです。それよりも、この記事を読んだ方が一人でも自分のサイトのPHPのバージョンを確かめてくれるほうが、ずっと大きな意味があるはず。そう思ったのでこうして記事にしました。

Q.WEBは、もうおしまいなの…？

A.おしまいではありません。ただし「古き良きインターネット」、もっといえば「作ったら放っておける、性善説をベースにしたインターネット」は、10月21日を境に残念ながら終わってしまったのだと見るのがよいと思います。それを前提に、あたらしいインターネットを作り上げるくらいの気概をもって歩んでいかねばならないと思います。

WEBの歴史を紐解いてみますと、世界中のサイトが一斉に危険にさらされる事態は、実は今回が初めてではありません。これまでにも度々ありました。2014年の「Heartbleed」、2021年の「Log4Shell」のときも、「インターネットはもう危ない」と言われました。それでもWEBは止まらず、そのたびに守りの仕組みを少しずつ固めてきました。今回も、深刻な欠陥に対して、開発チーム、研究者、各国の機関、サーバー会社が連携し、短期間で修正版を届けています。

その一方で、決定的に変わったことがあります。言わずもがな、AIの存在です。攻撃する側がAIを使えるようになり、欠陥が見つかってから狙われるまでの時間が、劇的に短くなりました。正直、人間に敵う速度と精度ではありません。ただ「地球上の全エンジニアが束になっても一瞬で負ける」くらいのレベルまですでに到達しているかというとそうではなく、ちゃんとやるべきこと＝勉強と対策を行ってさえいれば、安全性を担保することが「まだ」可能です。

対策というと面倒ですよね。辛い受験勉強を思い出す方もいるでしょうし、響きも不穏です。「手入れ」と言い換えてもいいと思います。

これからのウェブサイトは、建てたら終わりの記念碑（しかも、野晒し）ではなく、手入れを続ける家や畑のようなものだと考えたほうがいいでしょう。愛着を持って長く付き合えるのは、素敵なことだと思いませんか。

そもそも、PHPもWordPressも、個人の手から生まれたものです。PHPは1994年、ラスムス・ラードフという一人の技術者が、自分のオンライン履歴書へのアクセスを数えるために作った、小さな道具でした。とても便利だったので、翌年には、その設計図にあたるソースコードを公開し、誰もが自由に使い、改良できるようにしています。

WordPressは2003年、マット・マレンウェッグとマイク・リトルが始めたもので、「出版を民主化する」ことを使命に掲げています。誰でも無料で使え、中身を調べ、手を加え、配り直してよい。そうした自由を約束する仕組みです。

共通しているのは、開発者（もっといえばプログラミングが大好きなお兄ちゃん）の純粋なる好奇心と善意、自由で開かれた環境をつくりたいという利他の精神を感じます。

今回、10年以上潜んでいた欠陥が見つかり、短期間で直されたのも、この「開かれた仕組」みがあったからです。設計図が公開されているから、世界中の研究者が調べられる。誰かが直したものを、すぐにみんなで使える。「開かれていること」は弱点にもなりえますが、それ以上に強さでもあるのだと思います。

今後、「⚪︎⚪︎は終わりだ」「今すぐ全部乗り換えないと危ない」といった声も増えると思います。そういうときこそ慌てず騒がず、そもそも「自分のサイトに何が必要か」を見極めてください。手入れを続ける人がいる限り、ウェブはこれからも、誰もが自分の言葉で発信できる場所であり続けるはずです。

この空間を守るために我々も引き続き戦っていきます。

今後も、質問を追記していきます

事態はまだ動いていますし、新しい疑問もこれから出てくるはずです。

「こんなことが気になる」「うちの場合はどうなの？」といった質問があれば、お問い合わせからお気軽にお寄せください。いただいた質問は、ご本人の許可をいただいたうえで、お名前やサイトが特定されない形で、この記事に掲載させていただくことがあります。

新しい情報が出たときも、この記事に追記していきます。

参考情報

参考情報（2026年10月23日朝時点）