El 30 de agosto, investigadores de Horizon3 detectaron intentos de explotación reales contra centrales telefónicas Sangoma Switchvox expuestas a internet, desde una misma dirección de atacante y contra varios de sus señuelos. Lo publicaron el 1 de septiembre, con los indicadores para buscarlo en el propio equipo.
La falla es CVE-2026-9586, y ya la cubrimos el miércoles cuando entró al catálogo de CISA junto con otras seis. Lo que cambió desde entonces es lo que más importa: dejó de ser una falla catalogada para pasar a ser una campaña observada, con técnica conocida y rastro verificable.
El parche es la versión 8.4.0.2, publicada el 14 de julio. El plazo que había fijado CISA venció ayer.
Los 47 días entre el parche y el primer ataque
La cronología, toda con fuente en el informe de Horizon3, es el argumento más fuerte de esta nota:
| Fecha | Qué pasó |
|---|---|
| 10 de abril de 2026 | Horizon3 encuentra la falla y la reporta a Sangoma el mismo día |
| 14 de julio de 2026 | Sangoma publica 8.4.0.2 y corrige |
| 30 de agosto de 2026 | Se observan los primeros ataques reales |
| 2 de septiembre de 2026 | CISA la suma al catálogo, plazo de tres días |
| 5 de septiembre de 2026 | Vence el plazo |
Casi siete semanas entre el parche disponible y el primer ataque. Es el margen que separa una actualización programada de una respuesta a incidentes, y en la mayoría de las PyMEs se gasta entero sin que nadie se entere de que existía.
Por qué una inyección SQL termina en ejecución de comandos
La parte técnica explica por qué esta falla es peor de lo que suena "inyección SQL".
Según Horizon3, el problema está en un endpoint sin autenticación, /_pa_, atendido por PhoneAppsHandler.pm, que procesa notificaciones XML de los teléfonos. De ese XML se toma el campo PhoneIP y se concatena directamente a una consulta SQL sin parametrizar. El endpoint acepta contenido que empieza con <PolycomIPPhone> y no lo sanea.
Hasta ahí es una inyección SQL clásica. Lo que la convierte en control del servidor es el privilegio: la consulta corre como superusuario de PostgreSQL. Y PostgreSQL, cuando lo ejecuta un superusuario, permite escribir el resultado de una consulta hacia un programa externo en vez de hacia un archivo. Esa función legítima, pensada para tareas de administración, es la que el atacante usa para hacer que la base ejecute un comando del sistema operativo.
La lección que sobrevive a este CVE en particular: una base de datos que corre con el privilegio máximo convierte cualquier inyección en control del servidor. Es el argumento a favor de que las aplicaciones se conecten con un usuario limitado, aunque sea más trabajo de configuración.
Qué hicieron los atacantes dentro del Switchvox
Horizon3 describe dos etapas. La primera carga fue un shell inverso: hacer que la central se conecte de vuelta a un servidor del atacante y le entregue una línea de comandos. Después vino enumeración: pedirle al equipo la lista de los procesos en ejecución y mandarla afuera.
Es la secuencia habitual de un acceso inicial. Nadie cifra ni roba nada en el primer minuto: primero se mira qué se consiguió. Desde ahí en adelante el camino es el de siempre —movimiento lateral con credenciales válidas—, que es donde se justifica un EDR sobre un antivirus.
¿Cómo sé si mi Switchvox ya fue atacado?
Este es el aporte más útil del informe, porque hay rastro concreto que buscar.
- Revisá el registro
/var/log/switchvox/db-quirks.log. Es donde quedan las consultas anómalas. Horizon3 muestra que los intentos de inyección aparecen ahí, incluyendo los que intentan enviar la salida hacia un programa externo. - Buscá conexiones hacia
176.65.148.184, la dirección desde la que Horizon3 observó los ataques, en los registros del firewall y del propio equipo. - Mirá conexiones salientes inesperadas desde la central hacia internet. Una central telefónica hace tráfico saliente predecible; una conexión a un puerto alto arbitrario no lo es.
- Revisá procesos y tareas programadas en el equipo si encontrás cualquiera de las señales anteriores.
Que no aparezca nada no prueba que estés limpio —un atacante prolijo borra registros— pero que aparezca algo sí prueba lo contrario, y eso ya cambia el plan del día. Si llegás a ese punto, lo que decide cuánto duele es tener una copia de respaldo que no dependa del equipo comprometido.
¿A quién afecta la falla de Sangoma Switchvox?
- A quien tenga una central Switchvox en versión anterior a 8.4.0.2, y más si está publicada a internet.
- Horizon3 contó, vía Shodan, unos 4.000 equipos expuestos, la mayoría en Estados Unidos. Que la concentración esté allá no cambia nada para el que tiene el suyo en Buenos Aires: un equipo publicado es alcanzable desde cualquier parte, y los barridos no eligen país.
Vale agregar un dato del mismo informe: Horizon3 reportó 12 vulnerabilidades distintas en Switchvox, todas ya corregidas. Actualizar no resuelve solo esta.
¿Quién puede ignorar el aviso de Switchvox?
- Quien no tiene Switchvox. Es una falla de este producto, no del protocolo SIP ni de la telefonía IP en general.
- Quien ya está en 8.4.0.2 o posterior.
- Quien usa telefonía en la nube de un proveedor, sin central propia instalada.
- Quien tiene la central accesible solo desde la red interna o por VPN. El endpoint vulnerable no está autenticado, pero hay que poder llegar a él.
Qué hacer con el Switchvox, en orden
- Actualizá a 8.4.0.2 o superior. Está disponible desde el 14 de julio.
- Antes o después de actualizar, revisá el registro. Si ya te atacaron, el parche no deshace el acceso que hayan conseguido: actualizar sin mirar el rastro deja al atacante adentro con la puerta cerrada por fuera.
- Sacá la central de internet si puede vivir sin estar publicada. Los anexos remotos suelen poder entrar por VPN. Es la misma decisión que discutimos en acceso remoto seguro sin VPN y la que ordena el riesgo de todos los aparatos de borde.
- Verificá con qué usuario se conecta la aplicación a su base. Es la corrección de fondo que sobrevive a este CVE.
- Ponele dueño al equipo. Una central telefónica se compra como un teléfono grande y termina siendo un servidor Linux con PostgreSQL que nadie mira, igual que Zimbra y TrueConf.
Preguntas frecuentes sobre CVE-2026-9586 en Switchvox
¿Alcanza con actualizar si ya me atacaron?
No. El parche cierra la vía de entrada, pero no revierte lo que el atacante haya dejado: cuentas nuevas, tareas programadas, claves cambiadas. Si el registro muestra actividad, hay que investigar el equipo además de actualizarlo.
Mi central no está publicada a internet, ¿estoy a salvo?
De los barridos automáticos, sí, porque el atacante tiene que poder llegar al endpoint. Pero si alguien entra a tu red por otro lado, una central sin parchear es un excelente segundo paso: corre Linux, tiene base de datos y casi nunca está monitoreada.
¿Por qué una inyección SQL da ejecución de comandos?
Porque la consulta corre como superusuario de la base, y con ese privilegio PostgreSQL puede enviar la salida de una consulta a un programa externo. Con un usuario de base limitado, la misma inyección se quedaría en leer o alterar datos, que es grave pero no es control del servidor.
El plazo de CISA venció ayer, ¿ya es tarde?
El plazo obliga a las agencias federales de Estados Unidos, no a una empresa argentina. Como señal sigue sirviendo igual: dice que esto se está explotando ahora. Actualizar hoy es tarde respecto del calendario ideal y temprano respecto de lo que viene.
¿Sirve de algo tener antivirus en la central?
En general no hay antivirus corriendo en un aparato de este tipo, y el ataque llega como una petición web legítima en apariencia. Lo que sirve es el registro, el control de qué está publicado y el monitoreo de conexiones salientes.
Fuentes primarias. Divulgación de Horizon3 sobre CVE-2026-9586, publicada el 1 de septiembre de 2026 por Zach Hanley · CVE-2026-9586 en NVD · Catálogo KEV de CISA, versión 2026.09.04.
Consultadas el 6 de septiembre de 2026. El conteo de equipos expuestos es de Horizon3 sobre Shodan y no lo verificamos por cuenta propia. Para el vocabulario, el glosario; para el orden general de prioridades, la guía de ciberseguridad para PyMEs de LATAM.