Une clé secrète JWT partagée expose les serveurs Issabel PBX à l’exécution de commandes à distance

Une clé de signature universelle compromet l’authentification de l’API

Des attaquants exploitent une vulnérabilité critique dans Issabel Framework, le framework web qui sous-tend la plateforme open source Issabel PBX et de communications unifiées.

Répertoriée sous le numéro CVE-2026-89026, cette faille permet à un attaquant distant non authentifié d’exécuter des commandes arbitraires du système d’exploitation avec les privilèges de l’utilisateur Asterisk. L’exploitation ne nécessite ni identifiants volés, ni accès préalable, ni interaction de la part d’un utilisateur.

La vulnérabilité se trouve dans pbxapi/index.php, où Issabel Framework stockait directement dans le code de l’application une clé de signature de JSON Web Token HS256. Le secret était identique sur toutes les installations :

da893kasdfam43k29akdkfaFFlsdfhj23rasdf

Comme HS256 utilise le même secret pour créer et vérifier une signature JWT, toute personne qui connaît cette valeur peut générer des jetons acceptés par les systèmes Issabel vulnérables. L’intégration du secret dans le code source distribué supprime donc la frontière de sécurité que le jeton est censé faire respecter.

La faiblesse est classée CWE-321: Use of Hard-coded Cryptographic Key.

Quelles installations d’Issabel Framework sont concernées

La plage officiellement concernée couvre les versions d’Issabel Framework allant de 0 jusqu’au commit suivant, ce dernier étant exclu :

b97dbaf0b71c1c36f841e672b664afbeb02773bd

Certaines descriptions de la vulnérabilité utilisent la référence abrégée b97dbaf. Pour vérifier qu’un déploiement inclut bien le correctif, les administrateurs doivent se fier au hash complet.

Aucune limite correspondant à une version numérotée n’a été communiquée. Les organisations ne peuvent donc pas déterminer leur exposition de manière fiable en se basant uniquement sur le nom générique du produit Issabel PBX ou sur une branche de versions ; elles doivent vérifier que le code Framework installé intègre le commit correctif.

La vulnérabilité obtient un niveau de criticité élevé selon deux normes CVSS :

Version CVSS	Score	Gravité	Vecteur
CVSS 4.0	9,3	Critique	CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N
CVSS 3.1	9,8	Critique	CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H

Les deux évaluations mettent en évidence le même problème central : l’interface vulnérable est accessible sur le réseau, la complexité de l’attaque est faible et l’exploitation ne nécessite ni privilèges ni interaction de la part d’un utilisateur légitime.

Les opérateurs d’Issabel PBX sont directement exposés. L’exécution intervient avec les privilèges du compte Asterisk ; aucune étape confirmée d’élévation de privilèges ni aucun accès supérieur au système d’exploitation n’ont été décrits.

Du jeton falsifié à la commande du système d’exploitation

La chaîne d’exploitation combine le secret partagé avec une opération puissante de l’API PBX.

Dans un premier temps, l’attaquant signe un JWT à l’aide de la clé HS256 codée en dur. Il présente ensuite ce jeton à l’API Issabel PBX comme justificatif de type bearer. Comme le serveur vulnérable vérifie les signatures avec le même secret intégré, il considère le jeton fabriqué comme authentique.

L’attaquant cible ensuite le point de terminaison suivant :

/pbxapi/manager/originate

La fonction manager originate peut appeler une application Asterisk. En spécifiant l’application System et en fournissant une commande, l’attaquant amène Asterisk à transmettre cette commande au système d’exploitation sous-jacent.

La séquence est donc la suivante :

1. Créer un JWT signé avec le secret partagé par les installations vulnérables.
2. Envoyer ce jeton à l’API PBX.
3. Appeler /pbxapi/manager/originate.
4. Sélectionner l’application System.
5. Fournir une commande du système d’exploitation à exécuter par le processus Asterisk.

Cette faille ne permet pas seulement de lancer des appels sans autorisation ou de modifier les paramètres de téléphonie. Le résultat confirmé est l’exécution de commandes arbitraires avec les privilèges disponibles pour l’utilisateur Asterisk.

Elle montre également pourquoi la rotation des mots de passe ou le renforcement des contrôles de connexion interactive ne s’attaque pas à la cause première. L’attaquant ne s’authentifie pas par l’intermédiaire d’un compte utilisateur classique. Le serveur accepte plutôt un jeton cryptographiquement valide, créé avec un secret qui n’a jamais été unique ni confidentiel.

