Una clave JWT codificada de forma rígida en Issabel Framework permite ejecutar comandos del sistema operativo sin autenticación

En el framework web Issabel Framework, utilizado para gestionar sistemas PBX basados en Asterisk, se ha descubierto la vulnerabilidad CVE-2026-89026, que permite a un atacante remoto no autenticado ejecutar comandos arbitrarios del sistema operativo. La causa es una clave de firma JWT (JSON Web Token) codificada de forma rígida, idéntica en todas las instalaciones del framework. Según VulnCheck, un atacante puede falsificar el token de autorización y, a través del endpoint de la API de Asterisk, lanzar comandos del sistema. El parche está disponible en el repositorio oficial del proyecto; se recomienda a los administradores aplicarlo de inmediato.

Detalles técnicos de la vulnerabilidad

Issabel Framework es un framework web de código abierto que unifica módulos de gestión de telefonía IP (PBX) basados en Asterisk. La vulnerabilidad afecta al mecanismo de autenticación de la PBX API: en el archivo index.php del componente pbxapi se utiliza el algoritmo HS256 con una clave secreta codificada de forma rígida para firmar los tokens JWT. Dado que esta clave es idéntica en todas las instalaciones, cualquier atacante que conozca su valor puede generar un token bearer válido sin pasar por el proceso de autenticación.

Según se indica en el aviso de seguridad de VulnCheck, la cadena de ataque es la siguiente:

1. El atacante crea un token JWT falso utilizando la conocida clave de firma codificada de forma rígida.
2. Con ese token se envía una petición al endpoint /pbxapi/manager/originate.
3. En el parámetro System application se pasa un comando arbitrario del sistema operativo.
4. Asterisk ejecuta ese comando en nombre del usuario Asterisk.

De este modo, la explotación no requiere credenciales ni acceso previo al sistema: basta con que la PBX API sea accesible por red. En los materiales disponibles no se indica el intervalo de versiones afectadas, lo que dificulta evaluar el alcance de las instalaciones vulnerables.

Nota: las puntuaciones CVSS v3.1 (9.8) y CVSS v4.0 (9.3) indicadas en el informe original no han sido confirmadas de forma independiente a través de los registros NVD o CNA disponibles.

Análisis del parche

La corrección publicada en el commit del repositorio oficial elimina la causa raíz: la clave secreta codificada de forma rígida se sustituye por una clave cargada desde el archivo de configuración /etc/issabel.conf. El análisis del diff del commit muestra que el parche no solo traslada la clave a la configuración, sino que introduce comprobaciones de seguridad adicionales:

• El parámetro pbxapijwtsecret debe estar presente en /etc/issabel.conf; si falta, la inicialización de la PBX API finaliza con un error (RuntimeException).
• El valor del parámetro debe ser una cadena en Base64 que, al decodificarse, contenga al menos 32 bytes aleatorios. Si esta condición no se cumple, la API tampoco se iniciará.

Se trata de un matiz operativo importante: no basta con actualizar el código. Si después de aplicar el parche falta en el archivo de configuración un secreto correctamente generado, la PBX API dejará de funcionar. Los administradores deben no solo actualizar el código, sino también generar una clave criptográficamente robusta e incluirla en la configuración.

Información sobre la explotación

Según el informe original, Shadowserver Foundation ha registrado intentos de explotación de CVE-2026-89026 desde el 9 de septiembre de 2026. Sin embargo, esta información se ha transmitido a través de VulnCheck y no ha sido confirmada de forma independiente durante la verificación en las fuentes primarias disponibles. En el momento del análisis, la vulnerabilidad no figura en el catálogo CISA Known Exploited Vulnerabilities. No hay datos sobre atacantes concretos, víctimas ni el alcance de la campaña.

Evaluación del impacto

Issabel se utiliza como plataforma para sistemas PBX corporativos y de operadores. La compromisión de un sistema de este tipo puede dar lugar a:

• Ejecución de comandos arbitrarios en el servidor de telefonía con los privilegios del usuario Asterisk.
• Intercepción y manipulación del tráfico de voz.
• Uso del servidor comprometido como punto de apoyo para un movimiento lateral posterior en la red.
• Interrupción del servicio de telefonía de la organización.

Con frecuencia, los sistemas PBX se alojan en segmentos de red con controles debilitados y pueden ser accesibles desde internet, lo que aumenta la superficie de ataque.

Recomendaciones

1. Aplique el parche del commit oficial lo antes posible.
2. Genere un secreto criptográficamente robusto, de al menos 32 bytes aleatorios codificados en Base64, e introdúzcalo como valor de pbxapijwtsecret en el archivo /etc/issabel.conf.
3. Compruebe el funcionamiento de la PBX API después de la actualización: asegúrese de que la API se inicializa correctamente con la nueva clave.
4. Restrinja el acceso de red al endpoint /pbxapi/; no debe ser accesible desde internet salvo que sea estrictamente necesario.
5. Realice una auditoría de los registros en busca de accesos sospechosos a /pbxapi/manager/originate, especialmente desde direcciones IP atípicas.

Dada la trivialidad de la explotación —una clave codificada de forma rígida convierte de facto la autenticación en una formalidad— no se debe retrasar la actualización. Incluso en ausencia de una explotación masiva confirmada, el mero hecho de que el valor de la clave y la descripción del vector de ataque sean de dominio público convierte cada instalación de Issabel Framework sin parche en un posible objetivo. La acción prioritaria es actualizar el código, generar un secreto único y asegurarse de que la PBX API no es accesible desde redes no confiables.