php脆弱性のリークとeMudhura問題

インターネット史に残る大事件

news
作者

nikodehyakuen

公開

2026年10月22日

何が起こった？

2026年10月21日、ウェブの重要な基盤に２つの重大なセキュリティインシデントが表面化。
深刻度スコア9.2/10.0を記録する重大なインシデント

  • phpの未修正リモートコード実行脆弱性のリーク(PHP2Shell)
    • 世界のウェブサイトの７～８割で使われているというphpにおいて、認証なしでサーバーを則れるゼロデイ脆弱性の情報が修正パッチ公開前にネット上へ流出
    • 世界中のハッカーたちはセキュリティパッチの適用前後を張り、変わったところを探し出すことで、もともと脆弱だった部分を特定し、いまだパッチが未適用のサーバーへ攻撃を仕掛け続けている
  • 大手商用認証局「eMudhra」の中間証明書秘密鍵の欠陥・流出
    • HTTPS通信が「本物であること」を証明するはずの認証局があり得ないレベルで脆弱な秘密鍵を運用していたことが判明し、だれでも偽のTLS証明書を発行できる状態に。

このことによって

php

  • パッチの公開前に情報がリークしたため、世界中の無数のWordPressサイトやレガシーなWebサービスが「無防備なサンドバッグ状態」に晒される。
    • 世界中のサーバーを運営していた人たちは、確実にパッチを適用できるようになるまで一時的にサーバーを落としておかなければならなくなった
    • 世界中のWebエンジニアたちは今総出でセキュリティパッチを充てる作業に当たっている

eMudhra

  • 中間認証局の秘密鍵があれば、「google.com」や「銀行のドメイン」など、地球上のあらゆるドメインの正規のTLS証明書を攻撃者が自由に偽造・署名可能に。
    • DNSスプーフィングや公衆Wi-Fiなどの経路改ざんと組み合わせることで、ブラウザに「安全（鍵マーク）」と表示させたまま中間者攻撃（通信の盗聴・改ざん）が成立してしてしまう。

なぜこれが起こったのか？

php

  • リクエスト中断時やメモリ不足（OOM）時のバッファ処理不備に起因し、解放後メモリの不正参照（Use-After-Free / メモリ破損）が発生。PHP 5.4以降のほぼ全バージョンに存在し、細工したHTTPリクエストを1つ送りつけるだけで、認証なしでWebサーバー権限の任意コードを実行されたり、メモリ上の他ユーザーのセッション・平文パスワードを抜き取られる。
  • ここ10年間人間の目からは発見されず、ここ最近になり、GPT-5.6 Solがphpの致命的な欠陥を発見。
  • セキュリティ企業Wizも独自に、Gemini 4 Argonを用いたAntigravityを通じて、脆弱性の実証や、攻撃の検知方法、修正パッチの妥当性検証などに不可欠な多大なる貢献を行う。

eMudhra

  • eMudhraの楕円曲線暗号（P-384）中間認証局証明書8件において、生成プロセスの不備・スクリプトバグにより、秘密鍵の上位ビットがゼロ埋めされ、秘密鍵の整数値が「4」や「56」など1バイト未満（3〜8bit、256未満）の極小値になっているという初歩的なミス。研究者が公開証明書からわずか1秒未満で8件すべての秘密鍵を復元。

AIがもたらしたセキュリティの変革と脅威

  • 「もっとも深刻なAIによる発見」
    • Wizの共同創業者であるアミ・ルットワック氏は、今回の件を「これまでにAIが発見した中で最も深刻な脆弱性である」と評している。
  • サイバー防衛の先手となったが…
    • AIのおかげで、攻撃者に悪用される前に「防御側が先手を打ってパッチを用意できた」という大きな功績がある。しかし一方で、OpenAIなどは「同様のAI技術を使えば、攻撃者側も極めて短時間で強力な攻撃ツール（エクスプロイト）を自動生成できてしまう」と警告しており、今後のパッチ適用のスピード勝負はさらに激化すると見られている。

AIによってインターネットの7割に影響するバグが暴かれた今回のインシデントは、まさに「AI時代のサイバーセキュリティ」を象徴する出来事となった。

そもそもなにそれ？

「PHP」

  • 役割: 主にWebサーバー側で動くスクリプト言語（サーバーサイド言語）。

  • 特徴:HTMLに埋め込んで記述できる扱いやすさから、2000年代以降の動的Webを急速に普及させました。世界最大シェアのCMSであるWordPressをはじめ、EC-CUBE、MediaWikiなど世界中の無数のWebサイトのバックエンドを支えている。ユーザーのブラウザからリクエストを受け取り、データベースと対話してHTMLをリアルタイム生成する心臓部である。

