脆弱性は「どの層」で起きたのか：言語の脆弱性と、CMS の設計の話を分けて考える

Dixlase（ディクセイラス）を開発している、エクシーディーの柏原（カッシー）です。

2026 年 10 月 21 日に、PHP 本体の重大な脆弱性（CVE-2026-109618／109619、通称 php2shell）が公表されました。
Dixlase をお使いの方へのお願いは、先日の記事「PHP の脆弱性（php2shell）について」にまとめています。

PHP の脆弱性（php2shell）について：Dixlase の対応

そのあと、私のSNSの周りでは「PHP は歴史が長いぶん、仕組みが古いのでは」「そろそろ別の言語の仕組みに移るべきでは」など、様々な声も見かけるようになりました。
不安に思うのは自然なことです。

ただ、ここで確かめておきたいことが 2 つあります。
1 つは、今回の脆弱性が「どの層」で起きたのか。もう 1 つは、「PHP は仕組みが古いから危ない」「ほかの言語なら安全」というのが、事実として正しいのか、です。
この 2 つを分けて見ていくと、何をすればよいかがはっきりします。

今回は、その見分け方を書いてみます。

ウェブサイトは、いくつもの層でできている

CMS で動くウェブサイトは、ひとつのソフトウェアではなく、いくつもの層が重なってできています。
脆弱性は、そのどの層でも起きえます。そして、層によって、直す人も、利用者がすることも違います。

下の表では、上にあるほど、利用者から見える部分に近く、下にあるほど、ほかの層が動く土台にあたります。
下の層で問題が起きると、その上に重なるすべての層に影響が及びます。

サーバーそのもの（OS やウェブサーバー）は、言語よりもさらに下の土台です。
一方で、設定やパスワード、バックアップといった運用は、どこか 1 か所ではなく、どの層にもかかわります。

今回の php2shell は「言語・実行環境」の層

今回の脆弱性は、表の下のほう、土台にあたる PHP そのものの層で起きました。

そのため、特定の CMS の問題ではありません。
どの CMS を使っているか、CMS を使っているかどうかにかかわらず、PHP で動いているサイトやサービスは、どれも対象になりました。

出典：The Hacker News／Help Net Security

この層の脆弱性は、言語の開発チームが修正版を出し、利用者がそれに更新すれば閉じる種類の問題です。
今回も、PHP は 10 月 21 日に修正版を出しました。

ここで、修正版に更新するのは、サイトを運営する人ではなく、サーバーを管理する人です。
小規模な VPS や自分で用意したサーバー、Docker で動かしている場合は、サイトを運営する人がサーバーの管理も兼ねていることが多いので、その人が PHP を更新します。
専用サーバーや社内のサーバーなどで、サイトの運営とサーバーの管理の担当が分かれている場合は、サーバーの担当者が更新します。サイトを運営する人は、更新が済んだかを担当者に確かめてください。
レンタルサーバーでは、PHP の更新はサーバーの会社の作業で、サイトを運営する人にはできません。サーバーの会社からの案内を確かめてください。

一方で、この層の問題は、その上で動く CMS の側では直せません。
Dixlase を更新しても、今回の脆弱性が直らなかったのはそのためです。
CMS の開発元にできるのは、何をすればよいかを早く、分かりやすく伝えることと、配っているもの（Dixlase の場合は Docker のインストーラー）を更新しやすくすることです。

どんな脆弱性だったのか

今回の 2 件は、C 言語で書かれた PHP 本体の中で、メモリの扱いに不備があったことによるものです。どちらも、ログインしていない人が、外から PHP にコードを実行させられるおそれがありました。

• CVE-2026-109618：処理の途中でメモリが足りなくなったとき、作りかけのデータが残り、そのあとの片づけの処理がそれを正しいデータとして扱ってしまう問題です。
• CVE-2026-109619：一度解放したメモリを、あとで使ってしまう問題（Use-After-Free）です。あるリクエストの処理で残った古い状態を、同じワーカーが次に受けたリクエストで使ってしまいます。

PHP によると、Apache に組み込んで動かす形（mod_php）では、アプリケーションのコードが動き始める前の段階で突けることが確かめられています。そのため、アプリケーションの側でログインの確認を固めても、この脆弱性は防げません。ほかの動かし方でも、PHP を更新する必要があることは変わりません。

