Astro Bypass, AI Token Theft: Vibe-Coding Security News

A patched bug in a popular deploy adapter, a warning from Vercel about AI endpoints being drained for cash, and a quiet industry shift away from long-lived tokens. None of this made headlines outside developer circles, but all of it lands directly on apps built with Lovable, Bolt, Cursor, and friends deployed on Vercel. Here's what actually changed and what to check.

TL;DR

• CVE-2026-73424 let unauthenticated requests render routes on Astro sites deployed via the Vercel adapter, if those routes relied only on edge path rules or split middleware for protection. Fixed in 11.0.3.
• Vercel warned that AI endpoints are a much richer target than ordinary API routes — a single stolen token can cost far more than a stolen login.
• Vercel Blob now supports signed URLs and OIDC authentication, both aimed at killing off long-lived storage tokens.
• Builders on r/vibecoding are naming the same problem from the other side: security and auth get bolted on late, after the demo works.

An authentication bypass in Astro's Vercel adapter

CVE-2026-73424 affects Astro's Vercel adapter, versions 10.0.3 through 11.0.3. The adapter's _isr function accepted an x-astro-path header and rendered whatever route it named, trusting the header alone. If your route protection lived in Vercel edge path rules or split edge middleware — rather than inside the route handler itself — an unauthenticated request could walk straight past it.

This matters for vibe-coded sites specifically because AI builders and templates lean hard on edge-level rules for things like gated pages or paywalled content, because it feels simpler than writing the check into every page. The fix is already out in 11.0.3. If you don't know which Astro version your project shipped with, that's the first thing to check — not because the anon keys or public config in your app are the problem, but because a bypass like this defeats the access control sitting in front of them.

Your AI features are a bigger target than your database

Vercel's own writeup on token theft makes a point that non-technical founders miss: a normal HTTP request costs a fraction of a cent, but a single prompt to a frontier model can cost dollars. That gap makes any exposed AI endpoint — a chat feature, a summarizer, an agent — one of the highest-margin things an attacker can abuse. Vercel says it has seen this attack against its own APIs.

The practical takeaway for apps built with Lovable, Bolt, Cursor, or v0 that wire in an LLM call: verification needs to run on every AI request, not just at login or signup. If your app has an AI feature with no rate limiting and no per-request check, it isn't a convenience gap — it's an open tab someone else can run up.

The industry's answer: fewer long-lived tokens

Two smaller Vercel changes point at the same underlying fix. Signed URLs for Vercel Blob let you hand out a scoped, time-bound link for a single operation — upload, download, or delete — on a single file, instead of a credential that can touch the whole store. And Vercel Blob now defaults to OIDC for new projects, issuing short-lived tokens that rotate automatically instead of the old long-lived BLOB_READ_WRITE_TOKEN.

The pattern generalizes past Vercel Blob. Any credential your app holds — storage tokens, service keys, webhook secrets — is safer scoped to one operation and one expiry than kept around indefinitely. That's a different conversation from public-by-design values like a Supabase anon key or a Firebase web config; those are meant to be visible. The risk there is what's enforcing access behind them — your RLS policies, your rules — not the key itself.

What builders are already worried about

On r/vibecoding, a founder describes the gap between a working demo and a launchable product: security, auth, observability, and payments all show up as line items only once you decide to go from "vibing" to shipping something real. A separate post on rules for serious builders makes the same point from a different angle — more building isn't the same as more progress, and skipped groundwork doesn't disappear, it waits.

That's the throughline this week. The tools are getting better at closing gaps after the fact — a patched CVE, signed URLs replacing static tokens — but none of it replaces checking your own app before someone else finds the gap first.

FAQ

Is my vibe-coded app affected by CVE-2026-73424?

Only if it's an Astro site deployed on Vercel using the Vercel adapter between versions 10.0.3 and 11.0.3, with routes that rely on Vercel edge path rules or split edge middleware for protection rather than checks inside the route itself. Upgrading to 11.0.3 resolves it.

How do I stop AI endpoint token theft on my app?

According to Vercel, the fix is verifying every AI request individually rather than trusting a session or signup check, plus rate limiting on any endpoint that calls out to a paid model. Treat AI calls as expensive by default, since a single abused request can cost far more than a normal API hit.

Why does my app need short-lived tokens instead of one static key?

A long-lived credential like BLOB_READ_WRITE_TOKEN grants full access indefinitely if it ever leaks. Signed URLs and OIDC tokens, as Vercel Blob now supports, expire on a schedule and are scoped to one action, so a leak has a shelf life and a limited blast radius instead of an open-ended one.

The bottom line

One patched bug, one blunt warning, and two small storage changes all point the same direction: access control that lives at the edge, in a header, or in a token that never expires is fragile. Access control checked on every request, with credentials that expire, is not. Check your Astro version if you're on Vercel, lock down any AI endpoint that's public, and start treating long-lived tokens as something to phase out rather than set once and forget.