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

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

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

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

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

※多くのお問い合わせをいただいております。ご質問の順にお答えしていきますのでお時間を頂戴する場合がございますが、何卒ご容赦ください。AIによる自動返答ではなく、基本的に私自身がお答えします。待っていられないという場合は、まず当記事をご参照ください。

※2026年10月23日朝時点の情報に基づいています。

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

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

A. ホームページを、見られた瞬間に組み立てるためのプログラミング言語です。

ブログやネットショップの多くは、誰かがページを開いた瞬間に、サーバー（ホームページを置いておくコンピューター）が記事の文章や商品情報を取り出して、一枚のページに組み立てています。この組み立て係が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. 自分のサイトにPHPが使われているかどうか、どうやって見分ける？

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

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

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

Q. サイトを持っていない、見るだけの人にも関係ある？

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

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

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

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

騒動編：何が起きたの？

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までしか対応していません」とうたう機能を、バージョン６以上には適応できないのです。自信のない方は、まずはサイトを作った方に相談することをおすすめします。

Q. 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. 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. 15年以上現場にいるのですが、正直に言えば、PHPでここまでの事態（全世界規模の緊急脆弱性の発見）を実際に経験したのは初めてでした。

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

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

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

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

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

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

A. 今回のような記事が攻撃者の役に立つおそれは、ほぼないと考えています。セキュリティの世界でも、「どこまで公開すべきか」は長く議論されてきたテーマです。

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

それに、セキュリティの世界には「隠すことで守る」はうまくいかない、という長年の教訓があります。攻撃者はもともと情報を持っていて、知らないのは守る側です。将棋やチェスに似ているかもしれません。基本的には先手（最初に攻める側）が有利です。余談ですが『攻殻機動隊S.A.C.』における攻性防壁でも開発されない限りは、防御側が不利なのは変わりません。

特に、この記事を読んでほしいと考えている小さなお店や団体のサイト運営者は、情報がいちばん届いていない人たちです。発信を控えれば、困るのはその人たちのほうです。

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

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

Q. インターネット、WEBは、もうおしまいなの？

A. おしまいではありません。ただ、「作ったら放っておける」時代は、10月21日を境にもう終わってしまったのだと見るのがよいと思います。

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

一方で、変わったこともあります。攻撃する側がAIを使えるようになり、欠陥が見つかってから狙われるまでの時間が、劇的に短くなりました。これからのウェブサイトは、建てたら終わりの記念碑ではなく、手入れを続ける家や畑のようなものだと考えたほうがいいでしょう。

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

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

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

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

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

この記事は、ここで終わりではありません。事態はまだ動いていますし、新しい疑問もこれから出てくるはずです。

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

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

参考情報

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