
@artee_49 CVE-2025-48757 it already has a CVE its just not been fixed. Also the report was dismissed, its only right to post!
Post summary
The post simply notes that CVE‑2025‑48757 remains unfixed, providing no further technical or exploit details.
Exploitation observed; activity peaked at 20 mentions and remains active
Recommended action window: Immediate (within 24h)
NVD description
An insufficient database Row-Level Security policy in Lovable through 2025-04-15 allows remote unauthenticated attackers to read or write to arbitrary database tables of generated sites. NOTE: this is disputed by the Supplier because each individual customer of the Lovable platform accepts a responsibility over protecting the data of their application.
Priority
HIGH
Exploitation
ACTIVE
PoC
YES
Patch
AVAILABLE
Momentum
DECLINING
| Date | Total | Labels |
|---|
| 2026-02-02 | 1 | General1 |
| 2026-03-06 | 3 | Active Exploitation3 |
| 2026-04-01 | 1 | Disclosure1 |
| 2026-04-10 | 1 | Active Exploitation1 |
| 2026-04-20 | 20 | Disclosure9General10Patch1 |
| 2026-04-21 | 4 | Disclosure2General2 |
| 2026-05-02 | 1 | Active Exploitation1 |
| 2026-05-09 | 1 | Patch1 |
| 2026-05-27 | 3 | Active Exploitation2General1 |
| 2026-05-28 | 1 | Active Exploitation1 |
| 2026-06-02 | 1 | Disclosure1 |
| 2026-06-12 | 1 | General1 |
| 2026-06-30 | 1 | Active Exploitation1 |
| 2026-07-04 | 1 | Disclosure1 |
| 2026-07-28 | 1 | Active Exploitation1 |
| 2026-08-09 | 1 | General1 |
| 2026-08-17 | 2 | Disclosure1General1 |
| 2026-09-01 | 1 | Disclosure1 |
| 2026-09-02 | 1 | Disclosure1 |
| 2026-09-06 | 1 | Disclosure1 |
| 2026-09-14 | 2 | Disclosure2 |
| 2026-09-22 | 2 | Disclosure1General1 |
| 2026-09-25 | 1 | Disclosure1 |

@artee_49 CVE-2025-48757 it already has a CVE its just not been fixed. Also the report was dismissed, its only right to post!
Post summary
The post simply notes that CVE‑2025‑48757 remains unfixed, providing no further technical or exploit details.

A fresh warning from developer Morgan Linton says free Lovable accounts can still read other users' AI chat histories, source code, and database credentials on projects created before November 2025. The pattern is the same one that earned the platform CVE-2025-48757 last year. https://awesomeagents.ai/news/lovable-breach-chat-source-code-credentials/
Post summary
The message warns that free Lovable accounts can read other users’ data—similar to the prior CVE-2025-48757—yet it provides no PoC, exploit code, patch, or evidence of active attacks.

🕛August, 2025 Claude Opus 4.1 launched with 74.5% on SWE-bench Verified - exceptional at understanding complex software architectures and multi-file refactoring. Powered deeper codebase analysis for Claude Code. Lovable raised $200M at $1.8B valuation despite CVE-2025-48757 - a critical security flaw (CVSS 9.3) discovered in May that exposed 170+ apps to unauthenticated database access.
Post summary
The post references CVE‑2025‑48757 only in a business context, noting its severity and impact, but does not provide exploit details, patches, or evidence of active attacks.

Prompt 7: The Exposed Database Check A researcher scanned Lovable apps in 2025 and found 170 with the same hole: Supabase tables shipped with row level security never switched on. It became CVE-2025-48757. AI does what you ask. It never thinks about what you didn't ask. "You are an application security engineer who audits Supabase backed apps before launch and has seen the same handful of failures in every vibe coded project. Audit this project for the security problems AI generated code creates by default. Report everything. Fix nothing until I approve it. Audit: - Every table: is row level security actually enabled, and does each table have a policy that genuinely restricts rows - Any policy with a condition that evaluates true for everyone, which is the same as having no policy - Tables holding emails, names, messages, or anything personal, listed first - What the public key can read, write, and delete right now if someone pulls it out of my frontend bundle, which they can - API keys or secrets sitting in client side code instead of in secrets and edge functions - Data getting dumped to the browser console on page load - Anything the frontend enforces that the database does not, because the frontend is not a security layer - Flag anything that needs a professional security review before this site collects personal data or takes payments Output a findings table ranked critical to low, each with the exact fix, then wait for me to choose which ones to apply."
Post summary
The text discloses CVE-2025-48757, identifying that 170 Lovable apps have Supabase tables shipped without row-level security enabled. It provides detailed technical vulnerability information but includes no PoC, exploit, active exploitation evidence, or named patch.

