Search
Search Results (2 CVEs found)
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2026-91154 | 1 Marcoscamara01 | 1 Ecommerce-template | 2026-09-28 | N/A |
| Missing Authentication for Critical Function (CWE-306) in the product cache revalidation Server Action (src/app/actions.ts, revalidateProducts) in MarcosCamara01 Ecommerce Template before commit ec97209 allows a remote, unauthenticated attacker to force expiration of the entire storefront product cache at will. The file declares "use server" at file scope, so every exported function compiles into a POST-invokable Server Action; revalidateProducts calls updateTag("products") with no session or role check, unlike the read-only actions in the same file which are safe by construction. Two client components under src/components/admin import the function, which causes its Server Action id to be compiled into a public /_next/static chunk that the application's admin middleware (proxy.ts) does not gate, so any unauthenticated user can extract that id from the public bundle and invoke the action directly. With cacheComponents enabled, the entire storefront (home, categories, product pages, search) is served from "use cache" entries produced by getAllProducts, getCategoryProducts and getProduct, all tagged products with an hours-long cacheLife. Repeated unauthenticated invocation of revalidateProducts keeps that cache permanently cold, forcing every visitor's request to read the full product catalog from Postgres instead of serving from cache, degrading storefront availability at near-zero attacker cost. | ||||
| CVE-2026-90896 | 1 Marcoscamara01 | 2 Ecommerce-template, Ecommerce Template | 2026-09-17 | N/A |
| 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. | ||||
Page 1 of 1.