Cybersecurity im April 2026: Red-Team-Analyse für Unternehmen


Der April 2026 war ein Monat, in dem Cybersicherheit wieder aus Präsentationen heraus und in den normalen Unternehmensalltag hineinrutschte. Nicht durch einen einzigen spektakulären Angriff, sondern durch mehrere technische Brüche, die aus Angreifersicht sofort Sinn ergeben. Lokale Rechteausweitung unter Linux. Kompromittierte npm-Pakete. Ein KI-Gateway mit gespeicherten Provider-Schlüsseln. Eine Entwicklerplattform, die vertrauenswürdigen Code verarbeitet. OAuth-Berechtigungen, die wie eine harmlose Produktivitätsintegration wirkten.

Für Haxoris ist genau das der Stoff, der in Red-Team-Übungen, Penetrationstests und Angriffsflächenanalysen zählt. Entscheidend ist nicht nur, dass eine weitere Schwachstelle existiert. Entscheidend ist, wie sie sich mit Cloud-Security, CI/CD-Sicherheit, Identitäts- und Zugriffsmanagement, KI-Sicherheit, Incident Response und Cyber Resilience verbindet. Der April hat gezeigt, dass moderne Angriffe selten wie Filmszenen beginnen. Sie beginnen in normalen Arbeitsabläufen, denen Unternehmen mehr Vertrauen geben, als ihnen guttut.

29. April

Copy Fail: wenn aus einem schwachen lokalen Konto root wird

Das Xint Code Research Team veröffentlichte Copy Fail, eine Schwachstelle mit der Kennung CVE-2026-31431. Es handelt sich um einen Logikfehler im Linux-Kernel, konkret in der kryptografischen Vorlage authencesn. Ein lokaler Nutzer ohne besondere Rechte kann dadurch einen kontrollierten Vier-Byte-Schreibvorgang in den Page Cache einer lesbaren Datei auslösen.

Die Forscher zeigten, dass ein kurzer Python-Nachweiscode ein setuid-Binary nur im Arbeitsspeicher verändern und dadurch root-Rechte erlangen kann. Getestet wurden große Distributionen wie Ubuntu, Amazon Linux, RHEL und SUSE.

Besonders interessant ist nicht nur die Rechteausweitung selbst. Der Schreibvorgang erscheint nicht wie eine normale Dateiänderung auf der Festplatte. Die beschädigte Seite wird nicht für das Zurückschreiben markiert. Dadurch kann die Datei auf der Festplatte unverändert aussehen, während sich ihre Version im Speicher bereits anders verhält. Ein einfacher Vergleich von Prüfsummen zeigt dann möglicherweise nichts Verdächtiges.

In offensiven Sicherheitstests ist das genau die Art von Schwachstelle, die aus einem kleinen Zugriff die Kontrolle über einen Host macht. Ein Angreifer muss nicht als Administrator starten. Ein kompromittierter Nutzer, eine Web-Shell, ein schwaches Dienstkonto oder Zugriff auf einen Container kann genügen. Die lokale Rechteausweitung wird dann zur Brücke zwischen dem ersten Zugriff und der Kontrolle über den Host.

Wichtig ist auch die Container-Perspektive. Der Page Cache wird von Prozessen auf dem Host gemeinsam genutzt, und laut Xint betrifft die Schwachstelle auch Containergrenzen. Das bedeutet nicht, dass jeder Container mit einem einzigen Befehl automatisch fällt. Es bedeutet aber, dass der Satz „das läuft nur in einem Container“ keine Sicherheitsstrategie ist.

Mini Shai-Hulud: wenn eine normale Installation von Abhängigkeiten Zugangsdaten sammelt

Wiz veröffentlichte eine Analyse der Kampagne Mini Shai-Hulud. Sie traf legitime Pakete im SAP-Ökosystem des npm-Registers. Die Angreifer fügten in Pakete wie @cap-js/sqlite, @cap-js/postgres, @cap-js/db-service und mbt ein schädliches Preinstall-Skript ein, das automatisch während einer gewöhnlichen Installation von Abhängigkeiten ausgeführt wurde.

Genau das ist der Kern des Falls. Der Entwickler musste nichts Auffälliges tun. Keine Raubkopie, kein verdächtiger Anhang, keine gefälschte Anmeldeseite. Er tat genau das, was er jeden Tag tut: Abhängigkeiten installieren und ein Projekt bauen.

Laut Wiz lud der Schadcode die Laufzeitumgebung Bun herunter und führte anschließend einen Dieb für Zugangsdaten aus. Ziel waren GitHub-Token, npm-Zugangsdaten, Cloud-Geheimnisse für AWS, Azure und GCP, Kubernetes-Token sowie Geheimnisse aus GitHub Actions. Die Daten wurden über von den Angreifern kontrollierte GitHub-Repositories ausgeschleust. Außerdem enthielt der Code Logik zur weiteren Verbreitung über kompromittierte Token.

Für Unternehmen ist das eine sehr praktische Lehre. Build- und Deployment-Automatisierung ist kein Nebentool irgendwo im Hintergrund. Häufig ist es die Umgebung, die die wertvollsten Zugangsdaten im gesamten Unternehmen besitzt. Sie hat Zugriff auf Quellcode, Container-Registries, Cloud-Umgebungen, Kubernetes, Produktionsdeployments und manchmal auch Kundendaten.

