大多数团队将权限提升漏洞视为内核漏洞或误用。 sudo 在生产服务器上。到 2026 年，更危险的版本将存在于其他地方：在…… pipeline 它会构建并发布你的代码。 CI/CD 该作业通常会持有对您的代码仓库的写入权限、软件包注册表的令牌以及云平台的凭据。攻击者如果能让代码在该作业中运行，就不需要进行太多的权限提升。 pipeline 已经替他们做到了。
本指南解释了权限提升漏洞在网络上的表现形式。 CI/CD pipelines 和容器，逐步讲解攻击者最常用的攻击路径，并展示如何关闭每一条路径。
TL;DR：权限提升漏洞 CI/CD pipelines
在一个 pipeline攻击者通常不需要提升权限。 pipeline 已经有了。 权限提升漏洞 CI/CD 通常情况下，权限范围过大，超出了实际需要，导致不受信任的代码在其内部运行。
- Pipelines 是经过精心设计的特权。 他们可以阅读源代码、掌握机密信息、发布产品并部署到生产环境，这使他们成为组织中最有价值的升级目标之一。
- 大多数权限提升路径都是配置错误造成的，而不是漏洞利用造成的。 广泛的默认令牌，
pull_request_target运行分支代码的工作流和长期存在的云密钥造成的危害比任何零日漏洞都大。 - 容器权限提升可以将一个作业变成整个运行程序。 特权容器、root 用户和已挂载的 Docker 套接字使构建容器成为一扇门，而不是一道边界。
- 这种情况已经大规模发生了。 CHAINDROP 蠕虫利用 GitHub Actions 运行器的提升访问权限，直接从运行器内存中读取凭据。
- 解决办法是采用最小权限原则，并持续强制执行。 对每个令牌进行范围界定，强化每个容器，并在攻击者发现之前检测权限漂移。
什么是漏洞？
权限提升漏洞是指任何允许用户、进程或代码获得超出其预期权限的弱点。MITRE ATT&CK 将其列为一种独立的攻击策略。 TA0004：权限提升因为正是这一步，将小小的立足点变成了真正的破坏。
有两种经典形式：
- 垂直升级： 例如，从普通用户升级到 root 用户，或者从只读令牌升级到可写入令牌。
- 横向升级： 例如，横向移动，利用一个工作的访问权限访问另一个团队的存储库、密钥或环境。
攻击者利用三种弱点来提升权限：软件漏洞、配置错误和权限过大。在服务器上，漏洞最受关注。 CI/CD pipeline错误配置和过多的权限几乎造成了所有问题。
为什么它如此危险 CI/CD pipelines
A pipeline 它不仅仅是一个构建工具，更是一个自动化身份系统，拥有公司内最广泛的访问权限。一个典型的作业可以：
- 查看并修改源代码
- 从环境变量、密钥库和云元数据服务中读取密钥
- 发布软件包、镜像和发布工件
- 部署到测试环境和生产环境
此 OWASP顶级10 CI/CD 安全风险 直接指出了这个问题。它的风险 CICD-SEC-5：不足 Pipeline基于-的访问控制 描述了攻击者如何在……中运行恶意代码 pipeline 滥用授予它的横向移动权限，无论是在内部还是外部 CI/CD 系统。
这并非理论上的推测。在 2026 年 8 月的 CHAINDROP 攻击活动中，恶意软件 从 GitHub Actions 运行器内存中提取临时凭据 并利用窃取的发布令牌感染更多软件包。在 Linux 运行器上，有效载荷 通过 sudo 运行了它的收集器 读取运行进程的内存。这属于权限提升。 CI/CD pipeline最纯粹的s：一种有毒的依赖，对跑腿者的过度控制，以及这份工作可能触及的所有秘密。这与我们每周的调查结果中看到的模式相同。 恶意 npm 包.
权限提升漏洞隐藏在什么地方？ pipeline?
六条常见路径，每条路径能为攻击者解锁什么，以及关闭该路径的控制方法。
| 升级路径 | 它是如何发生的 | 攻击者会得到什么 | 如何关闭它 |
|---|---|---|---|
| 过度特权 pipeline 象征 | 工作流使用广泛的默认令牌范围运行，因为没有 permissions 块已设置 | 对代码、版本和其他工作流程的写入权限 | 设置只读默认值，并仅在需要时为每个作业授予写入权限。 |
| 中毒 pipeline 执行 | pull_request_target 或者类似的触发器会检出并运行来自不受信任分支的代码。 | 存储库密钥和写入令牌，来自单个 pull request | 永远不要在特权上下文中运行 fork 代码；将受信任作业和非受信任作业分开。 |
| 容器权限提升 | 构建容器可以以 root 用户身份运行，也可以在特权模式下运行，或者挂载 Docker 套接字运行。 | 在运行程序主机上拥有 root 权限，并可访问其运行的每个作业。 | 以非 root 用户身份运行，放弃某些功能，并在容器规范中阻止权限提升。 |
| 长期有效的云凭证 | 静态云密钥以密钥或环境变量的形式存储 | 工作结束后仍能持续访问云帐户 | 使用短期有效的联合凭证 自动撤销已泄露的秘密 |
| 持久自托管运行器 | Runner 可以在不同的作业和代码库中重复使用，而无需重新构建。 | 持久力，以及篡改其他队伍配置的能力 | 使用临时运行器并根据信任级别对其进行隔离。 |
| 特权人类账户 | 不活跃的管理员、外部合作者和未经审核的权限变更堆积如山。 | 一个可以更改的有效帐户 pipelines 和分支保护 | 持续审查访问权限，并对异常权限变更发出警报。 |
容器权限提升：当构建容器不是边界时
容器给人一种隔离的感觉，因此团队通常将其视为安全边界。 CI/CD它们通常并非一体。容器权限提升是指构建容器内的代码获得了对宿主机的控制权，进而控制了在其上运行的所有其他作业。
三种情况适用于大多数情况：
- 以root用户身份运行。 如果容器内的进程是根进程，那么任何突破都会从最强的位置开始。
- 特权模式。 特权容器对主机的访问权限几乎与直接在主机上运行的进程相同。
- 已挂载的 Docker 套接字。 安装
/var/run/docker.sock将其放入一个作业中，以便它可以有效地构建镜像，并将该作业的根目录交给主机，因为它可以启动新的特权容器。
安全研究人员已经展示了这种情况在实际的持续集成 (CI) 系统中是如何发生的。在一个有详细记录的案例中，研究人员从在 CI 容器内运行的构建脚本切换到了…… Cloudflare Pages 构建主机上的完全容器逃逸，前cis原因在于该集装箱被视为安全边界。
以下是一个经过强化的 Kubernetes 作业规范示例。关键设置是： allowPrivilegeEscalation: false，这 防止进程获得比其父进程更高的权限例如，通过 setuid 二进制文件。
# 强化构建 pod：阻止最常见的容器权限提升路径 api版本: v1 样: 下 元数据: 姓名: ci-build 规格: securityContext: 以非Root身份运行: true 以用户身份运行: 10001 seccompProfile: 类型: 运行时默认 集装箱：- 姓名: 我们按图纸规格 图片: registry.example.com/build-image@sha256: securityContext: 允许权限提升: false 特权: false 只读根文件系统: true 能力:
同样的原理也适用于 Dockerfile 本身。添加一个非 root 用户，并在入口点之前切换到该用户：
# 以非 root 用户身份运行容器 从 节点：22-slim 跑 useradd的 --uid 10001 --创建主目录 建设者 工作目录 /应用 COPY --chown=建造者：建造者 。 。 USER 建设者 CMD [“节点”, “ index.js”]
Kubernetes 文档 配置安全上下文 详细介绍了每一种设置。
GitHub Actions：一个隐藏在眼皮底下的权限提升漏洞
GitHub Actions 是许多团队首次遇到权限提升问题的地方。 CI/CD pipeline因为这些危险模式看起来完全普通。今天每个代码库中都值得检查两种模式。
令牌范围。 每个工作流程都会得到一个 GITHUB_TOKENGitHub 自身的指导意见 自动令牌认证 很明显：即使您没有显式传递令牌，操作仍然可以访问该令牌，因此您应该始终将其权限限制在最低限度。在工作流顶部设置只读权限，并为每个作业授予写入权限，可以一步消除最常见的权限提升路径：
姓名: 我们按图纸规格 on[推] # 所有作业的默认值：只读 权限: Contents: 读 工作: 实验: 连续运行: ubuntu-latest 步骤: # 将第三方操作固定到完整 commit SHA，而非可变标签 - 使用: actions/checkout@commit-sha> - 运行: npm ci && npm test 释放: 需要: 实验 连续运行: ubuntu-latest 只有这份工作才能写，而且只能写它需要的内容。 权限: Contents: 写 步骤：- 使用: actions/checkout@commit-sha> - 运行: ./scripts/release.sh
不受信任的触发器。 由以下因素触发的工作流 pull_request_target 即使使用目标存储库的密钥和具有写入权限的令牌运行， pull request 它来自一个分支。如果该工作流程随后检出并运行分支的代码，任何人都可以打开一个 pull request 并以你的权限执行代码。这是一个无需任何利用即可利用的权限提升漏洞，只需要…… pull request. 将特权步骤保留在受信任的代码上，并在单独的工作流中运行不受信任的代码，且不使用密钥。
如果你想在一个安全的地方查看这些模式， xygeni-山羊 存储库收集故意不安全的内容 pipeline 和 IaC 训练配置。如需更全面地了解您的 GitHub 设置，请参阅我们的指南。 如何判断 GitHub 应用或代码仓库是否安全.
如何防止权限提升漏洞 CI/CD pipelines
关闭权限提升 CI/CD pipeline归根结底，就是一个原则：最小权限原则，在每一层都应用该原则，并且持续检查，而不是只检查一次。以下是一个实用的检查清单：
- 对每个令牌进行作用域划分。 默认情况下为只读，每个作业都有写入权限，存储库工作流中没有组织范围的令牌。
- 将可信代码和非可信代码分开。 永远不要在包含机密信息的工作环境中运行来自分支或外部贡献者的代码。
- 加固所有构建容器。 非root用户，无特权模式，无Docker套接字，已移除所有权限
allowPrivilegeEscalation: false. - 摒弃长期保守的秘密。 优先使用有效期较短的联合身份验证凭证，并立即撤销任何已泄露的凭证。
- 固定你运行的内容。 引用第三方操作和图像 commit SHA 或摘要，因此被篡改的标签无法更改您的 pipeline.
- 注意漂移。 权限会随时间推移而扩大。当出现新管理员、分支保护减弱或工作流程发生意外变更时，系统会发出警报。
- 大门 pipeline. 在合并之前，如果出现严重配置错误，则构建失败。
难点不在于了解这些规则，而在于如何在数百个每天都在变化的代码库和工作流程中执行这些规则。
Xygeni 如何阻止权限提升漏洞？ CI/CD?
每条升级路径都与 Xygeni 检测或阻止该路径的功能相匹配。
| 风险 | Xygeni 的作用 |
|---|---|
| Pipeline 错误配置 | 配置错误检测器 扫描 GitHub、GitLab、Azure DevOps、Bitbucket、CircleCI 和 Jenkins 上的 CI 作业定义、构建脚本和配置文件，并标记超出最佳实践允许范围的权限。 |
| 容器权限提升 | IaC 以及集装箱检查 涵盖 Dockerfile、docker-compose 文件、Kubernetes 清单和 Helm Chart，包括以 root 用户身份运行的容器。 |
| 权限过高且不活跃的用户 | 最小权限分析可以识别不活跃用户和权限过高的用户，以及 Health Check 将每一项发现都转化为一张罚单 |
| 权限漂移 | 异常检测警报，针对异常权限变更、异常合并和意外插件安装发出警报 |
| 泄露的凭据 | 秘密检测涵盖代码， pipeline支持密钥类型和容器镜像，并可自动撤销受支持的密钥类型。 |
| 恶意代码 pipeline | 阻止反向 shell 和恶意软件下载 pipeline实时检测，MEW 甚至在恶意包的特征码出现之前就能检测到它们。 |
| 政策执行 | Pre-commit hooks 和CI guardrails 如果遇到关键问题，构建将失败，并可使用自定义 YAML 策略来管理您自己的规则 |
检查与 OWASP顶级10 CI/CD 安全风险 和 standard如 CIS、NIST 和 OpenSSF每一项发现都流入 Xygeni ASPM它会与代码、依赖项和密钥发现一起被优先处理，因此真正影响生产环境的权限提升漏洞会首先得到修复。
大多数权限提升 CI/CD pipelines 已经存在于您的工作流文件中，等待不受信任的代码运行。
常见问题解答
什么是权限提升漏洞？ CI/CD?
任何允许代码在……中运行的弱点 pipeline 获取超出工作所需的访问权限，例如权限过高的令牌、运行包含密钥的不受信任代码的工作流，或者可以访问主机的构建容器。
什么是容器权限提升？
容器权限提升是指容器内的进程获得更高的权限，通常是宿主机上的 root 权限。常见原因包括以 root 用户身份运行、处于特权模式以及挂载了 Docker 套接字。
儿童在 allowPrivilegeEscalation: false 阻止容器逃逸？
它阻止了一种重要的途径：进程获得比其父进程更高的权限，例如通过 setuid 二进制文件。它与非 root 用户、放弃权限设置且不使用特权模式结合使用效果最佳。
Is pull_request_target 总是危险的吗？
它本身并非如此。当工作流检出并运行来自该工作流的代码时，它就变成了一个权限提升漏洞。 pull request因为这段代码会使用你的密钥和一个具有写入权限的令牌来运行。
如何查找跨多个代码库的提权路径？
人工审核无法规模化。自动化审核则不然。 CI/CD 安全工具会持续扫描每个工作流程、容器规范和权限集，并在出现异常情况时发出警报。
