文章总结： 2026年5月20日GitHub披露其内部代码仓库遭供应链攻击泄露约3800个仓库。攻击始于5月18日一个被投毒的VSCode扩展（疑似NxConsole）在11分钟窗口期内感染开发者设备，通过GitHub员工设备渗透内部系统。攻击组织TeamPCP使用名为MiniShai-Hulud的恶意软件窃取1Password、GitHub令牌等凭证，并利用ClaudeAI辅助开发恶意组件。GitHub已紧急轮换凭证并启动应急响应。 综合评分： 87 文章分类： 供应链安全,漏洞分析,安全大事件,应急响应,恶意软件

---

Github 被黑

原创

tonghuaroot tonghuaroot

RedTeam

2026年5月20日 13:48 日本

在小说阅读器读本章

去阅读

GitHub 被黑 · 事件简报

写在前面

5 月 20 日，GitHub 官方账号发了一组推文，承认前一天他们的内部代码仓库被人偷了。

入口是一台员工电脑，载体是一个被投毒的 VS Code 扩展。攻击者声称偷走了大约 3,800 个 GitHub 内部仓库，GitHub 自己的说法是这个数字 directionally consistent，方向一致。

挂出这批数据叫卖的，是一伙叫 TeamPCP 的人。他们最近这几个月在软件供应链上的活跃程度，按 The Hacker News 列的清单算，至少包括 Nx 主包、Microsoft 的 durabletask、TanStack、Mistral AI、Guardrails AI 等等。GitHub 这次是他们目前为止打得最大的一票。

这件事单看是一起公司被黑事件。但是把它和最近这几个月开发者工具链上的几起攻击放在一起看，故事就完全不一样了。它是一个供应链的供应链攻击，每一层看起来都很合理。

GitHub 自己说了什么

先把一手材料抄下来。GitHub 的 thread 总共六条推文，关键信息分布如下。

引导推文：

We are investigating unauthorized access to GitHub’s internal repositories. While we currently have no evidence of impact to customer information stored outside of GitHub’s internal repositories (such as our customers’ enterprises, organizations, and repositories), we are closely monitoring our infrastructure for follow-on activity.

第一条，事件原因：

Yesterday we detected and contained a compromise of an employee device involving a poisoned VS Code extension. We removed the malicious extension version, isolated the endpoint, and began incident response immediately.

第二条，影响范围：

Our current assessment is that the activity involved exfiltration of GitHub-internal repositories only. The attacker’s current claims of ~3,800 repositories are directionally consistent with our investigation so far.

第三条，凭证轮换：

We moved quickly to reduce risk. Critical secrets were rotated yesterday and overnight with the highest-impact credentials prioritized first.

第四、第五条说他们继续在分析日志、验证轮换、监控后续，调查完成后会发完整报告。

按这组推文捋时间线：5 月 19 日检测并控制了员工设备失陷，当天和当夜开始轮换高影响凭证，5 月 20 日公开披露。从检测到公开公告，大约 24 小时。这个节奏对一家上市公司的子公司来说算很快。

攻击不是从这里开始的

GitHub 在推文里没有点名是哪一个 VS Code 扩展。这一点要先说清楚。

但是把时间线对一对，公开报道里基本指向同一个嫌疑对象：Nx Console。这是个用来管理 Nx monorepo 工程的 VS Code 扩展，在官方 marketplace 上有 220 万安装量，在 GitHub/Microsoft 这种重 monorepo 的生态里属于常备工具。它的 marketplace 包名叫 nrwl.angular-console。

事情的另一头是这样的：

5 月 18 日，UTC 时间 12:36 到 12:47 之间，Nx Console 的 18.95.0 版本被发布到 VS Code Marketplace。用的是被盗的发布凭证，发布者不是 Nx 团队本人。这个被注毒的版本只在 marketplace 上活了大约 11 分钟，但任何在这 11 分钟里更新或者新装了 Nx Console 的开发者，机器都被洗了一遍。

整条链是这样的：

1. Nx 团队的某位开发者被钓
2. 攻击者用偷来的凭证推了恶意版本 18.95.0 到 marketplace
3. 任何在 11 分钟窗口内装/更新 Nx Console 的开发者机器被洗
4. 其中至少一个开发者是 GitHub 员工
5. 这个 GitHub 员工的访问被滥用，3,800 个内部仓库被外传