Die Frage lautet daher nicht nur: „Verwenden wir sichere Pakete?“ Die Frage lautet: Wenn ein schädliches Paket in Ihrem Build-Prozess ausgeführt wird, was kann es lesen? Wenn die Antwort „fast alles“ lautet, ist nicht nur das Paket das Problem. Das Problem ist, dass die Automatisierung mehr Vertrauen besitzt, als sie wirklich benötigt.

LiteLLM: ein KI-Gateway als Tresor für fremde Schlüssel

LiteLLM musste eine kritische Schwachstelle mit der Kennung CVE-2026-42208 beheben. Das belgische Zentrum für Cybersicherheit beschrieb das Risiko sehr direkt: LiteLLM fungiert als Gateway für künstliche Intelligenz und zentralisiert Zugangsdaten zu Anbietern wie OpenAI oder Anthropic. Eine erfolgreiche Ausnutzung kann daher bedeuten, dass alle angebundenen KI-Anbieter-Konten auf einmal verloren gehen.

Die technische Ursache war unangenehm einfach. Der Wert eines Zugriffstokens aus einer HTTP-Anfrage konnte ohne ausreichende Bereinigung in eine Datenbankabfrage gelangen. Ein Angreifer konnte das Problem vor der Anmeldung ausnutzen und auf gespeicherte Anwendungsschlüssel, Zugangsdaten von Anbietern und weitere sensible Daten in der Datenbank zugreifen.

Das ist für jedes Unternehmen relevant, das künstliche Intelligenz einführt. Ein solches Gateway ist kein experimentelles Werkzeug am Rand der Infrastruktur. Sehr schnell wird es zu einem zentralen Speicher für Anwendungsschlüssel, Abrechnungsidentitäten, Nutzungsregeln, Anfrageprotokolle und manchmal auch interne Daten.

In einem Red-Team-Einsatz würde eine solche Komponente sofort unsere Aufmerksamkeit bekommen. Nicht, weil künstliche Intelligenz ein Trendthema ist, sondern weil neue Werkzeuge in Unternehmen oft schneller eingeführt werden, als ihr Sicherheitsmodell entsteht. Wo liegen die Schlüssel? Wer kann sie lesen? Was wird protokolliert? Lässt sich Zugriff schnell entziehen? Hat jeder Anbieter ein eigenes Konto und eigene Limits? Genau diese Antworten entscheiden, ob ein Vorfall lokal bleibt oder zu einer breiteren Cloud-Kompromittierung wird.

28. April

GitHub: auch ein gewöhnlicher Entwicklerbefehl kann serverseitig gefährlich werden

GitHub veröffentlichte eine Analyse einer kritischen Schwachstelle in dem Teil der Infrastruktur, der git push verarbeitet. Gemeldet wurde der Fehler von Forschern von Wiz über das Bug-Bounty-Programm. GitHub reproduzierte ihn nach eigener Darstellung innerhalb von vierzig Minuten, behob ihn auf GitHub.com in weniger als zwei Stunden und fand in der forensischen Analyse keine Hinweise auf Ausnutzung.

Der Kern des Fehlers war ernst. Ein Nutzer mit Berechtigung, Änderungen in ein Repository zu senden, auch in ein selbst erstelltes Repository, konnte die Ausführung von Befehlen auf dem Server auslösen, der diesen Push verarbeitete. Eine speziell präparierte Push-Option genügte, um eine unzureichende Zeichenbereinigung auszunutzen.

Für ein normales Unternehmen ist die größere Aussage entscheidend. GitHub, GitLab, Bitbucket oder interne Code-Repositories sind längst nicht mehr nur Orte zur Ablage von Quellcode. Sie sind Knotenpunkte, an denen Identität, Automatisierung, Freigaben, Geheimnisse, Builds, Tests, Deployments und Auditspuren zusammenlaufen.

Die Angriffsfrage lautet: Was passiert im Unternehmen nach einem erfolgreichen Push? Startet ein Build? Werden sensible Variablen geladen? Wird ein Artefakt erzeugt? Wird eine Änderung in die Cloud ausgerollt? Hat der Build-Worker Zugriff auf die Produktion? Jede dieser Antworten macht aus einem alltäglichen Entwicklungsschritt eine Sicherheitsentscheidung.

cPanel und WHM: ein Administrationspanel als Schlüssel zu mehreren Türen

cPanel veröffentlichte eine Sicherheitsmeldung zu CVE-2026-41940. Es handelte sich um eine Schwachstelle, die eine Umgehung der Anmeldung in cPanel & WHM sowie DNSOnly ermöglichte. Laut cPanel waren Versionen nach 11.40 betroffen, und für mehrere unterstützte Zweige wurden korrigierte Builds veröffentlicht.

Als Notmaßnahme empfahl cPanel, eingehenden Verkehr auf den Ports 2083, 2087, 2095 und 2096 zu blockieren oder betroffene Dienste vorübergehend zu stoppen, falls eine sofortige Aktualisierung nicht möglich war.

Auf den ersten Blick wirkt das wie ein Problem von Hosting-Anbietern. Tatsächlich betrifft es jeden, der über ähnliche Panels Websites, E-Mail, Domains, Zertifikate oder Kundenportale verwaltet. WHM ist eine Steuerungsebene. Wenn ein Angreifer die Anmeldung umgeht, geht es nicht nur um die Kompromittierung einer einzelnen Website. Es kann um Zugriff auf Kontoverwaltung, Domains, Postfächer, Zertifikate und manchmal auch Serverinfrastruktur gehen.

