安全事件报告：xygeni-action GitHub Action 入侵

执行摘要

2026年3月3日，Xygeni检测到用于发布xygeni/xygeni-action GitHub Action的仓库存在可疑活动。该活动源于与维护者令牌和安装在该仓库上的GitHub应用程序关联的凭据被盗用。

事件期间，攻击者试图通过一系列操作将恶意代码引入代码库。 pull requests这些尝试受到现有分支保护规则的阻止，导致代码无法合并到存储库的主分支中。

然而，攻击者随后利用了另一个攻击途径，将可变的 v5 标签移动到指向恶意目标的位置。 commit 期间创建的 pull request 因此，引用 xygeni/xygeni-action@v5 的工作流可以在不对其工作流定义进行任何明显更改的情况下检索到被篡改的代码。

3月9日，根据社区报告，我们发现了标签篡改事件。被篡改的标签已被立即移除，事件响应程序也已启动。

我们的调查得出以下结论：

• 没有恶意代码合并到代码库的主分支中。
• 有 没有证据表明 Xygeni SaaS 平台遭到入侵 或客户数据。
• 曝光窗口仅限于引用 xygeni/xygeni-action@v5 的工作流程。 3 年 9 月 2026 日和 XNUMX 日.
• 被篡改的标签已被永久删除，不会再重新创建。

在发现标签篡改漏洞后，Xygeni 在其代码库和发布流程中实施了多项安全改进措施，包括：

• 移除受损标签并提供迁移指南 SHA 固定引用.
• 执行 释放不可改变性 跨存储库。
• 加强代码库权限和贡献者访问权限。
• 强制性 加密签名 commits 面向维护人员。
• 限制写入权限，仅允许少数维护人员和管理员拥有写入权限。

我们发布这份报告是为了提高事件的透明度，分享经验教训，并帮助加强整个 GitHub Actions 生态系统的安全实践。

虽然此次攻击利用了GitHub Actions中已知的可变标签漏洞，但该事件也凸显了全面保护代码库、严格管理凭证以及纵深防御的重要性。 CI/CD 系统。

透明度和协作对于提高软件供应链的韧性至关重要。

事件概述

本报告记录了对一起影响公众的安全事件的调查过程。 xygeni/xygeni-action GitHub Action 仓库。

2026年3月3日，攻击者利用与代码库自动化相关的被盗凭据，通过一系列攻击植入恶意代码。 pull request 尝试。有效载荷包含一个伪装成扫描仪版本遥测数据的命令与控制植入体。

代码库分支保护规则成功阻止了恶意代码合并到代码库中。 总分支然而，攻击者后来篡改了可变数据。 v5 行李牌将其重定向到 commit 包含注入的有效载荷。由于许多工作流都使用主版本标签引用 GitHub Actions，因此这 标签中毒 允许下游工作流程引用 xygeni/xygeni-action@v5 在不改变工作流程配置的情况下，找回被入侵的代码。

作为提供者 software supply chain security 模具Xygeni运营的基础设施直接集成到开发过程中。 pipeline并且 CI/CD 环境。此类项目经常成为攻击目标，攻击者旨在破坏广泛使用的开发者工具，从而影响下游环境。

时间线

第一阶段：恶意 Pull Requests （3月3日，世界协调时10:22-10:50）

2026年3月3日10:22 UTC，攻击者利用两个被盗用的身份信息，对xygeni-action代码库发起了一场快速而协同的攻击：维护者的个人访问令牌（PAT）和一个GitHub应用（xygeni-onboarding-app-dev）的私钥。在接下来的28分钟内，三名攻击者…… pull requests 创建并关闭了这些文件，每个文件都将混淆的 shell 代码注入到 action.yml 中。

攻击者的策略是系统且灵活的：

• PR＃46 （UTC 10:22–10:29）：由受感染的维护者 PAT 在分支下创建 特征/扫描遥测攻击者试图合并，但被分支保护规则阻止。该 PR 未合并即被关闭。
• 侦察 （UTC 时间 10:39–10:40）：攻击者通过创建并立即删除一个名为“”的分支来测试 GitHub 应用程序的访问权限。 测试应用程序访问权限这证实了该应用程序对该存储库具有写入权限。
• PR＃47 （UTC 10:41–10:44）：第二次尝试使用维护者 PAT，现在位于一个已重命名的分支下。 改进/扫描遥测再次因分支保护机制而被阻止。攻击者试图使用 GitHub 应用批准 PR，通过让一个被盗用的身份批准另一个人的工作来绕过双人审核的要求。但这次也失败了。
• PR＃48 （UTC 时间 10:45–10:49）：角色互换——GitHub 应用创建了 PR（推送）。 commit 4bf1d4e），维护者 PAT 提交了审批审查。但该审查也被分支保护机制驳回。

