Contenido

Introducción

Prerequisites

Requirements

Componentes Utilizados

Antecedentes

Flujo de trabajo de remediación

Paso 1: Recopilar archivos técnicos de administración de todos los componentes de control

Alternativa: Verificación manual (solo si Admin-Tech no puede ser recolectada)

Paso 2: Abra un caso TAC y cargue archivos técnicos de administración

Paso 3: Evaluación del TAC

Paso 4: Si se identifican indicadores de compromiso, siga las directrices del TAC

Versiones de software fijas

Consideraciones

Dispositivos periféricos: Sospecha de riesgo

Apéndice: Pasos de verificación manual (solo si no es posible la recopilación de tecnología de administrador)

Verificación para CVE-2026-20245: Verifique scripts.log en cada componente del control para las entradas de carga de archivos

Verificación para CVE-2026-20262: Comprobar los archivos de registro de cada jefe (vManage) para entradas arbitrarias de escritura de archivos

Preguntas Frecuentes

Introducción

Este documento describe los pasos para identificar y abordar las vulnerabilidades de seguridad críticas en SD-WAN basándose en los avisos PSIRT del 4 y 15 de junio de 2026.

Prerequisites

Requirements

Cisco recomienda que tenga conocimiento sobre estos temas:

- Arquitectura Cisco Catalyst SD-WAN y componentes de control (vManage, vSmart, vBond)

- Procedimiento de actualización de Cisco Catalyst SD-WAN

- Administración de casos del TAC de Cisco y procedimientos de recopilación de tecnología de administración

Componentes Utilizados

La información que contiene este documento se creó a partir de los dispositivos en un ambiente de laboratorio específico. Todos los dispositivos que se utilizan en este documento se pusieron en funcionamiento con una configuración verificada (predeterminada). Si tiene una red en vivo, asegúrese de entender el posible impacto de cualquier comando.

Antecedentes

Para obtener información general detallada y las últimas actualizaciones, consulte la página oficial de asesoramiento sobre PSIRT.

Estos consejos están disponibles en los siguientes enlaces:

- Vulnerabilidad de escalación de privilegios autenticados de Cisco Catalyst SD-WAN Controller, Catalyst SD-WAN Manager y Catalyst SD-WAN Validator

- Vulnerabilidad de escritura arbitraria de archivos del administrador SD-WAN de Cisco Catalyst

Estos defectos se abordan en las siguientes recomendaciones PSIRT:

- ID de bug de Cisco CSCwu18563

- ID de bug de Cisco CSCwu18441

Flujo de trabajo de remediación

Estos avisos describen dos vulnerabilidades de la SD-WAN de Cisco Catalyst. La primera (CVE-2026-20245) es una vulnerabilidad de escalado de privilegios en componentes de control SD-WAN que requiere privilegios netadmin para aprovecharse de ella. El segundo (CVE-2026-20262) es una vulnerabilidad arbitraria de escritura de archivos en el Administrador de SD-WAN (vManage) que permite a un usuario autenticado crear o sobrescribir cualquier archivo en el sistema de archivos de un sistema afectado.

Tanto para CVE-2026-20245 como para CVE-2026-20262, las rutas conocidas para que un atacante remoto no autenticado obtenga las credenciales necesarias son la explotación de CVE-2026-20182 (cisco-sa-sdwan-rpa2-v69WY2SW) o CVE-2026-20127 (cisco-sa-sdwan-rpa-EHchtZk). CVE-2026-20245 requiere privilegios de administrador de red para aprovecharse, mientras que CVE-2026-20262 requiere al menos una cuenta de usuario de tarea única con menos privilegios.

Si sus componentes de control se han actualizado a una versión fija para ambos asesores y Cisco no identificó ningún indicador potencial de compromiso (IoC) en los archivos de administración y tecnología que proporcionó para los eventos anteriores, las rutas de explotación no autenticadas conocidas para CVE-2026-20245 y CVE-2026-20262 se mitigan en esos dispositivos específicos, según los archivos revisados. Esto no elimina la exposición cuando un atacante tiene credenciales válidas. Cisco recomienda actualizar a una versión fija para ambos asesores.

Acción requerida:abra un caso de Cisco TAC para abordar estos avisos de seguridad.

TAC está disponible para:

- Evalúe su entorno en busca de indicadores de compromiso

- Le guiará por la ruta de solución adecuada en función de la evaluación.

