PHPとHTTPS秘密鍵問題が発覚。安全のためWindowsやサーバーのアップデートを。

今週、インターネットの安全性に関わる大きな問題が2件同時に明らかになりました。認証局eMudhraの秘密鍵が、わずか8bit程度の強度しかなかった問題と、PHPに見つかった遠隔コード実行(RCE)の重大脆弱性です。どちらも「自分は関係ない」とは言い切れない内容です。ブラウザ、デバイスなどのOS、サーバーのモジュールを、ここ数日のうちに必ず更新してください。

結論：良いニュース？悪いニュース？

３つの意味で「すごく良いニュース」だと思っています。
まず、世界中で使われているPHPの「大穴」が見つかったことで修正がされます。　非常に危険な罠が世界中から、数十万も近い将来に消失します。　そしてこれを見つけたのがAIだということです。最近ではAIのせいで詐欺が増えた！という話題になっていますがAIが今後片っ端から「過去のプログラム資産」の検査をして一層の安全性が確保されることは明白です。そして最後の１つはPHPという言語がヤバイ、というのがやっと日本でも「広く強く」広まったことです。

ただし これで大騒ぎしてるのは AI 業界の広告の可能性があるということは最初に申し上げておきます。

正直なところ Webサイトがほとんどダメになっても一般の人はそれほど困りません。ほとんどは広告ですから。業界の人が騒いでるだけです。「風が吹けば桶屋が儲かる」 みたいなのがありますしね🙈

PHPが嫌いな件は個人的なバイアスです。わたしは過去に２０数年で Python,Python/Django,  GO, node.js,  Python/FastAPI  をWeb/APIサーバーとして使用していますが、PHPはその言語構造のヤバさに確信があり当初から断固として使用を反対、拒否してきました。（笑

日本では変わり者な私ですが海外では割と普通だということも一応、お断りしておきますね。

善意のハッカー（ホワイトハッカー）による活動も話題になっています。AI を使えることになったので作業は楽で、より多くのことができるようになっています。

該当するユーザー

鍵問題は今のところ悪用の報告はなく、eMudhraの証明書が実際に使われた形跡もないとされています。

PHPのほうはPHPでサイトを運営してたり、管理画面でPHPを使っている場合や
稀ですが業務用の一部のルーター、複合機などは管理画面にPHPを使っていることがあります。

昨夜からのPHP騒動とその理由

昨日の夜になって、突如大騒ぎになったわけですが、高市首相がなぜかXで個人アカウントで脆弱性の対応を呼びかけてしまい、余計に炎上した感があります。（高市首相のサイトもメンテに入って表示が最低なヘボいやつになっています。）

これは初期状態のサーバーインスタンスに切り替えたか、webサーバー apacheの初期状態ページに切り替えたと考えられますが誤解を与える見た目なので、これも炎上気味。国のトップとしてはもう少しマシな対応をしてほしいですが、これが日本の実力なのでしょう。

PHP問題が漏れるまで

この専門の人以外には技術的な細かいことを話しても面白くありませんし、知っても何かできることもありませんが、この問題の本質をよく理解するためにも、関連することとして業界の問題をちょっと語らせてください。🗿

実はこのノートを書いたのは昨日の朝方で、このお祭りについてのパートは22日の朝に追記しています。

大騒ぎになった理由として、ことの経緯を知る限り書くと、

ということで、混乱が広がりました。一方で お世話になっているcloudflareは対策を即座に出していたり、準備が整っていたのだろうなというのを感じました。

サーバーメンテーする側としては、普通であればこっそり対策したいところですが、話題になっていることと脆弱性レベルが高いため多くの事業者が早期にメンテモードに入りサービス停止が急速に広がりました。

今回のPHP脆弱性は最高レベルのものでPHPを外から操作できる（プログラムを実行できる🤮）ため、情報を引っこ抜いたりするだけではなく、そこを起点に他のサーバーへ攻撃踏み台にできる最悪なもので、サーバー利用側だけではなく一般ユーザーへの被害が予想されるものです。

PHP5~8にこの脆弱性がありますが、２１日夜にパッチが出ることがアナウンスされたのはPHP8だけで、他のものはソースのビルドなどPHP自体を自分で整備する必要があります。PHP5のリリースは2004年ですから20年以上も前から、実はやりたい放題になっていたのです。

それだけ利用者数も多いわけですが、レンタルサーバーだとバージョンが古かったりアップデートに対応していないこともあるので、運用の取りやめの告知も見受けられます。

（一夜明けてからのニュースはこちら）

PHP、本当の問題はどこか

