Ein vertrauter Produktname belegt keinen Herausgeber
Auf dem Paket steht Claude. Wer darf danach Code auf Ihrem Rechner ausführen? Die sichere Installation von KI-Programmierwerkzeugen beginnt damit, diese Beziehung zu belegen, bevor das Werkzeug Zugriff auf Repository oder Zugangsdaten erhält. Ein npm-Name, eine überzeugende Beschreibung und ein bekannter Produktbegriff belegen keine Freigabe durch dessen Hersteller.
Am 19. Oktober 2026 veröffentlichte GitHub Malware-Advisories für die acht unten aufgeführten npm-Paketnamen mit KI-Bezug. Diese Hinweise sind Anlass, eine Installation zu untersuchen. Sie belegen keine Kompromittierung der offiziellen Produkte Claude, Codex oder ChatGPT. Dieser Leitfaden nutzt Advisory-Daten und offizielle Dokumentation; er behauptet weder eine Malware-Analyse noch die Ausführung einer Probe. [1][2][3]
Flagged package names; do not install
claude-desktop-setup @decoopus/claude-setup
codex-setup chatgpt-desktop-setup
@decoopus/chatgpt-setup chatgpt-pro-activator
chatgpt-pro-setup-tool api-anthropicDie Entfernung aus dem Register erklärt den Payload nicht
Die geprüften Advisories kennzeichnen Malware, liefern für diese Gruppe aber keine Verhaltensanalyse. Die hier betrachteten Quellen belegen am 20. Oktober weder gelesene Dateien noch einen gezielt angegriffenen Zugangsdaten-Speicher oder eingerichtete Persistenz. Eine Infostealer-Familie zu nennen würde die Lücke mit einer Geschichte statt mit Belegen füllen. Das gemeinsame Thema beweist auch keinen gemeinsamen Betreiber. [1][2][3]
Downloadzahlen lösen dieses Problem nicht. Ein Download kann automatisiert, wiederholt oder zu Analysezwecken erfolgen. Er ist keine bestätigte Ausführung und kein betroffener Mensch. Für die eigene Exposition zählen eher das genaue Paket samt Version in Installationsnachweisen, die Installationsumgebung und eine Ausführung mit Zugriff auf wertvolle Daten. Halten Sie unbekannte Ausführung als unbekannt fest, statt fehlende Telemetrie als Sicherheitsbeweis zu behandeln.
Beginnen Sie beim Hersteller und folgen Sie dem Vertriebsweg
Anthropic dokumentiert für Claude Code die offizielle npm-Identität @anthropic-ai/claude-code und bietet auch native Installationswege an. Ein ähnlich benanntes Setup-Paket erbt diese Beziehung nicht. Das Verfahren gilt für jedes Werkzeug: Beginnen Sie auf der dokumentierten Installationsseite des Herstellers und folgen Sie dem genauen Kanal für Ihre Plattform, statt ein Paket aus einem Suchergebnis auszuwählen. [4]
Der betriebliche Prozess sollte die geprüfte Wahl leicht wiederholbar machen. Erfassen Sie Dokumentations-URL, Vertriebskanal, erwarteten Herausgeber, gewählte Version und Update-Verantwortlichen in einem kurzen Freigabenachweis. Paket-Pinning macht die gewählten Bytes oder Versionen reproduzierbar, belegt aber nicht die Legitimität der ursprünglichen Auswahl. Prüfen Sie auch den Update-Pfad: Die nächste Installation kann erfolgen, ohne dass erneut jemand einen Befehl kopiert.
Proposed approved-tool record
Vendor documentation URL -> exact distribution identity
Version + platform -> expected artifact
Publisher / signing key -> trust anchor
Artifact hash -> recorded bytes
Update mechanism -> owner and review policy
Runtime permissions -> separately approved accessEine Prüfsumme benötigt einen vertrauenswürdigen Vergleichswert
Eine Prüfsumme belegt die Übereinstimmung von Bytes und erwartetem Hash. Liefert ein nicht vertrauenswürdiger Distributor beides, ist damit der Hersteller nicht geklärt. Anthropic dokumentiert signierte Release-Manifeste ab Claude Code 2.1.89; ältere Manifeste enthalten Prüfsummen ohne diese separate Signatur. Prüfen Sie das Manifest anhand des dokumentierten Schlüsselfingerabdrucks und vergleichen Sie danach das Plattform-Binary mit dem authentifizierten Manifest. [4]
Die dokumentierten nativen Windows-Binaries tragen zusätzlich eine Authenticode-Signatur. Die folgenden Prüfkommandos führen die Datei nicht aus. Prüfen Sie sowohl Signaturgültigkeit als auch den erwarteten Herausgeber Anthropic, PBC; ein beliebiger gültiger Unterzeichner genügt nicht. Dies sind dokumentierte Prüfschritte, kein Bericht über ein für diesen Artikel heruntergeladenes oder geprüftes Binary. [4]
# Inspect an already-downloaded binary; do not execute it
Get-AuthenticodeSignature -LiteralPath .\claude.exe |
Select-Object Status, SignerCertificate
Get-FileHash -LiteralPath .\claude.exe -Algorithm SHA256
# Compare signer and hash with the vendor's documented trust chain.Verifizierte Herkunft ersetzt keine Rechteentscheidung
Signaturen und Provenance beantworten Herkunftsfragen. Sie beweisen weder die Abwesenheit schädlichen Verhaltens noch die von Schwachstellen. npm erklärt das für Provenance ausdrücklich: Sie verbindet ein Paket mit Quellcode und Build-Informationen zur Prüfung, statt Harmlosigkeit zu bescheinigen. Nutzen Sie das Ergebnis als einen Beleg zum Artefakt, nicht als Grund, ihm sämtliche Zugangsdaten des Rechners zu überlassen. [5]
Meine nächste Frage lautet, was das installierte Programm erreichen kann. Prüfen Sie bei einem freigegebenen Werkzeug Repository-Inhalte, Umgebungsvariablen, Zugangsdaten-Speicher und den Netzwerkzugriff seines Prozesses. Trennen Sie Entwicklungszugriff von Produktivzugangsdaten und vergeben Sie zusätzliche Rechte bewusst. Diese Empfehlung betrifft Ausführungsbefugnisse allgemein. Sie behauptet keine bestimmte Sammlungstechnik der entfernten Pakete.
Ist eine CLI ohne Installationsskripte sicher?
npm unterdrückt mit ignore-scripts package.json-Skripte während der Installation. Laut Dokumentation führen explizit angeforderte Skripte wie npm run ihren vorgesehenen Befehl aber weiterhin aus. Das ist keine Sandbox für ein später gestartetes Programm. Ein Team, das Lifecycle-Skripte blockiert und anschließend eine ungeprüfte CLI startet, trifft eine weitere Ausführungsentscheidung. Bewerten Sie diese separat. [6]
Auch legitime Pakete können Installationsschritte benötigen. Die Kompatibilitätskosten sind real. Die Antwort ist eine ausdrücklich geprüfte Ausnahme mit Begründung, keine globale Abschaltung wegen eines scheiternden Werkzeugs. Unterscheiden Sie im Freigabenachweis Metadatenprüfung, Installation und Ausführung. Jeder Schritt liefert andere Belege und kann andere Fähigkeiten freigeben; keiner sollte unbemerkt für den nächsten stehen.
Sichern Sie Belege, wenn ein gemeldetes Paket installiert wurde
Die Malware-Advisories empfehlen, einen Rechner mit installiertem Paket als kompromittiert zu behandeln und offengelegte Secrets von einem anderen Computer aus zu rotieren. Setzen Sie diese Empfehlung mit Ihrem Incident-Team um: Umgebung isolieren, Installations- und Prozessnachweise sichern und erreichbare Zugangsdaten bestimmen. Die bloße Paketentfernung beweist nicht, dass entstandener Zugang oder Persistenz beseitigt sind. [1][2]
Das ist bewusst keine Behauptung über einen bestimmten Payload. Sie können Eindämmung ernst nehmen und zugleich präzise beim Unbekannten bleiben. Bewahren Sie Paketkennungen und Versionen zusammen mit Ausführungsnachweisen und geprüften Zugangsdaten im Fallprotokoll auf. Kopieren Sie keine aktiven Secret-Werte in Tickets und erzeugen Sie Ersatz nicht auf einem nicht vertrauenswürdigen Arbeitsplatz.
Machen Sie Installation zu einer Engineering-Entscheidung
Ich würde ein Team bitten, für ein freigegebenes Werkzeug eine vollständige Kette zu zeigen: Der Hersteller verweist auf diesen Kanal, das Artefakt entspricht diesem authentifizierten Release und der Prozess erhält diesen dokumentierten Zugriff. Ein anderer Entwickler kann diese Kette prüfen. Ein Screenshot eines vertrauten Logos oder ein Downloadzähler ersetzt sie nicht.
Das ist sichere Softwareentwicklung, weil diese Entscheidungen in Onboarding, CI und Update-Automatisierung eingehen. Muss jeder Entwickler die Vertrauensentscheidung allein rekonstruieren, hat das Unternehmen eine wiederholbare Sicherheitskontrolle an ein Suchergebnis delegiert. Bauen Sie den geprüften Weg einmal, benennen Sie seinen Eigentümer und begrenzen Sie die Ausführungsrechte auf einen begründbaren Umfang.
Quellen
Soll das auch in Ihrem Produkt geprüft werden?
Individuelle Software- & Website-Entwicklung