- Proporcionar orientación sobre los siguientes pasos a seguir si se identifican indicadores de compromiso

1. Recopile Admin-Techs: ejecute admin-tech en todos los componentes de control (vSmart, vManage, vBond). vSmart admin-techs no se debe ejecutar simultáneamente: ejecútelos de uno en uno. Todos los demás pueden recogerse en cualquier orden. Seleccione las opciones Log (Registro) y Tech (Tecnología).  El núcleo no es necesario.

2. Abra el caso del TAC: comuníquese con el TAC de Cisco y proporcione todos los paquetes de registro de tecnología de administración de componentes de control.

3. Evaluación del TAC: El TAC realiza una evaluación preliminar de los indicadores de compromiso en su entorno basándose en los archivos técnicos de administración proporcionados.

4. Ejecutar remediación: complete el proceso específico proporcionado por el TAC si es necesario.

Paso 1: Recopilar archivos técnicos de administración de todos los componentes de control

required (obligatorio): Recopile los archivos de administración y tecnología de todos los componentes de control antes de realizar cualquier actualización o cambio de configuración para conservar los datos de diagnóstico y cualquier posible indicador de compromiso (IoC). El TAC utiliza estos archivos en el paso 3 para analizar su entorno.

Colección: Para la generación de tecnología de administración, seleccione Log and Tech options (Opciones de registro y tecnología). El núcleo no es necesario.

1. Ejecute admin-tech en ALL Controllers (vsmarts): no ejecute estos controladores simultáneamente; recolectar uno a la vez

2. Ejecute admin-tech en ALL Managers (vManagers)

3. Ejecute admin-tech en ALL Validators (vBonds)

Recopile una Admin-Tech en un entorno SD-WAN y cárguela en un caso TAC

Nota: TAC analiza estos archivos para evaluar su entorno en busca de indicadores de compromiso relacionados con ambos asesores. Para el aviso de escalado de privilegios, el análisis se centra en una entrada de registro específica en /var/log/scripts.log que no distingue entre uso legítimo y malintencionado; se requiere una revisión manual por parte del TAC. Para el aviso de escritura de archivo arbitrario, el análisis se centra en las entradas de /var/log/nms/vmanage-server.log; estas entradas también pueden producirse durante las operaciones estándar y deben evaluarse con respecto a la posición operativa normal para evitar falsos positivos.

Alternativa: Verificación manual (solo si Admin-Tech no puede ser recolectada)

Si no puede compartir los archivos de admin-tech, hay disponible un paso de verificación manual. Este paso proporciona un indicador preliminar que debe documentarse y compartirse con el TAC.

Consulte la sección Pasos de verificación manual al final de este documento para ver un procedimiento detallado. Documente todas las conclusiones y proporciónelas al TAC en su caso de soporte.

Paso 2: Abra un caso TAC y cargue archivos técnicos de administración

Después de recopilar técnicos de administración en el paso 1, abra un caso de soporte del TAC de Cisco y cargue los archivos técnicos de administración recopilados. El TAC analiza los técnicos administrativos para detectar indicadores de compromiso asociados a ambas recomendaciones (CVE-2026-20245 y CVE-2026-20262).

Acciones necesarias:

1. Abra un caso TAC de Gravedad 3 con "CVE-2026-20245, CVE-2026-20262" y las ID de asesoramiento cisco-sa-sdwan-privesc-4uxFrdzx y cisco-sa-sdwan-arbfw-c2rZvQ en el título para iniciar el análisis.

2. Cargue TODOS los paquetes de registro de tecnología de administración recopilados en el paso 1 (Controladores, administradores y validadores).

3. Espere a que el TAC complete el análisis y comunique los resultados.

Nota: Cisco ha publicado correcciones de software para estas vulnerabilidades en todos los trenes de versiones en este momento, pero no hay soluciones alternativas disponibles. El análisis del TAC del paso 3 ayuda a determinar si hay algún indicador de compromiso en los archivos de administración y tecnología que ha proporcionado. Actualice a una versión de software fija y siga la guía del TAC en relación con cualquier otro paso siguiente necesario.

Paso 3: Evaluación del TAC

TAC realiza un análisis preliminar de los archivos admin-tech que cargó en el paso 2 y los evalúa para detectar indicadores de compromiso asociados con ambas recomendaciones (CVE-2026-20245 y CVE-2026-20262).

