Pydantic AI CVEs and What They Mean for Vibe-Coded Apps

Three things happened today that matter if your app talks to an AI agent, ships on Lovable, or runs on Next.js. None of them are hype. All of them change what "secure enough" looks like for a vibe-coded app right now.

TL;DR

• Three new CVEs in Pydantic AI (used by Vercel's AI adapters) let attackers leak cloud credentials, reference arbitrary files, or smuggle tool calls past a safety filter. nvd.nist.gov
• Lovable now auto-revokes API keys the moment GitHub flags them in a public repo. docs.lovable.dev
• Vercel's WAF blocked 6 million React2Shell exploit attempts against Next.js, 2.3 million in a single day. vercel.com
• A Lovable builder lost 12GB of proprietary data with no warning — a reminder that platform access and backups are a security decision, not an afterthought. reddit.com

Pydantic AI vulnerability hits Vercel AI Gateway apps

If your app uses an AI agent framework wired into Vercel's AI Gateway or Vercel AI adapter, pay attention to this one. NVD published three CVEs in Pydantic AI, the Python framework many agent builders sit on top of.

• CVE-2026-46678: when an app allows force_download='allow-local', an attacker can reach cloud metadata endpoints by encoding the IP in an IPv6 transition form — IPv4-mapped IPv6, 6to4, or NAT64. That bypasses the metadata blocklist and can expose short-term cloud IAM credentials. This is an incomplete fix of an earlier CVE, meaning the first patch didn't cover every encoding.
• CVE-2026-54249: UI adapters (including the Vercel AI adapter) validate file URLs against an allowlist, but they forward UploadedFile references — provider file IDs or cloud storage URIs like s3:// or gs:// — without checking them. A client can submit message history that points to files it shouldn't have access to.
• CVE-2026-65975: the adapters strip "dangling" tool calls from untrusted message history as a safety default, but the strip is anchored to a message index computed before sanitizing. That timing bug can let unauthorized tool calls slip through.

None of these require you to have written the vulnerable code yourself. If you added an AI agent feature through a builder or a template that pulled in Pydantic AI, the exposure travels with the dependency. Check your stack, not just your own commits. nvd.nist.gov nvd.nist.gov nvd.nist.gov

Lovable now auto-revokes leaked API keys

Lovable shipped a real fix, not a feature announcement dressed up as one. If a workspace API key ends up committed to a public GitHub repo, GitHub flags it, and Lovable revokes the key automatically — no setup required. The creator and every workspace admin get an email naming the key and linking to the alert. The key cannot be restored; you generate a new one.

This is good hygiene from the platform. It is not a substitute for your own hygiene. Auto-revoke only fires after the key is already public and GitHub has scanned it — there's a window where the key is live and exposed. Keep secrets out of your repo in the first place; don't rely on the safety net to catch every case. docs.lovable.dev

React2Shell exploit attempts are still climbing

Vercel published numbers from the weeks after React2Shell's disclosure: its WAF blocked over 6 million exploit attempts against vulnerable Next.js deployments, with 2.3 million hitting in a single 24-hour period at peak. Vercel ran a bug bounty with 116 researchers, paid out more than $1 million, and shipped 20 WAF updates in 48 hours as new bypass techniques surfaced.

The takeaway isn't about Vercel's response — it's about attacker behavior. Disclosure doesn't end an incident; it starts a scanning campaign. If your app runs on Next.js and you haven't confirmed you're on a patched version, that's still an open door months after the headlines faded. vercel.com

When the platform, not an attacker, is the risk

A Lovable builder posted that after six months and over $1,000 in credits, their project — front end, back end, and 12GB of data on Lovable's hosted Supabase instance — was locked with no warning and no proof of what triggered it. This isn't a breach or a leak. It's a reminder that when a builder platform hosts your database, your access to your own data depends on that platform's support process, not just its security controls. Export your data regularly. Know what you'd do if access disappeared tomorrow. reddit.com

FAQ

What is CVE-2026-46678 in Pydantic AI?

It's a vulnerability where an app that allows local downloads can be tricked into reaching cloud metadata endpoints using an IPv6-encoded form of the metadata IP, bypassing the existing blocklist and exposing short-term cloud credentials. It affects Pydantic AI versions 1.56.0 through 1.98.0.

Does a leaked Supabase anon key count as a breach?

No. A Supabase anon key is meant to be public — it ships in your client-side code by design. The real risk is missing or misconfigured Row Level Security behind that key. If RLS is off or too permissive, the anon key gives access to data it shouldn't. Check your RLS policies, not the key's visibility.

Should I still worry about React2Shell if I've patched Next.js?

If you're confirmed on a patched version, the specific vulnerability is closed. But the scanning volume Vercel reported — millions of attempts — shows attackers are still probing broadly for anyone who hasn't patched. Verify your deployed version, not just your repo's package.json.

The bottom line

Today's pattern is the same one that keeps showing up: the risk has moved from the code you write to the platforms and frameworks you build on top of. A CVE in an agent framework, a key left in a public repo, a Next.js deployment still running an old version — none of these require a mistake in your own logic. They require you to check what's underneath it.