Eine gefälschte Jackson-Bibliothek stellte Cobalt Strike direkt aus Maven Central bereit

Wichtigste Erkenntnisse

• Ein Paket, das im Dezember 2025 über Maven Central bereitgestellt wurde und sich nur ein Namespace-Segment von Jackson entfernt befand, lieferte Cobalt Strike aus – es war keine CVE beteiligt.
• Maven Central überprüft, ob der Nutzer die Kontrolle über die Domain oder das Hosting-Konto eines Namespace hat, nicht jedoch, ob eine Verbindung zu dem Projekt besteht, dessen Namen der Namespace trägt.
• Über Maven Central veröffentlichte Artefakte sind mit PGP-Signaturen versehen, die von Maven standardmäßig nicht überprüft werden.
• Ein kompromittiertes npm-Paket gelangte im November 2025 über die mvnpm-Spiegelung automatisch in Maven Central.

Seit Log4Shell drehte sich der Großteil der Diskussionen rund um die Java-Lieferkette um eine bestimmte Art von Problem: eine Schwachstelle in legitimem Code. Dann, im Dezember 2025, tauchte etwas anderes auf. Bei einem Angriff durch Namensraum-Spoofing wurde ein Cobalt-Strike-Loader auf Maven Central unter Koordinaten platziert, bei denen ein einzelnes Segment der echten Jackson-Koordinaten ausgetauscht worden war.

Es wurde nichts ausgenutzt. Es lag keine Sicherheitslücke vor. Jemand hat einen Namensraum registriert, ein Artefakt veröffentlicht und darauf gewartet, dass die falschen Koordinaten kopiert werden.

Bei der Sicherheit von Maven Central geht es nicht nur um die von den meisten angenommenen Lücken bei der Signaturprüfung. Es handelt sich auch um ein Namespace-Problem, und die meisten Java-Tools erkennen keines von beiden.

Was ist eigentlich mit dem gefälschten Jackson-Paket passiert?

Die Funktionsweise lässt sich so einfach in einem Satz erklären, und genau deshalb hat sie funktioniert.

Jackson 2.x wird unter folgender Lizenz veröffentlicht: com.fasterxml.jackson.core:jackson-databind. Aikido Security, das das Paket am 25. Dezember entdeckt hatte, das bösartige Artefakt dokumentiert als org.fasterxml.jackson.core mit demselben jackson-databind artifactId, sodass die gesamte Koordinatenzeichenfolge um drei Zeichen verschoben war. Die Reverse-Domain-Benennung soll dies verhindern, und im Sinne ihres Konzepts hat sie gehalten, was sie versprochen hat. Maven Central bestätigte, dass der Herausgeber eine Domain kontrollierte, die mit dem Namespace übereinstimmte. Diese Domain lautete fasterxml.org, wurde am 17. Dezember 2025 – acht Tage vor der Analyse – über GoDaddy registriert und war nahezu identisch mit der echten fasterxml.com. Die Überprüfung der Eigentumsverhältnisse funktionierte korrekt. Sie überprüfte lediglich das Falsche.

Bei der Nutzlast handelte es sich nicht um einen schnellen „Smash-and-Grab“-Angriff. Nach der Entschleierung stellte sich heraus, dass es sich bei der Klasse um eine gefälschte Spring-Boot-Autokonfiguration handelte, und Forscher, die sie untersuchten, hat einen mehrstufigen Entwurf gefunden: AES-verschlüsselte Konfigurationszeichenfolgen, die mit einem fest programmierten Schlüssel entschlüsselt werden, ein @Configuration Klasse, die mit … annotiert ist @ConditionalOnClass(ApplicationRunner.class) damit Spring dies registrieren und die Nutzlast ausführen würde, sobald der Anwendungskontext geladen war: einen als IntelliJ-Datei getarnten Persistenzmarker sowie ein Plattform-Fingerprinting, bevor jeglicher Command-and-Control-Datenverkehr nach außen gelangte. Windows-Hosts luden svchosts.exe, ein Typosquat der echten svchost.exe Prozess. Auf Linux- und macOS-Hosts wurden Binärdateien gefunden, die von nahezu jeder Scan-Engine auf VirusTotal als Cobalt-Strike-Beacons identifiziert wurden – dabei handelt es sich um das kommerzielle Red-Team-Framework, dessen durchgesickerte Builds von Ransomware-Betreibern und APT-Gruppen weit verbreitet genutzt werden.

