React Server Components RCE脆弱性（CVE-2025-55182）への対応記録

2025-12-06T00:00:00+00:00

脆弱性の概要</h2>

CVE-2025-55182とは</h3>

CVE-2025-55182は、React 19のServer Components（RSC）における「Flight」プロトコルの安全でないデシリアライゼーション（deserialize）に起因する脆弱性です。主な特徴は次の通りです。

CVSSスコア: 10.0（最大値）</li>
影響範囲: React 19.0.0、19.1.0、19.1.1、19.2.0</li>
攻撃条件: 認証不要、細工されたHTTPリクエストのみで実行可能</li>

デフォルト設定で脆弱: create-next-app</code>により作成した標準的なNext.jsアプリケーションが影響を受ける</li> </ul> 技術的な仕組み</h3> この脆弱性は、RSCの内部通信プロトコルである「Flight」の処理において、攻撃者の制御可能なデータを適切な検証なしにデシリアライズしてしまうことに起因します。攻撃者からペイロードを含むHTTPリクエストが送信されると、サーバー側ではこれをFlightプロトコルのデータとして処理し、検証なしにデシリアライズします。この結果、任意のコードを実行される可能性があります。 重要なのは、この処理がアプリケーションの認証ロジックより前、つまりMiddlewareでの保護より深い層で行われるため、通常の認証機構では防げないという点です。 CVE番号の統合経緯</h2> 2025年12月3日時点では、以下の2つのCVE番号で追跡されていました。 CVE-2025-55182: React Server Componentsの脆弱性</li> CVE-2025-66478: Next.jsの脆弱性</li> </ul> 調査の結果、Next.jsの脆弱性は実質的にReactの脆弱性に起因することが判明し、CVE-2025-66478は重複として却下されました。現在はCVE-2025-55182に統合されています。 この経緯は、脆弱性の根本原因がReactのRSC実装そのものにあり、Next.jsはその影響を受けていたに過ぎないことを示しています。 影響を受けるバージョンと修正版</h2> React / React-dom</h3> 影響を受けるバージョン</th> 修正済みバージョン</th></tr></thead> 19.0.0</td> 19.0.1</td></tr> 19.1.0, 19.1.1</td> 19.1.2</td></tr> 19.2.0</td> 19.2.1</td></tr> </tbody></table> Next.js</h3> 影響を受けるバージョン</th> 修正済みバージョン</th></tr></thead> 15.x（全般）</td> 15.0.5, 15.1.9, 15.2.6, 15.3.6, 15.4.8, 15.5.7</td></tr> 16.x（全般）</td> 16.0.7</td></tr> 14.3.0-canary.77以降</td> （14.x Stable版は影響なし）</td></tr> </tbody></table> 注: Next.js 13.x、14.x stable版、Pages Router、Edge Runtimeは影響を受けません。 実際の攻撃状況</h2> この脆弱性は公表直後から実際に悪用されています。 2025年12月3日: 脆弱性が公表される</li> 同日中: 中国関連の脅威グループによる大規模な攻撃活動が観測される</li> 2025年12月5日午前6時（UTC）以降: Wizのセンサーが複数の被害者を検知</li> </ul> この脆弱性は「React2Shell」または「React4Shell」という名称でも呼ばれ、既に実証コード（PoC）が公開されています。 当ブログでの対応状況</h2> 対応タイムライン</h3> 2025年12月3日: CVE-2025-55182が公表される</li> 2025年12月5日: 当ブログで修正版へのアップデート実施（v1.7.1）</li> </ul> 実施した対応</h3> 以下のパッケージを修正版にアップデートしました。 # 実施したアップデート React: 19.0.0 → 19.2.1 React-dom: 19.0.0 → 19.2.1 Next.js: 15.2.3 → 15.5.7 @next/mdx: 15.2.3 → 15.5.7 eslint-config-next: 15.2.3 → 15.5.7</code></pre> 当ブログはCVE-2025-55182に完全対応済みであり、この脆弱性の影響を受けない安全な状態です。 推奨される対応</h2> Next.jsやReactを使用しているプロジェクトをお持ちの方は、以下の対応を推奨します。 1. バージョンの確認</h3> まず現在のバージョンを確認します。 npm list next react react-dom</code></pre>2. 修正版へのアップデート</h3> 該当する場合は、直ちに修正版へアップデートしてください。 # npm の場合 npm install next@latest react@latest react-dom@latest # yarn の場合 yarn add next@latest react@latest react-dom@latest # pnpm の場合 pnpm add next@latest react@latest react-dom@latest</code></pre>3. 内部依存関係の確認</h3> package.json</code>だけでなく、ロックファイル（package-lock.json</code>、yarn.lock</code>など）も確認し、内部依存関係として古いバージョンが残っていないか確認することを強く推奨します。 # ロックファイル内のReactバージョンを確認 grep -A5 '"react":' package-lock.json grep -A5 '"next":' package-lock.json</code></pre>4. デプロイ</h3> アップデート後は速やかにビルドとデプロイを実施してください。 npm run build # デプロイコマンドを実行</code></pre>まとめ</h2> CVE-2025-55182は、React Server Componentsの根本的な脆弱性であり、 CVSS 10.0という最大の深刻度を持つ重大な問題です。デフォルト設定で脆弱であり、認証を回避して攻撃可能という特性から、速やかな対応が必要です。 当ブログでは公表から2日以内に対応を完了しましたが、既に実際の攻撃が観測されているため、まだ対応されていない方は最優先で対応することを強く推奨します。 参考リンク</h2> Critical Security Vulnerability in React Server Components – React</a></li> Security Advisory: CVE-2025-66478 | Next.js</a></li> Critical RCE Vulnerabilities Discovered in React & Next.js | Wiz Blog</a></li> Critical Vulnerabilities in React Server Components and Next.js</a></li> NVD - CVE-2025-55182</a></li> </ul> GitHub Actionsでnpmパッケージ公開を自動化する - Trusted Publishingで実現するトークンレス運用 2025-12-05T00:00:00+00:00 本記事では、私が開発しているjrnl-mcp</a>パッケージで実装した、 GitHubが発表したnpmの認証強化</a> 対応の Trusted Publishing (OIDC) を使用したトークン管理不要の自動公開について記載しています。 npmの認証変更の背景</h2> GitHubは2025年9月29日に、npmのセキュリティ強化として以下の変更を発表しました。 Classic Access Tokenの廃止</li> Trusted Publishing (OIDC) またはGranular Access Tokenへの移行推奨</li> より細かい権限管理の実現</li> </ul> 移行先として2つの選択肢があります。 Granular Access Token</li> Trusted Publishing (OIDC)</li> </ol> Granular Access Tokenは、従来のトークン方式を改良したものでパッケージごとの権限管理が可能となっていますが、定期的なトークンのローテーションが必要です。 Trusted Publishingはトークンを完全に排除した新しい認証方式で、公開を自動化しトークンを完全に排除したものです。 jrnl-mcpでは、トークン管理の手間を完全に排除できる Trusted Publishing を採用しました。 自動公開の仕組み</h2> 全体のフロー</h3> jrnl-mcpでは、以下のフローで自動公開を実現しています。 GitHubでリリースを作成</li> GitHub Actionsが自動起動</li> 依存関係のインストールとテストを実行</li> npmへ自動公開</li> </ol> この仕組みにより、リリース作成だけでパッケージの公開が完了します。 GitHub Actionsの設定</h3> 実際に使用しているワークフロー設定は以下の通りです。 name: Publish to npm on: release: types: [published] permissions: contents: read id-token: write jobs: publish: runs-on: ubuntu-latest steps: - name: Checkout code uses: actions/checkout@v4 - name: Setup Node.js uses: actions/setup-node@v4 with: node-version: "20" registry-url: "https://registry.npmjs.org" - name: Install dependencies run: npm ci - name: Run tests run: npm run test:ci - name: Publish to npm run: npm publish --provenance --access public</code></pre> 重要なポイントは、 GitHubのリリース機能を使用することで、手動でのトリガーが可能になる。これにより、意図しないタイミングでの公開を防ぐ。</li> permissions</code>の設定により、GitHub Actionsはnpmに対して一時的なOIDCトークンを発行・認証する。長期的なトークンをSecretに保存する必要がない。</li> npm publish --provenance --access public</code>により自動的にprovenance（出所証明）が生成され、パッケージがどのリポジトリから公開されたか検証可能となる。</li> npm run test:ci</code>により公開前のテストを自動化する。</li> </ol> Trusted Publishing の設定方法</h2> Trusted Publishingを使用する場合、npm側での設定が必要です。 1. npm でパッケージを公開</h3> まず、通常の方法で初回のパッケージを公開します（トークンを使用）。npm側でパッケージが存在している必要があるためです。 2. npm で Trusted Publishing を設定</h3> npm のパッケージ設定</a>にアクセス</li> 公開したパッケージの"Settings"タブを開く</li> "Publishing access"セクションで"Add a publisher"を選択</li> GitHub Actionsを選択し、以下を設定する Repository: <username>/<repository-name></code>（例: yostos/jrnl-mcp</code>）</li> Workflow: ワークフローファイル名（例: publish.yml</code>）</li> Environment: 未指定（デフォルト）または特定の環境名</li> </ul> </li> </ol> 3. GitHub Actions の設定</h3> 前述のワークフロー設定で、id-token: write</code> 権限を付与するだけで完了です。トークンをSecretに保存する必要はありません。 トークンベースとの比較</h3> Trusted Publishingを使用することで、以下の作業が不要になります。 npmトークンの作成と保存</li> GitHub Secretsへのトークン登録</li> トークンの定期的なローテーション（Granular Access Tokenの場合、最大90日ごと）</li> トークン漏洩のリスク管理</li> </ul> まとめ</h2> Trusted Publishing (OIDC) とGitHub Actionsを使用したnpmパッケージの自動公開により、以下のメリットが得られました。 公開作業の効率化</li> トークン管理の完全な排除</li> セキュリティの向上</li> 品質の担保</li> 透明性の確保（自動provenance生成）</li> </ul> 特に、Trusted Publishingの導入により、トークンの定期的なローテーションや漏洩リスクの心配が不要になり、セキュリティと運用性が大幅に向上しました。npmパッケージを公開している方は、ぜひTrusted Publishingへの移行とGitHub Actionsによる自動化を検討してみてください。 Granular Access Tokenでもセキュリティは向上しますが、定期的なローテーション（最大90日ごと）が必要なため、可能であればTrusted Publishingの使用を推奨します。 参考リンク</h2> Strengthening npm security: Important changes to authentication and token management</a></li> jrnl-mcp GitHub Repository</a></li> npm Documentation: About access tokens</a></li> </ul> Amazon AmplifyのNode.jsバージョンアップ対応 2025-09-14T00:00:00+00:00 I recieved the following email from AWS. This blog does indeed use Amazon Amplify, but I thought it would be fine since I hadn't specified a Node.js version and the default was being used. 2025 年 9 月 15 日から、AWS Amplify コンソールは Node.js 14、Node.js 16、Node.js 18 のサポートを終了します。この日を過ぎると、Node バージョンをアップグレードするまでアプリケーションへの更新をデプロイできなくなります。2025 年 9 月 15 日までに、Node.js 14、Node.js 16、Node.js 18 を使用するすべてのアプリケーションを Node.js 20 以降に更新してください。 Node.js 14、Node.js 16、Node.js 18 ですでにデプロイされているアプリケーションは引き続き実行され、更新をデプロイする必要がない限り影響はありません。 アップグレードする前に新しいブランチでアプリケーションをテストして、すべての機能が正常に動作することを確認することをお勧めします。移行ガイドラインについては、[1] ページの「アプリケーションの Node.js バージョンを更新する必要がある」セクションを参照してください。 影響を受けるリソースのリストは、AWS ヘルスダッシュボードの「影響を受けるリソース」タブにあります。 AWS 通知メール『AWS Amplify は、2025 年 9 月 15 日をもって Node.js 14/16/18 ベースのアプリのサポートを終了します』 </footer> </blockquote> Just to be sure, I checked the Node version and found that Node 18 was being used. That's no good. Let's explicitly specify the version and rebuild. version: 1 frontend: phases: preBuild: commands: # Node.jsバージョンを24に指定（ローカルのMacと同じ） - nvm use 24 # バージョン確認（ログに出力） - node --version - npm --version # .envを削除 - rm -f .env - npm ci --cache .npm --prefer-offline # 環境変数を.envファイルに出力 - echo "NEXT_PUBLIC_SITE_URL=https://blog.yostos.org" >> .env (中略) build: commands: - npm run build artifacts: baseDirectory: .next files: - '**/*' cache: paths: - .next/cache/**/* - .npm/**/*</code></pre>

