La llave maestra que Issabel PBX repitió en cada instalación: CVE-2026-89026 ya se explota en Latinoamérica

Desde el 9 de septiembre de 2026, atacantes automatizados escanean internet buscando instalaciones de Issabel PBX sin parchar, según confirmó la Shadowserver Foundation. El motivo: cada copia de Issabel Framework instalada en el mundo, hasta el 1 de agosto de 2026, traía la misma llave criptográfica de fábrica para firmar sus tokens de sesión. Quien la conoce entra como si fuera administrador, sin usuario ni contraseña.

Issabel es el PBX de código abierto más usado en pymes y centros de contacto de Latinoamérica: nació como fork de Elastix cuando 3CX cerró esa comunidad en 2016, y hoy corre en miles de centralitas telefónicas que nadie trata como un sistema crítico de red. Ese es justo el problema.

Qué es la falla y por qué es tan grave

CVE-2026-89026 está en el archivo pbxapi/index.php del Issabel Framework: una llave HS256 fija, escrita directamente en el código fuente, que el sistema usa para firmar y verificar los JSON Web Tokens (JWT) de autenticación. Como la llave es idéntica en cada instalación del mundo, cualquiera puede forjar un token válido sin necesidad de credenciales, según el análisis técnico publicado por cybersecuritynews.com.

Con ese token forjado, el atacante llama al endpoint /pbxapi/manager/originate usando el parámetro System de Asterisk Manager Interface. Ese parámetro le dice al motor Asterisk que ejecute un comando del sistema operativo, y lo hace con los privilegios del usuario asterisk. El resultado es ejecución remota de comandos, sin autenticación, sin interacción del usuario y sin necesidad de explotar nada más en la red.

La calificación de severidad varía según el estándar: CVSS v4 la ubica en 9.3, y CVSS v3.1 la sube a 9.8 sobre 10, el rango más alto posible en cualquiera de las dos escalas.

Qué puede hacer un atacante una vez adentro

El PBX no es un sistema aislado: se conecta al proveedor de telefonía (el troncal SIP), guarda registros de llamadas, y en la mayoría de las pymes vive en la misma red que el resto de los servidores. Con ejecución de comandos como usuario Asterisk, un atacante puede:

• Originar llamadas hacia números de tarificación especial, generando fraude de peaje telefónico que la empresa paga a fin de mes sin saber por qué.
• Grabar o desviar llamadas, exponiendo conversaciones comerciales o de soporte.
• Usar el PBX comprometido como punto de apoyo para moverse lateralmente hacia el resto de la red interna, que es el riesgo que más le debería importar a quien decide presupuesto de TI.

La firma Rescana documentó el patrón de explotación activa y coincide en que el vector no requiere ni cuenta válida ni ingeniería social: basta con que el panel de administración del PBX sea alcanzable desde internet.

Los datos duros

Dato	Valor
CVE	CVE-2026-89026
CVSS v4	9.3
CVSS v3.1	9.8
Componente	pbxapi/index.php, Issabel Framework
Parche	1 de agosto de 2026, commit b97dbaf
Explotación activa detectada	9 de septiembre de 2026 (Shadowserver)
Privilegio obtenido	Usuario asterisk en el sistema operativo

El parche no agrega autenticación adicional ni cambia el flujo de la API: sustituye la llave fija embebida en el código por una llave única, generada por instalación y guardada en /etc/issabel.conf. Es la corrección correcta, pero resuelve el problema hacia adelante, no hacia atrás.

Ningún reporte público que revisamos, ni el de The Hacker News ni el de cybersecuritynews.com, ofrece una cifra confiable de cuántas instalaciones siguen expuestas en Shodan ni cuántas fueron comprometidas antes del parche. Cualquier número que circule sobre eso hoy no tiene una fuente que lo sostenga, así que no lo vamos a inventar aquí.

Por qué "ya actualicé" no es la respuesta completa