1. No row level security Your Supabase anon key ships in the client bundle. With no RLS behind it, it reads the entire database. 170 of 1,645 Lovable apps had exactly this. CVE-2025-48757, CVSS 9.3. One scan found 172 sites where anyone could delete rows, unauthenticated.
Post summary
The entry reveals that many Supabase applications ship an anonymous key with no row‑level security, allowing unauthenticated read and delete of the entire database. This flaw is identified as CVE-2025-48757 with a CVSS score of 9.3.

Prompt 7: The Exposed Database Check A researcher scanned Lovable apps in 2025 and found 170 with the same hole: Supabase tables shipped with row level security never switched on. It became CVE-2025-48757. AI does what you ask. It never thinks about what you didn't ask. "You are an application security engineer who audits Supabase backed apps before launch and has seen the same handful of failures in every vibe coded project. Audit this project for the security problems AI generated code creates by default. Report everything. Fix nothing until I approve it. Audit: - Every table: is row level security actually enabled, and does each table have a policy that genuinely restricts rows - Any policy with a condition that evaluates true for everyone, which is the same as having no policy - Tables holding emails, names, messages, or anything personal, listed first - What the public key can read, write, and delete right now if someone pulls it out of my frontend bundle, which they can - API keys or secrets sitting in client side code instead of in secrets and edge functions - Data getting dumped to the browser console on page load - Anything the frontend enforces that the database does not, because the frontend is not a security layer - Flag anything that needs a professional security review before this site collects personal data or takes payments Output a findings table ranked critical to low, each with the exact fix, then wait for me to choose which ones to apply."
Post summary
The text discloses CVE‑2025‑48757 (Supabase tables without row‑level security) and outlines a detailed audit checklist for AI‑generated projects, covering policy, secret exposure, and client‑side security issues. No PoC, exploit code, patch, or active exploitation information is provided.

What nobody tells you about leaving the platform: One audit found 170 of 1,645 AI-built production apps had missing or broken row-level security (CVE-2025-48757). Another founder shipped an app with "zero lines of code written." Database exposed in 3 days. 1.5M tokens leaked.
Post summary
A CVE-2025-48757 audit revealed 170 AI-built apps with broken row-level security, resulting in a database exposure and 1.5 M leaked tokens within three days, indicating active exploitation.

3/8 2. Broken authorization. CVE-2025-48757: Lovable apps wired to Supabase with row-level security off. One app had the access logic inverted — logged-in users blocked, anonymous visitors got everything. 170+ production apps leaked user data the same way.
Post summary
A newly disclosed authorization flaw in Supabase‑connected apps led to data leakage across more than 170 production deployments.

This isn't hypothetical. CVE-2025-48757 documented this exact pattern affecting Lovable apps built before April 2025. NIST published it May 29, 2026. Lovable's response: "each individual customer accepts responsibility over protecting the data of their application." Which is fair. Most customers just didn't know they had to.
Post summary
The post reports that CVE‑2025‑48757, identified by NIST, impacts Lovable apps built before April 2025, while the vendor notes customer responsibility for data protection, implying lack of a vendor‑issued patch.

@weezerOSINT @Keoikantse @Lovable @discord posted a full writeup, the api endpoint let any authenticated user pull project data by id with zero authorization checks. cve-2025-48757 if you want the formal reference
Post summary
A writeup reveals that CVE‑2025‑48757 exposes an API endpoint allowing authenticated users to retrieve any project data by ID due to missing authorization checks, but no exploit code, patch, or active exploitation reports are provided.

