CISA incluye fallas de WSO2 y Adobe Commerce en su lista

La agencia estadounidense de ciberseguridad CISA incluyó el jueves (24) dos fallas críticas en su catálogo de vulnerabilidades explotadas activamente, el KEV: la CVE-2026-5430, que afecta a productos de gestión de APIs de WSO2, y la CVE-2026-71362, en Adobe Commerce y Magento Open Source. La inclusión se basa en evidencia de explotación en ataques reales, según el aviso de la agencia, y otorga a las agencias civiles federales de EE.UU. hasta el 27 de septiembre para aplicar las correcciones.

Ninguna organización ha sido identificada públicamente como víctima de los ataques hasta el cierre de este artículo.

WSO2: la puerta de entrada de las APIs

La CVE-2026-5430 afecta al WSO2 API Manager en las versiones 4.1.0 a 4.6.0, al API Control Plane y al Traffic Manager en las versiones 4.5.0 y 4.6.0, y al Universal Gateway en las mismas versiones. El catálogo de CISA registra la falla como path traversal. Análisis técnicos de investigadores describen un mecanismo diferente: un desvío de autenticación en el que el sistema, al recibir un token JWT firmado con un algoritmo no soportado, deja de verificar la firma y acepta las credenciales como legítimas. En ambas interpretaciones, el resultado es el mismo, con posibilidad de toma de cuentas administrativas.

La empresa de seguridad watchTowr informó sobre intentos de explotación contra sus honeypots desde al menos el 13 de septiembre, según The Hacker News. Es decir, la ventana entre el primer ataque observado y la inclusión en el catálogo fue de 11 días.

El peso de la falla proviene de la función del producto. Un gateway de APIs se encuentra en el borde de la arquitectura, autenticando llamadas entre sistemas internos, socios y aplicaciones. WSO2, empresa de origen cingalés con operaciones en EE.UU. y Europa, vende esta capa a bancos, operadores y gobiernos, que la utilizan precisamente para exponer servicios a terceros. Una credencial administrativa forjada en este punto da acceso al inventario de APIs y a las políticas que controlan quién puede llamar a qué.

Adobe Commerce: sesión intercambiada, cuenta tomada

La CVE-2026-71362 tiene una calificación CVSS de 9.1 y está clasificada como autorización incorrecta. Según Sansec, empresa especializada en seguridad de comercio electrónico, el problema radica en el tratamiento de la identidad del cliente dentro de una sesión activa: un atacante sin autenticación puede cambiar la sesión por la de otro cliente y asumir la cuenta, con acceso a datos personales e historial de pedidos.

Adobe publicó la corrección en el boletín APSB26-92, el 11 de agosto, con versiones corregidas para Adobe Commerce 2.4.4 a 2.4.9, Magento Open Source 2.4.6 a 2.4.9 y Commerce B2B 1.3.3 a 1.5.3. El boletín corrigió siete vulnerabilidades, cinco de ellas críticas.

Sansec informó haber detectado y bloqueado los primeros intentos de explotación poco después de la publicación del boletín, aún en agosto. La inclusión en el KEV, seis semanas después, formaliza la lectura: para la CISA, hay explotación real.

Seis semanas es tiempo suficiente para que tiendas con un proceso maduro hayan aplicado la corrección, e insuficiente para las demás. En entornos con personalizaciones pesadas, comunes en el comercio minorista, cada parche pasa por pruebas de regresión antes de implementarse, y el calendario de mantenimiento rara vez acompaña al calendario de los atacantes, que comenzaron a probar la falla en cuestión de días.

Dónde se propaga el riesgo

El plazo del 27 de septiembre solo aplica al gobierno federal estadounidense, pero el catálogo KEV funciona como referencia de priorización para equipos de seguridad privados en varios países. La falla de WSO2 ya ha recibido alertas en la prensa especializada de Australia, y la de Adobe Commerce ha sido tratada en avisos de universidades y consultoras de comercio electrónico en EE.UU. y Europa.

En el comercio minorista, Magento mantiene una base relevante de tiendas de mediana capacidad en Europa y América Latina, incluyendo Brasil, muchas de ellas operadas por agencias e integradores externos. En este modelo, el parche depende de un contrato de soporte que no siempre prevé respuesta de emergencia. La pregunta para el CISO de retail es quién, en la cadena de proveedores, aplicó el APSB26-92, y cuándo.

Para bancos y fintechs que exponen APIs a través de WSO2, la verificación es más directa: la versión en producción, la fecha del último parche y los registros de autenticación desde el 13 de septiembre. Un token aceptado sin una firma válida no deja la misma huella que un inicio de sesión con una contraseña incorrecta, y la auditoría debe buscar esto específicamente.