F5 BIG-IP APM: zero-day crítico con ejecución remota sin autenticación

Qué se sabe del CVE-2026-94127 y por qué es grave

F5 publicó el 22 de septiembre un aviso de seguridad para una vulnerabilidad crítica en BIG-IP Access Policy Manager que ya se está explotando en ataques reales. La falla, identificada como CVE-2026-94127, permite a un atacante ejecutar código en el sistema afectado sin necesidad de autenticarse. No es una vulnerabilidad teórica ni un hallazgo de laboratorio: F5 la describe como zero-day, es decir, se estaba explotando antes de que existiera parche.

Solo afecta a BIG-IP APM como servidor de autorización OAuth

La puntuación es de 9,8 sobre 10 en la escala CVSS 3.1, y 9,3 en la versión 4.0. El fallo es un desbordamiento de búfer en el heap y se explota enviando tráfico manipulado a un servidor virtual afectado. Como no requiere credenciales, cualquier atacante con acceso de red al servicio puede intentarlo, y el resultado es ejecución de código con los privilegios del proceso comprometido. En un appliance de borde, que es lo que es BIG-IP, eso significa ponerse en posición de interceptar tráfico que pasa por él.

Versiones afectadas y hotfixes publicados por F5

Hay un matiz que importa mucho a la hora de saber si tu instalación está en riesgo: la vulnerabilidad no afecta a todos los BIG-IP con APM, solo a los que usan APM como servidor de autorización OAuth. Si en tu despliegue APM actúa únicamente como cliente OAuth o como servidor de recursos, la vulnerabilidad no aplica. Esta distinción es la que hay que comprobar primero, antes de entrar en pánico o de planificar una ventana de mantenimiento que quizá no sea urgente.

CISA lo incluye en KEV con plazo de tres días

Las versiones afectadas, antes de aplicar el hotfix correspondiente, son la rama 21.1 en su versión 21.1.0, la rama 17.5 desde 17.5.0 hasta 17.5.1, y la rama 17.1 desde 17.1.0 hasta 17.1.3. F5 ha publicado hotfixes de ingeniería específicos para cada rama, con nomenclatura que incluye la versión base y el número de compilación. La recomendación es actualizar a la versión con el hotfix aplicado, no esperar a la siguiente versión mayor.

Cómo mitigar si no puedes parchear todavía

El peso de este caso lo da CISA. La agencia estadounidense añadió la vulnerabilidad a su catálogo de vulnerabilidades explotadas conocidas el 22 de septiembre, el mismo día del aviso de F5, y dio a las agencias federales hasta el 25 de septiembre para aplicar mitigaciones. Que una vulnerabilidad entre en el catálogo KEV el mismo día en que se publica el aviso, y con un plazo de tres días, es una señal bastante clara de que la explotación activa estaba causando problemas serios.

Qué revisar en tu perímetro después de un caso así

Para quien no pueda parchear de inmediato, F5 ofrece una mitigación temporal en forma de regla iRule que se aplica al servidor virtual afectado y que hay que solicitar abriendo un ticket con el soporte de F5, porque no se distribuye públicamente. CISA recomendó expresamente aplicar primero esa iRule para poder hacer un triaje forense con calma y parchear después. El orden no es arbitrario: si parcheas antes de investigar, puedes destruir las evidencias que te dirían si te habían comprometido y desde cuándo.

Más allá del caso concreto, F5 BIG-IP es un objetivo recurrente y conviene sacar dos conclusiones. La primera es de inventario: muchas organizaciones no tienen claro qué appliances de borde tienen expuestos a internet, quién los mantiene ni con qué versión están. Sin ese inventario no puedes responder a la pregunta de si esta vulnerabilidad te afecta en menos de una hora. La segunda es de arquitectura: estos dispositivos concentran autenticación y tráfico, así que un fallo sin autenticación en ellos vale mucho más que en un servidor interno cualquiera. Eso justifica tratarlos con prioridad distinta.

Desde el punto de vista de una auditoría, este tipo de vulnerabilidad es exactamente lo que se busca cuando se revisa el perímetro: servicios de borde accesibles desde fuera, con funciones avanzadas activadas y sin control de versión actualizado. Comprobar qué servicios de administración están expuestos y qué versión corren es una de las primeras tareas de cualquier revisión de infraestructura, y en la mayoría de organizaciones aparece algo.