夜、そろそろ寝ようかとスマホを手に取って、いつもの癖で保育園の連絡帳アプリを開く。……開かない。「ただいまメンテナンス中です」の文字だけが、妙に冷たく光っている。あれ、おかしいな。じゃあせめて、昨日ポチったフリマの商品でも確認するか——と思ったら、そっちもメンテナンス。ゲームを起動すれば「緊急メンテナンスのお知らせ」。SNSを眺めると、知らない誰かが「ログインできない」「アプリが開かない」と、まるで同じ夜に同じ呟きを投げている。
2026年10月21日の夜、日本中のWebサービスが、こんなふうに一斉に静かになった。原因は、普段の私たちが名前すら意識していない「PHP（ピーエイチピー）」という技術の、深刻な脆弱性だった。「プログラミングの話でしょ、自分には関係ない」——正直、私も最初はそう思っていた。でも、あの夜に止まったのは、私たちの生活そのものだった。この記事では、あの夜なにが起きていたのか、そしてそれがどうして「保育園アプリ」にまでつながるのかを、できるだけ噛み砕いて書いていく。
まず、発端になった速報ポストがこちら。
47NEWS（@47news_official）が「【速報】PHP修正プログラムを公開」と伝えたのは、2026年10月21日22時56分。この時点ですでに63万回以上再生され、636のリポストと2160の「いいね」、160のブックマークが付いていた。たった一文の速報に、これだけの人が反応した。それだけ多くの人が、この夜を「自分ごと」として固唾をのんで見ていた、ということだ。
その夜、日本中の「当たり前」が一斉に止まった
まず、あの夜の事実を時系列で並べておこう。2026年10月20日、PHPの開発チーム（php.net）が「重大な脆弱性2件を修正するセキュリティリリースを、日本時間10月21日23時に出します」と予告した。深刻度を示すCVSS v4.0のスコアは、2件とも9.2。これは10段階評価で「緊急」に片足を突っ込んだ数字だ。
ところが、この予告が出た瞬間から、世の中がざわつき始める。修正版が出る前に「php2shell」なる攻撃コードの噂がネット上に出回り、「23時を待たずに攻撃が始まるのでは」と空気が張り詰めていった。そして迎えた当日、php.netは予定を少し前倒しする形で、10月21日22時40分頃（日本時間）に修正版を公開。対象はPHP 8.5.12、8.4.27、8.3.36、8.2.35の4系列だ。
この「公開前の数時間」が、現場にとっては地獄だった。ITmediaなどが伝えたところによると、この夜、保育施設向けサービスの「コドモン」が保護者アプリを含む全サービスを予防的に停止、ネットショップ作成サービスの「BASE」も21日午後から緊急メンテナンスに入った。さらに「シャドバ」や「さくらのレンタルサーバ」など、名前を聞けば誰もが知るサービスが次々と緊急メンテに踏み切った。
「予防的に止める」という判断は、使っている側からすると理不尽に映る。でも、あとで書くように、この脆弱性は「認証なしのリクエスト1つで、サイトのコードが動き出す前に攻撃が始まる」ことが実証されていた。止めるか、やられるか。サービスを預かる側にとっては、それくらいギリギリの選択だったのだ。
そもそも「PHPの脆弱性」って、私たちの生活とどうつながるのか
ここで一度、肩の力を抜いてほしい。PHPは、世界のWebサイトの大半を支えているプログラミング言語だ。身近な例えをするなら、コンビニのレジのようなもの。私たちはレジの中身を意識しないけれど、あの機械が止まれば、店はどんなに商品が揃っていても営業できない。PHPも同じで、ネットショップも予約サイトも、その裏側で静かに動いている。
今回の「php2shell」は、そのレジに置き忘れた前のお客さんの注文票が、次のお客さんの会計に紛れ込む、というイメージの不具合だ。専門用語では「Use After Free（解放後の使用）」と呼ばれる。セキュリティ各社の解説をまとめると、正体はこうだ。
1つめ、CVE-2026-109618は「メモリが足りなくなったときの処理（OOM時のlongjmp）」に穴があった。メモリが限界に達した際、処理中のリクエストの内部データが作りかけのまま放置され、壊れたデータが正しいものとして扱われてしまう。2つめ、CVE-2026-109619は「古い状態が残り続ける（Stale Global State）」問題。リクエストの内部状態が、メモリを解放したあとも残り、同じワーカーが次のリクエストを処理するときに、その古い状態を使い回してしまう。
公式アドバイザリでは、前半（壊れたデータを残す側）を「Producer」、後半（それを拾ってしまう側）を「Consumer」と呼んでいる。汚れたデータを残すリクエストと、それを拾う別のリクエスト——この2つを組み合わせることで、外部からサーバー上で任意のコードを実行できてしまう。これがリモートコード実行（RCE）だ。そして恐ろしいのは、影響範囲が「mod_php」「php-fpm」、そして「WordPress」「Laravel」「Symfony」など、ありとあらゆる構成に及ぶこと。WordPressの種類や設定に関係なく、PHPが動いている時点で対象になりうる。
【ガチ比較】「放置」「回避策」「更新」——実際どう違ったのか
では、現場で実際に選ばれた対応を、本音つきで並べてみよう。私が複数の一次情報と現場の声を突き合わせて作った、リアルな比較表だ。
| 対応 | 効果・実感 | 手軽さ・コスト | やってみた本音・注意点 |
|---|---|---|---|
| 何もしない（そのまま運用） | 効果なし（★☆☆☆☆） | 手軽さは最高、コストゼロ | 悪用コードが既に出回っていた夜。「見なかったこと」はできても「なかったこと」にはできない |
| 設定での回避策（session.upload_progress.enabled=0 など） | 一部の攻撃経路を減らす程度（★★☆☆☆） | php.ini編集＋全ワーカー再起動。数十分で可能 | php.net自身が「安全になるわけではない」と明言。あくまで更新までのつなぎ |
| OS標準パッケージの更新（apt/yum など） | 確実に修正が入る（★★★★☆） | OS会社に事前共有済み。普段の更新手順でOK | 版番号が変わらないことがあるため「直ったか」の確認が必須。地味に混乱する |
| Remiリポジトリ経由のPHP | 当日は更新なし（★☆☆☆☆） | — | php.netは「OS標準に切り替えるかソースからビルド」を推奨。これに気づかず待ちぼうけした人多数 |
| サービスを予防的に停止 | 被害はゼロにできる（★★★★★） | 売上・利用者への影響は甚大 | コドモンやBASEが選択。信頼を守るための「痛みを伴う正解」 |
| 8.1以前を使い続けている場合 | 公式修正なし（☆☆☆☆☆） | 自前ビルドか延長サポート契約が必要 | 「まだ動いてるから」で塩漬けにした古いシステムが、ここで一気に炙り出された |
この表で一番見てほしいのは、上から2番目の「回避策」の列だ。よく「session.upload_progress.enabled=0 にすれば大丈夫」とだけ広まったが、これはCVE-2026-109619の一部の攻撃を減らすだけで、しかも完全ではない。加えてCVE-2026-109618の経路には効かない。回避策はあくまで「低減」であり「防御」ではない——ここを取り違えると、「対策したつもり」で穴を開けたまま朝を迎えることになる。実際、php.netの告知にも「どれも一部の攻撃経路を減らすだけで、安全になるわけではない」と明記されている。数字でいえば、CVSS 9.2というスコアは「放置すれば一撃で任意コード実行に至る」深刻度だ。これを「設定1行で解決」と受け取ってしまうのは、かなり危険な読み違いだった。
実際にやってみて痛感した落とし穴と、現場の泥臭い話
ここからは、実際にこの夜を現場で過ごした人たちの声を交えながら、教科書には載らない落とし穴を書いていく。まず、多くの情シス担当者を最も苦しめたのは「うちのPHPがどこにあるか、即答できるか」という問題だった。ある情報システム担当のブログには、こんな一節がある。「PHPの更新は来週の定例メンテでいいか——そう考えていた担当者ほど、今日の夕方に胃が痛くなっている」。そう、脆弱性対応の本当の難しさは、パッチを当てる技術ではなく、「自社のどこで、どのバージョンのPHPが、誰の手で動いているか」を即座に把握できているか、に集約される。
次の落とし穴は「回避策の副作用」だ。たとえばCVE-2026-109618向けに「memory_limit=-1（メモリ上限なし）」にする回避策が案内されたが、これはコンテナやcgroupで上限をかけていないと、サーバー全体がメモリ不足で落ちる。守るための設定が、サービスを止める原因になりかねない。設定に自信がないなら、回避策をこねくり回すより、更新を優先したほうが結果的に安全だ。
そして、あの夜いちばん人間味があったのは、SNSに流れた声だった。予定が23時と言われていたのに22時台に修正版が出たことについて、「22:34に公開されており23時説は何だったんだ」と呟く人がいた。Xでは「政府に『高市さんPHPヤバいっす』って報告する技術技官がいて、『おっしゃ、なら首相アカウントで注意喚起するわ』と首相（チーム）が動いてくれる」という投稿も話題になっていて、技術と政治の距離が急に縮まった夜でもあった。一方で、「PHPはそれを使ってる企業側のセキュリティの問題で、一般の人ができることは『今夜は検索などインターネットをやらない』ことだと言ってた」という、ちょっと切ない（そして半分くらい間違った）呟きも広まっていた。情報が速い夜ほど、こうした“伝言ゲーム”が混ざる。一次情報を自分の目で確かめる習慣が、こんなときに効いてくる。
ぶっちゃけ読者が気になる疑問（FAQ）
Q1. 普通のユーザーの私にできることって、あるの？「今夜はネットをやらない」は本当？
A. 正直に言うと、一般ユーザーが個人でできることはほとんどありません。攻撃されるのはサービス側のサーバーであって、あなたのスマホが直接狙われるわけではないからです。だから「今夜はネットをやらない」は気休めに近く、実際には何の防御にもなりません。私たちにできるのは、①使っているサービスの公式アナウンスを確認する、②運営側の「予防的停止」を責めずに待つ、③もしもの時に備えて、大事なサービスはパスワードを使い回さない——この3つくらいです。
Q2. 個人ブログやWordPressも、やっぱり危ないの？
A. はい、これは他人事ではありません。今回の脆弱性は「PHPが動いている時点で対象になりうる」もので、php.netも「Webで動いているPHPはすべて対象」としています。個人のWordPressブログも、レンタルサーバーで動いていれば例外ではありません。レンタルサーバー業者が対応してくれている場合が多いですが、「自分のブログはどこで動いているか」を把握し、管理画面からPHPのバージョンを確認しておくだけで、いざという時の初動が段違いに速くなります。
Q3. これから同じことが起きたら、どう身を守ればいい？
A. 一番効くのは「知る速度」を上げることです。今回も、修正版が出る前に悪用コードの噂が先に広がりました。信頼できる情報源——php.netの公式告知、GMO Flatt Securityのようなセキュリティ企業のブログ、ITmediaなど大手メディア——を普段から軽く追っておくだけで、噂に振り回されにくくなります。そして運営者側なら、「自社のPHPがどこにあるか」を平時に棚卸ししておくこと。あの夜の胃痛は、ほとんどが「分からない」から来ていました。
まとめ——「当たり前」は、誰かの汗でできている
あの夜、保育園アプリもフリマもゲームも止まって、私たちはちょっとだけ不便をした。でもその不便は、サービスを預かる人たちが「止めるか、やられるか」のギリギリで、それでも利用者を守るほうを選んだ結果だった。見えないところで、誰かが22時40分の修正版公開に合わせて走り回っていた。
PHPという、普段は名前も出ない技術。その脆弱性ひとつで、日本中の「当たり前」が揺らいだ。これは、私たちの生活がどれだけ多くの見えない技術と、その上で働く人たちに支えられているかを教えてくれた夜だった。明日からできる最初の一歩は、とても地味だ。自分のブログやサイトが「どこで、どのPHPで動いているか」を、一度だけ確認してみる。それだけでいい。あの夜の胃痛を、次は自分の側で味わわなくて済むように。
参考にした一次情報・関連情報
コメント