Nachdem das Paket gemeldet worden war, wurde es von Maven Central innerhalb von etwa neunzig Minuten entfernt – eine schnelle Reaktion für ein öffentliches Repository. Diese Geschwindigkeit hilft den Projekten jedoch nicht, die das Paket bereits während seiner Verfügbarkeit eingebunden hatten, und sagt nichts darüber aus, wie sich eine unauffälligere Variante desselben Tricks verhalten würde. Ein auffälliges Cobalt-Strike-Beacon wird entdeckt. Etwas, das darauf ausgelegt ist, im Verborgenen zu bleiben und Daten langsam zu exfiltrieren, könnte weitaus länger unentdeckt bleiben.

So funktioniert die Namespace-Impersonation bei Maven Central

Maven identifiziert Abhängigkeiten anhand von drei Koordinaten: groupId, artifactId und version.

Es ist üblich, dass „groupId“ eine umgekehrte Domain ist, die der Herausgeber kontrolliert, und Maven Central setzt dies bei der Registrierung durch, indem es einen Nachweis über die Kontrolle über die Domain oder über das damit verknüpfte Code-Hosting-Konto verlangt. Diese Überprüfung findet tatsächlich statt und funktioniert genau wie vorgesehen.

Es funktioniert einfach nicht so, wie die Leute annehmen. Der Nachweis der Kontrolle über eine Domain sagt nichts darüber aus, ob der Betreiber in irgendeiner Beziehung zu dem Projekt steht, an das der Namensraum erinnert. Er bestätigt lediglich die Kontrolle über eine Domain, und eine ähnlich klingende Domain kostet nur ein paar Dollar.

Jacksons tatsächlicher Namensraum neben drei Mustern, die jeder registrieren könnte, wobei keines davon das hier verwendete ist.

Die io.fasterxml.jackson, com.fasterxml-jackson.coreund org.jackson.databind Alle Varianten sind auf rechtmäßige Weise erreichbar, ohne dass irgendwo Abstriche gemacht werden müssen. Beim Jackson-Vorfall wurde eine eingeschränktere Variante desselben Konzepts verwendet: kein Bindestrich und keine andere TLD, sondern lediglich ein einzelnes Top-Level-Segment, das von „com“ zu „org“ ausgetauscht wurde, gepaart mit einer Domain, die speziell registriert wurde, damit dieser Austausch die Überprüfung bestand.

Koordinaten werden meist aus Antworten auf Stack Overflow, Blogbeiträgen und KI-generierten Codeausschnitten kopiert, anstatt aus dem Gedächtnis eingegeben zu werden. Dies ist ein Grund, warum dies in Java schwerer zu erkennen ist als bei npm-Paketen. Ein Entwickler, der axios bereits fünfzig Mal installiert hat, bemerkt „axois“ sofort. Kaum jemand hat die Jackson-groupId im Kopf, und noch weniger würden ein vertauschtes Segment in einer vierzig Zeichen langen Zeichenkette bemerken, die sie einfügen, anstatt sie zu lesen.

Das Kopieren von Koordinaten von einer Suchergebnisseite anstelle der projektinternen Dokumentation schafft eine weitere Möglichkeit für Verwechslungen bei den Namensräumen. Es lohnt sich, diese Gewohnheit abzulegen, unabhängig davon, wie sich dieser konkrete Vorfall entwickelt hat.

Die Sicherheitslücke bei Maven Central, die niemand überprüft

Das ist der Punkt, der Java-Entwickler überrascht, die sich noch nicht genauer damit befasst haben, und es handelt sich dabei um ein anderes Problem als das oben beschriebene.

Maven Central akzeptiert keine Veröffentlichung ohne PGP-Signatur. Jedes über Central veröffentlichte Artefakt wird mit einer .asc die dazugehörige Datei sowie Prüfsummen, und die Veröffentlichungsanforderungen sind strenger als die von npm oder PyPI. Das ist eine echte Stärke.

