Welche Steuerelemente stoppen tatsächlich axios, jscrambler, Shai-Hulud und Miasma?

Wichtigste Erkenntnisse

• „Third Coming“ und „Miasma“ nutzten vertraute CI-Veröffentlichungswege aus, anstatt gestohlene, langfristig gültige Maintainer-Token zu verwenden.
• Ein Register, das Veröffentlichungsinhalte überprüft, kann solche Veröffentlichungen aufspüren, selbst wenn die Bescheinigung gültig ist.
• Bei Paketen, die von SecureChain abgedeckt werden, verhindert ein Neu-Build aus geprüften Quellen, dass eine mit gestohlenen Zugangsdaten erstellte Version in Ihren Build gelangt.
• Ein Quarantänefenster ist nur dann hilfreich, wenn die schädliche Version entfernt wird, bevor die Wartezeit abläuft.

npm-Sicherheitslücken treten so häufig auf, dass jedes Mal dieselbe Folgefrage aufkommt: Hätte eine sichere npm-Registry diesen Vorfall tatsächlich verhindern können? Die Antwort hängt vom jeweiligen Mechanismus ab – und genau diesen Aspekt lassen die meisten Anbieter in ihren Aussagen außer Acht.

In diesem Beitrag werden die tatsächlichen Kontrollmechanismen von SecureChain anhand von vier Vorfällen aus dem Jahr 2026 überprüft: axios, jscrambler, Shai-Huluds „Drittes Kommen“ und Miasma. Jeder Vorfall wird dem Mechanismus zugeordnet, der ihn abfängt, zusammen mit der Konfidenz, die diese Zuordnung erhält.

Zwei Grundursachen, nicht vier separate Vorfälle

Ordnet man die vier Kampagnen nach ihrem Wirkmechanismus, lassen sie sich in zwei Gruppen unterteilen, nicht in vier.

Sowohl bei Axios als auch bei Jscrambler ging es um gestohlene Veröffentlichungszugangsdaten, die direkt gegen das Repository eingesetzt wurden, wobei der projektinterne CI-Prozess vollständig umgangen wurde. Im Fall von Axios gelangte ein Angreifer durch eine gezielte Social-Engineering-Kampagne an den Rechner des Hauptbetreuers und veröffentlichte dann am 31. März manuell zwei manipulierte Versionen. Das Quell-Repository wurde zu keinem Zeitpunkt verändert, und hinter keiner der beiden Veröffentlichungen verbirgt sich ein Commit oder Tag. Der jscrambler-Vorfall im Juli verlief nach dem gleichen Muster. Jscrambler bestätigte später, dass ein Angreifer kompromittierte npm-Veröffentlichungszugangsdaten nutzte, um innerhalb von etwa drei Stunden fünf bösartige Versionen hochzuladen, wobei auch hier im Repository keinerlei Hintergründe zu finden waren.

„Third Coming“ und „Miasma“ entsprechen diesem Muster nicht, und genau diese Lücke ist der Grund, warum dieser Beitrag existiert, anstatt lediglich auf die Berichte zu verlinken. Bei beiden Kompromittierungen gelangte der Zugriff in die Build-Pipeline statt auf das npm-Token eines Betreuers. Bei Bitwarden erfolgte der Zugriff über eine kompromittierte Checkmarx-GitHub-Action, die bereits in Bitwardens eigener Pipeline verwendet wurde; anschließend wurde der Release-Workflow wiederholt bearbeitet, um ein vorgefertigtes Tarball über Bitwardens OIDC-gestützten npm-Veröffentlichungspfad zu veröffentlichen. Im Fall von Miasma wurden am 1. Juni mindestens 32 Pakete im Bereich @redhat-cloud-services von Red Hat mit bösartigen Versionen ausgeliefert, nachdem das GitHub-Konto eines Red-Hat-Mitarbeiters kompromittiert worden war. Der Angreifer pushte „Orphan-Commits“, die die Code-Review vollständig umgingen, und veröffentlichte sie anschließend über den OIDC-Pfad der GitHub-Actions des Repositorys. Keiner der Angreifer benötigte die npm-Anmeldedaten eines Betreuers, um eine Veröffentlichung legitim erscheinen zu lassen.