Trusted Publishing の設定方法</h2>
Trusted Publishingを使用する場合、npm側での設定が必要です。</p>

1. npm でパッケージを公開</h3>
まず、通常の方法で初回のパッケージを公開します（トークンを使用）。npm側でパッケージが存在している必要があるためです。</p>

3. GitHub Actions の設定</h3>
前述のワークフロー設定で、`id-token: write</code> 権限を付与するだけで完了です。トークンをSecretに保存する必要はありません。</p>`

参考リンク</h2>

Strengthening npm security: Important changes to authentication and token management</a></li>
jrnl-mcp GitHub Repository</a></li>
npm Documentation: About access tokens</a></li> </ul>

Coded Chords - Node

React Server Components RCE脆弱性（CVE-2025-55182）への対応記録

脆弱性の概要</h2>

当ブログでの対応状況</h2>

GitHub Actionsでnpmパッケージ公開を自動化する - Trusted Publishingで実現するトークンレス運用

Amazon AmplifyのNode.jsバージョンアップ対応

Coded Chords - Node

React Server Components RCE脆弱性（CVE-2025-55182）への対応記録

脆弱性の概要</h2>

当ブログでの対応状況</h2>

GitHub Actionsでnpmパッケージ公開を自動化する - Trusted Publishingで実現するトークンレス運用

