【要注意】PHPの重大な脆弱性で世界中が「緊急メンテナンス」！日本国内の大手サービスも停止対応へ

こんにちは、てつです！

2026年10月21日、日本国内を中心に 「急にサイトが使えなくなった」 というニュースがありました。

影響はありましたか？

ちょっと話を進める前に、大事な事実を1つ。

この問題の深刻さは、被害の大きさではなく「被害を防ぐために止めたもの」が桁違いに多いことにあります。

2026年10月21日、PHPに「認証なしでリモートコード実行（RCE）できる」重大な脆弱性が2件見つかり、世界中で緊急メンテナンス対応が広がりました。

国内的にも、銀行、ゲーム、ECサイト、自治体、大学。サービスの停止が連鎖しました。

シンガポールのサイバーセキュリティ機関は「PHPの全バージョンが影響を受ける」と警告を出しています。

そして今回の最大の見どころはひとつ。この脆弱性、AI（OpenAIやAnthropicのモデル）による監査で発見されたものだったということです。

未来を予言するのではなく、「起きてから」ではなく「起きる前から」AIが人力を代替して欠陥を掘り起こす時代が来た、という感覚です。

1. PHPとは

PHP（ピーエイチピー）は、サーバーサイドで動くスクリプト言語です。

1994年に初めて発表されて以来、30年近く、Webサイトの裏側（バックエンド）を支える土台として君臨し続けてきました。

PHPとは、HTMLに埋め込まれたスクリプトとして動作し、データベースにアクセスしてページを動的に生成する、という仕組みです。ブラウザではなくサーバー側で動く前提で書かれているため、作った人のサーバー上でしか動かない —— という意味です。

なぜそこまで広く使われてきたのでしょうか。理由はシンプルで、「すぐ動き、誰の手軽さでも公開できる」 ことに尽きます。

利点	説明
導入が容易	Apache等のWebサーバーにモジュールとして入れるだけ。LAMP（Linux + Apache + MySQL + PHP）構成のPとして、2000年代のWeb業界の定番になりました
ホスティングが多い	ほぼすべての共用サーバーに標準搭載。「PHPで書けば動かせる」場所が一般に広がる
CMS・Framework が豊富	WordPress、Drupal、Joomla!、EC-CUBE、Movable Type、PowerCMS、Laravel、Symfony、Nextcloud、Wikipedia（MediaWiki）…… 日本で使われている「多くのWebサービス」の裏側にPHPがいます
無料・オープンソース	ライセンス費用なし。構築時の負担も想像でき、ソースを自分で確認できます

そして今、2026年10月22日時点のW3Techs統計では、サーバーサイドの言語を判別できるサイトのうち、約69.3%がPHPを使っています。

つまり 「Web上の3分の2はPHP」 —— これが今回の事件のスケールの正体です。

2. 2026年10月に見つかった脆弱性とは

2026年10月21日、PHPの開発元であるThe PHP Groupがセキュリティリリースを公開しました。修正された脆弱性は2件で、通称「php2shell」と呼ばれています。

CVE	内容	深刻度
CVE-2026-109618	RCE via OOM corruption（メモリ枯渇によるメモリ破壊）	CVSS v4.0 9.2
CVE-2026-109619	RCE via stale global state（古いグローバル状態の残留）	CVSS v4.0 9.2

両件とも 9.2（Critical）。しかも 認証は不要 —— つまり攻撃者に管理者のログインIDやパスワードは不要で、外部からHTTPリクエストを1回送るだけで、サーバー上の任意のコードを実行できるということです。

世界中で「緊急メンテナンス」が叫ばれているPHP（php2shell）

CVE-2026-109618：メモリ枯渇の瞬間に「中途半端に初期化されたメモリ」が残る

PHPはメモリが memory_limit に達すると、処理を途中で打ち切って後片付け（後処理）へ移ります。