L’exploitation a été observée avant la publication de la fiche CVE

Un correctif aurait été publié le 1er août 2026. La Shadowserver Foundation a ensuite observé des signes d’exploitation le 9 septembre 2026.

La fiche du programme CVE, publiée et mise à jour le 15 septembre 2026, cite Shadowserver et associe à la vulnérabilité la balise x_known-exploited-vulnerability. Elle identifie également le projet comme open source au moyen de la balise x_open-source.

L’identité du ou des attaquants est inconnue. Aucun nombre estimatif d’installations Issabel analysées, ciblées ou compromises n’a par ailleurs été communiqué.

Les informations disponibles ne décrivent ni les charges utiles, ni les techniques de persistance, ni les activités ultérieures, ni l’infrastructure opérationnelle utilisée pour les attaques. Les défenseurs ne peuvent donc pas encore rattacher l’exploitation à une campagne identifiée ni utiliser un ensemble publié d’indicateurs propres à une campagne.

La désignation « vulnérabilité connue comme exploitée » du programme CVE ne doit pas être confondue avec l’inscription au catalogue Known Exploited Vulnerabilities de la Cybersecurity and Infrastructure Security Agency des États-Unis. Aucune entrée distincte dans le catalogue CISA KEV, aucune date d’ajout, aucune échéance de remédiation ni aucun indicateur d’utilisation par des opérateurs de rançongiciels n’ont été signalés pour CVE-2026-89026.

Le correctif rend le secret JWT propre à chaque installation

Les administrateurs doivent mettre à jour Issabel Framework avec une version intégrant le commit suivant :

b97dbaf0b71c1c36f841e672b664afbeb02773bd

La remédiation supprime le secret partagé de pbxapi/index.php. Le Framework récupère désormais la clé de signature JWT depuis :

/etc/issabel.conf

Chaque installation dispose ainsi de son propre secret de signature configuré, au lieu de dépendre d’une valeur distribuée avec l’application. Les jetons générés avec l’ancienne clé universelle devraient donc échouer à la validation une fois le code et la configuration corrigés.

Aucune mesure de contournement distincte n’a été communiquée. Aucune recommandation documentée n’indique non plus qu’un filtrage réseau suffirait à compenser de manière fiable le maintien de l’implémentation vulnérable.

Lorsqu’une mise à jour immédiate est impossible, limiter l’accès à l’API PBX peut réduire l’exposition, mais cette mesure ne doit pas être considérée comme un contournement officiellement confirmé par l’éditeur. Le problème d’authentification persiste tant que le Framework n’a pas été mis à jour et qu’il accepte encore des jetons signés avec la clé intégrée.

Ce que les défenseurs peuvent examiner

L’exploitation étant confirmée, l’application du correctif doit s’accompagner d’une analyse de l’incident et ne pas être considérée comme une simple mesure préventive.

Les indicateurs techniques actuellement disponibles sont limités à :

/pbxapi/manager/originate

System

da893kasdfam43k29akdkfaFFlsdfhj23rasdf

Les administrateurs peuvent examiner les journaux web, d’API, de reverse proxy et liés à Asterisk afin de repérer les requêtes inattendues vers le point de terminaison manager originate, en particulier celles qui impliquent l’application System. Ils doivent également rechercher les commandes du système d’exploitation lancées par Asterisk qui ne correspondent pas à une activité administrative attendue.

La clé JWT divulguée peut aider à repérer un code source vulnérable ou des hypothèses de configuration dangereuses, mais elle ne constitue pas un indicateur propre à une campagne. Sa présence montre qu’une installation contient cette conception non sécurisée ; elle ne suffit pas, à elle seule, à prouver une compromission.

Aucune règle de détection validée, aucun ensemble d’indicateurs forensiques, aucune liste d’adresses IP malveillantes ni aucune signature de charge utile n’ont été publiés. Le comportement post-exploitation reste également inconnu. Les organisations qui constatent une activité API suspecte doivent donc examiner plus largement l’hôte à la recherche de processus non autorisés, de fichiers modifiés, d’exécutions planifiées et d’autres changements effectués avec le compte Asterisk, sans partir du principe qu’un seul mode opératoire est utilisé.

La priorité est claire : vérifier la révision du Framework installé, déployer la gestion corrigée de la clé JWT et rechercher sur les systèmes exposés toute utilisation antérieure du chemin d’API vulnérable.