Bösartiger MCP‑Server entdeckt

Expertenbeitrag von KOI: KI‑Assistenten nutzen MCP‑Server, um E‑Mails zu verschicken, Datenbankabfragen zu erledigen und wiederkehrende Aufgaben zu automatisieren. Dabei erhalten diese Tools weitreichende Rechte — oftmals von Fremdentwicklern, deren Identität und Vertrauenswürdigkeit kaum überprüfbar sind. Dieses blinde Vertrauen kann gefährlich werden.

Die Risiko‑Engine bei KOI hat nun einen konkreten Fall identifiziert: das Paket postmark‑mcp, das nach Angaben der Analyse rund 1.500 Mal pro Woche heruntergeladen und in hunderten Entwickler‑Workflows eingesetzt wird. Ab Version 1.0.16 kopiert das Paket offenbar stillschweigend jede empfangene E‑Mail an einen persönlichen Server des Entwicklers — darunter Passwort‑Zurücksetzungen, Rechnungen, interne Memos und vertrauliche Dokumente.

Laut KOI handelt es sich dabei um den ersten dokumentierten Nachweis eines bösartigen MCP‑Servers im praktischen Einsatz. Die Entdeckung verdeutlicht, wie sich die Angriffsfläche von Endpunkt‑Supply‑Chain‑Attacken zunehmend zur zentralen Schwachstelle für Unternehmen entwickelt.

Die Details der Entdeckung: postmark‑mcp war lange Zeit unauffällig und zuverlässig — über fünfzehn Versionen hinweg funktionierte das Tool erwartungsgemäß. Der Entwickler trat mit seinem echten Namen auf, verfügte über ein glaubhaftes GitHub‑Profil und schien ein etablierter Software‑Ingenieur aus Paris zu sein. Genau deshalb war das Paket in zahlreiche Arbeitsabläufe eingebunden und genoss breites Vertrauen.

Mit der Veröffentlichung von Version 1.0.16 trat jedoch eine Verhaltensänderung auf. Bei einer Untersuchung stieß die KOI‑Risiko‑Engine auf einen verdächtigen Eintrag — versteckt in der Codebasis, an Zeile 231. Dieses Fundstück offenbarte das heimliche Exfiltrationsverhalten.

Vertrauen allein reicht nicht. Tools mit weitreichenden Berechtigungen können zur Einfallspforte werden, wenn Supply‑Chain‑Komponenten kompromittiert sind — selbst wenn sie von scheinbar seriösen Quellen stammen.

Eine einzige Zeile. Und schon hat jede E-Mail einen unerwünschten Passagier.

Die Sache ist die: Es gibt ein völlig legitimes GitHub-Repo mit dem gleichen Namen, das offiziell von Postmark (ActiveCampaign) gepflegt wird. Der Angreifer hat den legitimen Code aus ihrem Repo genommen, seine bösartige BCC-Zeile hinzugefügt und ihn unter dem gleichen Namen auf npm veröffentlicht. Klassische Identitätsfälschung.

Ich verstehe das. So ist das Leben. Vielleicht hatte der Entwickler finanzielle Probleme. Vielleicht hat ihm jemand ein Angebot gemacht, das er nicht ablehnen konnte. Vielleicht ist er auch einfach eines Tages aufgewacht und hat sich gedacht: „Mal sehen, ob ich damit durchkomme.“ Wir werden nie wirklich wissen, was in jemandem vorgeht – was einen legitimen Entwickler dazu bringt, plötzlich 1.500 Nutzer zu hintergehen, die ihm vertraut haben.

Aber genau das ist der Punkt. Wir KÖNNEN es nicht wissen. Wir können es nicht vorhersagen. Und wenn es passiert? Die meisten von uns werden es nicht einmal bemerken, bis es viel zu spät ist. Für moderne Unternehmen ist das Problem noch gravierender. Während sich Sicherheitsteams auf traditionelle Bedrohungen und Compliance-Rahmenbedingungen konzentrieren, setzen Entwickler unabhängig voneinander KI-Tools ein, die völlig außerhalb der etablierten Sicherheitsperimeter operieren. Diese MCP-Server laufen mit denselben Berechtigungen wie die KI-Assistenten selbst – vollständiger E-Mail-Zugriff, Datenbankverbindungen, API-Berechtigungen –, tauchen jedoch in keinem Bestandsverzeichnis auf, umgehen Risikobewertungen von Anbietern und umgehen jede Sicherheitskontrolle, von DLP bis hin zu E-Mail-Gateways. Wenn jemand bemerkt, dass sein KI-Assistent seit Monaten heimlich E-Mails an einen externen Server weiterleitet, ist der Schaden bereits katastrophal.