所有 PR 均未合并到主分支。我们的分支保护规则生效：需要两次批准、最近一次推送必须由推送者以外的人批准，以及禁止绕过这些设置，所有这些规则共同阻止了所有合并尝试。

我们的团队在例行 PR 审核过程中检测到了异常活动，并在 UTC 时间 12:21 启动了事件响应——距离第一个恶意 PR 发出不到两小时。响应措施包括移除工作流、保存恶意代码以进行取证分析以及保护代码库。

第二阶段：标签中毒

虽然分支保护成功阻止了恶意代码到达主分支，但攻击者利用了另一种攻击途径。攻击者使用被盗的 GitHub 应用凭据，将可变的 v5 标签指向了目标位置。 commit 4bf1d4e — 恶意 commit PR #48 即使在 PR 分支被删除后，仍然存在于存储库的对象存储中。

关键在于，这种标签篡改并非发生在 PR 之后。GitHub 的仓库活动日志不会像记录分支操作那样记录标签强制推送事件，这限制了我们还原标签修改的确切时间戳。然而，当社区在 3 月 9 日发出警报时，该标签已被证实遭到篡改。

这是关键所在：分支保护规则无法保护标签。 commit 包含后门的 Git 对象数据库存在于代码库中，下游工作流引用的 v5 标签可以被静默重定向到该后门。任何使用 xygeni/xygeni-action@v5 的工作流都会拉取被篡改的代码，而主分支或使用该代码库的工作流文件中不会出现任何可见的更改。

根本原因

我们的调查得出结论，根本原因是安装在存储库上的 GitHub 应用程序 (xygeni-onboarding-app-dev) 的私钥遭到泄露。

这个 GitHub 应用最初是为了测试 Xygeni 平台上的用户引导体验而创建的。它拥有对代码库的写入权限——事后看来，这些权限对于其预期用途而言过于宽泛。

攻击者利用 GitHub 应用的私钥可以：

• 随意生成短期安装令牌
• 创建并批准 pull requests
• 推 commit通过 HTTPS 使用 Git
• 移动标签——这一关键行动对此次事件产生了影响

攻击者同时使用了被攻破的维护者 PAT 和 GitHub 应用程序的凭据进行协同攻击：当一个身份无法单独绕过保护措施时，就同时使用这两个身份——一个用于创建，另一个用于批准。

私钥泄露的具体途径仍在调查中。GitHub 应用私钥（.pem 文件）可能通过配置错误的工作流程、被入侵的开发者机器或不安全的密钥存储方式泄露。

恶意有效载荷行为

注入的代码是一个紧凑的命令与控制植入程序。它被设计成与合法的扫描器一起静默运行，分三个阶段执行：

• 注册。植入程序联系 91.214.78.178 的 C2 服务器（通过 nip.io 通配符 DNS 伪装成 security-verify.91.214.78.178.nip.io），发送运行程序的主机名、用户名和操作系统版本。
• 轮询循环。在 180 秒内（符合典型的 CI 作业超时时间），植入程序每 2-7 秒轮询一次 C2 服务器，以获取要执行的命令。
• 命令执行。任何接收到的命令都通过 eval 执行，输出经过压缩（zlib）、base64 编码，并被泄露回 C2 服务器。

默默地吞咽下去，变量名称故意简短，轮询间隔随机化以避免流量模式检测。

如果植入程序运行在 CI 运行器上，攻击者将能够访问 GITHUB_TOKEN、代码仓库密钥、源代码，甚至可能包括工件签名密钥。如果植入程序在引用被入侵标签的工作流中执行，则攻击者可能允许在 CI 运行器上执行命令。

目前，我们有 没有证据表明有效载荷在任何客户的 CI 环境中执行过。 或者说，秘密是通过这次行动泄露出去的。

C2基础设施

C2 服务器托管于 Partner Hosting LTD（AS215826），注册地址为伦敦科文特花园谢尔顿街 71-75 号——这是一个常用的虚拟办公地址。该基础设施是新近配置的（子网在攻击发生前 5 天刚刚修改过），并且该 IP 地址已在威胁情报源中与远程访问木马 (RAT)、信息窃取程序和加载程序关联。基础设施和工具表明攻击者具备一定的技术能力，并且熟悉相关技术。 CI/CD 环境。

暴露评估

主要意见

可变标签是一个已知的风险——但惯性却很强大。