Para el CVE-2026-2025 de asesoramiento, el análisis se centra en una entrada de registro específica en /var/log/scripts.log en cada componente de control (vManage, vSmart y vBond). Debido a que el comando subyacente es legítimo y el registro no distingue entre uso legítimo y malintencionado, cualquier entrada coincidente requiere una revisión manual por parte del TAC en comparación con su estado operativo normal antes de ser tratada como un indicador confirmado.

Para el CVE-2026-20262 de asesoría, el análisis se centra en varios archivos del directorio /var/log/nms de cada jefe (vManage). En algunos casos, estos indicadores de compromiso pueden producirse durante las operaciones estándar.

Estos registros no distinguen entre uso legítimo y uso malintencionado; por lo tanto, cualquier entrada coincidente requiere una revisión manual por parte del TAC en comparación con su posición operativa normal antes de ser tratada como un indicador confirmado.

Posibles resultados del análisis del TAC:

- No se identificaron entradas de registro coincidentes: según los archivos admin-tech revisados, no se observaron indicadores asociados con ninguno de los dos asesores. Por el momento, no se requiere ninguna otra acción específica para estas recomendaciones. El resultado se limita a los archivos técnicos de administración recibidos y está sujeto al período de retención de registros en cada dispositivo.

- Se identificaron entradas de registro coincidentes: TAC involucra al usuario con pasos de revisión adicionales. Se recomienda actualizar a una versión fija para ambos asesores. Debido a la naturaleza de las recomendaciones, también puede ser necesario tomar medidas adicionales. La guía del TAC para escenarios de compromiso confirmado se documenta en los artículos TechZone relacionados a los que se hace referencia en el Paso 4.

Nota: Según el aviso de CVE-2026-20245, la explotación requiere privilegios de netadmin, mientras que CVE-2026-20262 requiere al menos una cuenta de usuario de tarea única con menos privilegios. Un atacante no autenticado puede obtener esas credenciales mediante credenciales válidas o la explotación de CVE-2026-20182 o CVE-2026-20127. Si los componentes de control se han actualizado a una versión fija para ambos asesores y no se identificaron indicadores de compromiso para los eventos anteriores, las rutas de explotación no autenticadas conocidas para CVE-2026-20245 y CVE-2026-20262 se mitigan en esos dispositivos específicos, según los archivos revisados.

Paso 4: Si se identifican indicadores de compromiso, siga las directrices del TAC

Si el TAC identifica indicadores de compromiso asociados con estos avisos en su entorno, el TAC se pone en contacto con usted para ofrecerle orientación específica. Complete todas las instrucciones proporcionadas por el TAC.

Si no se identifican indicadores de compromiso para ninguno de los dos informes, no se requiere ninguna otra acción específica para la evaluación de compromiso en este momento, según los archivos técnicos de administración revisados. Aún se recomienda encarecidamente actualizar a una versión fija para ambos asesores.

Versiones de software fijas

Estas versiones de software contienen correcciones para las vulnerabilidades identificadas:

Se aplica a las versiones actuales

Versión fija

Software disponible

20.9.9.1 y anteriores

20.9.9.2

20.9.9.2 imágenes de actualización para vManage, vSmart y vBond

20.12.7.1 y anteriores

20.12.7.2

20.12.7.2 imágenes de actualización para vManage, vSmart y vBond

20.15.4.4 y anteriores

20.15.4.5

20.15.4.5 imágenes de actualización para vManage, vSmart y vBond

20.15.5.2 y anteriores

20.15.5.3

20.15.5.3 imágenes de actualización para vManage, vSmart y vBond

20.16, 20.17 y 20.18.x

20.18.3.1

20.18.3.1 imágenes de actualización para vManage, vSmart y vBond

26.1

26.1.1.2

26.1.1.2 imágenes de actualización para vManage, vSmart y vBond

Nota: Para los clientes de CDCS (clúster alojado en Cisco), 20.15.507 también es una versión fija. Esto se aplica específicamente a la implementación de clústeres alojados por Cisco y se gestiona por separado de la ruta de actualización estándar.

Referencias importantes:

- Matriz de actualización

- Matriz de compatibilidad del controlador

- Remediate Catalyst SD-WAN Security Advisory: mayo de 2026

- Remediate Catalyst SD-WAN Security Advisory: febrero de 2026

- Vulnerabilidad de omisión de autenticación del controlador Cisco Catalyst SD-WAN (14 de mayo de 2026)