Diese Unterscheidung ist für eine Bewertung von Bedeutung. „Miasma“ ist ein anschauliches Beispiel dafür. Wiz stellte fest, dass der eingeschleuste Workflow ein OIDC-Token anforderte und Pakete mit gültigen SLSA-Herkunftsbescheinigungen veröffentlichte, da der Workflow, der diese erzeugt hatte, tatsächlich die legitime CI-Pipeline war – nur ausgelöst durch einen Commit, den niemand autorisiert hatte.

Bei „Third Coming“ ist die Lage undurchsichtiger. Endor Labs hat den öffentlichen Commit-Verlauf durchgesehen und festgestellt, dass der Release-Workflow fünfmal kurz hintereinander bearbeitet wurde, um ein gestuftes Tarball-Archiv zu veröffentlichen; bei einem dieser Versuche wurde das Provenienz-Flag gänzlich weggelassen. Die Analyse lehnt es ausdrücklich ab, die erfolgreiche Veröffentlichung einem bestimmten Durchlauf zuzuordnen oder als signierte Zeitleiste der Reaktion auf den Vorfall zu interpretieren.

So oder so bleibt das Argument bestehen. Der Ersatz langlebiger Token durch „Trusted Publishing“ ist genau das, was nach einem Vorfall mit gestohlenen Anmeldedaten wie bei Axios empfohlen wird, und beide Kampagnen zeigen, wo diese Empfehlung an ihre Grenzen stößt, denn eine kompromittierte Pipeline kann eine Veröffentlichung erzeugen, die legitim aussieht, unabhängig davon, ob ihr letztendlich eine einwandfreie Bescheinigung beigefügt ist oder nicht. Eine Registry, die nur auf eine grüne Bescheinigung prüft, hätte Miasma komplett übersehen, und es ist nicht davon auszugehen, dass sie Third Coming aufgefangen hätte.

Auch die Tradition der Namensgebung setzte sich fort. Im August tauchte eine separate Kampagne unter dem Hashtag „Here We Go Again“ auf. Dabei handelt es sich um einen eigenständigen Vorfall, nicht um eine Wiederholung von „Third Coming“.

Wie eine sichere npm-Registry erfasst, was in die Pipeline gelangt

Das ist der entscheidende Punkt bei „Third Coming“ und „Miasma“, denn bei keinem der beiden wird geprüft, ob eine Veröffentlichung aus einem vertrauenswürdigen Workflow stammt. Bei beiden handelte es sich um vertrauenswürdige CI-Veröffentlichungspfade.

Wann das Blockieren von Installationsskripten nicht mehr hilft

npm führt die Installationsskripte eines Pakets automatisch aus, sofern nichts dies verhindert, und genau diesen Mechanismus nutzten die meisten dieser Kampagnen als Erstes aus. Die bösartige axios-Abhängigkeit wurde über einen „postinstall“-Hook ausgelöst. Die ersten drei manipulierten Versionen von jscrambler nutzten „preinstall“, ebenso wie die mit einer Hintertür versehene Bitwarden-CLI und die Hauptwelle der Miasma-Veröffentlichungen.

Stand: npm 12, das im Juli 2026 ausgeliefert wurde, sind Skripte zur Installation von Abhängigkeiten standardmäßig deaktiviert. „preinstall“, „install“ und „postinstall“ werden nur noch ausgeführt, wenn ein Projekt dies ausdrücklich genehmigt, und npm blockiert zudem den impliziten „node-gyp“-Neubau, den ein Skript auf Root-Ebene binding.gyp Datei, die zum Auslösen verwendet wurde. Dieser zweite Teil ist hier keine reine Theorie, denn in Wiz’ Folgebeitrag vom 4. Juni wurde eine weitere Welle von Miasma-Paketen behandelt, die binding.gyp um während der Installation Code auszuführen – genau das geschieht, wenn Scanner nur den Skriptblock auslesen. Auf älteren Clients, --ignore-scripts umfasst die Teilmenge der Lebenszyklus-Skripte und nichts darüber hinaus.

Dann gibt es noch die Einschränkung, die jscrambler im Rahmen desselben Vorfalls demonstriert hat. Ab Version 8.18.0 hat der Angreifer den identischen Dropper aus dem Preinstall-Bereich in eine selbstausführende Funktion am Anfang von dist/index.js, sodass es beim Import oder bei der Verwendung über die Befehlszeile statt bei der Installation ausgeführt wurde und problemlos ablief npm install --ignore-scripts. Angreifer können die Schadlast verschieben. Durch das Blockieren von Installationsskripten wird sie nicht aus dem Paket entfernt.