公開鍵暗号・秘密鍵

暗号化と複号で異なるペアの鍵を使う仕組み。 - 秘密鍵 * この世で一つの「南京錠」を生成するための鍵 * 隠したい場所の最奥部に保管する * これが流出すると、その唯一無二性が破綻する * 秘密鍵が生成した「南京錠」を「電子証明書」と呼ぶ。

  • 公開鍵
    • 世界に公開された、「秘密鍵とマッチするかどうか」だけを判定する鍵。
    • いわば、南京錠の「回す鍵」の部分
    • いろんな秘密鍵に対して、開けられるかどうか鍵穴に刺してみることはできるが、「唯一会うペア」を見つけられない限り、その鍵穴が回ることはない

これによって、インターネット上で、その認証を受けたドメインの唯一無二性を担保している。

TLS認証とは？

TLS（Transport Layer Security）は、Web通信の「盗聴防止（暗号化）」「改ざん検知」「通信相手のなりすまし防止（認証）」を行うプロトコル。 旧称はSSL。過去に何度も脆弱性が発見され現在は廃止も、その定着具合から今もなおSSL認証と呼ぶことも多々。

  • サーバーは自身の「公開鍵」を含んだ「電子証明書」をクライアントに提示。
  • クライアント（ブラウザやOS）は、あらかじめ内蔵している信頼済みの「ルート認証局（Root CA）」の公開鍵を使って、その証明書が正当に署名されているかを検証。（鍵が開くか、鍵穴を回そうとする）。
  • ルート認証局は通常、直接個別のWebサイトすべてに署名するわけではなく、「中間認証局」に権限を委譲（署名）する。
  • 今回、中間認証局であるeMudhraの秘密鍵が暴かれたため、攻撃者が「偽サイトのための証明書」を正規の署名付きでいくらでも量産できる状態になってしまった。

いま私たちにできることは？

  • 対策1：OSとWebブラウザを即座に最新化する

  • 理由: Chrome、Firefox、Edge、Safari、iOS、Androidなどのベンダーは、問題となったeMudhraの8つの中間証明書を失効・ブロックする緊急アップデートを配信済み、または順次適用しています。ブラウザやOSのルート証明書ストアを更新することで、偽造された証明書を検知・拒絶できます。

  • 対策2：ブラウザの「証明書エラー警告」を決して無視しない

  • 理由: 失効したeMudhra経由の証明書を使っているサイトや、中間者攻撃を受けている回線では「この接続ではプライバシーが保護されません」といった警告画面が出ます。「詳細設定 ＞ 安全でないページに進む」をクリックして無視・バイパスしてはいけません。

  • 対策3：公衆Wi-Fiや信頼できない回線でのログイン・機密通信を避ける

  • 理由: TLS証明書の偽造が可能な状況下では、公衆無線LANでのDNS欺瞞（スプーフィング）やARPポイズニングによる中間者攻撃のリスクが跳ね上がります。モバイル通信（4G/5Gテザリング）や、信頼できるVPNを経由して通信を行ってください。

  • 対策4：Webサービス側のパッチ適用状況に注意を払う

  • 理由: PHPの脆弱性（PHP2Shell）は、利用者がログインして認証情報を送信した瞬間にサーバー側のメモリから平文パスワードやセッションが抜き取られる恐れがあります。個人運営の掲示板や長期メンテされていない中小規模のWebサイトなど、更新が滞っていそうなサーバーでの重要パスワードの入力・カード決済は一時的に控えるのが安全です。また、パスワードの使いまわしをしている場合は、早急に変更することが求められます。

私の理解のためにも、自分なりに今回の事件を調べて、まとめてみました。

こうしてみると、AI時代のネット戦争が始まったように思えますね。

phpを使っている側としても、常にそのインフラを管理できる人員がいるわけではない状況だったり、完全に委託だったりで、早急なパッチ適用が叶わないこともあるでしょうしね。

これはサーバーを運営する上でしょうがないリスクだとは思いますが、それは運営する人がどこまでサーバーを理解するのかという問題にあたりますね。

AIコーディングで穴だらけのサービスが増えたら、それをAIが突破するのかなぁと少し御先不安になりました。

このことに関して私は、できるだけ裾野を広げて、どんな状況にも対応できるようなインフラ設計管理と堅牢なバックエンド開発の勉強についてまだまだ励んでいかなければいけないなとつくづく感じた事件でした。