Drei Ausführungspfade legen Vertrauensprobleme in Zammad, MagicINFO und Unsloth Studio offen

Aktuelle Sicherheitsvorfälle zeigen, wie alltägliche Vorgänge zu Einfallstoren für schwerwiegende Angriffe werden können. Betroffen waren Sitzungen auf einer Supportplattform, beliebige Dateischreibvorgänge auf einem Digital-Signage-Server und die Metadatenprüfung in einem KI-Entwicklungstool.

Berichten zufolge nutzten Angreifer zwei Schwachstellen in Zammad gemeinsam aus, um in die Systeme des niederländischen Institute for Vulnerability Disclosure (DIVD) einzudringen. Dabei erlangten sie root-Rechte und exfiltrierten Daten. DIVD führte das schnelle Vorgehen und die Abfolge der Entscheidungen auf einen offenbar KI-gestützten Agenten zurück.

In einem anderen Vorfall führte Huntress einen Angriff auf eine bereits im Katalog der Known Exploited Vulnerabilities (KEV) der CISA gelistete Schwachstelle im Samsung MagicINFO 9 Server zurück. Der Angreifer installierte AnyDesk, schwächte die Endpoint-Schutzmaßnahmen, legte ein Administratorkonto an und kompilierte auf dem betroffenen System einen Kryptowährungs-Miner.

Ein dritter Fall betraf Unsloth Studio. Schon die Auswahl eines Hugging-Face-Modells konnte dazu führen, dass vom Repository kontrollierter Python-Code während der Prüfung ausgeführt wurde – noch bevor die Modellgewichte geladen wurden oder eine Inferenz begann.

Zwei Zammad-Schwachstellen ermöglichten Angreifern den Weg von gekaperten Sitzungen bis zu Root-Rechten

Angreifer kompromittierten DIVD, indem sie CVE-2026-102489 und CVE-2026-102490 kombinierten, wie The Hacker News berichtet.

Die erste Schwachstelle betrifft die Zammad-Versionen 6.3.0 bis 6.5.4. Sie ermöglicht das Kapern von Sitzungen. Darauf kann eine Remote-Code-Ausführung mit den Rechten des lokalen Kontos zammad folgen.

Die Schwachstelle ist auch in den Versionen 7.0.0 bis 7.1.3 vorhanden. Laut NVD-Beschreibung ist sie in diesem Versionsbereich aufgrund der jeweiligen Umgebungsbedingungen jedoch nicht ausnutzbar.

Die zweite Schwachstelle vervollständigt die Rechteausweitung. CVE-2026-102490 betrifft alle Zammad-Versionen, einschließlich der neuesten Alpha-Version. Sie ermöglicht es einem lokalen Nutzer mit dem Konto zammad, seine Rechte auf root auszuweiten.

DIVD zufolge nutzten die Angreifer beide Schwachstellen zusammen, um Sitzungen zu übernehmen, Code auszuführen und Kontrolle auf Root-Ebene zu erlangen. Nachdem sie das Zammad-System kompromittiert hatten, griffen sie auf weitere Dienste zu und lasen Daten aus, die sie anschließend exfiltrierten. Zu den betroffenen Informationen gehörten Daten von freiwilligen Helfern, darunter DIVD-E-Mail-Adressen und möglicherweise weitere Kontaktdaten.

Für die Eingrenzung eines Vorfalls ist dieser Ablauf entscheidend. Der Angriff endete nicht beim ursprünglichen Anwendungsserver. Eine Untersuchung, die sich auf Zammad-Protokolle oder Änderungen am Dateisystem beschränkt, könnte daher den anschließenden Zugriff auf verbundene Dienste übersehen.

DIVD stufte die Operation als automatisiert und offenbar KI-gestützt ein. Nach eigener Darstellung wählte der Agent nach jedem Schritt eine neue Aktion und ging schnell vor, verhielt sich dabei aber auch sprunghaft. DIVD zufolge beeinträchtigte der Angreifer die eigenen Man-in-the-Middle-Aktivitäten, indem er im Rahmen der Operation zusätzlich Password Spraying einsetzte.

Diese Beschreibung ist DIVDs Einschätzung des beobachteten Verhaltens. Sie rechtfertigt keine weitergehenden Aussagen über das konkrete Modell, den Betreiber oder das verwendete Automatisierungs-Framework. Nichts davon geht aus dem zitierten Bericht hervor.

Path Traversal in MagicINFO führte zu Fernzugriff und Kryptomining

Huntress berichtete von einem separaten Angriff, der mit der Ausnutzung von CVE-2025-4632 begann – einer Path-Traversal-Schwachstelle im Samsung Electronics MagicINFO 9 Server.

