CISA incorporó CVE-2026-5430, asociada con productos de gestión de API de WSO2, a su catálogo de vulnerabilidades explotadas el 24 de septiembre de 2026. El aviso original del fabricante describe un problema crítico en la validación de firmas de tokens JWT que puede permitir acceso no autorizado. Para una empresa colombiana que utiliza WSO2, la respuesta comienza por identificar productos y versiones reales, aplicar el remedio correspondiente y buscar señales en los registros. La incorporación a KEV no confirma víctimas en Colombia.

La novedad y lo que ya se sabía

WSO2 había publicado el aviso WSO2-2026-5328 antes de esta actualización. Su tabla incluye API Manager, API Control Plane, Traffic Manager y Universal Gateway en determinadas versiones. La novedad del 24 de septiembre es la evaluación de CISA de que existe explotación activa; eso eleva la urgencia de instalaciones expuestas. No debe confundirse la fecha de publicación del fallo con la fecha de reconocimiento público de explotación.

Hay una diferencia de nomenclatura que exige cautela. El registro KEV presenta una descripción abreviada distinta de la explicación técnica de WSO2, que se centra en aceptación de algoritmos de firma JWT no configurados o no admitidos. Para tomar decisiones de versión y parche, la organización debe acudir al aviso específico del fabricante. Un resumen externo no reemplaza las condiciones de producto, rama y parche de WSO2.

Por qué importan las firmas de los tokens

Un JWT transporta afirmaciones de identidad y permisos. El receptor debe comprobar que fue firmado con un algoritmo esperado y una clave válida antes de confiar en esas afirmaciones. Si una implementación acepta un algoritmo que no debía aceptar, el límite entre una identidad autorizada y una solicitud falsificada puede romperse. La gravedad depende de qué funciones protege ese control, qué rutas son accesibles y qué privilegios puede alcanzar el token.

No todos los JWT son inseguros ni toda API WSO2 es vulnerable. El problema está en productos y versiones enumerados por el fabricante y en el comportamiento corregido. Una investigación seria evita saltar de «token falsificable bajo ciertas condiciones» a «todos los datos se filtraron». El equipo debe evaluar el gateway, el plano de control, las identidades, los endpoints publicados y los registros de autenticación de su implementación.

El inventario debe seguir la arquitectura de API

Las API suelen repartirse entre ambientes, equipos y proveedores. Un gateway público puede estar administrado por infraestructura; las credenciales, por identidad; las aplicaciones, por equipos de desarrollo; y la lógica de autorización, por un tercero. Identifique instancia, producto, versión, función, URL pública, propietario, origen de tokens, algoritmo permitido, claves, registros y dependencia de negocio. Incluya ambientes de pruebas que quedaron accesibles en internet.

El inventario también debe mostrar qué datos o transacciones pasan por cada puerta. Una API de consulta de catálogo no tiene el mismo impacto que una API que emite órdenes, gestiona cuentas o expone información personal. La clasificación permite priorizar sin afirmar que una empresa concreta esté afectada. Para Colombia, la pregunta práctica es cuáles servicios digitales propios o contratados dependen de esta infraestructura y quién puede demostrar su estado.

Respuesta técnica sin destruir evidencia

Preserve primero configuraciones y registros relevantes. Contraste versiones con la matriz del aviso oficial y aplique los parches o actualizaciones indicados por WSO2. Una mitigación temporal debe tener alcance y fecha de sustitución. Después confirme que el tráfico real llega a la versión corregida en todos los nodos, no solo al servidor de administración. Pruebe autenticación legítima, integraciones críticas y denegación de tokens que incumplen la política.

Si el cambio obliga a rotar claves, coordine emisores y consumidores para evitar indisponibilidad. La rotación sin plan puede interrumpir integraciones de clientes y proveedores. Si se detecta un token sospechoso, conserve el valor de referencia con tratamiento seguro, hora, cabeceras relevantes, ruta solicitada, respuesta y acciones posteriores. La correlación es más útil que una lista de direcciones IP sin contexto.

Qué señales revisar en los registros

Busque autenticaciones con algoritmos inesperados, errores de validación, solicitudes a rutas administrativas, cambios de roles y uso de permisos que no correspondan al emisor. Compare con la configuración previa para separar pruebas autorizadas, errores de integración y actividad anómala. Una respuesta HTTP exitosa no demuestra por sí sola acceso a datos sensibles; exige revisar qué recurso se devolvió y qué acciones siguieron.

Los registros pueden estar dispersos entre gateway, proveedor de identidad, balanceador, WAF y servicio de destino. Reconstruya una línea de tiempo de versión vulnerable, corrección, claves y sesiones. Cuando hay indicios de acceso no autorizado, preserve logs originales y aplique el procedimiento de respuesta. El Análisis Forense Digital ayuda a delimitar hechos antes de atribuir una filtración o borrar rastros.

El impacto empresarial está detrás del gateway

Una API puede conectar aplicaciones móviles, socios, proveedores de pago, logística o sistemas internos. El riesgo no se mide solo por el CVSS del componente: depende de las operaciones que el gateway autoriza y de si existen verificaciones adicionales en el servicio final. Un diseño con comprobación de permisos en cada aplicación puede limitar efectos; una confianza ciega en el token recibido del gateway puede ampliarlos.

