Die US-amerikanische Cybersecurity and Infrastructure Security Agency (CISA) hat am 9. November vier Schwachstellen in ihren Katalog bekannter ausgenutzter Schwachstellen (Known Exploited Vulnerabilities, KEV) aufgenommen und sich dabei auf Belege für aktive Ausnutzung gestützt. Die Schwachstellen betreffen GPUStack, SignalWire FreeSwitch, OpenBSD OpenSSH und IBM Aspera Faspex. Organisationen, die verwundbare Installationen betreiben, riskieren dadurch unberechtigten Zugriff, Befehlsausführung oder erweiterte Rechte.
Die Warnmeldung der CISA legt für betroffene Organisationen diese Prioritäten bei der Behebung fest. Öffentliche technische Berichte beschreiben Angriffe auf OpenSSH unter Linux und auf GPUStack. Der Sicherheitshinweis des Herausgebers zu FreeSWITCH bestätigt zudem eine Ausnutzung in der Praxis.
Die vier neuen Einträge im Katalog sind:
- CVE-2026-102895, GPUStack: unzureichende Authentifizierung, die administrativen Zugriff ohne Zugangsdaten erlaubt. Der Herausgeber stuft Versionen vor 2.2.0 als betroffen ein und empfiehlt 2.2.0 oder neuer.
- CVE-2026-116779, SignalWire FreeSwitch: Codeinjektion, die Konfiguration und Zugangsdaten offenlegen, Angreifern die Kontrolle über Anrufe geben und Befehle ausführen kann.
- CVE-2026-123158, OpenBSD OpenSSH: eine Schwachstelle durch einen unerwarteten Statuscode oder Rückgabewert, bekannt als SSHole, die unter Linux die Authentifizierung umgehen kann.
- CVE-2026-123218, IBM Aspera Faspex: fehlerhafte Autorisierung, die einem authentifizierten Benutzer erlaubt, eine speziell gestaltete Nachricht zu senden und seine Rechte zu erweitern.
The Hacker News berichtete CVSS-Schweregrade von 9,8 für die Schwachstellen in GPUStack, FreeSwitch und Faspex sowie 8,1 für SSHole. Die Korrekturen datiert das Portal auf Juli, Oktober, November und November 2026, in dieser Reihenfolge.
OpenSSH-Angriffe umfassen Versuche, den Zugang aufrechtzuerhalten
The Hacker News berichtete, Previdian habe 22 Ausnutzungsversuche für SSHole aus 14 eindeutigen IP-Adressen erfasst, wobei die Versuche bis zum 6. November zurückreichen. Defused Cyber erklärte in einem Beitrag vom 7. November, man habe beobachtet, dass eine kleine Zahl von Akteuren die Schwachstelle ins Visier nehme, und die Aktivität sei noch nicht weit verbreitet.
GreyNoise ordnete den ersten Versuch gegen sein Honeypot-Netzwerk – Systeme, die dazu dienen, Angriffe zu beobachten – dem 7. November um 00:46 UTC zu. Das Unternehmen meldete bestätigte Aktivität nach erfolgter Ausnutzung von sechs Quell-IP-Adressen, die 18 voneinander getrennte Angriffsketten ausmachten.
Zu diesen Ketten gehörten Aufklärung, Abfragen von Cloud-Metadatendiensten, Versuche, Passwort-Hashes und Root-SSH-Schlüssel auszulesen, sowie Versuche, die Datei authorized_keys von SSH zu verändern, um den Zugang zu behalten. In mindestens einem Fall setzten Angreifer TAC Agent ein, ein Python-Programm zur Befehlssteuerung (Command-and-Control), das Shell-Befehle ausführen, Systeminformationen sammeln, Verzeichnisse auflisten, Dateien übertragen und sich selbst aktualisieren kann.
Der Bericht verwies außerdem auf Beobachtungen von watchTowr, wonach SSHole für Botnetz- und Kryptomining-Aktivitäten ausgenutzt wurde.
GPUStack kann entfernten Datenverkehr als lokalen Administrator einstufen
Der Sicherheitshinweis zu GPUStack beschreibt einen Vertrauensfehler in get_current_user in gpustack/api/auth.py. Vor Version 2.2.0 erhielten Anfragen, die von Loopback stammten – der eigenen lokalen Netzwerkadresse des Hosts –, automatisch die eingebaute Administratoridentität, wenn force_auth_localhost auf False stand, dem Standardwert.
Zwei Wege konnten dieses Verhalten auslösen. In einer typischen selbst gehosteten Installation mit einem Reverse-Proxy auf derselben Maschine, der an 127.0.0.1 weiterleitet, erreichten entfernte Anfragen GPUStack mit einer lokalen Socket-Adresse. Dafür waren weder Zugangsdaten noch ein gefälschter Header nötig. Laut Hinweis wurde dieser Pfad Ende-zu-Ende gegen HEAD 6bee5883 verifiziert. Alternativ könnte ein Angreifer X-GPUStack-Real-IP: 127.0.0.1 senden, damit eine Anfrage lokal erscheint.
Dieser Zugriff ermöglichte es Angreifern, Benutzer, Modelle, Worker und Konfiguration einzusehen und zu ändern, Worker-Zugangsdaten und Geheimnisse von Cloud-Anbietern auszulesen sowie dauerhafte administrative API-Schlüssel mit dem Scope ["*"] anzulegen, die danach von jeder Quell-IP-Adresse genutzt werden können. Administrative Funktionen, darunter POST /v2/inference-backends/from-yaml, konnten dann Code auf Worker-Hosts ausführen.
Die Maintainer melden Angriffe auf eine Installation mit 2.1.1, bei der von Angreifern angelegte benutzerdefinierte Backends Reverse Shells ausführten und so Fernzugriff auf Befehle verschafften. Sie danken für unabhängige Meldungen von Nikko Enggaliano, Wei Yunzhou sowie Rui Yang und Haoyu Wang von der Johns Hopkins University. Aktive Ausnutzung meldete Javier Sixto von Ulex Innovative Systems. The Hacker News datiert den Hinweis auf den 31. Juli.
Chat-Nachrichten in FreeSWITCH können Befehlsschnittstellen erreichen
Der Sicherheitshinweis zu FreeSWITCH erklärt, dass sofia_presence_handle_sip_i_message() den Zielbenutzer einer eingehenden SIP-MESSAGE am Zeichen + teilt und den linken Teil als Auswahl des Chat-Protokolls behandelt. SIP ist ein Signalisierungsprotokoll, das Telefonie-Systeme verwenden.
Das Modul mod_dptools registriert eine Chat-Schnittstelle api, die ihre Adresse an switch_api_execute() übergibt. Eine Gegenstelle, deren MESSAGE angenommen wird, kann daher einen FreeSWITCH-API-Befehl auswählen. Befehle laufen mit den Rechten des FreeSWITCH-Prozesses und ermöglichen die Ausführung von Betriebssystembefehlen, die Offenlegung von Zugangsdaten und Konfiguration sowie vollständige Anrufsteuerung. Ist mod_lua geladen, wie in der Standardkonfiguration, kann eingebetteter Lua-Code außerdem auf die gesamte Standardbibliothek zugreifen.
Eingehender Chat ist aktiviert, sofern ein Profil nicht enable-chat=false setzt. Die Standardprofile internal und external lassen ihn aktiviert. Eine Verschärfung der eingehenden Zugriffskontrollliste beseitigt die Exposition nicht, weil diese Liste keinen MESSAGE-Verkehr abdeckt.
Wo die MESSAGE-Authentifizierung erzwungen wird, genügt ein gewöhnliches Konto mit Registrierungsberechtigung. Einige Standardkonfigurationen erlauben den Zugriff auch ohne ein Konto, das der Angreifer besitzt: conf/vanilla/directory/default/default.xml definiert einen Benutzer default ohne password oder a1-hash, der sich authentifizieren kann, sofern allow-empty-password für diesen Benutzer nicht auf false gesetzt ist.
Der Fix führt eine profilbezogene Einstellung enable-chat-api-proto ein, die deaktiviert ist, sofern sie nicht ausdrücklich aktiviert wird. Blockierte Versuche, api auszuwählen, erhalten eine 403-Antwort und erzeugen ein Protokoll mit Quelle und angefordertem Befehl. Die Prüfung unterscheidet nicht zwischen Groß- und Kleinschreibung. Nachrichten ohne Selektor oder mit anderen Chat-Protokollen behalten ihr Routing. Die Einstellung ist in den Vanilla-Profilen und im mod_sofia-Beispiel auskommentiert. Der Hinweis führt Örn Arnarson und Gunnlaugur als Melder auf.
Was Administratoren tun sollten
GPUStack-Administratoren sollten auf 2.2.0 oder neuer aktualisieren. Diese Version entfernt den automatischen administrativen Zugriff über Loopback und härtet die Behandlung von Client-Adressen ab. Die Workarounds der Maintainer lauten: force_auth_localhost=true setzen, verhindern, dass Proxys externe Anfragen als Loopback darstellen, vom Client gesendete X-GPUStack-Real-IP-Header am Rand entfernen und den API-Zugriff über ein VPN oder eine Authentifizierung am Edge beschränken.
FreeSWITCH-Administratoren sollten den Fix des Herausgebers einspielen oder enable-chat=false in jedem Profil setzen, das keinen eingehenden SIP-Chat benötigt. Dieser Workaround deaktiviert auf diesen Profilen die Zustellung aller eingehenden MESSAGE-Chats.
Authentifizierung allein schließt den FreeSWITCH-Befehlspfad nicht. Die MESSAGE-Authentifizierung ist seit 1.10.7 standardmäßig aktiviert. Zusammen mit dem Entfernen aller Verzeichnisbenutzer ohne beide Passwortfelder – einschließlich des Standardbenutzers default und der Skinny-Beispielbenutzer – reduziert sie das Risiko nur noch auf die authentifizierte Befehlsausführung. Ebenso entfernt disable_system_api_commands=true die system-API, lässt aber andere APIs erreichbar, darunter das Laden von Modulen und das Auslösen von Anrufen.
Für zivile Bundesbehörden der US-Exekutive (U.S. Federal Civilian Executive Branch) verlangt die Binding Operational Directive 26-04 der CISA eine rasche Priorisierung von KEV-Schwachstellen auf öffentlich erreichbaren Systemen, wenn eine Ausnutzung die vollständige Kontrolle ermöglicht. Sie legt außerdem Erwartungen fest, um zu prüfen, ob eine Kompromittierung dem Patchen vorausging. The Hacker News nennt für diese Ergänzungen eine Frist zur Behebung am 12. November. Diese Frist betrifft die zivilen Bundesbehörden. Die CISA empfiehlt anderen Organisationen, die Behebung von KEV-Einträgen über ein risikobasiertes Schwachstellenmanagement zu priorisieren.