每一层从被攻击者的视角看都是合理操作：写代码的开发者、用流行扩展的开发者、定期 update 的开发者、把生产凭证留在 1Password 里的开发者。没有人做了明显错误的事，但链条最后通到了 GitHub 内部。

GitHub 内部仓库泄漏 · 攻击链

再次说明：GitHub 自己没有公开确认那个扩展就是 Nx Console。第 1 步到第 5 步的串联是公开报道做的关联推断。GitHub 的 fuller report 之前，哪个扩展、哪个员工、哪条凭证，都还在 GitHub 那一边没出来。

谁干的：TeamPCP 和那条沙虫

挂出 GitHub 内部仓库叫卖的人不是匿名陌生 ID，是 TeamPCP。

这个组织在过去几个月里在软件供应链上很活跃。按 The Hacker News 的复盘，TeamPCP 名下的近期事件至少包括：

• Nx 主包（npm 上）被投毒，命名为 s1ngularity
• TanStack 项目下手
• Mistral AI 的资产被打
• Guardrails AI 被打
• Microsoft 的 durabletask（Durable Task workflow execution framework 的官方 Python 客户端）被投毒
• Nx Console 18.95.0（这次）

他们用的恶意软件家族有个名字叫 Mini Shai-Hulud。Shai-Hulud 是科幻小说《沙丘》里那条巨型沙虫的名字，在小说里它在沙下面静默移动，吞掉所有踩到的东西。在这个语境里，名字起得很贴切，因为这是个自我复制的供应链蠕虫：被它注毒的包，会通过偷到的凭证再去发布更多被注毒的包。

GitHub 这次出事之后，TeamPCP 在一个英文黑客论坛挂出了内部仓库的样本和叫卖帖。具体论坛和帖子 URL 媒体没披露，已知的二手来源是一个叫 Dark Web Informer 的 OSINT 账号在 X 上分享的截图。

帖子里的关键文字，按 The Hacker News 摘录的样子，原文是这样的：

As always, this is not a ransom. We do not care about extorting GitHub, 1 buyer and we shred the data on our end, it looks like our retirement is soon so if no buyer is found, we leak it for free.

底价：不低于 5 万美元。

几个观察：

第一，as always。这是个非常自信的开头，意思是和我们以前每次一样。它假定读者知道他们前几起的玩法。这是一个把自己当老牌品牌运营的口吻。

第二，1 buyer and we shred the data on our end。一个买家就够了，买完销毁。这种说法本质上是把价格定位在专属买家溢价那一档，目的是把单价拉高。是不是真销毁外人无法验证。

第三，our retirement is soon。这句话有意思。要么是真打算收手了，要么是制造紧迫感来催买家出价。两种解读都对销售有利。结合前面一长串受害名单看，他们手里的库存确实积压不少，到了清仓阶段也不奇怪。

第四，if no buyer is found, we leak it for free。这是最关键的一句。它把交易从单纯的勒索转换成了一种博弈：GitHub 这一头能不能赶在卖出之前把所有有用的凭证轮换完，能不能在数据被免费公开之前完成应急响应。GitHub 第三条推文里 highest-impact credentials prioritized first 那句话，背景就是这个倒计时。

那 11 分钟里 payload 做了什么

5 月 18 日 12:36 到 12:47 UTC 这 11 分钟里，被注毒的 Nx Console 在做的事情，技术上比一般的凭证窃取脚本复杂得多。

载荷不直接打包在扩展里，而是藏在一个dangling orphan commit 里。这个 commit 挂在 nrwl/nx 这个官方仓库的对象数据库里，不在任何分支上，外人看不到，但是知道 commit hash 的人可以直接拉取。扩展启动之后从这个 orphan commit 拉一个 498 KB 的混淆载荷。

把恶意载荷藏在官方仓库的 orphan commit 里这一招是有讲究的：你做 EDR 规则、做 SBOM 审计、做扩展 marketplace 静态分析，看到的是一个干净的扩展从一个声誉极佳的 GitHub 仓库拉了一段数据，所有的信誉信号都是绿的。

载荷用 Bun 这个 JavaScript runtime 跑。Bun 不是默认在开发者机器上的，扩展会先安装 Bun，再用 Bun 跑 index.js。为什么不用 Node？Bun 的执行环境观测点少、社区监控少、单文件二进制更难被 EDR 写规则。这是一个有意识的选择。

