Die Muse-Sicherheitslücke im neuen KI-Assistenten von Meta zeigt ein Sicherheitsproblem, das weit über einen gewöhnlichen Fehler in einer Desktop-Anwendung hinausgeht, wie die Redaktion von Techify.de. Ein lokaler Prozess auf dem Mac konnte nach den Erkenntnissen des Sicherheitsforschers Patrick Wardle eine nicht dokumentierte Muse-Einstellung verändern, den Datenverkehr der Spracheingabe zu einem eigenen Server umleiten und dadurch potenziell Authentifizierungsdaten sowie die weitreichenden Berechtigungen des Assistenten missbrauchen.
Entscheidend ist dabei nicht nur der technische Fehler selbst, sondern die Kombination aus einem angreifbaren lokalen Client und einem KI-Agenten, dem Nutzer freiwillig Zugriff auf E-Mail, Dateien, Mikrofon, Kamera, Kalender und weitere Dienste geben.
Die Schwachstelle wurde am 21. September 2026 öffentlich beschrieben. Bereits am 22. September erklärte Meta, einen Hotfix für die Mac-App veröffentlicht zu haben. Das Unternehmen betont zugleich, dass kein Angreifer einen Mac allein über diese Lücke aus der Ferne übernehmen konnte: Für den Angriff musste bereits Code unter dem Benutzerkonto auf dem Gerät laufen. Genau diese Einschränkung ist für die Risikobewertung entscheidend – sie macht den Fehler nicht zu einer klassischen Remote-Code-Execution-Lücke, zeigt aber, wie ein zunächst begrenzter lokaler Zugriff durch einen hochprivilegierten AI-Assistenten erheblich wertvoller werden kann.
Was bei der Muse-Sicherheitslücke tatsächlich passiert ist
Der Ausgangspunkt des Problems liegt im macOS-Client von Muse. Wardles öffentliches Proof-of-Concept mit dem Namen „not-a-mused“ beschreibt eine nicht dokumentierte Konfiguration namens endo_voyager_dictation_endpoint.
Sie bestimmt, wohin Muse die Daten seiner Diktierfunktion sendet. Nach Angaben des Forschers konnte ein Prozess, der lediglich mit den normalen Rechten des angemeldeten Mac-Nutzers ausgeführt wurde, diesen Wert ändern – zusätzliche Administratorrechte waren dafür nicht erforderlich.
Normalerweise verarbeitet Muse die entsprechenden Anfragen über die dafür vorgesehenen Systeme. Wird der Endpoint manipuliert, kann der Datenverkehr stattdessen zunächst an einen vom Angreifer kontrollierten Server gelangen.
Dieser Server kann als Zwischenstation fungieren, Spracheingaben erfassen und manipulierte Instruktionen weiterreichen.
Der Angriff setzt damit an einer besonders sensiblen Grenze an: nicht an der KI-Antwort selbst, sondern an dem Weg, auf dem ein vertrauenswürdiger Nutzerbefehl zum Agenten gelangt.
Wardles Proof-of-Concept nennt mehrere mögliche Folgen:
- Abfangen diktierter Audioeingaben und Prompts;
- Einschleusen zusätzlicher Anweisungen in einen Nutzerprompt;
- Zugriff auf Muse-Authentifizierungsmaterial;
- Missbrauch der Dienste und Ressourcen, die der Nutzer bereits mit Muse verbunden hat;
- Ausführung von Aktionen über den KI-Agenten, für die das ursprüngliche lokale Programm selbst möglicherweise keine entsprechenden Berechtigungen besitzt.
Damit unterscheidet sich das Angriffsszenario grundlegend von einem Fehler, bei dem beispielsweise nur eine einzelne Einstellung einer App verändert werden kann.
„Muse’s access can potentially become the attacker’s access.“
So fasst Wardle die zentrale Gefahr in der Dokumentation seines Proof-of-Concept zusammen.
Warum der Fehler gefährlicher sein kann als ein gewöhnlicher App-Bug
Bei einem klassischen Desktopprogramm ist der mögliche Schaden häufig durch dessen Funktionsumfang begrenzt. Ein Bildbetrachter öffnet Bilder, ein Taschenrechner führt Berechnungen aus und ein Musikplayer besitzt normalerweise keinen legitimen Grund, gleichzeitig das E-Mail-Konto, die Kamera, persönliche Dokumente und Online-Shops zu kontrollieren.
Ein persönlicher KI-Agent funktioniert anders. Muse wurde ausdrücklich dafür entwickelt, im Auftrag eines Nutzers Aktionen auszuführen. Meta beschreibt Funktionen wie das Versenden von E-Mails, Reisebuchungen, das Ausfüllen von Formularen, Einkäufe und die Arbeit mit verbundenen Diensten.
Der Agent arbeitet dabei über eine eigene virtuelle Umgebung und kann verschiedene sogenannte Connectoren verwenden.
Das verändert die Sicherheitsrechnung.
| Gewöhnliche Anwendung | Persönlicher KI-Agent wie Muse |
|---|---|
| meist begrenzte Aufgabe | führt unterschiedliche Aufgaben selbstständig aus |
| Zugriff auf wenige Ressourcen | kann zahlreiche Dienste verbinden |
| kompromittierte App betrifft primär deren Daten | kompromittierter Agent kann mehrere Datenquellen verbinden |
| Benutzer löst viele Aktionen selbst aus | Agent kann Aktionen im Auftrag des Nutzers durchführen |
| Berechtigungen sind häufig eng begrenzt | Funktionsumfang verlangt teilweise breite Rechte |
| Schadsoftware muss Funktionen oft selbst implementieren | Angreifer kann vorhandene Agenten-Funktionen missbrauchen |
Das bedeutet nicht, dass eine Schwachstelle automatisch Zugriff auf jedes Konto jedes Muse-Nutzers ermöglicht. Welche Daten tatsächlich erreichbar sind, hängt davon ab, welche Dienste und Berechtigungen der jeweilige Nutzer zuvor freigegeben hat.
Der Sicherheitsunterschied liegt vielmehr im möglichen Multiplikatoreffekt: Ein erfolgreich übernommener Agent kann bereits existierende Vertrauensbeziehungen nutzen.
E-Mail, Kamera, Mikrofon und Dateien: Welche Rechte Muse nutzen kann
Meta beschreibt Muse als persönlichen Agenten, der nicht lediglich Texte generiert, sondern reale Aufgaben erledigt. Die Plattform kann mit E-Mail-Diensten und anderen Anwendungen verbunden werden und arbeitet in einer dedizierten Muse Secure VM.
Innerhalb dieser Umgebung werden nach Angaben des Unternehmens Dateien, Credentials und weitere für den Agenten benötigte Informationen verarbeitet.
Auf einem Mac kommen zusätzlich lokale Berechtigungen ins Spiel. Anwendungen können – nach entsprechender Freigabe durch den Nutzer – beispielsweise auf Mikrofon, Kamera, Dateien, Kalender oder andere geschützte Systemressourcen zugreifen.
Für einen Angreifer entsteht dadurch ein attraktives Ziel: Statt sämtliche Funktionen für Datendiebstahl selbst in Schadsoftware zu implementieren, kann versucht werden, einen bereits autorisierten Agenten zu kontrollieren.
Patrick Wardle formulierte diesen Punkt gegenüber Ars Technica besonders deutlich:
„We can manipulate the agent and leverage its privileges to do whatever we want.“
Wardle erklärte außerdem, dass seine Demonstrationen unter anderem das Schreiben schädlicher Dateien und das Aufnehmen von Bildern zeigten.
Hier liegt der entscheidende Unterschied zwischen Malware auf dem Mac und Malware plus kompromittiertem Agenten. Ein gewöhnlicher Prozess kann durch macOS-Schutzmechanismen bei Kamera-, Mikrofon- oder Dateizugriffen eingeschränkt sein. Hat ein Nutzer diese Rechte einem Assistenten bereits erteilt, wird der Assistent selbst zu einem besonders interessanten Angriffsziel.
Warum Apples Berechtigungsmodell das Problem nicht vollständig verhindert
macOS schützt sensible Ressourcen unter anderem durch explizite App-Berechtigungen. Das Prinzip ist einfach: Eine Anwendung erhält beispielsweise nicht automatisch Zugriff auf Kamera oder Mikrofon, nur weil sie auf dem System installiert ist.
Solche Mechanismen bleiben sinnvoll. Sie verhindern jedoch nicht automatisch den Missbrauch einer Anwendung, der der Nutzer die entsprechenden Rechte bereits gegeben hat.
Ein verwandtes Beispiel liefert die bereits dokumentierte macOS-Sicherheitslücke CVE-2026-65400. Dort ging es um Screen Sharing und unzureichende Authentifizierung. Wer nachvollziehen möchte, welche macOS-Freigaben und Fernzugriffsoptionen besonders sensibel sind, findet hier eine praktische Einordnung: macOS Screen Sharing nach CVE-2026-65400 prüfen
Bei Muse liegt das Problem anders, das Grundprinzip bleibt aber ähnlich: Eine legitime Funktion mit hohen Rechten kann sicherheitskritisch werden, wenn ihre Kontrollgrenzen umgangen werden.
So funktionierte der Angriff über die Diktierfunktion
Technisch betrachtet benötigt das öffentlich dokumentierte Szenario mehrere Schritte. Es reicht nicht aus, lediglich die E-Mail-Adresse eines Muse-Nutzers zu kennen oder ihm eine präparierte Website zu zeigen. Zunächst muss ein Angreifer Code im Kontext des angemeldeten Mac-Nutzers ausführen können.
Anschließend kann die manipulierte Einstellung den Diktierverkehr umleiten.
Ein vereinfachter Ablauf sieht folgendermaßen aus:
- Schadcode läuft bereits unter dem Benutzerkonto auf dem Mac.
- Dieser Prozess verändert den nicht dokumentierten Muse-Dictation-Endpoint.
- Der Nutzer aktiviert später die Mikrofon- beziehungsweise Diktierfunktion von Muse.
- Die Eingabe wird an den manipulierten Endpoint geleitet.
- Ein Angreifer kann die Anfrage erfassen oder verändern.
- Manipulierte Instruktionen können anschließend an Muse weitergegeben werden.
- Je nach Angriff können Authentifizierungsinformationen und vorhandene Muse-Berechtigungen missbraucht werden.
Der gefährliche Teil beginnt damit nicht beim ersten Malware-Kontakt, sondern bei der Erweiterung dessen, was bereits vorhandene Malware anschließend erreichen könnte.
Wardle verweist außerdem auf ClickFix-ähnliche Angriffsmethoden. Dabei wird ein Nutzer durch Social Engineering dazu gebracht, einen Befehl selbst auszuführen.
ClickFix-Angriffe haben sich in den vergangenen Jahren insbesondere deshalb verbreitet, weil sie klassische Browser-Sicherheitsgrenzen umgehen: Statt eine Softwarelücke auszunutzen, überzeugt der Angreifer den Nutzer davon, einen vermeintlichen Reparatur- oder Verifizierungsbefehl einzufügen.
Warum „lokaler Angriff“ nicht automatisch „harmlos“ bedeutet
Meta hat zu Recht darauf hingewiesen, dass die Lücke keine Remote-Übernahme eines sauberen Macs ermöglicht. David Singleton von Meta Superintelligence Labs erklärte nach der Veröffentlichung, für einen Missbrauch müsse bereits schädlicher Code unter dem Benutzerkonto auf dem Rechner laufen. Das Unternehmen veröffentlichte anschließend einen Hotfix.
Diese Einschränkung reduziert die Angriffsfläche erheblich.
Trotzdem ist die Aussage „Wenn Malware bereits läuft, ist ohnehin alles verloren“ bei agentischer Software zu grob. Betriebssysteme verwenden genau deshalb unterschiedliche Berechtigungen, Sandboxes und Zugriffskontrollen, damit ein kompromittierter Prozess nicht automatisch Zugriff auf sämtliche Ressourcen des Benutzers erhält.
Muse konnte diese Trennung im untersuchten Szenario abschwächen: Ein Prozess mit geringeren eigenen Rechten konnte versuchen, den wesentlich stärker autorisierten Agenten als Werkzeug zu verwenden.
Meta hatte Muse ausdrücklich mit umfangreichen Sicherheitsmechanismen entwickelt
Die Schwachstelle ist auch deshalb bemerkenswert, weil Meta vor dem Start umfangreiche Sicherheitsmaßnahmen für Muse beschrieben hatte. Der Assistent läuft laut Unternehmen in einer dedizierten Linux-VM.
Connectoren für verbundene Dienste sollen getrennt ausgeführt werden, und Credential-Zugriffe werden durch verschiedene Kontrollschichten begrenzt.
Zu diesen Komponenten gehören laut Meta:
- Privsep für die Trennung von Code mit Credential-Zugriff;
- Authd zur Kontrolle darüber, welches Credential-Material ein authentifizierter Prozess erhalten darf;
- Sentinel zur Bewertung, ob eine konkrete Aktion ausgeführt werden darf;
- isolierte Worker für unterschiedliche Connectoren;
- Filter für Einmalcodes und Passwort-Reset-Links in E-Mails;
- Erkennung potenzieller Prompt-Injection-Angriffe;
- zusätzliche Bestätigung bei sensiblen Zahlungsvorgängen.
Meta beschreibt die Architektur selbst folgendermaßen:
„Each person stays in control of their Muse and decides how much access it gets.“
Diese Aussage stammt aus der offiziellen Produktvorstellung vom 8. September 2026.
Der aktuelle Fall zeigt jedoch, dass eine sichere Cloud-Architektur nicht jede Schwachstelle eines lokalen Clients kompensieren kann. Wird eine vertrauenswürdige Verbindung schon vor Erreichen der geschützten Umgebung manipuliert, entsteht eine zusätzliche Angriffsebene.
Warum AI-Agenten ein neues Ziel für Schadsoftware werden
Bei klassischen Angriffen versucht Malware häufig, Browser-Cookies, Passwörter, Krypto-Wallets, Dokumente oder Session-Tokens direkt zu stehlen. Agentische KI schafft eine weitere Möglichkeit: Statt einzelne Informationen zu extrahieren, kann ein Angreifer versuchen, den Assistenten selbst zu übernehmen.
Das ist attraktiv, weil Agenten nicht nur Informationen besitzen, sondern Aktionen ausführen können.
Ein leistungsfähiger persönlicher Agent kann beispielsweise:
- E-Mails lesen oder schreiben;
- Kalenderdaten verarbeiten;
- Dateien erstellen und bearbeiten;
- Websites öffnen;
- Formulare ausfüllen;
- Online-Einkäufe vorbereiten;
- Kommunikationsdienste verwenden;
- weitere Werkzeuge oder Connectoren aufrufen.
Dadurch verschiebt sich ein Teil der Sicherheitsfrage von „Welche Daten kann dieses Programm lesen?“ zu „Welche Entscheidungen und Aktionen darf dieses Programm für mich ausführen?“.
Ein ähnliches Berechtigungsproblem lässt sich bei anderen KI-Produkten beobachten. Die Funktion ChatGPT Computer History auf dem Mac kann beispielsweise ausgewählte Aktivitäten aus Apps und Websites als Kontext erfassen und setzt dafür entsprechende Freigaben voraus.
Wie sich solche Zugriffe kontrollieren und deaktivieren lassen, ist hier beschrieben: ChatGPT Computer History auf dem Mac kontrollieren
Der Vergleich bedeutet nicht, dass dort dieselbe Muse-Schwachstelle existiert. Er zeigt vielmehr, warum lokale Berechtigungen bei KI-Software inzwischen zu einer eigenständigen Sicherheitskategorie werden.
Der Hotfix ist veröffentlicht – was Mac-Nutzer jetzt prüfen sollten
Nach der öffentlichen Offenlegung erklärte Meta am 22. September, einen Hotfix für den Muse-Mac-Client verteilt zu haben. Damit unterscheidet sich die aktuelle Situation von einem ungepatchten Zero-Day, für den Nutzer keine Herstellerkorrektur besitzen.
Wer Muse auf dem Mac verwendet, sollte deshalb zunächst sicherstellen, dass die aktuelle Version installiert ist.
Danach sind fünf Kontrollen sinnvoll:
| Prüfung | Warum sie relevant ist |
|---|---|
| Muse aktualisieren | der von Meta veröffentlichte Hotfix sollte installiert sein |
| macOS-Berechtigungen prüfen | nicht benötigte Kamera-, Mikrofon- oder Dateirechte reduzieren |
| verbundene Dienste kontrollieren | unnötige E-Mail-, Kalender- oder App-Verbindungen entfernen |
| unbekannte Programme prüfen | der veröffentlichte Angriff benötigt lokalen Code |
| Terminalbefehle nicht blind ausführen | ClickFix-Angriffe setzen häufig auf Social Engineering |
Zusätzlich sollte kontrolliert werden, welche Anwendungen überhaupt Zugriff auf sensible macOS-Funktionen besitzen. Je weniger Programme dauerhaft weitreichende Rechte erhalten, desto kleiner ist die mögliche Missbrauchsfläche.
Bei Sicherheitsproblemen auf dem Mac lohnt sich außerdem ein Blick auf installierte Betriebssystemupdates. Dass selbst systemnahe Funktionen unerwartete Angriffsmöglichkeiten besitzen können, zeigte zuletzt die Screen-Sharing-Lücke.
Die konkrete Prüfung der Freigaben wird in der bereits genannten Anleitung zu CVE-2026-65400 unter macOS beschrieben. Mac-Fernzugriff und Screen Sharing absichern
Was Unternehmen aus dem Muse-Fall ableiten können
Für Firmen ist die Frage größer als die Sicherheit einer einzelnen Consumer-App. KI-Agenten werden zunehmend mit E-Mail, Cloud-Speichern, Kalendern und Geschäftsanwendungen verbunden. Sobald ein Agent auf mehrere Systeme zugreifen kann, wird seine Identität selbst zu einem privilegierten Sicherheitsobjekt.
Unternehmen sollten daher nicht nur überprüfen, welches KI-Modell verwendet wird, sondern auch:
- welche lokalen Clients installiert werden;
- welche OAuth-Berechtigungen vergeben sind;
- welche Connectoren aktiv sind;
- wo Tokens gespeichert werden;
- welche Aktionen ohne erneute Nutzerbestätigung möglich sind;
- ob ein lokaler Prozess Agenten-Einstellungen verändern kann;
- ob ungewöhnliche Agenten-Aktivitäten protokolliert werden;
- wie Token nach einem Sicherheitsvorfall widerrufen werden können;
- ob Least-Privilege-Regeln auch für AI-Agenten gelten.
Besonders wichtig ist die Trennung zwischen Leserechten und Aktionsrechten. Ein Assistent, der Termine lediglich anzeigen soll, benötigt nicht automatisch die Möglichkeit, Termine zu löschen. Ein Agent, der E-Mails zusammenfasst, sollte nur dann Nachrichten senden dürfen, wenn diese Funktion tatsächlich benötigt wird.
Dieses Prinzip entspricht klassischem Least Privilege – bekommt bei agentischer KI aber zusätzliche Bedeutung, weil derselbe Agent viele Systeme miteinander verbinden kann.
Auch Browser bleiben eine relevante Angriffsfläche. Google musste im September 2026 beispielsweise erneut mehrere kritische Sicherheitslücken in Chrome 153 schließen.
Wer den Browser als Teil automatisierter Workflows verwendet, sollte daher nicht nur den Agenten, sondern auch dessen Softwareumgebung aktuell halten. Die konkreten betroffenen Versionen sind hier zusammengefasst: Chrome 153 und die geschlossenen kritischen Sicherheitslücken
Muse zeigt das eigentliche Sicherheitsproblem autonomer Assistenten
Der technische Fehler im Muse-Mac-Client lässt sich mit einem Hotfix beheben. Die dahinterliegende Architekturfrage bleibt jedoch bestehen: Persönliche KI-Agenten werden nützlicher, je mehr Datenquellen und Aktionen ihnen zur Verfügung stehen – und genau dadurch werden sie für Angreifer wertvoller.
Ein Chatbot, der ausschließlich eine Textfrage beantwortet, hat normalerweise eine deutlich kleinere Angriffsfläche als ein Agent, der gleichzeitig E-Mails durchsucht, einen Kalender verwaltet, Dokumente erstellt und mit lokalen Hardwarefunktionen interagiert.
Bei zukünftigen Agenten wird deshalb nicht nur die Sicherheit des KI-Modells entscheidend sein.
Mindestens ebenso relevant sind:
- die Sicherheit des lokalen Clients;
- die Speicherung und Lebensdauer von Authentifizierungstokens;
- die Grenzen zwischen einzelnen Connectoren;
- Schutz vor Prompt Injection;
- kontrollierte Freigaben für Kamera, Mikrofon und Dateien;
- Bestätigungen für besonders sensible Aktionen;
- Protokollierung ungewöhnlicher Agentenaktivitäten;
- schnelle Möglichkeiten zum Widerruf kompromittierter Sessions.
Die Muse-Sicherheitslücke macht damit ein strukturelles Risiko sichtbar: Je mehr digitale Handlungsmacht ein Assistent erhält, desto größer ist der mögliche Schaden, wenn ein Angreifer nicht den Nutzer selbst, sondern dessen Assistenten kontrolliert.
Für Smartphone-Nutzer gilt derselbe Grundsatz. Android schloss im September mehrere kritische Schwachstellen, darunter Fehler, bei denen unter bestimmten Voraussetzungen keine zusätzliche Nutzeraktion erforderlich war. Welche Patchlevel aktuell relevant sind, zeigt die Übersicht zum Android-Sicherheitsupdate September 2026.
Fragen und Antworten zur Muse-Sicherheitslücke
Kann ein Angreifer einen Mac über die Muse-Sicherheitslücke direkt aus dem Internet hacken?
Nach den bisher veröffentlichten technischen Informationen nein. Der demonstrierte Angriff setzt voraus, dass bereits Code unter dem Benutzerkonto auf dem Mac ausgeführt werden kann. Meta bezeichnete den Vorfall deshalb als lokalen Angriff und nicht als Remote-Exploit.
Warum ist die Lücke dann trotzdem relevant?
Weil vorhandene Malware normalerweise nicht automatisch dieselben Berechtigungen besitzt wie ein vom Nutzer autorisierter KI-Agent. Die Muse-Schwachstelle konnte diese Grenze unterlaufen: Ein lokaler Prozess konnte versuchen, den Agenten und dessen vorhandene Zugriffsrechte für zusätzliche Aktionen zu verwenden.
Welche Muse-Version war betroffen?
Die öffentlich beschriebene Schwachstelle betrifft den Muse-Client für macOS. Wardles Proof-of-Concept konzentriert sich auf die lokale Mac-Anwendung und deren veränderbaren Dictation-Endpoint.
Hat Meta die Sicherheitslücke bereits geschlossen?
Meta erklärte am 22. September 2026, einen Hotfix für die Muse-Mac-App veröffentlicht zu haben. Nutzer sollten deshalb sicherstellen, dass sie die aktuelle Version verwenden.
Muss Muse deinstalliert werden?
Aus den veröffentlichten Informationen folgt keine allgemeine technische Notwendigkeit, eine vollständig aktualisierte Installation zu entfernen. Entscheidend sind der aktuelle Patchstand und die tatsächlich vergebenen Berechtigungen. Wer Muse nicht benötigt oder dem Agenten keine weitreichenden Zugriffe geben möchte, kann zusätzlich nicht benötigte Connectoren und lokale Berechtigungen deaktivieren.
Welche wichtigste Schutzmaßnahme bleibt nach dem Hotfix?
Neben dem Update sollte überprüft werden, welche Rechte Muse und andere KI-Anwendungen besitzen. Kamera, Mikrofon, Dateien, Kalender, E-Mail und verbundene Online-Dienste sollten nur freigegeben werden, wenn sie tatsächlich benötigt werden. Besonders vorsichtig sollten Nutzer bei Terminalbefehlen sein, die eine Website, ein Popup oder eine angebliche Support-Anleitung zum Kopieren und Ausführen vorgibt.
Die Muse-Sicherheitslücke ist damit weniger ein Beleg dafür, dass jeder Muse-Nutzer unmittelbar kompromittiert wurde, sondern ein konkretes Beispiel für ein neues Problem moderner KI-Agenten mit Systemzugriff: Ein kleiner Fehler an der falschen Stelle kann einen Assistenten mit zahlreichen legitimen Berechtigungen zum Verstärker eines bereits bestehenden Angriffs machen. Mit dem veröffentlichten Hotfix ist die konkret dokumentierte Schwachstelle adressiert; für Entwickler und Nutzer bleibt jedoch die Aufgabe, Berechtigungen persönlicher AI-Agenten künftig genauso streng zu behandeln wie Administrator- oder Cloud-Zugänge.
Sie können dies und weitere nützliche Informationen auf unserer Website nachlesen. Wir empfehlen Ihnen außerdem die Lektüre folgender Artikel: Auracast statt Bluetooth-Pairing: Diese Handys und Kopfhörer empfangen öffentliche Audio-Streams