ただその後片付けのタイミングが「ちょうど悪い」。初期化されていない中途半端なデータが残ったまま、後片付けの処理がそのデータを読んでしまう —— そこからメモリ破壊につながるスタック破綻が起きます。

GitHubのセキュリティアドバイザリによると、multipartのリクエストを大量送ることで OOM を誘発させる経路が報告されています。

最も衝撃的なのは Apache + mod_php の構成です。アプリ側のコードが1行も実行される前に攻撃が成立し、デフォルト設定のままで完全なRCEが実証された、という報告があります。

CVE-2026-109619：前のリクエストの「残りカス」が次のリクエストを襲う

こちらは、リクエストを処理しきれなかったときに内部の状態が解放済みメモリを指したまま消えないという不備です。

同じワーカーが処理する次のリクエストがその残りを読み、Use-After-Free（解放済みメモリの再利用）が発生します。ワーカーのクラッシュが確認され、実際のWebアプリケーション上でRCEが実証されたとされています。

なお、この件で初めは「Session Upload Progress 機能（ext/session）が原因ではないのか」という推測もありましたが、公式の結論は「原因はZend Engine全体の設計にあり、セッション機能だけの問題ではない」 でした。推測は半分当たり、半分外れた、というのが正確なところです。

メモリ破壊（Use-After-Free）の模式図。CVE-Aが大量リクエストによるメモリ枯渇とデータ残留、CVE-Bが解放後の誤参照と不完全な初期化を表している

上の図の「CVE-A」は CVE-2026-109618、「CVE-B」は CVE-2026-109619 に対応します。

影響を受けるバージョン

バージョン	対応
PHP 8.5	8.5.12 に更新
PHP 8.4	8.4.27 に更新
PHP 8.3	8.3.36 に更新
PHP 8.2	8.2.35 に更新
PHP 8.1 / 8.0 / 7.4	サポート終了（EOL）。ソースコードパッチのみ公開され、バイナリは配布なし
PHP 5.4 以前	Wiz 消息称影響を受ける可能性あり

特に注意すべきは EOL（サポート終了）版です。 公式は「8.1以下はPHPプロジェクトから更新を受けない」と明記しています。今回だけ7.4・8.0・8.1向けの最小限のソースパッチがブランチで公開されましたが、リリース版のバイナリはありません。

つまり、EOLバージョンのままだと、脆弱なまま放置される以外の選択肢がありません。

影響を受ける構成（すべて危険）

Who is at risk: all PHP installations serving web requests, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed.

Webリクエストを処理するすべてのPHP構成が危険です。

PHP-FPM（Nginx + PHP-FPM が今いちばん多い構成）
Apache + mod_php（最も危険度が高い。アプリコード実行前からの攻撃が成立）
php-cgi
FrankenPHP
LiteSpeed

構成によって危険度は差があります。Red Hatは自社標準構成のPHP-FPMでは「実際にRCEに至るのは難しい」と評価し、評価をImportant（CVSS v3.1で8.1）としています。

ただし「PHP-FPMだから大丈夫」という話にはなりません。 構成が違うだけで、更新しなくていい理由にはなりません。

緩和策はあるの？

PHP公式は、暫定的な緩和策も公開しています。

memory_limit の上限撤廃（または十分に大きくする）
session.upload_progress.enabled = 0（セッションのアップロード進捗機能を無効化）

ただし公式の姿勢は明確です。

「完全な緩和策はない。更新が唯一の安全な選択である。」

この2つで攻撃を完全に防げる訳ではなく、パッチを適用するまでの時間を稼ぐだけ —— つまりWAFと同じ位置づけの「時間を稼ぐ道具」です。

実際に何が起きたのか（タイムライン）

この事件は「突然起きた」わけではありません。公開の数ヶ月前から準備が進んでいました。

