Skip to content
KitploitKITPLOIT
HerramientasExploitsBlog
Log in
Enviar
HerramientasExploitsBlog
Enviar

¡Herramientas de Hacking, PenTest y Ciberseguridad para tu Arsenal de Seguridad!

Kitploit es un directorio de herramientas de hacking, ciberseguridad y pentesting. Descubre las últimas actualizaciones de proyectos para encontrar vulnerabilidades, analizar sistemas, automatizar pruebas y fortalecer tu seguridad.

FeedsContactoPrivacidad© 2026 Kitploit

Directorio de Herramientas

Categorías

Ver todas las categorías
Loading categories
CVE-2026-74252 — XSS almacenado en el pago como invitado de J2Commerce mediante omisión del filtro de cookies | Kitploit
Herramientas/GitHubGitHub/toanln-cov/cve-2026-74252
Análisis de VulnerabilidadesExplotaciónExplotación de Aplicaciones WebSeguridad Web
GitHubtoanln-cov/cve-2026-74252

CVE-2026-74252

XSS almacenado en el pago como invitado de J2Commerce mediante omisión del filtro de cookies

Ver Repositorio
12hace 1 mesAún no revisado

Más Populares

Ver todos →

Descubre las herramientas más usadas por nuestra comunidad.

Explora todas las herramientas

Explora nuestra colección de herramientas

Ver todas las herramientas →
Compartir

XSS Almacenado en el Checkout de Invitados de J2Commerce mediante Bypass de Filtro de Cookies

J2Commerce (com_j2store) ≤ 4.1.5 — Un atacante no autenticado almacena un payload XSS que se ejecuta automáticamente en el navegador del administrador al cargar la página

CVE CVSS v4.0 CWE-79 Affected Researcher


RESUMEN

J2Commerce 4.1.5 es vulnerable a Cross-Site Scripting Almacenado (XSS) a través de los campos de dirección de facturación del checkout de invitados. Un atacante no autenticado explota un bypass de filtro en Input::getArray() de Joomla combinado con variables_order=EGPCS de PHP (la Cookie sobrescribe POST en $_REQUEST) para almacenar HTML sin sanitizar en campos como billing_first_name. Estos campos se imprimen directamente en el panel de administración de pedidos sin htmlspecialchars(), lo que provoca que el payload se ejecute en el navegador del administrador.

El payload XSS se dispara automáticamente al cargar la página cuando el administrador navega al listado de pedidos; no se requiere ningún clic en un pedido individual. Una sola cadena de solicitudes HTTP (añadir al carrito → enviar el checkout con el bypass de cookie → realizar el pedido) almacena el payload de forma permanente, que se ejecutará en el navegador de cada administrador hasta que el pedido se elimine o la vulnerabilidad se parchee.

El ataque no requiere autenticación por parte del atacante. El checkout de invitados es una función estándar y habitualmente habilitada en los sitios de comercio electrónico, lo que proporciona un incentivo económico para que los administradores vean los pedidos nuevos, haciendo que la explotación sea trivial de convertir en arma.


VERSIONES AFECTADAS

COMPONENTEVULNERABLEPROBADO ENCORREGIDO
J2Commerce (com_j2store)1.0.0 – 4.1.54.1.5 en Joomla 5.4.7 + MySQL 8.03.3.21 / 4.0.21 / 4.1.6

DETALLES DE LA VULNERABILIDAD

Tipo: Cross-Site Scripting — Almacenado (CWE-79) Autenticación requerida: Ninguna — no autenticado (checkout de invitados) Sink principal: administrator/components/com_j2store/views/orders/tmpl/default_items.php:73 Ruta de escritura: components/com_j2store/controllers/checkouts.php:535

Causa raíz

La vulnerabilidad se compone de dos debilidades que se combinan: un bypass del filtro de entrada en la ruta de escritura y la falta de codificación de salida en la ruta de lectura.

1. Bypass del filtro de entrada — mal uso de Input::getArray() de Joomla

El controlador de checkout de invitados de J2Commerce lee los campos de dirección utilizando $app->input->getArray($_POST). La implementación de Joomla itera el array $_POST y utiliza cada valor como un tipo de filtro (no como dato), mientras lee el valor real desde $_REQUEST:

COMPONENTS/COM_J2STORE/CONTROLLERS/CHECKOUTS.PHP:535 — RUTA DE ESCRITURA

$data = $app->input->getArray($_POST);

LIBRARIES/VENDOR/JOOMLA/INPUT/SRC/INPUT.PHP — MÉTODO GETARRAY() (LÍNEA 187)

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 — FUENTE DE DATOS (LÍNEA 97)

$this->data = $source ?? $_REQUEST;  // Reads from $_REQUEST, not $_POST

2. variables_order de PHP — la Cookie sobrescribe POST en $_REQUEST

$_REQUEST de PHP es una superglobal combinada construida a partir de $_GET, $_POST y $_COOKIE. Cuando variables_order=EGPCS (el valor predeterminado compilado en la mayoría de entornos PHP), Cookie (C) aparece después de POST (P), por lo que la Cookie gana en el caso de claves en conflicto.

Enviar first_name=RAW en el cuerpo de la solicitud POST hace que InputFilter::clean() de Joomla aplique el tipo de filtro 'Raw' (sin operación) al valor de la cookie first_name=<svg...>, que gana en $_REQUEST.

LIBRARIES/VENDOR/JOOMLA/FILTER/SRC/INPUTFILTER.PHP — MÉTODO CLEAN() (LÍNEA 215)

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

Resultado neto: el cuerpo POST first_name=RAW configura el filtro como una operación nula. La cookie first_name=<svg onload="alert(document.domain)"> gana en $_REQUEST. Joomla devuelve el valor de la cookie sin filtrar. J2Commerce lo almacena sin procesar en j2store_orderinfos.billing_first_name.

3. Codificación de salida ausente — sinks de la plantilla de administración

ADMINISTRATOR/COMPONENTS/COM_J2STORE/VIEWS/ORDERS/TMPL/DEFAULT_ITEMS.PHP:73 — SINK PRINCIPAL (se dispara al cargar la página de listado)

// 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 SECUNDARIO

// 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; ?>

Este bypass funciona en todos los entornos PHP excepto Debian/Ubuntu (que establece explícitamente request_order = "GP", excluyendo las cookies de $_REQUEST). Todos los demás entornos de alojamiento importantes — hosting compartido cPanel/Plesk, CentOS/RHEL, XAMPP/WAMP/MAMP, Windows IIS — recurren a EGPCS, activando la sobrescritura por Cookie por defecto sin necesidad de cambios de configuración.


PRUEBA DE CONCEPTO

1. Línea base del administrador — Listado de pedidos antes del ataque

Abra el listado de pedidos de administración de J2Commerce como el administrador víctima. Esto confirma que el administrador está usando activamente el panel y encontrará el payload en su próxima visita.

s1-step1-admin-orders-baseline

2. Extraer el token CSRF del frontend

Como atacante no autenticado, envíe una solicitud GET a la página de inicio del frontend de J2Commerce para establecer una sesión y extraer el token CSRF incrustado en las opciones JSON de la página. Este token es necesario para las solicitudes POST posteriores.

s1-step2-csrf-token-extract

3. Añadir producto al carrito

Añada un producto al carrito del atacante. El carrito debe estar no vacío para que el endpoint de checkout de invitados acepte el envío de la dirección.

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

Descargar herramienta