Postmark-Backdoor lädt E-Mails herunter

• Kürzlich wurde im Modul postmark-mcp bösartiges Verhalten entdeckt
• Ab Version 1.0.16 wurde Code hinzugefügt, der E-Mails auf einen externen Server des Entwicklers kopiert
• Eine strukturelle Schwachstelle wurde sichtbar, durch die sensible E-Mails aus Hunderten von Organisationen abfließen können
• Durch das fehlende Vertrauensmodell von MCP-Servern steigt das Risiko von Supply-Chain-Angriffen
• Alle MCP-Nutzer müssen sofort prüfen und das Paket entfernen

---

Was MCP-Server sind und Überblick über den Fall postmark-mcp

• MCP-Server sind Werkzeuge, mit denen KI-Assistenten wiederkehrende Aufgaben wie das Versenden von E-Mails oder das Ausführen von Datenbankabfragen automatisiert erledigen
• Diese Werkzeuge laufen mit sehr hohen Berechtigungen, und von Entwicklern geschriebener Code wird nahezu allein auf Vertrauensbasis installiert; ein echtes Prüfverfahren existiert praktisch nicht
• Das populäre Paket postmark-mcp übernahm den Quellcode aus dem offiziellen Postmark-GitHub-Repository, fügte eine bösartige BCC-Zeile hinzu und veröffentlichte es anschließend unter demselben Namen auf npm
• Ab Version 1.0.16 wurde dem ansonsten unauffälligen Code eine Zeile hinzugefügt, die alle E-Mails auf den privaten Server des Entwicklers (giftshop.club) kopiert
• Damit sind sämtliche E-Mail-Informationen betroffen, einschließlich Passwort-Resets, Rechnungen, interner Notizen und vertraulicher Dokumente

Erkennung des auffälligen Verhaltens und Angriffsaufbau

• Die Risk Engine von Koi erkannte in Version 1.0.16 Anomalien
• Die Identität des Entwicklers wirkte auf GitHub und anderswo unauffällig, und die ersten 15 Versionen funktionierten ohne Probleme und bauten so Vertrauen auf
• In 1.0.16 wurde mit nur einer einzigen Codezeile eine Funktion ergänzt, die wichtige Informationen nach außen abfließen lässt
• Der Angreifer kopierte nicht nur Code, sondern nutzte gleichzeitig die Methode der Entwickler-Imitation (Classic impersonation)
• Ein zuvor regulär und zuverlässig eingesetztes Tool wurde so irgendwann zu vertrauensbasierter Infrastruktur, die anschließend bösartiges Verhalten ausführt

Auswirkungen und Ablauf des E-Mail-Abflusses

• Bei ungefähr 1.500 Downloads pro Woche und unter der Annahme, dass etwa 20 % aktiv genutzt werden, sind Hunderte von Organisationen potenziell betroffen
• Es wird geschätzt, dass täglich 3.000 bis 15.000 E-Mails an giftshop.club gesendet werden
• Nutzer prüfen das Verhalten des Tools nicht einzeln nach und überlassen die Ausführung größtenteils automatisch dem KI-Assistenten
• Es gibt weder ein separates Sicherheitsmodell noch eine Sandbox oder einen Verifizierungsprozess
• Der Entwickler hat das Paket zwar von npm gelöscht, doch in bereits installierten Umgebungen hat das keine Wirkung, sodass weiterhin Daten abfließen

Analyse der Angriffsphasen

• Phase 1: Verteilung eines legitimen Tools

  • Von 1.0.0 bis 1.0.15 funktionierte es ohne Probleme und baute Vertrauen auf

• Phase 2: Einschleusen von Schadcode

  • In 1.0.16 wurde eine einzelne BCC-Zeile ergänzt, um E-Mails nach außen zu kopieren

• Phase 3: Datensammlung

  • Passwörter, API-Schlüssel sowie Finanz- und Kundendaten flossen an giftshop.club ab

• Der Entwickler war nicht erreichbar, und obwohl das Paket von npm entfernt wurde, hält der Schaden in bereits installierten Umgebungen an

Strukturelle Mängel im MCP-Ökosystem

• MCP-Server sind im Unterschied zu gewöhnlichen npm-Paketen Hochrisiko-Werkzeuge, die von KI-Assistenten automatisch Hunderte oder Tausende Male aufgerufen werden
• Weder KI noch bestehende Sicherheitslösungen erkennen zuverlässig, ob der Code bösartig ist; das System basiert allein auf Vertrauen
• Das gesamte MCP-Ökosystem ist strukturell riskant, weil es anonyme Entwickler mit vollständigen Rechten über kritische Assets ausstattet
• Zur Angriffserkennung sind Verhaltensänderungsanalysen und sicherheitstechnische Kontrollen wie ein Supply-Chain-Gateway erforderlich
• Koi arbeitet mit Risk Engine und Gateway daran, die Einschleusung ähnlicher bösartiger Pakete zu blockieren und zu verifizieren