日時（日本時間）	できごと
2024年	PHPが初めて数年ぶりに外部セキュリティ監査（OSTIFの資金でQuarkslabが担当）。この過程でPHPコア開発者が CVE-2026-109618 のOOM問題の最初の兆候を発見。2024年時点ではエクスプロイトは理論化のみで、具体的な攻撃ベクタは未発見
2026年5月	PHP Foundation が Ecosystem Security Team を設立。Volker Dusch が AI Security Engineer in Residence に就任
2026年前半	Alpha-Omega と連携し、Anthropic の Claude Mythos でPHPをスキャン。のちにOpenAIの Daybreak Red も追加
2026年7月30日	OpenAI の「Patch the Planet」プログラムにPHP Foundation が参加。Calif がPHPの監査を開始
2026年8月11日	Calif の Ryan A が無条件RCEを報告（OOM問題と同じ根本原因）。OpenAIも同日に独立して報告
2026年8月24日	Wiz が追加の攻撃ベクタを報告
2026年9月18日	OpenAI がさらに攻撃ベクタを追加報告
8月11日以降	修正が最優先課題に。休日も、24時間体制で修正作業
2026年10月20日 15:00 UTC	CVE IDが漏洩。本来は10月22日14:00 UTC公開予定だった。付随情報は「深刻度10.0」と誤った表記で、技術的な詳細はまだ漏れていない状態
2026年10月20日 20:00 UTC 頃	Califが誤ってPoC（概念実証）動画を公開。すぐに削除されたが、コピーが出回って拡散
2026年10月21日 07:41 UTC	Chainguard が修正済みコンテナイメージを先行公開。embargo（情報解禁日時）の裏切り
2026年10月21日 13:34 UTC	GitHub セキュリティアドバイザリ公開（予定より26分前）
2026年10月21日 13:30 UTC	修正版 8.5.12 / 8.4.27 / 8.3.36 / 8.2.35 公開（予定より前倒し。日本時間では22日22時台）
2026年10月21日 13:48 / 13:54 UTC	CVE-2026-109618 / CVE-2026-109619 が正式登録
2026年10月21日 14:00 UTC 頃	国家サイバー統括室がXで呼びかけ
2026年10月21日 21:55 頃	高市総理がXで対応を呼びかけ

この表だけを見ると、「10月21日に突然、世界が危機に瀕した」わけではありません。

2024年の監査で兆候が見え、5月にAI Security Engineer を置き、7月にOpenAIとの共同監査が始まり、8月に報告が上がり、10月に修正して、ようやく公表。

AIが発見したのは8月、公開は10月。 2ヶ月間の「直前期」があったという、重要な事実です。

3. PHPが使われている代表的なサイト・サービス（日本国内）

「PHPの脆弱性って、いまいちピンとこない話だったのでは……」と思うかもしれません。

いいえ、違うんです。 piyolog によると、2026年10月22日午前時点で、停止を告知した組織は211組織に及んでいます。

サービス全体を止めた・一部機能を止めた主な組織（国内）

区分	主な例
サービス全体を停止（約20件）	BASE（Webサービス・PAY IDアプリ・API）、Cygames（Shadowverse: Worlds Beyond、グランブルーファンタジー）、コドモン、アルファポリス、厚生労働省（介護サービス情報公表システム）、調整さん、pictSQUARE
一部の機能を停止（約7件）	エックスサーバー（公式サイト・管理画面。利用者のサーバーは稼働継続）、Shifter（ダッシュボードの一部）、筑波大学（問い合わせフォームなど）
自社・団体のサイトを停止（約27件）	湖池屋、阪神電気鉄道、LIG、スリーシェイク、文学フリマ事務局
自治体	札幌市、日野市、会津若松市、大垣市など
国・省庁	厚生労働省、財務省（いずれも一部）
大学・教育機関	筑波大学など

銀行・証券

静岡銀行、北海道銀行、北洋銀行、七十七銀行、auじぶん銀行、第四北越銀行、証券では大和証券。

「主要な銀行のネットバンキングが止まった」 —— かなり大きなインパクトです。給与振込の確認も、カードの明細確認もできない状態を想像してください。