Sprechen wir über die Auswirkungen

KOI schreibt weiter: Sie installieren einen MCP‑Server, weil Ihre KI E‑Mails verarbeiten soll — sinnvoll, zeitsparend, produktivitätssteigernd. Was in der Praxis aber geschieht: Sie übergeben die vollständige Kontrolle über Ihren gesamten E‑Mail‑Verkehr an eine fremde Person, die Sie nie getroffen haben.

KOI schätzt die Folgen konservativ:

• 1.500 Downloads pro Woche.

• Rund 20 % davon werden aktiv genutzt — das entspricht etwa 300 Organisationen.

• Jede Organisation sendet vermutlich 10 bis 50 E‑Mails pro Tag.

• Das bedeutet 3.000 bis 15.000 E‑Mails pro Tag, die direkt an giftshop.club geleitet werden.

Und das Besorgniserregende daran: Der Entwickler hat nichts kompromittiert — keine Hacks, keine Zero‑Day‑Exploits, keine komplexen Angriffsvektoren. Stattdessen haben wir ihm wissentlich die Schlüssel übergeben, indem wir diesen Code mit vollen Rechten ausgeführt haben — und unsere KI‑Assistenten nutzten ihn hunderte Male täglich. Das ist ein Versagen, das wir uns selbst ankreiden müssen.

Der Autor, ein seit Jahren im Bereich Sicherheit tätiger Fachmann, sagt, dieses Problem raube ihm den Schlaf. Laut ihm haben viele in der Branche stillschweigend hingenommen, dass es normal geworden sei, Werkzeuge von fremden Entwicklern zu installieren, die weitreichende Befugnisse erhalten.

Diese Tools können im Namen der Organisation E‑Mails versenden — mit voller Autorität — auf Datenbanken zugreifen, Befehle auf Systemen ausführen und API‑Aufrufe mit den hinterlegten Anmeldedaten tätigen. Sobald ein solcher MCP‑Server installiert ist, beginnt der KI‑Assistent zu agieren: ohne jeglichen Überprüfungsprozess, ohne Nachfrage — etwa „Soll ich diese E‑Mail wirklich mit BCC an giftshop.club senden?“ — stattdessen blinde, automatisierte Ausführung, Hunderte von Malen pro Tag.

Nach Ansicht des Autors existiert hierfür de facto kein Sicherheitsmodell: keine Sandbox, keine Eindämmung, keine Mechanismen zur Beschränkung. Wenn das Tool anweist „Sende diese E‑Mail“, wird die Anweisung ausgeführt. Wenn es verlangt „Kopiere alles an diese Adresse“, passiert auch das — ohne Rückfrage.

Die Hintertür in postmark‑mcp sei geradezu peinlich simpel, so der Experte. Genau deshalb aber offenbare sie in drastischer Weise, wie marode die gesamte Konfiguration sei: Ein einzelner Entwickler, eine einzige Codezeile — und tausende bis zehntausende gestohlene E‑Mails.

Timeline

Phase 1 — Ein legitimes Tool erstellen: Die Versionen 1.0.0 bis 1.0.15 funktionieren einwandfrei und gewinnen das Vertrauen der Nutzer. Entwickler integrieren das Paket in Produktions‑Workflows; es wird getestet, empfohlen und wird zum festen Bestandteil des Alltags.

Phase 2 — Eine Zeile hinzufügen: Mit Version 1.0.16 erscheint eine einzige, gezielte Änderung — eine zusätzliche BCC‑Anweisung. Abgesehen davon bleibt der Code unverändert, die Oberfläche weiterhin vertrauenswürdig.

Phase 3 — Profit: Danach lehnt sich der Angreifer zurück und beobachtet, wie E‑Mails mit Passwörtern, API‑Schlüsseln, Finanzdaten und Kundeninformationen an giftshop.club übertragen werden.

Dieses Muster alarmiert die Experten: Ein Paket kann monatelang als zuverlässig gelten, in der Produktion geprüft werden und unabdingbar für Teams werden — bis es schlagartig zur Malware wird. Sobald die Hintertür aktiviert ist, ist das kompromittierte Paket nicht mehr nur ein Softwarebaustein, sondern Teil einer vertrauenswürdigen Infrastruktur, die Daten in großem Umfang ausleitet.

Und giftshop.club? Offenbar ein Nebenprojekt des Entwicklers — inzwischen aber eine Sammelstelle für hochsensible „Geschenke“: die gestohlenen E‑Mails.

