Live › vulnerability › CVE-2026-115453
Go to dashboardThe MarcosCamara01 Ecommerce Template deletes and modifies cart and wishlist rows by primary key without checking the owning user. Any logged-in user can change or delete other accounts' cart and wishlist contents in the same installation.
Summary written from the sources below. Check the originals before acting.
First seen by InfraStack 2026-10-23 21:57 UTC. All times on this page are UTC.
Installations of the template where the application connects to PostgreSQL as the owner of the cart and wishlist tables, which is the default setup described by the sources. Any store with registered users is exposed, because any authenticated user can reach these operations. Deployments where the application uses a separate non-owner database role, or where the owner-bypass is closed with forced row level security, can skip it.
No product ranges from the sources yet.
DATABASE_URL for migrations and runtime.SELECT relname, relrowsecurity, relforcerowsecurity FROM pg_class WHERE relname IN ('cart_items','wishlist'); and look for relforcerowsecurity = false.src/lib/db/drizzle/repositories/ for delete and update calls on cart_items and wishlist that have no user_id condition.ALTER TABLE ... FORCE ROW LEVEL SECURITY to the migrations for cart_items and wishlist.user_id predicate to the cart and wishlist delete and update queries.Each row is the first time that source carried this signal. The analyst’s rows are its own findings.
Authorization Bypass Through User-Controlled Key (CWE-639) in the cart and wishlist repositories of MarcosCamara01 Ecommerce Template allows any authenticated user to delete and modify the cart and wishlist rows of any other user, because cartRepository.delete(), cartRepository.updateQuantityInternal() and wishlistRepository.delete() in src/lib/db/drizzle/repositories/ match rows by primary key alone, with no predicate on the owning user, and the per user authorization for those three operations rests on PostgreSQL row level security. The migrations run ALTER TABLE ... ENABLE ROW LEVEL SECURITY and create policies comparing app.current_user_id() with user_id, but never ALTER TABLE ... FORCE ROW LEVEL SECURITY, and PostgreSQL does not apply policies to the role that owns a table. The template uses one DATABASE_URL both to run the migrations, which create the tables, and for the application at runtime, so the application connects as the owner of the tables and the policies do not apply to it. cart_items.id and wishlist.id are sequential bigserial values, so the identifiers of rows belonging to other users can be enumerated, and the update path returns the modified row, which carries the identifier of the user it belongs to. This results in the destruction and modification of cart and wishlist contents belonging to other accounts of the installation.
This page as .md · .json · in your agent: get_signal("CVE-2026-115453")
NVD data is provided by NIST and is public domain · EPSS scores by FIRST, used with attribution. Posts quoted belong to their authors.