A month of leaks: what it means for vibe-coded apps

In three weeks there were critical updates for Next.js, Node.js and PHP, an attacker at the hosting platform Railway could decrypt environment variables of up to roughly 100,000 workspaces, and a compromised version of LiteLLM sat on PyPI for almost two hours. A team that follows this can apply most of it within a day or two. An app that was built with an AI tool and then left running often has no such team. My advice is to give that app an owner now and go through the five points at the end.

What happened in October

From the past few weeks:

• 8 to 12 October: GhostAction came back. According to GitGuardian, the attacker used about 1,900 hijacked accounts to push a workflow into more than 30,000 GitHub repositories to steal secrets.
• 14 October: Next.js 16.4.1 and 15.5.28 close two critical flaws that let an attacker run code without logging in. One is in image optimisation with SVG files, the other in use cache functions.
• 21 October: Node.js 22.23.4, 24.22.1 and 26.12.1 with ten CVEs, four of them rated high.
• 21 October: PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 against two flaws that run code without a login. Erik wrote about it in PHP2Shell: patching fast takes preparation.
• 21 October: Railway reports that an attacker could decrypt environment variables of at most 1.85% of all workspaces, about 100,000 according to Railway. The attacker appeared to be after AI provider keys in particular.
• 21 October: litellm 1.107.0 was compromised on PyPI for almost two hours and stole credentials.

What kept going wrong

Almost every attack was about keys. At Railway it was API keys in environment variables, with GhostAction it was secrets in GitHub workflows.

At LiteLLM it started with a configuration file for an AI agent, opencode.json, with a master key in it. That file landed in a public repository on 27 May. The commit was later overwritten, but the key was never revoked. On 10 October the attacker used it, and on 21 October the compromised release was online.

So a deleted commit is not a revoked key. And configuration files of AI tools are a new place where keys end up. How to handle keys is in Managing secrets and API keys safely.

Why vibe-coded apps run extra risk

Vibe coding is building software by telling an AI tool what you want, without writing or reading the code yourself. It gets you something working fast. The risk is in what does not happen: nobody reviews the code, and nobody maintains it.

UpGuard looked at about 300,000 domains that use Supabase, a database that coding agents work with easily, according to UpGuard. In 16,326 databases at least one table was readable by anyone, and in more than half of those UpGuard saw signs of personal data. UpGuard also names the cause: tables created through the API, the way coding agents create them, do not get row level security by default.

Moltbook showed early this year how that plays out. Its founder said he had not written a single line of code. Wiz found a Supabase key in the site's JavaScript and no row level security on the database. With that, the researchers could read about 1.5 million API tokens and 35,000 email addresses, and change data.

The code itself is not secure by default either. Veracode tested the code of a range of language models: it passed the security tests 56% of the time. A year earlier that was 55%. Only 15% held up against cross-site scripting.

Then there is maintenance. Who reads the Next.js advisory, updates Node and replaces the keys after Railway? If nobody has that job, the app runs on the versions from the day it was finished. Still on Node 20? It has been end-of-life since 30 April, and according to the Node.js project, end-of-life versions are always affected by a security release.

How I would check it

1. Find out what runs: which framework in which version, which Node or PHP version, where it is hosted and which keys it holds.
2. Update to at least Next.js 16.4.1 or 15.5.28, Node.js 22.23.4, 24.22.1 or 26.12.1, and a supported PHP version. On Node 20, moving to 22 or 24 is the only route.
3. Test your database as an outsider. Turn on row level security for every table and try to fetch data you should not see with the public key from your front end.
4. Take keys out of your front end and your repository, including .env files and the configuration of AI tools. If a key was ever in a public repository, revoke it. If your app runs on Railway, replace the keys stored there, as Railway asks.
5. Give the app an owner: someone who reads the advisories and can patch within a day.

Platforms do part of the work. Since 1 June, Lovable checks every app before publishing for issues such as missing row level security, and since April Replit has a Security Agent and a feature that patches critical CVEs in dependencies. The decisions stay with you: revoking a key, taking a site offline or scheduling an upgrade to a new Node version.

If your team works with AI coding tools, agree on what may and may not go into a prompt or configuration file. That is the subject of AI coding tools in a remote team.

Sources

• Next.js: Security Update for Upstream Vulnerabilities (14 October 2026)
• Node.js: October 2026 Security Releases
• Node.js Release Working Group: release schedule
• PHP: news archive 2026
• GitGuardian: GhostAction returns
• Railway: Preliminary report on the October security incident
• LiteLLM: Security incident 21 October 2026
• LiteLLM: Attack chain of the incident
• UpGuard: Systemic data exposure in Supabase apps
• Wiz: Exposed Moltbook database reveals millions of API keys
• Veracode: 2026 GenAI Code Security Report
• Lovable: How Lovable protects your apps automatically
• Replit: changelog 24 April 2026