The Story of a Security Audit Google Called "Infeasible" to Fix
On February 11, 2026, I submitted a comprehensive security audit of the Google Antigravity IDE (v1.107.0) to the Google VRP. I didn't just find a bug; I mapped out 70+ vulnerabilities that effectively turn a developer's machine into an open door for anyone.
Google’s response? "Infeasible to fix."
Fast forward to today, and we are seeing a massive wave of 403 Forbidden and 400 Bad Request errors. It seems Google decided that instead of fixing the architecture, it's easier to "fix" the users by banning them.
1. The Performance Paradox: RAM Hunger
Before we even get to the security, let's talk about the DX (Developer Experience). Antigravity was marketed as a high-speed AI-native IDE. In reality, it shares the worst traits of early Chrome:
Memory Leaks: The longer the session, the more RAM it consumes.
Degradation: Performance drops significantly after a few hours of work, forcing restarts.
It feels like security and optimization were both sacrificed for "speed of development," but the result is neither fast nor secure.
2. Technical Deep Dive: The Security "Sieve"
Here are the most critical architectural flaws I reported, which Google currently refuses to track as security bugs:
A. CSRF Token Leak via WMI (The Master Key)
Google uses a csrfToken to secure gRPC calls. However, they pass this token as a command-line argument when launching extension_server.exe.
The Vulnerability: Any process on the system (even without admin privileges) can read the command line of other processes.
The Attack: A simple WMI query (e.g., Get-CimInstance Win32_Process) instantly reveals the token.
Impact: The entire authentication layer is compromised before the user even types a single line of code.
B. Named Pipe without ACLs (The Open Door)
The IPC (Inter-Process Communication) happens through Named Pipes (like \.\pipe\antigravity_ipc).
The Vulnerability: These pipes have no Access Control Lists (ACLs).
The Attack: Once an attacker has the token from the WMI leak, they can connect to the pipe directly and send commands to the extension server, bypassing the IDE interface entirely.
C. Exfiltrating the "Crown Jewels"
My PoCs (poc_crown_jewels.py) proved that these flaws allow for the instant theft of:
SSH Keys & Git Configs
Cloud Tokens: AWS, Azure, and GCloud credentials.
Master DPAPI keys and Chrome session cookies.
3. The "Infeasible" Response
Initially, Google VRP assigned this a P2 Priority. But they later downgraded it to "Infeasible," arguing that:
"Since the attacker already has local access, we do not track these as security bugs."
This is a dangerous mindset in 2026. In an era of Supply Chain attacks, where a single malicious npm or pip package can execute local code, the IDE should be a fortress, not a playground. If your IDE doesn't protect your credentials from other local processes, it is failing its most basic security job.
4. From Technical Debt to Mass Bans
Instead of re-architecting the IPC or implementing proper sandboxing, Google has initiated a "scorched earth" policy. Over the last few days, thousands of users—including those on the Antigravity Ultra plan—have been banned.
The errors 403 and 400 aren't just technical glitches; they are the sound of a corporation trying to silence the fallout of a broken product. They are banning researchers and power users because it's cheaper than admitting the flagship AI IDE is architecturally flawed.
Conclusion: We Need Computational Immunity
This is why we are shifting our focus to the Direct Intent Protocol (DIP) and RLM-Toolkit. We don't need "Paper Fences" (WAFs and corporate ToS). We need security that is baked into the physics of the computation itself.
If you’ve been hit by the recent ban wave or have thoughts on the "Local Access" security debate, let's discuss in the comments.
Full Technical Report & PoCs available on my GitHub Gist.
Top comments (0)