El 30 de septiembre CISA agregó CVE-2026-76504 al catálogo de vulnerabilidades explotadas, con plazo al 3 de octubre. Es un salteo de autenticación en la API de Cisco Catalyst SD-WAN Manager, el equipo desde el que se administra toda una red SD-WAN, y el aviso del fabricante no deja mucho margen de interpretación.

Cisco le puso 9,8 crítica, confirma la explotación con una frase propia —"In September 2026, the Cisco PSIRT became aware of active exploitation of this vulnerability"—, aclara que el problema "affects Cisco Catalyst SD-WAN Manager, regardless of system configuration" y cierra la puerta a los paliativos: "There are no workarounds that address this vulnerability."

El resultado de explotarla, en palabras del aviso, es acceso a la API como el usuario administrador, sin credenciales.

Cómo se saltea la autenticación: la misma URL, leída dos veces

El mecanismo es de los más instructivos que pasaron por este sitio, y vale entenderlo porque no es exclusivo de Cisco. La causa, textual: "improper handling of URI encoding in an HTTP request, which allows the request to bypass an authentication rule that is intended to restrict access to a specific API endpoint".

Dos componentes, una misma dirección, dos lecturas 1. La regla de autenticación lee la dirección como llega escrita Con los caracteres codificados sin resolver, no coincide con la ruta que debe proteger. Conclusión de la regla: esto no es el endpoint protegido, no pido credencial. 2. La API resuelve la codificación y obtiene la ruta real Esa ruta sí es el endpoint protegido, y lo atiende con privilegios de administrador. La credencial nunca se pidió, porque el control de arriba ya había dicho que no hacía falta. Ninguno de los dos está roto por separado. Lo que falla es que no se ponen de acuerdo. Reconstruido de la descripción del aviso de Cisco. No se publica ninguna cadena concreta ni el endpoint afectado.

Vale aclarar por qué la nota se queda en ese nivel de detalle: el mecanismo se explica, la cadena concreta no. El aviso de Cisco tampoco la publica, y el valor para quien administra el equipo está en entender la forma del problema, no en tener la llave.

Lo que esa forma explica, y es la parte transferible, es por qué este tipo de falla derrota a las defensas que uno creería suficientes. Una regla de autenticación es un componente que lee una cadena y decide. Una regla de firewall de aplicación también. Cuando el ataque consiste precisamente en que dos lectores entiendan distinto la misma cadena, agregar un tercer lector no resuelve nada: agrega una lectura más para hacer discrepar. Es la misma familia de problema que la falla de miniOrange que daba acceso de administrador: cuando lo que se rompe es la verificación, lo que está detrás de la verificación deja de importar.

Puse a prueba una intuición y me salió al revés, así que vale contarlo con el resultado que dio. La clase de debilidad que Cisco le asigna a esta falla es CWE-177, manejo indebido de codificación en la URL. Me pareció que estaba viendo esa familia repetirse últimamente, así que la conté sobre las 1.730 entradas del catálogo.

No se repite. CVE-2026-76504 es la única entrada con CWE-177 en toda la historia del catálogo. Y si se amplía a la familia estricta de "dos componentes leen el mismo dato distinto" —sumando la interpretación inconsistente de peticiones HTTP y los errores de codificación— aparecen 5 entradas en total, repartidas en 2022, 2023, 2025 y dos en 2026.

Así que no es una ola: es una clase rara en el catálogo y devastadora cuando aparece. Y en esta aparición hay un detalle que la separa de las últimas que cubrió el sitio. CISA publica, además del puntaje, una evaluación con tres decisiones, y una de ellas es si el ataque se puede automatizar de punta a punta. En las tres anteriores que pasaron por acá —WordPress, NetScaler y Apple— esa decisión fue no. En esta es sí.

Que sea automatizable y que no requiera credenciales ni configuración particular significa que el escaneo masivo es viable, y con eso la ventana no la define tu calendario.

Defender por clase de falla cubre 2 de las últimas 14 entradas

El dato anterior abre una pregunta más útil que la de esta falla puntual: si las clases de debilidad casi no se repiten, ¿sirve organizar la defensa por clase? Lo medí sobre las entradas de los últimos 10 días.

