尧图网页设计 
1. FakeGit 的诱导链路Codex 为什么会推荐这些仓库FakeGit 事件曝光后最让人头痛的不是「知道有恶意仓库」而是检测脚本到手也未必跑得起来要生成 GitHub Token、装 Python 依赖、把仓库全称一个个填进列表跑完还要人肉核对输出。更要命的是Codex 这类 AI 编程工具本身就可能被高仿仓库的标签骗到。这次我把 Codex 的 Base URL 指到 TaoTokenhttps://taotoken.net/?utm_sourcetaotoken_aicg_blog_end让它照着 FakeGit 检测脚本的逻辑去读仓库清单、算风险分整个过程顺了很多。下面按「诱导链路 → 脚本特征 → Codex 接入 → 实测跑通 → 排障 → 对账」的顺序展开仓库清单可以直接替换成你正在怀疑的那批。1.1 高仿账号与标签投毒攻击者的做法是「高仿到细枝末节」。他们复刻了社区里一个 6700 多 Star 的 Claude 技能聚合仓库连项目简介、目录结构都一起抄再刷出一批 Star 和 Fork让仓库看起来像长期维护的成熟项目。账号层面同样用了形近字套路把正规开发者名字最后一位换成另一个相似字符主页资料、历史项目排版全部照搬。普通用户扫一眼很难察觉AI 的检索排序也只看匹配度、Star 数和更新时间自然把这类仓库排到前面。名字和标签是这套骗术的定向瞄准。恶意仓库统一打上 mcp-server、ai-skill、claude-plugin、data-integration 这些标签正好是 Codex 在回答「帮我找一个 MCP 服务器」「有什么好用的 AI 技能插件」时会去检索的关键词。Codex 为了给出可用的推荐会优先抓取标签贴合、文档结构完整的项目而这正好踩进攻击者预设的检索陷阱。1.2 从「AI 推荐」到「一键部署 ZIP」README 的诱导设计更隐蔽。恶意仓库首页写满了企业级能力说明、快速上手步骤、场景案例排版比很多正规项目还整齐唯一反常的地方是最后一步不让你源码编译而是强调「一键下载 Release ZIP开箱即用」。这个 ZIP 里没有 MCP 服务源码只包含 Windows 批处理启动脚本、被改过的 LuaJIT 运行环境和混淆后的 Lua 载荷。双击后窗口自动隐藏随后部署 SmartLoader 持久化加载器再落地 StealC 窃密木马浏览器 Cookie、SSH 密钥、云 API Key 都会被静默打包回传。对照这条链路检测脚本的切入点就很清楚了高仿仓库躲不开「标签撞车、创建时间扎堆、只有 Release 没有源码」这三个动作。只要这三个特征能被量化就能用脚本批量排查而不是靠肉眼刷仓库页面。2. 检测脚本拆解三个特征怎么凑出 50 分2.1 特征权重与判定逻辑原脚本的判定逻辑不是简单黑名单而是给每个仓库打分。分数来源是三个独立特征每个特征只负责一段攻击行为。用表格梳理如下检测特征加分对应攻击行为仓库名/标签命中 mcp-server、ai-skill、claude-skill、databricks-mcp、jenkins-mcp30定向投喂 AI 检索抢占推荐位创建时间在高危窗口且 Star 数不足 10040攻击高峰期批量注册缺乏真实历史沉淀仓库无源码Release 里只有 ZIP 包30把恶意载荷压缩隐藏诱导直接下载运行把阈值设在 50意味着至少两个特征同时命中才会被判定为高危。单靠 MCP 标签不能定罪因为正规 MCP 服务也这么命名只有「标签 新建低星」或「标签 无源码 ZIP」同时成立才符合 FakeGit 的仓库画像。判定出来的结果直接标成「是建议立即删除溯源」不再交给开发者二次判断。2.2 可运行的批量检测脚本下面是一个可直接运行的版本仓库清单从外部文件读取逻辑和原脚本保持一致。你可以保存为 fakegit_check.py也可以把这段逻辑直接丢给 Codex 改写。# fakegit_check.py # 用法: python fakegit_check.py repos.txt import requests import sys import time # 在 GitHub Settings - Developer settings - Personal access tokens 生成 GITHUB_TOKEN RISK_KEYWORDS [mcp-server, ai-skill, claude-skill, databricks-mcp, jenkins-mcp] RISK_MONTHS {2026-03, 2026-04} SCORE_THRESHOLD 50 def check_repo(full_name): score 0 reasons [] low full_name.lower() if any(kw in low for kw in RISK_KEYWORDS): score 30 reasons.append(命中 FakeGit 常用 MCP/AI 技能关键词) headers {Authorization: ftoken {GITHUB_TOKEN}} if GITHUB_TOKEN else {} r requests.get(fhttps://api.github.com/repos/{full_name}, headersheaders, timeout10) if r.status_code ! 200: return {repo: full_name, score: score, reasons: reasons [仓库不存在或访问失败], danger: False} info r.json() created info.get(created_at, )[:7] stars info.get(stargazers_count, 0) if created in RISK_MONTHS and stars 100: score 40 reasons.append(f{created} 新建低星仓库当前 Star{stars}) releases requests.get( fhttps://api.github.com/repos/{full_name}/releases, headersheaders, timeout10).json() if releases: assets releases[0].get(assets, []) has_zip any(a[name].endswith(.zip) for a in assets) has_source info.get(has_source_code, True) if has_zip and not has_source: score 30 reasons.append(无源码仅存在 Release ZIP 载荷) return {repo: full_name, score: score, reasons: reasons, danger: score SCORE_THRESHOLD} if len(sys.argv) 2: sys.exit(请传入仓库清单文件例如: python fakegit_check.py repos.txt) with open(sys.argv[1]) as f: repos [line.strip() for line in f if line.strip()] for repo in repos: result check_repo(repo) print(f\n【检测仓库】{result[repo]}) print(f【风险评分】{result[score]}) print(f【风险详情】{result[reasons]}) print(f【高危判定】{是建议立即删除溯源 if result[danger] else 安全无 FakeGit 特征}) time.sleep(1)运行时先写好 repos.txt再执行python fakegit_check.py repos.txt。GITHUB_TOKEN 在脚本开头留空也能跑但未认证的 GitHub API 请求限额很低仓库一多就会被打回 403建议填个人 Token。2.3 别忘了GitHub Token 和 TaoToken 各管一摊这里要分清两个东西检测脚本调的是 GitHub API所以 GitHub Token 仍旧需要你自己生成TaoToken 解决的是 Codex 的模型通道问题不替代检测脚本本身。换句话说TaoToken 只保证 Codex 能稳定拿到模型回复危险仓库的 50 分判定标准还是原脚本那套风险评分没有因为换了通道就变松。3. 把 Codex 的 Base URL 指到 TaoToken3.1 准备材料拿 Key 和确认模型 ID打开 TaoToken 注册账号在控制台创建 API Key得到一串 YOUR_API_KEY。创建 Key 的页面和模型广场在同一个控制台里模型 ID 以模型广场当时显示的列表为准不要凭记忆填。这一步完成后你手里有两样东西一个以 YOUR_API_KEY 形态存在的密钥字符串以及一个确切的模型 ID。3.2 ~/.codex/config.toml 的接入配置Codex 的模型供应商配置集中在一个文件~/.codex/config.toml。先备份原有文件然后写入# ~/.codex/config.toml model 模型广场显示的 Codex 模型 ID model_provider taotoken [model_providers.taotoken] name TaoToken base_url https://taotoken.net/api env_key TAOTOKEN_API_KEY然后让 Codex 进程读到这份环境变量export TAOTOKEN_API_KEYYOUR_API_KEY注意两处细节base_url 是 https://taotoken.net/api末尾没有 /v1Codex 会按自己的协议在请求里拼接路径YOUR_API_KEY 要完整替换成你刚才从控制台复制的那串字符而不是把这个占位符原样留到配置文件里。4. 在 Codex 里跑通 FakeGit 仓库检测4.1 准备仓库清单 repos.txt先把要检测的仓库全称写进 repos.txt每行一个格式是 owner/repo。例如xxx/xxx-mcp-server xxx/xxx-ai-skill也可以把 Codex 正在用的、你怀疑来源不明的 MCP 项目都丢进去。注意仓库全称大小写敏感拼错会在后续检测里直接返回「仓库不存在或访问失败」。4.2 给 Codex 的指令给 Codex 的指令可以这样写读取 repos.txt 里的每个仓库全称按 FakeGit 检测逻辑计算风险分 1. 仓库名含 mcp-server、ai-skill、claude-skill、databricks-mcp、jenkins-mcp加 30 分 2. 创建时间在 2026-03 到 2026-04 之间且 Star 数低于 100加 40 分 3. 仓库没有源码、Release 里只有 ZIP 包加 30 分。 总分 50 分及以上标记为高危输出表格并列出每个仓库命中的风险原因。Codex 只负责生成和解释代码执行仍发生在你的本地终端里。建议让它把脚本保存为 fakegit_check.py你自己运行python fakegit_check.py repos.txt再把输出贴回对话让 Codex 对照分析。这样既用了 AI 的代码能力又不会让 Codex 直接操作你机器上其他业务环境。4.3 期望输出长什么样脚本跑完后的输出会像这样【检测仓库】xxx/xxx-mcp-server 【风险评分】70 【风险详情】[命中 FakeGit 常用 MCP/AI 技能关键词, 无源码仅存在 Release ZIP 载荷] 【高危判定】是建议立即删除溯源高危仓库标记出来后不要停在「知道了」这一步还要按原文的 MCP 核验清单处理溯源作者身份、检查源码完整性、在沙箱里预运行。仓库列表和模型 ID 以 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_end 模型广场以及你自己写的 repos.txt 为准。5. 排障从 401 到拿到风险报告5.1 Codex 接 TaoToken 失败的三个典型原因这次踩坑下来九成是这三个原因。第一个是 401。YOUR_API_KEY 没有被替换或者环境变量没在当前终端 export。config.toml 里 env_key 写的是 TAOTOKEN_API_KEY那么 shell 里就要有同名变量不要在 .zshrc 里改完就忘Codex 当前进程读不到。第二个是 404。base_url 被写成了 https://taotoken.net/api/v1。TaoToken 的接入地址是 https://taotoken.net/api末尾不要多拼 /v1多余路径会让请求打不到模型接口。第三个是模型 ID 不存在。Codex 会按 config.toml 的 model 字段发起请求如果你填了一个模型广场上没有的型号返回的错误信息通常指向模型名称。去模型广场核对当前列表即可。5.2 检测脚本自身的报错脚本自身的问题集中在两类。一类是「仓库不存在或访问失败」多半是 GitHub Token 没填导致接口限流也可能是仓库全称拼错或者仓库已改名。另一类是全部仓库评分为 0先看看 repos.txt 里有没有空行、行尾空格再看 GitHub Token 是否有 public 仓库读取权限。这里补一句安全边界不要让 Codex 直接连到业务服务器去执行检测脚本。检测动作一律在你自己本地终端完成Codex 只负责生成脚本、解释输出和给出处理建议。6. 跑通之后去控制台对一下调用6.1 先发一条测试消息对账配置保存后先到 TaoToken 模型对话 用同一把 Key 发一条测试消息确认 Key 和模型 ID 都没问题。之后再回 Codex 跑一遍 repos.txt控制台里就能看到对应的调用记录。这样排障时能立刻分清是模型通道的问题还是检测脚本的问题。6.2 查套餐与 Key 管理如果你打算把这种检测变成每周固定的安全习惯可以看下 Coding Plan 的套餐是否够用新增密钥在 控制台 API Keys 管理按项目分把不同环境的 Key 分开避免一把 Key 到处贴。TaoToken 在这里只负责把 Codex 的模型通道换成一条统一、可按量查看的路径FakeGit 的 50 分判定标准没有变。跑完这轮之后我自己的习惯是凡是被脚本标成高危的仓库一律先隔离下架再按原文的 MCP 核验清单做二次确认而不是直接删掉完事。 FakeGit 检测脚本，把 Codex 的 Base URL 改到 TaoToken 后执行
1. FakeGit 的诱导链路Codex 为什么会推荐这些仓库FakeGit 事件曝光后最让人头痛的不是「知道有恶意仓库」而是检测脚本到手也未必跑得起来要生成 GitHub Token、装 Python 依赖、把仓库全称一个个填进列表跑完还要人肉核对输出。更要命的是Codex 这类 AI 编程工具本身就可能被高仿仓库的标签骗到。这次我把 Codex 的 Base URL 指到 TaoTokenhttps://taotoken.net/?utm_sourcetaotoken_aicg_blog_end让它照着 FakeGit 检测脚本的逻辑去读仓库清单、算风险分整个过程顺了很多。下面按「诱导链路 → 脚本特征 → Codex 接入 → 实测跑通 → 排障 → 对账」的顺序展开仓库清单可以直接替换成你正在怀疑的那批。1.1 高仿账号与标签投毒攻击者的做法是「高仿到细枝末节」。他们复刻了社区里一个 6700 多 Star 的 Claude 技能聚合仓库连项目简介、目录结构都一起抄再刷出一批 Star 和 Fork让仓库看起来像长期维护的成熟项目。账号层面同样用了形近字套路把正规开发者名字最后一位换成另一个相似字符主页资料、历史项目排版全部照搬。普通用户扫一眼很难察觉AI 的检索排序也只看匹配度、Star 数和更新时间自然把这类仓库排到前面。名字和标签是这套骗术的定向瞄准。恶意仓库统一打上 mcp-server、ai-skill、claude-plugin、data-integration 这些标签正好是 Codex 在回答「帮我找一个 MCP 服务器」「有什么好用的 AI 技能插件」时会去检索的关键词。Codex 为了给出可用的推荐会优先抓取标签贴合、文档结构完整的项目而这正好踩进攻击者预设的检索陷阱。1.2 从「AI 推荐」到「一键部署 ZIP」README 的诱导设计更隐蔽。恶意仓库首页写满了企业级能力说明、快速上手步骤、场景案例排版比很多正规项目还整齐唯一反常的地方是最后一步不让你源码编译而是强调「一键下载 Release ZIP开箱即用」。这个 ZIP 里没有 MCP 服务源码只包含 Windows 批处理启动脚本、被改过的 LuaJIT 运行环境和混淆后的 Lua 载荷。双击后窗口自动隐藏随后部署 SmartLoader 持久化加载器再落地 StealC 窃密木马浏览器 Cookie、SSH 密钥、云 API Key 都会被静默打包回传。对照这条链路检测脚本的切入点就很清楚了高仿仓库躲不开「标签撞车、创建时间扎堆、只有 Release 没有源码」这三个动作。只要这三个特征能被量化就能用脚本批量排查而不是靠肉眼刷仓库页面。2. 检测脚本拆解三个特征怎么凑出 50 分2.1 特征权重与判定逻辑原脚本的判定逻辑不是简单黑名单而是给每个仓库打分。分数来源是三个独立特征每个特征只负责一段攻击行为。用表格梳理如下检测特征加分对应攻击行为仓库名/标签命中 mcp-server、ai-skill、claude-skill、databricks-mcp、jenkins-mcp30定向投喂 AI 检索抢占推荐位创建时间在高危窗口且 Star 数不足 10040攻击高峰期批量注册缺乏真实历史沉淀仓库无源码Release 里只有 ZIP 包30把恶意载荷压缩隐藏诱导直接下载运行把阈值设在 50意味着至少两个特征同时命中才会被判定为高危。单靠 MCP 标签不能定罪因为正规 MCP 服务也这么命名只有「标签 新建低星」或「标签 无源码 ZIP」同时成立才符合 FakeGit 的仓库画像。判定出来的结果直接标成「是建议立即删除溯源」不再交给开发者二次判断。2.2 可运行的批量检测脚本下面是一个可直接运行的版本仓库清单从外部文件读取逻辑和原脚本保持一致。你可以保存为 fakegit_check.py也可以把这段逻辑直接丢给 Codex 改写。# fakegit_check.py # 用法: python fakegit_check.py repos.txt import requests import sys import time # 在 GitHub Settings - Developer settings - Personal access tokens 生成 GITHUB_TOKEN RISK_KEYWORDS [mcp-server, ai-skill, claude-skill, databricks-mcp, jenkins-mcp] RISK_MONTHS {2026-03, 2026-04} SCORE_THRESHOLD 50 def check_repo(full_name): score 0 reasons [] low full_name.lower() if any(kw in low for kw in RISK_KEYWORDS): score 30 reasons.append(命中 FakeGit 常用 MCP/AI 技能关键词) headers {Authorization: ftoken {GITHUB_TOKEN}} if GITHUB_TOKEN else {} r requests.get(fhttps://api.github.com/repos/{full_name}, headersheaders, timeout10) if r.status_code ! 200: return {repo: full_name, score: score, reasons: reasons [仓库不存在或访问失败], danger: False} info r.json() created info.get(created_at, )[:7] stars info.get(stargazers_count, 0) if created in RISK_MONTHS and stars 100: score 40 reasons.append(f{created} 新建低星仓库当前 Star{stars}) releases requests.get( fhttps://api.github.com/repos/{full_name}/releases, headersheaders, timeout10).json() if releases: assets releases[0].get(assets, []) has_zip any(a[name].endswith(.zip) for a in assets) has_source info.get(has_source_code, True) if has_zip and not has_source: score 30 reasons.append(无源码仅存在 Release ZIP 载荷) return {repo: full_name, score: score, reasons: reasons, danger: score SCORE_THRESHOLD} if len(sys.argv) 2: sys.exit(请传入仓库清单文件例如: python fakegit_check.py repos.txt) with open(sys.argv[1]) as f: repos [line.strip() for line in f if line.strip()] for repo in repos: result check_repo(repo) print(f\n【检测仓库】{result[repo]}) print(f【风险评分】{result[score]}) print(f【风险详情】{result[reasons]}) print(f【高危判定】{是建议立即删除溯源 if result[danger] else 安全无 FakeGit 特征}) time.sleep(1)运行时先写好 repos.txt再执行python fakegit_check.py repos.txt。GITHUB_TOKEN 在脚本开头留空也能跑但未认证的 GitHub API 请求限额很低仓库一多就会被打回 403建议填个人 Token。2.3 别忘了GitHub Token 和 TaoToken 各管一摊这里要分清两个东西检测脚本调的是 GitHub API所以 GitHub Token 仍旧需要你自己生成TaoToken 解决的是 Codex 的模型通道问题不替代检测脚本本身。换句话说TaoToken 只保证 Codex 能稳定拿到模型回复危险仓库的 50 分判定标准还是原脚本那套风险评分没有因为换了通道就变松。3. 把 Codex 的 Base URL 指到 TaoToken3.1 准备材料拿 Key 和确认模型 ID打开 TaoToken 注册账号在控制台创建 API Key得到一串 YOUR_API_KEY。创建 Key 的页面和模型广场在同一个控制台里模型 ID 以模型广场当时显示的列表为准不要凭记忆填。这一步完成后你手里有两样东西一个以 YOUR_API_KEY 形态存在的密钥字符串以及一个确切的模型 ID。3.2 ~/.codex/config.toml 的接入配置Codex 的模型供应商配置集中在一个文件~/.codex/config.toml。先备份原有文件然后写入# ~/.codex/config.toml model 模型广场显示的 Codex 模型 ID model_provider taotoken [model_providers.taotoken] name TaoToken base_url https://taotoken.net/api env_key TAOTOKEN_API_KEY然后让 Codex 进程读到这份环境变量export TAOTOKEN_API_KEYYOUR_API_KEY注意两处细节base_url 是 https://taotoken.net/api末尾没有 /v1Codex 会按自己的协议在请求里拼接路径YOUR_API_KEY 要完整替换成你刚才从控制台复制的那串字符而不是把这个占位符原样留到配置文件里。4. 在 Codex 里跑通 FakeGit 仓库检测4.1 准备仓库清单 repos.txt先把要检测的仓库全称写进 repos.txt每行一个格式是 owner/repo。例如xxx/xxx-mcp-server xxx/xxx-ai-skill也可以把 Codex 正在用的、你怀疑来源不明的 MCP 项目都丢进去。注意仓库全称大小写敏感拼错会在后续检测里直接返回「仓库不存在或访问失败」。4.2 给 Codex 的指令给 Codex 的指令可以这样写读取 repos.txt 里的每个仓库全称按 FakeGit 检测逻辑计算风险分 1. 仓库名含 mcp-server、ai-skill、claude-skill、databricks-mcp、jenkins-mcp加 30 分 2. 创建时间在 2026-03 到 2026-04 之间且 Star 数低于 100加 40 分 3. 仓库没有源码、Release 里只有 ZIP 包加 30 分。 总分 50 分及以上标记为高危输出表格并列出每个仓库命中的风险原因。Codex 只负责生成和解释代码执行仍发生在你的本地终端里。建议让它把脚本保存为 fakegit_check.py你自己运行python fakegit_check.py repos.txt再把输出贴回对话让 Codex 对照分析。这样既用了 AI 的代码能力又不会让 Codex 直接操作你机器上其他业务环境。4.3 期望输出长什么样脚本跑完后的输出会像这样【检测仓库】xxx/xxx-mcp-server 【风险评分】70 【风险详情】[命中 FakeGit 常用 MCP/AI 技能关键词, 无源码仅存在 Release ZIP 载荷] 【高危判定】是建议立即删除溯源高危仓库标记出来后不要停在「知道了」这一步还要按原文的 MCP 核验清单处理溯源作者身份、检查源码完整性、在沙箱里预运行。仓库列表和模型 ID 以 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_end 模型广场以及你自己写的 repos.txt 为准。5. 排障从 401 到拿到风险报告5.1 Codex 接 TaoToken 失败的三个典型原因这次踩坑下来九成是这三个原因。第一个是 401。YOUR_API_KEY 没有被替换或者环境变量没在当前终端 export。config.toml 里 env_key 写的是 TAOTOKEN_API_KEY那么 shell 里就要有同名变量不要在 .zshrc 里改完就忘Codex 当前进程读不到。第二个是 404。base_url 被写成了 https://taotoken.net/api/v1。TaoToken 的接入地址是 https://taotoken.net/api末尾不要多拼 /v1多余路径会让请求打不到模型接口。第三个是模型 ID 不存在。Codex 会按 config.toml 的 model 字段发起请求如果你填了一个模型广场上没有的型号返回的错误信息通常指向模型名称。去模型广场核对当前列表即可。5.2 检测脚本自身的报错脚本自身的问题集中在两类。一类是「仓库不存在或访问失败」多半是 GitHub Token 没填导致接口限流也可能是仓库全称拼错或者仓库已改名。另一类是全部仓库评分为 0先看看 repos.txt 里有没有空行、行尾空格再看 GitHub Token 是否有 public 仓库读取权限。这里补一句安全边界不要让 Codex 直接连到业务服务器去执行检测脚本。检测动作一律在你自己本地终端完成Codex 只负责生成脚本、解释输出和给出处理建议。6. 跑通之后去控制台对一下调用6.1 先发一条测试消息对账配置保存后先到 TaoToken 模型对话 用同一把 Key 发一条测试消息确认 Key 和模型 ID 都没问题。之后再回 Codex 跑一遍 repos.txt控制台里就能看到对应的调用记录。这样排障时能立刻分清是模型通道的问题还是检测脚本的问题。6.2 查套餐与 Key 管理如果你打算把这种检测变成每周固定的安全习惯可以看下 Coding Plan 的套餐是否够用新增密钥在 控制台 API Keys 管理按项目分把不同环境的 Key 分开避免一把 Key 到处贴。TaoToken 在这里只负责把 Codex 的模型通道换成一条统一、可按量查看的路径FakeGit 的 50 分判定标准没有变。跑完这轮之后我自己的习惯是凡是被脚本标成高危的仓库一律先隔离下架再按原文的 MCP 核验清单做二次确认而不是直接删掉完事。