Kurzfassung
Meta Ads MCP ist von einer kritischen Schwachstelle betroffen. Vor Version 1.0.109 akzeptiert der Dienst bestimmte HTTP-Anfragen ohne Authentifizierung und leitet sie an die MCP-Tool-Handler weiter. Im Fehlerfall kann der Server außerdem ein Access Token in der Antwort preisgeben. Wer den Dienst aus dem Netz erreichbar betreibt, sollte die Stelle ernst nehmen.
Was ist passiert?
Die Schwachstelle steckt in der Authentifizierungslogik von Meta Ads MCP. Statt unauthentifizierte Streamable-HTTP-Anfragen mit einem 401 abzuweisen, reicht die Middleware sie an die Tool-Schicht durch. Damit kann ein beliebiger erreichbarer Client MCP-Funktionen anstoßen, ohne sich vorher anzumelden.
Das Problem endet dort nicht. Fehlt pro Anfrage ein gültiger Zugang, greift der Dienst auf die Umgebungsvariable META_ACCESS_TOKEN zurück. Schlägt dann ein Aufruf an die Meta Graph API fehl, landet der vollständige Request inklusive des Tokens als Query-Parameter in der JSON-RPC-Antwort. Das ist ein Klartext-Leak über einen ohnehin ungeschützten Kanal.
Technische Details
Betroffen ist CVE-2026-48039. Der NVD-Eintrag bewertet die Lücke als kritisch. Als Ursache nennt er zwei Punkte: erstens die unzureichende Prüfung in AuthInjectionMiddleware.dispatch() in http_auth_integration.py, zweitens die fehlerhafte Fehlerbehandlung in api.py, die den Roh-Request samt access_token serialisiert.
Praktisch heißt das: Ein Angreifer braucht keinen gültigen Login. Er muss nur den Dienst erreichen können. Danach kann er MCP-Tools auslösen. Je nach eingesetzter Konfiguration kann er dabei auch an das Token kommen, das der Betreiber für Meta-API-Zugriffe hinterlegt hat. Ob weitere Pfade betroffen sind, geht aus der Quelle nicht hervor.
Wer ist betroffen?
Betroffen sind Installationen von Meta Ads MCP vor Version 1.0.109. Die Schwachstelle trifft vor allem Betreiber, die den Dienst im internen Netz oder direkt auf einem erreichbaren Host laufen lassen. Für Unternehmen im DACH-Raum ist das relevant, wenn ein Team solche MCP-Server produktiv oder in Testumgebungen einsetzt und den Netzwerkzugang nicht sauber begrenzt hat.
Für Privatnutzer spielt das Thema nur eine Rolle, wenn sie den Dienst selbst betreiben. Ein normales Endgerät ist hier nicht das Ziel. Kritisch wird es dort, wo ein Zugriffstoken für Werbe- oder API-Zwecke hinterlegt ist und der Server von außen erreichbar bleibt.
Empfohlene Maßnahmen
Die erste Maßnahme ist klar: auf Version 1.0.109 oder neuer aktualisieren. Alles andere ist Flickwerk. Wer den Dienst nicht sofort patchen kann, sollte ihn bis dahin vom Netz nehmen oder strikt auf vertrauenswürdige Netze beschränken.
Danach gehört die Umgebung geprüft. Betreiber sollten vorhandene META_ACCESS_TOKEN-Werte als potenziell kompromittiert behandeln, wenn der Dienst erreichbar war. Token rotieren, API-Zugriffe kontrollieren, Logs auf ungewöhnliche MCP-Aufrufe durchsuchen. Wer den Server per Reverse Proxy oder Firewall erreichbar gemacht hat, sollte die Freigabe sofort überdenken.
Für Admins im Alltag heißt das auch: keine offenen MCP-Endpoints ins Internet stellen, Authentifizierung nicht nur an einer Stelle prüfen und Fehlerausgaben nie mit sensiblen Parametern zurückgeben. Das klingt banal. Genau daran scheitern aber viele Integrationen.
Einschätzung von CyberSecurity-News.de
Die Schwachstelle ist technisch unsauber und in der Praxis unangenehm. Ein unauthentifizierter Tool-Zugriff wäre schon genug. Dass im Fehlerfall auch noch ein Token im Response landet, macht die Lage deutlich schlechter. Für Betreiber mit exponiertem Dienst ist das kein theoretisches Problem.
Die Informationslage ist allerdings knapp. Aus dem NVD-Eintrag geht nicht hervor, ob bereits aktive Ausnutzung beobachtet wurde oder welche Produktvarianten jenseits der genannten Versionen in der Praxis im Umlauf sind. Trotzdem ist die Reaktion eindeutig: patchen, Zugriff einschränken, Token prüfen. Wer den Dienst produktiv nutzt, sollte das heute noch anfassen.
Fazit
CVE-2026-48039 zeigt ein klassisches, aber gefährliches Muster: Authentifizierung fehlt an der falschen Stelle, und Fehlerbehandlung verrät im schlimmsten Fall Geheimnisse. Für Betreiber von Meta Ads MCP vor 1.0.109 ist die Priorität hoch. Die saubere Antwort lautet Update auf 1.0.109, Zugang beschränken und mögliche Token-Leaks einkalkulieren.
Quellenangabe
Weiterführende Quelle: NVD – CVE-2026-48039
