CVE-2026-115453: Ecommerce Template Auth Bypass Vulnerability

CVE-2026-115453 Overview

CVE-2026-115453 is an authorization bypass vulnerability [CWE-639] in the MarcosCamara01 Ecommerce Template. Any authenticated user can delete and modify cart and wishlist rows belonging to other users. The flaw stems from repository methods that match rows by primary key alone, with no predicate on the owning user. The template relies entirely on PostgreSQL row-level security (RLS) for per-user authorization, but the policies never take effect because the application connects as the table owner.

Critical Impact

Authenticated attackers can enumerate sequential bigserial identifiers to destroy or alter cart and wishlist contents of any other account on the installation.

Affected Products

• MarcosCamara01 Ecommerce Template (open-source project)
• Deployments using a single DATABASE_URL for both migrations and application runtime
• Installations prior to migration 0004_force_rls

Discovery Timeline

• 2026-10-22 - CVE CVE-2026-115453 published to NVD
• 2026-10-22 - Last updated in NVD database

Technical Details for CVE-2026-115453

Vulnerability Analysis

The vulnerability affects three repository methods in src/lib/db/drizzle/repositories/: cartRepository.delete(), cartRepository.updateQuantityInternal(), and wishlistRepository.delete(). Each method targets rows using only the primary key. None include a predicate restricting the operation to the authenticated user.

The project migrations run ALTER TABLE ... ENABLE ROW LEVEL SECURITY and define policies comparing app.current_user_id() with user_id. However, the migrations never execute ALTER TABLE ... FORCE ROW LEVEL SECURITY. PostgreSQL does not apply RLS policies to the role that owns a table unless FORCE is set.

Because the template uses one DATABASE_URL for both migrations and runtime, the application connects as the table owner. Every policy is silently ignored. The update path returns the modified row, exposing the identifier of the owning user and confirming successful cross-tenant writes.

Root Cause

Two defects combine to produce the bypass. First, repository code assumes authorization is enforced at the database layer rather than in query predicates. Second, the RLS policies are never forced, so the owner role used by the app bypasses them.

Attack Vector

An authenticated user enumerates sequential cart_items.id or wishlist.id values and submits delete or update requests against those identifiers. The server executes the operation on another user's row without any ownership check, and the response reveals the victim's user_id.

-- Conceptual illustration of the vulnerable predicate
-- Vulnerable: matches by primary key only
DELETE FROM cart_items WHERE id = $1;
UPDATE cart_items SET quantity = $2 WHERE id = $1 RETURNING *;

-- Expected: scope by owning user
DELETE FROM cart_items WHERE id = $1 AND user_id = $current_user;

Detection Methods for CVE-2026-115453

Indicators of Compromise

• Database audit records showing DELETE or UPDATE statements against cart_items or wishlist where the resulting user_id differs from the session's authenticated user.
• Application logs containing bursts of sequential identifier access patterns against cart or wishlist endpoints.
• User reports of missing or altered cart or wishlist contents without corresponding account activity.

Detection Strategies

• Enable PostgreSQL statement logging on cart and wishlist tables and correlate executed SQL with the authenticated session user.
• Compare the user_id returned by UPDATE ... RETURNING statements against the application's authenticated principal, flagging mismatches.
• Inspect running database sessions to confirm whether the application role is the table owner, which indicates RLS policies are not enforced.

Monitoring Recommendations

• Alert on repeated 2xx responses to cart or wishlist mutation endpoints targeting non-sequential or wide ranges of IDs from a single account.
• Monitor commit history and migration state for the presence of migration 0004_force_rls across environments.
• Track role ownership of application tables and alert if the runtime role matches the owner.

How to Mitigate CVE-2026-115453

Immediate Actions Required

• Apply the upstream patch that adds migration 0004_force_rls, which runs ALTER TABLE ... FORCE ROW LEVEL SECURITY on affected tables.
• Add explicit user_id predicates to cartRepository.delete(), cartRepository.updateQuantityInternal(), and wishlistRepository.delete().
• Separate the migration role from the runtime role so the application never connects as the table owner.

Patch Information

The fix is published in commit adf7dedbb41894c0bad0b33a26999b0da7e967b7 and introduces migration 0004_force_rls.sql. Additional analysis is available in the Secur0 CVE-2026-115453 Analysis.

+-- ========================================
+-- FORCE ROW LEVEL SECURITY
+-- ========================================
+-- Migrations 0002 and 0003 run `ALTER TABLE ... ENABLE ROW LEVEL SECURITY`
+-- and create the per-user policies. That is not sufficient: PostgreSQL does
+-- NOT apply RLS policies to the role that OWNS the table unless
+-- `FORCE ROW LEVEL SECURITY` is also set.
+--
+-- This template uses a single DATABASE_URL both to run migrations (which
+-- CREATE the tables, making that role the owner) and for the app at runtime,
+-- so the app connects as the table owner and every policy from 0002/0003 is
+-- silently ignored. See report #1628.
+--
+-- FORCE is idempotent and safe to re-run.
+
+DO $$
+DECLARE
+  target_table TEXT;
+  rls_tables CONSTANT TEXT[] := ARRAY[
+    'user',
+    'session',
+    'account',
+    'verification',
+    'products_items',
+    'products_variants',
+    'cart_items',

Source: GitHub commit adf7dedb

Workarounds

• Create a dedicated low-privilege PostgreSQL role for the application that does not own the tables, and grant it only the DML required.
• Manually run ALTER TABLE cart_items FORCE ROW LEVEL SECURITY; and ALTER TABLE wishlist FORCE ROW LEVEL SECURITY; until the patched migration is deployed.
• Add server-side ownership checks in cart and wishlist handlers as a defense-in-depth measure independent of database policy enforcement.

# Configuration example: apply FORCE RLS and switch to a non-owner runtime role
psql "$DATABASE_URL" <<'SQL'
ALTER TABLE cart_items FORCE ROW LEVEL SECURITY;
ALTER TABLE wishlist   FORCE ROW LEVEL SECURITY;

CREATE ROLE app_runtime LOGIN PASSWORD 'change-me';
GRANT SELECT, INSERT, UPDATE, DELETE ON cart_items, wishlist TO app_runtime;
SQL

# Point the application at the non-owner role
export DATABASE_URL="postgres://app_runtime:change-me@db-host:5432/app"