Betroffen sind Versionen vor 21.1052.0. In der Tabelle der betroffenen Produkte gibt die NVD den Versionsbereich mit 0 bis unter 21.1052 an. Die zugehörige Konfiguration definiert dagegen alle Versionen vor 21.1052.0 als verwundbar.

Die zugrunde liegende Schwachstelle ist CWE-22: Ein Pfadname wird nicht ausreichend auf ein zulässiges Verzeichnis beschränkt. Angreifer können diesen Fehler ausnutzen, um mit Systemrechten beliebige Dateien zu schreiben.

NVD und Samsung TV & Appliance bewerten CVE-2025-4632 mit CVSS 3.1: 9,8 (Kritisch). Der Vektor lautet:

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H

Die Metriken beschreiben einen über das Netzwerk erreichbaren Angriff mit geringer Komplexität, für den weder vorherige Berechtigungen noch eine Nutzerinteraktion erforderlich sind. Eine erfolgreiche Ausnutzung kann die Vertraulichkeit, Integrität und Verfügbarkeit stark beeinträchtigen.

Im von Huntress beschriebenen Vorfall unternahm der Angreifer drei Versuche, bevor er eine unerwünschte AnyDesk-Instanz installierte. Anschließend legte der Angreifer ein neues lokales Administratorkonto an, deaktivierte Defender-Schutzmaßnahmen und kompilierte Kryptowährungs-Mining-Software direkt auf dem kompromittierten Endgerät.

Die Kompilierung auf dem lokalen System ist aus Sicht der Angriffserkennung besonders relevant. Wer nur nach bekannten Miner-Binärdateien sucht, könnte frühere Anzeichen übersehen: wiederholte Downloads von Fernwartungssoftware, ungewöhnliche Compiler-Aktivitäten, unbefugte Administratorkonten und Änderungen an den Defender-Einstellungen.

Der NVD-Eintrag zu CVE-2025-4632 wurde am 13. Mai 2025 veröffentlicht und zuletzt am 17. Juni 2026 geändert. Er verweist auf Samsungs Abschnitt zu Sicherheitsupdates SVP-MAY-2025.

Die CISA nahm die Schwachstelle am 22. Mai 2025 in ihren Katalog der Known Exploited Vulnerabilities auf. Für US-Bundesbehörden galt der 12. Juni 2025 als Frist zur Behebung.

Die von der CISA geforderte Maßnahme ist eindeutig: Die Schwachstelle ist gemäß den Anweisungen des Herstellers zu beheben. Für Cloud-Dienste sind die einschlägigen Vorgaben aus BOD 22-01 anzuwenden. Falls keine Abhilfemaßnahmen verfügbar sind, ist das Produkt außer Betrieb zu nehmen. Der KEV-Status und die von Huntress dokumentierten Vorfälle belegen zusammen, dass es sich um eine tatsächlich angegriffene Angriffsfläche handelt und nicht um ein rein theoretisches Problem.

Unsloth Studio führte bei der Prüfung von Modellmetadaten Code aus

Pillar Security entdeckte in Unsloth Studio eine weitere Schwachstelle an einer Vertrauensgrenze. Das Tool ist Teil einer Open-Source-Bibliothek, mit der große Sprachmodelle feinabgestimmt und quantisiert werden können.

Die Schwachstelle lag im Ablauf zur Modellauswahl. Wenn Nutzer in der Oberfläche ein Modell auswählten, konnte das Backend Python-Code herunterladen und ausführen, der im zugehörigen Hugging-Face-Repository enthalten war.

Dazu musste keine Inferenz stattfinden. Auch das Laden der Modellgewichte war nicht erforderlich.

Es genügte, im Rahmen einer Metadatenprüfung die Datei config.json auszulesen. Damit wurde aus der Prüfung eines Modells ein Ereignis zur Codeausführung – obwohl Nutzer den Vorgang durchaus als passive Sichtung von Repository-Metadaten verstehen konnten.

Der eingeschleuste Code lief mit den Rechten des Kontos, unter dem Unsloth Studio betrieben wurde. Je nach Berechtigungen und Umgebung dieses Kontos konnte ein Angreifer auf proprietäre Trainingsdaten, Modellartefakte, Hugging-Face-Tokens, SSH-Schlüssel oder Cloud-Zugangsdaten zugreifen.

Pillar wies auch auf weitere mögliche Folgen hin, darunter die Manipulation von Modellen oder Trainingsergebnissen sowie den Zugriff auf zusätzliche Systeme mithilfe erreichbarer Zugangsdaten. Welche Auswirkungen eintreten können, hängt davon ab, auf welche Ressourcen der betroffene Prozess zugreifen kann.

Die Schwachstelle wurde in Unsloth Version 2026.6.9 behoben, die am 18. Juni 2026 veröffentlicht wurde. Im zitierten Bericht wird weder eine CVE-Kennung noch ein Schweregrad genannt.