In Unternehmenstests zeigen sich solche Panels immer wieder als unterschätzte Netzwerkgrenzen. Die Hauptanwendung wird geschützt, während die Verwaltungsoberfläche des Hostings, ein altes Kundenportal oder eine DNS-Konsole daneben liegen bleiben. Angreifer unterscheiden aber nicht zwischen „Hauptsystem“ und „Hilfswerkzeug“. Sie unterscheiden nur, was ihnen mit dem geringsten Aufwand die meisten Rechte verschafft.

24. April

UNC6692: falscher IT-Support, Teams und eine schädliche Browser-Erweiterung

Google Cloud und Mandiant beschrieben eine Kampagne der Gruppe UNC6692, die sehr gut zeigt, wie modernes Social Engineering im Unternehmen aussieht. Die Angreifer überfluteten das Ziel zunächst mit E-Mails, um Druck und Verwirrung zu erzeugen. Danach kontaktierten sie den Nutzer über Microsoft Teams als angeblicher technischer Support und boten eine „Lösung“ an.

Der Nutzer wurde auf eine Seite geleitet, die wie ein Tool zur Reparatur des Postfachs aussah. Von dort wurden eine umbenannte AutoHotKey-Datei und ein Skript heruntergeladen. Das Skript führte Systemaufklärung durch und installierte SNOWBELT, eine schädliche Erweiterung für Chromium-basierte Browser. Anschließend setzten die Angreifer weitere Werkzeuge ein, führten interne Aufklärung durch, bewegten sich lateral, sammelten Zugangsdaten und griffen auf Domänencontroller zu.

Wichtig ist, dass der Angriff nicht wie eine klassische Phishing-Mail aussah. Er sah aus wie ein interner Supportprozess. Das Problem lag nicht nur beim Nutzer. Das Unternehmensumfeld konnte nicht klar genug unterscheiden, wer echter Support ist, wie dessen Identität geprüft wird und was Mitarbeitende niemals auf Basis einer Chatnachricht installieren sollten.

Aus Haxoris-Sicht ist das ein hervorragendes Szenario für eine offensive Sicherheitsübung. Nicht „klicken Sie auf diese falsche E-Mail“, sondern eine realistische Kette: Überlastung, Stress, Chat über eine Unternehmensplattform, falscher Support, lokale „Reparatur“, schädliche Browser-Erweiterung, Netzwerkaufklärung und der Versuch, sensible Systeme zu erreichen.

22. April

Lovable: ein öffentliches Projekt bedeutet nicht nur eine öffentliche Anwendung

Lovable veröffentlichte eine Reaktion auf den Vorfall im April, nachdem ein Sicherheitsforscher darauf hingewiesen hatte, dass Daten in öffentlichen Projekten möglicherweise für jeden angemeldeten Nutzer zugänglich waren. Das Unternehmen gab an, die Korrektur innerhalb von zwei Stunden ausgerollt zu haben. Gleichzeitig räumte es ein, dass sowohl das Produkt als auch die erste Kommunikation die Situation nicht gut behandelt hatten.

Laut Lovable konnten zwischen dem 3. Februar und dem 20. April 2026 bei öffentlichen Projekten potenziell Gesprächsverläufe und Quellcode zugänglich sein. Private Projekte und Lovable Cloud waren nach Angaben des Unternehmens nicht betroffen. Das Problem entstand durch eine Kombination aus dem historischen Modell öffentlicher Projekte, späteren Änderungen der Sichtbarkeit und einem Backend-Fehler vom Februar, der den Zugriff auf Dinge wieder öffnete, die nicht mehr öffentlich sein sollten.

Das ist nicht nur die Geschichte eines KI-Werkzeugs zur Erstellung von Anwendungen. Es ist ein größeres Problem rund um das Wort „öffentlich“. Viele Nutzer verstehen eine öffentliche Anwendung so, dass die fertige Website für jeden erreichbar ist. Sie verstehen es nicht als Zugriff auf den Editor, Gespräche mit der KI, Quellcode, Arbeitsnotizen oder Integrationsdetails.

Ein Angreifer interessiert sich nicht dafür, wie der Nutzer die Einstellung versteht. Er interessiert sich dafür, was die Schnittstelle zurückgibt. Wenn ein solches Projekt Verweise auf Datenbanken, Zahlungsanbieter, Programmierschnittstellen, interne Endpunkte oder Konfigurationsfragmente enthält, kann eine schlecht entworfene Sichtbarkeit zu einer sehr praktischen Quelle für weitere Angriffe werden.

Die Lehre für Unternehmen ist einfach: Bei KI-Werkzeugen reicht es nicht, nur die fertige Anwendung zu schützen. Geschützt werden müssen auch Gespräche, Entwürfe, generierter Arbeitscode, Konzepte und alles, was Nutzer als „nur den Entstehungsprozess“ betrachten. Auch der Entstehungsprozess kann sensible Informationen enthalten.

19. April

Vercel und Context.ai: ein Zugriffstoken als stille Eintrittskarte

Vercel veröffentlichte einen Sicherheitsvorfall, der nicht mit einem direkten Angriff auf die Kerninfrastruktur begann. Laut Vercel entstand der Vorfall über die Kompromittierung eines Drittanbieters, konkret des Werkzeugs Context.ai, das von einem Mitarbeitenden genutzt wurde. Der Angreifer verwendete diesen Zugriff anschließend, um ein individuelles Konto im Google Workspace des Unternehmens zu übernehmen, auf das Vercel-Konto des Mitarbeitenden zuzugreifen und sich weiter im internen Umfeld zu bewegen.