npmの認証変更の背景</h2> GitHubは2025年9月29日に、npmのセキュリティ強化として以下の変更を発表しました。</p> Classic Access Tokenの廃止</li> Trusted Publishing (OIDC) またはGranular Access Tokenへの移行推奨</li>

自動公開の仕組み</h2> 全体のフロー</h3> jrnl-mcpでは、以下のフローで自動公開を実現しています。</p>

全体のフロー</h3> jrnl-mcpでは、以下のフローで自動公開を実現しています。</p>

Trusted Publishing の設定方法</h2> Trusted Publishingを使用する場合、npm側での設定が必要です。</p>

1. npm でパッケージを公開</h3> まず、通常の方法で初回のパッケージを公開します（トークンを使用）。npm側でパッケージが存在している必要があるためです。</p>

3. GitHub Actions の設定</h3> 前述のワークフロー設定で、id-token: write</code> 権限を付与するだけで完了です。トークンをSecretに保存する必要はありません。</p>

まとめ</h2> Trusted Publishing (OIDC) とGitHub Actionsを使用したnpmパッケージの自動公開により、以下のメリットが得られました。</p>

参考リンク</h2> Strengthening npm security: Important changes to authentication and token management</a></li> jrnl-mcp GitHub Repository</a></li> npm Documentation: About access tokens</a></li> </ul>

Amazon AmplifyのNode.jsバージョンアップ対応

Trusted Publishing の設定方法</h2>
Trusted Publishingを使用する場合、npm側での設定が必要です。</p>

1. npm でパッケージを公開</h3>
まず、通常の方法で初回のパッケージを公開します（トークンを使用）。npm側でパッケージが存在している必要があるためです。</p>

3. GitHub Actions の設定</h3>
前述のワークフロー設定で、`id-token: write</code> 権限を付与するだけで完了です。トークンをSecretに保存する必要はありません。</p>`

参考リンク</h2>

Strengthening npm security: Important changes to authentication and token management</a></li>
jrnl-mcp GitHub Repository</a></li>
npm Documentation: About access tokens</a></li> </ul>