Warum bei der Inhaltsprüfung die Bescheinigung außer Acht gelassen wird

Die Kontrollinstanz, die tatsächlich auf „Third Coming“ und „Miasma“ reagiert, greift bereits einen Schritt früher ein und überprüft die Release-Version anstelle des Herausgebers. Bei der Inhaltsprüfung kann nach unerwarteten Installations-Hooks, verschleiertem Code ohne ersichtlichen Grund, Abweichungen zwischen dem veröffentlichten Artefakt und dem Quellcode des Projekts sowie Anomalien zwischen den einzelnen Versionen gesucht werden. Der Bitwarden-Release zeigt, wie deutlich dieses letzte Signal ausfallen kann, da der rekursive Diff von Endor Labs Folgendes festgestellt hat: package.json In der Werbung wurde die Version 2026.4.0 angegeben, während die mitgelieferte CLI in ihren gepackten Metadaten noch die Version 2026.3.0 enthielt – was darauf hindeutet, dass sie schon lange vor jeglicher Dekompilierung neu gepackt wurde.

SecureChain selbst beschreibt diesen Schritt wie folgt: Jedes Paket wird in gehärteten, isolierten Umgebungen aus dem Quellcode neu kompiliert und auf bekannte Malware, verdächtige Codemuster und Risiken in der Lieferkette überprüft, wobei alles, was die Überprüfung nicht besteht, blockiert wird, bevor es Ihre Umgebung erreicht. Bei einer Überprüfung auf dieser Grundlage spielt es keine Rolle, ob eine Veröffentlichung über ein gekapertes persönliches Token oder eine kompromittierte CI-Pipeline mit einwandfreier Zertifizierung erfolgt ist, da die Zertifizierung nicht gelesen wird.

Die Zuverlässigkeit ist hier mäßig bis hoch, wobei derselbe Vorbehalt gilt wie bei der Skriptblockierung. Es handelt sich um eine Erkennung, und bei der Erkennung gibt es eine Falsch-Negativ-Rate. Malware kann ihr Verhalten verzögern, verschleiern oder aufteilen, und die Kursänderung von jscrambler mitten im Vorfall ist ein guter Hinweis darauf, dass sich Angreifer an das anpassen, wonach die Scanner suchen. Es ist immer noch das, was auf dieser Liste am ehesten der Herausforderung von „Third Coming“ und „Miasma“ auf deren eigenen Bedingungen gerecht wird, da es den Inhalt einer Veröffentlichung bewertet, anstatt der Identität dahinter zu vertrauen.

SecureChain als Ersatz für die npm-Registry zum Schutz vor Hijacking durch gestohlene Anmeldedaten

axios und jscrambler sind der übersichtlichere Fall, und genau hier macht sich ein Ersatz für die npm-Registry mit dem geringsten Aufwand bezahlt.

Richten Sie Ihre Builds auf einen kuratierten, aus dem Quellcode neu kompilierten Katalog aus. Für jedes von SecureChain abgedeckte Paket erhalten Sie dann die Version, die TuxCare aus verifiziertem Quellcode in einer gehärteten Umgebung erstellt hat – und nicht die Version, die zuletzt auf npmjs.com hochgeladen wurde. Ein bösartiges Tarball, das mit einem gestohlenen Token veröffentlicht wurde, befindet sich schlichtweg nicht in diesem Pfad. Es spielt keine Rolle, wie überzeugend es verpackt ist oder wie schnell es anderswo als verdächtig markiert wird, denn Ihr Build würde niemals auf die Kopie in der öffentlichen Registry zurückgreifen. Bei jscrambler handelt es sich strukturell um „axios“ mit einem anderen Paketnamen, sodass für beide die gleiche Garantie gilt.

