Im KI-Browser Comet des Anbieters Perplexity ist eine schwere Sicherheitslücke bekannt geworden. Forschende des Browser-Sicherheitsunternehmens SquareX berichten, dass ein kaum dokumentiertes MCP API in Verbindung mit versteckten, privilegierten Erweiterungen unter bestimmten Bedingungen die Ausführung von Befehlen auf dem Endgeraet ermöglichen konnte – vorbei an üblichen Schutzmechanismen moderner Browser-Sandboxes. Perplexity hat nach Angaben der Forschenden inzwischen ein stilles Sicherheitsupdate ausgeliefert, weist die Darstellung der Risiken jedoch öffentlich als «fake» zurück.
Verstecktes MCP API und privilegierte KI-Erweiterungen in Comet
Kern der Schwachstelle ist das wenig dokumentierte API chrome.perplexity.mcp.addStdioServer, das im Browser Comet für das Model Context Protocol (MCP) genutzt wird. MCP dient generell dazu, KI-Anwendungen sicher mit externen Datenquellen oder lokalen Umgebungen zu verbinden, etwa um Dateien zu lesen, Tools aufzurufen oder Skripte auszuführen.
In Comet greifen zwei fest integrierte Erweiterungen auf dieses API zu: Agentic und Analytics. Beide werden mit dem Browser ausgeliefert, tauchen nicht in der üblichen Erweiterungsverwaltung auf, können von Nutzerinnen und Nutzern nicht deaktiviert werden und besitzen erweiterte Rechte im Umgang mit MCP. Agentic führt automatisierte Agentenaktionen aus, während Analytics Telemetriedaten und das Verhalten von Agentic überwacht.
Nach Analyse von SquareX sind diese Komponenten so konfiguriert, dass sie nur mit Subdomains von perplexity.ai kommunizieren dürfen. Formal ist der Zugriff auf das MCP API damit an die Infrastruktur von Perplexity gebunden. Das ändert jedoch nichts an der grundsätzlichen Tragweite: Wird diese Vertrauenskette kompromittiert, kann ein derart privilegiertes API zu einem Einfallstor für die Ausführung von Code auf Betriebssystemebene werden.
Angriffsszenario: Extension Stomping und WannaCry-Demonstration
SquareX demonstrierte ein praxisnahes Angriffsszenario auf Basis von Extension Stomping – einer Technik, bei der ein legitimes Browser-Addon durch eine manipulierte Variante ersetzt wird. Die Forschenden entwickelten ein bösartiges Erweiterungsmodul, das sich als das interne Analytics-Modul ausgibt, und nutzten dieses, um dem Agentic-Modul Anweisungen zu erteilen.
Weil Agentic dem vermeintlich legitimen Analytics vertraute, leitete es Befehle an das MCP API weiter. Auf diese Weise gelang es SquareX, über MCP-Kommandos auf einer Testmaschine einen WannaCry-Ransomware-Dummy zu starten. Dabei handelte es sich um einen Proof-of-Concept, doch er verdeutlicht, dass bei einer Kompromittierung der Perplexity-Infrastruktur oder der eingebauten Erweiterungen prinzipiell beliebige Schadsoftware eingeschleust, Nutzeraktivitäten ausspioniert und sensible Daten exfiltriert werden könnten.
Die Forschenden verweisen zudem auf weitere realistische Angriffsvektoren wie Cross-Site-Scripting (XSS) auf vertrauenswürdigen Subdomains, Man-in-the-Middle-Angriffe (MitM) oder eine kompromittierte Software-Lieferkette. In all diesen Fällen könnte ein Angreifer die privilegierten KI-Erweiterungen missbrauchen, ohne dass umfangreiche Interaktion durch die betroffene Person erforderlich ist. Gerade Sicherheitsberichte von ENISA und OWASP zeigen seit Jahren, dass solche Kettenangriffe auf privilegierte Komponenten zu den gefährlichsten Szenarien gehören.
Position von Perplexity: Kritik am Szenario und Verweis auf den menschlichen Faktor
Perplexity wies die Darstellung von SquareX gegenüber Medien als «fake» zurück. Das Unternehmen argumentiert, das beschriebene Angriffsszenario sei künstlich konstruiert und entspreche nicht einem realistischen Bedrohungsmodell. Im Kern reduziere sich das Risiko auf klassischen Social-Engineering- bzw. Phishing-Betrug, bei dem Nutzer dazu verleitet würden, manuell Schadsoftware zu installieren.
Nach Darstellung von Perplexity sei für den Austausch der internen Erweiterungen ein Insider mit Produktionszugriff nötig. Außerdem betont das Unternehmen, dass die Einrichtung lokaler MCP-Instanzen und die Ausführung gefährlicher Befehle eine explizite Nutzerbestätigung erfordern. Das von SquareX veröffentlichte Video zeige eine Attacke, die zahlreiche manuelle Schritte beinhalte.
SquareX berichtet hingegen, Perplexity bereits am 4. November 2025 über die Schwachstelle informiert zu haben, jedoch zunächst keine direkte Rückmeldung erhalten zu haben. Inzwischen sei Comet stillschweigend aktualisiert worden: Versuche, die beschriebene Schwachstelle auszunutzen, enden nun mit der Meldung «Local MCP is not enabled», wodurch der konkrete Angriffsweg blockiert ist. Kritik bleibt vor allem an der mangelnden Transparenz im Umgang mit der gemeldeten Schwachstelle und der aus Sicht vieler Fachleute ungewöhnlich scharfen öffentlichen Zurückweisung der Forschung.
Strukturelle Risiken von MCP und KI-Browsern
Privilegierte KI-Integrationen als neue Angriffsoberflaeche
Aus sicherheitstechnischer Sicht berührt der Fall Comet einen grundsätzlichen Architekturtrend: KI-Browser und Agentenplattformen integrieren immer häufiger Erweiterungen mit weitreichenden lokalen Rechten, um Aufgaben wie Dateizugriff, Automatisierung oder Systemsteuerung zu ermöglichen. Sobald solche Komponenten an ein mächtiges API wie MCP gekoppelt sind, wird jede Schwachstelle in dieser Kette potentiell zu einer Remote-Code-Execution-Schwachstelle.
Best Practices in der Cybersicherheit – etwa das Least-Privilege-Prinzip und das Zero-Trust-Modell – fordern, dass selbst interne Komponenten nur genau die Rechte erhalten, die sie zwingend benötigen. Versteckte, nicht deaktivierbare Erweiterungen mit breitem Zugriff auf lokale Ressourcen widersprechen diesem Grundsatz und amplifizieren die Folgen einer etwaigen Kompromittierung.
Security by Design fuer MCP und Agenten
Für MCP- und Agentenarchitekturen in KI-Browsern bedeutet das: Transparenz über alle eingebauten Komponenten, die Möglichkeit, sie zu deaktivieren, eine klare Rechte-Trennung sowie granulare Sicherheitsabfragen. Besonders kritische Aktionen – etwa Ausführen lokaler Programme, Dateiverschlüsselung oder Skriptaufrufe – sollten mindestens mit starken, nachvollziehbaren Nutzerinteraktionen und idealerweise zusätzlicher Authentifizierung (z. B. 2FA) abgesichert werden.
Empfehlungen fuer Nutzer und Entwickler von KI-Browsern
Nutzern von KI-Browsern wie Comet ist zu raten, ihre Software konsequent auf dem aktuellen Stand zu halten, nur unbedingt notwendige Erweiterungen zu installieren und Quellen von Downloads sowie Erweiterungen sorgfältig zu prüfen. Ergänzend erhöhen EDR- und moderne Antiviren-Loesungen, regelmäßige Backups sowie der Verzicht auf Administratorkonten im Alltag die Resilienz gegenüber Angriffen, bei denen Browser als Einfallstor dienen.
Entwickler von KI-Browsern und KI-Plattformen sollten MCP- und Agentenfunktionen strikt nach dem Prinzip Security by Design konzipieren. Dazu gehören systematisches Threat Modeling, Bug-Bounty-Programme, die umfassende, öffentliche Dokumentation privilegierter APIs sowie transparente Sicherheits-Changelogs. Nur so lässt sich Vertrauen aufbauen und das Risiko verringern, dass kritische Schwachstellen unentdeckt bleiben oder unterschätzt werden.
Die Debatte um das MCP API in Comet verdeutlicht, dass die Integration leistungsfähiger KI-Funktionen in Browser neue Klassen von Risiken schafft. Wer die Chancen dieser Technologien nutzen will, sollte die Sicherheitsimplikationen von Anfang an mitdenken: durch sorgfältige Architekturentscheidungen auf Herstellerseite und durch eine erhöhte Cybersicherheits-Hygiene bei den Anwendern. Es lohnt sich, Sicherheitsmeldungen der Hersteller aktiv zu verfolgen, Updates zeitnah einzuspielen und die eigene KI-Toolkette regelmäßig kritisch zu überprüfen.
