Die US-Cybersicherheitsbehörde CISA hat am 9. November 2026 die FreeSWITCH-Lücke CVE-2026-116779 in ihren Katalog aktiv ausgenutzter Schwachstellen (Known Exploited Vulnerabilities, KEV) aufgenommen. Über den Fehler lässt sich die Open-Source-Telefonieplattform mit einer einzigen SIP-Textnachricht dazu bringen, API-Befehle auszuführen – bis hin zu Befehlen auf Betriebssystemebene mit den Rechten des FreeSWITCH-Prozesses. Neu ist die Lücke nicht: Das Update auf Version 1.11.3 erschien am 28. August 2026, das Sicherheits-Advisory der Entwickler am 28. Oktober, der CVE-Eintrag am 5. November.

FreeSWITCH ist ein quelloffener Software-Telefonie-Stack, der Vermittlungstechnik auf gewöhnlicher Hardware nachbildet; gepflegt wird das Projekt von SignalWire. Betroffen sind laut Advisory alle Versionen bis einschließlich 1.11.2. Die Entwickler bewerten die Lücke nach CVSS 3.1 mit 9,8 von 10 Punkten („kritisch“). Denselben Wert enthält der CVE-Eintrag, den GitHub als zuständige Vergabestelle (CNA) aus dem Advisory erzeugt hat; eine eigene CVSS-Bewertung der CISA gibt es nicht.

Wie aus einer Chatnachricht ein Befehl wird

Der Fehler sitzt im SIP-Modul mod_sofia, genauer in der Funktion sofia_presence_handle_sip_i_message(). Sie nimmt eingehende SIP-MESSAGE-Anfragen entgegen, also Textnachrichten, wie sie Telefone und Softphones über SIP austauschen. Den Benutzerteil der Empfängeradresse (To) trennt sie am Pluszeichen und behandelt den linken Teil als Namen eines Chat-Protokolls, an das FreeSWITCH die Nachricht weiterreicht. Eines dieser Protokolle heißt „api“: Das Modul mod_dptools registriert es, und es übergibt seine Adresse direkt an die interne Funktion switch_api_execute(). Wer eine Nachricht an api+<Befehl> zustellen kann, bestimmt damit, welchen FreeSWITCH-API-Befehl der Server ausführt. Laut Advisory schränkte nichts diese Auswahl ein, und Protokolle, die nur Nachrichten zustellen, wurden nicht von solchen unterschieden, die Befehle ausführen.

Als Folgen nennen die Entwickler beliebige Betriebssystembefehle, das Auslesen von Konfiguration und Zugangsdaten sowie die volle Kontrolle über Gespräche. Ist zusätzlich mod_lua geladen – wie in der Standardkonfiguration –, lässt sich auf demselben Weg Lua-Code mit voller Standardbibliothek ausführen. Laut Advisory wurde die Ausnutzung dieses Wegs bereits in freier Wildbahn beobachtet. Von wem, seit wann und in welchem Umfang, steht dort nicht.

Schon die Standardkonfiguration ist angreifbar

Die Chat-Verarbeitung ist aktiv, solange ein SIP-Profil nicht ausdrücklich enable-chat=false setzt, und die mitgelieferte Beispielkonfiguration conf/vanilla lässt sie im internen wie im externen Profil eingeschaltet. Die Zugriffsliste für eingehende Anfragen (inbound ACL) gilt nicht für MESSAGE – sie enger zu fassen, nimmt ein Profil also nicht aus der Schusslinie.

Für einen Angriff genügt es, eine einzige MESSAGE durchzubringen. Seit Version 1.10.7 verlangt FreeSWITCH für MESSAGE standardmäßig eine Anmeldung, doch dafür reicht laut Advisory irgendein Konto auf dem Profil: eine Nebenstelle, ein Tischtelefon oder ein Trunk-Partner, der sich nur registrieren darf. Wer noch die Beispieldatei conf/vanilla/directory/default/default.xml verwendet, braucht nicht einmal das. Sie definiert einen Benutzer „default“ ohne Passwort und ohne a1-hash; der Kommentar in der Datei weist selbst darauf hin, dass er sich ohne Passwort registrieren kann. Solche Benutzer authentifizieren sich erfolgreich, solange allow-empty-password für sie nicht auf false steht. Die Beispielkonfiguration enthält laut Advisory zwei davon: „default“ und ein Skinny-Beispiel.

Symbolbild: Geöffneter Serverschrank mit Rack-Servern und vielen farbigen Netzwerk- und Stromkabeln

Bild: Symbolbild – Server im Rechenzentrum der Wikimedia Foundation (2012). Foto: Victorgrigas, Lizenz CC BY-SA 3.0, via Wikimedia Commons

