The CVSS 8.6 framing obscures what makes this vulnerability analytically significant: it's a systems interaction failure, not a code-level sanitization mistake. The attacker bypasses J2Commerce's input filtering not by breaking the sanitizer, but by exploiting a filter bypass in Joomla's Input::getArray() combined with PHP's variables_order=EGPCS behavior, where $_COOKIE values override $_POST values in $_REQUEST. This means malicious input arrives through a vector the application doesn't expect to be user-controlled.
Three layers each made implicit assumptions about who controls which input vector: the PHP runtime, the Joomla framework, and the J2Commerce application. Their intersection creates the bypass. This is why the 'unauthenticated' label matters — guest checkout is maximally exposed by design, accepting hostile input from parties with zero trust relationship. There's no account to ban, no session context to invalidate, and the attack leaves no audit trail until the payload fires in an admin's session.
The blast radius of stored XSS in billing address fields is also underappreciated. The payload propagates through order confirmation emails to other customers, exported CSV reports, store dashboards, and potentially third-party integrations. Generic stored XSS has limited reach; e-commerce stored XSS is multi-channel.
The real question is how many other Joomla extensions silently inherit this same Input::getArray() + EGPCS interaction flaw. J2Commerce is likely not unique. The patch fixes this instance, but the underlying architectural problem — Joomla's input abstraction silently leaking PHP runtime behavior — remains. This warrants a framework-level audit of every extension using Input::getArray(), not just a single-component patch.