Why Google Antigravity is an Architectural House of Cards: 70+ Vulnerabilities & Mass Bans
Source: Dev.to
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. The audit identified 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, a massive wave of 403 Forbidden and 400 Bad Request errors is surfacing. It appears Google chose to “fix” the users—by banning them—rather than addressing the architectural flaws.
The Performance Paradox: RAM Hunger
- Memory Leaks – The longer a session runs, the more RAM it consumes.
- Degradation – Performance drops significantly after a few hours of work, forcing frequent restarts.
It feels as though both security and optimization were sacrificed for “speed of development,” resulting in a product that is neither fast nor secure.
Technical Deep Dive: The Security “Sieve”
A. CSRF Token Leak via WMI (The Master Key)
Vulnerability
Any process on the system (even without admin privileges) can read the command line of other processes.
Attack
A simple WMI query reveals the token instantly:
Get-CimInstance Win32_Process | Where-Object { $_.CommandLine -match "csrf_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)
Vulnerability
The IDE’s named pipes are created without Access Control Lists (ACLs).
Attack
Once an attacker obtains 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”
- SSH keys & Git configs
- Cloud tokens – AWS, Azure, and GCP credentials
- Master DPAPI keys and Chrome session cookies
These sensitive assets can be harvested by any local process that gains access to the compromised token.
The “Infeasible” Response
“Since the attacker already has local access, we do not track these as security bugs.”
This mindset is dangerous 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 an IDE cannot protect your credentials from other local processes, it fails its most basic security job.
From Technical Debt to Mass Bans
The 403 and 400 errors are not merely technical glitches; they are the sound of a corporation trying to silence the fallout of a broken product. Researchers and power users are being banned because it is cheaper than admitting that the flagship AI IDE is architecturally flawed.
Conclusion: We Need Computational Immunity
If you’ve been affected by the recent ban wave or have thoughts on the “local access” security debate, feel free to discuss in the comments.
Full Technical Report & PoCs available on my GitHub Gist.