Consideraciones

Al finalizar la remediación con éxito, y en función de sus requisitos de garantía de seguridad específicos, Cisco recomienda que evalúe y actúe en función de las actividades de higiene enumeradas aquí. Estas actividades se aplican independientemente de la opción de remediación seleccionada. Se administran por el usuario; Cisco no los dirige ni los lleva a cabo en su nombre.

- Revisión de todas las cuentas de usuario locales

- Rotación de credenciales

- Rotación de los secretos presentes en las configuraciones de los dispositivos, por ejemplo (lista no exhaustiva):

- Credenciales para cuentas de usuario locales

- Identificaciones de comunidad SNMP

- claves secretas TACACS

- Certificados y claves previamente compartidas de VPN

- Claves SSH de confianza

- Revisión de plantillas de configuración

Dispositivos periféricos: Sospecha de riesgo

Cisco no recomienda una ruta de remediación concreta; la selección de una opción de solución corresponde a cada cliente.

Nota: Si se sospecha que un dispositivo perimetral está en peligro, el restablecimiento de fábrica y la reincorporación de los dispositivos periféricos afectados es una acción gestionada por el cliente que se debe tener en cuenta al realizar la selección. La decisión sobre si seguir este enfoque y qué opción seleccionar corresponde a cada cliente.

El comando adecuado para realizar un restablecimiento de fábrica seguro es:

factory-reset all secure

Apéndice: Pasos de verificación manual (solo si no es posible la recopilación de tecnología de administrador)

Nota: El método preferido es la colección Admin-tech. Utilice solamente el paso de verificación manual que se muestra aquí si los archivos admin-tech no se pueden recolectar y compartir con el TAC. El resultado de este paso manual es preliminar; documentar las conclusiones y compartirlas con el TAC, que realiza la evaluación oficial.

Nota: En ambos casos, la verificación manual consiste en comprobaciones de registro específicas. Las entradas de registro objetivo de estas comprobaciones son generadas por comandos y actividades legítimos, y los registros por sí solos no distinguen entre uso legítimo y uso malintencionado. Todas las entradas coincidentes deben revisarse en función de su estado operativo normal antes de ser tratadas como un indicador potencial. Si una entrada coincidente no se puede conciliar con las operaciones normales, documente la conclusión y compártala con el TAC.

Verificación para CVE-2026-2025: Verifique scripts.log en cada componente del control para las entradas de carga de archivos

Según el aviso de PSIRT, se recomienda a los usuarios que auditen los archivos de registro para entradas similares a estos ejemplos. En la versión 20.9 y posteriores, estas entradas se encuentran en scripts.log en /var/log/. En las versiones anteriores a 20.9, los datos equivalentes se encuentran en los registros vdebug en /var/log/tmplog/.

Tres comandos de carga legítimos distintos generan entradas en este mismo registro con el mismo formato. Cada uno debe ser auditado:

Entrada de ejemplo para una carga de lista de arrendatarios: vconfd_script_upload_tenant_list.sh:

Apr 15 09:44:57 vmanage vScript: Tenant list upload per vsmart serial number: /usr/bin/vconfd_script_upload_tenant_list.sh -cli path /home/admin/malicious.csv vpn 0

Entrada de ejemplo para una carga de números de serie de vSmart: vconfd_script_upload_vsmart_serial_numbers.sh:

Jun  5 13:06:39 Manager vScript: vSmart upload serial numbers: /usr/bin/vconfd_script_upload_vsmart_serial_numbers.sh -cli path /home/admin/vsmart_serial_numbers_safe.csv

Entrada de ejemplo para una carga de números de chasis ZTP: vconfd_script_upload_chassis_number_file.sh:

Jun  5 13:08:47 Validator vScript: ZTP upload chassis numbers: /usr/bin/vconfd_script_upload_chassis_number_file.sh -cli path /home/admin/chassis_numbers_safe.csv

Paso 1: Acceda a vshell en cada componente de control y busque los archivos de registro apropiados para los indicadores CVE-2026-20245

La ubicación del archivo de registro depende de la versión de software que se ejecuta en el componente de control. Determine qué se aplica a su entorno antes de ejecutar la búsqueda.