Maven überprüft diese Signaturen standardmäßig nicht.

ausführen. mvn install Bei einem Projekt mit zweihundert transitiven Abhängigkeiten ruft Maven zweihundert JAR-Dateien ab und vergleicht die dazugehörigen Prüfsummen. Standardmäßig wird bei einer Nichtübereinstimmung lediglich eine Warnung ausgegeben; ein Fehlschlag des Builds aufgrund einer einzigen Nichtübereinstimmung erfordert -C, oder ein checksumPolicy oder im Repository fehlschlägt. So oder so, das .asc Die Dateien neben diesen JAR-Dateien werden niemals verändert, es sei denn, ein Plugin fordert sie an.

Die Überprüfung der Prüfsumme und die Überprüfung der Signatur werden oft als gleichbedeutend behandelt, sind es aber nicht. Eine Prüfsumme bestätigt, dass die empfangene Datei mit der Datei übereinstimmt, die das Repository bereitstellt. Eine gültige Signatur belegt, dass das Artefakt mit einem bestimmten privaten Schlüssel signiert wurde, und es bedarf einer vertrauenswürdigen Schlüsselzuordnung, um diesen Schlüssel mit einem vertrauenswürdigen Herausgeber in Verbindung zu bringen. Maven führt standardmäßig die erste Überprüfung durch und lässt die zweite vollständig aus.

Das ist entscheidend, um herauszufinden, was hier geholfen hätte und was nicht. Der Angreifer kontrollierte fasterxml.org und konnte mit seinem eigenen Schlüssel signieren, sodass die Signaturprüfung auch für das schädliche Paket erfolgreich verlaufen wäre. Die Signaturprüfung belegt, dass sich ein Artefakt seit seiner Signierung durch den Inhaber dieses Schlüssels nicht verändert hat. Sie sagt jedoch nichts darüber aus, ob der Herausgeber tatsächlich derjenige ist, den der Namensraum vermuten lässt. Zwei Probleme, zwei Lösungen.

Gradle hat hier gegenüber Maven die Nase vorn, und die meisten Teams haben es noch nicht aktiviert.

./gradlew --write-verification-metadata sha256,pgp help

Das führt zu einem verification-metadata.xml Datei, die Gradle auf irgendeine Weise auflöst, und der Bootstrap-Vorgang ist der Teil, für den es sich lohnt, etwas Zeit zu investieren. Er ist bewusst optimistisch ausgelegt. Schlüssel, deren Überprüfung erfolgreich verläuft, werden automatisch zur Liste der vertrauenswürdigen Schlüssel hinzugefügt, Artefakte ohne verwertbare Signatur greifen auf Prüfsummen zurück, und alles, was in Ihrem Baum bereits kompromittiert ist, wird im Laufe des Prozesses freigegeben. Lesen Sie die generierten Prüfsummen und vertrauenswürdigen Schlüssel, bevor Sie die Datei committen. Sobald diese Baseline überprüft wurde, bricht Gradle den Build bei allem ab, was nicht mehr mit ihr übereinstimmt – dies stellt eine strenge Kontrolle dar und ist bei einem unkomplizierten Projekt kein großer Aufwand.

Maven hat im Kern kein Äquivalent. „Verification“ bezieht sich auf ein Plugin.

mvn org.simplify4u.plugins:pgpverify-maven-plugin:1.19.1:check

Diese Funktion überprüft Signaturen von Abhängigkeiten und akzeptiert eine explizite Schlüsselzuordnung, sodass nur die von Ihnen angegebenen Signaturschlüssel als vertrauenswürdig gelten. Sie funktioniert, und es ist nicht die Standardeinstellung, die jeder erhält.

