Hart codierter JWT-Schlüssel im Issabel Framework ermöglicht Betriebssystembefehle ohne Authentifizierung

Im Web-Framework Issabel Framework, das zur Verwaltung von PBX-Systemen auf Basis von Asterisk verwendet wird, wurde die Schwachstelle CVE-2026-89026 entdeckt, die einem nicht authentifizierten entfernten Angreifer erlaubt, beliebige Befehle des Betriebssystems auszuführen. Ursache ist ein hart codierter JWT-(JSON Web Token)-Signaturschlüssel, der in allen Installationen des Frameworks identisch ist. Nach Angaben von VulnCheck kann ein Angreifer das Autorisierungstoken fälschen und über den Asterisk-API-Endpunkt Systembefehle starten. Der Patch ist im offiziellen Repository des Projekts verfügbar – Administratoren wird empfohlen, ihn umgehend einzuspielen.

Technische Details der Schwachstelle

Issabel Framework ist ein Open-Source-Webframework, das Module zur Verwaltung von IP-Telefonie-PBX-Systemen auf Basis von Asterisk bündelt. Die Schwachstelle betrifft den Authentifizierungsmechanismus der PBX API: In der Datei index.php der Komponente pbxapi wird der Algorithmus HS256 mit einem hart codierten geheimen Schlüssel zur Signierung von JWT-Token verwendet. Da dieser Schlüssel in allen Installationen identisch ist, kann jeder Angreifer, der seinen Wert kennt, ein gültiges Bearer-Token erzeugen, ohne eine Authentifizierung durchlaufen zu müssen.

Wie im Sicherheitshinweis von VulnCheck berichtet, sieht die Angriffskette wie folgt aus:

1. Der Angreifer erzeugt ein gefälschtes JWT-Token unter Verwendung des bekannten hart codierten Signaturschlüssels.
2. Mit diesem Token wird eine Anfrage an den Endpunkt /pbxapi/manager/originate gestellt.
3. Im Parameter System application wird ein beliebiger Betriebssystembefehl übergeben.
4. Asterisk führt diesen Befehl im Kontext des Benutzers Asterisk aus.

Die Ausnutzung erfordert somit weder Zugangsdaten noch einen vorherigen Zugriff auf das System – es genügt, dass die PBX API über das Netzwerk erreichbar ist. Der Bereich der betroffenen Versionen ist in den verfügbaren Materialien nicht angegeben, was die Einschätzung des Umfangs verwundbarer Installationen erschwert.

Hinweis: Die CVSS-v3.1- (9.8) und CVSS-v4.0-Bewertungen (9.3), die im ursprünglichen Bericht angegeben sind, wurden nicht unabhängig anhand verfügbarer NVD- oder CNA-Einträge bestätigt.

Analyse des Patches

Die im Commit des offiziellen Repositorys veröffentlichte Korrektur beseitigt die eigentliche Ursache – das hart codierte Geheimnis wird durch einen Schlüssel ersetzt, der aus der Konfigurationsdatei /etc/issabel.conf geladen wird. Die Analyse des Diffs des Commits zeigt, dass der Patch den Schlüssel nicht nur in die Konfiguration verschiebt, sondern zusätzliche Schutzprüfungen einführt:

• Der Parameter pbxapijwtsecret muss in /etc/issabel.conf vorhanden sein – fehlt er, wird die Initialisierung der PBX API mit einem Fehler (RuntimeException) abgebrochen.
• Der Wert des Parameters muss eine Base64-Zeichenkette sein, die sich in mindestens 32 zufällige Bytes dekodieren lässt. Ist diese Bedingung nicht erfüllt, startet die API ebenfalls nicht.

Dies ist ein wichtiger betrieblicher Aspekt: Ein einfaches Code-Update genügt nicht. Wenn nach Anwendung des Patches in der Konfigurationsdatei kein korrekt generiertes Geheimnis vorhanden ist, stellt die PBX API ihren Dienst ein. Administratoren müssen nicht nur den Code aktualisieren, sondern auch einen kryptographisch starken Schlüssel generieren und in der Konfiguration eintragen.

Informationen zur Ausnutzung

Laut dem ursprünglichen Bericht hat die Shadowserver Foundation seit dem 9. September 2026 Versuche zur Ausnutzung von CVE-2026-89026 registriert. Diese Information wird jedoch über VulnCheck übermittelt und wurde im Zuge der Verifizierung anhand verfügbarer Primärquellen nicht unabhängig bestätigt. Die Schwachstelle ist zum Zeitpunkt der Analyse nicht im CISA-Katalog Known Exploited Vulnerabilities aufgeführt. Angaben zu konkreten Angreifern, Opfern oder zum Umfang der Kampagne liegen nicht vor.

Auswirkungsbewertung

Issabel wird als Plattform für PBX-Systeme in Unternehmen und bei Betreibern eingesetzt. Die Kompromittierung eines solchen Systems kann zu Folgendem führen:

• Ausführung beliebiger Befehle auf dem Telefonieserver mit den Rechten des Benutzers Asterisk.
• Abfangen und Manipulation des Sprachverkehrs.
• Nutzung des kompromittierten Servers als Sprungbrett für eine weitere Bewegung im Netzwerk.
• Störung der Telefonkommunikation der Organisation.

PBX-Systeme werden häufig in Netzsegmenten mit schwächerer Kontrolle platziert und können aus dem Internet erreichbar sein, was die Angriffsfläche vergrößert.

Empfehlungen

1. Spielen Sie den Patch ein aus dem offiziellen Commit so schnell wie möglich.
2. Generieren Sie ein kryptographisch starkes Geheimnis – mindestens 32 zufällige Bytes, codiert in Base64 – und tragen Sie es als Wert von pbxapijwtsecret in der Datei /etc/issabel.conf ein.
3. Überprüfen Sie die Funktionsfähigkeit der PBX API nach dem Update: Stellen Sie sicher, dass die API mit dem neuen Schlüssel korrekt initialisiert wird.
4. Beschränken Sie den Netzwerkzugriff auf den Endpunkt /pbxapi/ – er sollte nicht ohne Notwendigkeit aus dem Internet erreichbar sein.
5. Führen Sie eine Log-Analyse durch auf verdächtige Zugriffe auf /pbxapi/manager/originate, insbesondere von untypischen IP-Adressen.

Angesichts der trivialen Ausnutzbarkeit – der hart codierte Schlüssel macht die Authentifizierung faktisch zur Formsache – sollte das Update nicht aufgeschoben werden. Selbst wenn keine bestätigte massenhafte Ausnutzung vorliegt, machen allein die öffentliche Verfügbarkeit des Schlüsselwerts und die Beschreibung des Angriffsvektors jede ungepatchte Installation des Issabel Framework zu einem potenziellen Ziel. Vorrangige Maßnahme: Code aktualisieren, ein eindeutiges Geheimnis generieren und sicherstellen, dass die PBX API aus nicht vertrauenswürdigen Netzen nicht erreichbar ist.