Ein gemeinsames JWT-Geheimnis ermöglicht die Remotecodeausführung auf Issabel-PBX-Servern

Ein universeller Signaturschlüssel hebelt die API-Authentifizierung aus

Angreifer nutzen derzeit eine kritische Schwachstelle im Issabel Framework aus, dem Webframework hinter der quelloffenen Issabel-PBX- und Unified-Communications-Plattform.

Die als CVE-2026-89026 erfasste Schwachstelle ermöglicht es einem entfernten, nicht authentifizierten Angreifer, beliebige Betriebssystembefehle mit den Rechten des Benutzers Asterisk auszuführen. Für die Ausnutzung sind weder gestohlene Zugangsdaten noch ein vorheriger Zugriff oder eine Benutzerinteraktion erforderlich.

Die Schwachstelle befindet sich in pbxapi/index.php. Dort hatte das Issabel Framework einen HS256-Signaturschlüssel für JSON Web Tokens direkt im Anwendungscode hinterlegt. Das Geheimnis war bei allen Installationen identisch:

da893kasdfam43k29akdkfaFFlsdfhj23rasdf

Da HS256 dasselbe Geheimnis zum Erstellen und Verifizieren einer JWT-Signatur verwendet, kann jeder, der diesen Wert kennt, von anfälligen Issabel-Systemen akzeptierte Token erzeugen. Durch die Einbettung des Geheimnisses in den verteilten Quellcode entfällt somit die Sicherheitsgrenze, die der Token eigentlich durchsetzen soll.

Die Schwachstelle ist als CWE-321: Use of Hard-coded Cryptographic Key klassifiziert.

Welche Issabel-Framework-Installationen betroffen sind

Der offiziell betroffene Bereich umfasst Issabel-Framework-Versionen ab 0 bis einschließlich der Version vor dem folgenden Commit:

b97dbaf0b71c1c36f841e672b664afbeb02773bd

In einigen Schwachstellenbeschreibungen wird die verkürzte Referenz b97dbaf verwendet. Administratoren sollten bei der Prüfung, ob eine Installation den Fix enthält, den vollständigen Hash heranziehen.

Eine Versionsgrenze für ein nummeriertes Release wurde nicht veröffentlicht. Unternehmen können ihre Gefährdung daher nicht allein anhand eines allgemeinen Issabel-PBX-Produktnamens oder einer Release-Reihe sicher bestimmen. Sie müssen prüfen, ob der installierte Framework-Code den korrigierenden Commit enthält.

Die Schwachstelle erreicht nach zwei CVSS-Standards eine kritische Bewertung:

CVSS-Version	Score	Schweregrad	Vektor
CVSS 4.0	9.3	Kritisch	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	Kritisch	CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H

Beide Bewertungen spiegeln dasselbe Kernproblem wider: Die anfällige Schnittstelle ist über das Netzwerk erreichbar, die Angriffskomplexität ist gering, und für die Ausnutzung sind weder Berechtigungen noch eine Interaktion durch einen legitimen Benutzer erforderlich.

Betreiber von Issabel-PBX-Systemen sind unmittelbar gefährdet. Die Befehle werden zunächst im Kontext des Asterisk-Kontos ausgeführt. Eine bestätigte Phase zur Rechteausweitung oder ein höherer Zugriff auf das Betriebssystem wurde nicht beschrieben.

Vom gefälschten Token zum Betriebssystembefehl

Die Angriffskette kombiniert das gemeinsame Geheimnis mit einer leistungsfähigen PBX-API-Funktion.

Zunächst signiert der Angreifer einen JWT mit dem fest im Code hinterlegten HS256-Schlüssel. Anschließend wird der Token der Issabel-PBX-API als Bearer-Credential übermittelt. Da der anfällige Server Signaturen mit demselben eingebetteten Geheimnis prüft, akzeptiert er den vom Angreifer erzeugten Token als authentisch.

Anschließend nimmt der Angreifer diesen Endpunkt ins Visier:

/pbxapi/manager/originate

Mit der Manager-originate-Funktion lässt sich eine Asterisk-Anwendung aufrufen. Wird die Anwendung System ausgewählt und ein Befehl übergeben, veranlasst der Angreifer Asterisk, diesen an das zugrunde liegende Betriebssystem weiterzureichen.

Die Abfolge sieht somit folgendermaßen aus:

1. Einen JWT erstellen, der mit dem bei anfälligen Installationen gemeinsamen Geheimnis signiert ist.
2. Diesen Token an die PBX-API übermitteln.
3. /pbxapi/manager/originate aufrufen.
4. Die Anwendung System auswählen.
5. Einen Betriebssystembefehl zur Ausführung durch den Asterisk-Prozess übergeben.

Die Auswirkungen beschränken sich damit nicht auf das unbefugte Initiieren von Anrufen oder die Manipulation von Telefoneinstellungen. Bestätigt ist die Ausführung beliebiger Befehle mit den Berechtigungen, die dem Benutzer Asterisk zur Verfügung stehen.

Die Schwachstelle zeigt außerdem, warum das Ändern von Passwörtern oder eine strengere Kontrolle interaktiver Anmeldungen die eigentliche Ursache nicht behebt. Der Angreifer authentifiziert sich nicht über ein reguläres Benutzerkonto. Stattdessen akzeptiert der Server einen kryptografisch gültigen Token, der mit einem Geheimnis erstellt wurde, das nie installationsspezifisch oder privat war.