14 entradas en 10 días, 13 clases de debilidad distintas Eliminar la clase de falla más frecuente del período Cubre 2 de 14. La clase más repetida aparece apenas dos veces; las otras 12 clases aparecen una sola vez cada una. Sacar las interfaces de administración de internet Actúa sobre las 14, porque ninguna se explota contra un servicio al que el atacante no llega. La defensa por clase de falla no escala. La defensa por exposición sí. Calculado sobre el feed del catálogo KEV, entradas del 21 de septiembre al 1 de octubre de 2026.

Las trece clases del período son de todo tipo: desborde de pila, validación de entrada, recorrido de rutas, certificados, autorización incorrecta, inyección de código, escritura fuera de límites y la de hoy. Es decir que no hay un enemigo a derrotar este trimestre. Cualquier plan que se arme alrededor de una clase de falla va a cubrir una fracción de lo que viene.

Lo que sí se repite en todas, y es lo único que escala, es la condición previa: el atacante tiene que poder llegar al servicio. Ese es el argumento que el sitio viene haciendo desde las fallas explotadas de agosto en la capa de administración, y esta falla es un caso de manual, porque Cisco dice que no hay paliativo y su propia recomendación mientras tanto es restringir el acceso desde internet y poner el equipo detrás de un firewall.

Las versiones corregidas, y la trampa de las anteriores a la 20.9

Primera versión corregida, por rama Rama 20.9 20.9.10.1 Rama 20.12 20.12.8.2 Rama 20.15 20.15.6.1 Rama 20.18 20.18.4.1 Rama 26.1 26.1.2.1 Rama 26.2 26.2.1 Anterior a la 20.9: no hay corrección para tu rama El aviso indica migrar. Es un salto de versión mayor, no una actualización de mantenimiento.

Ese último caso es el que conviene mirar primero si el equipo lleva años andando: para las versiones anteriores a la 20.9 no hay parche, hay migración. Y una migración de versión mayor en un equipo que administra toda la red no es algo que se haga en 3 días sin planificarlo.

Si estás ahí, la decisión realista no es si vas a migrar a tiempo —no vas a— sino qué hacés hoy para que el equipo no sea alcanzable mientras planificás la migración. Es la misma disyuntiva que apareció con NetScaler esta semana, aunque por un motivo distinto.

¿A quién afecta CVE-2026-76504 de Cisco?

A quien administre una red con Cisco Catalyst SD-WAN Manager, el producto que antes se llamaba vManage. No depende de la configuración: el aviso dice explícitamente que afecta al producto "regardless of system configuration", así que no hay una función que se pueda tener apagada para quedar afuera.

Esto no está en una PyME chica. Donde aparece es en la empresa con varias sucursales que unificó la conectividad con SD-WAN, y en los proveedores que administran la red de otros. En ese segundo caso vale la aclaración de siempre: si tu red la maneja un tercero, esta tarea es suya, y la pregunta concreta que conviene hacerle hoy es en qué versión está el controlador.

Y hay algo que hace a este equipo distinto de un servidor cualquiera: el SD-WAN Manager no es un equipo de la red, es el que configura la red. Acceso de administrador ahí no es acceso a un sistema, es la capacidad de cambiar cómo se enruta y se filtra el tráfico de todas las sucursales.

¿Quién puede ignorar el aviso de Cisco SD-WAN Manager?

Quien no tenga el producto. Es un controlador específico, no un componente que venga con otras cosas de Cisco: tener switches, teléfonos o firewalls de la marca no implica tenerlo.

Y quien ya esté en 20.9.10.1, 20.12.8.2, 20.15.6.1, 20.18.4.1, 26.1.2.1 o 26.2.1, o posterior según la rama.

Lo que no alcanza para ignorarlo: tener el controlador en una red interna sin exponerlo. Reduce mucho el riesgo y es lo que recomienda el fabricante mientras no se pueda actualizar, pero no es la corrección, y el acceso interno sigue existiendo como camino.

¿Cómo sé en qué versión está mi SD-WAN Manager y si estuvo expuesto?

Dos comprobaciones, y la segunda es la que más cuesta y más importa:

  1. La versión se ve en la propia interfaz de administración del controlador, en la pantalla de información del sistema, y también por línea de comandos en el equipo. Comparala con la lista de arriba según tu rama.
  2. Si la interfaz de administración estuvo accesible desde internet. Esto no se responde desde el equipo sino desde afuera: hay que verificar si el puerto de administración responde desde una conexión externa a tu red. Si responde, asumí que fue escaneado, porque con una falla automatizable y sin credenciales el escaneo es lo primero que ocurre.