出典：Tenable「php2shell (CVE-2026-109618, CVE-2026-109619): Critical PHP RCE FAQ」／The Hacker News

「言語が古い」と「危ない」は、別の話

今回の事態でSNS で「PHP は歴史がある一方で、仕組みが古い。そろそろ新しい環境に移る時期では」など様々な意見を見かけました。
たしかに、今回の欠陥は、長いあいだ PHP の中に残っていたものでした。ただ、歴史の長さや、仕組みの古さと、安全さは、直接にはつながりません。

たとえば、PHP は 1995 年にソースコードが公開された、30 年ほどの歴史がある言語です。
ただ、その後も新しい版のたびに中身が見直されてきました。PHP 8 では、型の扱いの強化や JIT（実行を速くする仕組み）など、大きな改良が入っています。

2010 年には、年に一度新しい版を出す決まりが作られました。いまも、8.2（2022 年）、8.3（2023 年）、8.4（2024 年）、8.5（2025 年）と、毎年新しい版が出ています。

出典：PHP Manual「History of PHP」／PHP 8.0 Release Announcement／PHP RFC「Release Process」／PHP「Supported Versions」

また、言語を動かす処理系（実行環境）の脆弱性は、PHP だけのものではありません。
JavaScript を動かすエンジン（V8）でも、2026 年 9 月に、実際に悪用された脆弱性が見つかり、修正されています。

出典：The Hacker News（2026 年 9 月）

php2shell の修正版が出たのと同じ 10 月 21 日には、JavaScript の実行環境である Node.js も、10 件の脆弱性を修正しました。そのなかには、リモートからコードを実行されるおそれのあるもの（Brotli の展開の処理）も含まれています。

出典：Node.js「Wednesday, October 21, 2026 Security Releases」

言語のまわりの仕組みにも、それぞれのリスクがあります。
2025 年には、JavaScript のパッケージを配る仕組み（npm）で、パッケージを次々に乗っ取って広がる攻撃が起き、米国の CISA が注意を呼びかけました。

出典：CISA「Widespread Supply Chain Compromise Impacting npm Ecosystem」（2025 年 9 月 23 日）

これは PHPやJavaScript が悪いということではありません。どの言語にも、どの層にも、リスクはあるということです。
大事なのは、脆弱性が見つかったときに修正が早く出ることと、利用者がそれにすぐ更新できる体制があることだと考えています。

AI で、脆弱性が見つかる速さが変わった

今回の php2shell では、AI がもう一つの役割を果たしました。

報道によると、研究者は AI のモデルを使うことで、長く残っていた問題を、実際に攻撃できる形にまで確かめる作業を大きく速めました。チームで数か月かかる作業を、1 人で 1 週間ほどでできたと述べています。
この問題は、PHP の開発者も 2024 年に気づいていましたが、直し方の合意ができず、修正が止まっていたと報じられています。

出典：The Hacker News／The Next Web

速くなったのは、守る側だけではありません。
Amazon は、AI を使った分析によって、修正の内容から攻撃の方法を組み立てるのが安く、速くなっていると指摘しています。脆弱性が公開されてから、攻撃が始まるまでの時間は、これからも短くなっていくと考えられます。

出典：Amazon Threat Intelligence

今回の脆弱性を見つけた側の一つである OpenAI も、今回の件は、すでに見つけて修正を進めている重大な脆弱性のうちの一つにすぎず、同じような発見は今後数か月で急増すると見込んでいる、としています。

出典：OpenAI「Patch the Planet: global response coordination as agents uncover critical vulnerabilities」（2026 年 10 月 21 日）／ITmedia AI＋（2026 年 10 月 22 日）

これは、PHP だけの話ではないと私たちは考えています。
古くから使われているソフトウェアほど、長いあいだ見過ごされてきた問題が残っている可能性があります。AI の助けで、PHP 以外の言語やソフトウェアでも、これから新しい脆弱性が見つかることは十分に考えられます。

見つかる問題が増えるのは、怖いことのようにも見えます。
ただ、見つかって直されることで、ソフトウェアは安全になっていきます。大切なのは、見つかったときに早く直され、利用者がすぐに更新できることです。