Vercel gab an, dass der Angreifer nicht sensible Umgebungsvariablen auf der Plattform aufzählte und entschlüsselte. Gleichzeitig empfahl das Unternehmen, Werte zu rotieren, die nicht als sensibel markiert waren, weil auch eine „nicht sensible“ Variable in der Praxis ein Token, einen Anwendungsschlüssel, Datenbankzugangsdaten oder einen Signaturschlüssel enthalten kann.

Das ist ein gutes Beispiel dafür, warum Passwörter nicht mehr das einzige Identitätsproblem sind. Ein Zugriffstoken ist oft leiser und gefährlicher. Es fragt nicht bei jeder Nutzung nach Mehrfaktor-Authentifizierung, es fällt weniger auf als eine neue Anmeldung, und in manchen Fällen überlebt es sogar eine Passwortänderung. Wenn es zusätzlich breite Berechtigungen hat, funktioniert es wie eine Eintrittskarte in die Cloud-Dienste eines Unternehmens.

Aus Haxoris-Sicht ist das ein typischer Angriffspfad über Vertrauen. Angegriffen wird nicht direkt das große Unternehmen. Angegriffen wird ein kleineres Werkzeug mit großen Berechtigungen. Danach sucht der Angreifer nach einem Nutzer mit Unternehmenskonto, breitem Dokumentenzugriff, freigegebenen Ordnern, Umgebungsvariablen, internen Abläufen und weiteren Stellen, an denen er sich vorwärtsbewegen kann.

17. April

Codex im Vorfall: wenn ein Nutzer während einer Kompromittierung künstliche Intelligenz einbindet

Huntress beschrieb einen ungewöhnlichen Vorfall auf einem Linux-Endgerät. Auf dem System waren mehrere Angreifer aktiv, die Kryptowährungs-Miner installierten, Zugangsdaten sammelten und weitere schädliche Aktivitäten vorbereiteten. Gleichzeitig verwendete der Nutzer auf demselben Gerät OpenAI Codex, um verdächtige Aktivitäten zu prüfen und zu beheben.

Das Huntress-Werkzeug wurde erst mitten in der Kompromittierung installiert. Dem Team fehlte daher die vollständige historische Telemetrie. Die Untersuchung wurde zusätzlich dadurch erschwert, dass von Codex generierte Befehle in einigen Fällen ähnlich aussahen wie Befehle der Angreifer. Der Nutzer wollte helfen, erzeugte aber genau in dem Moment eine weitere Schicht Rauschen, in dem legitime Schritte von schädlichen Aktivitäten getrennt werden mussten.

Das ist eine neue Kategorie von Vorfällen. Ein Nutzer bemerkt ein Problem, öffnet einen KI-Assistenten, lässt ihn Diagnosen ausführen, Dateien ändern, Befehle vorschlagen und das System „reparieren“. Währenddessen kann der Angreifer weiterhin aktiv sein. Ohne klare Regeln entsteht Chaos, das die Untersuchung verlängert.

Für Unternehmen folgt daraus ein praktischer Schluss. Incident Response darf keine improvisierte Fehlerbehebung eines Endnutzers mit KI sein. Wenn ein Mitarbeitender eine Kompromittierung vermutet, muss er wissen, was zu tun ist, wen er kontaktieren soll und was er auf keinen Fall ausführen darf. Künstliche Intelligenz kann Fachleuten helfen, sollte aber keinen geregelten Incident-Response-Prozess ersetzen.

Microsoft Defender: wenn ein Schutzwerkzeug zum Weg zu höheren Rechten wird

Huntress warnte im gleichen Zeitraum vor realer Ausnutzung von Schwachstellen, die als BlueHammer, RedSun und UnDefend bezeichnet wurden. BlueHammer wurde als CVE-2026-33825 verfolgt und von Microsoft in den April-Updates behoben. Laut Huntress handelte es sich um einen Fehler der Art „jetzt prüfen, später verwenden“ im Windows Defender, der einen Angreifer von einem normalen Konto zu SYSTEM-Rechten bringen konnte.

Für Unternehmen ist diese Geschichte unangenehm, gerade weil sie ein Schutzwerkzeug betrifft. Abwehrsoftware besitzt hohe Rechte, breiten Systemzugriff und ist natürlicherweise auf vielen Geräten vorhanden. Wenn darin eine ausnutzbare Schwachstelle entsteht, kann ein Angreifer sie als Teil der Rechteausweitung nach dem ersten Zugriff verwenden.

In offensiven Tests verändert das die Denkweise. Es reicht nicht zu fragen, ob ein Unternehmen ein Sicherheitstool hat. Man muss fragen, wie schnell es aktualisiert wird, ob seine Reichweite begrenzt ist, ob seine Konfiguration geschützt wird und ob das Team auch Schwachstellen in den Werkzeugen verfolgt, denen es die höchsten Rechte gibt.

16. April

Nginx UI: Webserver-Verwaltung als Zugang zur Produktion

Rapid7 und weitere Sicherheitsquellen warnten vor CVE-2026-33032 in Nginx UI. Dabei handelt es sich um eine Weboberfläche zur Verwaltung von Nginx-Servern. Der Fehler stand im Zusammenhang mit einer neuen Integration des Model Context Protocol und erlaubte einem nicht authentifizierten Angreifer die Übernahme des Servers. Verfügbare Daten deuteten auf tausende aus dem Internet erreichbare Instanzen hin.

