AI开发工具背后的隐形“后门”
随着大模型应用的爆发式增长，像Flowise这类低代码/无代码开发平台，凭借其拖拽式构建LLM工作流的便捷性，迅速成为了企业内部构建AI Agent的首选方案。然而，便利性往往伴随着安全边界的模糊。
近期，安全界披露了针对Flowise平台的重大安全隐患。CVE-2025-59528这一漏洞被评定为CVSS满分10.0的极危级别，其核心影响在于允许攻击者在目标服务器上执行任意JavaScript代码。从我们的应急响应经验来看，攻击者对于这类新兴AI基础设施的关注度正呈指数级上升，一旦此类平台被攻破，攻击者往往能直接获取服务器的完整控制权，甚至通过内网横向移动，窃取企业核心的大模型语料库或业务敏感数据。
攻击链深度解析：从配置项到远程代码执行
此次漏洞的核心根源在于Flowise的“自定义MCP节点（Custom MCP node）”设计缺陷。MCP（Model Context Protocol）作为连接AI Agent与外部工具的桥梁，本应是安全的通信接口，但在Flowise 3.0.5及之前版本中，其配置处理逻辑存在严重的安全漏洞。
攻击者利用了该平台对用户提供的MCP配置字符串缺乏严格校验的弱点。当开发者在Flowise中拖入MCP节点并填入JSON配置时，系统内部调用的转换函数（convertToValidJSONString）会将用户输入直接传递给JavaScript的Function()构造器。
这一设计失误导致了致命后果：Function()构造器在处理输入时，并未对其进行沙箱隔离或语法过滤，而是直接将其作为可执行代码运行。由于该函数在Node.js运行时环境下具备完整权限，攻击者可以通过构造恶意的JSON配置，轻松调用child_process或fs等敏感模块，从而实现文件读取、命令执行等恶意操作。
活跃的威胁情报：不仅仅是单一漏洞
根据最新的威胁情报监测，自今年4月起，已经观测到针对该漏洞的野外利用行为。监测数据显示，攻击流量呈现出明显的自动化特征，甚至追踪到了源自Starlink IP的攻击尝试。
更值得警惕的是，这并非孤立事件。在Solar团队持续跟进的安全动态中，我们发现除了CVE-2025-59528外，Flowise还存在CVE-2025-8943（身份认证缺失）和CVE-2025-26319（任意文件上传）等多个高危漏洞，且均已被标记为活跃利用状态。这意味着攻击者正在构建一套组合拳，通过扫描互联网上暴露的数万个Flowise实例，寻找最薄弱的入口进行渗透。
为什么企业容易忽视这些风险？
从Solar应急响应团队处理过的多个案例来看，这类AI平台往往被视为“内部研发工具”，因此在部署时缺乏严密的边界防护。
很多企业在部署Flowise时，将其直接暴露在公网，且未配置任何WAF或强认证机制。这一环节是很多企业容易忽视的盲点：开发者为了开发效率，往往忽视了这些工具并非为生产环境的直接暴露而设计。一旦底层平台存在漏洞，由于其具备Node.js执行权限，攻击者往往能直接绕过应用层的防御，直接在系统层面扎根。
Solar安全建议：构建AI时代的防御闭环
针对此次Flowise事件，以及日益复杂的AI基础设施安全挑战，Solar应急响应团队建议企业采取以下防御措施：
第一，立即开展资产排查。全面梳理组织内部是否存在暴露在公网的Flowise实例，确认版本号。如仍在使用3.0.5及以下版本，应第一时间升级至3.0.6或更高版本（当前推荐3.1.1及以上）。
第二，实施最小化权限原则。不要将AI开发平台直接暴露在公网。如果必须在生产环境使用，应强制部署在内网环境，并通过VPN或零信任网关进行访问控制。
第三，强化代码执行监控。在Node.js运行环境下，应配置严格的沙箱策略，限制应用对敏感模块（如child_process、fs、net）的调用权限，从系统调用层面阻断恶意代码的破坏行为。
第四，建立持续的漏洞运营机制。AI工具链更新极快，漏洞披露频率高。企业不应仅关注传统的Web应用漏洞，更应将AI开发框架、模型服务组件纳入日常的漏洞扫描与应急响应体系中。
类似攻击近年来明显增加，攻击者不再仅仅盯着传统的数据库或Web应用，而是将目光转向了这些承载着AI逻辑的中间件平台。AI安全不仅仅是算法层面的对抗，更在于基础设施的稳固。
如果您想了解勒索病毒的最新发展趋势，或在实际业务中遇到类似安全事件，欢迎关注“Solar应急响应团队”。
全国热线：400-613-6816 官网：www.solarsecurity.cn / www.sierting.com