Langflow 高危路径遍历漏洞被主动利用，AI开发平台面临新风险

Langflow 是什么，为何受攻击者青睐

Langflow 是一个开源的可视化 AI 开发平台，用户可通过拖拽组件而非手写代码快速构建 AI 应用、智能体、检索增强生成（RAG）系统，甚至基于 MCP 的工作流。该项目在 GitHub 上已获超过 14.9 万个 star 和 9200 个 fork，说明其在 AI 开发社区中拥有广泛用户基础。由于平台支持快速原型和低代码开发，许多团队将其部署在本地或云端，用于内部 AI 项目的开发与测试。然而，这种广泛的部署方式也为攻击者提供了大量潜在目标。当平台存在高危漏洞时，攻击面随之扩大，尤其是当默认配置允许无认证访问时，风险更是成倍增加。

攻击者之所以盯上 Langflow，正是因为其易用性带来的高暴露度。平台的文件上传功能在默认配置下允许未经身份验证的访问，攻击者无需任何凭据即可触达易受攻击的端点。这意味着，只要一台 Langflow 实例暴露在公网，且未及时修复漏洞，攻击者就能在几秒内发送一条精心构造的 HTTP 请求，实现任意文件写入。这种“零门槛”攻击模式，使得 CVE-2026-5027 成为当前 AI 开发工具链中极具威胁的安全风险之一。

CVE-2026-5027 漏洞细节：路径遍历如何绕过限制

CVE-2026-5027 是一个高危路径遍历漏洞，存在于 Langflow 的文件上传功能中。具体来说，当用户通过 POST /api/v2/files 端点上传文件时，系统未对 filename 参数进行充分的输入验证。攻击者可在 filename 中注入路径遍历序列（如 ../），从而将文件写入文件系统的任意位置，而非仅限于预期的上传目录。例如，攻击者可以通过构造形如 ../../../../etc/nginx/conf.d/backdoor.conf 的文件名，将恶意配置文件写入服务器的 Nginx 配置目录，进而实现远程代码执行或持久化控制。

安全研究机构 Tenable 在年初发现并报告了这一漏洞，但未能在首次报告后获得 Langflow 官方的及时响应。直到 3 月 27 日，Tenable 选择公开披露该漏洞，以敦促用户和开发者采取防护措施。这一延迟的沟通过程凸显了开源项目在安全事件响应中的脆弱性：当维护团队缺乏足够的资源或响应机制时，漏洞可能长期处于未修复状态，给用户带来持续风险。因此，对于依赖开源工具的企业而言，主动监控安全公告并评估第三方组件的风险，显得尤为重要。

攻击活动已实锤：无认证写入文件，7000 余实例暴露

根据 VulnCheck 安全研究员 Caitlin Condon 的观察，其部署的蜜罐系统已捕获到攻击者利用 CVE-2026-5027 的活动。攻击者通过发送未经身份验证的请求，首先获取有效的会话令牌，然后利用路径遍历漏洞向目标服务器写入测试文件。这一过程无需任何凭据，单次请求即可完成，攻击门槛极低。Condon 还指出，Censys 的扫描数据显示，约有 7000 台 Langflow 实例暴露在公网上。不过，Censys 的数据包含过去 12 个月的历史扫描结果，实际当前暴露的实例数量可能有所不同。

这一数据表明，Langflow 的默认配置（如无认证自动登录）和易于部署的特性，导致大量实例被意外暴露。对于企业用户而言，这意味着潜在的攻击面不仅包括已知的漏洞，还包括因配置不当而导致的暴露风险。安全团队应立即对内部和外部暴露的 Langflow 实例进行梳理，确保仅在必要时开放公网访问，并启用强认证机制。此外，攻击者之所以选择这一漏洞，很可能是因为其“低成本、高收益”的特性：通过写入少量文件即可实现持久化或横向移动，进而渗透整个开发环境。

修复进展：官方发布补丁，但旧版本仍具风险

在 Tenable 公开披露漏洞后，Langflow 官方于 3 月 30 日发布了修复版本。Snyk Security 报告称，漏洞已在 langflow-base 包的 0.8.3 版本中得到修复，而 Langflow 应用本身的修复版本为 1.9.0。这意味着，用户需要升级到指定版本才能消除风险。然而，由于开源项目的版本管理和依赖复杂性，许多用户可能仍在使用旧版本，特别是那些通过容器或第三方镜像部署的实例。此外，部分企业可能因业务连续性或合规要求，无法及时升级，导致风险长期存在。

对于依赖 Langflow 的企业而言，修复工作不仅限于升级软件本身，还需要评估依赖链中的其他组件。例如，如果应用依赖特定版本的 Python 包或系统库，升级 Langflow 可能会引入新的兼容性问题。因此，建议安全团队在升级前进行充分的测试，并制定回滚计划。同时，由于攻击活动已经出现，未修复的实例应被视为“已被入侵”的高危系统，需要立即隔离并进行安全审计。

