WSO2 y Adobe Commerce: las nuevas fallas críticas que CISA agregó a KEV (y por qué importan en LATAM)

octubre 3, 2026 Alfonso Moreno | Sysadmin Senior 30 Visitas 12 min de lectura

TL;DR — Lo que vas a tener al final

Tiempo de setup: 30 minutos a 2 horas dependiendo de la complejidad del entorno.
Requisitos: Acceso root, Linux moderno, conexión a internet para descargar dependencias.
Resultado: Servicio funcional y estable, documentado paso a paso.
Troubleshooting: Logs estándar en /var/log/, comandos de verificación al final de cada sección.

Qué añadió CISA al KEV el 24 de septiembre de 2026

El jueves 24 de septiembre de 2026, la Agencia de Ciberseguridad y Seguridad de Infraestructura de Estados Unidos (CISA) añadió dos vulnerabilidades críticas a su catálogo Known Exploited Vulnerabilities (KEV). Una afecta a la plataforma de gestión de API WSO2 y la otra a Adobe Commerce y Magento, el software de Adobe para construir tiendas online. Ambas cuentan con evidencia verificable de explotación activa en producción.

Las dos fallas son:

CVE-2026-5430 (CVSS 9.8) — una vulnerabilidad en WSO2 API Control Plane, API Manager, Traffic Manager y Universal Gateway que permite a un atacante remoto sin autenticación tomar el control administrativo completo del plano de gestión de API.
CVE-2026-71362 (CVSS 9.1) — una falla de autorización incorrecta en Adobe Commerce y Magento Open Source que permite a un atacante remoto sin autenticación tomar el control de sesiones de clientes existentes y escalar privilegios sin que el usuario objetivo interactúe.

La relevancia para sysadmins en Suramérica es directa: WSO2 es usado por cerca de mil organizaciones a nivel global, incluyendo banca, gobierno, telecomunicaciones y logística, sectores con fuerte presencia en Argentina, Chile, Colombia, Brasil y México. Adobe Commerce y Magento, por el contrario, son la columna vertebral de buena parte del e-commerce regional, desde tiendas independientes hasta retailers medianos que corren sobre LAMP/LEMP.

Lo que ya sabemos sobre la explotación antes del anuncio

Uno de los puntos más importantes de esta alerta es el desfase entre la inclusión en KEV y la actividad de los atacantes. La firma de threat intelligence watchTowr confirmó que detectó intentos de explotación en honeypots desde al menos el 13 de septiembre de 2026, once días antes de la publicación del aviso. Yordan Ganchev, principal threat intelligence specialist en watchTowr, lo dijo sin rodeos: “capturamos tokens JWT falsificados contra la falla el 13 de septiembre y reproducimos la vulnerabilidad nosotros mismos, a pesar de la falta de detalles técnicos públicos. Esa fue evidencia directa de que no era una vulnerabilidad meramente teórica o un puntaje crítico sobre el papel. Era explotable, y los atacantes ya estaban actuando sobre ella.”

Para la falla de Adobe Commerce/Magento, la firma holandesa de seguridad e-commerce Sansec detectó y bloqueó intentos de explotación en agosto de 2026. La firma Previdian registró además un intento único desde una dirección IP australiana contra sus sensores honeypot el 10 de septiembre de 2026. Adobe aún no había actualizado su advisory para confirmar oficialmente el estado de explotación al momento del aviso de CISA, lo que significa que la inclusión en KEV se basó en observaciones externas, no en confirmación del vendor.

CVE-2026-5430: el bypass de autenticación JWT en WSO2

El advisory oficial de WSO2, publicado el 3 de mayo de 2026 bajo la referencia WSO2-2026-5328, describe CVE-2026-5430 como un bug de JWT algorithm confusion: cuando el header alg de un token JWT nombra un algoritmo que el servidor no soporta, la función de validación de WSO2 falla abierta y acepta los claims del token sin verificar nunca la firma. Un token falsificado de ese modo otorga acceso administrativo completo al plano de gestión del API Manager.

