Lovable Found a Critical Flaw in Apps Like Yours. Then It Shielded Them.

TL;DR: A critical (CVSS 9.3) cross-site scripting flaw — CVE-2026-102989 — was found in TanStack Start, a framework a lot of AI-built apps run on. Lovable’s security team found it, reported it, and put firewall rules in front of its hosted apps while the fix was prepared. If your app is hosted on Lovable or Appwrite, someone stood in front of you. If it’s anywhere else, you need to act — and the vibe coding security catch is that updating your project isn’t enough. You have to redeploy.

What happened

On 30 September 2026, TanStack published a security update for CVE-2026-102989, tracked as GHSA-qx66-fv34-fjm8. Appwrite’s write-up puts the severity at CVSS 9.3 — critical, near the top of the scale.

TanStack credits Lovable with finding it. Lovable’s own post says its security team “found a vulnerability (CVE-2026-102989) in TanStack Start, reported it to the maintainers, and protected hosted apps with firewall rules while a fix was prepared.” Appwrite’s account agrees: “Lovable helped TanStack discover the issue and worked with them on the fix.”

Neither TanStack nor Appwrite reports any evidence of the flaw being exploited. As vibe coding security incidents go, this one was caught early.

What the flaw actually let someone do

In plain English, and this is the part worth understanding even if you never touch the code.

An attacker could craft a link to your app. Not break into your server, not steal a password — just build a URL. If one of your users clicked it, the attacker’s code would run inside your app, with that user’s access. Whatever that person could see or do in your app, the attacker could see or do.

No login required on the attacker’s side. The advisory describes an unauthenticated attacker.

The underlying mistake, per Appwrite: the framework “copied fields from the request payload into internal middleware state” when it should have restricted itself to public input fields, which let an attacker inject a value that the response handling then “treated as a real HTTP response.”

You were never going to catch that. Neither was the AI that wrote your app. It’s a flaw in the foundation, not in what you built on top of it — which is the uncomfortable centre of vibe coding security: the code you didn’t write can break in ways the code you did write cannot explain. That is the trade every vibe coding tool asks you to make, and most of the time you never see the bill.

Vibe coding security in practice: who stood in front of you

This is where the story gets genuinely encouraging, and it’s the part most coverage will skip.

• Lovable put firewall rules in front of its hosted apps while the fix was being prepared — protection that existed before a patch did.
• Appwrite blocks the attack pattern at the edge on every site, validating the `x-tsr-serverFn: true` header and rejecting navigation requests to server-function paths, and says it keeps doing so until your code is patched.

That is vibe coding security working the way it should. The platform noticed, told the maintainers, and shielded the people who couldn’t shield themselves — without requiring any of them to understand what a reflected XSS is.

But the shield is a property of where you host, not of what you built. If you exported your app and put it on your own hosting, or on a general-purpose host with no idea what TanStack Start is, nobody did this for you. The same app, the same flaw, no firewall in front of it.

The vibe coding security step people will get wrong

Here is the sentence to take away, straight from TanStack:

“Updating a local installation alone doesn’t patch an already deployed application.”

Running an update on your computer does nothing to the version of your app that’s on the internet. No amount of vibe coding security elsewhere in the stack covers this one. Those are two separate things, and conflating them is the single most common misunderstanding among people who build software without a development background.

Your live app runs the code you last deployed. Until you build and deploy again, it is running the vulnerable version, no matter what your project folder says.

Appwrite spells out the sequence: check which version your lockfile resolves to, upgrade, then commit the lockfile and push to trigger a new deployment.

What to do, in about ten minutes

1. Work out whether this affects you. Vibe coding security starts with knowing what your app is actually built on. It applies to apps using TanStack Start. If you don’t know what your app uses, ask the tool that built it: “does this app use TanStack Start, and which version?”
2. Check the version against the advisory. Affected ranges start at 1.143.12 and run up to 1.168.59 (`@tanstack/react-start`), 1.168.56 (`solid-start`), 1.168.55 (`vue-start`) and 1.169.38 (`start-server-core`).
3. Upgrade to a patched version — `@tanstack/react-start` 1.168.60 or later, `solid-start` 1.168.57+, `vue-start` 1.168.56+, `start-server-core` 1.169.39+.
4. Redeploy. This is the step that actually fixes it. Push the change so a new build goes live. If you only did step 3, you have not fixed anything that matters.
5. Check your live app afterwards. Not your editor — the real URL. Confirm the deployment went through.

If you’re on Lovable or Appwrite, you were covered during the gap, but you should still patch and redeploy. A firewall rule in front of a flaw is a stopgap, not a fix, and it’s one your platform gets to withdraw whenever it decides the emergency is over.

Who should care (and who shouldn’t)

• Running a live app with user accounts: this is today’s job, especially if you host it yourself. A flaw that runs code as your logged-in users is as serious as it sounds.
• On Lovable or Appwrite: vibe coding security worked for you here. Patch and redeploy anyway, and note this as evidence about the platform you picked.
• Building with a different tool: check whether your stack uses TanStack Start. AI builders reach for popular frameworks, and “I didn’t choose it” doesn’t mean “I don’t have it”.
• Static site, no accounts, no server functions: very likely nothing to do. The attack needs a user with access worth stealing.
• Still deciding which builder to use: add vibe coding security to the column that doesn’t appear in feature comparisons — who watches the foundation for you? It’s a real differentiator and our comparison is the place to start.

Our take

This is the best vibe coding security news we’ve covered, and it reads like bad news. That inversion is worth sitting with.

Five days ago we wrote about 16,326 databases left readable by anyone because one setting was never switched on. That was a story about nobody watching. This is the same category of vibe coding security risk, with somebody watching — a platform’s security team auditing a dependency its users have never heard of, finding a 9.3, telling the maintainers rather than sitting on it, and standing in front of its users in the meantime.

It also makes the Sutro acquisition from 22 September look like something other than a press release. A company that buys a team specialising in auditable, secure backends and then has its security team find a critical flaw upstream nine days later is a company actually spending money on this.

The honest caveat: vibe coding security can only be judged on the vulnerabilities that get found and disclosed. A clean record isn’t proof of safety, it’s proof of either diligence or silence, and from outside you can’t tell which. What you can observe is behaviour at the moment something goes wrong — and the behaviour here was good.

The part that should worry you is the redeploy step. Everything else in this story was handled by professionals. That one step is yours, and it’s the one a person who has never deployed software by hand is most likely to skip — because “I updated it” feels finished. It isn’t.

Not sure which builder gives you the most cover for what you’re building? Take the 60-second Vibe Coding Tool Finder quiz →

FAQ