CVE-2026-115453 in Ecommerce Template
Summary
by MITRE • 10/23/2026
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.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 10/23/2026
The vulnerability identified as CWE-639 represents a critical authorization bypass within the MarcosCamara01 Ecommerce Template, specifically affecting the cart and wishlist repositories. The core technical flaw stems from an incorrect implementation of PostgreSQL Row Level Security (RLS) policies in conjunction with how the application connects to the database. While migrations correctly enable RLS by running ALTER TABLE ... ENABLE ROW LEVEL SECURITY and defining policies that compare app.current_user_id() against user_id, they fail to execute ALTER TABLE ... FORCE ROW LEVEL SECURITY. This omission is significant because PostgreSQL does not apply row-level security policies to the role that owns a table unless forced. Consequently, any database connection established as the owner of these tables bypasses the intended access controls entirely.
The application architecture exacerbates this issue by utilizing a single DATABASE_URL for both running migrations and operating at runtime. This design choice means the application connects to the PostgreSQL instance using the credentials of the table owner rather than a restricted role with limited privileges. As a result, when functions such as cartRepository.delete(), cartRepository.updateQuantityInternal(), or wishlistRepository.delete() are invoked, they operate under the context of the database owner. Since RLS policies do not apply to this privileged role, these operations match rows solely by their primary key without verifying ownership through predicates on user_id. This allows any authenticated user who can supply a valid row identifier to manipulate data belonging to other users.
The operational impact is severe due to the predictable nature of the database identifiers. The cart_items.id and wishlist.id columns are defined as sequential bigserial values, which means they increment monotonically. An attacker can easily enumerate these identifiers by iterating through likely ranges or observing responses from successful operations on their own data. Because the update path returns the modified row, it carries the identifier of the user to whom that row belongs, providing further confirmation for enumeration attacks. This predictability enables an adversary to systematically target specific users' carts and wishlists without needing complex reconnaissance techniques.
The consequences of this vulnerability include the unauthorized deletion or modification of shopping cart contents and wishlist items belonging to other accounts on the installation. Attackers can remove items from a victim's cart, potentially disrupting their purchasing workflow or causing financial loss if they manipulate pricing logic associated with those items. Similarly, altering wishlists allows for social engineering attacks or data leakage regarding user preferences. This aligns with ATT&CK technique T1078, Valid Accounts, as the attacker leverages legitimate authentication credentials to perform unauthorized actions that should be restricted by identity verification mechanisms.
To mitigate this vulnerability, it is imperative to enforce row-level security policies on all tables containing sensitive user data by executing ALTER TABLE ... FORCE ROW LEVEL SECURITY during migration processes. This ensures that RLS applies even when queries are executed by the table owner or superuser roles within the application context. Additionally, the database connection strategy should be revised so that the runtime application connects using a dedicated role with minimal privileges rather than the table owner. This principle of least privilege ensures that even if code logic is flawed, the underlying security controls enforced by RLS will prevent unauthorized access to rows belonging to other users. Implementing these changes restores the intended isolation between user data and prevents enumeration-based attacks on sequential identifiers.