为什么 Google Antigravity 是一座建筑纸牌屋：70 多个漏洞与大规模封禁
Source: Dev.to
一个被 Google 称为“不可行”修复的安全审计故事
在 2026 年 2 月 11 日，我向 Google VRP 提交了对 Google Antigravity IDE (v1.107.0) 的全面安全审计。审计发现了 70 多个漏洞，这些漏洞实际上把开发者的机器变成了任何人都可以随意进入的敞开大门。
Google 的回应？“不可行，无法修复。”
快进到今天，大量 403 Forbidden 与 400 Bad Request 错误正不断出现。看起来 Google 选择“修复”用户——通过封禁他们——而不是解决架构缺陷。
性能悖论：对 RAM 的贪婪
- 内存泄漏 – 会话运行时间越长，消耗的 RAM 越多。
- 性能衰退 – 工作数小时后性能显著下降，迫使频繁重启。
感觉安全性和优化都被牺牲在了“开发速度”之上，导致产品既不快也不安全。
技术深度剖析：安全“筛子”
A. 通过 WMI 泄露 CSRF Token（主钥匙）
漏洞
系统上的任何进程（即使没有管理员权限）都可以读取其他进程的命令行。
攻击
一个简单的 WMI 查询即可立即获取 token：
Get-CimInstance Win32_Process | Where-Object { $_.CommandLine -match "csrf_token" }影响
在用户甚至还未敲下第一行代码之前，整个认证层就已经被攻破。
B. 没有 ACL 的命名管道（敞开的门）
漏洞
IDE 创建的命名管道未设置访问控制列表（ACL）。
攻击
攻击者在从 WMI 泄漏中获取 token 后，可直接连接管道并向扩展服务器发送指令，完全绕过 IDE 界面。
C. 盗取“皇冠上的宝石”
- SSH 密钥 & Git 配置
- 云令牌 – AWS、Azure、GCP 凭证
- DPAPI 主密钥 与 Chrome 会话 Cookie
任何获取到受损 token 的本地进程都可以收集这些敏感资产。
“不可行”的回应
“既然攻击者已经拥有本地访问权限，我们不将这些归类为安全漏洞。”
这种思维在 2026 年是极其危险的。在供应链攻击的时代——单个恶意的 npm 或 pip 包就能执行本地代码——IDE 应该是堡垒，而不是游乐场。如果 IDE 不能保护你的凭证不被其他本地进程窃取，那么它已经失去了最基本的安全职责。
从技术债务到大规模封禁
403 与 400 错误并非单纯的技术故障；它们是公司试图压制破损产品后果的声音。研究者和高级用户被封禁，是因为这比承认旗舰 AI IDE 在架构上有缺陷更便宜。
结论：我们需要计算免疫力
如果你受到近期封禁浪潮的影响，或对“本地访问”安全争论有看法，欢迎在评论区讨论。
完整技术报告与 PoC 已在我的 GitHub Gist 上提供。