拡張の安全さは、言語ではなく「設計」の話

CMS の話でよく出てくる「プラグインの脆弱性」は、表の「拡張」の層の話で、言語の脆弱性とは別のものです。

CMS には、プラグインが本体と同じところで動き、本体とほぼ同じことができる作りのものがあります。
Dixlase も、今はそうです。公式のプラグインはコアを壊すような操作をしませんが、作りの上では、できてしまいます。

プラグインでコアと同じような動作ができるのは、便利な反面、ひとつのプラグインに穴があると、サイト全体に影響が及ぶことがあります。

これをどう抑えるかは、言語ではなく、CMS の設計で決まります。
たとえば、次のような考え方があります。

• 権限を絞る：プラグインごとに、できることをあらかじめ決めておく
• 出どころを確かめる：配られたプラグインが、作者が出したままのものかを確かめる
• 隔離する：プラグインを、本体から切り離された場所で動かす

どれも、PHP でも、ほかの言語でも取り入れられる考え方です。
言語を変えれば自動的に安全になるわけではなく、どの言語を使っても、設計で守る必要があります。

Dixlase では

Dixlase は、拡張の層の守りとして、いまは次の仕組みを持っています。

• 権限の宣言：プラグインが何をするかを、あらかじめ宣言する
• 署名の検証：公式のプラグインが、配られたあとに書き換えられていないかを確かめる
• 健全性スコア：プラグインを入れる前に、中身を調べて点数をつける

一方で、プラグインを本体から隔離して動かす仕組み（サンドボックス）は、まだ実装されていません。ここは正直にお伝えします。プラグインのサンドボックス化についてはこれからの検討の課題です。
そのため、いまの Dixlase で、プラグインの脆弱性を完全に防げるわけではありません。

Dixlase が多要素認証やパスキー、改ざんの検知といった守りを、プラグインではなくコアにそろえているのは、守りのためにプラグインを足す必要を、できるだけ減らしたいからです。

静的なサイトでも、層はなくならない

今回の件のあと、「静的なサイトに移ろう」という声も見かけました。
たしかに、静的なサイトには PHP や CMS の層がないので、今回のような脆弱性の影響は受けません。
ただ、ほかの層は残ります。

• Web サーバー：2021 年 10 月には、Web サーバーの Apache（2.4.49）に、公開していない場所のファイルにアクセスされるおそれのある脆弱性が見つかり、実際に悪用されました。条件によっては、リモートでコードを実行されるおそれもありました。
• 外から読み込むスクリプト：2024 年 6 月には、多くのサイトが外部から読み込んでいた JavaScript の配布元が別の持ち主に渡り、配られるスクリプトに悪いコードが入れられました。10 万を超えるサイトが影響を受け、訪れた人が詐欺のサイトへ誘導されました。
• サーバーのアカウントや、サイトを作る道具：パスワードが盗まれたり、ビルドに使うパッケージが乗っ取られたりすれば、HTML や JavaScript そのものが書き換えられます。

出典：Tenable「CVE-2021-41773」／BleepingComputer（2024 年 6 月）

静的なサイトにすることは、守る層を減らす選択です。層をなくす選択ではありません。

脆弱性のニュースを見たら

脆弱性のニュースを見たときは、まず次の 3 つを確かめると、落ち着いて対応できます。

1. どの層の問題か：言語か、CMS の本体か、プラグインか、サーバーの設定か
2. 自分のサイトは対象か：使っているもの、その版が当てはまるか
3. 修正版は出ているか：出ていれば更新する。出ていなければ、開発元の案内に沿って、つなぎの対策をとる

おわりに

脆弱性は、どの言語にも、どの CMS にも、どの層にも起きます。
だからこそ、「どれが絶対に安全か」ではなく、「起きたときに、どこを、誰が、どう直すのか」を知っておくことが大切だと考えています。

Dixlase も、絶対に安全だとは言えません。
見つかった問題を早く直し、何をすればよいかを分かりやすくお伝えすることを、これからも続けていきます。

ご意見や感想は、GitHub の Issue や SNS で、気軽にお寄せください。

更新履歴

• 2026-10-28：公開
• 2026-10-30：「どんな脆弱性だったのか」を追記