GitLab CE/EE 16.0.0 版本里藏着一个 CVSS 10.0 的远程漏洞，CVE-2023-2825。代码路径穿越，执行未授权读取任意文件。漏洞听起来像老生常谈，复现但这次能直接拿到 RCE。远程我拿 Docker 搭了个环境，代码把过程走了一遍。执行

环境用官方镜像，漏洞版本锁定在 16.0.0-ce.0。复现启动命令没什么特别的远程，映射 80 和 22 端口，代码给足内存。执行容器起来后需要等两分钟，漏洞GitLab 的复现初始化很慢，尤其是数据库迁移那一步。浏览器打开 localhost，设置 root 密码，随便建个项目。这些前置步骤跳不过去，漏洞触发点依赖一个合法的项目路径。

漏洞入口在 uploads 接口。GitLab 处理文件上传时，对路径参数的过滤存在缺陷。具体来说，/(group)/(project)/uploads/(hash)/(filename) 这个路由里，filename 段没有正确剥离 .. 序列。构造类似 ..%2f..%2f..%2f..%2f..%2f..%2f..%2f..%2f..%2f..%2fetc%2fpasswd 的路径，就能跳出项目目录，读到系统文件。URL 编码要处理干净，否则 Rails 路由层会直接拦截。

我写了个 Python 脚本发请求。requests 库，关掉自动重定向，手动拼 URL。第一次试的时候返回 404，以为是路径深度不够。后来发现是编码问题，%2f 被二次解码了。换成双写编码 %252f，服务端解码一次后正好变成 %2f，再解码就是 /。这个细节卡了我半小时。成功读取 /etc/passwd 那一刻，响应体里出现 gitlab-www 和 git 用户，确认穿越成功。

读文件只是第一步。要 RCE，得找可写路径配合。GitLab 的 gitlab-rails 进程以 git 用户运行，家目录在 /var/opt/gitlab。我尝试读取 /var/opt/gitlab/.ssh/id_rsa，不存在。读取 /opt/gitlab/embedded/service/gitlab-rails/config/secrets.yml，拿到了 secret_key_base。这玩意儿能用来伪造 Rails 的 session cookie。但 GitLab 的 session 序列化格式是 Marshal，直接伪造需要构造 gadget chain，成本太高。

换思路。GitLab 有个 gitlab-rails runner 命令，能在控制台执行 Ruby 代码。如果能写到某个被 runner 加载的文件里，就能触发。我盯上了 /var/opt/gitlab/gitlab-rails/etc/gitlab.yml，但它是只读的。又看了 /var/opt/gitlab/.gitconfig，可写。Git 在操作仓库时会读取这个文件，里面的 core.fsmonitor 或 core.hooksPath 能指向任意可执行文件。不过触发条件需要一次 git 操作，不够直接。

更直接的办法是写 SSH 公钥。GitLab 容器里 git 用户的 authorized_keys 在 /var/opt/gitlab/.ssh/authorized_keys。路径穿越只能读不能写，得另找写入点。GitLab 的 uploads 功能本身允许上传文件，但文件落在项目目录下，权限是 git 用户可读写。如果能把上传的文件软链接到 SSH 目录，就能绕过。可惜上传接口不支持创建符号链接。

最后用了最粗暴的方法：路径穿越读 /proc/self/environ，拿到环境变量里的 GITLAB_ROOT_PASSWORD。虽然官方镜像默认不设这个变量，但很多生产环境为了自动化部署会显式传入。我本地环境没设，所以没读到。但读到了 DATABASE_URL，里面包含 PostgreSQL 的密码。用这个密码连数据库，直接改 users 表里 admin 的 encrypted_password，登录后台，再通过管理员功能执行系统命令。这条路绕了一圈，但确实通了。

整个复现过程最麻烦的不是漏洞本身，是环境初始化。GitLab 的组件太多，Nginx、Puma、Sidekiq、PostgreSQL、Redis 全塞在一个容器里，资源不够直接 OOM。我给了 8G 内存才跑稳。另外，16.0.0 之后的版本修了这个洞，16.0.1 就打了补丁。升级是唯一靠谱的防御手段。临时缓解可以限制 /uploads 路径的访问，但治标不治本。

写这篇文章的时候我又试了一次，用 curl 不带任何编码，直接发 ../../../etc/passwd，返回 400。Rails 的路由解析比想象中严格。必须编码，而且得算准解码层数。这种细节在真实攻击里往往是成败关键。