Kestra OSS 漏洞进入 KEV：无需认证即可创建工作流并远程执行代码-速维云

事件概述

美国网络安全与基础设施安全局（CISA）在 2026 年 9 月 2 日把 Kestra OSS 漏洞 CVE-2026-49869 加入已知被利用漏洞目录（KEV），并要求相关机构按厂商指引完成缓解和取证排查。CISA 给出的修复期限为 9 月 5 日，同时把该漏洞标记为需要取证分类处置。这意味着风险已经不再停留在理论验证阶段：仍在运行受影响版本的组织，应当把它放进紧急修复队列，而不是等待下一次常规维护窗口。

Kestra 是一套开源、事件驱动的工作流编排平台，常被用于数据处理、自动化任务和跨系统流程。此类平台通常能够调用脚本、连接数据库、访问对象存储并接触云端凭据，因此一旦认证边界被绕过，影响往往会超出应用本身，进一步波及工作容器、内部网络和云账户。

漏洞如何越过认证

Kestra 官方 GitHub 安全公告指出，问题出在 Basic Auth 的路径放行逻辑。程序原本只想公开特定配置接口，却使用了“路径以 /configs 结尾”的后缀匹配。结果是，只要其他 API 路径的最后一段同样叫 configs，也可能被错误地当成公开接口处理。

攻击者无需有效账号，便可能创建一个名称满足条件的恶意工作流并触发执行。Kestra 默认安装包含 Shell、Python、Node 等脚本执行插件，因而认证绕过可以进一步转化为远程代码执行。厂商公告还提到，相关任务在工作容器中可能以 root 身份运行；不过公告没有确认可直接从容器逃逸到宿主机，因此不能把“容器内 root”与“已经控制宿主机”简单画等号。

影响范围

根据厂商公告与 NVD 信息，受影响版本包括低于 1.0.45 的版本，以及从 1.1.0 开始但低于 1.3.21 的版本。修复版本为 1.0.45 和 1.3.21。官方描述的主要受影响场景是启用 Basic Auth 的 Kestra OSS 实例；这也是 Kestra OSS 的默认认证模式之一。

风险并不只属于公网部署。官方公告明确指出，只要攻击者能够访问 Kestra 服务端口，就可能尝试利用，因此办公网、测试网、开发网和通过 VPN 接入的内网实例同样需要清点。若工作节点可以访问云元数据服务、内部 API、数据库或凭据存储，潜在后果还可能包括服务端请求伪造、云凭据泄露、工作流篡改以及审计日志被破坏。

工作流编排平台一旦认证边界失守，脚本执行、容器权限与内部网络访问能力可能形成连锁风险。

为什么运维团队要立即关注

工作流编排平台是典型的“高权限中枢”：它为了完成自动化任务，往往被授予比普通 Web 应用更广的网络和数据访问能力。攻击者一旦获得任意工作流执行能力，就可能借助平台现有连接器和脚本能力横向探测内部系统，而不需要首先攻破每个目标服务。

其次，很多团队会把 Kestra 部署在 Docker 或 Kubernetes 环境中，于是容易产生“容器天然隔离”的误判。容器确实能降低部分风险，但如果工作容器能读取挂载目录、访问内部服务、获取环境变量或调用云元数据接口，攻击造成的业务损失仍可能非常严重。真正的防线应当是认证、网络隔离、最小权限和凭据管理共同发挥作用。

先做资产与版本排查

管理员应先从 CMDB、容器编排清单、镜像仓库、反向代理配置和云资产列表中确认是否部署 Kestra OSS，并记录实例版本、暴露地址、所在网络、使用的认证模式以及工作节点可访问的资源。不要只在公网扫描结果里找目标，开发和测试环境也可能保存真实凭据，或与生产网络互通。

版本核对优先使用管理界面、容器镜像标签、部署清单或官方支持的版本查询方式，并与实际运行实例交叉确认，避免只看某个旧的 compose 文件就得出结论。若版本落在受影响范围，应当按已暴露资产优先、接触敏感凭据资产优先的原则安排升级。

排查日志时，可重点关注异常的新建或覆盖工作流、名称为 configs 的资源、非预期执行记录、脚本任务、异常出站连接、访问云元数据地址的迹象、可疑 KV 变更以及日志被删除或出现时间缺口等现象。由于公开漏洞细节已经足以帮助攻击者理解触发条件，单纯“没有收到告警”不能证明系统未被访问。

修复与临时缓解

最直接的处理方式是升级到厂商已经修复的版本：1.0.x 分支至少升级到 1.0.45，1.1.0 至 1.3.20 范围的部署升级到 1.3.21 或更高安全版本。升级前应备份配置和数据库，在测试环境验证插件、工作流与连接器兼容性，并提前评估滚动更新或重启对正在执行任务的影响。生产环境不要未经评估直接覆盖镜像或强制重启全部工作节点。

如果暂时无法升级，应先从负载均衡、反向代理、安全组或网络策略层收敛访问范围，仅允许明确的管理网段和受控跳板机访问 Kestra；同时避免将服务端口直接暴露到互联网。对 Kubernetes 部署，可复核 Ingress、Service 类型和 NetworkPolicy；对 Docker 部署，应检查端口映射与宿主机防火墙，但改动前必须确认不会误伤正常调度任务。

还应限制工作容器访问云元数据服务和不必要的内部网段，减少挂载的敏感目录，清理不再使用的连接器凭据，并遵循最小权限原则调整云 IAM。若发现可疑活动，应先保全 Web、应用、容器运行时、反向代理和云审计日志，再隔离受影响实例、轮换可能暴露的密钥并开展横向排查；不要为了“清理现场”而先删除容器或日志。

不能只打补丁

由于 CISA 已确认该漏洞存在真实利用，并要求进行取证分类，已经公网暴露或位于复杂共享网络中的实例不应把升级视为处置终点。补丁可以阻止后续利用，却不会自动撤销攻击者可能已经获得的凭据，也不会恢复被修改的工作流和访问控制。

完成升级后，应回查升级前后的工作流定义、执行历史、用户与权限、KV 数据、插件变更和异常网络连接。若 Kestra 可以访问对象存储、代码仓库、数据库、云 API 或通知平台，还应检查这些下游系统的审计记录，并按风险轮换相关令牌。对互联网服务而言，必要时可结合速维云云服务器的安全组与主机防火墙做双层收敛，但规则调整前仍要先梳理真实业务来源，避免把管理端口从“公网开放”变成“误封运维”。