ゲーム・SNS・EC

Cygames、BASE、ニコニコ動画、pixiv、コドモン（保育園の連絡帳SaaS）、pictSQUARE、調整さん（ファンコミュニティ）、ConoHa WING。

ホスティング事業者（← 個人ユーザーにとって最も関係深いところ）

事業者	対応（2026年10月22日時点）
さくらインターネット	サーバー側のPHPを修正版へ更新（22日6:30に完了）。古いPHPの利用者には PHP 8.3 への切替を案内
エックスサーバー	PHP 8.2〜8.5対象の全サーバーで修正適用済み（22日6:45時点）。旧版は順次。公式サイトと管理画面は予防的に一時停止 → 点検が済んだものから順次再開（利用者のサーバーは稼働継続）
カゴヤ・ジャパン	PHP 8.2〜8.5を修正版公開後に順次更新。18:20の更新で調査範囲を共用サーバー・マネージド専用サーバーにも拡大。恒久対応は調整中、暫定策として利用者にサイトの公開停止やアクセス制限を検討するよう要請
IDCフロンティア（Zenlogic）	サーバー側のPHP更新とパッチ適用（Apache停止を伴うメンテナンス）
CPI	サービスサイトと管理画面を停止。利用者のサーバーは稼働継続
さくらのクラウド	データベースアプライアンスのWeb UI（phpMyAdminなど）を停止
Six Apart	Movable Type クラウド版で緊急メンテナンスを予定
アルファサイド	PowerCMS利用者に、修正版をすぐ当てられない場合はサイトの一時停止も検討するよう呼びかけ

海外でも止まりました

ウィキメディア財団（Wikipedia の運営元）：Cloud VPS、Toolforge、Wikibase クラウドインスタンスを停止
4chan、Something Awful、Internet Archive
オランダ政府（Overheid.nl）、デンマークの全国学校連絡プラットフォーム、フィンランド政府の公開サービスすべて、法国内務部の全ウェブサイト
米国では FBI と NSA が緊急勧告。更新できない場合は、事故が起きる前にサイトを一時的に停止することを提案

「世界中で緊急メンテナンス」 —— これは誇り表現ではなく、実態です。

4. いつから危険性の兆候が存在していたのか

ここが今回の一番の大事なポイントです。

「2026年10月21日に突然、PHPに穴が開いた」ではありません。

上のタイムラインに書いたとおり、2024年の時点で既に「OOM処理の不備」の存在は知られていました。 ただし、具体的な攻撃手法（ベクタ）が分かっていなかった —— つまり「壊れうる仕組みの認識はあるが、攻撃経路が未確定」だった、ということです。

PHP2Shellの発見までの縦タイムライン。2024年に兆候を発見、2026年5月にAI Security Engineerを設置、7月30日にOpenAIのPatch the Planetプログラムへ参加、8月11日にRCEを報告、10月20日に情報が漏洩し、10月21日に緊急パッチが公開された流れ — php2shell の発見まで2年、公開まで3ヶ月

この時系列を図に表すと、「突然の危機」ではなく「2年かけた地雷的原っぱ、そして3ヶ月の最後のラッシュ」 だと分かります。

特に参考になったのが、以下の動画です。世界のメディアがどう報じたかが、そのまま分かります。

ポイント：「PHPの脆弱性」が突然凍結したものではありません。 数ヶ月の準備の過程があった —— それが今回の教訓です。

5. AIによって欠陥が発見された

ここからが、今回の見どころです。

脆弱性の発見に、OpenAIとAnthropicのAIモデルが深く関わりました。

具体的な流れ