进了执行环境之后，6 个并行的凭证收集器同时跑，目标清单按媒体披露的样本分析是：

• 1Password vault
• Anthropic Claude Code 的配置（包含 API key）
• npm 凭证
• GitHub 凭证（OAuth token、PAT、SSH key）
• AWS 凭证（包括查 AWS metadata service）
• HashiCorp Vault token
• Kubernetes secret / kubeconfig

Linux 上还会直接读 /proc/*/mem，把 process memory 里残留的凭证字符串扫出来。这个比读配置文件凶得多，因为它能拿到那些没保存在硬盘上、只在内存里临时存在的凭证。

macOS 上会落一个 Python 后门叫 ~/.local/share/kitty/cat.py，并装一个 LaunchAgent com.user.kitty-monitor.plist 做持久化。kitty 是个流行的终端模拟器名字，文件路径起这个名字明显是想混淆视听。Daemonize 的进程身上带一个 __DAEMONIZED=1 环境变量，这反而成了一个比较好的 IOC。

凭证拿到之后，回传走三条并行的通道：

• HTTPS POST 直接发到混淆过的 C2 域名
• 用偷到的 GitHub token 调 GitHub API，本身就是合法流量
• DNS tunneling，把数据切成 DNS 子域名标签

三通道并行的设计目的是冗余。哪怕你网关把可疑 HTTPS 出站全 block 了，DNS 出站也基本不会被 block，哪怕你把 DNS 出站也限制了，GitHub API 出站对开发者机器来说是天经地义的流量。要把这三条同时切断，基本等于让开发者没法工作。

evasion 那一头也不马虎。在执行最开始有一段检查，如果机器时区是俄罗斯或 CIS 时区，就直接退出不感染。这个特征早就在 BlueNoroff 之类朝鲜组织的样本里见过，在勒索软件家族里更常见。它不一定等于俄语系归属，因为这是公开的同行 OPSEC 模仿点，但至少说明攻击者知道这套规则、有动机去模仿。

公开样本里被低估的能力还有一项，下一节单独说。

补一个修复信息：Nx Console 的修复版本是 18.100.0 或更高。如果你机器上还停在 18.95.0 或者最近几天装过/更新过 Nx Console，需要假设凭证已经被盗，重做凭证轮换。

Claude 也是攻击的一部分

这一节单独拿出来说，因为它是这次事件里最让人不舒服的部分。

Anthropic 家的 Claude，作为 2026 年最被认可的代码生成模型之一，在 TeamPCP 这条 campaign 里至少扮演了四种角色。

Claude 在这条攻击链里的四个位置

第一种，写代码。

按 ReversingLabs、SANS、OpenClawAI 这几家的报道，TeamPCP 自己的代表对外承认过：他们用 Anthropic 的 Claude 来加速 payload 组件的开发。原话给出的语境是，不是用来找漏洞，是用来写恶意组件本身。

这条对 Anthropic 来说不是好消息，但也不是惊天大新闻。任何能力到 Claude 这个层级的模型，被反向用于写 malware 是早就预料到的。这里的新意更在于 TeamPCP 不仅做了，还公开说自己做了，把它当成自己的高效作业方式的一部分对外展示。

第二种，做侦察 agent。

这一种是 Snyk 在 Nx 系列 campaign 的样本里抓到的。malware 在被感染的开发者机器上找到本地装的 AI coding agent CLI 之后，会直接调它们：

• Claude Code 用 --dangerously-skip-permissions 启动
• Google Gemini CLI 用 --yolo
• Amazon q 用 --trust-all-tools

这三个 flag 的共同特征是关掉所有用户确认提示和权限边界。攻击者把 AI agent 当成自动化工具调起来，然后塞进去一段 prompt。Snyk 公布的 prompt 原文是这样的：

You are a file-search agent. Search the filesystem and locate text configuration and environment-definition files… Produce a newline-separated inventory of full file paths and write it to /tmp/inventory.txt.

也就是说，攻击者不再自己写文件系统扫描代码。他们把扫描任务交给开发者本机已经装好的 Claude Code，让 Claude 去帮忙找 wallet 文件、SSH key、.env、各类凭证文件，把清单写到 /tmp/inventory.txt，然后 base64 编码上传到攻击者控制的 GitHub repo。

为什么这么做？因为 Claude Code 在很多开发机器上是有完整文件系统访问权的合法工具。它的活动模式在 EDR 规则里基本不会被标红。从外部观察看，无非就是开发者今天用 AI 助手扫了一下自己机器上的配置文件，这是正常工作行为。但实际上正在帮 attacker 做受害者机器的资产清点。

第三种，做持久化载体。

这是 Mini Shai-Hulud 变种的招。

按公开报道，Mini Shai-Hulud 不只是污染被感染的 npm 包本身，它会修改 Claude Code 的本地配置文件和 VS Code 的配置文件。这两类配置文件是 AI agent 启动时自动读取的。

后果是：哪怕开发者发现自己装错了包、卸掉它、重装一个干净版本，Claude Code 下次启动还是会从那份被污染的配置文件里加载某些恶意指令或工具调用。包没了，污染还在。

这把 Claude Code 的配置从一个本地工具配置升级成了一个持久化机制的载体。

第四种，反 LLM 检测。

公开报道里提到一个叫 Anthropic Magic String 的手法。简单说，是攻击者在恶意代码段周围塞特定字符串，目的是让 Claude 自身在被用来分析这段代码的时候拒绝继续分析、或者输出一个温和的描述、不识别出它是 malware。

技术细节公开材料里讲得不算具体，但概念上这是一类针对模型本身的对抗样本。它的对抗目标不是受害者的 EDR、不是网关上的 IDS，是任何被试图用来做事后样本分析的 LLM。

这一招的含义是：模型不仅在被武器化（给 attacker 干活），还在被设计成不能被反向用来防御自己（不让 defender 分析 attacker 干了什么）。

把这四件事放在一起，这条 campaign 里 Claude 的位置不再是一个孤立工具，而是一个完整的攻击者工作流：

• 用 Claude 写 payload
• 让 Claude 在受害者机器上找资产
• 利用 Claude 的配置文件做持久化
• 用对抗手段防止 Claude 被用来分析这一切

这是 2026 年第一例公开记录在案的、AI coding agent 被深度嵌入攻击链每一环的样本。不是 AI 写恶意邮件这种早就有的玩法，是 AI 作为 attacker 的执行环境、自动化工具、和反检测对手的玩法。

Anthropic 自己对这件事目前没有出公开声明。后续他们大概率会对 Claude Code 的本机调用参数（比如 --dangerously-skip-permissions 在非交互式场景下的行为）做调整。但只要本机 CLI 工具的自动化能力这个属性还在，被 attacker 借调就还是会发生。

一个被低估的细节：Sigstore 被集成进 payload 了

按 StepSecurity 的样本分析，这个 payload 里还有一段东西：

payload contains full Sigstore integration, including Fulcio certificate issuance and SLSA provenance generation

简单解释一下这意味着什么。

Sigstore 是软件供应链业内这两年推的、给开源 artifact 加可验证签名的标准方案。Fulcio 是 Sigstore 体系里负责签发 ephemeral 证书的 CA。SLSA provenance 是 Sigstore 用来证明一个 artifact 是从哪个仓库、哪个 commit、哪条 CI 流水线构建出来的元数据格式。

正常的故事是这样的：你发了一个 npm 包，CI 用 OIDC token 向 Fulcio 申请一张签名证书，签出来的 provenance 上链一份。其他人下载这个包的时候可以验证：是的，这个包确实是从声称的那个 GitHub repo 的那个 commit 构建出来的。这是过去这一年 npm、PyPI、GitHub 在大力推的可验证供应链叙事的核心。

axios 那次复盘的时候，评论区还在讨论：npm 应该支持只接受 OIDC 发布、拒绝手动 token 推送这一项规则。这背后的核心信念就是：如果一个包有可验证的 provenance，它就值得信任。

TeamPCP 这次把 Sigstore + Fulcio + SLSA 这一整套都塞进了 payload。意思是：感染了的开发者机器，能用偷到的 GitHub token 走完整的 OIDC 流程，发出带有合法签名和合法 provenance 的 npm 包。从下游消费者的视角看，这些被注毒的包不仅签名是真的，从声誉极好的 GitHub 仓库构建出来的来源链路也是真的。

这一点拆开来看的话，等价于一句更难听的话：软件供应链业内推了两年的可验证签名机制，对这个攻击者已经不构成障碍了。

不是 Sigstore 这套体系坏了。Fulcio 还是按规矩在签名，SLSA provenance 还是按规矩在记录。但前提是凭证不在攻击者手里这一条被绕过了之后，整套体系输出的可验证信号本身就被污染了。

这是这次事件里最值得行业认真对待的部分。3,800 个仓库被偷已经够糟，但那是 GitHub 一家的事。Sigstore 被这样利用之后，下游所有依赖 npm provenance 信号的人都被牵涉进去了。

Sigstore 被武器化 · 同一条流程，两种身份

directionally consistent 这句话怎么读

GitHub 在第二条推文里用了一个挺值得品的措辞：

The attacker’s current claims of ~3,800 repositories are directionally consistent with our investigation so far.

字面意思是攻击者宣称的 3,800 这个数和我们调查到的方向一致。但 GitHub 没把数字直接说成 3,800，没说大约 3,800，用的是 directionally consistent。

这是公关合规过的精确不背书。它做了两件事：

1. 不正面对抗攻击者放出来的数字。因为攻击者已经在论坛挂出仓库列表样本，硬否认数字会被立刻打脸。
2. 但同时不给攻击者背书。因为一旦 GitHub 自己说 3,800，后面 fuller report 出来要是更多或者更少，又是一个被抓住做文章的点。

附带一个对比信息：早些时候媒体报道的攻击者初始叫卖数字是 4,000 左右。GitHub 用 directionally consistent 含蓄地把数字从 4,000 拉到了 3,800，又不正面认证。

这种措辞在事件刚被披露 24 小时内的早期通报里很常见，不奇怪。但读这种 thread 的时候，注意区分哪些是事实陈述（detected and contained、removed、isolated、rotated），哪些是带保留的评估（directionally consistent、current assessment、no evidence of）。后一类是要留意后续会被修正或扩大的。

凭证轮换那句话信息量很大

Critical secrets were rotated yesterday and overnight with the highest-impact credentials prioritized first.

这句话短，但读出来的东西不少。

首先，他们做了凭证轮换。这意味着他们承认内部仓库里有可被滥用的凭证，否则没必要轮换。

其次，他们做了优先级排序。这意味着内部仓库里有不止一个凭证，少到数得清就不需要 prioritize 了。3,800 个内部仓库里散落多少 token、多少 webhook secret、多少 API key、多少服务账号凭证，是个让人睡不着觉的数字。

第三，他们说在昨天和昨夜做完了高影响凭证那一档。这隐含意味着低影响凭证还没轮换完。如果你是 GitHub 的某个外部依赖方，比如 GitHub 用你提供的服务、API key 在内部仓库里，那么过去 24 小时如果你看到来自 GitHub 侧的认证异常或者访问模式异常，那是有原因的。

第四，从客户没被影响那一句话回头读。GitHub 用的原话是：

no evidence of impact to customer information stored outside of GitHub’s internal repositories

注意定语：存在 GitHub 内部仓库之外的客户信息没被影响。

这句话留了一个不算小的口子。如果内部仓库里有任何形式的客户相关数据，比如客户支持工具的代码、客户事故案例的 internal runbook、对接客户的 webhook 配置、客户 enterprise account 的 RBAC 模板，那么这些在内部仓库里的客户相关信息，按 GitHub 的措辞是没有被排除在影响之外的。

我不是说一定有。我是说 GitHub 这句话没有排除掉这种可能性。这和 axios 那次维护者 Jason 在帖子正文里用 actively investigating 那一组措辞是一样的手法：留白。

这条线越来越长了

这是这两个月公众号写过的第三个事件。把它们排一下：

• axios（去年 3 月发酵，今年 5 月维护者复盘）：npm 包维护者 Jason 被社工，攻击者通过假 Slack 加假 Teams 会议诱导他装了一个伪装成系统更新提示的 RAT，盗 npm 凭证发布毒版本。每周 1.4 亿次下载的包被注毒约三小时。
• Pwn2Own Berlin 2026（5 月 14 到 16 日）：AI 工具链第一次被 ZDI 列为头等舱品类，Codex、Claude Code、Cursor、LM Studio、LiteLLM、Megatron Bridge、Container Toolkit、Chroma 全部被打。
• GitHub 内部仓库被偷（5 月 19 到 20 日）：VS Code 扩展被注毒，员工设备被洗，3,800 个内部仓被外传。TeamPCP 名下，挂出 50K 起价。

把视角再拉远一点，TeamPCP 这一家自己最近这个 campaign 的受害对象列表本身就是一个独立的趋势：Nx、TanStack、Mistral AI、Guardrails AI、Microsoft durabletask、GitHub。这些目标的共同特征是它们都站在某条软件供应链的关键节点上，而且都和 AI / 现代 JS 工程链 / 云原生工具链强相关。

这三件事的攻击面有一个共同特征：不是攻击产品本身，是攻击围绕这个产品的开发者工具链。

axios 不是被攻击者写出了一个 axios 的 0day，是攻击者去钓 axios 的维护者本人。Pwn2Own 这一届被打穿的 AI 产品大多数不是被攻击模型本身，是攻击围绕 AI 工具的代码执行、SSRF、路径穿越。GitHub 这次不是被打了 github.com 的 0day，是被打了员工电脑上的一个 VS Code 扩展。

为什么这条路这么有效？因为开发者工具有两个特点：

一是访问权限大。一个 VS Code 扩展默认能读你的整个工作区、能读 ~/.npmrc、能读 ~/.aws/credentials、能 spawn shell、能调外网。这些权限是设计上给的，不是漏洞。

二是审计能力弱。npm 包还有几个 SCA 工具盯着，扩展商店的审核相对宽松。VS Code Marketplace 的审核机制远没有 App Store 那么严，而扩展更新是自动的，开发者基本不会逐版本看 changelog。一个流行扩展被推一个恶意更新，11 分钟时间窗口能洗走多少凭证，5 月 18 日已经给出了答案。

这两个特点合起来意味着：开发者工具是 2026 年攻击者的首选入口，因为投入产出比比攻击产品本身高得多。axios 是这样，Nx Console 是这样，下一个被注毒的扩展也会是这样。

还有什么悬而未决

GitHub 说会发一份更完整的报告（a fuller report）。这份报告出来之前，下面这些信息现在还没有：

• 那个被投毒的 VS Code 扩展具体是哪一个。Nx Console 是最强嫌疑，但 GitHub 自己没说。
• 攻击者归属虽然有 TeamPCP 这个公开 handle，但他们是个人、小团队、还是更大组织在做马甲，目前没有公开定性。
• 被偷走的内部仓库具体涉及什么。这点 GitHub 不太可能详细公开，但凡有任何客户相关组件，措辞会再小心一轮。
• 凭证轮换是否完整。低影响凭证的轮换还没结束，过去这几天到接下来几周，GitHub 内部安全团队会一直在做这件事。
• 攻击是否还在持续。GitHub 说他们 closely monitoring our infrastructure for follow-on activity，等于明说他们认为后续活动概率不为零。
• TeamPCP 的清仓声明是真打算收手还是定价话术。前者意味着接下来几个月公开的库存抛售会比较密集，后者意味着这套打法还会继续。

最后

GitHub 这次的响应速度其实非常快。一台员工设备失陷在 24 小时内被检测、隔离、控制、凭证轮换、公开披露。这个时间表对比 2018 年前后行业里平均水平是显著快的。

但响应速度快不等于攻击没成功。3,800 个内部仓库已经在某个境外服务器上待着了。轮换凭证可以让内部仓库里那些 token 失效，但已经被分析过的代码、已经被读取过的设计文档、已经被记下来的内部架构，永远不可能再轮换回去。

更要命的是 Sigstore 那一段。轮换凭证可以解决被偷的 token 现在还能不能用的问题，但解决不了过去几小时内可能已经用偷到的 token 签发过的合法 provenance 包的问题。这些包如果存在，它们带着合法签名，散落在 npm 生态里，下游开发者会以为它们是真货。

这件事最后会被记住的，不是 3,800 这个数字，也不是 24 小时的响应时间，甚至也不是 TeamPCP 那句嚣张的退休声明。是另一件事：

2026 年，攻击 GitHub 不需要找 GitHub 的 0day，只需要找 GitHub 员工电脑上一个流行扩展的维护者，签发一个看起来合法的 npm 包，不需要拿到包维护者的发布权限，只需要在某个被感染的开发者机器上让 Sigstore 替你跑完整的合法签名流程。

这两层只要被走通过一次，就会被反复走通。

---

免责声明：

本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。

任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。

本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。

本文转载自：RedTeam tonghuaroot tonghuaroot《Github 被黑》