「侵害されたn8nインスタンスは、単に1つのシステムを失うことを意味するのではなく、攻撃者にあらゆるものの鍵を渡すことを意味する」と、セキュリティ研究者は深刻度10.0の脆弱性について記した。
研究者らは、多くの企業がLLM搭載エージェントや自動化ワークフローを構築するために利用しているプラットフォームn8nで、ひそかに修正されていた重大な脆弱性の詳細を公開した。この欠陥により、未認証の攻撃者がローカルのn8nデプロイメントを完全に掌握し、基盤となるシステム上でコマンドを実行し、ワークフローが通常アクセスできる機密性の高い企業データを抽出できる可能性がある。
この脆弱性を発見したデータセキュリティ企業Cyeraの研究者は、脆弱性に関する報告書で「侵害されたn8nの影響範囲は甚大だ」と指摘した。「n8nは、組織のGoogle Drive、OpenAIのAPIキー、Salesforceデータ、IAMシステム、決済処理業者、顧客データベース、CI/CDパイプラインなど、無数のシステムを接続している。これは自動化インフラの中枢神経系だ。」
n8nの開発者は11月18日にリリースされたバージョン1.121.0でこの問題を修正したが、当時のリリースノートにはセキュリティ修正について言及がなかった。これは、n8nのセキュリティアドバイザリが意図的に遅れて公開されるため、標準的な手順のようだ。プロジェクトはその後も、CVE-2025-68613、CVE-2025-68668、CVE-2026-21877など、他の重大なRCE脆弱性を修正しているため、ユーザーは常に最新の利用可能なバージョンへ更新していることを確認すべきだ。
Content-Typeの混乱が任意のファイル読み取りにつながる
CVE-2026-21858として追跡されているこの脆弱性は、深刻度10.0（クリティカル）と評価され、2段階の攻撃を可能にする。まず、n8nのWebフォームにアクセスできる未認証の攻撃者が、n8nサーバー内部のファイルを漏えいさせられる。これは、n8nのフォームノードがデータを受け取るために使用するformWebhook関数が、ユーザーが送信するPOSTリクエストのContent-Typeフィールドがmultipart/form-dataに設定されているかどうかを検証しないためだ。
たとえば非常に一般的なユースケースとして、n8nを使ってユーザーがシステムにファイルをアップロードできるチャットインターフェースを構築している場合を想像してほしい。例としては、エラーのスクリーンショットやログを受け付けるカスタマーサポートポータル、履歴書（CV）を提出するための人事システム、あるいは従業員が後でLLM搭載チャットボットで照会できるように文書をアップロードしてインデックス化するナレッジベースなどがある。
通常のフローでは、コンテンツタイプがmultipart/form-dataで、リクエストボディにfiles:の定義がある場合、n8nはparseFormData()関数でリクエストを解析する。この関数はNode.jsライブラリFormidableを使用し、ファイルをランダムなパスの一時ディレクトリに保存してから、ファイル名と場所でreq.body.filesグローバル変数を埋めることで、安全にファイルアップロードを処理する。
しかし、リクエストのコンテンツタイプが異なる場合、たとえばapplication/jsonの場合、n8nはparseBody()という別の関数でリクエストボディを解析し、挙動が異なる。この関数はリクエストのdataセクションを抽出してreq.body.dataグローバル変数を埋めるが、同時にリクエスト内の他のセクションも抽出し、それぞれの内容で対応するreq.body.[section name]変数を埋める。
formWebhookが、filesセクションを含むリクエストが実際にmultipart/form-dataであるかどうかを検証しないため、ボディに対して誤った解析関数を呼び出してしまい、req.body.files変数がファイル名やパスといったユーザー制御の値で埋められる結果となる。その後、req.body.files変数内のファイル（本来はランダムな一時パスであるはず）を永続的な保存場所へコピーし、他のノード／ワークフローで利用できるようにするcopyBinaryFile()という関数を呼び出す。これにより、正規のシステム上のファイルが上書きされたり、ワークフロー内の別の場所で読み込まれたりする可能性があるパストラバーサル攻撃につながり得る。
この脆弱性を悪用するには、攻撃者はapplication/jsonとして、ローカルシステム上の既知のファイルパス（機密の認証情報やトークンを含むn8n設定ファイルなど）を指定するfilesセクションを含むリクエストを送信できる。これらのファイルがLLM搭載チャットボットノードのコンテキストに追加されると、攻撃者はチャットインターフェースを使ってそれらのファイルについて質問し、内容を漏えいさせられる。
任意ファイル読み取りから管理者権限へ
この脆弱性によって可能になる攻撃の第2段階は、「影響範囲」を大きく広げる。というのも、任意のローカルファイルを読み取れる能力は、n8nが認証済みセッションを追跡する方法のために深刻な意味を持つからだ。
セッションCookieは、一定期間ユーザーの認証状態を維持するためにブラウザに保存される文字列である。攻撃者は、侵害されたシステムからセッションCookieを盗み、認証を回避して被害者としてさまざまなWebサイトにログインすることがよくある。
n8nでは、セッションCookieはユーザー固有IDと、ユーザーのメールアドレスおよびパスワードのSHA256ハッシュを組み合わせ、その結果を各n8nインストール固有の秘密鍵で署名して生成される。
問題は、セッションCookieを再構築するために必要な情報がすべてローカルファイルに存在することだ。固有の秘密鍵は/home/node/.n8n/configに保存され、すべてのユーザーレコードは/home/node/.n8n/database.sqliteファイルに保存される。これら2つのファイルの内容が漏えいすると、攻撃者は管理者を含む任意のユーザーのn8n-authCookieを再作成できる。
管理者権限があれば、攻撃者は新しいワークフローを作成できる。またn8nにはExecute Commandというノードがあり、名前が示すとおり、n8nサービスの権限で基盤となるオペレーティングシステム上のコマンドを実行する。
研究者らは報告書で「10,000人以上の従業員を抱える大企業で、誰もが使うn8nサーバーが1台ある状況を想像してほしい」と記した。「侵害されたn8nインスタンスは、単に1つのシステムを失うことを意味するのではなく、攻撃者にあらゆるものの鍵を渡すことを意味する。API認証情報、OAuthトークン、データベース接続、クラウドストレージ――すべてが1か所に集約されている。n8nは単一障害点となり、脅威アクターにとっての金鉱になる。」
