こんにちは。株式会社オレンジソフトウェアの藤田です。
最近、セキュリティ関連のニュースを見ていると、「PHP2Shell」「HTTP2Shell」「XSS2Shell」など、「○○2Shell」という名前の脆弱性をよく目にするようになりました。
弊社でも、今年7月にWordPressの「wp2shell」、8月には「XSS2Shell」、そして今月21日には「PHP2Shell」に関係する重大な脆弱性を記事で取り上げています。
こうした情報を日々確認していると、名前がどれもよく似ていることに気付きます。
私自身、サーバーやネットワークの構築・保守に携わる立場として、脆弱性が公表されるたびに「弊社が管理しているシステムに影響はないか」「どの程度急いで対応する必要があるのか」を確認しています。
その中で少し気になったのが、今回の「Shell」という名前です。
調べてみると、最近突然使われ始めた名前というわけではなく、2014年のShellshockや、2021年に世界中で大きな話題になったLog4Shellなど、以前から似た名前の脆弱性がいくつも存在していました。
しかも、名前は似ていても、実際に問題が発生したソフトウェアや、攻撃の仕組みはまったく異なります。
そこで今回は、なぜ似た名前が付けられるのか、それぞれどのような脆弱性なのかを、私なりに整理してみました。
技術的な内容も含みますが、できるだけ分かりやすくご紹介します。
そもそも「Shell」とは何なのか？
私たちエンジニアにとっては、普段の仕事でほぼ毎日のように使っているものなので、すぐにイメージできると思います。
すでにご存じの方は、この項目を読み飛ばしていただいても大丈夫です。
「Shell（シェル）」とは、簡単に言えば、コンピューターに命令を伝えるための仕組みのことです。
映画やドラマなどで、コンピューターに詳しい人物が黒い画面に向かって、英数字をものすごい速さで入力している場面を見たことはありませんか？
あのような画面で使われているのが、Shellと呼ばれる仕組みの一つです。
例えば、Linuxサーバーでは、Shellを使ってファイルを操作したり、プログラムを実行したり、システムの設定を変更したりします。
マウスでアイコンをクリックして操作するのとは違い、文字で命令を入力することで、コンピューターを細かく操作できます。
実はこのShellという仕組み、コンピューターの歴史と深い関わりがあります。
ここからShellの誕生やUNIX、Linuxの歴史をたどっていくと、それだけで一つの記事になってしまいそうなので、今回は省略します。
ただ、個人的にはコンピューターの歴史はとても面白い分野だと思っています。
現代の電子式コンピューターが登場してから、まだ80年ほど。現在につながるコンピューター技術の歴史を広く見ても、約100年という比較的新しい世界です。
そのため、歴史の教科書に載っていてもおかしくないような偉大な技術者が、今も現役で活動していたり、つい最近まで活躍していたりします。
例えば、Linuxを開発したリーナス・トーバルズ氏は、1991年にLinuxの開発を始め、現在も開発に関わっています。
普通の歴史では、偉人といえば何百年も前の人物であることが多いですが、コンピューターの世界では、私たちが日常的に使っている技術を作った本人が、今も同じ時代に生きているということが珍しくありません。
こうした背景を知ると、普段何気なく使っている技術の見え方も少し変わってきます。
興味のある方は、ぜひ一度コンピューターの歴史についても調べてみてください。なかなか面白い世界です。
さて、少し話がそれてしまいましたが、本題に戻りましょう。
今回の脆弱性で使われている「Shell」という言葉は、このコンピューターに命令を出す仕組みと関係しています。
通常、サーバーの操作は適切な権限を持つ利用者によって行われます。
しかし、ソフトウェアに重大な脆弱性があると、外部の攻撃者が不正なデータを送り込むことで、本来実行されるはずのない命令やプログラムをサーバー上で実行できてしまう場合があります。
これを「リモートコード実行（RCE：Remote Code Execution）」と呼びます。
RCEが成立すると、攻撃者はそのプログラムが持つ権限の範囲で、ファイルの読み取りや不正な処理を実行できる可能性があります。
さらに、サーバーの設定や権限管理に問題があれば、被害が拡大することも考えられます。
こうした攻撃によってサーバーを操作できる状態になるイメージから、「Shell」という言葉が脆弱性の名前に使われることがあります。
ただし、「Shell」という名前が付いていても、必ずしも攻撃者がコマンド操作用のShellを直接取得できるとは限りません。
また、こうした名称は、脆弱性を発見した研究者やセキュリティ企業などが付けた通称であり、公式な分類ではありません。
なぜ「2Shell」「4Shell」という名前が多いのか？
「React2Shell」「PHP2Shell」「HTTP2Shell」などの名前に入っている数字の「2」。 これは、脆弱性の第2世代やバージョン2を意味する数字ではありません。 英語の「2（two）」と「to」の発音が似ていることを利用した言葉遊びです。 例えば「React2Shell」は、「ReactからShellへ」という意味を連想させる名前になっています。
一方、「4」が付く名前の代表であるLog4Shellの「4」は、もともとのライブラリ名「Log4j」に由来しています。 その後に登場したSpring4ShellやText4Shellは、Log4Shellにならった名前と考えられます。「4（four）」と「for」の発音が似ていることから言葉遊びと説明されることもありますが、命名の意図ははっきりしない部分もあります。
私が調べた中で興味深かったのは、Log4Shellという名前が広く知られるようになって以降、似た形式の名前が重大な脆弱性に付けられる例が増えたことです。
短くて覚えやすい名前は、注意喚起を広めるうえでは効果的なのだと思います。
ただし、名前が似ているからといって、同じような攻撃が成立するわけではないことには注意が必要です。
代表的な「Shell」系の脆弱性一覧
今回調べた代表的な12種類を、公表された年代順にまとめました。
| 名称 | 年 | 主な対象 | 原因・特徴 |
|---|---|---|---|
| Shellshock | 2014 | Bash | 環境変数の処理 |
| ProxyShell | 2021 | Microsoft Exchange | 複数の脆弱性を連鎖 |
| Log4Shell | 2021 | Apache Log4j | ログに含まれる文字列の処理 |
| Spring4Shell | 2022 | Spring Framework | データバインディング |
| Text4Shell | 2022 | Apache Commons Text | 文字列の置換処理 |
| ProxyNotShell | 2022 | Microsoft Exchange | SSRFとRCEの組み合わせ |
| React2Shell | 2025 | React / Next.jsなど | データの復元処理 |
| wp2shell | 2026 | WordPress | REST APIとSQLインジェクションの連鎖 |
| KindaRails2Shell | 2026 | Ruby on Rails | ファイルの処理 |
| XSS2Shell | 2026 | WordPress | XSSを起点とする攻撃 |
| PHP2Shell | 2026 | PHP | メモリ管理とリクエスト処理 |
| HTTP2Shell | 2026 | Brotli / Node.jsなど | 圧縮データの展開処理 |
なお、Node2ShellとHTTP2Shellは別々の脆弱性ではありません。どちらも同じCVE-2026-111497を指す名称として使われています。
それでは、それぞれの特徴を見ていきます。
Shellshock｜Linuxなどで使われるBashの脆弱性
公表：2014年9月
CVE-2014-6271など
Shellshockは、Linuxなどで広く利用されているBashというコマンド処理ソフトウェアで発見された脆弱性です。
Bashが環境変数から関数を読み込む際の処理に問題があり、攻撃者が特殊なデータを与えることで、意図しないコマンドが実行される可能性がありました。
特定のWebサーバーやSSHなどの構成では、外部からの通信を通じて攻撃できる場合もありました。
この名前は、後のLog4Shellなどが登場する以前から使われていました。
ProxyShell｜Microsoft Exchangeへの侵入につながる攻撃
公表・攻撃の注目：2021年
CVE-2021-34473、CVE-2021-34523、CVE-2021-31207
ProxyShellは、Microsoft Exchange Serverに存在した3件の脆弱性を組み合わせた攻撃チェーンです。
Exchange Serverは企業などで利用されるメールサーバーです。
攻撃者は複数の脆弱性を連鎖的に悪用することで、認証を回避するような形で内部機能へアクセスし、最終的にサーバーを侵害できる可能性がありました。
ProxyShellは1つのプログラムの単純な不具合ではなく、複数の問題を組み合わせることで深刻な被害につながる事例です。
Log4Shell｜世界中で大きな問題となったJavaの脆弱性
公表：2021年12月
CVE-2021-44228
Log4Shellは、Javaで利用されるログ出力ライブラリ「Apache Log4j」に発見された重大な脆弱性です。
ログは、サーバーのアクセス履歴やエラーなどを記録するために使われます。
しかし、Log4jの特定の機能では、ログに記録される文字列に特殊な内容が含まれていると、外部のサーバーへアクセスする処理が実行され、条件によっては不正なコードの実行につながりました。
Log4jはさまざまな製品に組み込まれていたため、影響範囲が非常に広くなりました。
私が特に重要だと感じるのは、利用者がLog4jを直接使っていると認識していなくても、内部で使用している別のソフトウェアに組み込まれている可能性があった点です。
これは、その後の脆弱性にも共通する問題だと思います。
Spring4Shell｜JavaのWebアプリケーションに影響した脆弱性
公表：2022年3月
CVE-2022-22965
Spring4Shellは、JavaのWebアプリケーション開発で使用されるSpring Frameworkに存在した脆弱性です。
Webアプリケーションが受け取ったデータを、プログラム内部のオブジェクトに反映する「データバインディング」という処理に問題がありました。
特定の条件では、攻撃者が細工したリクエストを送信することで、サーバー上で任意のコードを実行できる可能性がありました。
代表的な攻撃経路では、JDK 9以降、Tomcat、WAR形式の配置など、複数の条件が関係していました。
Log4Shellと同じJava関連の脆弱性ですが、原因はまったく異なります。
Text4Shell｜文字列を置き換える機能の脆弱性
公表：2022年10月
CVE-2022-42889
Text4Shellは、Apache Commons TextというJavaの文字列処理ライブラリに発見された脆弱性です。
このライブラリには、文字列に含まれる特別な記述を別の値に置き換える機能があります。
ところが、特定の機能ではスクリプトの実行や外部通信を行う仕組みも含まれていました。
信頼できないデータを危険な形で処理すると、外部から任意のコードを実行される可能性がありました。
ただし、影響を受けるのは問題のある置換機能を利用しているアプリケーションです。
Log4Shellのように、広く利用されるライブラリに問題があったとしても、攻撃の成立条件や実際の影響範囲は異なります。
ProxyNotShell｜Exchangeで発見された別の攻撃チェーン
公表：2022年9月
CVE-2022-41040、CVE-2022-41082
ProxyNotShellは、Microsoft Exchange Serverに発見された2件の脆弱性に関係する攻撃です。
一方はサーバー側リクエストフォージェリ（SSRF）、もう一方はリモートコード実行に関係しています。
これらを組み合わせることで、特定の条件下でサーバーに不正な命令を実行させることが可能でした。
ただし、この攻撃には認証済みのアクセスが必要でした。
先に登場したProxyShellと似た名前ですが、別の問題です。
React2Shell｜React Server Componentsの重大な脆弱性
公表：2025年12月
CVE-2025-55182
React2Shellは、React Server Componentsに発見された重大な脆弱性です。
ReactはWebアプリケーションの画面を構築するためのJavaScriptライブラリで、Next.jsなどでも利用されています。
今回問題になったのは、外部から受け取ったデータをプログラム内部の形式に復元する「デシリアライズ」という処理でした。
攻撃者が細工したデータを送信することで、認証なしでサーバー上のコードを実行できる可能性がありました。
深刻度はCVSS 10.0と評価され、実際に悪用する攻撃も確認されています。
ただし、Reactを使っているだけですべてのWebサイトが影響を受けるわけではなく、React Server Componentsの利用状況などが関係します。
wp2shell｜WordPress本体の脆弱性を組み合わせた攻撃
公表：2026年7月
CVE-2026-63030、CVE-2026-60137
wp2shellは、WordPress本体に存在した複数の脆弱性を組み合わせた攻撃チェーンです。
WordPressのREST APIにおけるリクエスト処理の問題と、SQLインジェクションの問題を連鎖させることで、条件がそろうと、認証されていない外部の攻撃者がサーバー上で任意のコードを実行できる可能性がありました。
WordPressのプラグインやテーマではなく、本体の問題だった点が特徴です。
弊社でも当時、管理するWordPressサイトへの影響を確認し、必要な更新作業を進めました。
この脆弱性については、以前の記事で仕組みや対策を詳しく紹介しています。
関連記事：
wp2shellとは？WordPress緊急脆弱性の対応方法とSEOへの影響
KindaRails2Shell｜Ruby on Railsのファイル処理に関係する脆弱性
公表：2026年7月
CVE-2026-66066
KindaRails2Shellは、Ruby on RailsのActive Storageというファイル管理機能に存在した脆弱性です。
Active Storageは、画像やファイルのアップロード、保存、画像の加工などに使われます。
今回の問題では、特定の条件下で攻撃者が細工したファイルをアップロードすると、サーバー内のファイルや認証情報を読み取られる可能性がありました。
さらに、環境や設定によってはリモートコード実行につながる危険性もありました。
名前に含まれる「Kinda」は、英語で「ある意味」「ちょっと」といったニュアンスの言葉です。
こうした名前の付け方も、脆弱性の通称ならではの特徴だと感じます。
XSS2Shell｜ブラウザー上のXSSからサーバー侵害につながる脆弱性
公表：2026年8月
CVE-2026-64638
XSS2Shellは、WordPress本体のログイン画面に存在したクロスサイトスクリプティング（XSS）の脆弱性です。
XSSとは、Webページ上で攻撃者が用意したJavaScriptを、利用者のブラウザーで実行させてしまう問題です。
今回の脆弱性では、攻撃者が細工したURLを、ログイン中のWordPress管理者に開かせるなどの条件がそろうと、管理者の権限を悪用して不正な操作を行い、最終的にサーバー上でPHPコードを実行できる可能性がありました。
通常、XSSというとブラウザー上での不正なスクリプト実行をイメージしますが、場合によってはサーバー側の侵害にまで発展します。
この点がXSS2Shellの特徴です。
弊社でも2026年8月に詳しい解説記事を公開しています。
関連記事：
XSS2Shell（CVE-2026-64638）とは？WordPressの脆弱性の影響と対策
PHP2Shell｜PHP本体のメモリ管理に関する重大な脆弱性
公表：2026年10月
CVE-2026-109618、CVE-2026-109619
PHP2Shellは、2026年10月21日に公表されたPHP本体の2件の脆弱性の総称です。
PHPはWordPressやLaravelなど、多くのWebサイトや業務システムで利用されています。
今回の脆弱性は、PHP内部でメモリ不足が発生した際のエラー処理や、リクエスト処理に関するメモリ状態の管理に存在しました。
CVE-2026-109618では、メモリ不足によって処理が中断された際に、内部データが不完全な状態のまま後続の処理に使われる可能性があります。
CVE-2026-109619では、解放されたメモリを参照する情報が残り、後続の処理で再利用される問題があります。
いずれも、条件によっては外部から認証なしで任意のコードを実行される可能性があります。
修正版として、PHP 8.2.35、8.3.36、8.4.27、8.5.12が公開されています。
なお、サポートが終了した古いPHPについては、OSや保守提供元によって修正がバックポートされている場合もあります。単純にバージョン番号だけで判断せず、提供元のセキュリティ情報を確認する必要があります。
弊社でも、この脆弱性について修正版の公開前から情報を確認し、注意喚起の記事を公開しました。
関連記事：
【緊急】PHPの重大脆弱性「CVE-2026-109618 / CVE-2026-109619」発見！WordPress・Laravelへの影響と対策
HTTP2Shell｜Brotliという圧縮ライブラリの重大な脆弱性
公表：2026年10月
CVE-2026-111497
HTTP2Shellは、Brotliというデータ圧縮ライブラリに存在する脆弱性です。
BrotliはGoogleが開発した圧縮技術で、Web通信などでデータ量を小さくするために使われています。
今回の脆弱性では、圧縮されたデータを元に戻す「展開処理」に問題がありました。
攻撃者が細工した圧縮データを脆弱なライブラリに処理させることで、メモリの領域外への書き込みが発生し、プログラムの異常終了やメモリ内の情報漏洩、場合によっては任意のコード実行につながる可能性があります。
この問題は、Node.jsへの影響が注目されたことから「Node2Shell」とも呼ばれています。
しかし、問題があるのはNode.js固有の処理ではなく、内部で利用しているBrotliのデコーダーです。
そのため、PythonやBunなど、同じライブラリを利用する複数のソフトウェアにも影響が確認されています。
こうした影響範囲の広がりを踏まえ、「HTTP2Shell」という名前も使われています。
なお、HTTP2Shellという名前ですが、HTTP/2という通信プロトコルそのものの脆弱性ではありません。
また、PHP2Shellと同じ時期に公表された問題ですが、原因はまったく異なります。
私がこの問題で特に気になったのは、普段あまり意識しない圧縮ライブラリが、複数のソフトウェアに共通するセキュリティリスクになった点です。
Log4Shellのときと同様、システムの内部でどのようなソフトウェアが使われているのかを把握する重要性を感じました。
「Shell」が付いているからといって、すべて同じ危険性ではない
ここまで紹介した脆弱性は、名前こそ似ていますが、攻撃の成立条件はそれぞれ異なります。
例えば、React2Shellは、影響を受ける構成で認証なしのリモートコード実行が可能になる脆弱性でした。
一方、XSS2Shellでは、管理者が細工されたURLにアクセスするなどの条件が必要になります。
HTTP2Shellでは、攻撃者が制御したBrotli圧縮データを、脆弱なデコーダーが処理することが重要な条件です。
このように、同じ「Shell」という名前が付いていても、攻撃方法や影響範囲は異なります。
また、「Shell」という名前が付いていない重大な脆弱性も数多く存在します。
セキュリティ上の危険性を判断するには、通称だけではなく、CVE番号、対象となるソフトウェア、バージョン、攻撃の成立条件などを確認する必要があります。
企業のセキュリティ対策で大切だと感じること
今回、過去の脆弱性も含めて調べてみて、改めて感じたことがあります。
それは、自社で開発したプログラムに問題がなくても、そのシステムを動かしているソフトウェアに問題があれば、システム全体が危険になる可能性があるということです。
現在のWebシステムは、プログラミング言語やフレームワークだけでなく、多数のライブラリや外部のソフトウェアを組み合わせて動作しています。
そのすべてを常に把握し、最新の状態に維持することは簡単ではありません。
また、重大な脆弱性が公表された際には、早急なアップデートが必要になる場合もあります。
しかし、業務システムの場合は、アップデートによって既存の機能が正常に動作しなくなる可能性もあるため、バックアップや動作確認なども必要です。
私たちのようにお客様のシステムを保守・運用する立場では、セキュリティ対策とサービスの安定稼働の両方を考えなければなりません。
だからこそ、問題が発生してから対応方法を考えるのではなく、普段から利用しているソフトウェアの把握や、更新時の手順、障害が発生した場合の復旧方法を整えておくことが重要だと考えています。
まとめ
今回紹介した12種類の脆弱性は、名前は似ていますが、発生した原因も、影響を受けるソフトウェアもさまざまです。
「2Shell」「4Shell」という名前には英語の発音を利用した言葉遊びが含まれる場合があり、Log4Shellが広く知られるようになったことも、似た形式の名前が使われる背景の一つと考えられます。
ただし、こうした名称は正式な分類ではなく、脆弱性の危険度を表すものでもありません。
今回調べてみて、名前の付け方そのものも興味深かったのですが、それ以上に、脆弱性はさまざまなソフトウェアの、思いもよらない部分から発見されるということを改めて感じました。
今後も新しい脆弱性は発見され続けると思います。
弊社でも、こうしたセキュリティ情報を継続的に確認し、お客様のシステムへの影響を判断しながら、必要な対策を進めていきたいと考えています。
最後までお読みいただき、ありがとうございました。
株式会社オレンジソフトウェア
藤田
サーバーや社内ネットワークのセキュリティが気になる方へ
株式会社オレンジソフトウェアでは、中小企業向けにセキュリティ診断サービスを提供しています。
サーバーや社内ネットワークについて、古いソフトウェアの利用状況、既知の脆弱性、外部からのアクセス経路、設定上の問題などを確認し、改善すべき点をご提案します。
長期間運用しているサーバーや、更新状況が分からない業務システムなどでお困りの場合は、お気軽にご相談ください。
この記事は2026年10月25日時点の公開情報に基づいて作成しています。脆弱性の影響範囲や対策情報は更新される場合があるため、実際の対応にあたってはソフトウェア提供元の最新情報をご確認ください。
