CVE-2026-21858：n8n「Ni8mare」漏洞——CVSS满分10.0的工作流自动化平台RCE

2026年1月7日，Cyera研究团队公开披露了CVE-2026-21858，一个CVSS 10.0的远程代码执行漏洞，影响所有n8n ≤1.0版本。攻击者无需任何认证，通过Content-Type混淆即可实现任意文件读取，进而伪造管理员JWT令牌、绕过沙箱，最终获得服务器的完全控制权。全球约10万台n8n实例面临风险。

漏洞概述：工作流自动化平台的噩梦

CVE-2026-21858被Cyera命名为「Ni8mare」（谐音Nightmare），是n8n平台有史以来最严重的安全漏洞。n8n是一个开源的工作流自动化平台，类似于Zapier和Make，但允许自托管部署。企业使用n8n连接各种服务、自动化业务流程——这意味着n8n服务器中存储着大量API密钥、OAuth令牌和数据库凭据。

字段	详情
CVE编号	CVE-2026-21858
代号	Ni8mare
CVSS评分	10.0（Critical，满分）
漏洞类型	Content-Type混淆 → 任意文件读取 → RCE
影响版本	n8n ≤1.0
认证要求	无需认证
修复版本	n8n 1.0+
影响范围	全球约10万台服务器
发现者	Dor Attias, Cyera Research Labs
PoC状态	公开可用（GitHub: Chocapikk/CVE-2026-21858）

技术原理：从Content-Type混淆到完全控制

n8n使用两个不同的函数处理基于Content-Type的请求：

• multipart/form-data：上传解析器，将文件保存到临时位置
• application/json：JSON解析器，处理结构化数据

漏洞的核心在于：文件复制函数在执行时不验证Content-Type是否为multipart/form-data。攻击者可以发送一个Content-Type为application/json的请求，但其中包含文件参数。由于缺乏验证，攻击者可以完全控制req.files对象，进而控制文件复制操作的filepath参数。

攻击链路分7个阶段：

阶段1: 发送application/json请求，包含文件参数
阶段2: 控制req.files对象
阶段3: 触发文件复制函数，控制filepath参数
阶段4: 实现任意文件读取（Primary Primitive）
阶段5: 读取n8n配置文件，提取存储的凭据
阶段6: 读取数据库文件，获取会话数据
阶段7: 伪造管理员JWT令牌 → 利用CVE-2025-68613表达式注入 → 绕过沙箱 → RCE

关键代码路径分析：

# 漏洞触发的简化逻辑
def handle_webhook(request):
    # 不验证Content-Type
    if request.files:
        # 直接使用用户控制的filepath
        copy_file(request.files['file'].filepath, dest_path)
        # 攻击者可以指定任意本地文件路径

攻击面分析：谁在裸奔

n8n的攻击面取决于部署方式。以下条件组合使风险最大化：

条件	风险影响
Form Webhook工作流已创建且激活	✅ 必要条件
Webhook端点公开可访问	✅ 必要条件
n8n版本 ≤1.0	✅ 必要条件
无反向代理认证	🔴 风险倍增
默认配置运行	🔴 风险倍增
存储了大量凭据	🔴 影响扩大

Cyera估计全球约10万台n8n服务器可能受影响。n8n的典型使用场景包括：

• 业务流程自动化：运营数据暴露风险
• 数据集成：多系统凭据泄露
• CI/CD编排：供应链攻击跳板
• 监控告警：安全可见性丧失
• API集成：第三方服务访问权泄露

PoC已公开：攻击门槛极低

2026年1月，GitHub用户Chocapikk公开发布了CVE-2026-21858的PoC利用代码（Chocapikk/CVE-2026-21858）。这意味着即使技术水平有限的攻击者也能轻松利用此漏洞。

因素	状态
PoC可用性	✅ 公开（GitHub）
武器化难度	低
自动化攻击潜力	高
大规模扫描可能性	高

