JieGou has evolved.
Since this post was published, JieGou has pivoted from an AI automation platform to an AI-powered operations company delivering managed marketing and operations services. Learn about our managed services →
期限が迫っています
明日、2026年3月25日は、CISAが全連邦文民行政機関（FCEB）に対して、n8nの積極的に悪用されている脆弱性の修正または緩和を義務付けた期限です。n8nは広く普及しているオープンソースのワークフロー自動化プラットフォームです。政府機関、規制産業、企業を問わず、この期限はあなたの組織にも関係があります。
何が起きたのか、何がリスクなのか、そしてどのような選択肢があるのかをご説明します。
脆弱性のタイムライン
2026年2月、セキュリティ研究者がn8nの一連の重大な脆弱性を公開し、状況は懸念レベルから壊滅的なレベルへと急速にエスカレートしました：
- 2月初旬：n8nが25億ドルの評価額で1.8億ドルを調達し、主要なオープンソース自動化プラットフォームとしての地位を確立。
- 2月中旬：CVE-2025-68613がCISA既知の悪用された脆弱性（KEV）カタログに追加 — 実環境での積極的な悪用が確認。
- 2月下旬：研究者が「Ni8mare」（CVE-2026-21858）を公開。CVSS 10.0の未認証リモートコード実行脆弱性で、webhookのContent-Type混同を悪用。ログイン不要。
- 3月初旬：さらに2つのRCEベクター（CVE-2026-27577、CVE-2026-27493）が浮上し、重大なCVEの合計は6件以上、独立したRCEパスは4本に。
- 3月4日：CISA、シンガポールCSA、カナダCCCSがそれぞれ正式な勧告を発行。
- 3月11日：CISAがFCEB修復期限を3月25日に設定。
これは理論上のリスクではありません。CISAは積極的な悪用が確認された場合にのみ、脆弱性をKEVカタログに追加します。
4つの独立したRCEベクター
この状況の深刻さは異例です。ほとんどの脆弱性の公開は単一の問題に関するものです。n8nには4つの独立したリモートコード実行パスがあります：
| CVE | CVSS | タイプ | 説明 |
|---|---|---|---|
| CVE-2025-68613 | — | RCE | 積極的に悪用中；CISA KEVに追加 |
| CVE-2026-21858 (Ni8mare) | 10.0 | 未認証RCE | Webhook Content-Type混同 — 認証情報不要 |
| CVE-2026-27577 | 9.4 | 認証後RCE | 認証済みリモートコード実行 |
| CVE-2026-27493 | — | ゼロクリックRCE | 完全なサーバー乗っ取り、ユーザー操作不要 |
それぞれが単独でn8nインスタンスを侵害するのに十分です。合わせると、セキュリティ境界の完全な崩壊を表しています。
パッチだけでは不十分な理由
n8n v1.xを実行している場合、パッチの適用は実行可能な修復パスではありません。その理由は以下の通りです：
n8n v1.xはサポート終了に達しました。 n8nチームはv1.xがセキュリティアップデートを受け取らなくなることを発表しました。組織はv2.0に移行する必要があります — これは単純なパッチではなく、メジャーバージョンアップグレードです。スキーマの変更、APIの破壊的変更、ワークフローの互換性テストが必要になります。
認証情報の侵害は全面的です。 これらの脆弱性のいくつかにより、攻撃者はn8nの暗号化キーを抽出できます。つまり、保存されているすべての認証情報 — APIキー、OAuthトークン、データベースパスワード — は侵害されたと想定する必要があります。ソフトウェアにパッチを当てても、すでに流出した認証情報の侵害を取り消すことはできません。n8nに保存されているすべてのシークレットをローテーションする必要があります。
攻撃対象面は構造的です。 Censysはインターネットに露出した24,700のn8nインスタンスを特定しました。その多くはWAF、ネットワークセグメンテーション、侵入検知のない自己ホスト型デプロイメントです。保存された認証情報とコード実行機能を持つ自己ホスト型自動化サーバーというアーキテクチャパターンは、n8nを高価値ターゲットにしています — これはバージョンアップでは変わりません。
対応方法
状況に応じて、3つの現実的なパスがあります：
1. n8n v2.0にアップグレード
n8nの使用を継続する場合は、直ちにv2.0にアップグレードしてください。これは任意ではありません — v1.xはEOLであり、これ以上のパッチは提供されません。アップグレード後：
- n8nに保存されているすべての認証情報（APIキー、OAuthトークン、データベースパスワード）をローテーション。
- webhookエンドポイントの不正アクセスを監査。
- 実行ログで侵害の兆候を確認。
- n8nをWAFの背後に配置し、ネットワークアクセスを制限。
チームがメジャーバージョン移行の能力を持ち、強力なインフラストラクチャセキュリティプラクティスがある場合、これが正しいパスです。
2. マネージドプラットフォームに移行
n8nの脆弱性クラスターは、自己ホスト型自動化プラットフォームの構造的リスクを浮き彫りにしています：すべての依存関係、すべての露出エンドポイント、すべての保存された認証情報のセキュリティ負担を引き受けることになります。マネージドSaaSプラットフォームはその負担をベンダーに移転します。
JieGouはまさにこのために構築されています。以下を提供します：
- CVEゼロ、npm audit脆弱性ゼロ。 依存関係チェーンはクリーンで、継続的に監視しています。
- SOC 2 Type II監査進行中、3月20日にAdvantage Partnersと開始。ペネトレーションテストは完了済み。
- パッチが必要な自己ホストインフラなし。 マネージドプラットフォームとして、セキュリティアップデートは私たちが透過的に適用します。
- n8n移行ツール、45以上のノードタイプマッピングでn8nワークフローをJieGouレシピとワークフローに変換。
- 10層ガバナンススタック、承認ゲート、監査ログ、RBAC、データ分類、コンプライアンスコントロールを網羅。
オンプレミスデプロイメントが必要な組織向けに、自己ホストスターターキット（Docker Compose + Ollama + Redis）も提供しており、強化されたリファレンスアーキテクチャに従いながらインフラストラクチャを自社管理下に置けます。
3. 代替案を評価
自動化スタックを再検討しているなら、今が適切なタイミングです。現在最も重要な基準：
- マネージド vs. 自己ホスト：パッチ適用の責任は誰にありますか？
- 認証情報の分離：シークレットはどのように保存・暗号化されていますか？
- 監査証跡：何がいつ起きたかを証明できますか？
- コンプライアンス対応：SOC 2、GDPR、業界固有の要件。
n8nへの公正な評価
n8nは真に有用な製品を構築しました。ビジュアルワークフロービルダー、ノードエコシステム、オープンソースコミュニティは真の強みです。n8nチームは修正に取り組んでおり、v2.0へのアップグレードパスについて透明性を保っています。
しかし、脆弱性に関する透明性は、パッチ未適用のソフトウェアを実行するリスクを低減しません。CISA KEVリストへの掲載は、これが仮定の話ではないことを意味します — これらの脆弱性は今、実際のターゲットに対して悪用されています。
まとめ
3月25日は明日です。n8nを実行している場合：
- バージョンを確認してください。 v1.xを使用している場合、既知の、積極的に悪用されているRCE脆弱性を持つサポート終了ソフトウェアを実行しています。
- 直ちに認証情報をローテーションしてください。パッチを当てるか移行するかに関係なく。
- 決断してください：v2.0にアップグレードするか、マネージドプラットフォームに移行するか、リスクを書面で受け入れるか。
移行を検討したい場合は、チームにお問い合わせいただくか、n8n移行ガイドでワークフローがJieGouにどのようにマッピングされるかをご確認ください。
JieGouは、12のメッセージングチャネル、10層ガバナンス、エンタープライズコンプライアンスを備えた部門ファーストのAIワークフロー自動化プラットフォームです。詳しくはjiegou.aiをご覧ください。