Flowise の文書ストアAPIに未認証で任意ファイルを書き込める欠陥（CVSS 9.8・再起動でRCE）

Critical（CVSS 9.8）に分類されるFlowiseAI Flowise 3.1.3 以前の脆弱性です。LLM アプリを画面上で組み立てるオープンソースツール Flowise の 3.1.3 以前に、未認証でファイルシステムへ任意のファイルを書き込める欠陥がある。/api/v1/document-store/loader/process エンドポイントが fileName パラメータを検証せずに扱うため、../ を含む値を送るとサーバー上の任意のパスへ書き込める。package.json のような起動時に読まれるファイルを上書きしておけば、アプリケーションが再起動した時点で任意コードが実行される。CVSS 3.1 基本値は 9.8（AV:N/AC:L/PR:N/UI:N/C:H/I:H/A:H）で、認証も利用者の操作も要らない。 同時期に公表された CVE-2025-71333（Flowise 2.2.4 以前・CVSS 9.8）も同じ性質の欠陥で、storageType が local のときに /api/v1/attachments の chatId・chatflowId でパストラバーサルが成立し、任意ディレクトリへファイルをアップロードできる。どちらも「認証が要らない」「ファイルを置ける」「置いた先が実行に使われる」という3点が揃っているため、到達できる状態で放置すると乗っ取りに直結する。 この種のツールは検証目的で立てたまま社内ネットワークやクラウド上に残りやすい。Flowise は既定で認証が有効になっていない構成でも動くため、「社内からしか見えないつもり」のインスタンスが実際には外部から到達できる、という形の事故が起きやすい位置にある。

まず自組織に Flowise が動いていないかを洗い出す。開発者が個人で立てた検証用インスタンスが対象になりやすいので、コンテナイメージ名（flowiseai/flowise）や既定ポート 3000 での稼働を横断的に確認する。 見つかったら 3.1.3 より後のバージョンへ更新する。更新できるまでの間は、インターネットからの到達を遮断するのが最優先である。ALB/WAF・Cloud Armor・Application Gateway・セキュリティグループのいずれでもよいので、/api/v1/document-store/ と /api/v1/attachments への外部到達を落とす。認証（FLOWISE_USERNAME / FLOWISE_PASSWORD）を有効にしていても、この欠陥は未認証で成立するため認証だけでは防げない。 既に到達可能な状態で運用していた場合は、侵害前提で確認する。アプリケーションのディレクトリで package.json・起動スクリプト・node_modules 配下の更新時刻が想定外に新しくなっていないか、プロセスが不審な外部通信をしていないかを見る。書き込まれたファイルは再起動まで発火しないため、「まだ何も起きていない」ことは安全の証拠にならない。疑わしければコンテナを作り直し、永続ボリュームの中身も確認する。 あわせて、この手の LLM 基盤ツールを誰がどこに立てているかを把握する仕組みを作っておきたい。今回の欠陥は個別の実装ミスだが、検証用に立てたまま忘れられるという運用の穴のほうが再発しやすい。

FlowiseAI Flowise 3.1.3 以前 を利用している場合、稼働バージョンが影響範囲に含まれるかを一次情報（https://nvd.nist.gov/vuln/detail/CVE-2025-71338）で確認してください。AWS・GCP・Azure・Linux それぞれの対応状況は本ページの「クラウド／OS 別の対応状況」表にまとめています。確認できていない項目は「情報確認中」と明記しており、存在しないパッチ番号・バージョンは記載していません。