The XSS payload fires automatically on page load when the administrator navigates to the orders listing — no click on an individual order is required. A single HTTP request chain (add to cart → submit checkout with cookie bypass → place order) permanently stores the payload, which will execute in every administrator's browser until the order is deleted or the vulnerability is patched.

The attack requires no authentication from the attacker. Guest checkout is a standard, commonly-enabled feature of e-commerce sites, providing economic incentive for admins to view new orders — making exploitation trivial to weaponize.

AFFECTED VERSIONS

VULNERABILITY DETAILS

Type: Cross-Site Scripting — Stored (CWE-79) Authentication required: None — unauthenticated (guest checkout) Primary Sink: administrator/components/com_j2store/views/orders/tmpl/default_items.php:73 Write Path: components/com_j2store/controllers/checkouts.php:535

Root Cause

The vulnerability consists of two compounding weaknesses: an input filter bypass at the write path and missing output encoding at the read path.

1. Input filter bypass — Joomla Input::getArray() misuse

J2Commerce's guest checkout controller reads address fields using $app->input->getArray($_POST). Joomla's implementation iterates the $_POST array and uses each value as a filter type (not as data), while reading the actual value from $_REQUEST:

COMPONENTS/COM_J2STORE/CONTROLLERS/CHECKOUTS.PHP:535 — WRITE PATH

LIBRARIES/VENDOR/JOOMLA/INPUT/SRC/INPUT.PHP — GETARRAY() METHOD (LINE 187)

LIBRARIES/VENDOR/JOOMLA/INPUT/SRC/INPUT.PHP — DATA SOURCE (LINE 97)

2. PHP variables_order — Cookie overrides POST in $_REQUEST

PHP's $_REQUEST is a merged superglobal built from $_GET, $_POST, and $_COOKIE. When variables_order=EGPCS (the compiled-in default for most PHP environments), Cookie (C) is listed after POST (P), so Cookie wins for conflicting keys.

Submitting first_name=RAW in the POST body causes Joomla's InputFilter::clean() to apply filter type 'Raw' (no-op) against the cookie value first_name=<svg...>, which wins in $_REQUEST.

LIBRARIES/VENDOR/JOOMLA/FILTER/SRC/INPUTFILTER.PHP — CLEAN() METHOD (LINE 215)

Net result: POST body first_name=RAW sets the filter to a no-op. Cookie first_name=<svg onload="alert(document.domain)"> wins in $_REQUEST. Joomla returns the cookie value unfiltered. J2Commerce stores it raw in j2store_orderinfos.billing_first_name.

3. Missing output encoding — admin template sinks

ADMINISTRATOR/COMPONENTS/COM_J2STORE/VIEWS/ORDERS/TMPL/DEFAULT_ITEMS.PHP:73 — PRIMARY SINK (fires on listing page load)

ADMINISTRATOR/COMPONENTS/COM_J2STORE/VIEWS/ORDER/TMPL/FORM_CUSTOMER.PHP:56 — SECONDARY SINK

This bypass works on all PHP environments except Debian/Ubuntu (which explicitly sets request_order = "GP", excluding cookies from $_REQUEST). All other major hosting environments — cPanel/Plesk shared hosting, CentOS/RHEL, XAMPP/WAMP/MAMP, Windows IIS — fall back to EGPCS, making Cookie override active out of the box with no configuration changes required.

PROOF OF CONCEPT

1. Admin Baseline — Orders Listing Before Attack

Open the J2Commerce admin orders listing as the victim administrator. This confirms the admin is actively using the panel and will encounter the payload upon next visit.

2. Extract CSRF Token from Frontend

As the unauthenticated attacker, send a GET request to the J2Commerce frontend homepage to establish a session and extract the CSRF token embedded in the page's JSON options. This token is required for subsequent POST requests.

3. Add Product to Cart

Add a product to the attacker's cart. The cart must be non-empty for the guest checkout endpoint to accept address submission.

4. KEY BYPASS — Submit Guest Checkout with Cookie Filter Trick

Submit the guest checkout address form with two conflicting values for first_name:

• POST body: first_name=RAW — Joomla interprets this as the filter type (no-op)
• Cookie: first_name=<svg...> — this wins in $_REQUEST (PHP EGPCS: Cookie > POST) and is returned unfiltered

5. Complete Shipping Validation

Submit the shipping address step using the same cookie bypass. This step sets the shipping country in session — skipping it causes a "SHIPPING_ADDRESS_NOT_FOUND" error on subsequent steps.

6. Select Payment Method

Select the payment method (cash on delivery). The payment_plugin field is not a text input susceptible to XSS.

7. Retrieve Order Confirmation Hash

Submit the confirm step to receive the order summary page containing a hidden hash field. This hash is required to finalize the order.

8. Place Order — XSS Payload Persisted to Database

Finalize the order using the hash from the previous step. The server creates the order record in joom_j2store_orderinfos with billing_first_name set to the raw XSS payload.

9. XSS Executes in Administrator Panel — Automatic on Page Load

As the victim administrator, navigate to the J2Commerce orders listing. The XSS payload fires immediately on page load — no click required. The default_items.php:73 template renders billing_first_name unescaped in the Customer column.

When admin views the order, the server response includes:

IMPACT

1. Admin Session Hijack — JavaScript executing in the administrator backend has access to the admin's session cookies (unless HttpOnly) and can exfiltrate them to an attacker-controlled server, enabling complete account takeover without requiring the admin's credentials.
2. Rogue Admin Account Creation — The XSS payload can programmatically call Joomla's user management API to create a new super-administrator account, granting the attacker persistent access even after password rotation or session invalidation.
3. Malicious Plugin Installation — With admin-level JS execution, the attacker can trigger plugin installation endpoints to upload a PHP webshell, achieving Remote Code Execution on the underlying server without further interaction.
4. Full Website Compromise — The attacker gains the ability to modify any content, extract the database (including customer PII and payment references), inject malware into frontend pages, and establish persistent backdoors — constituting a complete site takeover.
5. No Attack Prerequisite Beyond Placing an Order — Guest checkout is a standard, commonly-enabled feature of e-commerce sites. Any anonymous visitor can trigger this attack by submitting a checkout form — providing economic incentive (admins routinely review orders), making exploitation trivial to weaponize at scale.

REFERENCES

• CVE: https://www.cve.org/CVERecord?id=CVE-2026-74252
• NVD: https://nvd.nist.gov/vuln/detail/CVE-2026-74252
• GitHub Advisory: https://github.com/advisories/GHSA-42m7-jqh7-g85c
• Vendor Security Announcement: https://www.j2commerce.com/blog/security-announcement-releases-3-3-21-4-0-21-and-4-1-6
• Vendor Repository: https://github.com/j2store/J2Store