CVE-2026-28154

If you're running WooCommerce on a commercial WordPress theme, check whether your theme came from snstheme — two of their WooCommerce themes (Samex at version 2.5 and M.Anh at version 1.7) contain identical reflected XSS in how they handle request parameters on WooCommerce pages. The same vulnerability appearing in two separate products from one vendor isn't coincidence; it's the fingerprint of either shared framework code that never received security vetting or a development culture where input escaping simply isn't part of the review process. The CVSS 7.1 score understates this. These themes live on e-commerce sites running checkout flows, account logins, and potentially admin sessions. Reflected XSS on those pages is a direct path to session cookie exfiltration — not a theoretical risk, but a live attack surface for stolen credentials and pivoted admin access. The base CVSS metric wasn't built to capture what happens when XSS meets a payment processing context. Your priority actions: First, verify which theme version is installed. Version 1.7 or 2.5 on a snstheme product almost certainly means you're running code that has received zero security review since active development stopped — ThemeForest-era commercial themes that reached these version numbers are typically in minimal maintenance or fully abandoned. Second, assume the vulnerability exists in any WooCommerce template file that echoes request parameters without escaping — check search results pages, product filter handlers, and any template doing direct echo or printf of GET/POST data. Third, if you can't confirm a security patch was applied by the vendor, treat the theme as unmaintained and plan migration to an actively supported alternative. The exposure window between disclosure and actual patch deployment in commercial WordPress themes routinely stretches to months or years, not days.

Reviewed through automated stages and approved by a human before publication.