Si las dos respuestas son malas —versión vieja y expuesto—, la pregunta pasa a ser si entraron, y ahí lo que hay que mirar son los registros de acceso a la API y los cambios de configuración que nadie del equipo reconozca. Un acceso como administrador que vino por este camino no deja un intento de autenticación fallido, porque nunca hubo autenticación: va a parecer actividad administrativa normal, y lo único anómalo va a ser el origen y el horario.

¿Qué hago si tengo Cisco SD-WAN Manager?

En este orden, y el orden importa porque el primer punto es el único que se puede hacer hoy sin ventana de mantenimiento:

  1. Sacá la interfaz de administración de internet, si está. Es la recomendación del propio fabricante mientras no haya actualización aplicada, y es lo único que se puede hacer en minutos.
  2. Averiguá la versión y la rama, y buscá tu primera versión corregida en la lista. Si tu rama tiene parche, esto es una actualización de mantenimiento.
  3. Si estás por debajo de la 20.9, asumí que la corrección no te llega y armá dos planes en paralelo: el de migración, con fecha realista, y el de contención mientras tanto.
  4. Revisá los registros de la API y los cambios de configuración del período en que el equipo estuvo expuesto sin parchear. Como no hay fallas de autenticación que buscar, lo que sirve es revisar actividad administrativa por origen y horario.
  5. Rotá las credenciales de administración y las claves de integración del controlador si encontrás algo raro, o directamente si estuvo expuesto con versión vulnerable. Un atacante con la API de administrador pudo crear accesos propios.

El encuadre de por qué las interfaces de administración son el blanco preferido está en las fallas explotadas de agosto, y la alternativa de resolver el acceso remoto sin exponer equipos propios, en acceso remoto seguro sin VPN y en VPN y acceso remoto. Otro caso reciente de Cisco agrupado por clase de falla está en las seis de Cisco ISE, y los términos, en el glosario.


Preguntas frecuentes sobre CVE-2026-76504 y SD-WAN Manager

Si el controlador está en mi red interna, ¿estoy a salvo?

Estás mucho mejor, pero no a salvo. Sacarlo de internet es la recomendación del propio Cisco mientras no haya parche, y elimina el escaneo masivo, que con una falla automatizable es la amenaza inmediata. Lo que no elimina es el camino interno: cualquier equipo de tu red que llegue a la interfaz de administración puede explotarla igual, y eso incluye una máquina comprometida por otra vía. Reducir exposición compra tiempo; no reemplaza la actualización.

¿Por qué un firewall de aplicación no me cubre?

Porque el ataque consiste exactamente en que dos componentes lean la misma dirección de forma distinta, y un firewall de aplicación es un componente más que lee esa dirección y decide. Puede ayudar si bloquea formas de codificación concretas, pero el problema de fondo no es una cadena puntual, es la discrepancia. Sumar lectores suma oportunidades de discrepar.

Cisco dice 9,8. ¿Ese número lo puso NVD?

No. El 9,8 lo asignó el PSIRT de Cisco, y en la ficha del CVE figura como puntaje secundario con la fuente del fabricante. NVD ya analizó la ficha pero el número que vas a ver es el de Cisco. Vale la aclaración porque en los últimos días este sitio mostró casos donde el fabricante y CISA puntúan distinto, y otros donde el fabricante no puntúa en absoluto.

Estoy en una versión anterior a la 20.9. ¿Qué hago con un plazo de 3 días?

El plazo de CISA obliga a organismos federales de Estados Unidos, no a vos, y en tu caso es materialmente imposible: migrar de versión mayor un controlador de red no se hace en tres días de forma responsable. Lo que corresponde es tratarlo como dos tareas: contener hoy, sacando el equipo de internet y limitando desde dónde se llega a la administración, y migrar con un plan y una fecha. Lo que no corresponde es dejarlo como está esperando una ventana que no va a aparecer sola.

¿Cómo sé si entraron por acá?

Es más difícil que en otras fallas, y conviene saber por qué: no hay intentos de autenticación fallidos que contar, porque la autenticación nunca se pidió. El acceso va a aparecer en los registros como actividad administrativa legítima. Lo que queda es mirar el contexto en lugar del evento: direcciones de origen que no correspondan a tu equipo de administración, actividad en horarios en los que nadie trabaja, y cambios de configuración o usuarios nuevos que nadie reconozca.