Sources

CVE-2025-48757 — insufficient RLS policy in Lovable lets unauthenticated attackers read/write arbitrary tables of generated sites

Both pages quote the NVD description verbatim, carry the 9.3 score and the publication date, and state that Lovable disputes the entry. The dispute is part of the record and is not omitted. The prior register entry claimed '170+ apps / 303 endpoints' — NVD carries no such count, so it is gone from the pages.

A Supabase publishable/anon key is safe to expose in a browser only because RLS, not the key, is the security boundary

Refetched 2026-09-10. The policy is unchanged, but both buyer pages now use the current role-mapping explanation and the direct instruction to enable RLS on every table before deployment. The publishable-key exposure statement and secret-key RLS-bypass statement remain present on the primary source.

Supabase legacy anon / service_role JWT keys are deprecated at the end of 2026 in favour of sb_publishable_ / sb_secret_

A live deadline inside the register's own horizon — recheck every rotation. When Supabase names an exact date, replace 'end of 2026' with it on the page and here. Refetched 2026-08-08: verbatim unchanged, 'They will be deprecated by the end of 2026, and you should now use the publishable (sb_publishable_xxx) and secret (sb_secret_xxx) keys instead.' STILL NAMES NO EXACT DATE, which the checkers guide says explicitly rather than leaving a reader to assume 31 December. The scan engine must recognise BOTH key formats until this passes; a detector that only knows the JWT shape will walk past an sb_secret_ key sitting in a client bundle. REFETCHED 2026-09-06 and the SENTENCE MOVED while the DEADLINE did not. Supabase now writes "Supabase is deprecating the anon and service_role keys by the end of 2026. Use the publishable (sb_publishable_xxx) and secret (sb_secret_xxx) keys instead." The prior wording, quoted verbatim on two guides and in a source comment since 2026-08-02, was "They will be deprecated by the end of 2026, and you should now use the publishable (sb_publishable_xxx) and secret (sb_secret_xxx) keys instead." Anyone following our citation would have found a sentence that was not the one in our quotation marks. All three sites corrected. EIGHTH STANDING RULE, and it is the seventh rule turned inward: A QUOTATION DECAYS SEPARATELY FROM THE FACT IT CARRIES. Re-reading a source to confirm the DEADLINE is not the same as re-reading it to confirm the SENTENCE, and a page in quotation marks is asserting the sentence. Check the string, not only the value. Still no exact date, which both guides continue to say explicitly.

What Supabase's own Security Advisor checks, and every RLS lint it names

DRIFT CORRECTED 2026-08-09, and it is the LaunchGuard failure repeated against a FIRST-party tool. The 2026-08-06 version of this claim recorded three lints (0007/0008/0013) and the page turned that count into an argument: that the advisor "cannot see ... that a permissive clause left over from a debugging session is now shipping". 0024_permissive_rls_policy is exactly that lint and it was already there — its IDENTIFIER alone would have contradicted the sentence, and nobody opened it. Two of the six read policy CONTENT (0015, 0024), so "it reads structure, not behaviour" was wrong and wrong in this product's favour. FIFTH STANDING RULE: A CAPABILITY LIST IS A SNAPSHOT, NOT A DEFINITION. An enumeration read once ("the three lints") silently hardens into a negative claim ("only three"), and vendors add to lists — so record the count WITH the date it was counted, and never phrase it so that the competitor growing makes our page wrong in our favour. Corollary of the title-vs-body rule: a lint identifier is a title; open the lint page. What SURVIVES, stated narrowly on the page: a policy scoped to the wrong column (using auth.uid() = created_by where you meant user_id) is well-formed, restrictive, references nothing user-editable, and passes all six lints. That is the gap, and it is much narrower than this page claimed for three days.

What pgTAP's RLS assertions actually test