Los siguientes comandos de búsqueda utilizan el patrón ampliado vconfd_script_upload_.*\.sh para que una única invocación por ubicación de registro detecte los tres scripts de carga mencionados anteriormente (vconfd_script_upload_tenant_list.sh, vconfd_script_upload_vsmart_serial_numbers.sh y vconfd_script_upload_chassis_number_file.sh).

Versión 20.9 y posterior: busque scripts.log en /var/log/tmplog/:

En la CLI de vManage, vaya a vshell y ejecute:

vs

zgrep -E "vconfd_script_upload_.*\.sh" /var/log/scripts.log*

Versiones anteriores a 20.9 — Search vdebug logs in /var/log/tmplog/:

En las versiones anteriores a 20.9, scripts.log no está presente. Los datos de registro equivalentes se escriben en /var/log/tmplog/vdebug. Se conservan hasta cinco archivos numerados (vdebug, vdebug.1 a vdebug.5). Buscar todos los archivos activos con:

vs

zgrep -E "vconfd_script_upload_.*\.sh" /var/log/tmplog/vdebug*

Además de los archivos activos, los registros más antiguos se archivan como archivos tar comprimidos en /var/log/ utilizando el patrón de nombres vdebug_<timestamp>.tar.gz, con los datos de registro almacenados en el archivo en var/log/tmplog. Buscar en todos los archivos con:

for f in /var/log/vdebug_*.tar.gz; do echo "=== $f ==="; tar -xOf "$f" var/log/tmplog 2>/dev/null | grep -E "vconfd_script_upload_.*\.sh"; done

Repita todas las comprobaciones aplicables en cada componente de control de la implementación (incluidos todos los miembros del clúster y cualquier vManage emparejado con DR).

Paso 2: Interpretar resultados y documentos para TAC

Si NO se devuelven entradas coincidentes:

- No se observaron indicadores de compromiso asociados con este aviso en el archivo de registro de este dispositivo.

- Documente este resultado para su caso TAC (incluya el nombre de host del dispositivo y la fecha/rango de los archivos de registro buscados).

- Continúe con la comprobación de los jefes restantes.

Si se devuelven entradas coincidentes:

- Cada entrada correspondiente debe ser revisada en función de su estado operativo normal. Los comandos subyacentes (carga de lista de arrendatarios, carga de números de serie vSmart y carga de números de chasis ZTP) son legítimos y aparecen durante las operaciones rutinarias.

- Para cada entrada coincidente, capture la marca de tiempo, la línea de registro completa y la ruta de archivo a la que se hace referencia después de la ruta -cli.

- Si una entrada coincidente no se puede conciliar con una operación conocida y legítima, esto es un posible indicador de riesgo. Documente el resultado y proporciónelo al TAC para su revisión.

- Documentar todas las conclusiones y abrir un caso TAC. Incluya las entradas de registro coincidentes y el resultado del comando source en su caso.

- El TAC realizará la evaluación oficial. Si la evaluación identifica indicadores de compromiso, consulte el flujo descrito en los documentos relacionados de TechZone: y las guías de remediación.

Verificación para CVE-2026-20262: Comprobar los archivos de registro de cada jefe (vManage) para entradas arbitrarias de escritura de archivos

Según el aviso de PSIRT, se recomienda a los usuarios que auditen estos archivos de registro en cada administrador (vManage) para obtener entradas similares a estos ejemplos:

Ejemplo de entrada sospechosa en vmanage-server.log (ubicado en /var/log/nms/)

11-June-2026 03:53:37,310 EDT INFO  [a66cdc5f-807d-4c23-944e-5c809a2ece6b] [server] [SdraAnyConnectFileUploadHandler] (default task-40704) |default| uploaded Remote Access Anyconnect profile file: ../../../../var/lib/wildfly/standalone/deployments/suspicious.war to vManage.

Ejemplo de entrada sospechosa en vmanage-appserver.log (ubicado en /var/log/nms/)

11-June-2026 07:52:55,275 UTC INFO  [server] (DeploymentScanner-threads - 2) WFLYSRV0010: Deployed "suspicious.war" (runtime-name : "suspicious.war")

Ejemplo de entrada sospechosa en serviceproxy-access.log (ubicado en /var/log/nms/contenedores/service-proxy/)

POST /suspicious/index.jsp HTTP/1.1

Nota: En las versiones anteriores a 20.9, serviceproxy-access.log se encuentra en /var/log/nms/ en lugar de /var/log/nms/contenedores/service-proxy/.