El detalle interesante es la discrepancia entre dos lecturas oficiales del mismo identificador. El advisory de WSO2 describe una vulnerabilidad de confusión algorítmica en JWT que alcanza privilegios administrativos vía token falsificado. La entrada del catálogo KEV de CISA, por el contrario, describe CVE-2026-5430 como una “vulnerabilidad de path traversal en múltiples productos WSO2” que “podría permitir la subida de archivos sin restricciones y conducir a ejecución remota de código.” El catálogo federal y el writeup del vendor sobre el mismo número CVE describen dos vulnerabilidades distintas. Lo más prudente para un sysadmin es asumir el peor escenario —que ambas rutas de ataque son viables— y aplicar el parche de inmediato.

Las versiones afectadas son API Manager 4.1.0 hasta 4.6.0, además de las líneas API Control Plane, API Universal Gateway y Traffic Manager, en todos los niveles de actualización previos a los parches específicos del vendor.

Versiones afectadas por producto

Producto WSO2	Rango afectado	Acción
API Manager	4.1.0 a 4.6.0 (builds previos al parche)	Aplicar update del vendor
API Control Plane	Versiones hasta el nivel de actualización vulnerable	Aplicar update del vendor
API Universal Gateway	4.5.0 / 4.6.0 (builds previos al parche)	Aplicar update del vendor
Traffic Manager	Versiones hasta el nivel de actualización vulnerable	Aplicar update del vendor

Cómo verificar si tu infraestructura WSO2 está expuesta

El audit binario más directo es identificar la versión de cada componente WSO2 desplegado y compararla con la matriz de versiones afectadas publicada por el vendor. En ambientes productivos donde WSO2 corre detrás de un reverse proxy o un API gateway externo, conviene revisar además los logs de autenticación en busca de tokens JWT con header alg inusual (por ejemplo none, HS256 cuando el servidor espera RS256, o algoritmos custom).

# Buscar tokens con alg=none o algoritmos no esperados en logs de access
grep -E 'alg[":= ]*(none|HS[0-9]+|RS[0-9]+|ES[0-9]+)' 
  /var/log/wso2/*.log /var/log/nginx/access.log 2>/dev/null | head -20
# Identificar versión del API Manager desplegado
cat /opt/wso2am/4.6.0/repository/conf/wso2am.xml 2>/dev/null 
  | grep -i 'version|product' | head -5
# Si corres WSO2 en Kubernetes/OpenShift
kubectl get deploy -A -l app=wso2 -o jsonpath='{range .items[*]}{.metadata.name}{"t"}{.spec.template.spec.containers[0].image}{"n"}{end}'

Si encuentras tokens con algoritmos no esperados, o tu versión cae en los rangos vulnerables, asume que la superficie de ataque está abierta y prioriza el parche del vendor antes que cualquier otra mitigación.

CVE-2026-71362: el takeover de sesión en Adobe Commerce y Magento

La segunda falla, catalogada bajo CWE-863 (Incorrect Authorization), es más directa en su mecánica: permite a un atacante remoto sin autenticación escalar privilegios y obtener acceso elevado a la aplicación sin ninguna interacción del usuario. Adobe la documenta en su security bulletin APSB26-92, publicado en agosto de 2026. Lo que Sansec detectó en producción es igual de concreto: “la vulnerabilidad permite a los atacantes cambiar una sesión de cliente a la cuenta de otro cliente. Esto les da acceso a la cuenta de la víctima y a datos privados del cliente.”

El impacto operativo para un retailer LATAM que corre sobre LAMP es severo: un atacante puede tomar el control de cuentas de clientes existentes (con datos de tarjeta, historial de compras, direcciones) y, dependiendo de la configuración de roles en el backend, escalar a la creación de usuarios administradores o puertas traseras administrativas. Es exactamente el tipo de falla que los Magecart groups weaponizan para inyectar credit card skimmers en flujos de checkout.

Versiones afectadas por producto Adobe

Producto Adobe	Rango afectado	Acción
Adobe Commerce	2.4.4 a 2.4.9 (builds previos al parche de agosto 2026)	Aplicar update del vendor
Adobe Commerce B2B	1.3.3 a 1.5.3 (builds previos al parche de agosto 2026)	Aplicar update del vendor
Magento Open Source	2.4.6 a 2.4.9 (builds previos al parche de agosto 2026)	Aplicar update del vendor

Cómo verificar si tu tienda Adobe Commerce o Magento está expuesta

Para Magento Open Source la verificación es directa por línea de release en comandos. Para Adobe Commerce la verificación requiere acceso al admin backend o al binario de deployment.

# Magento Open Source / Adobe Commerce 2 — versión actual
php -r 'require "app/Mage.php"; echo Mage::getVersion();' 2>/dev/null 
  || bin/magento --version 2>/dev/null 
  || grep -A1 '<title>' app/design/frontend/*/template/page/html/header.phtml 2>/dev/null | head -2