2026年5月、PHP Foundation が「AI Security Engineer in Residence」という役職を新設。Volker Dusch が就任
2026年前半、Alpha-Omega と連携し、Anthropic の Claude Mythos でPHPをスキャン。さらに OpenAI の Daybreak Red も追加
2026年7月30日、OpenAI の「Patch the Planet」プログラムにPHP Foundation が参加。Calif がPHPの監査を開始
2026年8月11日、Calif の Ryan A が無条件RCEを報告。OpenAIも同日に独立して報告 —— つまりAIの監査が2つの独立したルートから同じ根本原因に到達した
8月24日にWiz、9月18日にOpenAIが追加の攻撃ベクタを報告
CVEレコードには Calif.io、Wiz、OpenAI の名前が挙がっています

なぜこれが衝撃だったのか

普通の脆弱性発見と違います。「基礎ソフトウェアのリモートコード実行脆弱性を、AIが先に見つけた」 —— つまり 「次のCVEは人間がコードレビューで見つける時代」から「AIが探して人間が直す時代」への切り替え が、初めて現実の規模で示された出来事です。

The Verge などが、発見の功績をOpenAIに帰属させた形で報じたことにも注目です。「AIが危険な物を発見した」のではなく、「AIが危険な物を発見し、人間が対応した」 —— これが今回の本質です。

そして皮肉なことに、AIの進化は「被害のスケール」を早めました。 正確には「より早く見つかった分、公開も早くなる」という構造です。

より早く「見つかる」＝より早く「公開される」＝攻撃者に与えられる時間が短くなる

この二面性は、掘り下げると面白いテーマです。

6. WordPressなどにも使われている

「PHPって PHP で書いたWebアプリの話だったのでは……」と思う方のために、現実的なデータを。

今回の脆弱性は、WordPress固有の不備ではありません。 WordPress公式の日本語ブログ（ja.wordpress.org）もこう言っています。

今回の脆弱性は WordPress に固有のものではありません。PHP アプリケーションをホストしているすべてのサーバーが影響を受けます。この問題のために WordPress を更新する必要はなく、WordPress の更新も予定していません。

つまり WordPress Core のバージョンを気にして更新しても意味がない。PHP 本体を更新しないと直りません。

そもそも WordPress の更新自体、9月22日に深刻な脆弱性（WordPress Core）が公開され、4.7系までの古い系列にも修正を提供したばかりでした。「WordPressを使っている人」＝更新をサボりがちな人 は、ちょうど今回の直撃を食らっています。

PHPが使われている主なソフトウェア:

カテゴリ	ソフトウェア
CMS	WordPress、Drupal、Joomla!、Movable Type、PowerCMS、EC-CUBE、concrete CMS
Framework	Laravel、Symfony、CodeIgniter
その他のWebアプリ	Nextcloud、MediaWiki（Wikipedia）、Roundcube（Webメール）
サーバ管理画面	cPanel、Plesk（ホスティングの管理UIにPHPが内蔵されている）
その他	一部のWindowsアプリにもPHPが同梱されている

「cPanel や Plesk の管理画面」は忘れがちです。 ホスティング利用者自身は直接触らない画面ですが、どこかの共有サーバーでPHPアプリケーションを動かしていないかチェックするツールとしてPHPが動いています。

7. 当ブログ「てつblog」は？

ここからが、当ブログ固有の話です。

結論から言うと、当ブログは今回の脆弱性の影響を受けません。

当ブログ構成

項目	詳細
静的サイトジェネレータ	Hugo（Go言語製のSSG）
配信	Cloudflare Pages
サーバーサイド実行	なし（PHPを一切使わない）
ビルド	GitHub Actions で自動ビルド → 静的HTML / CSS / JS を生成

Hugoは ビルド時に Markdownを静的HTMLに変換します。読み取り専用の静的ファイルを配信するだけで、サーバー側でPHPが動くことがありません。

したがって、

PHP-FPM を使っていない → CVE-2026-109619（古いグローバル状態の残留）の影響なし
mod_php を使っていない → CVE-2026-109618（OOMによるメモリ破壊）の最悪経路にも該当しない
メモリ枯渇が起きるサーバーがない（静的ファイルの配信なので）

