はじめに
初めまして。あんじゅんです。
普段はエンジニアとしてシステムを開発しながら、バンドでギターを弾いています。
休日はギターでコードを鳴らし、平日はパソコンに向かってコードを書いています。
今回は、2026年10月に話題となったPHPやNode.jsの脆弱性について書いてみたいと思います。
特にPHPでは、以下の重大な脆弱性が報告されました。
- CVE-2026-109618
- CVE-2026-109619
その名も「PHP2Shell」。
ハードコアバンドみたいな名前ですね。
どちらも不穏な空気とヒリヒリとした緊張感があります。
エンジニアの方にはおなじみかもしれませんが、PHPもNode.jsも、さまざまなWebサイトやサービスの裏側を支えている技術です。
今回はこれらの脆弱性を、ライブハウスやエフェクターボードに例えながら説明してみます。
厳密な内部実装の解説というより、脆弱性とは何なのか、今回何が起きたのか、そしてなぜ危険なのかを理解することが目的です。
最後には、AIによる脆弱性の自動修復と、エンジニアの責任についても少し考えてみます。
1. PHPとNode.jsって何？
まず、PHPとNode.jsについて。
PHPはプログラミング言語、Node.jsはJavaScriptをサーバー側などで動かすための実行環境です。
どちらもWebアプリケーションのバックエンドなどで使用されています。
例えばライブハウスのホームページ。
出演者を表示したり、チケットを予約したり、お問い合わせを受け付けたり。
こうした処理の裏側でPHPやNode.jsが使われていることがあります。
音楽で例えるなら、ライブハウスのスタッフです。
お客さんから見えるのはステージと出演者ですが、裏側ではPA、照明、受付、ブッキング担当などが働いています。
つまり、見えているWebサイトがステージなら、PHPやNode.jsは裏方の仕事を動かす仕組みです。
裏方がいなければライブは成立しません。
ちなみに、バンドマンもライブが成立しなくなります。
2. 脆弱性って何？
脆弱性とは、簡単に言えばソフトウェアやシステムのセキュリティ上の弱点です。
ライブハウスで考えてみましょう。
普通、ライブハウスに入るにはチケット代を払います。
受付でお金を払い、ドリンク代を払い、ようやく入場できます。
ところが、ある日こんなことが発覚しました。
「受付で特定の言葉を言うと、無料で入場できてしまう」
しかも受付の人は、それが正しい手続きだと思い込んでいる。
これが脆弱性のイメージです。
本来は許可されていない行動が、仕組みの問題によって可能になってしまう。
プログラムでも同じことが起こります。
本来は見られない情報を見ることができたり、操作できない機能を操作できたりします。
さらに厄介なのは、普段は何の問題もなく動いていることです。
いつも通りライブは開催されるし、受付もちゃんと機能している。
でも、特定の方法を知っている人だけが不正に入場できる。
つまり、正常に動作していることと、安全であることは別の話なんですね。
バンドマンにも心当たりがあると思います。
リハーサルでは完璧だった機材が、本番の一曲目で突然死ぬ。
もちろん、単なる機材トラブルとセキュリティ上の脆弱性は異なりますが、普段の正常動作だけでは潜在的な問題を発見できないという点は共通しています。
3. PHP2Shellでは何が起きたのか？
さて、今回のPHP2Shell。
2026年10月21日、PHPのメモリ管理やリクエスト処理に関係する2件の脆弱性に対して修正版が公開されました。
| CVE | 概要 |
|---|---|
| CVE-2026-109618 | メモリ不足（OOM）時の処理に起因するメモリ破損 |
| CVE-2026-109619 | 解放済みメモリを参照し得る状態管理の問題 |
いずれも、条件によっては遠隔から任意のコードを実行される可能性があります。
ここでいうOOM（Out of Memory）は、利用可能なメモリが不足した状態を指します。
エフェクターボードで考えてみましょう。
エフェクターをたくさん接続すると、それぞれを動かすための電力が必要になります。
ところが、パワーサプライにも供給できる電力の上限があります。
消費電力の大きなデジタルエフェクターを大量につなぐと、電力が足りなくなって正常に動かないことがあります。
「あと一個くらいいけるだろ」と思ってつないだ空間系が、ボード全体を道連れにするわけです。
今回のPHPでは、こうしたリソース不足などの異常な状況を処理する仕組みに問題がありました。
ただ単にプログラムが停止するだけなら、まだマシです。
問題なのは、その不具合を悪用すると、外部の人間がサーバー上で勝手にプログラムを動かせる可能性があることです。
これは「リモートコード実行（RCE：Remote Code Execution）」と呼ばれます。
先ほどのエフェクターボードに戻りましょう。
電力不足でエフェクターが停止する。
ここまでは普通に困ります。
しかし、仮にその不具合を利用して、客席にいる知らない人がエフェクターの設定を勝手に変更できるとしたらどうでしょうか。
しかも、ディレイタイムを変えるだけでなく、ボードに接続された他の機材まで操作できてしまう。
イントロのクリーンアルペジオが突然BIG MUFFフルテンになったら、さすがに困ります。
もちろん、実際のPHP2Shellがエフェクターの電源不足と同じ仕組みで発生するわけではありません。
今回問題となったのは、PHP内部のメモリ状態が適切に管理されず、不正なメモリアクセスなどにつながる可能性があることです。
そして重要なのが、条件によっては認証されていない外部の第三者でも攻撃を成立させられる点です。
つまり、パスワードを知られていなくても危険な場合があるわけです。
影響を受けるPHPのバージョン
PHP公式が公表している修正バージョンは以下のとおりです。
| PHP系列 | 影響を受けるバージョン | 修正バージョン |
|---|---|---|
| PHP 8.2 | 8.2.35より前の同系列 | 8.2.35 |
| PHP 8.3 | 8.3.36より前の同系列 | 8.3.36 |
| PHP 8.4 | 8.4.27より前の同系列 | 8.4.27 |
| PHP 8.5 | 8.5.12より前の同系列 | 8.5.12 |
上記以外の古い系列についても、サポート状況や利用しているディストリビューション、サービス提供元の対応情報を確認する必要があります。
なお、影響を受けるPHPのバージョンを使用しているからといって、必ず外部から攻撃が成立するという意味ではありません。
実際のリスクは、PHPの実行方式やWebサーバー構成、攻撃可能な経路などによって変わります。
4. Node.jsでも何か起きたらしい
続いてNode.jsです。
こちらも2026年10月21日にセキュリティアップデートが公開されました。
今回の修正には、DNSの名前解決に関する脆弱性「CVE-2026-105482」などが含まれています。
DNSとは、ざっくり言えばインターネット上の名前から接続先を調べるための仕組みです。
今回の問題では、特定の文字を含むホスト名が途中で切り詰められ、意図しない名前が解決される可能性がありました。
ライブハウスのブッキングで考えてみましょう。
「来月、あのバンドを呼びたい！」
という話になり、出演依頼を送るとします。
ところが、相手の名前を確認する仕組みに問題があり、特定の書き方をされた名前を途中までしか読んでいなかった。
その結果、本来とは違う相手を正しい相手として扱ってしまう可能性があります。
Faraquetを呼んだつもりが、知らない人のカラオケ大会が始まったら困ります。
しかも、チケット代はそのままです。
実際のNode.jsの問題も、名前の解釈の違いが、アプリケーション側のセキュリティチェックをすり抜ける原因になる場合があるというものです。
例えば、接続先のホスト名を検証する処理と、実際に名前解決する処理で、異なるホスト名として解釈される可能性があります。
ただし、今回のNode.jsの脆弱性すべてが同じ問題というわけではありません。
修正対象となったバージョンは次のとおりです。
| 系列 | 2026年10月21日の修正版 |
|---|---|
| Node.js 22.x | 22.23.4 |
| Node.js 24.x | 24.22.1 |
| Node.js 26.x | 26.12.1 |
重要なのは、プログラムが相手を正しく確認しているつもりでも、その確認処理自体に問題がある場合があるということです。
人間も同じですね。
「大丈夫です！」「できます！」と自信満々に言う人ほど、本当に大丈夫なのか確認した方がいいことがあります。
特に「転換10分でいけます」は慎重に判断しましょう。
5. で、実際に何が危ないの？
ここまで、PHPやNode.jsの脆弱性について説明しました。
では、実際に何が危ないのでしょうか。
例えば、バンドのホームページ。
ライブ情報を掲載したり、チケット予約を受け付けたりしていると思います。
仮に、そのホームページのサーバーにある脆弱性を攻撃者が悪用し、十分な権限を得てしまった場合、何が起きるでしょうか。
- ホームページを書き換えられる。
- 予約したお客さんの情報を盗まれる。
- 偽物のチケット購入ページに誘導される。
- サーバーを利用して別のサイトへ攻撃を行われる。
いずれも、攻撃者が獲得した権限やシステム構成によっては起こり得る被害です。
つまり、自分たちのホームページが、知らないうちに誰かの悪事に利用される可能性があるわけです。
ライブハウスで例えるなら、知らない人間が勝手に受付に立ち、お客さんからチケット代を徴収しているようなものです。
しかも、出演バンドには一円も入りません。
普段からノルマやスタジオ代を払っているのに、これ以上財布が軽くなったらたまりませんね。
もちろん、脆弱性が存在するからといって、これらの被害がすべて発生するわけではありません。
脆弱性があること、攻撃が成立すること、実際に被害が発生することは、それぞれ別の段階です。
この区別は、脆弱性対応の優先度を判断するうえでも重要になります。
6. 何で今まで普通に動いていたの？
ここで疑問が出てくると思います。
PHPもNode.jsも、何年も前から使われている技術です。
今まで普通に使えていたのに、なぜ突然危険だと言われるのでしょうか。
これは、エフェクターの不具合と少し似ています。
普段は問題なく使えているエフェクターでも、特定の電源や接続方法でだけ不具合が起こることがあります。
そして、その問題が何年も発見されない場合もあります。
プログラムも同じです。
正常系のテストがすべて成功していても、異常な入力や特殊な実行状態で想定外の動作をする場合があります。
つまり、昨日突然壊れたのではなく、今まで気づかなかった問題が見つかったというケースがあるわけです。
ここで怖いのが、脆弱性の情報が公開されると、攻撃者にもその情報が伝わる可能性があることです。
だからこそ、修正されたバージョンへのアップデートが重要になります。
ただし、アップデートによって既存の機能が動かなくなる可能性もあるため、事前の影響確認やテストも必要です。
エフェクターのファームウェア更新と似ています。
アップデートしたら、昨日まで使えていたプリセットの挙動が変わっていた。
そんなことになれば、ライブ前に困ります。
実際のシステムでは何を確認するのか？
今回のような脆弱性への対応では、例えば次のような確認を行います。
- 利用しているPHP・Node.jsのバージョンを確認する。
- 公式情報から影響の有無と攻撃が成立する条件を調べる。
- 修正版への更新による影響範囲を確認する。
- 必要に応じてバックアップを取得し、検証環境でアップデートする。
- 既存機能や関連するテストが正常に動作するか確認する。
- 本番環境へ反映し、動作やログを確認する。
なお、コンテナ環境やマネージドサービスでは、ローカルで確認したPHP・Node.jsのバージョンが本番環境と一致するとは限りません。
また、OSやクラウド事業者が独自にセキュリティ修正をバックポートしている場合もあるため、単純なバージョン番号の比較だけでは判断できないことがあります。
7. AIがあれば、エンジニアはいらなくなる？
さて、ここまで脆弱性について説明してきましたが、最近はAIという便利なものがあります。
文章を書いたり、画像を作ったり、プログラムを書いたり。
僕も仕事で毎日のように使っています。
最近では、AIがプログラムの問題を見つけたり、修正したりすることもできるようになってきました。
では、ここで一つ疑問が生まれます。
AIがプログラムを書いて、AIが脆弱性を発見して、AIが修正する。
それなら、もう人間のエンジニアはいらないのでは？
個人的には、ここで一つ問題があると思っています。
それは、AIが行った修正が本当に正しいのか、誰が判断するのかという問題です。
例えば、AIが脆弱性を自動で修正して、プログラムをアップデートしたとします。
脆弱性は解消されたかもしれません。
でも、その修正によって別の機能が壊れていたら？
あるいは、脆弱性が直ったように見えて、実は別の問題が残っていたら？
AIが「修正しました！」と言っても、それをそのまま信用していいのかという話です。
音楽で例えてみましょう。
あなたは90年代のエモをやっているバンドのメンバーです。
ある日、ギタリストにこんなお願いをしました。
「このソロ、アドリブっぽく好きに弾いてほしい！」
すると、ギタリストは突然エフェクターを全部踏み、ギターからジャックを引き抜き、トム・モレロみたいなノイズとワーミーでソロを始めました。
いや、そういうことじゃない。
もちろん、たまたま曲にハマったら最高だと思います。
むしろ、予想外のアプローチから名曲が生まれることだってあるでしょう。
でも、全然曲にハマっていなかったらどうでしょうか。
「好きに弾いていいとは言ったけどさ……」
流石に僕も「えぇ……」ってなります。
これ、AIにも似たようなことが言えると思っています。
AIは指示に従って、それらしい答えを出してくれます。
しかも、人間が思いつかなかったような解決策を提案してくれることもあります。
でも、その答えが本当に目的に合っているのかを判断することと、答えを出すことは別の話です。
プログラムも同じです。
修正によって何が変わったのか。
本当に問題は解決したのか。
ほかの機能に影響はないのか。
こうしたことを確認し、最終的に採用するかどうかを決める必要があります。
もちろん、AI自身にテストや検証をさせることもできます。
ただ、そのテストで何を確認すれば十分なのか、どこまでのリスクを許容するのかという判断は残ります。
組織のトップがその判断と責任を引き受けるなら、エンジニアはその方針に従って対応することもあるでしょう。
一方で、技術的な判断をエンジニアに任せるのであれば、その判断に対する責任も伴います。
つまり、僕はAIによってエンジニアの仕事は大きく変わっても、判断と責任まで自動的になくなるわけではないと思っています。
ギターを弾くのがAIになったとしても、そのソロを曲に採用するかどうかは別の問題です。
もっとも、トム・モレロみたいなソロを弾いてくれるAIがいたら、僕は一度くらい使ってみたいです。
8. まとめ
今回はPHP2ShellとNode.jsの脆弱性について、音楽に例えながら説明してみました。
今回伝えたかったことは、大きく分けて3つです。
- 普通に動いているプログラムにも、セキュリティ上の弱点が存在する可能性がある。
- 脆弱性の悪用によって、本来許可されていない操作が行われる場合がある。
- 脆弱性を修正するだけでなく、その修正の妥当性や既存機能への影響を確認することが重要である。
もちろん、PHPやNode.jsを使っているサイトがすべて危険というわけではありません。
重要なのは、利用しているバージョンや実行環境、外部からのアクセス経路などを把握し、適切な対策を取ることです。
僕らバンドマンも、普段から機材の調子を確認したり、弦を交換したり、エフェクターのアップデートをしたりします。
Webサイトも同じように、動かし続けるためのメンテナンスが必要になります。
そして、個人的には音楽とプログラミングはこういう部分でも似ていると思います。
どちらも複雑な仕組みが組み合わさって、一つのものが成立しています。
それぞれの役割が正しく機能しているからこそ、全体が成り立っている。
逆に、一つの問題が全体に影響することもあります。
たった一本のシールドが死んだだけで、ギタリストがステージ上で完全に無力化されるように。
まあ、僕の場合はシールドが生きていても大して変わらないかもしれません。
それでは、また。
参考資料
元記事
本記事は、noteに投稿した「バンドマンのための、PHPの脆弱性の話」を、Qiita向けに技術的な情報を補足して再編集したものです。