Der Fall ist interessant, weil er zwei Dinge verbindet, die Unternehmen häufig unterschätzen: Verwaltungsoberflächen und neue Integrationen für künstliche Intelligenz. Nginx UI ist nicht nur ein schönes Panel. Es verwaltet Webserver-Konfigurationen, Verkehrslenkung, Zertifikate, Reverse Proxies, Weiterleitungen und manchmal auch den Zugriff auf interne Anwendungen.

Wenn ein Angreifer einen solchen Punkt übernimmt, muss er nicht sofort die Datenbank lesen. Er kann Routing ändern, schädliche Weiterleitungen einfügen, Kommunikation abfangen, Phishing auf derselben Domain vorbereiten oder einen dauerhafteren Zugriff schaffen.

Aus Haxoris-Sicht ist das ein weiterer Beleg dafür, dass die Netzwerkgrenze heute oft nicht ein einzelner Firewall ist. Sie besteht aus vielen Verwaltungsoberflächen, die mehr Macht haben, als ihre Besitzer wahrhaben wollen.

15. April

Model Context Protocol: wenn ein KI-Werkzeug dem System zu nahe kommt

Sicherheitsforscher warnten vor einer Schwäche in der Art, wie Model Context Protocol verwendet wird. Das Problem lag nicht nur in einer konkreten Anwendung. Es betraf ein breiteres Prinzip: Werkzeuge, die an künstliche Intelligenz angebunden sind, können durch falsch verarbeitete Konfigurationen oder Befehle die Möglichkeit erhalten, Systembefehle auszuführen.

The Hacker News berichtete unter Berufung auf OX Security, dass das Risiko mehrere Projekte betrifft und zu Zugriff auf Nutzerdaten, interne Datenbanken, Anwendungsschlüssel und Gesprächsverläufe führen kann. Entscheidend ist, dass diese Art von Problem an der Schnittstelle zwischen Assistent, Werkzeug und System entsteht.

Für Unternehmen ist das eine Warnung davor, künstliche Intelligenz blind an alles anzuschließen. Wenn ein Modell oder sein Werkzeug Dateien lesen, externe Dienste aufrufen, Skripte ausführen oder mit internen Daten arbeiten kann, ist es kein harmloser Helfer. Es ist ein neuer Ausführungskanal.

In offensiven Sicherheitstests interessiert uns daher nicht nur die Frage „welches Modell verwenden Sie“. Uns interessiert, was es tun darf. Auf welche Dateien hat es Zugriff? Welche Befehle kann es ausführen? Welche Geheimnisse sieht es? Und was passiert, wenn ein Nutzer etwas in den Chat schreibt, das das Modell oder Werkzeug falsch als Anweisung interpretiert?

NIST und die überlastete Welt der Schwachstellen

NIST kündigte eine Änderung an, wie Schwachstellen in der National Vulnerability Database verarbeitet werden. Grund war der starke Anstieg der Zahl von CVE-Einträgen. Praktisch bedeutet das, dass Verteidiger sich nicht darauf verlassen können, dass jede Schwachstelle schnell und vollständig mit Kontext angereichert wird.

Für technische Teams klingt das vielleicht wie ein Verwaltungsdetail. Für die Unternehmensleitung ist es aber ein wichtiges Signal. Die Zahl der Schwachstellen wächst schneller, als Menschen sie manuell verarbeiten können. Ohne Priorisierung nach realer Auswirkung, Internetexposition, aktiver Ausnutzung und Wert des betroffenen Systems wird Sicherheit zu einer endlosen Aufgabenliste.

Aus Sicht des Angreifers ist das vorteilhaft. Er muss nur warten, bis das Unternehmen nicht mehr hinterherkommt. Aus Haxoris-Sicht ist das ein Grund, Angriffspfade zu testen und nicht nur Funde zu zählen. Zehn kritische Schwachstellen auf einer Liste können weniger relevant sein als ein unauffälliger Fehler, der direkt zu Token und Produktion führt.

14. April

Composer: ein schädliches Projekt als Befehl auf dem Entwicklerrechner

Im PHP-Ökosystem wurden zwei Schwachstellen im Werkzeug Composer veröffentlicht, verfolgt als CVE-2026-40176 und CVE-2026-40261. Das Problem betraf die Verarbeitung von Konfigurationen für Repositories vom Typ Perforce. Ein Angreifer, der eine schädliche composer.json oder eine Quellreferenz kontrollierte, konnte Befehle im Kontext des Nutzers ausführen, der Composer startete.

Das ist genau die Art von Fehler, die in Unternehmen unterschätzt wird. Ein Entwickler öffnet ein fremdes Projekt, startet die Installation von Abhängigkeiten und geht davon aus, dass im schlimmsten Fall Bibliotheken heruntergeladen werden. In Wirklichkeit verhalten sich Entwicklerwerkzeuge häufig wie Ausführungsumgebungen. Sie lesen Konfigurationen, rufen externe Systeme auf, führen Skripte aus und verwenden lokale Zugangsdaten.

In offensiven Tests sind Entwicklungsumgebungen sehr attraktive Ziele. Nicht weil Entwickler etwas falsch machen, sondern weil ihre Rechner häufig Zugriff auf Repositories, Testdatenbanken, Cloud-Konten, interne Pakete und Deployment-Werkzeuge haben. Wenn ein schädliches Projekt in der falschen Umgebung ausgeführt wird, kann es der erste Schritt in das gesamte Unternehmen sein.

Microsoft Patch Tuesday: viele Korrekturen, wenig Zeit

Die April-Updates von Microsoft behoben 167 Schwachstellen, darunter zwei Zero-Day-Fehler. Acht Schwachstellen wurden als kritisch eingestuft, die meisten davon ermöglichten entfernte Codeausführung.