GitHub Actions 生态系统存在一个众所周知的问题：可变标签。当用户引用 action@v5 时，他们相信该标签指向的是安全的代码。但任何拥有写入权限的人都可以强制推送标签。这是 GitHub Actions 供应链中最常见的攻击途径，我们对此心知肚明——然而我们的文档仍然引导用户使用 @v5。

树枝保护并非标签保护

我们的分支保护规则完全按照预期运行。它们阻止了恶意代码合并到主分支。但攻击者并不需要合并——他们只需要…… commit 在代码仓库中（任何 PR 分支都提供此功能），以及移动标签的功能。分支保护让我们产生了一种虚假的安全感。

新功能不提供追溯保护

GitHub 引入 释放不可改变性 2025年10月——一项阻止修改版本标签的功能。我们之前就注意到了这一点，但并未完全理解其影响：

• 它只保护与 GitHub Releases 关联的标签，不保护独立标签。
• 它不具备追溯保护功能——在启用该功能之前创建的现有版本仍然可以更改。
• 标签保护规则（一项单独的功能）必须单独配置。

如果我们启用版本不可变性并确保 v5 标签与受保护的版本相关联，标签投毒攻击就会失败。

GitHub 应用权限范围过于宽松

该 GitHub 应用的写入权限超出了其运行需求。在拥有多个应用、机器人和集成的复杂组织中，权限很容易累积超出实际需要。每增加一项权限，就意味着增加了一个攻击面。

对公共记录的更正

研究人员的报告对提高公众意识起到了至关重要的作用，我们感谢他们的快速反应。然而，我们的内部调查发现了一些与他们所述不符的细节：

• 标签中毒事件的时间线研究人员的报告指出，v5 标签的移动时间大约在 3 月 3 日 10:49 UTC，即 PR 关闭之后。我们的调查无法证实这一时间点——GitHub 的仓库活动日志中并未记录标签强制推送事件。我们已知的是，该标签在恶意操作之后的某个时间点被篡改了。 commit 它被创建，并在社区于 3 月 9 日发现它之前就已存在。
• 此 commit 未“使用维护者的电子邮件签名”。 研究人员的报告描述了第一个恶意 commit 虽然它被描述为“使用维护者的电子邮件地址签名”，但这混淆了 Git 作者元数据和加密签名——这两者本质上是不同的。 commit 该代码未经过加密签名。攻击者只是简单地将 Git 作者字段设置为另一位维护者的电子邮件地址——任何人都可以这样做，因为 Git 作者元数据是自行报告的，未经身份验证。 commit 是通过被入侵的维护者 PAT 推送的；被使用的维护者的电子邮件并未被入侵，并且仅出现在 UTC 时间 12:21 开始的存储库活动日志中，作为事件响应团队的一部分。
• 涉及的身份研究人员将维护者身份和 GitHub 应用机器人描述为“凭证被盗而非内部人员操作”的证据。我们可以确认，维护者的经典 PAT 和 GitHub 应用的私钥均已泄露。两者均由同一外部攻击者使用。PR #48 出现在“幽灵用户”名下，因为它是由 GitHub 应用安装程序创建的，而非由已删除的人类帐户创建。
• 受影响的存储库数量该研究人员的报告引用了 137 个以上的代码库使用了 @v5 标签。我们对 GitHub 代码搜索结果的审查并未证实这一数字。在我们最近一次分析时，我们没有发现任何公共代码库在可执行工作流中积极使用 xygeni/xygeni-action@v5。已识别的引用对应于 Xygeni 代码库中的文档示例，这些示例后来都已更新。实际上，大多数客户使用基于 CLI 的扫描器下载和 Xygeni 的托管扫描功能，该功能会在内部调用该操作，并使用 SHA 锁定且经过内部验证的版本，该版本不受标签操作的影响。由于 GitHub 代码搜索仅索引公共代码库，我们无法 100% 确定私有代码库是否引用了该标签。根据现有信息，实际的下游风险似乎远低于最初报告的水平。

【我们将在调查结束后更新此部分内容。】

应对措施

立即回应（3月3日）

• 恶意 PR 被标记并阻止（分支保护阻止了合并）。
• 恶意代码已被提取并保存，以备法证分析。
• C2域名和IP地址被记录为入侵指标
• 被入侵的 GitHub 应用（xygeni-onboarding-app-dev）已从仓库中移除。
• 所有贡献者 PAT 均轮换。
• 已审查存储库审计日志——未发现先前未经授权的合并记录。

补救指南

补救措施（3月9日至10日）