→ 今回の「緊急メンテナンス」の対象外です。

ただし、静的サイトだから安全、とは限らない

ここ、大事なポイントなので補足します。「静的サイトなら無敵」ではありません。

残るリスク	内容
XSS（クロスサイトスクリプティング）	Markdownに埋め込んだスクリプトが実行される。ビルド時ではなく閲覧者側のブラウザで発火
ビルド環境 / 依存関係	Hugo本体やテーマ、ビルド用の依存パッケージの脆弱性。CI/CDとGitHub Actionsのトークン管理
Supply Chain	依存パッケージが改ざんされた場合、ビルド成果物に混入
ビルド時の情報漏えい	ビルド環境のAPIキー、認証情報が漏れる
CDN / ホスティング側の脆弱性	Cloudflare Pages 側の問題

「サーバーを自分で保守しない」のではなく、「サーバーを自分で保守しないかわりに、攻撃者が触れる面が劇的に小さくなる」 —— これが静的サイトの本質的なメリットです。

実際、当ブログは 2026年2月に Blogger から Hugo+Cloudflare Pages へ移行しました（「Hugo×Cloudflare Pages移行後、検索流入はどう変わった？」参照）。

あのとき「サーバーを手放す」という判断が、ちょうど今回の事件で本当に実りを返しました。 サーバー管理に深入らなくて済む設計は、「何が起きたときに対応できるか」 を左右します。

「現象が起きたときに止められるか」 —— これこそが、構成設計で現実にもっとも重要なことだと、思いました。

8. 個人でできる対策

個人には大きく3つの立場があります。あなたはどれに当たりますか？

A. 個人でサイト・ブログを運用している場合（最も影響が大きい）

まず確認：自分のPHPバージョンは？

WordPressの場合、管理画面 → ツール → サイトヘルス → 情報 → サーバー で確認できます。ホスティングの管理画面にもPHPバージョンの表示があります。

自分のPHP	対応
8.5.12 / 8.4.27 / 8.3.36 / 8.2.35 以上	対応完了。ひとまず再起動して確認
8.2〜8.5 だが上記未満	今すぐに更新。ホスティング側で更新済みの場合も多い
8.1 以下（EOL）	要対応。ホスティングの切替案を確認するか、サーバーそのものを8.2以上に上げる必要があります

対応手順（今日やること）

ホスティング会社の公式アナウンスを確認する
- 「サーバー側で更新済み」と「利用者が自分で切り替える必要あり」で対応が変わる
- さくらインターネットは22日6:30に完了、エックスサーバーは22日6:45時点ですでに修正適用済み
更新前に必ずバックアップを取る（ファイル + データベース）
WordPress本体・テーマ・プラグインを最新に更新する
- 古いプラグインはPHP 8.2+で動かないことがあります。PHP更新の前に済ませておく
PHPバージョンを切り替える（8.2以上を推奨）
主要なページと管理画面を触って動作確認する
更新内容を記録しておく
プラグイン・テーマの更新を自動化する（更新をサボると、また同じ轍に）

それでも更新できない場合

公式は「更新できないなら、完全に緩和できるまでシステムをオフラインにする」と提案（英国NCSCも同じ旨の勧告）
ホスティング側でWAFルールの設定が済んでいるか確認する
WAFは「パッチまでの時間を稼ぐ道具」であって、「パッチの代わり」ではない —— この点を忘れると、WAFを有効にしただけで安心してしまう
を忘れると、WAFを有効にしただけで安心してしまう

監視も継続しておく

アクセスログ・エラーログに異常な大量リクエスト（特に multipart の POST）がないか確認
php.ini で session.upload_progress.enabled = 0 を設定（暫定緩和）
memory_limit の撤廃（暫定緩和）
ファイル整合性チェック（改ざんされていないか）

B. 一般の利用者として（ブログを読むだけの人）