The absence of a role-switching example is the load-bearing part of this claim and it is an ABSENCE, so it decays differently from a quotation: if Supabase adds a two-user RLS example to this page, the comparison page's pgTAP row becomes wrong. Rechecked 2026-08-08 for an auth.uid() / request.jwt.claims / set-role example specifically, not just for the quoted sentences — still none.

What LaunchGuard tests, the access it works from, and whether it authenticates

DRIFT CORRECTED 2026-08-08, and it is the lesson of this rotation. The 2026-08-06 version of this claim read 'Cross-user check is the usual IDOR tricks' and 'Runs from outside with no credentials', sourced entirely from /supabase-scanner — so the comparison page asserted LaunchGuard becomes nobody. Its /pricing page, never read, puts logged-in testing in the FREE plan. The two LaunchGuard surfaces genuinely pull against each other and the page now quotes both rather than keeping the flattering one. NEW STANDING RULE, alongside the price rule, the capability rule and the title-vs-body rule: A CLAIM THAT A NAMED COMPETITOR CANNOT DO SOMETHING MUST BE CHECKED AGAINST THAT VENDOR'S PRICING / PLAN PAGE AS WELL AS THE PAGE MARKETING THE SINGLE TOOL. A tool page sells the tool; the plan page is where the vendor enumerates capability, and it is where a negative claim goes to die. What survives as this product's differentiator is narrower and is stated narrowly on the page: signing in as ONE user is not comparing TWO. If LaunchGuard ever states a two-user cross-read, the guide's central claim is gone and the table must be rewritten, not patched.

LaunchGuard's published plan prices and what Pro adds over the free scan

Added 2026-08-08. The comparison table previously showed LaunchGuard's cost as a flat 'Free' beside this product's 'Free scan / $49', which read as a favourable comparison built on an unchecked cell. Both prices here are quoted from LaunchGuard's own pricing page per the standing rule the rescue-page episode established. This is a competitor's list price and is among the faster movers in the register — recheck whenever the checkers guide is touched.

What SecurifyAI's Supabase RLS Security Scanner Chrome extension tests, and its maturity signals

The user count and update date are the fastest-moving figures in this register. The count moved from 14 on 2026-08-06 to 12 on 2026-08-08, then to 21 on 2026-09-08; it cannot be treated as a ratchet. The update date (3 May 2026) has not moved. They are on the page because 'early software' is a fair and checkable thing to say with a dated number and an unfair thing to say without one; the page dates the count in-sentence rather than stating it as a standing fact. If either figure cannot be re-read, cut the sentence rather than soften it. Stated neutrally: the page does not use the count to dismiss the tool. The Chrome Web Store listing is NOT the whole vendor — see securifyai-open-source-scanner-scope.

What Pragmatic Coders publicly states about the cost of its vibe-code rescue service

Refetched 2026-08-07: unchanged — still no rate card, still 'FREE' consultation and 'From $0*' code assessment with the same asterisk. This claim is an ABSENCE ('publishes no rate card'), so it flips the moment the agency publishes one; recheck it on the same footing as a live deadline. Replaces the invented 'Project-based, typically mid-four to five figures' that sat in this provider's pricing cell until 2026-08-03. Attributing a price band to a named, identifiable company on no source is the most expensive kind of claim this site could carry. The row now links to the service page itself rather than the agency homepage.

What Redwerk publicly states about the cost of its vibe-code cleanup service

Refetched 2026-08-07: unchanged — the FAQ sentence is verbatim identical and there is still no rate card. Same absence-flips-on-publication caveat as the Pragmatic Coders row. The register previously pointed at redwerk.com (the homepage); the actual service page is /services/vibe-code-cleanup/ and the row now deep-links to it. Exact service name corrected from 'Vibe Code Cleanup' to the page's own 'Vibe Code Cleanup for AI-Generated Apps'.

What SecurifyAI's own site says its open-source Supabase RLS scanner checks (a separate tool from the Chrome extension)