Das ist keine Sektion darüber, dass Patchen wichtig ist. Das weiß jeder. Wichtiger ist die Realität in Unternehmen. Ein Sicherheitsteam erhält an einem Tag Dutzende Korrekturen. Einige Systeme sind kritisch, einige alt, einige gehören einem Lieferanten, einige haben Ausnahmen, einige dürfen während der Arbeitszeit nicht ausfallen und bei einigen ist nicht klar, wem sie gehören.

Angreifer kennen diese Realität. Sie brauchen nicht, dass ein Unternehmen alle Updates ignoriert. Es reicht, wenn genau das eine Update verschoben wird, dessen System aus dem Internet erreichbar ist oder nach einem ersten Zugriff höhere Rechte ermöglicht. Deshalb ist es sinnvoll, Korrekturen nach Angriffspfad zu priorisieren: was ist von außen erreichbar, was wird aktiv ausgenutzt, was führt zu höheren Rechten und was schützt die wertvollsten Systeme?

13. April

Itron: wenn ein Angriff auf einen Lieferanten kritische Infrastruktur berührt

Itron, ein großer Anbieter von Technologien für Energie, Messwesen und städtische Infrastruktur, bestätigte einen Angriff, bei dem Angreifer Zugriff auf Teile seiner internen IT-Umgebung erhielten. Das Unternehmen erklärte, den Vorfall am 13. April entdeckt, seinen Reaktionsplan aktiviert und externe Berater hinzugezogen zu haben. Nach Unternehmensangaben gab es keine wesentliche Betriebsunterbrechung und keine Auswirkungen auf Kunden.

Wichtig ist, wer Itron ist. Das Unternehmen liefert intelligente Zähler, Sensoren und Datenplattformen an tausende Versorger und Städte in mehr als hundert Ländern. Auch wenn der konkrete Vorfall laut Unternehmen keine Kunden traf, erinnert er daran, dass die Lieferkette kritischer Infrastruktur kein abstrakter Begriff ist.

In offensiven Sicherheitstests betrachten wir Lieferanten als Teil des Angriffspfads. Nicht jeder Angriff muss direkt beim Betreiber beginnen. Manchmal ist es sinnvoller, nach einer Schwäche in einem Werkzeug, im Support, im Fernzugriff, im Aktualisierungsprozess oder in einer Datenplattform zu suchen, die mehreren Kunden gegenüber natürliches Vertrauen besitzt.

Für Unternehmen folgt daraus eine einfache Konsequenz: Lieferantenbewertung darf nicht nur ein Fragebogen einmal im Jahr sein. Sie muss auch technische Fragen enthalten. Welche Zugriffe hat der Lieferant? Wie werden sie protokolliert? Wie werden sie entzogen? Welchen Reaktionsplan hat er? Wie schnell informiert er Kunden? Und was passiert, wenn ein internes Konto des Lieferanten kompromittiert wird?

Adobe Acrobat: PDF als alter, aber weiterhin wirksamer Einstieg

Adobe veröffentlichte eine außerplanmäßige Korrektur für Acrobat und Acrobat Reader zu CVE-2026-34621. Der Fehler erlaubte Codeausführung nach dem Öffnen einer schädlichen PDF-Datei, und Adobe bestätigte, dass er aktiv ausgenutzt wurde.

Diese Art von Schwachstelle ist gerade deshalb interessant, weil sie nicht modern wirkt. PDF ist ein altes Format, das Nutzer täglich öffnen. Rechnungen, Verträge, Bestellungen, Dokumentationen, Rechtsunterlagen, Lebensläufe, Anhänge von Lieferanten. Genau deshalb bleibt es als Einstieg in Unternehmen brauchbar.

Aus Sicht eines Angreifers ist ein schädliches Dokument oft günstiger als die Suche nach einem exotischen Fehler in der Hauptanwendung. Es braucht nur die richtige Geschichte, den richtigen Absender, den richtigen Zeitpunkt und einen verwundbaren Client. Kommt ein Nutzer mit Zugriff auf interne Systeme hinzu, wird das Dokument zum ersten Schritt eines Angriffspfads.

Für Unternehmen bedeutet das: Endgeräteschutz, Dokumentisolierung, schnelle Aktualisierungen und begrenzte Nutzerrechte sind keine langweilige Hygiene. Sie sind die Schichten, die entscheiden, ob das Öffnen eines Anhangs zu einem Vorfall wird.

10. April

Marimo: ein Daten-Notebook als Shell ohne Anmeldung

Sysdig warnte, dass die kritische Schwachstelle CVE-2026-39987 im Werkzeug Marimo innerhalb von zehn Stunden nach Veröffentlichung ausgenutzt wurde. Marimo ist ein offenes Python-Notebook für Datenwissenschaft und Analyse. Der Fehler bestand darin, dass der WebSocket-Endpunkt des Terminals nicht ausreichend authentifiziert war und ein nicht authentifizierter Angreifer eine vollständige Shell auf dem System erhalten konnte.

Das ist ein gutes Beispiel dafür, wie sich die Grenze zwischen Entwicklung, Datenanalyse und Produktion verschiebt. Notebooks werden oft schnell gestartet, manchmal nur vorübergehend, manchmal in der Cloud, manchmal mit Zugriff auf Daten, Modelle, Datenbanken und Token. Genau deshalb sind sie für Angreifer attraktiv.

