The Complete List of Public AI-Generated Code Security Incidents (2025–2026)

AI coding tools are extraordinarily productive. They are also producing vulnerabilities at scale. This post catalogs every named, publicly reported security incident caused — directly or indirectly — by AI-generated code between 2025 and 2026. It is maintained and updated as new incidents are documented. The goal is not to blame the tools. It is to make the failure patterns legible, so developers can check for them before shipping.

The incidents

The pattern

Two of the three incidents above share an identical root cause: Row-Level Security was never enabled. This is a single checkbox in the Supabase dashboard — or a single SQL statement if you're managing Postgres directly. It is not obscure. It is documented prominently. AI coding tools did not forget about it. They simply do not check configuration layers that exist outside the application code itself.

This is the structural gap. AI coding tools operate on code. Database-level access control, secrets management, TLS configuration, and platform security settings exist outside the code. They are real parts of your security posture. They are invisible to the tools that wrote your code.

What RLS actually is, and why AI tools miss it

Row-Level Security is a Postgres feature that lets you define who can read, insert, update, or delete each row in a table. Without it, any authenticated database user — including your application's service role — can access every row in every table. In Supabase, this means any authenticated user of your application can query any row in any table, as long as they can reach the Supabase client.

When you build with Supabase + an AI coding tool, the tool generates your application code correctly: it creates tables, inserts records, queries data. But RLS is a database-level configuration, not an application-level one. The AI tool is not looking at your Supabase project settings. It generates working code that interacts with an open database — and the database stays open unless a human specifically goes in and closes it.

-- Enable RLS on a table (run this in Supabase SQL editor or via migration)
ALTER TABLE your_table ENABLE ROW LEVEL SECURITY;

-- Add a policy: users can only see their own records
CREATE POLICY "Users can only see their own data"
ON your_table
FOR SELECT
USING (auth.uid() = user_id);

-- Without these two statements, any authenticated user
-- can read every row in the table.

A checklist for AI-generated backends

This list is not exhaustive. It covers the failure patterns seen in documented incidents. Check each item before your app receives real users:

1. 1Row-Level Security enabled on every Supabase / Postgres table that stores user data.
2. 2RLS policies defined for every CRUD operation — SELECT, INSERT, UPDATE, DELETE. Enabling RLS without policies denies all access by default, which is safe but will break your application.
3. 3API keys and secrets not hardcoded in source code. Use environment variables. Verify they are not committed to your git repository.
4. 4Database credentials using minimum-privilege roles. Your application should not connect as a superuser.
5. 5AI agents operating with read-only access unless they explicitly need to write. The Replit incident involved an agent with write access that was instructed not to use it.
6. 6Authentication required before any data access. Test that unauthenticated requests to your API return 401, not data.
7. 7CORS configured to your domain, not `*`.

Why this keeps happening

The Veracode 2025 AI Code Security Report found that 45% of AI-generated code fails basic security audits. The Stack Overflow Developer Survey (February 2026) found that 92% of developers use AI coding tools daily, but only 29% highly trust the output. The gap between adoption and trust exists precisely because developers have learned — often by experience — that AI tools are excellent at writing code and poor at configuring the environment that code runs in.

The tools are not getting worse. The attack surface is growing faster. More AI-built apps means more apps with the same unchecked configuration layer. The pattern will repeat until either the tools start checking the configuration layer automatically, or developers build a habit of checking it themselves before deployment.