Found by applying the 2026-08-08 rule (check the vendor, not just the tool page) to the one row where it had never been applied. This is a DIFFERENT tool from the Chrome extension and the page must not conflate them — the extension row still quotes the store listing, and this scanner gets its own paragraph. Its checklist is wider than the extension's and includes storage buckets, which the page had credited to LaunchGuard alone. IMPORTANT on the negative claim: the site does not DENY authenticating, it is silent. Silence is not a denial, and the page says so rather than reading absence as a limitation. If SecurifyAI ever states a two-user cross-read, this product's central differentiator narrows again and the table must be rewritten, not patched.

Suparbase's published plan prices and what the paid tier adds over the free one

Added 2026-08-26 when Suparbase became the fourth competitor in src/data/competitors.json. ENFORCEMENT LIVES IN competitors.json, NOT HERE: every figure below is also a cell there with a literal `probe` string, and ops/qa/compare-gate.mjs --verify re-fetches the page and fails the build when the probe is gone. This register entry exists so the claim is discoverable from the product's own fact list; it must never become a second place where the number is edited. Change competitors.json, re-run the gate, then mirror here. Continuous scanning is a PAID line item — 'Agent Sentry continuous scans' appears only on Hosted — and the comparison pages must not imply the free tier watches anything on a schedule.

What Suparbase's own site says its Security Scanner and RLS debugger test — specifically whether either signs in as a real user

Added 2026-08-26 when Suparbase became the fourth competitor in src/data/competitors.json. ENFORCEMENT LIVES IN competitors.json, NOT HERE: every figure below is also a cell there with a literal `probe` string, and ops/qa/compare-gate.mjs --verify re-fetches the page and fails the build when the probe is gone. This register entry exists so the claim is discoverable from the product's own fact list; it must never become a second place where the number is edited. Change competitors.json, re-run the gate, then mirror here. IMPORTANT on the negative claim, same rule as securifyai-open-source-scanner-scope: the site does not DENY a two-account test, it is silent on one, and every page here says 'does not publish' rather than 'cannot'. The distinction the comparison rests on is real and narrow — their probe is anon-key, their role coverage is a rolled-back SIMULATION against your own connection driven query by query, and neither is a request made by a signed-up account. If Suparbase ever ships an authenticated cross-user probe, this product's central differentiator narrows and /vs/suparbase must be rewritten rather than patched.

What Defencecore's free Supabase scanner tests, the access it needs, and whether it can test tenant isolation

The isolation claim here is stronger than the one made about SecurifyAI or Suparbase, and deliberately so: for those two the vendor is SILENT on a two-account cross-read and silence is not a denial, whereas Defencecore states positively that it does not select application rows, which excludes the test as a matter of design rather than of omission. Do not soften that distinction and do not extend it: it applies to the SCANNER. The monitor reads logs, which is a different surface, and it is credited separately. Fifth standing rule applies: this checklist is a snapshot counted 6 September 2026, not a definition.

What Defencecore's paid monitor watches, what it detects, and what it costs

Read 2026-09-06 because the search loop reported defencecore.com cited for this product's buyer queries on 4 of the last 7 days across 3 engines, and nothing on this host named it. It is a real competing vendor, not a regulator or a primary source, so the competitor-gap was genuine. NOTE THE PATHS: /pricing and /free-scanner both 404. The nav labels say Pricing and Free scanner but the real routes are the landing's own pricing section and /scan. Pricing was read off the landing, not off a pricing page, because there is no pricing page. The page's argument turns on a distinction that must not be flattened: a LOGGED RLS VIOLATION is a request Postgres REFUSED, which is the healthy case, while the failure this product tests for produces a SUCCESSFUL read by the wrong customer and therefore no log line at all. A monitor reading refusals cannot see a permission wrongly granted. Fourth standing rule was applied and is why the price is quoted from the vendor's own FAQ sentence rather than from the plan card alone.