Die US-Cybersicherheitsbehörde CISA hat die FreeSWITCH-Lücke CVE-2026-116779 am 9. November in ihren Katalog aktiv ausgenutzter Schwachstellen (KEV) aufgenommen. Über eine einzige präparierte SIP-Nachricht können Angreifer auf verwundbaren Systemen beliebige FreeSWITCH-API-Befehle ausführen – bis hin zu Betriebssystembefehlen mit den Rechten des FreeSWITCH-Prozesses. Betroffen sind alle Versionen bis einschließlich 1.11.2, der Fix steckt in Version 1.11.3. Wer die quelloffene Telefonie-Software betreibt, sollte das Update jetzt einspielen oder zumindest den Chat-Empfang abschalten.
CVE-2026-116779: Was hinter der Lücke steckt
FreeSWITCH ist ein verbreiteter Open-Source-Softswitch, auf dem viele VoIP-Telefonanlagen, Callcenter-Plattformen und Konferenzdienste aufbauen. Gepflegt wird das Projekt von SignalWire. Laut dem Sicherheitshinweis GHSA-mg63-h38w-8p9p liegt der Fehler in der Funktion sofia_presence_handle_sip_i_message(), die eingehende SIP-MESSAGE-Anfragen verarbeitet – also Textnachrichten, die über das SIP-Protokoll verschickt werden.
Die Funktion teilt den Empfänger („To“-User) einer solchen Nachricht am Pluszeichen auf und interpretiert den linken Teil als Namen eines Chat-Protokolls. Die Nachricht wird dann an die passende registrierte Chat-Schnittstelle weitergereicht. Das Problem: Das Modul mod_dptools registriert eine Chat-Schnittstelle namens api, die ihre Adresse direkt an switch_api_execute() übergibt. Wer eine SIP-Nachricht zustellen kann, bestimmt damit, welchen FreeSWITCH-API-Befehl der Server ausführt. Eine Einschränkung gab es nicht; Protokolle zur Nachrichtenzustellung und solche zur Befehlsausführung wurden nicht unterschieden.
Die Folgen beschreibt das Advisory so: Ausführung beliebiger Betriebssystembefehle, Preisgabe von Konfiguration und Zugangsdaten sowie volle Kontrolle über Anrufe. Ist mod_lua geladen – was in der Standardkonfiguration der Fall ist –, steht zusätzlich Lua-Code mit voller Standardbibliothek als zweiter Angriffsweg offen. Und: „Exploitation of this path has been observed in the wild“ – die Ausnutzung wurde bereits beobachtet.
Bewertung und Einstufung
- CVSS 3.1: 9,8 (kritisch), Angriff über das Netzwerk, geringe Komplexität, keine Rechte und keine Nutzerinteraktion nötig.
- Schwachstellentypen: CWE-77 (Command Injection), CWE-78 (OS Command Injection) und CWE-749 (offengelegte gefährliche Funktion).
- Betroffen: FreeSWITCH bis einschließlich 1.11.2.
- Behoben: ab Version 1.11.3.
- Entdeckt von: Örn Arnarson und Gunnlaugur.
In der NVD ist der CVE-Eintrag seit dem 5. November veröffentlicht. Die CISA hat ihn in ihrer SSVC-Bewertung mit „Exploitation: active“, „automatable: yes“ und „technical impact: total“ eingestuft.
Warum die Standardkonfiguration betroffen ist
Besonders heikel: Für einen Angriff ist laut Advisory keine ungewöhnliche Einstellung nötig. Betroffen ist jedes SIP-Profil, das eingehende MESSAGE-Anfragen annimmt. Der Chat-Empfang ist standardmäßig aktiv, solange ein Profil nicht enable-chat=false setzt. Die mitgelieferte Beispielkonfiguration conf/vanilla lässt ihn sowohl im internen als auch im externen Profil eingeschaltet. Die eingehende ACL erfasst MESSAGE-Anfragen nicht – eine strengere ACL nimmt ein Profil also nicht aus der Schusslinie.
Voraussetzung ist lediglich, dass eine einzige SIP-Nachricht von einem Profil akzeptiert wird. Ist die Authentifizierung für Nachrichten aktiv, genügt irgendein Konto auf diesem Profil: eine Nebenstelle, ein Telefon oder ein Trunk-Partner, der sich nur registrieren darf. Noch einfacher wird es auf Installationen, die noch die Datei conf/vanilla/directory/default/default.xml enthalten. Dort ist ein Benutzer default ohne Passwort und ohne A1-Hash definiert – und ein solcher Benutzer authentifiziert sich erfolgreich, sofern allow-empty-password für ihn nicht auf false steht. Das dürfte erklären, warum das Advisory die Lücke mit „keine Rechte erforderlich“ bewertet.
Patch und Workarounds
Version 1.11.3 führt den neuen Profilparameter enable-chat-api-proto ein. Er legt fest, ob eine eingehende Nachricht das api-Chat-Protokoll auswählen darf, und ist standardmäßig deaktiviert. Damit ist der Weg auf allen Profilen geschlossen, solange niemand ihn ausdrücklich freischaltet. Versucht eine Nachricht trotzdem, das Protokoll anzusprechen, antwortet FreeSWITCH mit 403 und protokolliert Quelle und angeforderten Befehl. Laut den Release Notes zu 1.11.3 wurde die Option sowohl in mod_sofia als auch in mod_verto ergänzt; außerdem wird die Aufteilung des To-Users im Nachrichten-Handler nun begrenzt. Das Release ist auf GitHub auf den 28. August 2026 datiert, das Advisory auf den 28. Oktober – der Patch war also schon vor der Offenlegung verfügbar.
Wer nicht sofort aktualisieren kann, hat laut Advisory nur einen wirksamen Workaround:
enable-chat=falseauf jedem Profil setzen, das keinen eingehenden SIP-Chat braucht. Das stoppt die Nachricht, bevor der Protokoll-Selektor ausgewertet wird – deaktiviert aber auch jede eingehende Chat-Zustellung auf diesem Profil.auth-messagesallein reicht nicht. Die Nachrichten-Authentifizierung ist seit Version 1.10.7 standardmäßig aktiv. Zusammen mit dem Entfernen aller Verzeichnisbenutzer ohne Passwort oder A1-Hash –conf/vanillaliefert zwei davon mit,defaultund das Skinny-Beispiel – reduziert sie das Problem auf eine Befehlsausführung durch angemeldete Nutzer, schließt den Weg aber nicht.disable_system_api_commands=trueentfernt diesystem-API, nicht aber den Angriffsweg selbst. Alle anderen registrierten APIs, etwa zum Laden von Modulen oder zum Aufbau von Anrufen, bleiben erreichbar. Laut Advisory dennoch sinnvoll, aber keine Lösung.
Da die Lücke bereits ausgenutzt wird, empfiehlt es sich zudem – als allgemeine Vorsichtsmaßnahme, nicht als Vorgabe aus dem Advisory – zu prüfen, ob es Anzeichen einer Kompromittierung gibt: ungewöhnliche SIP-MESSAGE-Anfragen mit Pluszeichen im Empfänger, unerwartete Prozesse unter dem FreeSWITCH-Benutzer, geänderte Konfigurationsdateien und auffällige Anrufe – etwa teure Auslandsverbindungen. Zugangsdaten, die in der Konfiguration hinterlegt sind, etwa für SIP-Trunks, sollten nach einem Verdacht rotiert werden. Konkrete Kompromittierungsindikatoren haben SignalWire und CISA in den geprüften Quellen nicht veröffentlicht.
CISA-Frist und der Rest der KEV-Liste
Laut der CISA-Mitteilung vom 9. November kamen gleichzeitig vier Lücken in den Katalog: neben CVE-2026-116779 eine Authentifizierungslücke in GPUStack (CVE-2026-102895), eine Autorisierungslücke in IBM Aspera Faspex (CVE-2026-123218) und die OpenSSH-Lücke CVE-2026-123158, die wir als SSHole-Lücke in OpenSSH 10.6p2 beschrieben haben. US-Bundesbehörden müssen alle vier bis zum 12. November beheben – nach der Richtlinie BOD 26-04 einschließlich einer forensischen Prüfung, ob Systeme bereits vor dem Patch kompromittiert wurden. Ob die FreeSWITCH-Lücke für Ransomware genutzt wird, ist laut CISA unbekannt.
Einordnung
Telefonieserver gelten in vielen Unternehmen als Infrastruktur, die einmal eingerichtet und dann selten angefasst wird. Genau das macht sie zum attraktiven Ziel: Sie sind oft direkt aus dem Internet erreichbar, verwalten Zugangsdaten zu SIP-Trunks und können bei Missbrauch schnell hohe Kosten verursachen. Die FreeSWITCH-Lücke zeigt zudem ein bekanntes Muster: Eine Komfortfunktion aus der Standardkonfiguration wird zum Einfallstor, weil Eingaben ungeprüft an eine mächtige Schnittstelle weitergereicht werden.
Ähnlich gelagert war zuletzt die ausgenutzte Barracuda-ESG-Lücke CVE-2026-116606, bei der ebenfalls ein Gerät am Netzwerkrand ohne Anmeldung übernommen werden konnte. Und wie beim WordPress-Updater im CISA-KEV gilt: Sobald eine Lücke im KEV-Katalog steht, ist sie keine theoretische Gefahr mehr. Offen ist, wer FreeSWITCH-Systeme angreift und wie viele Installationen betroffen sind. Für Betreiber ändert das wenig: Update auf 1.11.3, Chat-Empfang abschalten, wo er nicht gebraucht wird, und passwortlose Beispielbenutzer entfernen.