Lovable's clarification was to separate their platform from the issue. No hack or leak hit Lovable's core systems, user prompts, or proprietary codebases. The real problem: CVE-2025-48757—missing/misconfigured Row Level Security in Supabase DBs of ~170+ user-built apps. AI-generated apps often skip proper auth by default, exposing data publicly. They stated "no breach" to reassure users their Lovable accounts were safe, while highlighting it's on devs to review/secure what the AI builds. Classic vibe-coding risk, not platform compromise.
Post summary
Lovable confirms no platform breach while highlighting that CVE‑2025‑48757 affects many AI‑generated apps due to missing row‑level security in Supabase DBs; no exploitation, PoC, or patch is reported.

@mohbii @weezerOSINT 48 days open is wild but the real number is 170+ databases exposed through missing RLS policies, cve-2025-48757 confirms it was baked into every project by default
Post summary
The tweet announces that CVE‑2025‑48757 is a default configuration flaw in many projects, resulting in over 170 databases being exposed due to missing RLS policies.

@sanjaygpts @weezerOSINT cve-2025-48757 literally shows the platform itself shipped no RLS on generated projects, so yeah the weakest link was never the vibe coder
Post summary
The tweet highlights a missing security feature (no RLS on generated projects) in the platform related to CVE-2025-48757, indicating a disclosure of a potential vulnerability.

CVE-2025-48757. Someone scanned 1,645 apps built with Lovable. 170 of them had databases anyone could read. #supabase
Post summary
The tweet discloses scan findings related to CVE-2025-48757, noting 170 Lovable apps had publicly readable Supabase databases, without mentioning patches, exploits, or active attacks.

CVE-2025-48757: 170 Lovable apps with no working row level security. 303 endpoints. The platform shipped a scanner that checked whether RLS existed, not whether it worked.
Post summary
The text discloses technical details about CVE-2025-48757, describing ineffective row-level security in Lovable apps and endpoints. It does not mention a PoC, exploit tool, active exploitation, or remediation.

Same month: CVE-2025-48757 – an inverted access control check in Lovable's Supabase integration – left ~170 production apps open. LLMs generate plausible code. Plausible and correct diverge exactly at the boundaries: auth, permissions, data exposure.
Post summary
The post announces CVE‑2025‑48757 as an inverted access control flaw that left roughly 170 production apps vulnerable, but offers no PoC, exploit code, or patch details.

What actually stops it is a policy on the table itself. Nobody asks for one, no test goes red without one, and the app looks identical either way. CVE-2025-48757: 170+ production apps, CVSS 9.3, disputed by the vendor.
Post summary
CVE‑2025‑48757 has a CVSS of 9.3 and affects over 170 production apps, yet the vendor disputes it; a policy appears to mitigate exploitation.

Checklist plus the version-pinned CVE list: http://github.com/boxed-dev/vibe-coding-security Sources in order: CVE-2025-48757 on http://nvd.nist.gov, the 5,600-app scan is http://Escape.tech's Oct 2025 audit, and Lovable published their own April 2026 incident writeup. I haven't re-scanned those apps myself. Those numbers are theirs, not mine.
Post summary
The post lists a CVE and various sources, including an incident writeup, but provides no technical details, PoC, exploit code, or patch information.

CVE-2025-48757: apps on Lovable shipped without Supabase row-level security on by default. A scan of 1,645 live apps found 303 exposed endpoints across 170 of them — no login needed to read/write PII and API tokens. (Lovable disputes the classification; the scan itself isn't.)
Post summary
The CVE‑2025‑48757 disclosure highlights that Lovable applications were shipped without Supabase row‑level security, leading to 303 exposed endpoints that could read/write PII and API tokens; no exploit proof‑of‑concept or patch is mentioned, and the vendor disputes the classification.

4/ La parte que no entra en la valuación: seguridad. CVE-2025-48757: +170 apps de Lovable exponiendo correos, API keys y datos de pago, sin auth. Tres incidentes serios en 13 meses. RLS y manejo de secretos son justo lo que no ves en la demo.
Post summary
The post reports CVE-2025-48757 has led to three serious incidents in 13 months, exposing sensitive data due to authentication bypass, highlighting active exploitation in the wild.