総務省は「一般のインターネット利用者の皆様に、特段の対応を求めるものではありません」と明確に述べています。 22日11:18時点の取材への回答です。

現時点で、日本国内でこの脆弱性による「被害の公表」はありません。 停止した各社は、告知の中でいずれも「被害は確認されていない」と書いています。止まったのは「やられたから」ではなく、「やられる前に」止めた —— 予防的措置です。

ただし、「今この瞬間に、PHPを使ったサイトを利用している自分」 なら、念のため以下のことを確認しておくと安心です。

いつものパスワードを変更する（他サイトとの使い回しは避ける）
二要素認証（2FA）を有効にする（Google Authenticator やパスキーなど）
セッションを作り直す（一度ログアウトしてからログインし直す）
不審なメール・SMSに注意（「PHPの脆弱性でアカウントを保護します、即日再登録はこちら」みたいなフィッシングに乗らない）
「世界的な知名サイトが止まっている」こと自体は正常 —— 「〇〇がまた落ちた」ではなく「更新のための予防停止」であることを理解する

重要：復旧を待つのではなく、「自分が影響を受けるサービスを使っているかどうか」を把握しておく —— 預金のネットバンキングや、送料の支払いなど、止まると困るものについて、各社の状況を確認しておくのが感覚です。

C. 日々の防御力を上げておく（どの立場にも当てはまる）

静的サイト（SSG）に移行できないか検討する
- 当ブログがそうしているように、「サーバーを保守する責任」をなくす —— それがそのままセキュリティ対策になります
- WordPress の「更新を自動で続ける」方針とは別の方針です
一次ソースをフォローする
- php.net（PHP公式のセキュリティ告知）
- 国家サイバー統括室（Xでリアルタイムに注意喚起）
- IPA（10月21日に事前の注意喚起を掲載）
- JVN（脆弱性情報データベース）
- CISA / NIST（海外）
「棚卸し」を習慣にする（IPAが求めたこと）
- 自分のIT資産 —— 「何を管理して、何を手放すか」のリストを持っておく
WordPressの更新を自動化する
- コア・テーマ・プラグインの自動更新設定
バックアップを「取得する」だけでなく「復元テスト」する
- 復旧できないバックアップはバックアップではない
WAFを「時間を稼ぐ道具」として使う（パッチの代替にしない）

まとめ

2026年10月21日、PHPに2件の重大なRCE脆弱性が見つかり、世界中で「緊急メンテナンス」が始まりました。

振り返ると、この事件のポイントは3つです。

1つ目。 これは突然の危機ではなかった。2024年に兆候が見え、2026年5月にAIセキュリティエンジニアが導入され、7月にOpenAIとの共同監査が始まり、8月に報告が上がった。2年かけた地雷的原っぱと、3ヶ月の最後のラッシュだった。

2つ目。 発見にAIが深く関わった。「AIが危険なバグを人間より早く見つける」 —— これは、初めて現実の規模で示された結果だった。同時に、「早く見つかる＝早く公開される＝攻撃者に与えられる時間が短くなる」 という逆説的な面もある。技術進歩の裏返しでもある。

3つ目。 影響のスケールは「PHP＝Webの3分の2」。結果は、銀行・ゲーム・EC・自治体・大学、そしてホスティングが全て止まった。 そして 個人ブロガーも例外ではなく、WordPress 管理者は「自主的な更新」が要る。

当ブログ「てつblog」 は、Hugo + Cloudflare Pages の静的サイト構成なのでPHPを一切使わず、今回の影響はありません。ただし「静的だから安全」ではなく、「攻撃面が小さいから、攻撃者が到達できなかった」 —— それが本質です。

最後に一つだけ。

あなた自身のサービスが「止まった」とき、それは「やられたから」ではなく「やられる前に止めた」から。 被害が出なかったことに安堵し、「止めたことで学べたこと」を次の1回に使う。それがこの事件の学びの核心だと思います。

てつblog