Das Problem „Artefakt versus Quellcode“ liegt beiden Kontrollmechanismen zugrunde, da eine JAR-Datei ein Build-Ergebnis ist und nichts dafür sorgt, dass sie mit dem Quellcode-Repository übereinstimmt, auf das ein Projekt verweist. Ein Scanner, der die veröffentlichte Binärdatei ausliest, sieht genau das, was der Herausgeber dort hinterlegt hat – unabhängig davon, ob sie signiert ist oder nicht. Erst durch das Neuerstellen aus verifiziertem Quellcode erhalten Sie einen unabhängigen Nachweis darüber, was in ein Artefakt eingeflossen ist, anstatt sich auf die Binärdatei des Herausgebers zu verlassen – und genau auf dieser Prämisse basiert SecureChain für Java.

MavenGate und das Problem mit aufgegebenen Koordinaten

„MavenGate“, eine im Januar 2024 von Forschern bei Oversecured veröffentlichte Studie, beschrieb einen anderen Weg zu einem ähnlichen Ergebnis, der wohl noch beunruhigender ist, da er keinerlei Identitätsbetrug erfordert.

Die Technik zielt auf veraltete Abhängigkeiten ab. Eine Bibliothek, die vor Jahren unter com.oldcompany.util befindet sich in Tausenden von Abhängigkeitsbäumen. Das Unternehmen geht in Konkurs, die Domain läuft aus, und niemand bemerkt es, da das Artefakt weiterhin problemlos über Maven Central abgerufen werden kann.

Was als Nächstes geschieht, läuft weniger automatisch ab, als es klingt. Wenn kein Konto diese groupId in einem bestimmten Repository verwaltet, kann derjenige, der nun Eigentümer der Domain ist, diese mit einem DNS-TXT-Eintrag beanspruchen. Ist die groupId bereits registriert, bedeutet die Übernahme, dass das Support-Team des jeweiligen Repositorys davon überzeugt werden muss, den Zugriff zu übertragen, und Oversecured erklärte ausdrücklich, dass es keine Informationen darüber habe, wie solche Übertragungen ablaufen. Ein Großteil des Risikos geht zudem von Projekten aus, die sich über mehrere Repositorys erstrecken: Dort gelangt eine an anderer Stelle in der Liste eingefügte bösartige Version dennoch unter Koordinaten an, denen der Build bereits vertraut. Projekte, die Versionsbereiche verwenden oder auf die Version des Angreifers aktualisieren, übernehmen diese dann, ohne jemals einen unbekannten Namen zu sehen.

Das Ausmaß lässt sich leichter bestimmen als die technischen Details. Oversecured wandelte die groupIds aus Maven Central in Domains um und prüfte, welche davon einfach gekauft werden konnten; dabei erwiesen sich 3.710 von 26.163 Domains (14,18 Prozent) als käuflich. Erweitert man dies auf die von GitHub unterstützten Namespaces und die privaten Repositorys, die die Forscher finden konnten, schienen 18,18 Prozent eines Datensatzes mit 33.938 Identifikatoren offengelegt zu sein.

Sonatype stellte die Durchführbarkeit des Angriffs angesichts der vorhandenen Automatisierung in Frage, deaktivierte anschließend Konten, die mit abgelaufenen Domains verknüpft waren, verschärfte die Überprüfung von Namespaces und behob einen Fehler bei der Validierung öffentlicher Schlüssel, durch den Artefakte durchgelassen worden waren, die mit Schlüsseln signiert waren, die nirgendwo veröffentlicht worden waren. Oversecured entgegnete, dass keine einzelne Registrierungsstelle diese Lücke schließen könne, da der Angriff Projekte ins Visier nehme, die gleichzeitig aus mehreren öffentlichen Repositories aufgerufen würden, und dass Repository-Betreiber höchstens automatische Ansprüche auf Namespaces ablehnen könnten, die bereits als anfällig gekennzeichnet seien.

Die übliche Richtlinie von Maven Central sieht vor, dass veröffentlichte Releases unveränderlich bleiben, sodass eine Version vom Herausgeber nicht unbemerkt geändert oder zurückgezogen werden kann; Sicherheitsbedingte Rücknahmen wie im Fall von Jackson stellen dabei eine seltene Ausnahme dar. Dies ist für die Reproduzierbarkeit von Vorteil. Es bedeutet aber auch, dass aufgegebene Abhängigkeiten weiterhin aufgelöst werden können und noch lange, nachdem die hinter dem Namespace stehende Domäne oder das Konto nicht mehr gepflegt wird, tief in den Abhängigkeitsbäumen verbleiben und von innen betrachtet identisch mit funktionierenden Abhängigkeiten aussehen. pom.xml.