Als KOI den Entwickler um eine Erklärung bat, blieb jede Rückmeldung aus — keine Stellungnahme, keine Ablehnung, kein Hinweis auf ein Versehen. Stattdessen löschte der Entwickler das Paket umgehend aus dem npm‑Repository — offenbar in dem Versuch, Spuren zu verwischen.

Doch das Entfernen eines Pakets aus npm beseitigt nicht die Installationen, die bereits in Produktivumgebungen laufen. Die wöchentlichen Downloads sind weiterhin kompromittiert; die betroffenen Instanzen senden nach wie vor BCC‑Kopien an giftshop.club. KOI betont, dass der Entwickler sich dessen bewusst zu sein scheint und offenbar darauf setzt, dass viele Opfer die fortdauernde Infektion nicht bemerken, obwohl das Paket nicht mehr öffentlich verfügbar ist.

Warum das gesamte MCP-Modell grundlegend fehlerhaft ist

KOI betont: MCP‑Server sind nicht vergleichbar mit normalen npm‑Paketen. Sie sind speziell für den autonomen Einsatz durch KI‑Assistenten konzipiert — und genau darin liegt das Problem.

Mit der Installation von postmark‑mcp wird nicht einfach eine weitere Abhängigkeit zur package.json hinzugefügt. Vielmehr übergibt man dem KI‑Assistenten ein Werkzeug, das hunderte Male automatisch ausgeführt wird, ohne jemals innezuhalten oder zu hinterfragen: „Stimmt hier etwas nicht?“

Die KI erkennt weder BCC‑Felder noch, dass E‑Mails gestohlen werden. Für sie ist es lediglich ein funktionierendes Tool: E-Mail senden — erfolgreich. Wiederholen — erfolgreich. Währenddessen werden alle Nachrichten stillschweigend abgefangen, Tag für Tag, Woche für Woche.

Die Backdoor in postmark‑mcp betrifft nicht nur einen böswilligen Entwickler oder die 1.500 wöchentlich kompromittierten Installationen. Sie ist ein Warnsignal für das gesamte MCP‑Ökosystem. KOI warnt: Wir geben Tools, deren Entwickler wir nicht kennen, keine Möglichkeit haben zu überprüfen und denen wir keinen Grund zu vertrauen, volle Rechte („Gott-Modus“) auf unsere sensibelsten Systeme. MCP‑Server sind nicht nur npm‑Pakete — sie sind direkte Pipelines zu sensiblen Operationen, automatisiert durch KI-Assistenten, die sie tausendfach ohne Rückfrage ausführen.

Die Backdoor sammelt aktiv E-Mails, während die Nutzer arbeiten. KOI meldete den Vorfall an npm, doch die größere Frage bleibt: Wie viele andere MCP-Server sind bereits kompromittiert? Und wie könnte man das überhaupt wissen?

KOI erkennt solche Verhaltensänderungen durch seine Risiko-Engine. Das MCP-Ökosystem verfügt über kein integriertes Sicherheitsmodell. Vertrauen allein reicht nicht; es braucht Überprüfung. Die Hintertür von Version 1.0.16 wurde automatisch erkannt, etwas, das traditionelle Sicherheitstools nicht melden würden.

Darüber hinaus schützt das Supply-Chain-Gateway von KOI vor bösartigen Paketen: Es fungiert als Kontrollpunkt zwischen Entwicklern und dem unkontrollierten npm‑Ökosystem, blockiert bekannte Bedrohungen, markiert verdächtige Updates und verlangt Genehmigungen für Pakete, die kritische Operationen wie E-Mail- oder Datenbankzugriffe durchführen. Während andere darauf hoffen, dass Entwickler „gute Entscheidungen“ treffen, stellt KOI sicher, dass nur verifizierte und kontinuierlich überwachte Optionen genutzt werden.

Wer postmark‑mcp in Version 1.0.16 oder höher einsetzt, befindet sich in Gefahr. KOI empfiehlt: sofort entfernen und alle möglicherweise kompromittierten Zugangsdaten ändern. Noch wichtiger: Jeder MCP-Server sollte gründlich überprüft werden. Die entscheidende Frage lautet: Weiß man tatsächlich, wer diese Tools entwickelt hat, denen man volle Kontrolle über die Systeme überträgt?

Bei MCP‑Servern ist Misstrauen nicht nur ratsam — es ist zwingend notwendig.

Das könnte Ihnen gefallen

---

Bild/Quelle: https://depositphotos.com/de/home.html

Folgen Sie uns auf X

Folgen Sie uns auf Bluesky