Cursor Account Hijacked, Vercel Blocks a CVE by Default

Three things happened this week that point the same direction. An AI coding tool account got taken over while its owner was on holiday. A hosting platform started blocking a known-vulnerable package by default instead of just warning about it. And that same platform gave teams a way to stop AI-generated code from calling out to the internet at all. None of these are exotic. All of them are about limiting what happens after something goes wrong, not just preventing it in the first place.

TL;DR

• A Cursor user reported their account was hijacked, burning 170M tokens in under 24 hours and racking up $300+ in on-demand charges — on a standard $20/month Pro plan, with on-demand billing somehow auto-enabled during the intrusion. (reddit.com)
• Vercel now automatically blocks new deployments that use a vulnerable version of next-mdx-remote (CVE-2026-0969) instead of letting them ship. (vercel.com)
• Vercel Sandbox added egress firewall controls (SNI filtering, CIDR blocks) so AI-generated or untrusted code can't reach arbitrary hosts by default. (vercel.com)
• None of this is about leaked keys or exposed configs. It's about account credentials, dependency versions, and outbound network access — the parts of your stack that don't show up when you eyeball your code.

A Cursor account got hijacked — what it means for your app

A Cursor user posted that their team's account was compromised while they were away. The report: 170 million tokens burnt in under 24 hours, $300+ in on-demand charges, and an API key that appeared without any matching login trace. On-demand billing had been switched off, but somehow got flipped back on during the intrusion. (reddit.com)

We don't know the root cause yet — could be a leaked session token, a reused password, a phished credential. What matters for you: your AI coding tool account is not just a place where code gets written. It's a billing account with API access. If someone gets in, they can run up charges and, more importantly, generate and push code you never wrote. Treat the login to Cursor, Bolt, Lovable, or Replit with the same seriousness as your cloud provider console. Use a unique password, turn on two-factor authentication if it's offered, and check your usage dashboard periodically — not just when the bill looks wrong.

A vulnerable package now gets blocked automatically

Vercel is now refusing to deploy any project that ships a vulnerable version of next-mdx-remote, tied to CVE-2026-0969. Previously this would have shipped with a warning at best. Now the deployment fails outright, unless you explicitly override it with an environment variable. (vercel.com)

If your app touches MDX content — blogs, docs pages, anything rendered from markdown with embedded components — check your next-mdx-remote version. This is a good reminder that vibe-coded apps accumulate dependencies fast, and most founders never look at what's actually in package.json after the AI tool adds it. A blocked deploy is annoying. A vulnerable package that ships anyway is worse.

Locking down what AI-generated code can talk to

Vercel Sandbox — used for running AI agent-generated or otherwise untrusted code — now supports egress firewall rules: SNI filtering and CIDR blocks that restrict which hosts a sandbox can reach over the network. By default, sandboxes still have unrestricted internet access. Vercel's own guidance is blunt: when running AI-generated code, lock down the network to only what the workload actually needs, because a compromised or hallucinated dependency can otherwise call out anywhere. (vercel.com)

This matters beyond Vercel specifically. If your AI builder runs generated code in any sandbox or preview environment, ask what that sandbox can reach. Unrestricted outbound access means a bad dependency, a prompt injection, or a hallucinated package could exfiltrate data or call an attacker's server without anyone noticing. Default-open network access is a common blind spot in vibe-coded stacks, precisely because nobody set it up on purpose.

FAQ

Is Cursor safe for vibe coding after this account hijack?

Cursor itself wasn't shown to have a platform-wide breach — this was one reported account takeover, with cause still unconfirmed. Cursor remains widely used and there's no evidence of a systemic flaw. The practical takeaway is account hygiene: strong unique passwords, 2FA where available, and regular checks on usage and API keys tied to your account.

How to secure AI-generated code running in a sandbox or preview environment?

Start by checking what the sandbox can reach outbound. Vercel Sandbox now lets you restrict egress to specific hosts via SNI and CIDR rules — the same principle applies wherever your builder runs generated code. Default-open network access should be the exception, not the norm, especially for code you didn't write line by line.

What is CVE-2026-0969 and does it affect my app?

CVE-2026-0969 is a vulnerability in the third-party package next-mdx-remote. If your app renders MDX content and uses that package, check your version — Vercel now blocks new deployments running the vulnerable version by default. If you're not on Vercel or don't use MDX, this specific CVE doesn't apply, but it's a reminder to check dependency versions your AI builder pulled in.

The bottom line

None of this week's news is about a dramatic exposed key or a leaked database. It's about accounts, dependencies, and default network access — the boring plumbing that most vibe-coded apps never get audited. Check who can log into your builder account, check what's actually in your package list, and check whether the code your AI agent runs can talk to the open internet by default. Those three checks would have caught everything above.