Was mit diesen Bibliotheken geschieht, wenn eine CVE bekannt wird, ist eine Frage, auf die es keine gute Antwort gibt. Es gibt keine gepatchte Version, auf die man aktualisieren könnte, und wenn man eine sicherheitsrelevante Java-Bibliothek in das eigene Repository einbindet, bedeutet dies, dass Ihr Team nun für deren CVEs verantwortlich ist – unabhängig davon, ob dafür Personal vorgesehen war oder nicht.

Wie ein manipuliertes npm-Paket in Maven Central gelangte

Was den meisten Java-Teams entgeht, ist, dass dies geschehen kann, ohne dass sich jemand aus dem Team auch nur im Entferntesten mit npm befassen muss.

Im November 2025 wird die zweite Welle der Der npm-Wurm „Shai-Hulud“ hat Maven Central erreicht durch automatisierte mvnpm-Spiegelung. mvnpm veröffentlicht npm-Pakete als Maven-Artefakte neu, sodass Java-Webprojekte Frontend-Bibliotheken im Rahmen ihres normalen Build-Prozesses ohne separate JavaScript-Toolchain beziehen können. Die Spiegelung erfolgt automatisch, und neue npm-Veröffentlichungen werden sofort nach ihrer Veröffentlichung synchronisiert – genau darin liegt der Sinn des Tools, und genau so gelangte das kompromittierte Paket auch durch die Sicherheitsbarriere. Eine bösartige Veröffentlichung des npm posthog-node Das Paket wurde in Maven Central neu erstellt als org.mvnpm:posthog-node:4.18.1, mit dem gleichen setup_bun.js Lader und bun_environment.js Nutzlast als die npm-seitige „Shai-Hulud“-Kampagne.

Socket meldete das Artefakt, und Maven Central bestätigte, dass die kompromittierte Version aus dem automatisierten mvnpm-Prozess stammte, und löschte noch am selben Tag alle gespiegelten Kopien. PostHog veröffentlicht überhaupt nichts bei Maven. Es gibt keine Hinweise darauf, dass sich der Wurm innerhalb des Maven-Ökosystems selbst weiterverbreitet hat; es gab lediglich dieses eine gespiegelte Artefakt. Diese Unterscheidung ist entscheidend dafür, wie ernst man diesen Vorfall als aktives Muster in der Maven-Lieferkette und nicht als Einzelfall nehmen sollte. Der Vorfall war real und erfolgte automatisch, und kein Java-Betreuer musste etwas neu veröffentlichen, damit eine kompromittierte npm-Version für Java-Builds verfügbar wurde – doch sobald sie dort angekommen war, verhielt sie sich nicht wie ein Wurm.

Dies zeigt jedoch, dass durch automatische Spiegelung eine Vertrauensgrenze verschoben wird, ohne dass jemand bewusst eine solche Verschiebung beschlossen hat. Ein Java-Entwicklungsteam, das noch nie mit npm zu tun hatte, kann am Ende ein kompromittiertes npm-Paket einbinden, weil ein Bridge-Dienst es in seinem Auftrag in eine JAR-Datei umgewandelt hat.

Überprüfen Sie den transitiven Pfad direkt, anstatt darüber zu spekulieren, was dort sein sollte. Finden Sie heraus, was tatsächlich in Ihrem Baum enthalten ist.

mvn dependency:tree -DoutputFile=deps.txt

Dann lesen Sie es doch einfach. Ein mittelgroßer Spring-Service kann problemlos mehrere hundert Artefakte aus ein paar Dutzend deklarierten Abhängigkeiten auflösen. Gespiegelte Pakete tauchen in dieser Ausgabe tatsächlich auf, und zwar unter org.mvnpm Koordinaten – das ist ein echter Hinweis, solange jemand im Team weiß, dass „Namespace“ für einen für Maven neu verpackten npm-Code steht.

Was Sie diesen Monat an Ihrem Build ändern sollten