# Listar parches de seguridad aplicados (Adobe Commerce)
ls -la app/etc/patches/ 2>/dev/null | head
# Buscar archivos sospechosos en pub/static y app/code (indicador de compromiso Magecart)
find pub/static -type f -name '*.js' -newer composer.json 2>/dev/null | head -10
find app/code -type f -name '*.php' -newer composer.json 2>/dev/null | head -10

Si detectas archivos JS desconocidos en pub/static o scripts PHP que no reconoces en app/code con fechas posteriores al último deploy conocido, asume compromiso y aísla la instancia antes de aplicar el parche.

BOD 26-04: el nuevo modelo de deadlines de CISA

El aviso del 24 de septiembre de 2026 introduce una diferencia operativa relevante para equipos que gestionan infraestructura en países que no son Estados Unidos. Bajo la directiva anterior (BOD 22-01), CISA asignaba plazos uniformes de remediación — típicamente 14 o 21 días desde la inclusión en el catálogo. La directiva BOD 26-04, que reemplazó a la anterior en 2026, establece plazos por activo según exposición, estado de explotación e impacto técnico, en lugar de un plazo único. El texto de la propia directiva pone el escalón más corto en tres días.

Para estas dos vulnerabilidades, The Hacker News reportó que las agencias federales recibieron el consejo de aplicar los fixes antes del 27 de septiembre de 2026, exactamente tres días después de la inclusión. Las agencias federales de EE. UU. están obligadas por la directiva; las empresas privadas fuera de EE. UU. enfrentan a los mismos atacantes y deberían moverse en la misma línea de tiempo. El KEV no es la línea de partida, es la señal de que los atacantes llevan días o semanas trabajando.

Qué hacer HOY si operas WSO2 o Adobe Commerce/Magento

Identifica versiones en producción — usa los comandos de verificación de arriba en cada instancia WSO2 y cada tienda Magento/Adobe Commerce que mantengas. Documenta la versión actual y compárala con las matrices de versiones afectadas.
Aplica el parche del vendor sin esperar al próximo ciclo de mantenimiento — tanto WSO2 como Adobe publicaron fixes; el costo de un reinicio controlado es mucho menor que el costo de un compromiso de admin API o de una filtración de datos de clientes.
Fuerza algoritmos JWT estrictos — para WSO2, revisa la configuración del JWT validator y asegúrate de que la lista de algoritmos permitidos esté fijada a RS256/ES256, rechazando cualquier alg no soportado o none. Esta es la causa raíz del bypass.
Revisa logs en busca de indicadores de compromiso — busca tokens JWT con algoritmos anómalos, requests a endpoints administrativos de Magento desde IPs que no reconoces, archivos JS no documentados en pub/static y cuentas administrativas nuevas o modificadas.
Rota credenciales administrativas — después de aplicar el parche, rota todas las contraseñas de administradores y las claves API de management. Si encontraste evidencia de compromiso, rota claves de integración con ERP, CRM y pasarelas de pago.
Audita cuentas de clientes y eventos de sesión — en Magento/Adobe Commerce, revisa el log de sesiones y la tabla customer_entity en busca de logins desde IPs o geolocalizaciones inconsistentes con el patrón normal de tus clientes.