安全团队应假设未打补丁的n8n实例已经被扫描和尝试利用。

n8n安全漏洞家族：2026年的连环打击

CVE-2026-21858并非n8n在2026年唯一的严重漏洞。JFrog安全团队后续又发现了两个沙箱逃逸漏洞：

CVE	类型	CVSS	认证要求	说明
CVE-2026-21858	Content-Type混淆→RCE	10.0	无需	Ni8mare
CVE-2026-1470	JS沙箱逃逸	9.9	需要	通过废弃的with语句绕过
CVE-2026-0863	Python沙箱逃逸	8.0	需要	Python执行环境绕过
CVE-2026-25049	补丁绕过→RCE	9.4	需要	绕过之前的修复
CVE-2026-33696	原型污染→RCE	9.4	需要	XML和GSuiteAdmin节点

五个CVE，CVSS均在8.0以上，这在单一开源项目中极为罕见。n8n作为工作流自动化平台，本质上是一个「特权跳板」——攻陷n8n等于攻陷它连接的所有系统。

检测与应急响应

检测是否已被利用

# 检查n8n版本
grep -r "version" /path/to/n8n/package.json

# 检查Webhook访问日志
grep -i "webhook" /var/log/n8n/*.log | grep -E "POST|application/json"

# 检查异常文件访问
find /path/to/n8n -name "*.json" -newer /path/to/n8n/package.json -exec ls -la {} \;

# 检查JWT令牌异常
grep -i "jwt\|token" /var/log/n8n/*.log | grep -v "refresh"

应急响应清单

优先级	行动	说明
🔴 P0	升级到n8n 1.0+	唯一完整修复方案
🔴 P0	轮换所有存储凭据	包括API密钥、OAuth令牌、数据库密码
🔴 P0	审计工作流日志	检查是否有异常Webhook调用
🟡 P1	禁用公开Webhook	减少攻击面
🟡 P1	实施网络层访问控制	限制n8n实例的访问来源
🟡 P1	审计连接系统	检查是否有未授权访问
🟢 P2	部署WAF规则	阻止异常Content-Type请求
🟢 P2	实施网络分段	隔离n8n与敏感系统

检测指标（IoC）

指标	含义
异常文件访问模式	可能的漏洞利用
认证异常	会话伪造尝试
新增或修改的工作流	未授权变更
n8n服务器发出的异常API调用	横向移动
异常来源的凭据使用	凭据被盗用

防御纵深：企业级防护策略

对于无法立即升级的企业，以下防御纵深措施可以降低风险：

# nginx反向代理：限制Webhook访问
server {
    listen 443 ssl;
    server_name n8n.internal.com;

    # 限制Webhook端点访问
    location /webhook/ {
        allow 10.0.0.0/8;      # 仅允许内网
        deny all;

        # 验证Content-Type
        if ($content_type !~* "multipart/form-data") {
            return 403;
        }

        proxy_pass http://127.0.0.1:5678;
    }

    # 管理界面需要VPN
    location / {
        allow 10.0.0.0/8;
        deny all;
        proxy_pass http://127.0.0.1:5678;
    }
}

长期建议：

• 将n8n部署在内网，通过VPN访问
• 使用外部密钥管理服务（HashiCorp Vault、AWS Secrets Manager）替代n8n内置凭据存储
• 实施最小权限原则，n8n连接的每个服务使用独立的受限凭据
• 建立n8n安全更新的定期审查机制

---

数据来源与参考文献

1. Cyera Research. "CVE-2026-21858: Ni8mare." cyera.com, January 7, 2026.
2. NVD. "CVE-2026-21858." nvd.nist.gov, 2026.
3. GitHub. "Chocapikk/CVE-2026-21858 PoC." github.com, 2026.
4. JFrog. "n8n Sandbox Escape Vulnerabilities." jfrog.com, February 2026.
5. n8n Official. "Security Advisory." n8n.io, 2026.

更新时间：2026-06-13