n8nの脆弱性12件、6件は1.x系に修正が出ていない

自社のサーバーでn8nを動かしているなら、2.x系の修正版へ上げる。2.45系なら2.45.5以降、2.46系なら2.46.1以降だ。n8nが10月28日にGitHubで公開した12件のセキュリティ勧告は、これらの版で全部直る。1.x系にも修正版は出た。ただし、直るのは12件のうち6件にとどまる。

n8nは、業務の手順をつないで自動で動かすワークフローのツールで、自社のサーバーにも置ける。10月14日にも10件の勧告が出ており、その中身は情シスの相棒の記事が詳しい。

「高」の3件は、どれもサーバーでコードが動く

12件のうち3件は、深刻度が「高」とされた¹。3件とも、n8nが動くサーバーの上で、意図しないコードが動きうるものだ。

まず、ワークフローの式を評価するときの隔離が足りなかった。ワークフローを作る・直す権限がある利用者なら、この隔離を抜けて、サーバーで任意のコードを動かせた。

次に、公式のDockerイメージに入っている画像処理ソフト、GraphicsMagickに既知の脆弱性があった。外から受け取った画像をEdit Imageノードで処理すると、任意のコードを動かされるおそれがある。認証の無いWebhookからEdit Imageへ画像を渡すワークフローは、とくに危ない。

この2件は、1.x系の修正版でも直った。一方、3件目は1.x系に修正が出ていない。古いコードノード（Function、Function Item、LangChain Code）を使うと、n8n本体のプロセスでコードを動かせる件だ。Codeノードは、タスクランナーという別の仕組みに分けて動かす。しかし、古い3つのノードはこの隔離の外で動く。

使っている系列	上げる先	直る件数
2.46系	2.46.1以降	12件
2.45系	2.45.5以降	12件
1.x系	1.123.89以降	6件

11月3日時点で、GitHubで「stable」の印が付いているのは2.45.7、「beta」は2.46.4だ。

1.x系に修正が出ていない6件

残りの6件は、影響する版の範囲に1.x系も含む。それでも、1.x系の修正版は示されていない。古いコードノードの件に加えて、次の5件がある。

• 認証情報を使うノードが、別のサイトへリダイレクトされたときも、認証のヘッダーを付けて送る（HTTP Requestノードの4.4版は除く）
• 利用者が自分の認証情報をつなぐ流れで、OAuthのアカウントを乗っ取られうる
• Browser Useのアップロード機能で、n8nのサーバーにある任意のファイルを読める
• Asana TriggerノードのWebhookで、認証の無い要求から検証用の秘密を作り直せる
• OracleDBのVector Storeノードで、SQLインジェクションが起きうる

そのため、1.x系のまま更新を続けても、12件はそろって直らない。

2.x系へ上げる前に見直すこと

1.x系から2.x系へ上げると、互換性が崩れる変更をまたぐ。n8nの手引きにある主な変更は、次のとおり。

1. Codeノードは、タスクランナーで動くのが既定になった。上げる前にN8N_RUNNERS_ENABLEDをtrueにすると、今のワークフローが動くかを試せる。
2. Codeノードから環境変数を読むのは、既定で止まる。秘密の値は、認証情報の機能へ移す。
3. コマンドを動かすExecute Commandと、ファイルの変化を見るLocal File Triggerは、既定で使えない。
4. データの保存先にMySQLとMariaDBは使えない。上げる前に、移行のツールでPostgreSQLかSQLiteへ移す。

Codeノードを多く使う会社ほど、試す手間がかかるだろう。また、上げる先の2.45.5と2.46.1では、古いコードノードが既定で止まっている。これらのノードを足したり直したりしたワークフローは、保存できない。すでに保存したワークフローは、そのまま動き続ける。勧告は、Codeノードへの置き換えを求めている。

N8N_DEPRECATED_NODES_BLOCKをfalseにすれば、止めずに済む。ただし、脆弱な動きに戻る。3.0ではこれらのノード自体がなくなる（3.0のベータ版のニュース）。

すぐに上げられないとき

勧告には、上げるまでのつなぎの対策もある。ただし、どれも危険をなくすものではない。

• n8nに入れる利用者を、信頼できる人に絞る。
• 使わないノードを、環境変数NODES_EXCLUDEで外す。Edit Imageはn8n-nodes-base.editImage、古いコードノードはn8n-nodes-base.functionなどの名前で指定する。
• n8nから外への通信を、決まった相手に絞る。N8N_SSRF_PROTECTION_ENABLEDをtrueにしても、危険を減らせる。
• 信頼できないリダイレクト先に渡ったおそれのある認証情報は、作り直す。

n8nの手引きは、少なくとも月に1回の更新を勧めている。何版もまとめて飛ぶより、壊れる変更に気づきやすいからだ。

注

1. GHSA-gx3v-3x3v-f8r5（式の評価の隔離）、GHSA-f2cw-9483-7vcp（GraphicsMagick）、GHSA-9p7v-45m2-wxgj（古いコードノード）。CVSS 4.0の値は7.7、7.7、8.7。11月3日時点で、CVEの番号は付いていない。 ↩