Organisationen, die Unsloth Studio einsetzen, sollten prüfen, ob ihre Installationen auf die korrigierte Version aktualisiert wurden. Außerdem sollten sie dafür sorgen, dass dem Studio-Prozess möglichst wenige Zugangsdaten und sensiblen Daten zur Verfügung stehen, da vom Repository bereitgestellter Code im Sicherheitskontext des jeweiligen Nutzers ausgeführt wird.

Verteidiger sollten die gesamte Ausführungskette untersuchen

Jeder der Fälle zeigt eine andere Abfolge beobachtbarer Aktivitäten.

Bei Zammad sollten Verteidiger Sitzungsanomalien zusammen mit der Codeausführung unter dem Konto zammad, der Rechteausweitung auf root und dem anschließenden Zugriff auf weitere Dienste untersuchen. Da DIVD von einer Datenexfiltration berichtete, sollte die Prüfung über Hinweise auf die ursprüngliche Codeausführung hinausgehen.

Administratoren von MagicINFO sollten zunächst Installationen identifizieren, die älter als 21.1052.0 sind, und Samsungs Empfehlungen zur Behebung der Schwachstelle befolgen. Systeme, die während des verwundbaren Zeitraums erreichbar waren, sollten auf unerwartete Dateierstellungen, AnyDesk-Installationen, wiederholte Downloads von Fernwartungswerkzeugen, neue lokale Administratorkonten, Änderungen an der Defender-Konfiguration und nicht erklärte Compiler-Prozesse untersucht werden.

Der Miner selbst kann die letzte Phase des Angriffs sein – aber nicht unbedingt der beste Ansatzpunkt für die Erkennung.

Für Unsloth Studio ist ein anderes Sicherheitsmodell erforderlich. Modell-Repositories sollten als potenziell ausführbare Eingaben behandelt werden, nicht als passive Sammlungen aus Gewichten und Konfigurationsdateien. Wenn der Studio-Prozess keinen Zugriff auf Geheimnisse, Trainingsdaten, SSH-Schlüssel und Cloud-Zugangsdaten hat, lässt sich der Schaden durch die Ausführung von Repository-Code begrenzen.

Weitere Forschung zeigt dasselbe Problem an Vertrauensgrenzen

Mehrere verwandte Entwicklungen zeigen, wie Daten zu Anweisungen werden können, wenn Software ihnen unbeabsichtigt Autorität verleiht.

Chainalysis beschrieb EtherHiding, eine Form des Blockchain Dead Drop, bei der Malware-Anweisungen auf öffentlichen Blockchains gespeichert werden. Eine solche Infrastruktur lässt sich schwerer beschlagnahmen oder entfernen als ein herkömmlicher, vom Angreifer kontrollierter Server. Chainalysis zufolge entwickelten staatliche Akteure aus Nordkorea und dem Iran unterschiedliche Techniken. Außerdem berichtete das Unternehmen von einem Anstieg der BDD-Aktivität um 440 %, seit leistungsfähige chinesische Open-Source-KI-Modelle ohne Beschränkungen für schädlichen Code veröffentlicht wurden. Dieser zeitliche Zusammenhang belegt keine Ursache.

YesWeHack erläuterte Cache-Key-Injection: Dabei fügen Anwendungen vom Angreifer beeinflusste Werte ohne klare Trennzeichen zusammen. So können zwei unterschiedliche HTTP-Anfragen denselben Cache-Schlüssel erzeugen. Abhängig vom Endpunkt und der Cache-Architektur kann eine solche Kollision Cache Deception, die Offenlegung geschützter Antworten, einen Denial-of-Service oder – unter spezielleren Bedingungen – gespeichertes Cross-Site-Scripting ermöglichen.

Tracebit untersuchte indirekte Prompt-Injection als Verteidigungsmechanismus und stellte dazu Context Bombs vor. Für den Test wurden präparierte Anweisungen in einem Canary-Geheimnis in AWS Secrets Manager abgelegt. Durch Begrenzungszeichen für Konversationen und eine gefälschte Nutzernachricht sollte ein erkundender Agent zu der Annahme gebracht werden, sein Betreiber habe ihn angewiesen, anzuhalten.

In all diesen Fällen beschränkt sich das Grundproblem nicht auf eine einzelne Produktkategorie. Sitzungen werden zu Ausgangspunkten für Codeausführung, Dateipfade zu privilegierten Schreibmöglichkeiten, Metadaten zu Python-Code und zwischengespeicherte oder abgerufene Inhalte zu Handlungsanweisungen. Verteidiger müssen daher nicht nur prüfen, welche Daten Systeme verarbeiten, sondern auch, welche Befugnisse sie ihnen dabei einräumen.