Por Canuto  

Una vulnerabilidad crítica de Sangoma Switchvox ya está siendo explotada contra sistemas expuestos a internet. La falla permite ejecutar comandos sin autenticación y podría afectar a miles de plataformas VoIP que aún no han instalado la actualización publicada por Sangoma en julio.
***

  • Horizon3 y Defused Cyber detectaron intentos activos de explotación de CVE-2026-9586 desde el 30 de agosto de 2026.
  • La falla de inyección SQL afecta un endpoint HTTP sin autenticación y puede escalar hasta la ejecución de comandos en el servidor.
  • Sangoma publicó Switchvox 8.4.0.2 el 14 de julio; los administradores deben actualizar y revisar registros en busca de compromiso.

Una falla crítica llega a la etapa de explotación

Una vulnerabilidad crítica de Sangoma Switchvox comenzó a atraer ataques contra sistemas de telefonía empresarial expuestos a internet, en una señal de que la ventana para aplicar parches se redujo de forma considerable. La falla, identificada como CVE-2026-9586, permite enviar solicitudes sin autenticación y podría terminar en la ejecución de comandos del sistema operativo alojado en el servidor VoIP.

Horizon3 informó que sus investigadores observaron intentos activos de explotación en honeypots desplegados junto con Defused Cyber, una actividad detectada el 30 de agosto de 2026. El hallazgo resulta relevante porque Sangoma había publicado una corrección el 14 de julio, por lo que las organizaciones tuvieron varias semanas para actualizar sus instalaciones antes de que aparecieran señales de ataques en la naturaleza.

La vulnerabilidad se encuentra en un endpoint HTTP llamado /pa, utilizado por Switchvox para procesar solicitudes relacionadas con notificaciones telefónicas. De acuerdo con los investigadores, el parámetro PhoneIP controlado por un atacante se incorpora directamente a una consulta PostgreSQL sin una parametrización adecuada, lo que abre la puerta a la inyección de instrucciones SQL arbitrarias.

El problema no se limita a la manipulación de información en la base de datos, ya que Horizon3 demostró que la cadena de explotación puede alcanzar la ejecución de comandos del sistema operativo. La vulnerabilidad recibió una puntuación CVSS de 9,3, considerada crítica, aunque las fuentes públicas presentan diferencias sobre las versiones específicas afectadas.

Cómo funciona el riesgo para las empresas

Sangoma Switchvox es una plataforma de comunicaciones unificadas basada en VoIP y construida sobre el motor de código abierto Asterisk, con presencia especialmente orientada a pequeñas y medianas empresas. El producto puede desplegarse en instalaciones propias, servicios en la nube o infraestructuras virtualizadas, de modo que su exposición depende de la arquitectura elegida por cada organización.

El ataque comienza con una solicitud HTTP POST especialmente manipulada que llega a un endpoint que no exige credenciales. Esa característica elimina una barrera defensiva importante, porque un actor remoto puede sondear sistemas visibles desde internet sin necesitar primero una cuenta legítima o la interacción de un empleado.

En la actividad observada por los investigadores, el atacante intentó utilizar la capacidad de ejecución de comandos de PostgreSQL para invocar nc y después empleó curl para enviar información sobre los procesos en ejecución hacia una infraestructura bajo su control. Estos indicios sugieren una fase de reconocimiento y recopilación, aunque la presencia de esas órdenes debe correlacionarse con otros datos antes de confirmar un compromiso.

La superficie potencial también preocupa por el número de dispositivos visibles en línea. Una búsqueda realizada en Shodan por Horizon3 identificó aproximadamente 4.000 sistemas Switchvox expuestos a internet, la mayoría ubicados en Estados Unidos, aunque esa cifra no significa que todos sean vulnerables o que hayan sido comprometidos.

Qué deben revisar los administradores