Ausnutzung bereits vor Veröffentlichung des CVE-Eintrags beobachtet

Ein Patch soll am 1. August 2026 eingespielt worden sein. Die Shadowserver Foundation beobachtete anschließend am 9. September 2026 Hinweise auf eine Ausnutzung.

Der CVE-Program-Eintrag, der am 15. September 2026 veröffentlicht und aktualisiert wurde, nennt Shadowserver als Quelle und versieht die Schwachstelle mit dem Tag x_known-exploited-vulnerability. Außerdem kennzeichnet er das Projekt mit dem Tag x_open-source als Open Source.

Die Identität des Angreifers oder der Angreifer ist nicht bekannt. Ebenso gibt es keine veröffentlichte Schätzung dazu, wie viele Issabel-Installationen gescannt, angegriffen oder kompromittiert wurden.

Die verfügbaren Informationen enthalten keine Angaben zu Payloads, Persistenztechniken, Folgeaktivitäten oder der operativen Infrastruktur hinter den Angriffen. Daher können Sicherheitsverantwortliche die Ausnutzung derzeit keiner bekannten Kampagne zuordnen oder auf eine veröffentlichte Sammlung kampagnenspezifischer Indikatoren zurückgreifen.

Die Kennzeichnung als bekannte ausgenutzte Schwachstelle durch das CVE-Programm darf nicht mit einer Aufnahme in den Katalog der Known Exploited Vulnerabilities der US-amerikanischen Cybersecurity and Infrastructure Security Agency verwechselt werden. Für CVE-2026-89026 wurden weder ein separater CISA-KEV-Eintrag noch ein Aufnahmedatum, eine Frist zur Behebung oder eine Kennzeichnung zur Nutzung durch Ransomware gemeldet.

Der Fix macht das JWT-Geheimnis installationsspezifisch

Administratoren sollten das Issabel Framework auf einen Code-Stand aktualisieren, der den folgenden Commit enthält:

b97dbaf0b71c1c36f841e672b664afbeb02773bd

Durch die Behebung wird das gemeinsame Geheimnis aus pbxapi/index.php entfernt. Stattdessen bezieht das Framework den JWT-Signaturschlüssel aus:

/etc/issabel.conf

Damit verfügt jede Installation über ein eigenes konfiguriertes Signaturgeheimnis, anstatt einen mit der Anwendung ausgelieferten Wert zu verwenden. Token, die mit dem alten universellen Schlüssel erzeugt wurden, sollten nach der Installation des korrigierten Codes und der entsprechenden Konfiguration folglich nicht mehr validiert werden.

Ein separater Workaround wurde nicht veröffentlicht. Ebenso gibt es keine dokumentierte Empfehlung, wonach eine reine Netzwerkfilterung die weitere Nutzung der anfälligen Implementierung sicher kompensieren könnte.

Wenn eine sofortige Aktualisierung nicht möglich ist, kann die Einschränkung des Zugriffs auf die PBX-API die Gefährdung reduzieren. Sie sollte jedoch nicht als bestätigter Hersteller-Workaround betrachtet werden. Das grundlegende Authentifizierungsproblem bleibt bestehen, bis das Framework aktualisiert wurde und keine Token mehr akzeptiert, die mit dem eingebetteten Schlüssel signiert sind.

Was Sicherheitsverantwortliche untersuchen können

Da eine Ausnutzung bestätigt ist, sollte die Aktualisierung von einer Untersuchung möglicher Sicherheitsvorfälle begleitet werden und nicht nur als vorbeugende Wartungsmaßnahme gelten.

Die derzeit verfügbaren technischen Indikatoren sind begrenzt:

/pbxapi/manager/originate

System

da893kasdfam43k29akdkfaFFlsdfhj23rasdf

Administratoren können Web-, API-, Reverse-Proxy- und Asterisk-bezogene Protokolle auf unerwartete Anfragen an den Manager-originate-Endpunkt prüfen, insbesondere auf Anfragen, in denen die Anwendung System verwendet wird. Außerdem sollten sie nach Betriebssystembefehlen suchen, die von Asterisk gestartet wurden und nicht zu erwarteten administrativen Aktivitäten gehören.

Der veröffentlichte JWT-Schlüssel eignet sich dazu, anfälligen Quellcode oder unsichere Konfigurationsannahmen zu identifizieren, ist jedoch kein kampagnenspezifischer Indikator. Sein Vorhandensein zeigt, dass eine Installation das unsichere Design enthält; allein daraus lässt sich kein erfolgreicher Angriff ableiten.

Es wurde bislang weder eine validierte Erkennungsregel noch ein Paket forensischer Indikatoren, eine Liste schädlicher IP-Adressen oder eine Payload-Signatur veröffentlicht. Auch das Verhalten nach einer erfolgreichen Ausnutzung ist unbekannt. Unternehmen, die verdächtige API-Aktivitäten feststellen, sollten daher den betroffenen Host umfassend auf unbefugte Prozesse, veränderte Dateien, geplante Ausführungen und andere Änderungen unter dem Asterisk-Konto untersuchen, ohne von einem einheitlichen Vorgehen aller Angreifer auszugehen.

Die Priorität ist eindeutig: die installierte Framework-Revision prüfen, die korrigierte Verarbeitung des JWT-Schlüssels bereitstellen und exponierte Systeme auf eine vorherige Nutzung des anfälligen API-Pfads untersuchen.