-
-
[原创]代码层面深度分析 Dokploy 的 CVE-2026-24841 命令注入漏洞
-
发表于: 2小时前 53
-
一、组件介绍
Dokploy 是一款开源的轻量级 DevOps 平台,专为开发者和小团队设计,核心目标是简化 Docker 容器化应用的部署、管理和运维流程。它可以理解为「简化版的 Portainer + CI/CD 工具」,无需复杂的配置即可快速实现代码部署、容器管理、日志查看、终端交互等核心能力,主打「易用性」和「轻量化」。
二、漏洞分析
(一)获取漏洞版本源码
(二)代码层面分析漏洞成因(定位漏洞位置)
核心漏洞文件:apps/dokploy/server/wss/docker-container-terminal.ts
- 定位漏洞代码段

- 漏洞成因分析
containerId和activeway这两个参数直接拼接到了docker exec 命令中,如果没有针对这两个参数做过滤,就会导致直接拼接攻击者传入的恶意参数(如 ;、&&、|、$( ) 等命令分隔符)造成命令执行漏洞
而且可以看到的是spawn 调用时开启了 shell: true,意味着拼接后的命令会通过系统 shell 执行,攻击者可通过注入分隔符执行任意命令。
举例:攻击者传入 containerId=test; whoami,拼接后的命令变为 docker exec -it test; rm -rf / ${command},shell 会先执行 docker exec -it test,再执行 whoami,导致服务器被恶意操作造成任意命令执行。
我们往上分析针对这两个参数是否有处理操作

可以看到有两个if分支,用于检查containerId参数是否存在和用户是否登录
并无针对恶意参数的检验操作直接将参数拼接到了docker exec 命令中造成命令执行漏洞
(三)修复代码对比
我们看一下修复后的代码逻辑,对比一下会有更加直观得感受


同样拼接了containerId,shell这两个参数,shell这个参数由传入的activeWay决定,所以还是要分析containerId、activeWay这两个参数在传入之前做了什么处理
containerId:
使用了这个方法isValidContainerId()处理了containerId参数,跟进实现逻辑

代码通过正则表达式检查三种格式:完整的64位十六进制ID、简短的12位十六进制ID或有效的容器名称(以字母数字开头,包含字母数字下划线点横线,长度不超过128字符)。
如果格式不对就会报错,实现了防御恶意参数传入的命令注入攻击的效果
activeWay:
跟进查看isValidShell()方法实现
白名单校验这个值

通过上面的分析可以知道,修复后的带代码逻辑增加了对传入参数的合法性和安全性的校验,以此达到防御命令注入的目的
定位漏洞触发路由 / 接口

(四)示例poc
GET /docker-container-terminal?containerId=test-nginx&activeWay=sh;whoami&serverId=1 HTTP/1.1 Host: localhost:3000 Upgrade: websocket Connection: Upgrade Sec-WebSocket-Key: xxxxxxxx Sec-WebSocket-Version: 13