Bei zwei Punkten lohnt es sich, genau zu sein, denn wenn man sie miteinander verwechselt, wird dieses Argument überbewertet. Der erste Punkt ist die Abdeckung. SecureChain startete mit den am häufigsten verwendeten Paketen aus der npm-Registry und fügt ein Paket hinzu, auf das Sie angewiesen sind, falls es noch nicht im Katalog enthalten ist. Die oben genannte Garantie gilt also für die abgedeckten Pakete und nicht für jeden Namen, den ein Abhängigkeitsbaum zufällig mit einbezieht. Der zweite Punkt ist die Reproduktionsgenauigkeit. Ein veröffentlichtes npm-Paket enthält oft transpilierte oder gebündelte Ergebnisse statt des Rohquellcodes aus dem Repository, und eine Byte-für-Byte-Übereinstimmung würde bedeuten, die eigene Build-Umgebung des Herausgebers zu reproduzieren – was das Ökosystem nicht garantiert. Ein SecureChain-Neubau ist kein bitweiser Klon des Tarballs des Herausgebers, und das war auch nie beabsichtigt. Es handelt sich um einen Build mit nachvollziehbarer Herkunft – eine andere und nützlichere Eigenschaft, wenn Sie dem Tarball des Herausgebers nicht mehr vertrauen.

Genau für diese Rückverfolgbarkeit sind die zugehörigen Metadaten gedacht. SecureChain-Pakete werden so erstellt und signiert, dass sie die Herkunftsnachweise gemäß SLSA Level 3 unterstützen, wobei die Builds aus geprüften Quellen stammen und durch kontinuierliche Tests abgesichert sind. TuxCare veröffentlicht SBOM- und VEX-Metadaten, sofern diese verfügbar sind. Die SBOM-Abdeckung variiert je nach Paket und wird weiterhin ausgebaut – je nach Paket im SPDX- oder CycloneDX-Format. Sie sollten daher die aktuelle Dokumentation konsultieren, anstatt von einem einheitlichen Satz auszugehen.

Ein Quarantänefenster verhält sich gegenüber kurzlebigen Freigaben deterministisch

Überprüfung, Skriptblockierung, Neuerstellung aus dem Quellcode. Bei allen drei Verfahren wird erkannt, dass etwas nicht stimmt. Ein Quarantänefenster muss nichts erkennen.

Verzögert man die Auswertung einer frisch veröffentlichten Version lange genug, ist eine Version, die innerhalb dieses Zeitfensters zurückgezogen wird, niemals für einen Build qualifiziert. Es wird nichts analysiert, und es gibt keinen Klassifikator mit einer Falsch-Negativ-Rate, die angepasst werden müsste. Die Länge des Zeitfensters und etwaige Ausschlüsse sind zwar nach wie vor Konfigurationsentscheidungen, aber es handelt sich um solche, die man an einem Whiteboard festlegen kann. Der Haken liegt jedoch im Wortlaut. Das Alter allein macht eine Version noch nicht sicher. Es verschafft anderen Zeit, sie aufzuspüren. Eine bösartige Version, die über die Verzögerungszeit hinaus online bleibt, wird wie jede andere Version mit der Zeit für die Überprüfung zugelassen – genau das ist bei jscrambler 8.14.0 passiert.

Zwei davon sind eindeutige Siege der Arithmetik über die Analysis. jscrambler ist das Gegenbeispiel. Miasma liegt dazwischen, da Wiz berichtete, dass die meisten bösartigen Versionen bis 13:00 Uhr UTC widerrufen worden waren, wobei zu diesem Zeitpunkt noch zwei aktiv waren. Dies belegt zwar eine schnelle teilweise Entfernung, lässt jedoch offen, ob jede Version verschwunden war, bevor eine 24-Stunden-Sperrfrist abgelaufen wäre.

Der Kompromiss ist ebenfalls real. Ein Quarantänefenster bedeutet, dass man bei legitimen Patches leicht in Verzug gerät, und Teams, die auf der Grundlage sich schnell verändernder Upstream-Abhängigkeiten arbeiten, spüren dies stärker als Teams auf langsameren internen Plattformen. Es ist zudem eine der am einfachsten umzusetzenden Kontrollmaßnahmen in diesem Zusammenhang und jene, die bei einer Bewertung am ehesten abgetan wird, weil sie zu einfach klingt, um wirklich etwas zu bewirken.

Sicherheit privater npm-Registries – mehr als nur ein Pull-Through-Cache

Ein Wechsel ist nur dann von Bedeutung, wenn er im Alltag funktioniert – daher nun zum praktischen Teil.

