CVE-2026-115453 is an authorization bypass vulnerability in the MarcosCamara01 Ecommerce Template affecting the cart and wishlist repositories. The flaw allows any authenticated user to delete or modify cart and wishlist items of other users due to improper enforcement of PostgreSQL row level security (RLS). The application connects to the database as the table owner, bypassing RLS policies that rely on user ID checks. Sequential identifiers enable enumeration of other users' items, leading to unauthorized data modification and deletion.
CVE-2026-115450 is a vulnerability in the MarcosCamara01 Ecommerce Template that allows an authenticated user without special privileges to manipulate the checkout process. The flaw arises because the API accepts separate parameters for the product variant and the Stripe price ID without verifying their consistency. This enables users to pay the price of a cheaper product while ordering a more expensive one, leading to incorrect order records and financial loss. The Stripe price IDs are publicly accessible, making exploitation straightforward and repeatable. A fix has been implemented in a specific commit.
CVE-2026-91154 is a vulnerability in the MarcosCamara01 Ecommerce Template that allows unauthenticated attackers to invoke a critical server action to forcibly expire the entire product cache. This occurs because the revalidateProducts function lacks authentication checks and is exposed publicly via a client component, enabling attackers to repeatedly disable caching and degrade storefront availability by forcing database reads on every request.
Missing Authentication for Critical Function (CWE-306) in the checkout session lookup handler (src/app/api/stripe/checkout_sessions/route.ts), exposed at GET /api/stripe/checkout_sessions, in MarcosCamara01 Ecommerce Template before commit 91e273c allows a remote, unauthenticated attacker holding a valid Stripe Checkout Session id (cs_...) to retrieve the full session object, including the buyer's name, email, phone, billing address, amount paid and internal userId, because the GET handler calls stripe.checkout.sessions.retrieve() and returns the result without checking for an authenticated session or session ownership. Sibling endpoints such as POST /api/stripe/payment already enforced authentication via auth.api.getSession(); this endpoint had no access control whatsoever. The session_id is exposed in the buyer's own browser URL after payment (success_url = /result?session_id={CHECKOUT_SESSION_ID}), so it leaks through Referer headers, analytics tools, server access logs and shared-machine browser history, resulting in disclosure of the buyer's personal data to an unauthenticated actor.