• 被篡改的v5标签已被移除。
• 释放不可更改性 已为该存储库启用，并在所有 Xygeni 拥有的存储库中全局强制执行。
• 分支机构保护规则得到加强，包括强制签署相关文件。 commits（Xygeni 使用硬件支持的 commit （签名）
• v5 标签故意没有重新创建，以明确表明它已被篡改，并鼓励迁移到 SHA 固定引用。
• 文档已更新，引用了完整内容。 commit SHA (13c6ed2797df7d85749864e2cbcf09c893f43b23) 对应于 v6.4.0
• 作为预防措施，GitHub Actions 已暂时在该仓库中禁用。
• 写入权限受到限制——只有两名指定的维护者和两名代码库管理员保留写入权限。

适用于 xygeni-action 用户

如果您使用的是 xygeni/xygeni-action@v5，则应该：

• 立即更新 将您的工作流程固定到保险箱 commit SHA：

uses: xygeni/xygeni-action@13c6ed2797df7d85749864e2cbcf09c893f43b23

• 审核您的 CI 日志 2026 年 3 月 3 日至 3 月 9 日期间，任何到 91.214.78.178 或 security-verify.91.214.78.178.nip.io 的出站连接。
• 轮换所有秘密 在那段时间内接触过 CI 跑步者的人。
• 作为替代方案，您可以使用 直接扫描仪下载和验证

我们为何没有在3月3日公开披露

这是一个我们必须诚实回答的问题。

3月3日，当我们的团队对恶意PR做出响应时，评估结果显示攻击已在PR阶段被完全遏制。分支保护规则有效。没有恶意代码合并到主分支。没有CI运行器执行有效载荷。被入侵的PAT已轮换，GitHub应用程序已移除，仓库审计日志未显示任何先前未经授权的合并记录。该事件被归类为中等严重程度（P2）——入侵尝试已被阻止。

根据这一评估，当时认为没有必要公开披露信息。但事后看来，这一评估并不全面。

我们忽略了标签投毒。v5 标签已被悄悄移动，指向恶意目标。 commit但这在我们审查的相同审计层面上却无法发现。GitHub 的仓库活动日志对标签更改和分支操作的记录方式不同，这使得在初始调查期间，这种修改不太容易被发现。我们的事件响应重点放在了可见的攻击途径上—— pull requests 以及主分支——并且没有检查标签是否被篡改。

事后看来，这正是此次事件的关键教训之一：你不能泄露你不知道的事情。3月3日，我们对当时已知的威胁做出了快速有效的应对。但攻击者还有第二个更为隐蔽的攻击途径，这个途径在六天内都没有被发现——直到社区发现了它。

公开披露（3月9日）

2026年3月9日，社区成员提出了这个问题。 #54 展位研究人员对恶意代码和被篡改的v5标签提出了质疑，并发布了一份详细的分析报告，这有助于提高整个生态系统的防范意识。

我们感谢研究人员在扩大警报范围和为受影响用户提供切实可行的指导方面所发挥的作用。同时，我们也想澄清他们报告中的一些细节，因为我们的内部调查得出了不同的结论——这些内容将在“更正”部分进行说明。

对生态系统的启示

• 按 SHA 值而非标签进行 Pin 操作可变标签是 GitHub Actions 生态系统中最大的攻击面。 行动@ 在所有生产流程中。
• 了解每项安全功能的局限性分支保护保护分支，标签保护保护标签，版本不可变性保护版本发布。它们不可互换，而它们之间的漏洞正是攻击者可乘之机。
• 持续审核 GitHub 应用权限每个拥有写入权限的已安装应用都可能成为横向移动的途径。请遵循最小权限原则，轮换密钥，并定期检查关键存储库中安装了哪些应用。
• 将 CI 跑者视为敌对环境对于软件供应链中的存储库而言，网络出口监控、临时运行程序和密钥隔离并非可有可无。
• 新的安全功能需要主动采用。GitHub 的版本不可变性功能在此次事件发生前几个月就已经可用。未启用的功能无法提供任何保护——安全并非默认设置。
• 无符号 commit可能拥有伪造的身份. Git commit 作者和 committer 字段是自行报告的——任何人都可以将其设置为任何值。没有加密技术 commit 即使使用签名（GPG、SSH 或 S/MIME），也不能保证 commit 实际上，该恶意代码是由其声称的作者所写。在本事件中，攻击者将第一个恶意代码的作者设定为攻击者。 commit 发送到另一位维护者的邮箱，造成虚假归属。需要签名 commit通过分支保护规则消除此向量。
• 复杂性会扩大攻击面。PAT、GitHub 应用、分支保护规则、标签语义和版本不可变性之间的相互作用，使得攻击者能够找到任何单一功能都无法覆盖的漏洞。尽可能简化。即使无法完全理解威胁模型，也要努力理解。

妥协指标（IOC）