今起きているPHP騒動の背景には技術だけではなく日本独特の問題も含めて、いつかの構造があります。

また、PHPの安全かどうかという話ですが、学術的なサイトの調査だと圏外です。　（Rust4.8、Pythonは3.8、Goは3.5でした。PHPは表示された範囲に入っていません）

これはたくさん使われてるし アップデートもされてるので安全じゃないということではないと思われますが、やはり専門家から見ると言語として問題あるし下世話な話になるので、あまり相手にしてないのかな？という気がします。

止めてはいけない文化

ユーザーの情報を保持していたり他のサーバーへの攻撃拠点にされる可能性があるため、社会・市民の安全を優先して「サービスを止めてメンテする」事を検討すべきですが日本では技術者以外の人が管理者、上司になることが多く「ダメだしが仕事」なので「止めてはいけない」風潮があり「徹夜で作業すべき」といったムードがあります。ただこれは脆弱性を逆に増やす可能性があり、急いでやれば正しいかというとそうでもないのです。

対応するのは人間ですから 急がされたり圧をかけられれば ミスが増えるのは当たり前です。もっと良くないのは 緊急対応 みたいなことは当たり前になるとまともな人は寄り付かなくなり、 結局は能力がない人ばかりになってしまうのです。

実際に ネットワーク管理部、インフラ関係は発達障害みたいな人が割合として多くなり、コミュニケーションがうまくできなかったり、社会全体諸々の文脈が理解できなくて経験的にはトラブルになることが多いのです。

下世話な話ですが、このことは実際にアンケート調査で「合コンに呼んで欲しくない職業第1位」として IT系が長い間君臨してたことからも証明されています。これは海外だとちゃめちゃモテることと対照的です。

問題の連鎖

脆弱性対応ではパッチが出た直後が危険とされています。

となるため、パッチがあたった直後に大きな侵入被害が起きることが過去のケースからもわかっています。

それと、みんなが一斉にパッチを当てたり対応することでサーバー資源が枯渇しインストールが途中で止まって環境が壊れるなど 副次的な問題が発生しやすくなるのは技術者ならよく知っていることです。
実際に 今回も、様々な問題が発生しています。

今回の脆弱性は極めて危険なものなので、一旦サービスを停止して高みの見物を決め込むぐらいの知恵を持って対応したいものす。

利益先取り、問題先送りでユーザーを犠牲に

そして、そもそもの問題はコストダウンのためにオープンソースの言語やフレームワークを使って「利益の先取り」と「リスクの先送り」をしているのが原因なので、本来は経営者や管理者はその責任を取り、技術者に押し付けるべきではありませんから、管理者の仕事上の「村」での立場のためにワーワーやるのではなく、社会的な安全保全の視点で落ち着いてやるべきことだと思います。徹夜をすれば効率やミスは増えますし、翌日に大きな問題が更に出たら目も当てられません。

マネジメント下手という養分

マネジメント後進国の日本では、大声で危機を叫んで仕事をしろ！徹夜で対応！という人がマネージャーになりがちです。会社がも具体的な策がなくマネージャーに丸投げ、マネージャーは外部の下請けに丸投げ、が基本路線です。自分はどっち側もやったことがあるのですが工場生産の文化が抜けないのかな？という感じがします。

ITの現場でPM と言われる人たち（プロジェクトマネージャー、プロダクトマネージャー）はコンピューターサイエンスもマネジメントも本格的に学んでない人ばかりです。

こうなると何が起きるかというと、本格的な問題は起こりうるはずだ、というシミュレーションや事前の技術選定、1日サーバーが止まった時の損失額の事前の計算と判断規定の策定、など準備がほとんどできないどころか、それ自体のアイデアも持っていないことがほとんどです。

彼らのほとんどの時間は村社会での関係性 自分の立ち位置の保全のために使われます。人類的にはクズなわけですが脆弱性の土壌であり、こういう人たちがいる前提で成り立ってるのです。

緊急性の誤謬

数で15万ほど、約70%のウェブサイトがPHPを使っていると言われており大問題というのは当然そうなのですが、これらのサーバーのほとんどは止めても私たちの生活に影響はないものです。

理由は個人のブログ、 WordPress利用のような広告を主体としたサイトがほとんどだからです。また作ったまま放置してるものも多数あると考えられ調査ではPHP5~7 の古いサイトは３０％ほどあるそうです。
PHPは導入も簡単でサーバーにも元々入ってたりするので専門で人が使うというケースが多く、これが放置されることで攻撃者に利用されやすい理由としても長年指摘されているところです。

