Cada empresa tiene una máquina que decide quién eres. Inicias sesión una vez, esa máquina comprueba la sesión, emite un token y dice a todas las aplicaciones que tiene detrás que confíen en ti. En muchas organizaciones, esa máquina es F5 BIG-IP Access Policy Manager (APM) actuando como servidor de autorización OAuth.
El 22 de septiembre, F5 confirmó que los atacantes ya están ejecutando su propio código en ella. Sin iniciar sesión. Se identifica como CVE-2026-94127, tiene una puntuación de 9.8 (CVSS v3.1) y su hotfix debería estar en tu calendario hoy, no el próximo trimestre.
La versión corta
- CVE-2026-94127 es un desbordamiento de búfer de tipo heap (CWE-122) en BIG-IP APM, con 9.8 en CVSS v3.1 y 9.3 en v4.0.
- Solo existe cuando APM está configurado como servidor de autorización OAuth: una política de acceso y un perfil OAuth en el mismo servidor virtual.
- Tráfico malicioso específico enviado a ese servidor virtual provoca ejecución remota de código por parte de un atacante no autenticado.
- F5 lo divulgó el 22 de septiembre y publicó hotfixes de ingeniería. CISA lo añadió al catálogo KEV ese mismo día y dio a las agencias federales hasta el 25 de septiembre.
- En palabras de F5: «We have learned that this vulnerability has been exploited.»
Tres días entre el aviso y la fecha límite federal. Esa es la nueva aritmética del parcheo, y no es una errata.
Qué es exactamente la falla
BIG-IP APM es el módulo que arbitra el acceso a tus aplicaciones: ejecuta la política de acceso, aplica las comprobaciones de postura y entrega los tokens que las aplicaciones posteriores aceptan como prueba de identidad.
La configuración vulnerable es estrecha pero común: una política de acceso de APM y un perfil de servidor de autorización OAuth en el mismo servidor virtual. Cuando un sistema está configurado así, el tráfico malformado dirigido al servidor virtual puede desbordar un búfer de heap y entregar la ejecución al atacante.
Las ramas afectadas y sus correcciones:
- 21.1 — 21.1.0 antes del hotfix →
Hotfix-BIGIP-21.1.0.2.0.30.22-ENG - 17.5 — de 17.5.0 a 17.5.1 →
Hotfix-BIGIP-17.5.1.9.0.160.12-ENG - 17.1 — de 17.1.0 a 17.1.3 →
Hotfix-BIGIP-17.1.3.5.0.41.14-ENG
Hay una buena noticia. Si APM solo actúa como cliente o servidor de recursos OAuth, sin perfiles de servidor de autorización configurados, no estás afectado. F5 actualizó su registro CVE a las 00:45 UTC del 23 de septiembre para limitar la condición específicamente al rol de servidor de autorización, lo que significa que los primeros textos de CERT-EU y del catálogo KEV eran más amplios que el alcance final. Revisa el rol, no solo la versión.
Por qué cerrar la interfaz de gestión no te salvará
El instinto tras cualquier día cero en un appliance de borde es esconder la interfaz de administración detrás de un jump host y dar el tema por cerrado. Aquí eso no sirve de nada.
Esto es un problema del plano de datos. El tráfico malicioso va al servidor virtual que gestiona los flujos OAuth, la misma dirección que tus usuarios, y los de tus socios, deberían alcanzar. F5 afirma que no hay exposición en el plano de control y, algo crucial, que los sistemas BIG-IP en modo Appliance también son vulnerables. El modo Appliance es justamente el endurecimiento que la gente aplica para que estas máquinas sean más difíciles de abusar.
Así que la exposición no es «quién puede alcanzar el puerto de gestión». La exposición es «quién puede alcanzar el endpoint de identidad». En la mayoría de las arquitecturas, eso es internet.
Y estos appliances no son raros. Shadowserver rastrea actualmente más de 14.700 direcciones IP con huella de BIG-IP APM. Ese número no dice cuántos están sin parchear o mal configurados, pero sí dice lo atractiva que es esta clase de objetivo.
Cómo saber si ya te atacaron
Aquí la historia se vuelve incómoda. F5 divulgó la falla como día cero, lo que significa que los detalles explotables existían en el mundo real antes de que tuvieras un parche que instalar. Todo lo que llega como día cero trae una cantidad desconocida de tiempo ya consumido.
F5 publicó indicadores que los defensores pueden buscar. El patrón que merece una alerta es una secuencia, no un evento aislado:
- Fallos repetidos de autenticación OAuth contra el servidor virtual de BIG-IP APM.
- Comandos sospechosos que aparecen poco después de esos fallos.
- Un evento TMM SIGABRT justo detrás.
Si ves esa cadena en una misma ventana, trátala como un compromiso confirmado, no como una teoría. Los pasos posteriores del patrón, los comandos de post-explotación, solo existen si algo entró primero.
Si no puedes instalar el hotfix de inmediato, F5 ha publicado un iRule a través de sus canales de soporte que se puede asociar al servidor virtual afectado como mitigación temporal. Temporal significa exactamente eso: te compra las horas para programar la corrección real, no la sustituye.
Qué haríamos nosotros esta semana
- Audita la configuración, no el banner de versión. Un escaneo remoto no puede decirte si hay perfiles de servidor de autorización OAuth configurados. Extrae la configuración y lista cada servidor virtual que tenga política de acceso y perfil OAuth.
- Aplica los hotfixes con nombre en las ramas afectadas, empezando por todo lo expuesto a internet. Si una ventana de mantenimiento es inevitable, pon el iRule primero y registra la excepción.
- Caza la cadena de indicadores más atrás del 22 de septiembre. Los atacantes conocían la falla antes del aviso; empieza la revisión de registros antes de la fecha de divulgación.
- Rota ante la sospecha, no ante la certeza. Si aparece la cadena, asume que los tokens y secretos de cliente que emitió ese appliance pueden estar comprometidos. Rota los secretos de cliente OAuth, revisa el manejo de claves de firma e invalida las sesiones vigentes.
- Mapea el radio de impacto. Cada aplicación que confía en ese servidor de autorización como proveedor de identidad está aguas abajo de esta falla. Las que aceptan tokens a ciegas, sin volver a comprobar los claims, son las primeras que debes revisar.
- Prueba la restauración del plano de identidad. Tu gestor de accesos está delante de casi todo. Si se cae, ¿cómo vuelves a entrar? La mayoría de los equipos con los que hablamos nunca lo han ensayado.
La conclusión
La infraestructura de identidad es ahora la joya de la corona, y los atacantes están de acuerdo. Hace dos días escribimos sobre los appliances VPN de Check Point; hoy le toca al gestor de accesos de F5. El patrón es constante: las máquinas que deciden quién entra son las que vale la pena romper, y sus fallas no se preocupan por tus restricciones en la interfaz de gestión.
Parchea esto rápido, pero no te quedes solo en el parcheo. El plazo de tres días es una señal de la velocidad con la que la explotación sigue a la divulgación. Detección, auditoría de configuración y una ruta de recuperación ensayada son lo que te sostiene en los días en que no tienes corrección.
Si no tienes certeza de si tu despliegue de BIG-IP APM funciona como servidor de autorización OAuth, esa incertidumbre es el riesgo. Vamos a cerrarla.