Gegenmaßnahmen und IOC

• Bösartiges Paket: postmark-mcp (npm)
• Bösartige Version: 1.0.16 oder höher
• Abflussadresse für E-Mails: phan@giftshop[.]club
• Domain: giftshop[.]club

Erkennungsmethoden

• In E-Mail-Logs nach Spuren suchen, dass giftshop.club als BCC verwendet wurde
• In der MCP-Server-Konfiguration unerwartete Parameter zur E-Mail-Weiterleitung prüfen
• Installationen von postmark-mcp ab Version 1.0.16 genau untersuchen

Reaktion und Wiederherstellung

• postmark-mcp sofort entfernen
• Alle Zugangsdaten, die während des Kompromittierungszeitraums per E-Mail geteilt wurden, rotieren
• E-Mail-Logs auf abgeflossene sensible Informationen vollständig untersuchen
• Bei bestätigtem Vorfall unverzüglich die zuständigen Behörden informieren

Fazit und Empfehlungen

• Für alle MCP-Server müssen Verfahren zur Identitätsprüfung von Entwicklern, Codevalidierung und Sicherheitskontrolle zwingend eingeführt werden
• Aufgrund der Natur von MCP als automatisierter KI-Hilfsinfrastruktur sind mindestens ein grundlegendes Misstrauensmodell und kontinuierliches Monitoring erforderlich
• Nutzer von postmark-mcp ab Version 1.0.16 müssen das Paket sofort entfernen und Sicherheitsmaßnahmen einleiten
• Vertrauensbasierte Nutzung bedeutet letztlich, dem Risiko eines Supply-Chain-Angriffs ausgesetzt zu sein
• Paranoia (Misstrauen/Skepsis) als Grundprinzip zu akzeptieren, ist eine rationale Strategie für den Einsatz von MCP

[GN⁺]

Hacker-News-Kommentare

• Ich frage mich, worin sich das von der Backdoor in einer Thunderbird-Erweiterung und diesem Vorfall unterscheidet. Ich habe früher eine Thunderbird-Erweiterung gepflegt, und als ich das Interesse daran verlor, hat jemand erst ein paar echte Beiträge geleistet und dann plötzlich nachdrücklich gefordert, das Projekt dauerhaft zu übernehmen. Am Ende habe ich abgelehnt, weil ich es für absurd hielt, Zehntausende von Mailbox-Schlüsseln an einen Fremden zu übergeben. Schon dass die Leute mir überhaupt so sehr vertraut haben, war irgendwie absurd, aber ich bin wenigstens ein anständiger Mensch
  • Sehe ich genauso. Das liegt nicht an MCP, sondern ist bei jeder Software dasselbe Problem. Am Ende bleibt einem nichts anderes übrig, als Entwicklern und Anbietern zu vertrauen. Ich kann Microsoft nicht davon abhalten, meine Outlook-Mails zu kopieren, und Google nicht daran hindern, Gmail zu kopieren. Selbst wenn Open Source bedeutet, dass „viele Augen“ den Code prüfen, mag das bei populären Projekten gelten, aber selbst dann bleibt ein Restrisiko. Am Ende vertrauen die meisten Leuten den Entwicklern einfach. Das ist ein chronisches Problem, so alt wie Software selbst
  • In der Situation, die du beschreibst, muss ich immer wieder an eine Datenschutz-Aussage von Zuckerberg denken. Wir sollten uns fragen, warum wir unsere Daten und unsere Privatsphäre irgendeinem Menschen einfach so anvertrauen
  • Ich habe schon oft betrunkene Fremde in mein Auto gesetzt und nach Hause gefahren. Ich sage ihnen immer, dass es wirklich gefährlich ist, bei einem Fremden ins Auto zu steigen. Ehrlich gesagt hatten sie einfach Glück, zufällig an einen gutmütigen Menschen mit zu viel Zeit wie mich geraten zu sein. Ich gehe wohl oft spät in kleine Bars in der Nachbarschaft, deshalb passiert mir das öfter