Lecciones operativas para tu flota Linux

Estas dos fallas comparten un patrón que vale la pena internalizar para cualquier sysadmin que gestiona infraestructura heterogénea: los atacantes actúan antes de la confirmación oficial del vendor. watchTowr vio exploits de CVE-2026-5430 el 13 de septiembre, once días antes del aviso de CISA; Sansec detectó exploits de CVE-2026-71362 desde agosto, un mes antes. Esperar al advisory oficial del vendor, al aviso de CISA, o al comunicado del CERT regional significa exponer tu superficie de ataque durante días o semanas.

El segundo patrón es la divergencia entre vendors y catálogos oficiales. El mismo CVE-2026-5430 está descrito por WSO2 como un bypass de autenticación JWT y por CISA como un path traversal con file upload. Esto no es un capricho burocrático: significa que el atacante puede llegar al mismo resultado (control administrativo del plano de gestión de API) por dos rutas distintas, y un parche que cierre solo una deja la otra abierta.

El tercer patrón es la velocidad. BOD 26-04 acortó el plazo mínimo federal a tres días para vulnerabilidades en KEV. Si tu equipo opera infraestructura crítica, asume que ese piso federal es también tu propio piso. La disciplina de parcheo no es opcional: es la diferencia entre un incidente contenido y una filtración masiva.

Resumen accionable

Vulnerabilidad	Producto	CVSS	Acción inmediata
CVE-2026-5430	WSO2 API Manager, Control Plane, Traffic Manager, Universal Gateway	9.8	Aplicar parche del vendor + forzar RS256/ES256 en JWT validator
CVE-2026-71362	Adobe Commerce 2.4.4-2.4.9, B2B 1.3.3-1.5.3, Magento OS 2.4.6-2.4.9	9.1	Aplicar parche Adobe de agosto 2026 + auditar pub/static y admin accounts

Si tu organización usa WSO2 o Adobe Commerce/Magento en producción, este es el aviso para moverte hoy, no la próxima semana. La ventana entre la actividad de los atacantes y el aviso público ya se cerró.

Preguntas frecuentes

¿Por qué WSO2 y Adobe Commerce: las nuevas fallas críticas que CISA agregó a KEV (y por qué importan en LATAM) es relevante para sysadmins Linux?

Forma parte del flujo diario de administración. Los conceptos explicados se aplican directamente a servidores en producción y resuelven problemas reales que enfrentan sysadmins hispanohablantes.

¿Qué necesito para empezar con WSO2 y Adobe Commerce: las?

Distribución Linux actualizada (Debian, Ubuntu, RHEL, Fedora o Arch), acceso root, y conexión a internet. Para producción: entorno de staging separado antes de aplicar cambios.

¿Cuáles son los errores más comunes con WSO2 y Adobe Commerce: las?

Los tres más frecuentes: (1) saltar la lectura de logs, (2) aplicar cambios directos en producción sin probar, (3) olvidar permisos y ownership. La documentación y un plan de rollback siempre.

¿Cuándo usar WSO2 y Adobe Commerce: las y cuándo una alternativa?

Esta solución es ideal para el caso descrito. Alternativas como Docker, Ansible o configuración manual pueden ser mejores según contexto: portabilidad, escala y reproducibilidad son los factores clave.

¿Cómo migro desde una configuración previa a WSO2 y Adobe Commerce: las?

Documentar el estado actual, probar la nueva configuración en staging, validar funcionalmente, y aplicar en producción con rollback plan listo. Los posts de SoyLinux incluyen troubleshooting para los problemas más comunes.