Nhost Dev Leak, Agent Overreach, and Skill Audits

Three things happened this week that matter more than another model release. A local dev tool leaked secrets to any web page open in your browser. A founder asked an agent to move a button and got a rewritten layout instead. And a marketplace for AI "skills" started running third-party security audits before you install anything. None of this is exotic. All of it is about trust: what your tools do behind your back, and whether you'd notice.

TL;DR

• CVE-2026-47671: Nhost CLI's local dev server exposed admin secrets and JWT config to any origin, including a random web page, while nhost dev was running. Fixed in 1.46.0.
• A recurring theme on r/vibecoding: founders wiring up Supabase auth and Netlify hosting without understanding what connects to what — the exact gap where Row Level Security gets skipped.
• An agent asked to move a button 4px rewrote the whole layout instead. Harmless here. Not harmless if it touches auth or data-access code without you noticing.
• Vercel's skills.sh now runs every published skill through Socket, Snyk, and Gen for a public security audit — a first step toward supply-chain accountability for AI add-ons.

A local dev tool leaked more than it should

Nhost is an open-source Firebase alternative. Its CLI has a local dev mode, nhost dev, that spins up a hidden config server called Mimir. In versions before 1.46.0, that server used placeholder authorization checks and allowed requests from any origin. That means any process — including a malicious web page open in another browser tab — could reach it, read your project's admin secrets and JWT config, and even rewrite your local .secrets file. See CVE-2026-47671.

This only bites while nhost dev is running on your machine. It doesn't touch production. But local secrets often end up copied into production config, and a compromised dev machine is a foothold. If you use Nhost, update the CLI to 1.46.0 or later before your next dev session.

When you don't understand your own auth setup, you can't secure it

A post in r/vibecoding this week ("Vibe hosting") captures a pattern we see constantly: someone wiring together Next.js, Google auth, Supabase, and Netlify, following instructions from an AI assistant that don't match what the actual dashboard shows. This isn't a bug. It's the normal state of stitching together an auth provider, a database, and a host without knowing how the pieces enforce access.

To be clear: a Supabase anon key or a Firebase web config showing up in your frontend code is not a leak. Those are meant to be public. The real risk is what happens after the client connects — whether your database's Row Level Security policies actually restrict what that anon key can read and write. If you can't explain in one sentence what your RLS policies block, that's the gap to close, not the presence of the key itself.

Agents that do more than you asked

A founder asked Codex to move a button 4 pixels. It rewrote the layout instead (r/vibecoding). Funny when it's a layout. Not funny when the same overreach touches a login flow, an API route, or a database policy you never asked it to change.

Agents that rewrite more than the request don't distinguish between cosmetic code and security-relevant code. The fix isn't to stop using agents. It's to always look at the diff before you accept it, especially for anything near auth, permissions, or data access — and to ask the agent to explain what it changed and why, every time.

Third-party skills get a security check

Separately, Vercel announced that skills on skills.sh — the growing library of reusable instructions agents pull in to do specialized tasks — now get automated security audits from Socket, Snyk, and Gen, published publicly on each skill's page. With over 60,000 skills already on the platform, this is a reasonable response to an obvious problem: installing a skill is installing code you didn't write, reviewed by no one, run with your agent's permissions. A public audit trail is a good start. It's not a substitute for reading what a skill actually does before you add it to a project with real user data.

FAQ

Does the Nhost CVE affect my live production app?

No, not directly. The vulnerability is in the local dev CLI (nhost dev), reachable only on your own machine while it's running. The risk is a compromised dev environment leaking secrets that later end up in production. Update to CLI 1.46.0 or later.

Is a public Supabase or Firebase key in my frontend a security problem?

Not by itself. Anon keys and web configs are designed to be public. The actual risk is missing or misconfigured Row Level Security (or Firebase security rules) that let that public key read or write data it shouldn't. Check your policies, not just for the key's presence.

How do I stop an AI agent from making unrequested changes near sensitive code?

Review every diff before accepting it, not just the file you asked about. Ask the agent to summarize what it touched. For anything near auth, payments, or data access, do a manual pass — don't rely on the agent's own summary of its work.

The bottom line

None of this week's items is a dramatic breach. They're small reminders that vibe-coded apps inherit risk from three places: the dev tools you run locally, the auth setup you don't fully understand, and the agent that does more than you asked. Patch the Nhost CLI if you use it. Check your RLS policies instead of worrying about public keys. And read the diff before you accept it.