CISA ha añadido a su catálogo de vulnerabilidades explotadas en el mundo real el fallo CVE-2026-94127, de F5 BIG-IP APM. Fecha de alta: 22 de septiembre de 2026. Fecha límite para actuar: 25 de septiembre. Tres días.
Qué ha pasado
Es un desbordamiento de memoria dinámica —el clásico CWE-122— que aparece cuando un servidor virtual tiene a la vez una política de acceso y un perfil OAuth configurados. En esas condiciones, un atacante sin credenciales puede llegar a ejecutar código en el aparato. El que termina las VPN y la autenticación de tus usuarios. El que mira a internet.
La ficha del catálogo de vulnerabilidades explotadas de CISA trae dos detalles que no suelen ir juntos:
- Mitigación en dos pasos. Primero se aplica una iRule que publica el fabricante para tapar el agujero de forma temporal; después, el parche definitivo en cuanto se pueda. El detalle de F5 está en su propio aviso y la ficha técnica, en NVD.
- Triaje forense obligatorio. Para las agencias estadounidenses, la directiva de parcheo por riesgo que CISA aprobó este año (la que va numerada como BOD 26-04) exige recoger evidencia antes de tocar nada en los casos marcados. Este está marcado.
En uso con ransomware, el catálogo pone «desconocido». No dice que no, dice que no consta.
Y un dato de contexto que se ve mejor en la lista completa: con este ya son ocho los fallos de F5 en el catálogo. El del interfaz de gestión de 2020, el de autenticación ausente de 2022, la pareja encadenada de 2023 —un salto de autenticación más una inyección SQL—, el desbordamiento de pila de marzo de este año y este. Es un reincidente estructural.
Por qué importa
Lo importante no es el bug. Es el reloj.
En octubre de 2023, aquella pareja de fallos entró en el catálogo con tres semanas de margen: alta el 31 de octubre, límite el 21 de noviembre. En 2022, lo mismo: veintiún días. En marzo de 2026, el desbordamiento de pila del APM se publicó un viernes y había que tenerlo resuelto el lunes. Y ahora, otra vez tres días.
Eso significa que la ventana de mantenimiento ya no la negocias tú con el cliente. Te la impone el calendario de la explotación activa, porque un fallo no entra en ese catálogo por ser grave: entra porque alguien ya lo está usando contra alguien. Si tu proceso para parchear un equipo de borde pasa por pedir hueco al comité de cambios del mes que viene, tu proceso no existe.
Lo que yo cambiaría a partir de hoy, concreto:
- Saber qué tienes publicado y en qué configuración. Aquí la condición es muy específica: política de acceso más perfil OAuth en el mismo servidor virtual. Media hora de inventario te ahorra una noche entera. Pero esa media hora hay que haberla invertido antes, no el día del aviso.
- Tener definida la ventana de emergencia por escrito. Quién autoriza, a qué hora se corta, quién avisa a los usuarios, cuánto se tarda en volver atrás. Si eso se improvisa, los tres días se van en correos.
- Recoger evidencia antes de parchear, no después. Esto es lo que mucha gente se salta. Parchear sobre un equipo comprometido borra el rastro: te quedas seguro y ciego a la vez. Volcado de configuración, registros, cuentas y claves creadas, tareas programadas. Luego ya aplicas la mitigación.
- No confundir la iRule con el parche. La mitigación temporal te compra horas. He visto demasiadas veces el apaño de urgencia convertido en configuración permanente porque nadie cerró el ticket.
Qué no cambia
Tres cosas, para no exagerar.
Una: no todas las instalaciones de BIG-IP APM son vulnerables. Hace falta esa combinación concreta de política de acceso y OAuth. Si no la tienes, esto no va contigo —y comprobarlo es más rápido que entrar en pánico.
Dos: el catálogo de CISA es obligatorio para la administración federal estadounidense. Para una empresa de Valencia no obliga a nada. Lo que lo hace útil es otra cosa: es la mejor lista pública de «esto ya se está explotando», y por eso vale como criterio de priorización aunque no te aplique ninguna directiva.
Tres: que el aparato de borde sea el punto de entrada no es ninguna novedad de 2026. El fallo de F5 de 2020 que acabó en campañas de ransomware contaba exactamente la misma historia. Lo que ha cambiado es la velocidad entre que se publica y se explota, no la naturaleza del problema.
Nuestra lectura
Mi opinión: los plazos de tres días me parecen bien y van a ir a menos. Quien los critique por irrealistas está confundiendo el síntoma con la enfermedad. El plazo no es irreal: lo irreal es tener el concentrador de acceso de la empresa publicado en internet y no saber quién lo parchea ni cuándo se parcheó por última vez.
Lo que creo que va a envejecer mal es el modelo del aparato único que hace de todo en el perímetro: termina TLS, resuelve la autenticación, habla OAuth con tu proveedor de identidad y encima lleva su propio panel de administración. Cada función añadida es superficie nueva, y la lista de ocho entradas de F5 en el catálogo lo dice sin necesidad de teoría. Mínimo honesto: el interfaz de gestión fuera de internet, siempre, y una suscripción a los avisos del fabricante que llegue a una persona con nombre, no a un buzón genérico.
Y una manía mía: el día del aviso no es el día para improvisar la recogida de evidencia. Si el procedimiento forense se escribe con el reloj corriendo, se escribe mal. Mejor tenerlo en cuatro puntos en un documento aburrido que nadie lee hasta que toca.
Esto es justo lo que nos encontramos cuando entramos a revisar el perímetro de alguien: casi nunca falta el parche porque no exista, falta porque nadie sabía que ese equipo estaba publicado ni quién era responsable de tocarlo. El inventario aburrido vale más que la herramienta cara.
Cualquier duda me dices y lo vemos.
Un saludo, Vicente.