Beginnen Sie mit dem Build-Tool, das Sie bereits verwenden, da die beiden Vorgehensweisen einen unterschiedlichen Aufwand erfordern. Mit Gradle lässt sich die Überprüfung der Abhängigkeiten schnell einrichten, und zwar mit --write-verification-metadata sha256,pgp, dann müssen die generierten Hashes und Schlüssel überprüft werden, bevor die Datei festgeschrieben wird. Da Maven keine entsprechende native Funktion bietet, muss ein Plugin hinzugefügt und die Versionen in pluginManagement, was zwar etwas mehr Vorbereitungsaufwand erfordert, aber dennoch eine Aufgabe für eine Woche ist und nicht für ein Quartal.

Schauen Sie sich dann die Vorgehensweise an, die das Jackson-Paket überhaupt erst durchgelassen hat. Koordinaten werden einfach von dort kopiert, wo sie gerade gefunden werden, anstatt mit den projektinternen Dokumenten abgeglichen zu werden – und das lässt sich mit einer Regel leichter beheben als mit einem Tool. Überprüfen Sie jede groupId, die Ihr Team bisher noch nicht verwendet hat, anhand der Koordinaten im offiziellen Repository oder in der Dokumentation des Projekts, bevor sie auch nur in die Nähe eines pom.xml, insbesondere alles, was aus einem Suchergebnis oder einem von einer KI generierten Ausschnitt übernommen wurde.

Bei aufgegebenen Abhängigkeiten ist eine andere Art der Beurteilung erforderlich, und MavenGate ist der Grund dafür. Ein Artefakt ohne aktuelle Veröffentlichungen und ohne aktiven Betreuer ist ein Kandidat für eine Übernahme, unabhängig davon, ob derzeit eine offene CVE vorliegt oder nicht, denn das Risiko liegt nicht im Code, sondern darin, ob noch jemand die Kontrolle über die Domain oder das Konto hinter diesem Namespace hat.

Ein Gradle-Projekt, das in den letzten Jahren gestartet wurde, lässt sich innerhalb eines Tages auf Verifikation umstellen. Bei einem zehn Jahre alten, aus mehreren Modulen bestehenden Maven-Build mit einem benutzerdefinierten Parent-POM und vierzig Plugins ist das eine ganz andere Geschichte, und der Implementierungsaufwand unterscheidet sich zwischen den beiden Fällen tatsächlich erheblich.

Wo SecureChain zum Einsatz kommt

Maven Central überprüft beim Einlesen die Eigentumsverhältnisse der Namespaces, und Maven vergleicht beim Herunterladen die Prüfsummen des Repositorys. Nichts im Standardpfad bestätigt, dass die von Ihnen aufgelöste Binärdatei mit dem übereinstimmt, was das Projekt tatsächlich erstellt hat. SecureChain for Java ersetzt diesen Auflösungspfad, erstellt jedes Paket aus verifizierter Quelle neu, überprüft es auf böswilliges Verhalten, bevor es Ihren Build erreicht, und führt kontinuierlich Patches durch – auch nach Ablauf des Upstream-Supports. Ihr bestehender Maven- oder Gradle-Workflow bleibt unverändert – richten Sie ihn einfach auf TuxCare aus und fahren Sie mit dem Build fort.

Erfahren Sie, was SecureChain for OSS abdeckt, oder abonnieren Sie den Newsletter, um solche detaillierten Berichte zu Vorfällen zu erhalten, sobald sie eintreten.

FAQ

Was versteht man unter „Namespace-Impersonation“ bei Maven Central?

Veröffentlichung eines Artefakts unter einer groupId, die so gestaltet ist, dass sie dem Namensraum eines legitimen Projekts ähnelt. Maven Central überprüft, ob der Herausgeber die Kontrolle über die entsprechende Domain oder das Hosting-Konto hat. Dies bestätigt zwar die Kontrolle über diesen Namensraum, sagt jedoch nichts über eine mögliche Verbindung zu dem nachgeahmten Projekt aus.

Überprüft Maven PGP-Signaturen?

