フロントエンドエンジニアのための
脆弱性キュレーション
React, Next.js, Vue, Node.jsなどのモダンフロントエンド技術に関する最新のセキュリティアドバイザリ（CVE）を自動収集し、AIが日本語で分かりやすく3行要約。日々のキャッチアップにかかる時間を大幅に削減し、安全なプロダクト開発をサポートします。
最新の脆弱性情報
よく探す:
深刻度:
全 1414 件中 1414 件を表示
CVE-2026-71851criticalCVSS: 9
2026-08-07crypto-js: Insufficient Entropy in Cryptographic Secret Generation via Vulnerable CryptoJS Dependency Chain
AIで3行以内に要約した超簡単な概要
`crypto-js`ライブラリの一部のバージョンで、セキュアでない乱数生成器が使用されていました。これにより、暗号鍵や仮想通貨ウォレットの復元フレーズなど、機密性の高い情報が推測され、攻撃者に盗まれるリスクがあります。 影響を受ける期間に生成された情報は危険なため、ライブラリの緊急アップデートと、影響を受けた情報の再生成が必須です。
要約した概要
### 脆弱性の概要
`crypto-js`ライブラリのバージョン4.0.0未満において、`CryptoJS.lib.WordArray.random()`関数が使用する乱数生成器は、暗号学的に安全ではありませんでした。これは`Math.random()`をシードとするカスタムの疑似乱数生成器に依存していたため、十分なランダム性（エントロピー）を持たず、生成される値のパターンが予測されやすい状態でした。例えば、本来128ビットや256ビットのランダム性が期待される場面でも、実際には2の39乗や2の47乗程度の限られた選択肢しかなく、一般的なコンピュータでも総当たり攻撃によって短時間で推測できてしまうレベルでした。
### 影響を受ける条件と経緯
この脆弱性は、`crypto-js`のバージョン3.1.2-4から3.x系のほとんど（3.2.0と3.2.1を除く）に存在しました。バージョン3.3.0で一度は変更が戻されましたが、脆弱な乱数生成器は残存していました。この問題は、バージョン4.0.0でプラットフォームネイティブの暗号API（Web Crypto APIやNode.js `crypto`モジュールなど）を使用するように変更されたことで修正されました。
アプリケーションは、単に`crypto-js < 4.0.0`に依存しているだけでは脆弱ではありません。**`CryptoJS.lib.WordArray.random()`関数を、暗号鍵、トークン、仮想通貨ウォレットの復元フレーズ（BIP39）など、セキュリティ上極めて重要な値を生成するために直接使用している場合にのみ影響を受けます。** 一度生成された値のランダム性が低い場合、その後にPBKDF2のような鍵導出関数やハッシュ関数を適用しても、失われたランダム性を取り戻すことはできません。
実際に、仮想通貨ウォレットアプリケーションがこの脆弱な関数をBIP39の復元フレーズ生成に使用した事例が確認されており、攻撃者によって数百万ドル規模の資産が盗難される被害が発生しています。この被害は永続的であり、一度脆弱な方法で生成されたシークレットは、ライブラリやウォレットを更新しても安全にはなりません。将来的にそのアドレスへの入金も危険に晒される可能性があります。
### 推奨される対応策
**フロントエンド開発者向け（プロジェクト側）:**
1. **`crypto-js`ライブラリをバージョン`4.0.0`以降に直ちにアップグレードしてください。** 可能であれば、CryptoJSの乱数生成機能の代わりに、ブラウザの`Web Crypto API`やNode.jsの`crypto`モジュールなど、プラットフォームが提供するネイティブの暗号APIを使用することを強く推奨します。
2. 自身のプロジェクトだけでなく、依存しているライブラリ（直接的・間接的問わず）が`crypto-js`のバージョン`4.0.0`未満を使用していないか、徹底的に監査してください。
3. `CryptoJS.lib.WordArray.random()`関数が、これまでどのセキュリティ上重要な値（ユーザーのパスワードハッシュのソルト、APIキー、セッショントークン、暗号鍵など）の生成に使われたかを特定してください。
4. 脆弱な乱数生成パスが存在したアプリケーションのバージョンと期間を特定します。
5. **特定された期間に生成された、長期的に使用されるすべての機密情報（例：ウォレットのシード、APIキー、認証情報など）は、侵害されたものとみなし、直ちに再生成（ローテーション）してください。**
6. 影響を受けるユーザーに対して、ライブラリのアップデートだけでは過去に生成された機密情報は安全にならないことを通知し、影響を受けた情報の再生成を促してください。
**ウォレット利用者向け:**
1. **新しいウォレットを、信頼できるソースから新たに作成し、新しい復元フレーズを生成してください。**
2. 既存のウォレットから、新しく安全な方法で生成されたウォレットのアドレスへ、資産を速やかに移動してください。
3. **既存の復元フレーズを、新しいウォレットや更新されたウォレットにインポートしてはなりません。** そのフレーズはすでに安全ではない可能性があります。
**重要:** Coinspectが提供する公開チェッカー（[https://illbloom.org/](https://illbloom.org/)）で自身のアドレスが流出データセットに含まれているか確認できますが、**絶対に復元フレーズ、シードフレーズ、ニーモニック、秘密鍵、パスワードなどを入力しないでください。** 公開されているブロックチェーンアドレスのみを入力してください。
crypto-js
< 4.0.0→4.0.0GHSA-55q2-fjhq-7xh7medium
2026-08-07DOMPurify: IN_PLACE hook removal leaves a detached subtree executable, causing XSS
AIで3行以内に要約した超簡単な概要
DOMPurifyの`IN_PLACE`モードと特定のカスタムフックを組み合わせると、HTMLサニタイズ後もXSS（クロスサイトスクリプティング）が発生する可能性があります。削除された要素の子孫に不正なJavaScriptイベントハンドラが残り、実行されてしまうためです。該当する設定を利用している場合、早急にDOMPurifyを最新版へアップデートしてください。
要約した概要
### 脆弱性の仕組み
DOMPurify 3.4.12以前のバージョンでは、`IN_PLACE`モードでサニタイズを行う際に脆弱性がありました。`beforeSanitizeElements`や`uponSanitizeElement`といったカスタムフックを使って特定の要素をDOMから削除する処理を行った場合、その要素自体は削除されます。
しかし、削除された要素の子孫（例：`<footer>`内の`<img>`タグ）に不正なイベントハンドラ（例：`onload="alert(1)"`）が設定されていた場合、DOMPurifyが通常行うはずの子孫要素の無害化処理がスキップされてしまいます。
これは、フックが要素を削除した際にサニタイズ処理がすぐにリターンしてしまい、子孫要素のイベントハンドラを無効化する重要な処理（`_neutralizeSubtree()`）が呼ばれないためです。
結果として、サニタイズ処理は完了し、返されるDOMは安全に見えますが、ブラウザのイベントキューには無害化されなかったイベントハンドラが残っており、後になって実行されてXSS攻撃につながる可能性があります。この問題は、通常のDOMPurifyの削除パスでは発生せず、カスタムフックによる早期リターン時のみに起こります。
### 影響を受ける条件とリスク
この脆弱性の影響を受けるのは、DOMPurifyを以下の設定で利用しているアプリケーションです。
* `IN_PLACE: true` が設定されていること。
* 要素を削除するカスタムフック（`beforeSanitizeElements`または`uponSanitizeElement`）が使われていること。
攻撃者がアプリケーションにHTMLコンテンツを供給できる場合、上記の設定が組み合わさっていると、アプリケーションがコンテンツをサニタイズして画面にレンダリングした後でも、不正なJavaScriptコードが実行される可能性があります。フック自体が悪意のあるハンドラを追加するわけではなく、あくまで既存の正規のハンドラが無害化されずに残ってしまうことが問題です。
### 推奨される対応策
この脆弱性を修正するためには、DOMPurifyのバージョンを更新し、修正が適用された最新バージョンを使用してください。具体的には、`_sanitizeElements()`関数内で、フックによって要素が切り離された際に、既存の`_neutralizeSubtree(currentNode)`ヘルパーを呼び出すように変更されています。
また、同様の脆弱性が再発しないよう、`beforeSanitizeElements`および`uponSanitizeElement`フックに関する退行テストを追加し、祖先要素がフックによって切り離された後に、子孫のリソース要素（例：`<img>`）のイベントハンドラが確実に削除されることを検証することが望ましいとされています。
dompurify
<= 3.4.12→3.4.13CVE-2026-71498mediumCVSS: 5.1
2026-08-06node-re2: Out-of-bounds heap read in `replace`/`split` via a `Buffer` ending in a truncated multi-byte UTF-8 character → adjacent heap memory disclosed to JavaScript
AIで3行以内に要約した超簡単な概要
node-re2ライブラリに、特定のBuffer入力によって情報漏洩が発生する脆弱性があります。 アプリケーションのヒープメモリから最大3バイトのデータが攻撃者に読み取られる危険性があります。 速やかにre2@1.26.1以上へアップグレードしてください。
要約した概要
node-re2ライブラリに、Buffer型の入力に対する「ヒープ領域の範囲外読み取り（Out-of-bounds heap read）」の脆弱性が発見されました。特に`replace()`や`split()`メソッドを使用している場合に影響があります。
**脆弱性の仕組み:**
re2は、`Buffer`を入力として渡された際に、UTF-8文字のバイト長を正しく判断できないことがあります。マルチバイトUTF-8文字（例えば日本語の文字など）の途中で`Buffer`が切れて終わっている場合、re2はその文字の残りのバイトがあると誤解し、本来の`Buffer`の領域を超えて最大3バイトまで読み取ってしまいます。これは、re2内部の文字サイズを計算する関数が、残りのバイト数を考慮せず、UTF-8の先頭バイトだけで文字の長さを推測しているためです。
**影響:**
1. **情報漏洩の可能性:** `replace()`や`split()`メソッドを使用している場合、この範囲外の読み取りで得られたデータが、隣接するアプリケーションのヒープメモリ領域からJavaScriptに返されてしまいます。攻撃者は入力`Buffer`を工夫することで、ヒープメモリの内容を少しずつ読み取り、機密情報（セッション情報、個人情報、パスワードの一部など）を不正に取得できる可能性があります。
2. **サービス停止の可能性:** `RE2`コンストラクタに不正な`Buffer`を渡してパターンをコンパイルする際にも同様の範囲外読み取りが発生しますが、この場合はパターンが無効として拒否されるため、情報漏洩にはつながりません。しかし、バッファがメモリページの境界で終わっている場合に範囲外を読み取ろうとすると、アプリケーションがクラッシュし、サービスが停止する可能性があります。
**影響を受ける条件と受けない条件:**
この脆弱性は、`Buffer`型の入力を使用する場合のみ影響を受けます。JavaScriptの文字列を`re2`に渡す場合は、re2が内部で適切にUTF-8エンコーディングを処理するため、この脆弱性の影響は受けません。また、入力`Buffer`が常に完全な（切り詰められていない）UTF-8文字で構成されている場合も安全です。
**推奨される対応策:**
1. **最優先の対応:** `node-re2`ライブラリを`re2@1.26.1`以降のバージョンに速やかにアップグレードしてください。このバージョンで脆弱性は修正済みです。
2. **アップグレードが困難な場合の暫定的な回避策:**
* `replace()`、`split()`、`RE2`コンストラクタに`Buffer`を直接渡すのを避け、可能な限りJavaScriptの文字列を渡すように変更してください。
* どうしても`Buffer`を渡す必要がある場合は、事前にその`Buffer`が完全なUTF-8形式であるかを確認するバリデーション処理を追加してください。例えば、`Buffer.compare(Buffer.from(buf.toString('utf8')), buf) === 0`のようなチェックが考えられます。
re2
<= 1.26.0→1.26.1CVE-2026-71430mediumCVSS: 6.2
2026-08-06node-re2: String.prototype.replace(re2, template) aborts the Node process (uncatchable ToLocalChecked on empty MaybeLocal) when the result exceeds V8's max string length
AIで3行以内に要約した超簡単な概要
node-re2ライブラリを使用している場合、特定の正規表現置換でNode.jsプロセス全体が突然クラッシュする脆弱性が見つかりました。 これは`try/catch`で防げない致命的なエラーで、攻撃者によってサービス停止（DoS）を引き起こされる可能性があります。 システムが停止する恐れがあるため、すぐに`re2`パッケージを最新版（1.25.1以上）にアップデートしてください。
要約した概要
node-re2ライブラリの`String.prototype.replace`メソッドに脆弱性があり、特定の条件下でNode.jsプロセス全体が強制終了してしまいます。
**脆弱性の具体的な仕組みと発生条件:**
この問題は、正規表現の置換結果がV8エンジンの扱える最大文字列長（64ビット環境で約536MB）を超えた場合に発生します。特に、置換テンプレートに`$'`（マッチした部分の後ろの文字列）や`` $` ``（マッチした部分の前の文字列）を含め、かつグローバル置換（`g`フラグ）を行う場合に、結果文字列のサイズが元の入力文字列の長さの二乗に比例して爆発的に増加することがあります。
通常、V8エンジンは文字列が長すぎる場合に「空のデータ」を返しますが、`node-re2`はこの空の返り値をチェックせずに処理を続行してしまいます。その結果、V8内部で致命的なエラーが発生し、Node.jsプロセス自体が`abort()`（強制終了）してしまいます。
**もたらされるリスクと影響:**
* **捕捉不可能なクラッシュ:** このエラーはJavaScriptの例外ではないため、通常の`try/catch`ブロックでは捕捉できません。一度発生すると、そのNode.jsプロセスまたはワーカー全体が停止してしまいます。
* **サービス拒否（DoS）攻撃:** 攻撃者が、例えばユーザーからの入力値などを操作して、意図的にこの条件を満たすような文字列や置換テンプレートを渡した場合、認証なしでリモートからNode.jsサービスを強制的に停止させることが可能です。
* **標準的な挙動との乖離:** Node.jsの標準的な正規表現エンジンでは、このようなケースでは「文字列長が不正です」という捕捉可能な`RangeError`をスローしますが、`node-re2`はプロセスを強制終了させてしまうため、より危険です。
**推奨される対応策:**
この脆弱性は`re2`パッケージのバージョン`1.25.1`で修正されています。プロジェクトで使用している`re2`パッケージを、`npm upgrade re2`などのコマンドで`1.25.1`以上にすぐにアップデートしてください。
この修正により、強制終了する代わりに標準エンジンと同様に捕捉可能な`RangeError: Invalid string length`がスローされるようになります。APIの変更はないため、バージョンアップだけで修正が適用されます。
re2
<= 1.25.0→1.25.1GHSA-5p4m-2wfm-xmqjhighCVSS: 7.5
2026-08-06JS-YAML: Quadratic CPU consumption in !!omap resolution (3.x and 4.x) — CVE-2026-59870 fix not backported
AIで3行以内に要約した超簡単な概要
js-yaml v3.x/v4.xでは、特定のYAMLデータ（`!!omap`）をパースする際にCPU使用率が急増し、サービス停止（DoS）のリスクがあります。 攻撃者が操作可能なYAMLを処理するシステムは、少ないデータ量でも機能不全に陥る可能性があります。 v5.xでは修正済みのため、早急なバージョンアップを強く推奨します。
要約した概要
### 脆弱性の概要
js-yamlライブラリのバージョン3.xおよび4.xにおいて、`!!omap`という形式のYAMLデータをパースする際に、CPU使用率が異常に高くなる脆弱性が存在します。これは、キーの重複チェックに非効率なアルゴリズム（O(n²)の計算量）が使用されているためです。結果として、攻撃者が意図的に作成した小さなYAMLドキュメントでも、サービスが停止するサービス拒否（DoS）攻撃を引き起こす可能性があります。
### 脆弱性の詳細と影響
`yaml.load()`関数が`!!omap`シーケンス内のキーの一意性をチェックする際、要素ごとのループ内で線形探索（`Array.prototype.indexOf`）を実行します。これにより、キーの数 `n` が増えるにつれて、処理時間が `n` の2乗に比例して増加します。例えば、80,000エントリのYAMLをパースすると2.5秒以上、150,000エントリ（約2.5MB）のドキュメントでは10秒以上もの処理停止が発生する可能性があります。
この処理はNode.jsのイベントループを同期的にブロックするため、単一のリクエストがプロセス全体の他のリクエストも停止させ、アプリケーション全体が応答不能に陥る深刻な影響があります。`!!omap`はデフォルトスキーマに登録されているため、特別なオプションなしで`yaml.load()`を使用している場合でもこの脆弱性の影響を受けます。
この脆弱性は、js-yaml 5.x系で修正されたCVE-2026-59870と同じ根本原因を持っていますが、その修正が3.xおよび4.x系にはバックポートされていません。
### 影響を受けるバージョン
* **js-yaml 3.x系**: 3.15.0までの全バージョンが影響を受けます。
* **js-yaml 4.x系**: 4.3.0までの全バージョンが影響を受けます。
* **js-yaml 5.x系**: 5.2.1以降のバージョンは、この脆弱性の影響を受けません（5.2.0以前の5.x系は影響を受けます）。
### 推奨される対応策
**最優先でjs-yamlをバージョン5.x系（5.2.1以降）にアップデートしてください。**
バージョン5.xでは、キーの重複チェックに効率的な`Set`データ構造が使用されており、この脆弱性は完全に解決されています。バージョンアップが難しい場合でも、攻撃者が操作可能な信頼できないYAMLデータをjs-yamlでパースする処理を見直すか、外部からの入力で`!!omap`形式の利用を制限するなどの対策を検討してください。しかし、これらの対策は根本的な解決ではないため、バージョンアップが最も推奨される対応策です。
js-yaml
>= 4.0.0, < 4.3.1→4.3.1js-yaml
>= 3.0.0, < 3.15.1→3.15.1Advertisement
CVE-2026-71320highCVSS: 8.1
2026-08-05Nuxt: Server-Side Remote Code Execution via Runtime Template Injection in Nuxt Server Island Props
AIで3行以内に要約した超簡単な概要
Nuxtの特定のバージョンと設定において、攻撃者がNuxt Server Islandを悪用し、サーバー上で任意のコードを実行できてしまう脆弱性が見つかりました。 `vue.runtimeCompiler: true`（デフォルトは無効）を使用している場合に影響を受けます。 ほとんどのNuxtアプリはデフォルト設定で影響を受けませんが、該当する場合は速やかに最新バージョンへアップグレードしてください。
要約した概要
### 脆弱性の概要
この脆弱性は、Nuxtのサーバーアイランド機能に存在します。通常はサーバーサイドで実行されるコンポーネント（Server Island）が、攻撃者によって制御されたテンプレートコードを受け取ってしまい、それをサーバー上で実行してしまう可能性があります。
具体的には、以下の条件がすべて揃った場合に脆弱性が成立します：
1. **Nuxtのバージョン:** `3.4.0`から`3.21.10`未満、または`4.0.0`から`4.5.1`未満のNuxtを使用している。
2. **Vueのランタイムコンパイラ:** Nuxtの設定で`vue.runtimeCompiler: true`が有効になっている（**デフォルトは`false`であり、ほとんどのアプリケーションは影響を受けません**）。
3. **動的コンポーネントの利用:** アプリケーションに、サーバーアイランドコンポーネントがあり、それがVueの動的コンポーネント解決機能（例: `<component :is>`、`resolveDynamicComponent`、`h()` 関数、または`@nuxt/ui`などのライブラリが提供する`as` / `asChild`プロパティ）に、プロパティを渡している場合。
この状況下で、攻撃者はアイランドのプロパティに悪意のある`template`キーを注入することで、Vueのランタイムテンプレートコンパイラにそれをサーバープロセスでコンパイル・実行させ、サーバーサイドでのリモートコード実行（RCE）を可能にします。例えば、`{"as": {"template": "<攻撃者制御のコード>"}}`のような形式で悪用されます。
### 影響を受ける条件と要因
* `vue.runtimeCompiler` がデフォルトの`false`であるNuxtアプリケーションは、この脆弱性の影響を受けません。
* たとえ`vue.runtimeCompiler: true`が有効であっても、サーバーアイランドが攻撃者制御の値を動的コンポーネントパスに渡していない場合は影響を受けません。
* `@nuxt/ui`のようなUIライブラリは、`as`や`asChild`といったプロパティを介して動的コンポーネント解決を行うことが多く、これが意図せず脆弱な状態を生み出す可能性があります。明示的にプロパティを転送していなくても、Vueの属性継承により、アイランドのルート要素がこれらの多態性コンポーネントである場合、間接的に影響を受けることがあります。
* 静的サイト生成（SSG）や静的デプロイメントでは、RCEの対象となるサーバープロセスが存在しないため、この脆弱性の影響はほとんどありません。
### 推奨される対応策
**最優先の対策は、Nuxtを最新の修正済みバージョンにアップグレードすることです。**
* **Nuxt 4系:** `nuxt@4.5.1`以降にアップグレードしてください。
* **Nuxt 3系:** `nuxt@3.21.10`以降にアップグレードしてください。
**すぐにアップグレードできない場合の暫定的な回避策:**
1. **`vue.runtimeCompiler`の設定確認:** Nuxtの設定ファイル（`nuxt.config.ts`など）で、`vue.runtimeCompiler`が**必ず`false`に設定されていることを確認してください**。これがデフォルト設定であり、ほとんどのケースでは変更する必要はありません。
2. **プロパティのサニタイズ:** サーバーアイランドのプロパティを`<component :is>`、`resolveDynamicComponent`、または`h()`関数に渡す前に、信頼できない入力が含まれていないか厳密に検証し、サニタイズしてください。
3. **WAF（Web Application Firewall）の導入:** 念のための防御策として、WAFルールを設定し、`/__nuxt_island/`エンドポイントへのリクエストのうち、URLデコードおよびJSONパースされた`props`値に`template`または`render`という名前のプロパティが含まれているものをブロックします。ただし、この方法はエッジでのリクエストにのみ有効であり、サーバー内部でのSSRレンダリングには適用されないため、完全な対策ではない点に注意してください。
nuxt
>= 4.0.0, < 4.5.1→4.5.1nuxt
>= 3.4.0, < 3.21.10→3.21.10CVE-2026-71318mediumCVSS: 4.8
2026-08-05Nuxt: Unauthorized Component Instantiation via Server Island Props
AIで3行以内に要約した超簡単な概要
Nuxtのサーバーアイランド機能に脆弱性があり、外部からの悪意ある入力によって、意図しないVueコンポーネントやHTML要素がレンダリングされる可能性があります。これにより情報漏洩やサイトの見た目の改ざんリスクがあるため、Nuxtのバージョンを早急に最新版にアップデートしてください。
要約した概要
### 脆弱性の概要と仕組み
Nuxtのサーバーアイランドは、`/__nuxt_island/` エンドポイントを通じてプロパティ（props）を受け取ります。この脆弱性は、サーバーアイランド内のコンポーネントが受け取ったプロパティをVueの動的コンポーネント解決機能（`<component :is>`、`resolveDynamicComponent`、`h()` など）に直接渡す場合に発生します。
攻撃者は、コンポーネント定義の代わりに単純な文字列値（例: `{ "as": "SomeGlobalComponent" }` や `{ "as": "iframe" }`）をプロパティとして送り込むことができ、これにより、グローバルに登録されている任意のVueコンポーネントや、`<iframe>` のような任意のネイティブHTML要素を不正にインスタンス化・レンダリングさせることが可能になります。特に重要なのは、この攻撃には以前の脆弱性（RCE）と異なり、`vue.runtimeCompiler` が有効である必要がないため、より多くのNuxtアプリケーションが影響を受ける可能性がある点です。
`@nuxt/ui`（`reka-ui` 経由）のような、`as` や `asChild` といったポリモーフィックなプロパティを持つUIライブラリがサーバーアイランドのルートコンポーネントとして使用されている場合、プロパティが明示的に宣言されていないと、リクエストからの入力が「属性フォールスルー」という仕組みを通じて自動的にこれらのプロパティに渡されてしまい、攻撃者は動的コンポーネントの解決を容易に制御できます。
### 影響を受ける条件とリスク
この脆弱性は、Nuxtのバージョンが **`3.1.0` 以上 `3.21.10` 未満**、または **`4.0.0` 以上 `4.5.1` 未満** の環境で、サーバーアイランド機能がアクティブなアプリケーションに影響します。
攻撃が成功した場合、以下のようなリスクがあります。
* **情報漏洩**: グローバルに登録されているコンポーネント（`RouterView`、`RouterLink`、`components/global/` 下のコンポーネント、モジュールがグローバル登録したものなど）を不正に表示させ、本来なら見えないはずの情報が外部に漏れる可能性があります。
* **UIの改ざん**: 意図しないHTML要素（例: `<iframe>`）を挿入したり、画面のレイアウトを崩したりする可能性があります。
* **機能の誤用**: `RouterLink` のようなコンポーネントを悪用して、意図しないURLへ誘導するリンクを生成させることも可能です。
ただし、この脆弱性による攻撃では、任意のJavaScriptコードを実行することはできません。実行されるのは、アプリケーションのビルド時に登録されているコンポーネントやHTML要素のレンダリングに限定されます。
### 推奨される対策
1. **最優先の対策**: Nuxtを直ちに **`nuxt@4.5.1`** または **`nuxt@3.21.10`** にアップデートしてください。これらのパッチバージョンでは、トップレベルの `as` プロパティがサーバーアイランドのプロパティとして渡された場合、HTTP 400エラーとして拒否され、暗黙的な属性フォールスルーによる脆弱性が解消されます。これにより、ほとんどのケースでこの攻撃がブロックされます。
2. **すべてのバージョンで推奨される追加のセキュリティ対策**: アップデート後も以下の点を考慮することで、より堅牢なアプリケーションになります。
* サーバーアイランド内で受け取ったプロパティを、`<component :is>`、`resolveDynamicComponent`、`h()`などの動的コンポーネント解決の機構に直接渡すことは避けてください。もし動的にコンポーネントを切り替える必要がある場合は、事前に定義された信頼できるコンポーネントのホワイトリストを作成し、その中から選択させるように実装してください。
* サーバーアイランドが受け入れるプロパティを明示的に宣言するか、コンポーネントに `inheritAttrs: false` を設定して、リクエストから送られてきた宣言されていないプロパティがルートコンポーネントに自動的に渡されないようにしてください。
* 攻撃者によって意図せずインスタンス化された場合に、情報漏洩や悪用につながる可能性のある機密性の高いコンポーネントは、グローバルに登録しないように検討してください。
nuxt
>= 4.0.0, < 4.5.1→4.5.1nuxt
>= 3.1.0, < 3.21.10→3.21.10CVE-2026-71315highCVSS: 8.2
2026-08-05Nuxt route rules silently dropped for mixed-case paths, bypassing appMiddleware auth gates (incomplete fix for CVE-2026-53721)
AIで3行以内に要約した超簡単な概要
Nuxtで大文字・小文字が混在するURLパス（例: `/Admin`）を使用すると、認証などのセキュリティルールが適用されず、保護されたページに未認証のユーザーがアクセスできてしまう脆弱性があります。 これは以前のセキュリティ修正が不完全だったために発生しており、早急にNuxtを最新バージョンにアップデートしてください。 アクセス制御のバイパスにつながるため、対応の緊急度が高いです。
要約した概要
### 脆弱性の仕組み
Nuxtでは、通常URLパスの大文字・小文字を区別せずにルーティングルールを適用します。しかし、以前のセキュリティ修正（CVE-2026-53721）の際、ユーザーからのURLパスはすべて小文字に変換されるようになったにもかかわらず、`routeRules`で定義されたルールキー（例: `routeRules: { '/Admin/dashboard': ... }` や、`pages/Admin.vue`のような大文字・小文字が混在するファイル名から自動生成されるルール）は大文字・小文字がそのまま維持されていました。
このため、小文字に変換されたURLパスと、大文字を含むルールキーが一致しなくなり、結果として、大文字・小文字が混在するURLパスに対して該当する`routeRules`が「密かに」適用されない状態になっていました。
### 影響を受ける条件とリスク
この脆弱性の最も深刻な影響は、`appMiddleware`で設定された認証機能がバイパスされることです。例えば、`/Admin/dashboard`というパスに認証ミドルウェアを適用していても、実際には認証されていないユーザーが`/Admin/dashboard`、`/admin/dashboard`、`/ADMIN/dashboard`といった異なる大文字・小文字の組み合わせのURLで、保護されたページやそのページでサーバーから取得されるデータにアクセスできてしまいます。本来行われるべきログインページへのリダイレクトなども発生しません。
認証機能のバイパス以外にも、クライアントサイドのリダイレクトミドルウェア、アプリサイドでの`ssr: false`（サーバーサイドレンダリングを無効にする設定）、プリレンダリング、ペイロードの処理など、Nuxtが提供する他のアプリレベルのルーティング関連の保護も、大文字・小文字が混在するキーを持つ`routeRules`では適用されなくなります。
**注意点**: サーバーサイドで処理される`headers`、`redirect`、`proxy`といった`routeRules`は、NuxtではなくNitroによって処理されるため、この脆弱性の影響は受けません。
### 推奨される対応策
**最も推奨される対応**: Nuxtを以下のバージョンにアップデートしてください。
* Nuxt 4.x系: `nuxt@4.5.1`
* Nuxt 3.x系: `nuxt@3.21.10`
これらの修正バージョンでは、ルールキーとURLパスの両方で大文字・小文字の正規化が適切に行われるようになり、問題が解決されています。
**緊急の回避策（すぐにアップデートできない場合）**:
以下のいずれかの方法で、一時的に脆弱性を軽減できます。
1. **すべての`routeRules`のキーとページファイル名を完全に小文字で統一する**: これにより、URLパスが小文字に変換されてもルールキーと一致するようになります。
2. **Nuxtの設定でルーティングを大文字・小文字厳密に区別するように変更する**: `nuxt.config.ts`で `router: { options: { sensitive: true } }` を設定してください。この設定により、ルーティングと`routeRules`のマッチングが両方とも大文字・小文字を厳密に区別するようになります。ただし、ユーザーはURLパスの大文字・小文字を正確に入力する必要があります。
3. **`routeRules`に依存せず、サーバーサイドで別途セキュリティ保護を実装する**: 例えば、Nuxtのサーバーミドルウェアなどで独自の認証チェックを実装し、`routeRules`が適用されなくてもセキュリティが確保されるようにします。
nuxt
>= 4.4.7, < 4.5.1→4.5.1nuxt
>= 3.21.7, < 3.21.10→3.21.10CVE-2026-71314highCVSS: 7.5
2026-08-05Nuxt: Unauthenticated out-of-memory crash via unbounded v-for expansion in island rendering
AIで3行以内に要約した超簡単な概要
Nuxtのサーバーコンポーネントで`v-for`を使っていると、外部からの不正なリクエストでサーバーがメモリ不足になり、クラッシュする可能性があります。 サービス停止につながるため、認証なしで攻撃可能な深刻な脆弱性です。 すぐにNuxtを最新バージョンにアップデートしてください。
要約した概要
### 脆弱性の概要と仕組み
この脆弱性は、Nuxtアプリケーションにおいて、アイランド（Island）またはサーバーコンポーネント内で`v-for`ディレクティブが外部から渡されるプロパティ（例: `v-for="n in count"`）を反復処理する際に発生します。
認証されていない攻撃者が、この`v-for`の繰り返し回数を表すプロパティに、非常に大きな数値を指定したリクエストを送ることができます。Nuxtサーバーはこれを基にSSR（サーバーサイドレンダリング）を実行しようとし、指定された回数分のDOMノードを生成するために膨大なメモリを消費します。結果として、サーバーはメモリを使い果たし（Out-of-Memory: OOM）、クラッシュしてしまいます。
この攻撃は認証が不要であり、わずか130バイト程度の小さなリクエストでサーバーを停止させることが可能なため、非常に危険です。
### 影響を受ける条件とリスク
* `nuxt@4.5.1`および`nuxt@3.21.10`より古いバージョンのNuxtを使用している場合に影響を受けます。
* 特に、Nuxtのアイランド機能やサーバーコンポーネントにおいて、`v-for`ディレクティブを外部から受け取るプロパティに対して直接使用しているアプリケーションが影響対象です。
* サーバーがクラッシュすることで、アプリケーションのサービスが完全に停止する可能性があり、外部からの攻撃によって容易にサービス妨害（DoS）を受けるリスクがあります。
### 推奨される対応策
**最優先でNuxtを最新バージョンにアップデートしてください。**
* この脆弱性は、`nuxt@4.5.1`および`nuxt@3.21.10`以降のバージョンで修正されています。これらのバージョンでは、`v-for`の最大繰り返し回数が100,000に制限され、メモリ枯渇が防止されるようになります。
**アップデートがすぐに難しい場合の回避策:**
* サーバーコンポーネント内で、外部から渡されるプロパティを直接`v-for`の繰り返し元として使用することを避けてください。
* やむを得ず使用する場合は、コンポーネント内部で繰り返し回数に上限を設定するロジックを追加してください（例: `v-for="n in Math.min(count, 1000)"`）。
* `/__nuxt_island/`へのリクエストに対するボディサイズ制限は、配列形式の入力による攻撃には有効ですが、攻撃者が整数で繰り返し回数を指定するケースには十分な対策とはならない点に注意が必要です。
nuxt
>= 4.0.0, < 4.5.1→4.5.1nuxt
>= 3.1.0, < 3.21.10→3.21.10CVE-2026-70609mediumCVSS: 5.7
2026-08-05Electron: DevTools JavaScript Injection via Unsanitized Dock State Parameter
AIで3行以内に要約した超簡単な概要
Electronアプリで、開発者ツール（DevTools）の設定に脆弱性が見つかりました。悪意のある入力によってDevTools内で任意のコードが実行され、Node.js機能まで悪用される危険性があります。アプリのセキュリティを保つため、速やかなアップデートまたは推奨される回避策の適用が不可欠です。
要約した概要
この脆弱性は、Electronの `webContents.openDevTools()` メソッドの `mode` オプションが、DevToolsのフロントエンドで使用される前に適切にサニタイズ（安全な形式に無害化）されていなかったことに起因します。
攻撃者がこの `mode` の値を操作できる場合、DevToolsのコンテキスト内で攻撃者自身のJavaScriptコードを実行させることが可能になります。特に、アプリがサンドボックス（隔離環境）化されていない構成の場合、DevToolsコンテキストはNode.jsの機能にアクセスできるため、ファイルシステムの操作や外部コマンドの実行など、アプリやシステムに深刻な被害をもたらす恐れがあります。
**この脆弱性の影響を受けるアプリの条件:**
* 信頼できない入力（ユーザー入力など）が `openDevTools()` メソッドの `mode` 引数に直接渡される可能性がある場合。
* または、アプリに埋め込まれた `<webview>` 内の信頼できないコンテンツが、その `webview` に対して `openDevTools()` を呼び出せる場合。
常に固定された安全なドックモードの値のみを渡しているアプリは、この脆弱性の影響を受けません。
**推奨される対応策:**
1. **アップデート:** アプリで使用しているElectronを、以下のいずれかの修正済みバージョンに速やかにアップデートしてください。
* `42.0.0-beta.1`
* `41.2.0`
* `40.9.0`
* `39.8.7`
2. **回避策:** すぐにアップデートできない場合は、以下の回避策を適用してください。
* `openDevTools()` を呼び出す際、`mode` 引数には `right`, `bottom`, `undocked`, `detach` のように、許可された固定値のみを渡すように徹底してください。
* 信頼できないコンテンツやユーザー入力から `openDevTools` メソッドへのアクセスを絶対に許可しないでください。
electron
< 39.8.7→39.8.7electron
>= 40.0.0-alpha.1, < 40.9.0→40.9.0electron
>= 41.0.0-alpha.1, < 41.2.0→41.2.0electron
>= 42.0.0-alpha.1, < 42.0.0-beta.1→42.0.0-beta.1Advertisement
CVE-2026-70603mediumCVSS: 6
2026-08-05Electron: shell.openPath path validation bypass via embedded null byte
AIで3行以内に要約した超簡単な概要
Electronアプリで、ユーザーからの悪意あるファイルパスが文字列検証をすり抜け、意図しないファイルを開く可能性がありました。 ユーザーからのパスを`shell.openPath()`に渡す場合は、ヌルバイト（`\0`）のチェックと、修正バージョンへの更新が必須です。 放置すると、攻撃者にシステム上の別のファイルを開かれるリスクがあります。
要約した概要
この脆弱性は、Electronの`shell.openPath()`メソッドが、埋め込まれたヌルバイト（`\0`）を含むファイルパスを適切に拒否しなかったことに起因します。アプリケーションがファイルパスの拡張子チェックなどの文字列ベースの検証のみを行い、その後`shell.openPath()`にそのパスを渡した場合、攻撃者はパスにヌルバイトを挿入することで、検証をすり抜け、意図しない異なるファイルを開かせることが可能でした。
具体的には、例えば`image.png\0bad_script.sh`のようなパスが文字列検証を通過しても、`shell.openPath()`はヌルバイトの手前までを有効なパスとして解釈し、最終的に`image.png`ではなく、悪意のある`bad_script.sh`が開かれてしまう、といった状況が起こりえました。
この脆弱性の影響を受けるのは、以下の両方の条件を満たすElectronアプリケーションです。
1. 信頼できない（ユーザー入力など、攻撃者が制御可能な）ソースから取得したパスを`shell.openPath()`に渡している。
2. ファイルシステムでの実際の存在確認などを行わず、ファイルパスに対して文字列ベースの検証のみに依存している。
Node.jsの`fs`モジュール（`fs.existsSync()`や`fs.stat()`など）はヌルバイトを含むパスを拒否するため、`shell.openPath()`の前にこれらの`fs` APIを使ってファイルシステムチェックを行っているアプリは影響を受けません。また、信頼できるパスのみを`shell.openPath()`に渡しているアプリも影響を受けません。
**推奨される対応策:**
1. **修正済みバージョンへのアップデート:**
* `42.0.0-beta.1`
* `41.1.1`
* `40.9.0`
* `39.8.6`
上記を含む、修正が適用された最新バージョンへ速やかにアップデートしてください。
2. **回避策:**
アップデートが難しい場合は、`shell.openPath()`にパスを渡す前に、ヌルバイト（`\0`）が含まれていないかをチェックし、含まれている場合は拒否する処理を実装してください。JavaScriptのコード例は以下の通りです。
```javascript
if (filePath.includes('\0')) {
throw new Error('無効なパスです: ヌルバイトが含まれています');
}
```
この対策により、`shell.openPath()`に悪意のあるパスが渡されるのを防ぐことができます。
electron
>= 42.0.0-alpha.1, < 42.0.0-beta.1→42.0.0-beta.1electron
>= 41.0.0-alpha.1, < 41.1.1→41.1.1electron
>= 40.0.0-alpha.1, < 40.9.0→40.9.0electron
< 39.8.6→39.8.6CVE-2026-70601highCVSS: 7.5
2026-08-05Electron: Context isolation bypass via Function.prototype.bind hijack
AIで3行以内に要約した超簡単な概要
Electronアプリで、Webコンテンツと連携する機能にセキュリティ上の脆弱性が見つかりました。悪意のあるコンテンツが本来隔離されているはずの領域に侵入し、最悪の場合、OSの機能まで実行される可能性があります。アプリ側の回避策はないため、すぐに最新版へのアップデートが必要です。
要約した概要
この脆弱性は、Electronが提供する`contextBridge`を使って、Promiseを返す関数をWebコンテンツに公開しているアプリに影響を与えます。具体的には、`Function.prototype.bind`というJavaScriptの標準機能が不正に操作されることで、本来Webコンテンツからはアクセスできない「プリロードスクリプト」の実行環境（`preload world`）に、信頼できないWebコンテンツが侵入できてしまう問題です。
これにより、攻撃者はプリロードスクリプトが持つあらゆる権限を悪用できるようになります。もし、アプリのレンダープロセスがサンドボックス保護されていなかったり、`nodeIntegration`が有効になっている場合、悪用されたプリロードスクリプトを通じて、Node.jsの機能にアクセスされ、システムレベルの操作（ファイルシステムへのアクセスや外部コマンド実行など）が行われるリスクがあります。
この脆弱性の影響を受けるのは、**信頼できない外部コンテンツを読み込むウィンドウ**で、かつ**`contextBridge`を介してPromiseを返す関数（例: `ipcRenderer.invoke`のラッパー）を公開している**Electronアプリです。これらの条件に当てはまらないアプリは影響を受けません。
**対応策としては、アプリ側でこの脆弱性を回避する方法はありません。** セキュリティを確保するためには、速やかに以下のいずれかの修正済みElectronバージョンにアップデートする必要があります。
* `42.0.0-beta.5`
* `41.2.2`
* `40.9.2`
* `39.8.9`
不明な点があれば、Electronのセキュリティチーム（`security@electronjs.org`）へ問い合わせてください。
electron
< 39.8.9→39.8.9electron
>= 40.0.0-alpha.1, < 40.9.2→40.9.2electron
>= 41.0.0-alpha.1, < 41.2.2→41.2.2electron
>= 42.0.0-alpha.1, < 42.0.0-beta.5→42.0.0-beta.5CVE-2026-70477critical
2026-08-04Flowise: CSV Agent Prompt Injection Remote Code Execution Vulnerability
AIで3行以内に要約した超簡単な概要
FlowiseのCSV Agentノードを使っていると、攻撃者が悪意のある質問（プロンプトインジェクション）を送るだけで、あなたのサーバー上で好きなプログラムを動かせてしまう脆弱性です。ログイン不要で攻撃される可能性があり、サーバー乗っ取りのリスクがあるため、すぐにアップデートしてください。
要約した概要
### 脆弱性の概要と危険性
Flowiseの『CSV Agent』ノードを使ったチャットフローに、遠隔からコードを実行できる脆弱性（CVE-2024-XXXX）が見つかりました。これは、攻撃者が巧妙な「質問文」（プロンプトインジェクション）を送ることで、Flowiseが稼働しているサーバー上で、攻撃者が指定した任意のプログラムを実行できてしまうというものです。この結果、サーバーの乗っ取り、機密情報の窃取、システムの破壊など、非常に深刻な被害につながる可能性があります。
### 脆弱性の具体的な仕組み
この脆弱性は、Flowiseの`CSV Agent`ノードを使用するチャットフローにおいて、以下の段階で発生します。
1. **プロンプトインジェクション:** 攻撃者が、`CSV Agent`ノードが組み込まれたチャットフローの予測エンドポイントに対し、悪意のあるプロンプト（質問）を送信します。
2. **悪意のあるスクリプトの生成:** チャットフローに設定された大規模言語モデル（LLM）は、このプロンプトに応答して、Pythonのコードを生成します。
3. **セキュリティチェックの回避:** Flowiseには、生成されたPythonコードが安全かどうかを検証するバリデーター（`validatePythonCodeForDataFrame`関数）が組み込まれています。しかし、このバリデーターは静的な正規表現によるブラックリスト方式に依存しており、攻撃者は文字列の連結、文字コードエンコーディング、組み込み関数のエイリアス化といった様々な難読化技術を駆使することで、このチェックを容易に回避できます。
4. **サンドボックス化されていない環境での実行:** 回避された悪意のあるPythonスクリプトは、`pyodide`環境で実行されます。通常、`pyodide`はブラウザ内でPythonコードを安全に実行するためのものですが、Flowiseのこの環境はサーバー上で動作し、ホストOSに対してフルアクセス可能な状態でした。このため、セキュリティチェックをすり抜けたPythonコードが、サーバーのOSインターフェースに直接アクセスし、任意のコマンドを実行できてしまいます。
根本的な原因は、ユーザーからの入力値がLLMへのプロンプト構築に使われる際に、その入力値のサニタイズ（安全な形式への変換・検証）が不十分だったことです。
### 影響を受ける条件と攻撃シナリオ
* **Flowiseのバージョン:** 報告されたテストバージョンは`3.1.1`ですが、関連するコードベースを持つ他のバージョンも影響を受ける可能性があります。
* **CSV Agentノードの使用:** `CSV Agent`ノードを含むチャットフローを運用しているFlowiseインスタンスが影響を受けます。
* **攻撃経路:**
* **プロンプトインジェクション（認証不要の可能性）:** 既存のチャットフローの予測エンドポイントに対し、直接悪意のあるプロンプトを送信する攻撃です。この場合、Flowiseへの認証は不要な場合があります。
* **悪意のあるチャットフローの構成（認証済み攻撃）:** 認証済みの攻撃者が、自身の管理するサーバーを参照するLLMモデル（例：`ChatOllama`）を設定したチャットフローを作成し、ペイロードをFlowiseのシステムに直接注入するケースも考えられます。
### 推奨される対応策
1. **最優先でFlowiseを最新の修正済みバージョンにアップデートしてください。** これが最も確実で推奨される対応策です。
2. もしすぐにアップデートが難しい場合は、`CSV Agent`ノードを使用するチャットフローを一時的に無効化するか、外部からのアクセスを制限することを強く推奨します。
3. 一般的なセキュリティ対策として、ユーザーからの入力値をLLMに渡す前に、より厳格な検証やサニタイズを行うようにシステムを見直すことが重要です。
4. LLMが生成したコードをサーバー上で実行する際は、必ず完全に隔離されたサンドボックス環境を利用し、ホストOSへのアクセスを厳しく制限する設計を検討してください。
flowise
<= 3.1.2→3.1.3flowise-components
<= 3.1.2→3.1.3CVE-2026-70476high
2026-08-04Flowise: Broken Access Control in Stripe Subscription Endpoints Allows Cross-Tenant Billing Manipulation
AIで3行以内に要約した超簡単な概要
FlowiseのStripe連携部分に、他社の課金情報を不正に操作できるアクセス制御の脆弱性が見つかりました。 認証済みの攻撃者が他社のサブスクリプションプラン変更やシート数操作を行えるため、金銭的な損害やサービス停止に直結する重大なリスクです。 早急な対応が求められます。
要約した概要
この脆弱性は、FlowiseのStripeサブスクリプション関連APIエンドポイント（例: `/update-subscription-plan`、`/update-additional-seats`）に起因します。これらのエンドポイントは、ユーザーから送られてくるStripeの`subscriptionId`を、それが現在ログインしているユーザーの組織に属するものかどうか検証せずに、Stripe連携層に直接渡してしまいます。
そのため、認証済みの攻撃者が他の組織の`subscriptionId`を知っている場合、自分のアカウントでログインした状態で、そのIDを指定してAPIを叩くことで、被害者組織のサブスクリプションプランを勝手に変更したり、有料シート数を操作したりすることが可能になります。これにより、意図しない課金（高額プランへのアップグレードや追加シートの購入）や、サービス利用の妨害（無料プランへのダウングレードやシート数の削減）が発生する可能性があります。
**影響を受ける条件:**
* Flowiseを使用しているシステムで、Stripeサブスクリプション機能を利用している場合。
* 認証済みの攻撃者が、被害者組織の`subscriptionId`を何らかの方法で入手できる場合（他のエンドポイントからの情報漏洩などが考えられます）。
**推奨される対応策:**
ユーザーから受け取った`subscriptionId`を使用する前に、それが**必ず現在認証されているユーザーの組織に紐づくものであるかをサーバーサイドで厳密に検証するロジックを追加**してください。具体的には、ログインユーザーの組織コンテキストから正しい`subscriptionId`を取得し、リクエストで送られてきたIDと一致するかを確認する処理を実装する必要があります。これにより、他のテナント（組織）の請求情報を不正に操作されるリスクを防ぐことができます。
flowise
<= 3.1.2→3.1.3CVE-2026-70474high
2026-08-04Flowise: Cross-Workspace OAuth2 Credential Metadata Leak
AIで3行以内に要約した超簡単な概要
Flowiseに深刻なOAuth2脆弱性があり、攻撃者が認証なしで他のワークスペースの認証情報（トークン）を盗んだり、書き換えたりする可能性があります。 これにより、連携している外部サービス（Google、Microsoftなど）へのアクセス権が完全に奪われ、データ漏洩や不正操作につながる非常に危険な問題です。 **緊急性の高い対応が必要です。**
要約した概要
### 脆弱性の概要と仕組み
FlowiseのOAuth2認証連携機能において、設定された認証情報（クレデンシャル）の取り扱いに脆弱性が発見されました。これにより、本来アクセスを制限されるべき認証情報が、不正にアクセス・操作される可能性があります。
根本原因は主に以下の2点です。
1. **ワークスペース分離の不備**: OAuth2クレデンシャルをデータベースから検索する際、それがどの「ワークスペース」（Flowiseにおけるチームやプロジェクトの単位）に属するかを確認していませんでした。このため、Flowiseにログインしたユーザーであれば、自分のワークスペースではない他のワークスペースに設定されたクレデンシャルにもアクセスできてしまう状態でした。
2. **認証スキップの誤設定**: OAuth2の「コールバック」と「リフレッシュ」という重要な処理を行うAPIエンドポイントが、Flowiseの認証メカニズム（ユーザーログインやAPIキーチェックなど）をスキップする「ホワイトリスト」に誤って含まれていました。これにより、これらのエンドポイントには認証なしで誰でもアクセスできる状態でした。
### 具体的な影響と攻撃シナリオ
上記の原因により、攻撃者は以下のような深刻な行為を実行できます。
* **他のワークスペースの認証情報設定の漏洩（要ログイン）**:
* Flowiseにログイン済みの攻撃者は、他のワークスペースに設定されたOAuth2クレデンシャルのID（UUID）を知っていれば、そのクレデンシャルの詳細な設定情報（`client_id`, `scope`, `redirect_uri`など）を盗み見ることができます。これは、攻撃者が自分のワークスペースから、他のワークスペースの認証プロセスを偽装することで、不正な認証URLを生成させることで可能になります。
* **認証なしでのトークン書き換え（認証不要）**:
* **最も危険なシナリオの一つです。** 認証されていない攻撃者が、特定のOAuth2クレデンシャルのIDを知っていれば、そのクレデンシャルに保存されているアクセストークンやリフレッシュトークンを、攻撃者が用意した不正な値に書き換えることができます。
* 攻撃者は、自身が管理する不正なOAuth2プロバイダー（認証サーバー）を悪用するか、正規のOAuth2フローを中間で乗っ取る（MitM）ことで、任意のトークンをFlowiseに注入し、被害者のクレデンシャルを完全に乗っ取ることが可能になります。
* **認証なしでのトークン窃取と悪用（認証不要）**:
* これも**非常に危険なシナリオです。** 認証されていない攻撃者が、特定のOAuth2クレデンシャルのIDを知っていれば、そのクレデンシャルに保存されている「リフレッシュトークン」（期限切れのアクセストークンを更新するための鍵）を使って、新しい「アクセストークン」を生成し、それを直接盗み取ることができます。
* 盗まれたアクセストークンは、Flowiseが連携していたMicrosoft 365、Google Workspace、Slackなどの外部サービスに不正にアクセスするために使用され、機密データの窃盗、不正なコンテンツの作成、アカウントの乗っ取りなど、広範囲な被害を引き起こす可能性があります。
### 影響を受ける条件
* Flowiseインスタンスが稼働しており、OAuth2クレデンシャルが設定されている場合、影響を受けます。
* 攻撃者が対象となるOAuth2クレデンシャルのUUID（ユニークな識別子）を知っている必要があります。このUUIDは、他の情報漏洩（ログ露出など）や、不適切なアクセス制御（IDORなど）、または総当たり攻撃によって取得される可能性があります。
### 推奨される対応策
この脆弱性は、外部サービス連携におけるセキュリティの根幹を揺るがすものであるため、以下の対策を**最優先で実行してください。**
1. **Flowiseの最新バージョンへのアップデート**: 最も重要です。開発元が提供するセキュリティパッチを適用するため、Flowiseを直ちに最新バージョンに更新してください。
2. **ワークスペースIDによる認証情報フィルタリングの徹底**: OAuth2クレデンシャルをデータベースから取得するすべての箇所で、現在ログインしているユーザーの`workspaceId`と一致するかどうかを確認する処理を追加する必要があります。
3. **認証なしエンドポイントからの削除**: OAuth2の「コールバック」エンドポイント（`/api/v1/oauth2-credential/callback`）と「リフレッシュ」エンドポイント（`/api/v1/oauth2-credential/refresh`）を、認証をスキップするホワイトリストから削除し、適切な認証（例: セッション認証）を必須とするように修正してください。
4. **アクセストークンの返却停止**: `/refresh`エンドポイントが、レスポンスボディに生成された新しい`access_token`を直接返さないように変更してください。アクセストークンはサーバー側で暗号化して保存するのみとし、クライアント側には一切返却すべきではありません。
5. **状態管理の強化**: OAuth2フローで使用される`state`パラメーター（コールバック時に正規のリクエストであることを確認するための値）を、より安全な暗号学的にランダムな値に変更し、ユーザーセッションと厳密に紐付け、一度しか使用できないようにするなどの対策を導入してください。
flowise
<= 3.1.2→3.1.3Advertisement
CVE-2026-69264critical
2026-08-04Flowise: RCE via CSVAgent csvFile data URI base64 segment is interpolated into Python source without validation
AIで3行以内に要約した超簡単な概要
FlowiseのCSV処理機能に深刻な脆弱性があり、悪意のあるCSVデータを送ることで、サーバー上で任意のコードを実行されてしまう可能性があります。 これにより、サーバーの乗っ取りやデータ流出の危険があり、緊急性の高い対応が必要です。 認証済みのユーザーが細工したチャットフローを一度仕込むと、誰でも認証なしで攻撃をトリガーできます。
要約した概要
### どんな問題か？
FlowiseのCSVAgent（CSVファイルを処理する機能）には、サーバー上で任意のコードが実行されてしまう（RCE: Remote Code Execution）非常に危険な脆弱性があります。これは、攻撃者が巧妙に細工したCSVデータを送ることで、Flowiseが動作しているサーバーのシステムを完全に制御できてしまう可能性があることを意味します。
### なぜ問題が起きるのか？
この脆弱性は、Flowiseがユーザーから提供されるCSVデータ（実際にはbase64エンコードされたデータURIの一部）を、検証が不十分なままPythonのソースコードテンプレートに直接埋め込んでしまうことに起因します。さらに、Flowise内でPythonコードを実行するために使用されているPyodideというライブラリが、Node.js環境においてデフォルトで`globalThis`（`eval`関数や動的な`import()`機能を含む）にアクセスできる設定になっていました。このため、攻撃者は注入したPythonコードからNode.jsの`eval`関数を呼び出し、Node.jsのファイルシステム操作 (`fs`) やOSコマンド実行 (`child_process`) モジュールを動的にインポートすることで、Pyodideが提供する隔離環境（サンドボックス）を突破し、Flowiseが稼働しているホストサーバー上で任意のコードを実行できてしまいます。既存のセキュリティ検証機能は、この脆弱なコードパスには適用されていませんでした。
### 攻撃はどのようにして行われるのか？
1. まず、`chatflows:create`またはそれと同等のチャットフロー更新権限を持つユーザー（Flowiseの管理者など）が、悪意のあるCSV Agentノードを含むチャットフローを作成または更新します。このノードの`csvFile`フィールドに、特別に細工されたデータURIを含めます。
2. この細工されたチャットフローが、認証なしでアクセス可能な`POST /api/v1/prediction/:id`エンドポイント（Flowiseのホワイトリストに登録されている公開API）で公開されている場合、**認証されていないあらゆるリクエスト**によってホストサーバーでのコード実行がトリガーされます。
つまり、一度悪用されたチャットフローが仕込まれてしまうと、誰でも簡単にサーバーを乗っ取ることが可能になります。
### 攻撃されるとどうなるか？
Flowiseが動作しているサーバー上で、攻撃者が好きなOSコマンドを自由に実行できるようになります。これにより、Flowiseの暗号化された認証情報ファイル、データベース全体、ホストサーバーのファイルシステム、さらにはホストがアクセス可能なネットワークリソースへの直接アクセスが可能になり、サーバーの完全な乗っ取りや大規模なデータ漏洩につながる可能性があります。この脆弱性はCVSSスコア9.9（最も高い「Critical」レベル）と評価されており、非常に危険です。
### 対策はどうすればよいか？
**Flowise開発者の方へ（根本的な修正策）：**
1. **文字列補間を排除する:** `base64String`の値をPythonソースコードに直接埋め込むのではなく、Pyodideの安全なAPIである`globals.set`を使ってPythonの変数として渡すように変更してください。これにより、攻撃者が文字列リテラルを閉じて任意のコードを注入することを防げます。同様のパターンを持つ他のコンポーネント（例: `AirtableAgent.ts`）にもこの変更を適用してください。
2. **Pyodideの`js`モジュールを無効化する:** Pyodideをロードする際に、`loadPyodide({ jsglobals: {} })`オプションを使用するか、`js`モジュールを削除する設定を行い、Node.jsの`globalThis`へのアクセスを阻止してください。
3. **入力値の厳密な検証:** `base64String`がPythonソースコードに補間される前に、`^[A-Za-z0-9+/=]*$`のような正規表現で、想定されるbase64形式であるかを厳密に検証してください。
4. **Pythonコードの検証強化:** `validatePythonCodeForDataFrame`などのPythonコード検証機能を、LLM（大規模言語モデル）が出力するコードだけでなく、内部のブートストラップテンプレートにも適用してください。また、`validateCustomReadCSVFunction`に対して、安全なpandasの読み込み関数（例: `read_csv`）のみを許可するホワイトリスト方式を導入し、`read_pickle`などの危険な関数を禁止してください。
**Flowise利用者の方へ（パッチがリリースされるまでの一時的な軽減策）：**
1. **APIキー認証の強制:** CSVAgentを使用するすべてのチャットフローで`chatflow.apikeyid`を設定し、`POST /api/v1/prediction/:id`エンドポイントに認証を強制してください。これにより、認証なしでの攻撃を防げます。
2. **権限の厳格化:** `chatflows:create`や`agentflows:create`などのチャットフロー作成・更新権限を、信頼できるユーザーのみに厳しく制限してください。
3. **`csvFile`のオーバーライド制限:** 可能な場合は、影響を受けるチャットフローにおいて、API経由で`csvFile`フィールドが外部から上書きできないように`nodeOverrides`の許可リストから除外してください。
flowise
<= 3.1.2→3.1.3flowise-components
<= 3.1.2→3.1.3GHSA-88pr-878c-24wfhigh
2026-08-04Flowise: Authenticated arbitrary file write in the `S3 Directory` document loader via unsanitized S3 object keys
AIで3行以内に要約した超簡単な概要
FlowiseのS3関連機能に脆弱性があり、認証済みの攻撃者がサーバー上に任意のファイルを書き込める可能性があります。 これにより、設定の改ざんや機密情報の漏洩、最悪の場合はサーバーが乗っ取られる恐れがあります。 セキュリティ上のリスクが高いため、早急な対応が求められます。
要約した概要
### 脆弱性の概要
FlowiseのS3ドキュメントを読み込む機能（`S3 Directory`および一部の`S3File`ローダー）に、認証済みユーザーが任意のファイルをサーバー上に書き込める脆弱性が発見されました。この問題は、S3オブジェクトのキー（ファイル名やパス）を処理する際に、`../`のようなディレクトリトラバーサルを示す特殊な文字列が適切に検証されずに利用されることが原因です。結果として、Flowiseサーバーは本来意図しない場所（例えば、システムの設定ファイルや他のアプリケーションの重要なファイルなど）に、攻撃者が指定した内容のファイルを保存してしまいます。
### 脆弱性の仕組みと影響
Flowiseは、一時ディレクトリ内にS3のファイルをダウンロードしますが、この際、S3オブジェクトキーと一時ディレクトリのパスを単純に結合しています。攻撃者はS3オブジェクトキーに`../../`のようなパス操作文字列を含めることで、一時ディレクトリの範囲を『抜け出し』、ファイルシステム上の任意の場所にファイルを書き込むことが可能になります。ダウンロード処理後に一時ディレクトリがクリーンアップされても、抜け出した場所に書き込まれたファイルはシステム上に残存します。これにより、Flowiseサーバープロセスがファイルシステムに対して持っている権限で、アプリケーションのデータ、秘密情報、設定ファイルなどを上書き・改ざんされる危険性があります。場合によっては、サーバーの起動スクリプトや実行ファイルを変更され、結果的にリモートからサーバーを完全に制御される（リモートコード実行、RCE）可能性もありますが、これはサーバーの環境設定に依存します。
### 影響を受ける条件
この脆弱性を悪用するには、以下の条件が必要です。
* FlowiseがHTTPサーバーモードで稼働していること。
* 攻撃者が`documentStores:preview-process`権限を持つアカウントで認証済みであること。
* 攻撃者は、自身が管理するS3互換のストレージ（例: MinIOなど）をFlowiseに指定できる必要があります。既存のAWSバケットへのアクセスは不要です。
### 推奨される対応策
根本的な原因は、S3オブジェクトキーが安全なローカル相対パスとして信頼されていることです。以下の対応が推奨されます。
1. **パスの検証と正規化:** S3オブジェクトキーをファイルパスとして利用する前に、`path.resolve()`などを用いてパスを正規化し、そのパスが意図した一時ディレクトリの範囲内に収まっていることを厳密に検証してください。一時ディレクトリ外へのパス指定は拒否すべきです。
2. **既存バリデーターの利用:** Flowiseには既にパスのトラバーサルチェックやファイル名のサニタイズを行うためのバリデーター機能（`packages/components/src/validator.ts`に定義）が存在します。これらの既存の機能を活用し、入力されるパスが安全であることを確認するロジックを導入してください。
3. **S3Fileローダーへの適用:** 同様の脆弱性が`S3File`ローダーの一部（`fileProcessingMethod = unstructured`の場合）にも存在するため、同様の修正を適用してください。
flowise-components
<= 3.1.2→3.1.3flowise
<= 3.1.2→3.1.3CVE-2026-70471high
2026-08-04Flowise: RBAC Bypass Leading to Unauthorized Workspace Variables Disclosure
AIで3行以内に要約した超簡単な概要
Flowiseで、権限のないユーザーが本来アクセスできないはずのワークスペース内の機密情報（パスワード、APIキーなど）を不正に取得できる脆弱性が見つかりました。 これを悪用されると、システム全体に深刻な情報漏洩やセキュリティ侵害が発生する可能性があります。 速やかにアップデートを適用するか、推奨される設定変更を行い、情報漏洩リスクを最小限に抑えてください。
要約した概要
### 脆弱性の具体的な仕組み
この脆弱性は、Flowiseの特定の機能、特にカスタムJavaScriptコードを実行するサンドボックス内で発生します。通常、ワークスペースの変数にアクセスするには「variables:view」という権限が必要ですが、内部処理で`$vars`という変数をサンドボックスに注入する際に、この権限チェックがスキップされていました。
これにより、たとえ「variables:view」権限を持たないユーザーやAPIキーであっても、`api/v1/node-custom-function`のようなAPIを呼び出すことで、ワークスペースに設定されている全ての変数にアクセスできてしまいます。これらの変数には、静的に設定された値だけでなく、サーバーの環境変数（例：`process.env`）から読み込まれるランタイム変数（データベースパスワード、JWTシークレット、APIキー、SMTPパスワードなど）も含まれており、これらが外部に漏洩するリスクがあります。
### 影響を受ける条件とリスク
権限のないユーザーが、上記の仕組みを利用してカスタムJSコンテキスト内で`$vars`の内容を読み出すことで、設定されている機密情報（データベースの認証情報、外部サービスのAPIキー、シークレットトークンなど）を不正に取得できてしまいます。これらの情報は、Flowiseが連携する外部システムへの不正アクセスや、アプリケーション全体の乗っ取りなど、極めて深刻なセキュリティインシデントに繋がりかねません。
### 推奨される対応策
1. **権限チェックの厳格化:** `$vars`をカスタムJSサンドボックスに注入する前に、呼び出し元が「variables:view」権限を持っているか、厳格にチェックするように修正することが最も重要です。
2. **変数インジェクションの制限:** あるいは、カスタムJS機能の実行に本当に必要な変数のみを明示的に許可リストとして指定し、それらだけを注入するように変更することも検討してください。
3. **ランタイム変数の見直し:** 自己ホスト環境でFlowiseを運用している場合、`type=runtime`の変数の使用を無効にするか、あるいはどの環境変数をマッピングできるかを厳しく制限することを推奨します。これにより、OSの環境変数に設定された機密情報が意図せず露出するリスクを低減できます。
4. **Flowiseのアップデート:** 本脆弱性に対応するFlowiseの公式アップデートがリリースされている場合は、速やかに最新バージョンへの更新を適用してください。公式のアナウンスを常に確認し、指示に従って対応することが重要です。
flowise
<= 3.1.2→3.1.3CVE-2026-70470critical
2026-08-04Flowise: Pyodide validator Unicode homoglyph bypass leads to RCE
AIで3行以内に要約した超簡単な概要
Flowiseに深刻な脆弱性があり、特殊なUnicode文字を利用してセキュリティチェックをすり抜け、Flowiseサーバー上で任意のコードを実行できてしまいます。これにより、サーバーの乗っ取りや機密情報の漏洩につながる可能性があり、直ちに対応が必要です。
要約した概要
Flowiseの「CSV Agent」や「Airtable Agent」でPythonコードを実行する機能に、セキュリティ上の欠陥（リモートコード実行、RCE）が見つかりました。この脆弱性は、以前に修正された同種の問題を実質的に再発させるものです。
**脆弱性の仕組み:**
1. **セキュリティチェックの盲点**: Flowiseは、危険なPythonコードの実行を防ぐため、`import`や`__class__`といった特定のキーワードを正規表現でチェックしています。しかし、JavaScriptの正規表現における「単語の区切り（`\b`）」はASCII文字（一般的な英数字）しか認識しないという特性があります。
2. **Unicode文字によるすり抜け**: 攻撃者は、見た目は似ていますが内部的には異なるUnicode文字（例: 通常の`a`ではなく数学的太字の`𝐚`）を悪意のあるコードに含めることができます。
3. **Pythonの解釈**: Pythonは、このようなUnicode文字を内部的に通常のASCII文字として扱います（正規化処理）。
4. **結果**: 上記の組み合わせにより、`__cl𝐚ss__`のようなホモグリフ（見た目が似た文字）を使った悪意のあるコードがセキュリティチェックをすり抜けてしまいます。その後、Pyodide（ブラウザ内でPythonを実行する技術）の機能を使って、Flowiseが動作しているNode.jsサーバー上でOSのコマンドを自由に実行できるようになります。
**影響を受ける条件:**
Flowiseの「CSV Agent」または「Airtable Agent」を含むチャットフローを使用している場合、この脆弱性の影響を受けます。攻撃者は以下のいずれかの方法で悪用できます。
* **チャット経由での悪用**: 公開されているチャットフローの場合、認証されていないユーザーでも、チャットメッセージを通じてLLM（大規模言語モデル）に悪意のあるPythonコードを生成させ、サーバー上で任意のコードを実行できます。
* **直接設定による悪用**: チャットフローの編集権限を持つワークスペースユーザーであれば、`customReadCSV`などの設定項目に直接悪意のあるコードを埋め込むことで、攻撃を実行できます。
**もたらされるリスクと緊急度:**
この脆弱性が悪用されると、Flowiseが動作しているサーバー上で、Flowiseプロセスと同じ権限でOSのコマンドが実行されてしまいます。これにより、サーバー内の機密情報（認証情報やファイルなど）の読み書き、内部ネットワークへの侵入、サーバー全体の乗っ取りといった深刻な被害につながる可能性があります。以前に修正された同種の脆弱性と同じ極めて高いリスク（重大度9.8）があり、Flowiseを利用しているすべてのユーザーは早急な対応が求められます。
**推奨される対策:**
Flowiseを最新の修正済みバージョンにアップデートすることが強く推奨されます。
flowise
<= 3.1.2→3.1.3flowise-components
<= 3.1.2→3.1.3CVE-2026-69263high
2026-08-04Flowise: CVE-2025-8943 Patch Bypass: npm_config_yes bypasses MCP environment variable blocklist (Unauthenticated RCE)
AIで3行以内に要約した超簡単な概要
Flowiseのセキュリティパッチに抜け穴があり、認証なしでサーバーを乗っ取れる脆弱性（RCE）が確認されました。 特定の環境変数を悪用することで、本来ブロックされるはずの危険な挙動が実行されてしまいます。 サービス停止や情報漏洩に繋がるため、**至急**対応が必要です。
要約した概要
### 脆弱性の概要
Flowiseで以前発見された脆弱性CVE-2025-8943に対するセキュリティパッチに、回避策が見つかりました。このパッチは、`npx`コマンドの`-y`や`--yes`といった危険なオプション（ユーザーの確認なしに任意のパッケージが自動インストール・実行されてしまう）をブロックすることを目的としていました。これらのコマンドラインオプション自体は効果的にブロックされています。
しかし、パッチの一部である環境変数チェックに大きな抜け穴がありました。このチェックは、`PATH`などのごく限られた4つの環境変数名だけをブロックしており、それ以外の環境変数は素通りさせていました。`npm`は、`npm_config_`というプレフィックスを持つ環境変数から設定を読み込む仕組みを持っています。攻撃者が`npm_config_yes=true`という環境変数を設定すると、`npx`は`-y`や`--yes`オプションが指定された場合と同じように、自動でパッケージをインストールし、実行してしまいます。これにより、本来パッチが防ごうとしていた危険な挙動が完全に回避されてしまいます。
この脆弱性は、Flowiseのセキュリティ機能である`CUSTOM_MCP_SECURITY_CHECK=true`が有効になっている環境でも機能します。特にFlowiseのデフォルト設定では認証機能が有効になっていない場合が多く、その環境では**認証されていない攻撃者でも、FlowiseのAPIにアクセスできるだけで、サーバー上で任意のコードを遠隔で実行できてしまいます（Unauthenticated RCE）**。
### 脆弱性の根本原因
元のパッチは、この問題をコマンドラインオプションのフィルタリングとして捉えていました。しかし、`--yes`オプションで制御される挙動は、`npm`の環境変数ベースの設定を介しても実現可能です。これは、`node`や`python3`などの他のインタープリタでも同様の問題を引き起こす可能性があります。危険な変数をブロックリストで列挙する方式では、すべての潜在的な危険な環境変数を網羅することは不可能であり、根本的な対策とはなりません。
### 影響を受けるバージョン
* Flowise 3.1.1（2026年3月29日時点の最新版）
### 攻撃の詳細
`packages/components/nodes/tools/MCP/core.ts`内の`validateEnvironmentVariables`関数が問題の箇所です。この関数内の`dangerousEnvVars`配列には、わずか4つの環境変数しか含まれていません。`npm_config_yes`はこのリストに含まれていないため、チェックをすり抜けてしまいます。
攻撃者は、以下のようなMCPサーバー設定を悪用することで、パッチを回避できます。
```json
{
"mcpServers": {
"bypass": {
"command": "npx",
"args": ["malicious-package"],
"env": {
"npm_config_yes": "true"
}
}
}
}
```
この設定では、コマンドラインフラグも環境変数もチェックをすり抜け、`npx`は指定された悪意のあるパッケージを自動でインストールし、Flowiseプロセスの権限で実行してしまいます。
**追加のバイパス経路**
同様の根本原因により、以下の環境変数もブロックリストになく、他のインタープリタを通じて悪用される可能性があります。
* `npm_config_prefix`: `npx`でパッケージインストール先を攻撃者が制御するパスにリダイレクト。
* `npm_config_userconfig`: `npx`で攻撃者が制御する`.npmrc`設定ファイルをロード。
* `NODE_PATH`: `node`でモジュールロードパスを攻撃者が制御するパスに設定。
* `PYTHONPATH`: `python3`でモジュールロードパスを攻撃者が制御するパスに設定。
### もたらされる影響
Flowiseプロセスと同じ権限で、サーバー上で完全にリモートコードが実行されます。デフォルトで認証が設定されていない環境では、攻撃者は何の認証情報も不要で、Flowiseサーバーを乗っ取ることができます。これは、データ漏洩、サービス停止、サーバーの改ざんなど、非常に深刻な結果を招きます。
### 推奨される対策
最も根本的な対策は、Flowiseが子プロセスに環境変数を渡す際に、以下のいずれかの方法を取ることです。
1. **環境変数を完全に除去する。**
2. **ホワイトリスト方式を採用する。** すなわち、**明示的に許可された変数のみ**を子プロセスに渡すように変更する。
既存の危険な環境変数（`npm_config_yes`、`npm_config_prefix`、`NODE_PATH`、`PYTHONPATH`など）を現在のブロックリストに追加することは、目先の穴を塞ぐ一時的な措置に過ぎません。将来的に新しいインタープリタが追加されたり、新たな環境変数による制御が見つかったりすると、再度同様のバイパス手法が生まれる可能性があります。根本的な解決策としては、ホワイトリスト方式への移行を強く推奨します。
flowise
<= 3.1.2→3.1.3flowise-components
<= 3.1.2→3.1.3Advertisement
1 / 71