Contexte de la vulnérabilité
Le framework Issabel, utilisé comme interface web pour le PBX open‑source Asterisk, intègre un module pbxapi exposant plusieurs points d’accès REST. En septembre 2026, VulnCheck a identifié une faille classée CVE‑2026‑89026 avec un score CVSS v3.1 de 9.8 et v4.0 de 9.3. Cette vulnérabilité repose sur un jeton JSON Web Token (JWT) signé avec la même clé HS256 codée en dur dans le fichier pbxapi/index.php de chaque installation.
const JWT_KEY = "da893kasdfam43k29akdkfaFFlsdfhj23rasdf";La présence d’une clé identique sur toutes les instances permet à un attaquant distant non authentifié de générer des tokens valides et d’accéder aux API internes.
Mécanisme d’exploitation
Un acteur malveillant crée un JWT portant le champ alg HS256 et signe le payload avec la clé codée en dur. Le token ainsi forgé est présenté comme un bearer token dans l’en‑tête HTTP. Le serveur accepte le token et autorise l’appel du point d’accès /pbxapi/manager/originate. En spécifiant le paramètre Application=System, l’API transmet la commande au moteur Asterisk, qui l’exécute sous l’identité de l’utilisateur système asterisk. Le résultat est une exécution de commandes OS arbitraires, sans aucune étape d’authentification préalable.
La chaîne d’exploitation repose sur trois éléments mesurables : la clé statique (identique sur chaque déploiement), le endpoint non protégé (/pbxapi/manager/originate) et le paramètre System qui déclenche l’appel système d’Asterisk. La combinaison de ces facteurs réduit la barrière d’entrée à la simple génération d’un JWT valide.
Correction et recommandations
Le correctif officiel, publié le 1 août 2026, remplace la clé codée en dur par une valeur dynamique lue dans /etc/issabel.conf. Cette modification empêche la réutilisation d’un même secret entre plusieurs installations et oblige chaque serveur à disposer d’un secret unique. Le patch modifie également la logique de validation du token afin de refuser les JWT signés avec HS256 lorsqu’une configuration de clé externe est détectée.
Les administrateurs doivent appliquer immédiatement la mise à jour fournie par le projet Issabel. Par ailleurs, il est recommandé de :
• Vérifier que le fichier /etc/issabel.conf contient un secret aléatoire d’au moins 32 octets.
• Restreindre l’accès réseau au répertoire /pbxapi via des listes de contrôle d’accès (ACL) ou un pare‑feu d’application web.
• Activer la journalisation des appels à /pbxapi/manager/originate et surveiller les tentatives d’utilisation du paramètre System.
• Effectuer des tests de pénétration ciblant les JWT afin de confirmer l’absence de clés résiduelles.
La Shadowserver Foundation a détecté les premiers signes d’exploitation le 9 septembre 2026, mais aucune donnée publique n’indique l’ampleur réelle de l’attaque. En l’absence d’informations supplémentaires, la priorité reste la mise à jour du secret et le durcissement des points d’accès API.