Die Integration besteht aus zwei Zeilen in .npmrc, eine Registrierungszeile und die Authentifizierungszeile für diesen Host, unter Verwendung des CLN-Tokens, das TuxCare Ihnen ausstellt, wobei „YOUR_CLN_TOKEN“ durch das tatsächliche Token ersetzt wird:

registry=https://artifacts.tuxcare.com/npm/
//artifacts.tuxcare.com/npm/:_authToken=YOUR_CLN_TOKEN

package.json ändert sich nicht. Namen und Versionen bleiben unverändert, und derselbe Endpunkt stellt sowohl SecureChain-Builds bereit, sofern vorhanden, als auch das öffentliche Upstream-Paket für alles andere, sodass keine zweite Registry eingerichtet werden muss.

Es gibt einen kleinen Haken, den man vor einer flächendeckenden Einführung noch testen sollte. package-lock.json Es speichert unter anderem eine aufgelöste URL, die angibt, woher der jeweilige Tarball stammt, sowie einen Integritäts-Hash über die Bytes dieses Tarballs. Es ist zu erwarten, dass sich die aufgelöste URL ändert, wenn man den Host wechselt. Der Integritäts-Hash ist dabei der interessante Aspekt. Ein Hash wird anhand eines byte-identischen Tarballs von einem beliebigen Host validiert; ein reiner Hostwechsel würde ihn also nicht beeinflussen, doch ein neu erstellter SecureChain ist naturgemäß nicht byte-identisch mit dem öffentlichen Artefakt. Diese Diskrepanz zeigt sich als EINTEGRITY wenn eine alte Sperrdatei der öffentlichen Registrierung auf eine neue Registrierung darunter trifft.

Planen Sie also lieber eine Neuerstellung der Lockdatei ein als einen rein kosmetischen Diff. Löschen Sie node_modules und package-lock.json, führen Sie eine Neuinstallation mit der neuen Registry durch und übertragen Sie anschließend die dabei erstellte Sperrdatei, in der die SecureChain-URLs und Prüfsummen gespeichert sind. Führen Sie dies zunächst in einem temporären Branch oder einem Klon durch, damit Sie den Diff selbst lesen können, anstatt darauf zu warten, dass CI ihn für Sie ermittelt. Entscheide dann im Voraus, ob die Änderung als eigenständiger Commit in allen Repos in einem Durchgang erfolgt oder schrittweise ausgerollt wird. Wenn ein Wechsel der Registry in einen Feature-Zweig gemischt wird, kann die Konfiguration unbemerkt von jemandem rückgängig gemacht werden, der gar nicht wusste, dass sie dort vorhanden war.

Zwei weitere Schritte machen aus dem Vorschlag eine verbindliche Regelung. Verschieben Sie CI nach npm ci wo auch immer es noch läuft npm install, da npm ci führt die Installation anhand der festgeschriebenen Sperrdatei durch und schlägt fehl, wenn die Sperrdatei und package.json Statt es stillschweigend zu aktualisieren, sollte man lieber widersprechen. Anschließend sollte der ausgehende Datenverkehr zu registry.npmjs.org von den Build-Agenten blockiert werden, da – solange dies nicht behoben ist – die Registry-Einstellung in .npmrc ist ein Vorschlag, den jeder außer Kraft setzen kann, um eine Bereitstellung freizugeben.

Testen Sie diese Ausgangsblockierung zunächst in der Staging-Umgebung, bevor Sie sie überall durchsetzen. Wenn dort Fehler auftreten, können Sie erkennen, welche Pipelines und Tools die Registry-Einstellung umgangen haben – und diese Liste ist als Dokument viel wertvoller als als Vorfall.

Argumente für eine andere npm-Registry

Die Inhaltsprüfung und das „Rebuild-and-Resolve“-Verfahren decken unterschiedliche Fehlermodi ab – nicht denselben zweimal. Die Inhaltsprüfung bezieht sich auf „Third Coming“ und „Miasma“, da sie nicht davon abhängt, woher eine Veröffentlichung stammt. Das Neuerstellen und Auflösen aus einem kuratierten Katalog bezieht sich auf „axios“ und „jscrambler“, da bei einem abgedeckten Paket das bösartige Artefakt niemals in den Pfad gelangt, aus dem Ihr Build aufgelöst wird – gestützt durch signierte Artefakte und eine Herkunftsnachweis nach SLSA Level 3.