Paso 1: Acceda a vshell en cada Manager (vManage) y busque los archivos de registro

Desde la CLI de vManage, vaya a vshell y ejecute :

vs

zgrep "SdraAnyConnectFileUploadHandler" /var/log/nms/vmanage-server.log*

zgrep "WFLYSRV0010" /var/log/nms/vmanage-appserver.log*

En algunas versiones, se puede acceder al registro del proxy de servicio directamente desde vshell. En las versiones donde se requiere acceso al shell root, descargue admin-tech y busque los archivos serviceproxy-access.log dentro de él de la misma manera usando un comando similar a:

Versión 20.9 y posteriores:

tar -xOf

.tar.gz var/log/nms/containers/service-proxy/serviceproxy-access.log 2>/dev/null | grep "suspicious"

Versiones anteriores a 20.9:

tar -xOf

.tar.gz var/log/nms/serverproxy-access.log 2>/dev/null | grep "suspicious"

Si accede directamente desde vshell, utilice el nombre de archivo .war identificado a partir de los resultados de los dos comandos anteriores (sin la extensión) en lugar de suspect:

Versión 20.9 y posteriores:

zgrep "POST" /var/log/nms/containers/service-proxy/serviceproxy-access.log* | grep "suspicious"

Versiones anteriores a 20.9:

zgrep "POST" /var/log/nms/serverproxy-access.log* | grep "suspicious"

Repita la comprobación en cada vManage de la implementación (incluidos todos los miembros del clúster y cualquier vManage emparejado con DR).

Paso 2: Interpretar resultados y documentos para TAC

Si NO se devuelven entradas coincidentes:

- No se observaron indicadores de compromiso asociados con este aviso en los archivos de registro de este dispositivo.

- Documente este resultado para su caso TAC (incluya el nombre de host del dispositivo y la fecha/rango de los archivos de registro buscados).

- Continúe con la comprobación de los jefes restantes.

Si se devuelven entradas coincidentes:

- Cada entrada correspondiente debe ser revisada en función de su estado operativo normal. Estas entradas pueden producirse durante las operaciones estándar y no confirman por sí mismas la existencia de un riesgo.

- Para cada entrada coincidente en vmanage-server.log, capture la marca de tiempo, la línea de registro completa y la ruta de acceso al archivo a la que se hace referencia en el controlador de carga.

- Si una entrada coincidente no se puede conciliar con una operación conocida y legítima, esto es un posible indicador de riesgo. Documente el resultado y proporciónelo al TAC para su revisión.

- Documentar todas las conclusiones y abrir un caso TAC. Incluya las entradas de registro coincidentes y el resultado del comando source en su caso.

- El TAC realizará la evaluación oficial. Si la evaluación identifica indicadores de compromiso, consulte el flujo descrito en los documentos relacionados de TechZone: y las guías de remediación.

Preguntas Frecuentes

A: ¿Cuál es el primer paso para abordar estos avisos de seguridad?

R: Recopile archivos de tecnología de administración de todos los componentes de control (vSmart, vManage, vBond) antes de realizar cualquier actualización o cambio de configuración para conservar los datos de diagnóstico y cualquier posible indicador de compromiso. A continuación, abra un caso del Cisco TAC y cargue los técnicos administrativos para que el TAC pueda analizarlos.

A: ¿Ha publicado Cisco una solución de software para estas vulnerabilidades?

R: Sí, las versiones fijas están disponibles para ambos asesores, como se indica en la sección Versiones fijas de software. No hay soluciones alternativas.

A: ¿Por qué recomienda Cisco tomar medidas que van más allá de la actualización?

R: La explotación de estas vulnerabilidades requiere un usuario autenticado. Un atacante no autenticado puede obtener esas credenciales solo a través de credenciales válidas o mediante la explotación de CVE-2026-20182 o CVE-2026-20127. Asegurarse de que los componentes de control se actualicen a las versiones fijas de esos asesores anteriores dirige las rutas no autenticadas conocidas para obtener los privilegios necesarios para explotar estas vulnerabilidades. El análisis técnico-administrativo del paso 3 ayuda a determinar si hay algún indicador de compromiso en los archivos revisados.

A: ¿Necesito recopilar técnicos de administración de todos los componentes de control?

R: Yes. TAC requiere archivos de tecnología de administración de todos los controladores (vSmart, recopilados de uno en uno), todos los administradores (vManage) y todos los validadores (vBond) para realizar el análisis.