Wenn ein Notebook auf einem Server mit Zugriff auf eine interne Umgebung läuft, kann ein scheinbar kleines Werkzeug zum Einstiegspunkt werden. Der Angreifer erhält eine Kommandozeile, untersucht Umgebungsvariablen, Konfigurationsdateien, Befehlsverlauf und Datenverbindungen und bewegt sich weiter.

Für Unternehmen ist der praktische Punkt klar: temporäre Analyse- und Entwicklungswerkzeuge müssen im Inventar stehen. Wenn sie nicht erfasst sind, werden sie nicht aktualisiert, nicht überwacht und niemand weiß, welche Zugriffe sie besitzen.

8. April

Ivanti EPMM: mobile Geräteverwaltung als Eingangstor ins Netzwerk

CISA fügte CVE-2026-1340 in Ivanti Endpoint Manager Mobile dem Katalog aktiv ausgenutzter Schwachstellen hinzu. Es handelte sich um einen Fehler, der Code-Injektion in einem Produkt zur Verwaltung mobiler Geräte ermöglichte.

Systeme zur Geräteverwaltung haben in Unternehmen eine besondere Stellung. Sie kennen Geräte, Richtlinien, Profile, Zertifikate, Anwendungen und häufig auch die Regeln, welche Geräte sich mit der Unternehmensumgebung verbinden dürfen. Wenn ein Angreifer diese Schicht erreicht, erhält er nicht nur einen Server. Er erhält einen Kontrollpunkt über eine Geräteflotte.

Aus Sicht offensiver Tests ist das ein sehr sensibles Ziel. Mobile Geräteverwaltung, Endgeräteverwaltung und Fernzugriff sitzen oft an der Grenze zwischen Internet und internem Umfeld. Sie sind für Administration gemacht und besitzen deshalb naturgemäß große Rechte.

Genau deshalb sollten diese Systeme nicht „wenn Zeit ist“ aktualisiert werden. Wenn sie von außen erreichbar sind und die Schwachstelle in einem Katalog aktiv ausgenutzter Fehler steht, ist das keine normale Wartung. Es ist die Entscheidung, ob man einem Angreifer ein offenes Steuerpanel lässt.

7. April

Flowise: ein Werkzeug zum Bau von KI-Agenten als Auslöser für Codeausführung

VulnCheck und andere Quellen warnten vor aktiver Ausnutzung von CVE-2025-59528 in Flowise. Flowise ist eine offene Plattform zum Bau von Anwendungen und Agenten mit künstlicher Intelligenz. Die Schwachstelle erhielt die höchste Schwerebewertung und erlaubte Codeausführung durch fehlerhafte Verarbeitung der Konfiguration im CustomMCP-Knoten.

Wichtig ist, dass Flowise nicht nur ein Textwerkzeug ist. Es läuft als Dienst, verbindet sich mit Modellen, Speichern, internen Systemen, Programmierschnittstellen und automatisierten Arbeitsabläufen. Wenn ein Angreifer auf einem solchen Server Code ausführen kann, erreicht er möglicherweise Dateien, Geheimnisse, Integrationsschlüssel und Datenquellen.

Das ist das größere Problem neuer KI-Werkzeuge. Unternehmen setzen sie oft als Experiment ein. Angreifer betrachten sie als Infrastruktur. Wenn sie Zugriff auf interne Daten und Systeme haben, müssen sie wie Produktionssysteme geschützt werden, nicht wie ein Spielzeug für das Innovationsteam.

In einem Test würden wir sehr direkt fragen: Wo läuft Flowise, wer meldet sich an, was ist angebunden, welche Schlüssel sind gespeichert, ist die Oberfläche aus dem Internet erreichbar und kann eine Konfiguration zur Ausführung von Befehlen führen?

5. April

Gefälschte Strapi-Pakete in npm: wenn ein Plugin kein Plugin ist

Sicherheitsforscher entdeckten 36 schädliche Pakete im npm-Register, die sich als Strapi-Plugins ausgaben. Sie verwendeten Namen, die mit strapi-plugin- beginnen, um vertrauenswürdig zu wirken. Tatsächlich enthielten sie schädliche Skripte zur Datensammlung, zum Missbrauch von Redis und PostgreSQL, für Reverse Shells und für dauerhafteren Zugriff.

Dieser Fall ist interessant, weil es nicht nur um einen einfachen Token-Dieb ging. Laut Analyse versuchten die Angreifer mehrere Ansätze: Missbrauch von Redis, Aufklärung, Diebstahl von Zugangsdaten und Aufrechterhaltung von Zugriff.

Für Entwicklungsteams ist das eine weitere Erinnerung daran, dass ein Paketname kein Vertrauensnachweis ist. In Ökosystemen mit tausenden Paketen versuchen Angreifer oft nicht, Schutzmaßnahmen zu brechen. Sie versuchen, ausreichend ähnlich auszusehen wie etwas Legitimes, das ein Entwickler erwartet.

Aus Haxoris-Sicht ist das eine Prozessfrage. Hat das Unternehmen Regeln für neue Abhängigkeiten? Sieht es, was während der Installation ausgeführt wird? Begrenzt es Rechte in der Build-Umgebung? Weiß es, welche Pakete in Produktion verwendet werden? Wenn nicht, wird die Lieferkette nicht getestet. Ihr wird einfach vertraut.

2. April

Progress ShareFile: ein Dateiaustausch-Gateway als Einstieg ins Unternehmen