Falls Ihr Team noch immer direkt aus dem öffentlichen Register abruft, holen Sie sich ein Angebot für SecureChain für npm ein und finden Sie heraus, was es kostet, diese Lücke zu schließen.

FAQ

Was ist eine sichere npm-Registry?

Eine Registrierungsschicht, die für die von ihr abgedeckten Abhängigkeiten neu erstellte und geprüfte Pakete bereitstellt, anstatt das Artefakt des Herausgebers direkt weiterzuleiten. In der Praxis handelt es sich um eine Mischung aus SecureChain-Builds, sofern vorhanden, und öffentlichen Upstream-Paketen für den Rest, die alle über denselben Endpunkt bereitgestellt werden. Dies unterscheidet sich von einem Pull-Through-Cache, der die Verfügbarkeit und Geschwindigkeit verbessert, ohne die durch ihn hindurchgeleiteten Daten zu prüfen.

Hätte eine sichere npm-Registry die „Third Coming“-Kampagne von Shai-Hulud verhindern können?

Das ist möglich, vorausgesetzt, die Registrierungsstelle prüft den Inhalt unabhängig von der Identität des Herausgebers. Ob die bösartige Veröffentlichung selbst eine gültige Bescheinigung enthielt, wurde nie geklärt, sodass man sich hier nicht allein auf identitätsbasierte Prüfungen verlassen kann. Ein Überprüfungsschritt, bei dem der Inhalt einer Veröffentlichung analysiert wird – beispielsweise ein neuer Build-Hook, verschleierter Code oder Dateien ohne entsprechenden Commit –, kann dies unabhängig vom Inhalt einer Bescheinigung erkennen. Miasma ist das anschaulichere Beispiel für denselben Fehlermodus, da diese Veröffentlichungen eine gültige, signierte SLSA-Herkunftsangabe enthielten.

Hätte ein Quarantänefenster Axios aufgehalten?

Ja. Die schädlichen Versionen waren etwa drei Stunden lang online und wurden dann entfernt. Eine eintägige Verzögerung bei der Übernahme – die kürzeste, die npm zulässt – hätte also dafür gesorgt, dass sie während ihrer gesamten schädlichen Lebensdauer unzulässig geblieben wären, ohne dass etwas als schädlich identifiziert werden musste. Diese Sperre ist die Einstellung „min-release-age“, die einen Wert in Tagen annimmt und npm 11.10.0 oder neuer erfordert, da ältere Clients sie stillschweigend ignorieren. Sie regelt die Auflösung von Abhängigkeiten und dient nicht als nachträgliche Überprüfung; daher stellt eine schädliche Version, die bereits in einer festgeschriebenen Lockdatei fixiert ist, ein separates Problem dar.

Was ändert sich im Alltag eigentlich durch einen Ersatz für die npm-Registry?

Vor allem, woher Installationsbefehle ihre Werte beziehen. package.json und die meisten Arbeitsabläufe bleiben unverändert. package-lock.json muss einmal neu generiert werden, da sowohl die aufgelöste URL als auch der darin enthaltene Integritäts-Hash auf Elemente aus der alten Registrierungsdatenbank verweisen.

Wird die Sicherheit einer privaten npm-Registry allein dadurch gewährleistet, dass man eine private Registry einrichtet?

Nicht von allein. Ein Caching-Proxy bietet Ihnen zwar einen Kontrollpunkt für die Herkunft der Pakete, doch ein solcher Kontrollpunkt allein garantiert noch nicht, dass die Daten, die ihn passieren, vertrauenswürdig sind. Ob Installationen tatsächlich sicherer werden, hängt davon ab, was an diesem Kontrollpunkt ausgeführt wird und ob auch die Umgehungswege abgesperrt sind. Die übliche Sicherheitslücke besteht nach wie vor darin, dass CI-Prozesse weiterhin direkt aus dem öffentlichen Register beziehen.

Zusammenfassung

Artikel Name

Sichere npm-Registry, getestet mit axios und Shai-Hulud

Beschreibung

Hätte eine sichere npm-Registry Axios, Jscrambler, Shai-Hulud und Miasma verhindern können? Die Kontrollmechanismen von SecureChain, zugeordnet zu den einzelnen Mechanismen.

Autor

Artem Karasev

Name des Herausgebers

TuxCare

Logo des Herausgebers