Dirección necesita respuestas concretas: qué procesos podrían alterarse, qué datos serían accesibles, qué integraciones deben suspenderse temporalmente y cuánto tardaría una restauración. Esa lectura permite decidir el orden de parcheo y comunicación. La notificación de una brecha de datos requiere hechos sobre acceso real y obligaciones aplicables; un CVE en el inventario, por sí solo, no prueba una brecha notificable.

Aplicación responsable para Colombia

No hay en los avisos citados una lista de organizaciones colombianas comprometidas. La noticia es relevante para cualquier entidad local que opere versiones afectadas, directamente o mediante un integrador. Pregunte a cada proveedor por producto, versión, fecha de parche, controles de firma JWT, cobertura de logs y resultado de la búsqueda retrospectiva. Una confirmación genérica de que «la nube está protegida» no responde esas preguntas.

Un Análisis de Vulnerabilidades puede ordenar el inventario y verificar exposición de componentes. El Ethical Hacking autorizado puede probar controles de autenticación y autorización de API con límites acordados. Ninguna prueba debe intentar explotar sistemas de terceros sin permiso ni reemplazar el parche del fabricante.

Lo que debería quedar resuelto en treinta días

Formalice un registro de APIs con dueño, propósito, clasificación de datos, emisor de identidades, versiones y ciclo de cambios. Automatice comprobaciones de configuración donde sea viable, revise permisos de cuentas técnicas y ensaye rotación de claves. Defina qué evidencias entrega cada proveedor y cuánto tiempo se conservan. La próxima alerta será más sencilla de gestionar si la arquitectura puede responder en horas, no semanas.

También conviene revisar la separación entre autenticación y autorización. Validar un JWT responde quién o qué presentó una credencial aceptable; no demuestra que esa identidad pueda realizar cualquier operación. Las aplicaciones deben comprobar permisos específicos para cada recurso, registrar denegaciones y limitar el alcance de cuentas de servicio. Una prueba de regresión debe cubrir tanto tokens válidos como inválidos y acciones fuera de perfil.

Cómo verificar que la corrección funciona

Una prueba de cierre debe cubrir tanto el tráfico permitido como el denegado. Genere tokens de prueba con el emisor y algoritmo autorizados y confirme que acceden solo a recursos de su perfil. En un entorno de ensayo, compruebe que el gateway rechaza tokens con algoritmos no autorizados, firmas inválidas, audiencias erróneas y expiración vencida. No utilice credenciales productivas ni datos personales para demostrar la denegación. Registre versión de cada nodo, configuración aplicada, resultado y fecha.

Verifique después que las aplicaciones finales no confían exclusivamente en la decisión del gateway. Un usuario con sesión válida puede intentar una operación sobre recursos de otra persona; la autorización de objeto debe negarla. Las pruebas de regresión requieren acordar cuáles rutas y roles representan el negocio. Un resultado favorable para un endpoint no garantiza que todos los servicios conectados compartan la misma política.

Cuando el proveedor administra la plataforma, solicite evidencia de que el tráfico pasa por nodos corregidos y de que no hay rutas que eludan el gateway. Si se aplicó una configuración temporal, confirme que permanece documentada y que se reemplazará por la solución oficial. La búsqueda retrospectiva debe mostrar qué registros se consultaron, el periodo, las condiciones de detección y las limitaciones. Esa trazabilidad permite explicar el cierre a auditoría y responder si aparecen indicadores nuevos.

Un modelo de decisión para dirección

Clasifique cada API por exposición pública, sensibilidad de datos, capacidad de ejecutar operaciones, versión y evidencia de abuso. Una API pública de transacciones con versión afectada y registros incompletos requiere prioridad mayor que una instancia aislada y ya corregida. El criterio no debe esconder incertidumbre: si no se conoce la versión, el estado es «pendiente de confirmar», no «seguro».

Asigne al dueño de servicio la continuidad, al administrador el parche, a identidad las claves y a seguridad la revisión de logs. Un único coordinador reúne las conclusiones. Si se confirma acceso indebido, evalúe alcance y obligaciones según hechos. Si no hay señales y la cobertura de registros es suficiente, documente el razonamiento, sin convertir una ausencia de alertas en prueba absoluta de que nunca ocurrió actividad.

Preguntas frecuentes

¿KEV significa que nuestra API fue atacada?

No. Significa que CISA dispone de evidencia de explotación de la CVE. Determine su exposición y revise sus registros.

¿Basta con cerrar el acceso público al administrador?

Puede reducir superficie, pero no corrige la validación defectuosa ni sustituye una revisión de rutas y versiones afectadas.

¿Hay que renovar todos los tokens?

Depende de la investigación y de la arquitectura. Coordine claves, sesiones e integraciones con sus emisores; la rotación sin evaluación puede afectar servicios.

Aclare la exposición de sus API

Fuentes y alcance

La fuente primaria documenta producto y mecanismo; CISA documenta explotación. No se afirma afectación confirmada de empresas de Colombia.