La medida prioritaria consiste en actualizar Switchvox a la versión 8.4.0.2 o una posterior, actualización que Sangoma publicó el 14 de julio de 2026 e incluyó entre las correcciones de seguridad del producto. Los equipos responsables también deben determinar si la interfaz del sistema está accesible desde internet pública, porque esa condición aumenta la probabilidad de que el servidor sea localizado y sometido a intentos automatizados.

Las organizaciones con acceso SSH pueden revisar el archivo /var/log/switchvox/db-quirks.log en busca de evidencias de instrucciones SQL inyectadas, según la recomendación de Horizon3. Sin embargo, una entrada sospechosa no debería analizarse de forma aislada: conviene compararla con solicitudes al endpoint /pa, conexiones salientes inusuales, procesos inesperados y registros de otros dispositivos de la red.

También resulta necesario buscar señales de ejecución de comandos en la telemetría del host y en los controles de red, especialmente aquellas vinculadas con conexiones mediante nc o transferencias realizadas con curl. Si los administradores encuentran indicios de que una orden se ejecutó con éxito, deben tratar el servidor como potencialmente comprometido y activar el procedimiento de respuesta a incidentes, en lugar de limitarse a instalar la actualización.

Las discrepancias sobre el rango de versiones afectadas aconsejan evitar conclusiones basadas únicamente en una versión antigua. Las notas de Sangoma describen CVE-2026-9586 como un problema de Switchvox 8.2.2.1, mientras que el registro del CNA identifica Switchvox SMB Edition 8.3, compilación 104997, y versiones anteriores a la 8.4.0.2; por ello, Horizon3 y Security Risk Advisors recomiendan actualizar los sistemas SMB a la versión corregida o posterior.

Una carrera contra la explotación temprana

La cronología del caso ilustra la presión que enfrentan los administradores cuando una vulnerabilidad afecta infraestructura conectada a internet. Horizon3 reportó el problema a Sangoma el 10 de abril de 2026, la compañía reconoció el informe ese mismo día y el 21 de abril entregó una versión preliminar con correcciones de validación antes del lanzamiento público de la actualización.

La diferencia entre la fecha del parche y la detección de los primeros intentos de explotación fue de aproximadamente seis semanas. Ese intervalo puede parecer suficiente para organizaciones con inventarios actualizados y procesos maduros, pero se vuelve estrecho cuando existen sistemas olvidados, dispositivos administrados por terceros o cambios de configuración que vuelven a exponer una interfaz previamente restringida.

El caso también muestra por qué la visibilidad de activos debe acompañar al proceso de actualización. Un sistema visible en internet no necesariamente contiene la versión vulnerable ni evidencia de intrusión, pero su presencia facilita que los atacantes lo identifiquen, comparen su respuesta con patrones conocidos y prueben solicitudes contra endpoints que no deberían estar abiertos.

Help Net Security informó que las organizaciones usuarias de Switchvox deben comprobar de inmediato si existen señales de compromiso, mientras que eSecurity Planet destacó la necesidad de aplicar el parche y revisar los registros del servidor. Para las empresas que todavía no han actualizado, la secuencia más prudente es corregir primero la exposición, preservar evidencias relevantes y luego determinar si el atacante llegó antes que el equipo de seguridad.

Imagen original de DiarioBitcoin, creada con inteligencia artificial, de uso libre, licenciada bajo Dominio Público.

Este artículo fue escrito por un redactor de contenido de IA y revisado por un editor humano para garantizar calidad y precisión.


ADVERTENCIA: DiarioBitcoin ofrece contenido informativo y educativo sobre diversos temas, incluyendo criptomonedas, IA, tecnología y regulaciones. No brindamos asesoramiento financiero. Las inversiones en criptoactivos son de alto riesgo y pueden no ser adecuadas para todos. Investigue, consulte a un experto y verifique la legislación aplicable antes de invertir. Podría perder todo su capital.

Suscríbete a nuestro boletín

Artículos Relacionados