Ecommerce Template EUVD-2026-108213

Requires a valid authenticated account on the targeted installation (PR:L); any low-privileged shopper suffices, with no user interaction needed. The flaw is present in the template's default deployment, where a single DATABASE_URL is used both to run migrations (making that role the table owner) and for the runtime app, so PostgreSQL does not apply the RLS policies to the owner connection. Exploitation is eased by cart_items.id and wishlist.id being sequential bigserial identifiers that can be enumerated, and the update path returning the modified row including its owning user_id. Limiting factors: an account on the specific installation is mandatory, and an operator who separated the migration and runtime roles or applied the 0004_force_rls fix (FORCE ROW LEVEL SECURITY) would not be exposed via the owner-connection path.

Signals are moderate and broadly consistent. The CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:L/UI:N) and the 7.1 base score describe a remotely reachable, low-complexity flaw that requires an authenticated account (PR:L), with high integrity impact on other users' data (VI:H), a minor confidentiality leak (VC:L), and no availability or subsequent-system impact. The vuln.today Decision label is this_week - a real but non-emergency priority - and it is not in CISA KEV; no EPSS score was supplied, so widespread-exploitation probability cannot be quantified from the input. No confirmed working exploit code is provided; the reporter (Secur0) published a public technical advisory describing the IDOR. The practical risk driver is that exploitation is trivial once authenticated: identifiers are sequential bigserial values that are easily enumerated, the intended RLS defense is silently inactive, and the update path even returns the victim's user_id. The main dampeners are that an account on the specific installation is required and the affected product is a niche open-source template rather than widely deployed software, which argues for targeted rather than mass exploitation. No key signals conflict; the chief gap is the absence of EPSS/KEV data to gauge real-world exploitation breadth.

An attacker registers an ordinary shopper account on an affected installation and authenticates. They enumerate the sequential cart_items.id and wishlist.id values and invoke the delete/update operations, which match rows by primary key alone; because the tables never had FORCE ROW LEVEL SECURITY set and the app connects as the table owner, PostgreSQL ignores the per-user policies and the calls succeed against other shoppers' rows. No exploit is confirmed as working code, but the reporter published a public technical advisory detailing the flaw.