• Ich kann der Annahme nicht zustimmen, dass ein einzelner NPM-Download bald einer eindeutigen Organisation entspricht. Diese Zahl ist massiv übertrieben. Ein Download auf npm bedeutet nur, dass jemand (npm i ausführt) oder etwas (eine automatisierte Umgebung) etwas installiert. In der Praxis läuft npm i in CI bei schlampiger Konfiguration pro Ausführung, wenn nicht sogar pro Schritt. Deshalb können selbst 1.500 Downloads in Wirklichkeit nur von zwei Firmen stammen. Bei der einen nutzt ein Entwickler es für ein PoC, bei der anderen ist die CI-Konfiguration miserabel. Selbst im offiziellen Repo gibt es nur 1 Watch, 0 Forks und 2 Stars https://github.com/ActiveCampaign/postmark-mcp. MCP und Supply-Chain-Probleme an sich sind ernst, aber in diesem Fall ist die tatsächliche Auswirkung fast null
  • Nach derselben Logik wären die Downloadzahlen beliebter Python-Pakete bald auf einem Niveau, bei dem praktisch die gesamte Menschheit auf der Erde — Kinder, Senioren und sogar Menschen, die nicht einmal wissen, was ein Computer ist — jeweils ein Exemplar heruntergeladen hätte. https://pypistats.org/top
• Der Artikel selbst ist gut, aber ich verstehe nicht, warum ich unbedingt eine KI-übersetzte und von ChatGPT zusammengefasste Version lesen soll. Man hätte einfach den ursprünglichen Prompt zeigen sollen. So wie jetzt wirkt es unnötig langsam und irgendwie respektlos gegenüber den Nutzern
  • Gut zu hören, dass du das auch so empfindest. Ich hasse diesen Stil mit KI-Eingriffen, aber manche meiner Freunde merken das gar nicht oder es ist ihnen egal
• Man sieht es in letzter Zeit ständig, aber ich habe das Gefühl, wir reden nicht genug darüber, dass wir solchen Tools gottgleiche Rechte geben. Es sind Tools von Leuten, deren Gesichter wir nicht einmal kennen, und wir vertrauen ihnen einfach. Für KI-Assistenten gilt dasselbe. Alle vertrauen ihnen einfach zu 100 %. Es gibt Artikel, die genau das anprangern, aber sie haben etwas von „Wusstest du, dass du dir in den Fuß schießt, wenn du dir die Pistole an den Fuß hältst und den Abzug drückst??“. Es ist so offensichtlich, dass diese Artikel wie Content wirken, der aus kaum etwas gemacht wurde. Ich frage mich, ob wirklich so viele Menschen das nicht begreifen oder ob das nur fürs Schreiben künstlich aufgeblasen wird
  • Vor kurzem gab es auch einen Bericht darüber, dass ein KI-Code-Assistent die Produktionsdatenbank einer Firma gelöscht hat https://fortune.com/2025/07/23/ai-coding-tool-replit-wiped-database-called-it-a-catastrophic-failure/. Das hat mehrere Ebenen: 1) Der Gründer hat einem KI-Tool vollständig vertraut und damit sich selbst ins Knie geschossen. Das war also wirklich Unwissenheit. 2) Außerdem war direkter Zugriff aus der Entwicklungsumgebung auf die Produktions-DB offen. In so einer Umgebung wäre es ohnehin früher oder später zu einem Unfall gekommen
  • Was für HN-Nutzer selbstverständlich ist, ist für den Großteil der Welt überhaupt nicht selbstverständlich. Solche Artikel sind genau für diese Leute nötig. Tatsächlich wurden bei der Entwicklung von MCP-Servern und KI-Agenten Sicherheitsthemen anfangs nicht einmal diskutiert, deshalb sind sie von Grund auf unsicher. Ob sich das in Zukunft ändert, weiß niemand, aber bis dahin ist ständige Aufklärung wohl das Beste
  • „Sind die Leute wirklich so abgestumpft?“ Schon grundlegende SQL-Injection verursacht jedes Jahr weiterhin enorme Schäden und steht immer noch weit oben bei OWASP. Auch SQL-Injection läuft letztlich darauf hinaus, einer Datenbank gottgleiche Rechte zu geben, ohne zu verstehen, wie das Ganze funktioniert. Auch die Handlungsbefugnisse von KI-Agenten sind für Nutzer nicht unbedingt sichtbar
  • Dass mit MCP auf breiter Front solcher leichtfertiger Zugriff stattfindet, sollte viel breiter diskutiert werden. Selbst sonst vorsichtige Menschen erkennen das Risiko oft nicht richtig
  • Früher nannte man es eine „Automatisierungsrevolution“, wenn E-Mail-Clients eingebettete Skripte aus von beliebigen Leuten aus dem Internet gesendeten Mails ausführten. Und früher hielt man es auch für gesünder, Kinder statt fernsehen lieber das Internet nutzen zu lassen. Wir wissen doch alle, wie das ausgegangen ist, oder?
