Hey, ich bin Marcel, und wenn ihr mich bereits kennt, wisst ihr, dass ich doch eher pessimistisch durchs Leben schreite. Falls ihr euch also erhofft, in diesem Meinungsbeitrag ein Happy End zu finden — wie wir als Entwickler:innen mit der neuen Geschwindigkeit von Supply-Chain-Angriffen, Kernel-Exploits und KI-gestützter Schwachstellensuche umgehen sollen — muss ich euch enttäuschen.
Was im Titel nach Clickbait klingt ist die Realität von vielen Entwickler:innen derzeit da draußen. Falls ihr nicht so tief in den Hacker News drin seid, hier ein paar Beispiele der letzten Wochen:
Copy_Fail: Vier Bytes zu Root auf Linux
Der Copy_Fail-Exploit, veröffentlicht auf copy.fail, beschreibt eine lokale Privilegieneskalation im Linux-Kernel. Ein nicht-privilegierter Benutzer kann gezielt vier Bytes in den Page Cache einer beliebigen lesbaren Datei schreiben und sich darüber Root-Rechte verschaffen. Der Angriff setzt lokalen Zugriff voraus, ist aber für Multi-User-Systeme, Container-Hosts und Shared Hosting kritisch. Wer Linux-Server betreibt, sollte Kernel-Updates der Distribution zeitnah einspielen.
Copy_Fail 2 (Electric Boogaloo): MSG_SPLICE_PAGES als Einfallstor
Die Fortsetzung Copy_Fail2 nutzt eine Schwachstelle im Verarbeitungsablauf von MSG_SPLICE_PAGES. Auch hier reicht ein lokaler Benutzer ohne Sonderrechte aus, um Inhalte im Page Cache lesbarer Dateien zu manipulieren und am Ende Root-Privilegien zu erlangen. Die Angriffsklasse ist dieselbe wie bei Copy_Fail — der Einstiegspunkt ein anderer. Das zeigt: Eine einzelne Patch-Runde reicht oft nicht, wenn die zugrundeliegende Page-Cache-Logik mehrere angreifbare Pfade hat.
Shai-Hulud bei TanStack: 84 kompromittierte npm-Pakete in sechs Minuten
Am 11. Mai 2026 traf eine neue Welle der „Mini Shai-Hulud"-Kampagne den npm-Maintainer TanStack. Laut Socket veröffentlichten die Angreifer innerhalb von rund sechs Minuten 84 bösartige Paket-Artefakte über 42 @tanstack/*-Pakete — darunter @tanstack/react-router mit über 12 Millionen wöchentlichen Downloads. Die Gruppe TeamPCP nutzte eine Kette aus drei GitHub-Actions-Schwachstellen: einen „Pwn Request" über pull_request_target, Cache Poisoning über die Fork-Vertrauensgrenze und Memory-Extraktion eines OIDC-Tokens aus dem Actions-Runner-Prozess.
Die Malware exfiltriert über drei redundante Kanäle (Typosquat-Domain, Session-Messenger, GitHub-API-Dead-Drops) Anmeldedaten, Cloud-Tokens, SSH-Keys und CI/CD-Secrets. Besonders heikel: Die kompromittierten Pakete tragen valide SLSA-Build-Level-3-Provenance-Attestierungen — der erste dokumentierte npm-Wurm, dessen Schadpakete von echten Paketen kryptografisch nicht zu unterscheiden sind. Betroffen waren laut Wiz auch Pakete von UiPath, Mistral AI, Guardrails AI und OpenSearch. Die Quintessenz für Teams: Lockfiles mit Integritäts-Hashes pinnen, Cooldown-Fenster für neue Paketversionen aktivieren und Sigstore-Provenance nicht als alleiniges Sicherheitssignal behandeln.
Quarkus-Bypass: Autorisierung umgehen mit einem Semikolon
Die GHSL-2026-099 im Java-Framework Quarkus erlaubt es Angreifern, pfadbasierte Autorisierungsregeln zu umgehen. Indem ein Semikolon und beliebiger Text an eine geschützte URL angehängt werden, kann eine eigentlich gesicherte Route wie /api/admin über /api/admin;bypass ohne ordnungsgemäße Authentifizierung erreichbar werden. Die Ursache liegt in unterschiedlicher Behandlung von Path-Parametern zwischen Routing- und Autorisierungs-Layer — eine Klasse von Fehlern, die historisch auch Tomcat, Spring und andere JVM-Stacks getroffen hat. Wer Quarkus produktiv einsetzt, sollte auf die gepatchte Version aktualisieren und Autorisierungsregeln zusätzlich auf Handler-Ebene durchsetzen, nicht nur per Routing-Konfiguration.
Dirtyfrag: Privilegieneskalation über den Netzwerk-Stack des Kernels
Dirtyfrag ist eine weitere lokale Linux-Privilegieneskalation, die Fehler im Page Cache der Netzwerkkomponenten des Kernels ausnutzt. Auch hier reicht ein Benutzer mit minimalen Berechtigungen, um Root zu werden. Der Name spielt auf die Dirty-Pipe- und Dirty-Cow-Klassiker an und ordnet den Exploit in dieselbe Familie ein: Memory-Management-Bugs, die seit Jahren immer wieder neue Varianten hervorbringen. Für Betreiber gilt dieselbe Empfehlung wie bei Copy_Fail — Kernel-Updates priorisieren, besonders auf Mehrbenutzer- und Container-Systemen.
GitHub kompromittiert: Bösartige VS-Code-Extension als Einfallstor
Laut GitHub Security wurde ein Entwickler-Rechner intern bei GitHub über eine bösartige VS-Code-Erweiterung kompromittiert. Die Angreifer konnten in der Folge Tausende interne GitHub-Repositories kopieren. Der Vorfall verdeutlicht zwei Punkte: Erstens sind Editor-Extensions ein unterschätzter Supply-Chain-Vektor mit oft weitreichenden Berechtigungen. Zweitens reicht ein einziger kompromittierter Entwickler-Account aus, um Quellcode im großen Stil abzuziehen — selbst bei einem Plattformbetreiber, der Security zum Kerngeschäft macht. Teams sollten Extensions kuratieren, Auto-Updates kritisch prüfen und Repository-Zugriffe nach dem Least-Privilege-Prinzip einschränken.
Und das sind nur die Berichte die schon öffentlich sind. Erst vor kurzem gab Anthropic bekannt (https://www.anthropic.com/research/glasswing-initial-update) dass Partner mithilfe von Claude Mythos Preview im Rahmen von Project Glasswing bereits über 10.000 Schwachstellen mit hoher oder kritischem Schweregrad gefunden hat. Es bleibt abzuwarten ob, das alles ein riesiger Marketing Stunt ist um die Leute zu überzeugen für das nächste Model dann noch tiefer in die Tasche zu greifen oder ob das wirklich die Realität ist. Unrealistisch ist es nicht, da jede:r Entwickler:in weiß dass sie nicht unfehlbar ist. Von Junior bis Senior hat jeder in seinem Leben Schwachstellen erzeugt und vergessen. Die Frage ist nur, wie wir damit nun umgehen, dass es nicht mehr Monate braucht um eine Schwachstelle zu finden und auszunutzen sondern Stunden bis Tage. Was passiert wenn wir nur noch damit beschäftigt sind die Löcher zu stopfen anstatt Features zu entwickeln? Das sind alles Fragen, die wir uns auch bei farbenmeer stellen, und wir haben noch keine zufriedenstellende Antwort darauf — außer eine Reihe von Sicherheitsvorkehrungen, die in Summe das Risiko reduzieren, auch wenn sie keine einzelne große Lösung sind.
Cooldown-Fenster für neue Paketversionen. Wir lassen neue Releases drei Tage altern, bevor sie in unsere Builds wandern. Das ist ein Kompromiss: Lang genug, um schnell entdeckte Vorfälle wie den TanStack-Angriff abzufangen, kurz genug, um wichtige Sicherheits-Patches nicht zu verzögern. Wer auf Nummer sicher gehen will, geht auf 7 bis 14 Tage — das ist die gängige Empfehlung nach den Shai-Hulud-Wellen.
Lockfiles mit Integritäts-Hashes pinnen. Egal ob package-lock.json, pnpm-lock.yaml, yarn.lock oder bun.lock — alle modernen Package Manager schreiben kryptografische Hashes für jede installierte Version in ihre Lockfile. Wenn die Hashes im CI gegen Mismatches geprüft werden, fällt eine nachträglich manipulierte Paketversion auf, bevor sie ins Build wandert.
Restriktivere OIDC-Token-Scopes in der CI. Der TanStack-Angriff funktionierte, weil ein OIDC-Token mit weitreichenden Rechten im Speicher des Actions-Runners lag. Wir setzen permissions: id-token: none als Default in unseren Workflows und erlauben id-token: write nur im konkreten Publish-Job. Das reduziert die Angriffsfläche drastisch.
Kuratierte Editor-Extensions. Der GitHub-Vorfall hat gezeigt, wie viel eine einzelne bösartige VS-Code-Erweiterung anrichten kann. Wir führen eine interne Liste freigegebener Extensions, prüfen Auto-Updates und behandeln Editor-Plugins mit der gleichen Sorgfalt wie produktive Dependencies.
Least-Privilege für Entwickler-Accounts. Entwickler-Maschinen haben historisch viel zu breite Berechtigungen — Cloud-Tokens, Production-Zugänge, Repository-Schreibrechte für alles. Wir trennen das stärker auf, nutzen kurzlebige Tokens und prüfen regelmäßig, was wirklich gebraucht wird.
Längere Reviews mit AI-Unterstützung. Wir setzen KI-Tools nicht ein, um Reviews zu beschleunigen, sondern um sie zu vertiefen. Ein zweites Augenpaar, das systematisch nach den Mustern sucht, die menschliche Reviewer übersehen — Path-Traversal-Tricks, Race Conditions, ungeprüfte Eingaben in dynamischen Imports.
Keine dieser Maßnahmen ist allein ausreichend. Aber zusammen verschieben sie das Risiko von „eine einzige unglückliche Verkettung reicht aus" zu „mehrere Schichten müssten gleichzeitig versagen". Das ist der einzige realistische Schutz, solange Angreifer schneller werden als die Patches.
Zum Schluss noch ein Zitat aus einem Deep Rabbit Hole auf Reddit, für das ihr den Aluhut aufsetzen müsst.
Was wäre wenn die großen IT Security Modelle wie Claude Mythos und Co. einfach das Ende eines kapitalistischen Kreislaufs sind? Claude Code möchte seinen Job als Entwickler:in behalten und baut bewusst Fehler in den Code ein und Claude Mythos findet diese und gibt sie Claude Code zum Auftrag zu fixen, der wieder Fehler einbaut. Wäre das nicht eine mega gute Marktstrategie?
Viel Spaß im Rabbit hole und vergesst nicht eure Packages zu aktualisieren... aber auch nicht zu oft weil kann ja auch kompromittiert sein.