相似漏洞频发，AI 开发工具链安全堪忧

CVE-2026-5027 并非 Langflow 首次遭遇的高危漏洞。今年以来，该平台已曝出多个安全漏洞，包括 CVE-2026-0770、CVE-2026-21445 和 CVE-2026-33017。这些漏洞涉及不同的攻击面，如未授权访问、代码注入或服务器端请求伪造（SSRF），共同构成了对 Langflow 用户的严重威胁。此外，美国网络安全与基础设施安全局（CISA）在去年就曾警告称，CVE-2025 年的某些漏洞正在被主动利用，这进一步表明 AI 开发工具链正成为网络攻击的新兴目标。

这种频繁的漏洞曝光，反映了 AI 开发平台在快速迭代过程中对安全测试的重视不足。许多开源 AI 工具在设计初期更注重功能和易用性，而安全性往往被视为次要考虑。然而，随着 AI 应用在企业和政府中的广泛部署，攻击者也将目光转向这些高价值目标。对于 AI 开发团队而言，这意味着需要将安全纳入开发流程的各个阶段，包括静态代码分析、依赖扫描和容器镜像安全加固。

对企业用户的具体建议：如何降低风险

面对 CVE-2026-5027 的威胁，企业用户应立即采取以下措施降低风险：

1. 立即升级至安全版本 将 Langflow 应用升级至 1.9.0 版本，或确保 langflow-base 包已更新至 0.8.3。对于通过容器部署的实例，应重新构建镜像并替换运行中的容器。建议在升级前备份配置和数据，并测试新版本的兼容性。

2. 限制公网访问并启用认证 审查所有 Langflow 实例的网络暴露情况，确保仅在必要时开放公网访问。启用强认证机制（如 OAuth、LDAP 或 API 密钥），并禁用默认的无认证自动登录功能。对于内部使用的实例，建议通过 VPN 或内网访问进行隔离。

3. 部署 Web 应用防火墙（WAF） 在 Langflow 实例前部署 WAF，配置规则阻止路径遍历和文件上传攻击。常见的 WAF 如 ModSecurity 或云厂商的 WAF 服务，可有效减少恶意请求的影响。同时，启用日志记录和异常检测，及时发现潜在的攻击行为。

4. 进行安全审计和渗透测试 对所有 Langflow 实例进行全面的安全审计，检查是否存在其他未修复的漏洞或配置错误。可考虑聘请第三方安全团队进行渗透测试，模拟攻击者的行为，验证防护措施的有效性。对于高风险系统，建议定期进行安全评估。

5. 监控异常文件活动 在服务器上启用文件完整性监控（FIM），如 AIDE 或 Tripwire，实时检测文件系统的异常变更。结合 SIEM 工具（如 Splunk 或 ELK），建立告警机制，在发现未经授权的文件写入时立即响应。此外，定期检查系统日志中的异常请求，如大量上传请求或路径遍历尝试。

对开源社区的启示：安全需要协作与自动化

Langflow 的漏洞事件为整个开源 AI 社区敲响了警钟。开源项目在获得广泛采用的同时，也需要承担更大的安全责任。首先，项目维护团队应建立完善的安全响应流程，包括及时响应安全报告、定期发布安全公告和修复补丁。其次，社区应加强对第三方依赖的安全审查，避免因依赖链中的漏洞而影响整个项目。例如，Langflow 可考虑集成自动化的依赖扫描工具，如 Dependabot 或 Snyk，在依赖更新时自动检测安全风险。

此外，开源项目应积极参与安全社区的协作，如加入 OpenSSF（Open Source Security Foundation）或 CNCF（Cloud Native Computing Foundation）的安全项目。通过与其他项目和安全研究机构的合作，共享威胁情报和最佳实践，提升整体安全水平。对于企业用户而言，支持和参与开源安全项目，不仅能提升自身的安全能力，也能回馈社区，推动整个行业的安全发展。

总结：行动是关键，风险管理不能等

CVE-2026-5027 的主动利用表明，AI 开发平台正成为网络攻击的新热点。对于 Langflow 用户而言，风险不仅来自漏洞本身，更在于默认配置的不当暴露和修复的延迟。企业必须立即行动，升级软件、限制访问、部署防护措施，并持续监控潜在威胁。对于开源社区而言，这一事件提醒我们，安全必须与功能同步发展，协作与自动化是降低风险的有效手段。

未来，随着 AI 应用的进一步普及，开发工具链的安全问题将愈发突出。企业和开发者应将安全视为 AI 项目的核心组成部分，而非事后补救的环节。唯有如此，才能在享受 AI 带来的效率提升的同时，守住数字资产的安全底线。