なので一般の人はサービスが止まることを心配するより、被害に遭わないことにフォーカスすべきです。

そして運営してる人たちは余程の理由がない限りは公開を止めて落ち着いて対応するというのが 今回のかなり重篤な脆弱性での責任ある対応だと技術者としては考えています。

実際に、政府の専門部署もそのように今回は告知をしていますし、首相自らのサイトがしょぼーい表示（ It works! / 動いた！）になっています。流石にもう少しマシなこと出せよ、っておもいましたが。これはデフォルトの表示なのでまあ最短、最小工数でお願いしたのでしょう。

しかし本業の部署からは行かように真っ当な呼びかけがなされていまして、これは本当に良いことだと思いました。

また、PHPには他にも脆弱性が複数公開されていますし、後述する鍵問題もあります。普段体制、対応がない組織が徹夜をして無理に進めるような状況かは疑問です。(これについては現代の潮流を別に書く予定です）

（他にも続々と…しばらくはこの状態が平常運転として淡々と仕事ができる状況をキープするべきです。）

PHPへのアタックを確認する方法

PHP関連ファイルの確認、過去の脆弱性のクローリングはいつも通り大量に来ています。以下はほんの一部ですが、常に大量の脆弱性確認アクセスが来ています。

107.172.87.210 - - [21/Oct/2026:15:16:55 +0900] "GET /tests/vendor/phpunit/phpunit/src/Util/PHP/eval-stdin.php HTTP/1.1" 404 162 "-" "libredtail-http"
107.172.87.210 - - [21/Oct/2026:15:16:59 +0900] "GET /test/vendor/phpunit/phpunit/src/Util/PHP/eval-stdin.php HTTP/1.1" 404 162 "-" "libredtail-http"
107.172.87.210 - - [21/Oct/2026:15:17:03 +0900] "GET /testing/vendor/phpunit/phpunit/src/Util/PHP/eval-stdin.php HTTP/1.1" 404 162 "-" "libredtail-http"
107.172.87.210 - - [21/Oct/2026:15:17:08 +0900] "GET /api/vendor/phpunit/phpunit/src/Util/PHP/eval-stdin.php HTTP/1.1" 404 162 "-" "libredtail-http"
107.172.87.210 - - [21/Oct/2026:15:17:12 +0900] "GET /demo/vendor/phpunit/phpunit/src/Util/PHP/eval-stdin.php HTTP/1.1" 404 162 "-" "libredtail-http"
107.172.87.210 - - [21/Oct/2026:15:17:16 +0900] "GET /cms/vendor/phpunit/phpunit/src/Util/PHP/eval-stdin.php HTTP/1.1" 404 162 "-" "libredtail-http"
107.172.87.210 - - [21/Oct/2026:15:17:20 +0900] "GET /crm/vendor/phpunit/phpunit/src/Util/PHP/eval-stdin.php HTTP/1.1" 404 162 "-" "libredtail-http"
107.172.87.210 - - [21/Oct/2026:15:17:24 +0900] "GET /admin/vendor/phpunit/phpunit/src/Util/PHP/eval-stdin.php HTTP/1.1" 404 162 "-" "libredtail-http"
107.172.87.210 - - [21/Oct/2026:15:17:28 +0900] "GET /backup/vendor/phpunit/phpunit/src/Util/PHP/eval-stdin.php HTTP/1.1" 404 162 "-" "libredtail-http"
107.172.87.210 - - [21/Oct/2026:15:17:31 +0900] "GET /blog/vendor/phpunit/phpunit/src/Util/PHP/eval-stdin.php HTTP/1.1" 404 162 "-" "libredtail-http"

調べ方はこちら。２００が返ったものは「無し」なので正常運転でした。

# 21日・22日のPHP関連だけ
zgrep -hE "2[12]/Oct/2026" /var/log/nginx/access.log* | grep -iE "\.php|cgi|\.env|vendor"

# 200が返ったものだけ（ここが重要）
zgrep -hE "2[12]/Oct/2026" /var/log/nginx/access.log* | grep -iE "\.php|cgi|\.env|vendor" | awk '$9 == 200'

# 21日・22日に来た攻撃元IPの集計
zgrep -hE "2[12]/Oct/2026" /var/log/nginx/access.log* | grep -iE "\.php|cgi|\.env|vendor" | awk '{print $1}' | sort | uniq -c | sort -rn | head

アクセスを確認。PHPは使っていないので全て４０４です。

$ zgrep -h "147.224.143.42" /var/log/nginx/access.log* | awk '{print $9}' | sort | uniq -c
    669 404
$ zgrep -h "147.224.143.42" /var/log/nginx/access.log* | awk '{print $7}' | sort | uniq -c | sort -rn | head -15
      1 /.zsh_history
      1 /wwwroot/.env.production
      1 /wwwroot/.env.local
      1 /wwwroot/.env
      1 /workspace/startup.log
      1 /workspace/start.sh
      1 /workspace/stable-diffusion-webui/webui-user.sh
      1 /workspace/stable-diffusion-webui/.env
      1 /workspace/logs/startup.log
      1 /workspace/.env.production
      1 /workspace/.env.local
      1 /workspace/.env.bak
      1 /workspace/.env
      1 /workspace/entrypoint.sh
      1 /workspace/ComfyUI/.env

こういう事はAIにいくらでも相談できるようになり今回の脆弱性もAIが見つけて手当できたので、AIがヤバイ！ではなく実際には盾と鉾の物語が今後も続くのだと思います。そもそも悪いことをする人がいるからなのですしね。

今回のPHP2shellの確認方法

error.log

zgrep -HnEi 'Allowed memory size.*exhausted|Unknown on line 0|Out of memory|SIGSEGV|Segmentation fault|zend_mm_heap corrupted|exited on signal 11' error.log*

access.log

zgrep -HnE 'POST ' access.log* | grep -E ' (500|502|503) ' | awk '{print $1}' | sort | uniq -c | sort -nr

ということで、ここからは２つの問題の概要解説です。

① eMudhraの認証局鍵問題:384bitのはずが、実際は8bit以下

インドの認証局eMudhraが持つ中間CA証明書8本の秘密鍵は、誰でもほぼ一瞬で復元できる状態でした。本来は384bit(P-384)の巨大な乱数であるべき鍵が、実際には4、56、66、115、155、156、230、237といった、1〜255程度の小さな整数だったのです。これは約255通りを総当たりするだけで解けるため、研究者は公開されている証明書の情報だけから、すぐに秘密鍵を割り出せました。

何が起きえるか

悪用されると通信が丸見えになってしまいます。通常は暗号化されて通信をしているので パスワードとかどこにアクセスしたか とか 何を話したか とかわからないのですが、解読されて丸見えになってしまう危険があるわけです。

仕組み

認証局の鍵を手にした人は、どのWebサイトにも、ブラウザやアプリが信頼する偽の証明書を発行できます。通信の盗聴や、本物そっくりの偽サイトを作る攻撃に悪用できるため、認証局にとっては致命的な問題です。

経緯と現状

• 10月17日:研究者が発見し、Mozilla、Google、Apple、Microsoftなどのルート証明書プログラムに報告

• eMudhraは、2025年4月に使った鍵生成スクリプトのミスが原因だと説明。弱い鍵が混入し、署名用に誤って選ばれたとしている

• 8本の中間証明書はすでに失効済みで、新規発行も停止。Mozilla、Google、Appleは該当の証明書をブロック済み

• eMudhraは、多くは本番で使われておらず、悪用の証拠もないとしている。ただし、弱い鍵は2025年4月から悪用が可能だった

注意したい点

• 弱かったのは、発行済みのすべての証明書ではなく、証明書を発行するCA側の中間証明書の鍵です。ただし、そこから偽の証明書を作れるため、影響は広範囲に及びます

• 失効(無効化)しても、失効の確認をしないソフトウェアには効果がありません。ブラウザ側のブロックが届いていない古い端末、VPN機器、独自の証明書ストアを持つアプリは特に注意が必要です。

追記）
eMudhraは今回の問題を受けて、SSLから撤退を発表しています。ブランド名どころじゃないですし、あまり反省もなく捨て台詞的に発表していなくなる感じですね。

② PHPの重大脆弱性:認証なしで遠隔からコード実行の恐れ

PHPチームは、CVE-2026-109618とCVE-2026-109619の2件の重大な脆弱性について、臨時のセキュリティリリースを予告しました。どちらもCVSS v4.0で9.2と評価され、認証なしの遠隔コード実行(RCE)につながる可能性があります。技術的な詳細は、修正版の公開まで明らかにされていません。
※その後パッチが公開されました。

PHP対応の概要

下のバージョン以上に更新が必要です。

※レンタルサーバーの場合は、サーバー会社が修正版を提供するまで更新できないこともあります。

• 対象:PHP 5.4以降の全バージョンに及ぶとされ、WordPress、Magento、Shopware、WooCommerceなど、PHPで動くWebサイトやECサイトが含まれる

• 修正版の公開予定:2026年10月21日14:00(UTC)=日本時間23:00。情報漏えいや攻撃の兆候があれば前倒しになる

• 現状:10月21日時点で、悪用の報告や公開された攻撃コードは確認されていません。ただし、セキュリティ企業は、修正版の公開直後から大規模な攻撃が始まると警告しています

• サポート終了のバージョン:PHP 8.1以前、8.0、7.x、5.xはすでにサポートが終了しており、修正版は提供されません。これらを使い続けているサイトは、バージョンアップが必要です

「PHP 5だけの問題」ではなく、PHP 5以降の幅広い系列に影響が及ぶ可能性がある点に注意してください。また、内部で使っている製品があり、機器メーカーの公式サイトで、セキュリティ情報やファームウェア更新を確認する必要があります。

今すぐやったほうが良さそうな事

一般の利用者

[ ] ブラウザ(Chrome、Firefox、Safari、Edgeなど)を最新にする

[ ] Windows、macOS、iOS、Androidを最新にする

[ ] ルーター、VPN機器、NASなどのファームウェアを確認する

[ ] 古くて更新が止まった端末やアプリは、使用を控えるか買い替えを検討する

サイト運営者・サーバー管理者

[ ] 使っているPHPのバージョンを確認する(php -v、レンタルサーバーの管理画面など)

[ ] 修正版が公開されたら、当日〜数日以内に適用する

[ ] PHP 8.1以前、7.x、5.xなどサポート終了のバージョンは、対応バージョンへの移行計画を立てる。すぐに移行できない場合は、アクセス制限やWAFの導入で、公開範囲を一時的に絞る

[ ] WordPress本体、テーマ、プラグイン、ECシステムも更新する

[ ] 不審なログイン、見覚えのないファイル、改ざんの跡がないかログを確認する

[ ] 自社だけでなく、委託先や外部サービスのPHP環境にも確認を依頼する

証明書まわり(開発者・運用者)

[ ] 独自に証明書ストアを管理しているアプリや機器は、eMudhraの該当中間証明書を信頼しない設定にする

[ ] 証明書の失効確認(OCSP、CRL)が有効かどうかを見直す

おわりに

PHPの脆弱性問題は当初からあり、作者も「失敗作で酷いものだった」と反省を述べています。わたしは古典的プログラマーなので２０年数前にPHP4の仕様を見たときには正直、あまりの酷さに目を疑いました。

もちろん当時から使うのに反対で、Pythonなど別の言語でWeb構築をしてきました。

言語仕様だけではなく駆動する実行基盤に問題がありすぎるものですが、酷い＝簡単なので短い期間で習得できるため、目先の利益を優先して安全性を犠牲にしてきた負債が噴出しているのが本当のところです。

多くの問題はPHP８まで20年かけてかなり修正されましたが依然として本質的な問題は残っており、だからこそバージョン 5から8まで今回の脆弱性となっています。

また、PHPには暗い側面もあります。それは「簡単」＝「安い仕事」として早くから「負け犬が使う言語」として欧米やロシアではバカにされ、移民やオフショア開発（まさにベトナムITがそれです）の仕事となっていました。
日本は幸い？士農工商の習慣がある成果、技術者は底辺扱いでやすいため国内技術者がPHPにとどまる残念なことになっています。

私が欧米のテックマンからPHPは「負け犬の仕事」と聞いたのは15年くらい前ですが、現在は中国もそうなっているようです。

同じように、ベトナムの技術者も現在は困っている人たちがたくさんいます。夢を描いて 日本語屋PHPを学んだのにどちらも オワコンになったからです。

認証局の鍵問題も、ここまで弱かった例は異例ですし、PHPのRCEは公開直後に攻撃が集中しやすい種類の脆弱性です。ブラウザ側のブロックは進んでいますが、更新されていない端末やサーバーが、最も狙われやすくなります。確認と更新は、早いほど安全です。身近な運営者や取引先にも、ぜひ共有してください。

• BleepingComputer:Mozilla、Google、AppleがeMudhraの侵害された証明書をブロック

• Mozilla Bugzilla:eMudhra中間証明書の秘密鍵漏えい

• CoinDesk:eMudhraの秘密鍵8本が解読された件

• CERT-EU:Security Advisory 2026-018(PHPの重大な脆弱性)

• The Hacker News:PHP2Shell

• Sansec:PHPのRCE(CVE-2026-109618・CVE-2026-109619)

情報は2026年10月21日時点のものです。PHPの修正版の公開後は、対象バージョンなどが更新される可能性があります。