• Es heißt oft, „wir leben in einer Welt, in der es normal geworden ist, Tools von zufälligen Leuten zu installieren“, aber eigentlich machen wir das schon seit Windows-XP-Zeiten, als wir CD-Ripping-Software, Bonzi Buddy und alles Mögliche völlig sorglos installiert haben. Bequemlichkeit stand immer schon über Sicherheit. Die wichtigste Lehre ist am Ende eher die Frage, warum „Sandbox, Sandbox, Sandbox“ bis heute noch keine Realität geworden ist. Bei diesem Vorfall wirkt es so, als hätte KI sämtliche bisherigen Sicherheitsprinzipien auf Werkseinstellungen zurückgesetzt
  • Auf die Frage „Menschen entscheiden sich leichter für Bequemlichkeit als für Sicherheit. Warum ist Sandboxing immer noch keine Realität?“ lautet die Antwort: weil Sandboxing nicht leicht umzusetzen ist. Und mit „leicht“ ist hier gemeint, dass es vom OS standardmäßig bereitgestellt wird
• Ein Nutzer könnte einem Nutzer bei GMail Spam-Mails mit Prompt Injection schicken, die für die KI bestimmt sind, auch wenn kein Mensch sie jemals öffnet https://www.linkedin.com/posts/eito-miyamura-157305121_we-got-chatgpt-to-leak-your-private-email-activity-7372306174253256704-xoX1/
• Dieser Blogpost ist extrem schwer zu lesen. Er wirkt, als hätte eine KI daran herumgedoktert. Zu viele unnötige Sätze und zu viel Zierrat. Schade, denn das Thema selbst ist interessant
• Bei Problemen der Supply-Chain-Sicherheit werden npm-Pakete fast immer erwähnt. Das liegt wohl daran, dass npm am weitesten verbreitet ist und Angreifer dort den größten Anreiz haben, aber ein bitterer Nachgeschmack bleibt trotzdem
  • OpenAI verteilt auch Codex CLI über npm. Es ist in Rust gebaut und verwendet trotzdem ein npm-Paket. Ich persönlich finde das absurd. Offenbar sind die Alternativen aber noch unbequemer
  • Genau aus diesem Grund betreibe ich keine stdio-MCP-Server. Alle MCPs laufen in Docker-Containern auf einem isolierten VM-Host in einem nicht vertrauenswürdigen VLAN. Und ich verbinde mich nur per SSE. Natürlich bleibt es anfällig für Prompt Injection, aber ich verbinde es nicht mit meinem zentralen Browser-Profil, meinen E-Mails oder meinen Cloud-Konten. Es ist vollständig von sensiblen Informationen getrennt
  • Es ist nicht wünschenswert, dass der obige Kommentar so viele Upvotes bekommt und dadurch missverstanden wird, als sei das die Hauptaussage dieses Artikels. Wenn man es so auffasst, verfehlt man den Kern
• Vielleicht hat der Entwickler das gar nicht absichtlich getan. Ich habe selbst schon Releases mit eingebautem Debugging-Code ausgeliefert. Wenn es nur ein schlichtes bcc war, könnte es tatsächlich einfach Debugging-Code gewesen sein
  • Genau das wollte ich auch sagen. Ehrlich gesagt würde niemand seine eigene E-Mail so offen hinterlassen, wenn es absichtlich gewesen wäre. Und dass man 2025 noch persönliches Gmail für Tests benutzt, ist schon peinlich genug. Außerdem ist das kein MCP-spezifisches Problem, sondern kann bei jedem Paket passieren
  • Auch das Löschen des Pakets als Reaktion ist ehrlich gesagt das typische Verhalten eines unerfahrenen Entwicklers, der zum ersten Mal mit einem Sicherheitsvorfall konfrontiert ist. Wenn es kein Vorsatz, sondern nur ein Debugging-Fehler war, ist Kommunikation der Schlüssel: die schädliche Version entfernen, einen Patch veröffentlichen und über öffentliche Kanäle wie Blog, hier auf HN und soziale Medien kommunizieren. Das ist der Weg, Vertrauen wiederherzustellen. Auch eine präzise Zeitleiste des Vorfalls (und nicht so eine von KI geschriebene Zusammenfassung wie im OP) würde dabei helfen
• Das Problem mit MCP-Servern ist riskant, aber ich glaube, diese Art von Angriff kann in jeder Situation auftreten, in der externe Abhängigkeiten wie ein smtp-Paket verwendet werden
  • Trotzdem nutzt man bei smtp-Paketen meist erprobte und seit Langem vertrauenswürdige Bibliotheken. Bei MCP ist alles neu, und es gibt noch keine gewachsene Vertrauensbasis. Es ist so etwas wie ein Wildwestgebiet der Software, in dem man mit einem geladenen Sechsschüsser herumlaufen muss