watchTowr Labs veröffentlichte Forschung zum Progress ShareFile Storage Zone Controller. Zwei Schwachstellen, CVE-2026-2699 und CVE-2026-2701, konnten zu einer Kette verbunden werden, die entfernte Codeausführung vor der Anmeldung ermöglichte. Die betroffene Komponente dient als kundenseitig verwaltetes Gateway, über das Organisationen Dateien in ihrer eigenen Infrastruktur speichern und bereitstellen.

Gefährlich war, dass der Angreifer keine Zugangsdaten benötigte. Netzwerkzugriff auf den betroffenen Storage-Zone-Controller reichte aus. Nach Umgehung der Anmeldung konnte beliebiger Code auf dem zugrunde liegenden System ausgeführt werden. Laut watchTowr waren StorageCenter-Versionen 5.x bis einschließlich 5.12.3 betroffen; die korrigierte Version ist 5.12.4.

ShareFile ist ein gutes Beispiel für ein System, das Unternehmen oft als sicheren Kanal für Dateiaustausch wahrnehmen, nicht als kritische Netzwerkgrenze. Genau solche Portale sitzen jedoch zwischen der Außenwelt und internen Daten. Sie verwalten Anmeldung, Dokumentzugriff, Speicherkonfiguration, Netzwerkfreigaben, Cloud-Speicher und Kundenkommunikation.

Für einen Angreifer ist das ein attraktives Ziel. Es verbindet externe Erreichbarkeit mit hohem Datenwert. Wenn ein solches Gateway kompromittiert wird, muss der Angreifer sensible Informationen nicht im ganzen Netzwerk suchen. Ein großer Teil davon fließt ganz natürlich durch dieses System.

Was wir bei Haxoris aus dem April mitnehmen

Wenn wir aus den April-Ereignissen eine einzige offensive Übung bauen würden, würde sie nicht wie ein Hollywood-Szenario beginnen. Kein dramatisches Aufbrechen des Haupttors. Eher ein normaler Arbeitsmoment: ein neues Paket im Projekt, ein Testwerkzeug im Internet, ein gestresster Nutzer, eine Berechtigung für eine App, die Zeit sparen sollte, oder ein älteres Portal, das niemand mehr als kritisches System betrachtet.

Genau so entstehen heute interessante Vorfälle. Nicht durch einen magischen Fehler, sondern durch eine Kombination kleiner Dinge, die einzeln harmlos wirken. Eine gibt dem Angreifer Zugang. Eine zweite öffnet mehr Rechte. Eine dritte zeigt, wo Schlüssel gespeichert sind. Eine vierte erlaubt Bewegung ohne viel Lärm.

Für die Unternehmensleitung ist dabei eine Sache entscheidend: Sicherheit lässt sich nicht nur daran messen, ob ein Scan, ein Audit oder eine Schulung durchgeführt wurde. Das alles ist sinnvoll, reicht aber nicht. Ein realer Angriff fragt nicht, ob ein System formal als kritisches Asset eingestuft ist. Er fragt, ob es erreichbar ist, ob es Rechte hat, ob es Token speichert, ob es überwacht wird und ob jemand bemerkt, wenn es sich anders verhält.

Der April hat außerdem gezeigt, dass neue Technologien nicht nur neue Möglichkeiten bringen, sondern auch neue blinde Flecken. Werkzeuge für künstliche Intelligenz, Build-Automatisierung, Entwicklerplattformen und Chat-Anwendungen sind ein natürlicher Teil des Unternehmensalltags geworden. Angreifer sehen sie nicht als Zusatzmodule. Sie sehen sie als weitere Türen.

Aus Haxoris-Sicht ist es deshalb am wichtigsten, ein Unternehmen als lebendige Umgebung zu testen und nicht als Liste von IP-Adressen. Wo würden wir den ersten Zugriff bekommen? Wohin würden wir uns nach der Kompromittierung eines Kontos bewegen? Welches Werkzeug hat zu viele Rechte? Wo werden Schlüssel gespeichert? Welchen Prozess würde ein Mensch unter Stress umgehen? Und was würde passieren, wenn der Angreifer nicht das sichtbarste System angreift, sondern das praktischste?

Deshalb gewinnt offensives Sicherheitstesten an Wert. Nicht, weil es die schönste CVE findet. Sondern weil es zeigt, ob aus einem gewöhnlichen Vorfall ein echtes Geschäftsproblem werden kann. Der April lieferte dafür mehr als genug Beispiele.

Häufige Fragen

Für wen ist dieser April Throwback gedacht?

Für Sicherheitsteams, Entwickler, IT-Leitung und Geschäftsführung, die sich mit Red Teaming, Penetrationstests, NIS2, Cloud-Sicherheit, DevSecOps oder KI-Sicherheit beschäftigen.

Warum konzentriert sich der Artikel auf Angriffspfade?

Eine Liste von Schwachstellen reicht nicht aus. Ein Angriffspfad zeigt, wie Angreifer Erstzugriff, Token, Cloud, CI/CD, Identität, Anwendungen und Nutzer zu einem realen Unternehmensvorfall verbinden könnten.

Wie kann Haxoris unterstützen?

Haxoris hilft Unternehmen, ihre Angriffsfläche durch Red Teaming, Penetrationstests, Cloud- und Anwendungssicherheitstests, CI/CD-Reviews, Sicherheitsübungen und konkrete Maßnahmen zur Risikoreduktion zu überprüfen.

Quellen und empfohlene Lektüre

Verwandte Artikel

Warten Sie nicht auf Angreifer - finden Sie Ihre schwächste Stelle mit einem Penetrationstest.

Jetzt buchen