Nicht standardmäßig. Maven Central verlangt PGP-Signaturen für veröffentlichte Artefakte, und Maven vergleicht zwar die Prüfsummen des Repositorys, überprüft jedoch standardmäßig weder diese Signaturen noch die Zuordnungen zu vertrauenswürdigen Schlüsseln. Für die Überprüfung ist ein Plugin wie das „pgpverify-maven-plugin“ erforderlich.

Wie aktiviere ich die Abhängigkeitsprüfung in Gradle?

ausführen. ./gradlew --write-verification-metadata sha256,pgp help um ein verification-metadata.xml Datei, überprüfen Sie die generierten Prüfsummen und vertrauenswürdigen Schlüssel und übernehmen Sie anschließend diese Baseline. Danach bricht Gradle den Build für jedes Artefakt ab, dessen Prüfsumme oder Signatur nicht mehr übereinstimmt.

Was ist MavenGate?

Eine im Januar 2024 von Forschern von Oversecured veröffentlichte Übernahme-Technik, die auf aufgegebene Abhängigkeiten abzielt. Wer die abgelaufene Domain oder das Konto hinter einer alten groupId erwirbt, kann möglicherweise diesen Namensraum in einem Repository beanspruchen, in dem dieser nicht verwaltet wird, oder versuchen, Zugriff auf eine bestehende Registrierung zu erlangen; Projekte, die über mehrere Repositorys hinweg aufgelöst werden, können dann bösartige Artefakte unter vertrauten Koordinaten akzeptieren.

Kann ein kompromittiertes npm-Paket Auswirkungen auf ein Java-Projekt haben?

Ja. Bridge-Dienste, die npm-Pakete automatisch als Maven-Artefakte neu veröffentlichen, können eine kompromittierte npm-Version in Maven Central einbringen, wo sie als gewöhnliche JAR-Datei in einem Java-Build unter org.mvnpm Koordinaten. Diese Koordinaten benennen die Brücke, aber ein Team, das den Namensraum nicht erkennt, behandelt das Artefakt wie jede andere Abhängigkeit. Genau das ist passiert, als Shai-Hulud 2.0 im November 2025 über mvnpm bei Maven Central landete.

Wie kann ich feststellen, ob bei meinem Java-Build eine schädliche Java-Bibliothek eingebunden wurde?

ausführen. mvn dependency:tree oder ./gradlew dependencies und jede unbekannte `groupId` anhand der Dokumentation des jeweiligen Upstream-Projekts überprüfen, anstatt sich auf Suchergebnisse zu verlassen. Bei eingestellten Projekten sollte das Risiko einer Übernahme unabhängig vom CVE-Status betrachtet werden. Letztendlich kommt es immer noch auf diese Art der manuellen Überprüfung an, da die Namespace-Überprüfung von Maven Central lediglich die Kontrolle über eine Domain oder ein Hosting-Konto feststellt und nicht die Zugehörigkeit zu einem gleichnamigen Projekt, und da Maven die Signaturen von Abhängigkeiten standardmäßig nicht authentifiziert.

Gibt es in Java ein Äquivalent zu den „postinstall“-Skripten von npm?

Dies gilt zwar nicht für die Installation von Abhängigkeiten, doch Java-Builds führen nach wie vor nicht vertrauenswürdigen Code aus. Maven-Plugins werden im Build-Lebenszyklus ausgeführt, Annotationsprozessoren laufen innerhalb des Compilers, und Gradle-Build-Skripte sind ausführbare Programme und keine Konfigurationsdateien. Das gefälschte Jackson-Paket nutzte zur Laufzeit einen ähnlichen Trick, wodurch Spring seine Konfigurationsklasse erkennen und die Schadfunktion in seinem Namen starten konnte.

Zusammenfassung

Artikel Name

Sicherheit bei Maven Central nach dem Jackson-Doppelgänger

Beschreibung

Ein gefälschtes Jackson-Paket hat die Prüfungen bei Maven Central bestanden und Cobalt Strike bereitgestellt. Hier erfahren Sie, wie das funktioniert hat und wie man es erkennen kann.

Autor

Tim Walker

Name des Herausgebers

TuxCare

Logo des Herausgebers