Aquí está el error que más le va a costar a quien administra uno de estos sistemas: instalar el parche del 1 de agosto cierra la puerta hacia adelante, pero no revierte nada de lo que haya pasado entre el momento en que la llave fija quedó expuesta en el código y hoy. Si un atacante forjó un token y entró antes de que tú aplicaras el parche, ese acceso ya ocurrió, y el parche no lo deshace.

El orden correcto es:

1. Confirma la versión y aplica el parche primero. Verifica que tu instalación ya use el commit b97dbaf o posterior, y que /etc/issabel.conf tenga una llave generada localmente, no la que traía de fábrica.
2. Revisa los registros de Asterisk y del PBX antes de dar por cerrado el caso. Busca llamadas a pbxapi/manager/originate con el parámetro System, tokens emitidos fuera de horario de oficina, y llamadas originadas hacia destinos que tu empresa nunca marca (números internacionales de tarificación especial son la señal clásica de fraude de peaje).
3. Revoca y regenera cualquier credencial que el PBX pueda tocar, incluidas las de la base de datos y las cuentas de sistema con las que corre Asterisk, si encuentras cualquier indicio de actividad sospechosa en los logs.
4. Verifica si el panel de administración del PBX sigue expuesto a internet. Si no necesitas administrarlo desde fuera de la oficina, ponlo detrás de una VPN o restringido por lista de IPs. Esa exposición es la que convirtió una falla de código en un incidente activo.
5. Pregúntale a tu proveedor de telefonía o a tu equipo de TI, con esas cuatro preguntas por escrito, no de forma verbal: qué versión corren, cuándo se aplicó el parche, si revisaron logs retroactivos y si el panel está expuesto a internet hoy mismo.

Dónde esto no aplica

Si tu empresa usa un PBX comercial con actualizaciones automáticas gestionadas por el proveedor (una centralita en la nube tipo SaaS, por ejemplo), esta falla específica no te toca directamente, aunque el patrón sí: cualquier sistema con una llave de firma fija de fábrica es vulnerable por diseño, la pregunta es si ya se descubrió o no. Tampoco tiene sentido migrar de PBX de urgencia si tu instalación ya está parchada, aislada de internet y sin evidencia de tokens sospechosos en los logs: eso sería gastar presupuesto en resolver un problema que ya no tienes, en vez de invertirlo en la revisión de logs que sí hace falta.

Lo que sí conviene evitar es la respuesta reflejo de "vamos a reemplazar todo el sistema telefónico". El problema no es Issabel como plataforma, es una llave de fábrica que debió generarse por instalación desde el diseño original, un error de ingeniería que cualquier sistema con autenticación por token puede cometer si nadie audita ese punto.

Qué hacer si nadie en tu equipo puede revisar esto hoy

Revisar logs de Asterisk en busca de tokens forjados y llamadas anómalas no es una tarea que se resuelva leyendo un boletín: requiere alguien que sepa qué patrón buscar y tiempo para hacerlo bien. Si tu equipo de TI ya está saturado con la operación diaria, una revisión de vulnerabilidades apoyada en IA puede priorizar ese tipo de hallazgo y guiar la remediación sin que dependa de que alguien se acuerde de revisarlo manualmente cada semana.

Este tipo de fallas (una llave fija, un secreto compartido, un valor por defecto que nadie cambió) rara vez sale en la auditoría anual. Sale cuando alguien externo la encuentra primero, como pasó aquí. Vale la pena que la próxima revisión de infraestructura de tu empresa incluya, explícitamente, los sistemas de telefonía y no sólo los servidores que ya sabes que son sensibles. Si quieres una segunda opinión sobre cómo montar esa revisión, automatizamos ese seguimiento en vez de dejarlo para la próxima vez que algo se caiga.

Fuentes

• Attackers Exploit Issabel Framework Flaw Enabling Unauthenticated OS Command Execution, The Hacker News
• Critical Issabel PBX Command Execution Vulnerability Exploited in the Wild, cybersecuritynews.com
• Issabel PBX Vulnerability CVE-2026-89026 Exploited in the Wild, securityonline.info
• Active Exploitation Alert: Issabel PBX CVE-2026-89026, Rescana
• Qué es y para qué sirve Issabel, Servnet