Amazon Inspector には EC2 インスタンスにインストールされたソフトウェアパッケージの脆弱性を検出する機能があります。 OS パッケージだけでなく、Java、JavaScript、Python といったプログラミング言語のパッケージも含まれますが、多くの場合でパッケージのインストールパスを指定する必要があります。
Amazon Inspector が何も検出しないので脆弱性がないと思っていたらスキャン対象外になっていた、という事態は避けなければいけません。
本記事では、 Amazon Linux 2023 でJavaScript (Node.js) の環境に2025年12月に公開された脆弱性 CVE-2025-55182 通称 React2Shell で影響を受けるパッケージ react-server-dom-webpack 19.1.1 がインストールされていた場合に、 Amazon Inspector で検出されるのかという観点で確認していきます。
なお、本記事のように脆弱性のあるパッケージをあえてインストールする場合は、セキュリティグループで外部接続を禁止する、HTTP サーバを起動しない、というような安全確保をすることを推奨します。
- Amazon Inspector の脆弱性スキャン対象となるパス
- グローバルインストール（npm install -g）の場合
- ローカルインストール（npm install）の場合
- グローバルインストール（npm install -g）の場合、ただしNVMを使用
- Next.js でプロジェクト作成（npx create-next-app）した場合
- （補足）エージェントレススキャンについて
- まとめ
Amazon Inspector の脆弱性スキャン対象となるパス
重要な前提となります。
Amazon Inspector は、すべてのアカウントで Amazon Inspector がスキャンする以下のデフォルトパスに加えて、すべてのカスタムパスをスキャンします。
/usr/lib
/usr/lib64
/usr/local/lib
/usr/local/lib64
Linux ベースの Amazon EC2 インスタンス向け Amazon Inspector 詳細検査 - Amazon Inspector
グローバルインストール（npm install -g）の場合
以下のように npm install -g で脆弱性のあるパッケージをインストールされていたとします。 -g オプションをつけると、グローバルモードでのインストールとなります。
$ sudo dnf install nodejs24 $ cd /home/ec2-user/project1 $ sudo npm install -g react-server-dom-webpack@19.1.1
パッケージがインストールされるパスを確認をしてみます。
$ npm list -g /usr/lib/nodejs24/lib ├── npm@11.6.2 └── react-server-dom-webpack@19.1.1
/usr/lib の配下にインストールされているので、Inspector のスキャン対象になり、以下のように脆弱性が検出されました。
ローカルインストール（npm install）の場合
-g をつけない場合は、コマンド実行時のディレクトリ配下にインストールされます。
$ sudo dnf install nodejs24 $ cd /home/ec2-user/project1 $ npm install react-server-dom-webpack@19.1.1
$ npm list project1@ /home/ec2-user/project1 └── react-server-dom-webpack@19.1.1 $ npm list -g /usr/lib/nodejs24/lib └── npm@11.6.2
Amazon Inspector のデフォルトパス（/usr/lib、/usr/lib64、/usr/local/lib、/usr/local/lib64）ではないため、スキャン対象外になります。
スキャン対象とするためには、カスタムパスで /home/ec2-user/project1 を指定します。
なお、/home/ec2-user といった上位パスを指定することも可能です。
グローバルインストール（npm install -g）の場合、ただしNVMを使用
AWS の開発者ガイドで NVM（Node Version Manager） を使用したセットアップが紹介されていることもあり、こちらの方法でインストールする方も多いでしょう。 NVM を使用している場合は、-g でグローバルインストールすると、ユーザーのホームディレクトリ配下にパッケージがインストールされます。
$ curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.39.7/install.sh | bash $ source ~/.bashrc $ nvm install --lts $ cd /home/ec2-user/project1 $ npm install -g react-server-dom-webpack@19.1.1
$ npm list -g /home/ec2-user/.nvm/versions/node/v24.12.0/lib ├── corepack@0.34.5 ├── npm@11.6.2 └── react-server-dom-webpack@19.1.1
この場合もローカルインストールと同じく、カスタムパス設定が必要です。
Next.js でプロジェクト作成（npx create-next-app）した場合
Next.js というフレームワークでプロジェクトを作成すると、プロジェクトディレクトリの中に自動的にパッケージがインストールされます。 CVE-2025-55182 の脆弱性の影響を受けるバージョン 15.0.0 を指定してインストールをしてみます。
$ sudo dnf install nodejs24 $ cd /home/ec2-user $ npx create-next-app@15.0.0 project1
npm list で next@15.0.0 の存在を確認できます。
$ cd /home/ec2-user/project1 project1@0.1.0 /home/ec2-user/project1 ├── @emnapi/runtime@1.8.1 extraneous ├── @types/node@20.19.27 ├── @types/react-dom@18.3.7 ├── @types/react@18.3.27 ├── eslint-config-next@15.0.0 ├── eslint@8.57.1 ├── next@15.0.0 ├── postcss@8.5.6 ├── react-dom@19.0.0-rc-65a56d0e-20241020 ├── react@19.0.0-rc-65a56d0e-20241020 ├── tailwindcss@3.4.19 └── typescript@5.9.3
カスタムパスの中に脆弱性のあるバージョンの next パッケージがインストールされているので、以下のように検出されます。
ちなみに、CVE ではないタイトルの検出結果も作成されており、脆弱性ソースが GitHub となっていました。
なお、今回は next では検出されていますが、react-server-dom-webpack や react-server-dom-turbopack パッケージでは検出されませんでした。 理由は正確にはわからなかったのですが、package.json や package-lock.json にそれらのパッケージのバージョン記載がないことが考えられます。 例えば、Inspector で検出されたパッケージについて記載された package.json を見ると、以下のようにバージョンが含まれていました。
$ cat ./node_modules/next/package.json
{
"name": "next",
"version": "15.0.0",
以下略
cat /home/ec2-user/project1/node_modules/next/dist/compiled/@babel/runtime/package.json
{"name":"@babel/runtime","version":"7.22.5"
以下略
しかし、プロジェクトディレクトリ内のに多数ある package.json を調べても、react-server-dom-webpack のバージョン記載は見当たりませんでした。 そもそも、react-server-dom-webpack-builtin という少し違う名前になっていましたが、それにもバージョン記載はありませんでした。
$ cat ./node_modules/next/dist/compiled/react-server-dom-webpack/package.json
{
"name": "react-server-dom-webpack-builtin",
以下略（ "version" は無し）
Next.js のような大きなパッケージの場合、その中に含まれているパッケージでは package.json に記載がなく、検出されない可能性はあるかもしれません。 とはいえ、今回は Next.js 自体で検出されて脆弱性に気がつくことができたので、大きな問題ではないでしょう。
（補足）エージェントレススキャンについて
ここまでの説明は Amazon Inspector のエージェントベースモード設定のスキャンに関するものでした。 実は、ハイブリッドスキャンモード設定にすると、エージェントレススキャン方式が使用されることがあり、その場合は特にカスタムパスの指定がなくても、すべてのパスがスキャンされます。
Linux インスタンスのアプリケーションプログラミング言語パッケージの脆弱性をスキャンする場合、エージェントレス方式では使用可能なすべてのパスがスキャンされます。一方、エージェントベーススキャンでは、デフォルトパスと、Linux ベースの Amazon EC2 インスタンス向け Amazon Inspector 詳細検査 の一部として指定した追加パスのみがスキャンされます。これにより、同じインスタンスでも、エージェントベース方式を使用してスキャンされたか、エージェントレス方式を使用してスキャンされたかによって、異なる検出結果が得られる可能性があります。
Amazon Inspector による Amazon EC2 インスタンスのスキャン - Amazon Inspector
それではハイブリッドスキャンモード設定にすれば、全てのパスがスキャン対象となりそうに感じますが、このモードでも多くの場合でエージェントベース方式によるスキャンが実行され、エージェントレス方式では実行されません。
ハイブリッドスキャン — このスキャンモードでは、Amazon Inspector はエージェントベースの方式とエージェントレス方式の両方を組み合わせてパッケージの脆弱性をスキャンします。SSM エージェントがインストールおよび設定されている適格な EC2 インスタンスでは、Amazon Inspector はエージェントベースの方式を使用します。SSM マネージドではない対象インスタンスの場合、Amazon Inspector は対象の EBS-backed インスタンスに対してエージェントレス方式を使用します。
Amazon Inspector による Amazon EC2 インスタンスのスキャン - Amazon Inspector
ハイブリッドスキャンモードでは、エージェントベース方式が優先されます。エージェントレス方式を使用するためには、「SSM エージェントがインストールおよび設定されている適格な EC2 インスタンス」ではない状態にする必要があります。この条件に当てはまるには、IAM ロールをアタッチしない、SSMエージェントをインストールしない、等が考えられます。しかし、SSM マネージドインスタンスでない状態にすると他の機能に影響がありますので、実際の利用は難しいと思われます。
なお、各 EC2 インスタンスに適用されているスキャン方式は、Inspector > リソースのカバレッジ > EC2 インスタンスの画面で確認できます。
まとめ
- Amazon Inspector の EC2 スキャンでプログラミング言語パッケージの脆弱性スキャンをする場合は、インストールパスを確認しましょう。
- Amazon Inspector のデフォルトパス（/usr/lib、/usr/lib64、/usr/local/lib、/usr/local/lib64）以外にインストールされている場合は、カスタムパスで指定しましょう。
- package.json、package-lock.json にバージョン記載がない場合は脆弱性が検出されない可能性があります。心配な場合は確認しましょう。
