CVE-2026-90896

The GET /api/stripe/checkout_sessions endpoint in MarcosCamara01's Ecommerce Template lacks any authentication or ownership check, directly calling stripe.checkout.sessions.retrieve() on the supplied session id and returning the full session object to whoever asks. An unauthenticated remote attacker who obtains a valid Stripe Checkout Session id (cs_...) can therefore read the buyer's name, email, phone, billing address, amount paid, and internal userId. Session ids leak easily in practice because the template's success_url places the session id in the browser URL (/result?session_id=...), exposing it via Referer headers, analytics tools, server access logs, and shared-machine browser history. All deployments built from the template before commit 91e273c are affected; sibling endpoints like POST /api/stripe/payment already enforced auth.api.getSession(), so only this handler was unprotected. No public PoC exists, the flaw is not in the CISA KEV catalog, and no exploitation has been reported.

What to do: Update to commit 91e273c or later, and verify the checkout_sessions handler now enforces an authenticated session and matches the session's userId to the caller before returning data. If you cannot update immediately, block or restrict GET /api/stripe/checkout_sessions at the reverse proxy/WAF and audit access logs for unauthenticated hits carrying cs_ ids. Also stop putting CHECKOUT_SESSION_ID in the success_url (use a server-side lookup after redirect) and scrub session ids from logs and analytics to cut off the id-leakage path.