Fix im August, Details im Oktober

Behoben ist die Lücke in FreeSWITCH 1.11.3 vom 28. August 2026. Die Release Notes sprachen damals von kritischen Sicherheitskorrekturen und rieten dringend zum Update. Die Lücke selbst beschrieben sie nicht, sie nannten lediglich einen neuen Parameter enable-chat-api-proto für mod_sofia und mod_verto. Er ist ab Werk aus und steht in den Beispielprofilen nur auskommentiert. Wählt eine eingehende MESSAGE das api-Protokoll auf einem Profil ohne diese Freigabe, antwortet FreeSWITCH mit „403 Forbidden“ und protokolliert Absender und angefragten Befehl. Die Einzelheiten zur Lücke folgten erst mit dem Advisory vom 28. Oktober.

Mit der KEV-Aufnahme müssen US-Bundesbehörden die Lücke bis zum 12. November 2026 schließen. Die CISA hat den Eintrag zudem mit „Forensic Triage“ markiert: Nach den Umsetzungsvorgaben ihrer Richtlinie BOD 26-04 müssen Behörden dann auch prüfen, ob ihre Systeme bereits kompromittiert wurden. Ob die Lücke bei Ransomware-Angriffen eine Rolle spielt, führt der Katalog als unbekannt. Außerdem weist die CISA darauf hin, dass es sich um eine Open-Source-Komponente handelt, die in verschiedenen Produkten stecken kann. Wer eine Telefonanlage oder Contact-Center-Software auf FreeSWITCH-Basis betreibt, sollte beim Anbieter klären, welche Version enthalten ist.

Was du jetzt tun solltest

Version prüfen. Die laufende Version zeigt der API-Befehl version, den du über die FreeSWITCH-Konsole absetzt:

fs_cli -x "version"

Alles bis einschließlich 1.11.2 ist verwundbar.

Aktualisieren. Ziel ist 1.11.3. Wer noch 1.11.1 oder älter einsetzt, schließt damit zugleich eine Reihe weiterer Lücken, die bereits in 1.11.2 behoben wurden und zu denen das Projekt Ende Oktober und Anfang November Advisories veröffentlicht hat – darunter zwei mit CVSS 9,1.

Übergangsweise den SIP-Chat abschalten. Bis das Update eingespielt ist, empfiehlt das Advisory, in jedem SIP-Profil, das keinen eingehenden SIP-Chat braucht, die Chat-Verarbeitung abzuschalten. Die Nachricht wird dann verworfen, bevor FreeSWITCH die Protokollauswahl auswertet:

<param name="enable-chat" value="false"/>

Danach liest du die Konfiguration neu ein und startest die betroffenen Profile neu, in der Beispielkonfiguration also internal und external. Ein Neustart des Profils kann laufende Gespräche darüber trennen:

fs_cli -x "reloadxml"
fs_cli -x "sofia profile internal restart"
fs_cli -x "sofia profile external restart"

Nicht auf Teilmaßnahmen verlassen. Die MESSAGE-Authentifizierung (auth-messages) reicht laut Advisory allein nicht. Zusammen mit dem Entfernen aller Verzeichnisbenutzer ohne Passwort oder a1-hash macht sie aus der Lücke immerhin eine, für die Angreifer ein gültiges Konto brauchen. Die globale Variable disable_system_api_commands=true (gesetzt in der vars.xml, ausgewertet beim Laden von mod_commands) entfernt den API-Befehl system, lässt aber alle übrigen erreichbar, etwa zum Laden von Modulen oder zum Auslösen von Anrufen. Sinnvoll, aber kein Ersatz für das Update.

Nach Spuren suchen. Nach dem Update schreibt FreeSWITCH jeden abgewiesenen Versuch als Warnung ins Log. Das Log-Verzeichnis verrät global_getvar, die Standard-Logdatei heißt freeswitch.log:

fs_cli -x "global_getvar log_dir"
grep "addressed to the 'api' chat proto" /PFAD/ZUM/LOGVERZEICHNIS/freeswitch.log

Für die Zeit davor helfen nur Mitschnitte: SIP-Traces, Paketmitschnitte oder Aufzeichnungen eines Session Border Controllers lassen sich nach MESSAGE-Anfragen durchsuchen, deren Empfänger mit „api+“ beginnt. Weil Angreifer laut Advisory Konfiguration und Zugangsdaten auslesen und Anrufe steuern konnten, solltest du bei einem Verdacht auch die Verbindungsdaten (CDR) auf ungewöhnliche Anrufe und den Server auf fremde Prozesse und Dateien prüfen sowie alle Zugangsdaten erneuern – SIP-Konten, Trunk-Zugänge und das Event-Socket-Passwort.

Quellen

Bildnachweis