A: ¿Cómo determina el TAC si mi sistema tiene indicadores de compromiso asociados con estos avisos?

R: El TAC revisa los archivos técnicos de administración para encontrar indicadores de compromiso específicos para cada aviso. Para el asesor de escalado de privilegios (CVE-2026-20245), el TAC busca entradas de registro específicas en /var/log/scripts.log en cada componente de control. Para el aviso de escritura de archivos arbitrarios (CVE-2026-20262), TAC busca entradas de registro específicas en tres archivos de registro en cada Manager: /var/log/nms/vmanage-server.log, /var/log/nms/vmanage-appserver.log y /var/log/nms/containers/service-proxy/serviceproxy-access.log. En ambos casos, la actividad subyacente puede producirse durante las operaciones estándar; el TAC revisa todas las entradas coincidentes comparándolas con su estado de funcionamiento normal antes de considerarlas un indicador confirmado.

A: ¿Qué ocurre si se identifican indicadores de compromiso?

R: El TAC se pone en contacto con usted para ofrecerle orientación específica. La actualización por sí sola no resuelve un riesgo confirmado. La guía del TAC se basa en el flujo documentado en los artículos relacionados de TechZone para las recomendaciones de mayo de 2026 y febrero de 2026.

A: ¿Se ven afectados por estos consejos los routers periféricos (Cisco IOS XE)?

R: Estas recomendaciones afectan principalmente a los componentes de control de Cisco Catalyst SD-WAN. Para el asesor de escalado de privilegios (CVE-2026-20245), todos los componentes de control (vManage, vSmart, vBond) se ven afectados y Cisco ha observado casos limitados en los que la explotación ha dado lugar a que un cambio de configuración se traslade a los dispositivos periféricos; se recomienda a los usuarios que verifiquen la configuración de sus dispositivos periféricos. Para el aviso arbitrario de escritura de archivos (CVE-2026-20262), la vulnerabilidad se limita al sistema de archivos del administrador SD-WAN y no afecta directamente a los dispositivos periféricos.

A: ¿Qué tipos de implementación se ven afectados?

R: Según estos consejos, estas vulnerabilidades afectan a todos los tipos de implementación de SD-WAN de Cisco Catalyst, independientemente de la configuración del dispositivo, incluidas la implementación in situ, Cisco SD-WAN Cloud-Pro, Cisco SD-WAN Cloud (gestionada por Cisco) y Cisco SD-WAN para instituciones gubernamentales (FedRAMP).

A: Ya he actualizado las recomendaciones de mayo de 2026 y febrero de 2026 y no se han identificado indicadores de compromiso para estos eventos. ¿Estoy expuesto a estas nuevas vulnerabilidades?

R: Si sus componentes de control están ejecutando una versión fija para CVE-2026-20182 y CVE-2026-20127 y no se identificaron indicadores de compromiso para esos eventos anteriores en los archivos admin-tech revisados, las rutas de explotación no autenticadas conocidas para CVE-2026-20245 y CVE-2026-20262 se mitigan en esos dispositivos específicos, según los archivos revisados. Esto no elimina la exposición cuando un atacante tiene credenciales válidas. Cisco recomienda actualizar a una versión fija para estos avisos.

A: ¿Puedo realizar la verificación yo mismo en lugar de esperar al TAC?

R: Los usuarios que no pueden compartir técnicos de administración pueden realizar el paso de verificación manual descrito en el Apéndice. El resultado es preliminar; documentar las conclusiones y compartirlas con el TAC, que realiza la evaluación oficial.

A: ¿Cuáles son las prácticas recomendadas generales para reforzar mi superposición SD-WAN?

R: Consulte la Guía de Consolidación de Cisco Catalyst SD-WAN para conocer las prácticas recomendadas.

A: ¿Proporciona Cisco TAC servicios de análisis o investigación de diagnóstico para estas vulnerabilidades?

R: Cisco TAC puede ayudar a los usuarios revisando los archivos técnicos de administración para encontrar los indicadores de compromiso documentados en ambos avisos PSIRT. Cisco TAC no realiza análisis de diagnóstico en profundidad ni investigaciones de incidentes. Para llevar a cabo un trabajo de diagnóstico completo o investigaciones de seguridad detalladas, se recomienda a los usuarios que contraten a su empresa de respuesta ante incidentes (IR) de terceros preferida.