Anmelden
(Bild: Shutterstock)
Der EU-Rat verhängt restriktive Maßnahmen gegen Kriminelle und Firmen in Südostasien, die groß angelegte Betrugszentren betreiben und Menschen versklaven.
Die EU geht gegen südostasiatische Scam-Center vor, die weltweiten Krypto-Betrug mit schwersten Menschenrechtsverletzungen verknüpfen. Der EU-Rat hat am Donnerstag beschlossen, Sanktionen gegen sieben Einzelpersonen und drei Organisationen zu erlassen.
Die Vertreter der Mitgliedstaaten werfen den Betroffenen vor, für Menschenhandel, Folter sowie grausame und erniedrigende Behandlung im Zusammenhang mit organisiertem Betrug in Südostasien verantwortlich zu sein. Die straff organisierten Netzwerke locken Opfer aus aller Welt unter falschen Versprechungen an, halten sie gewaltsam fest und zwingen sie zu systematischem Online-Betrug.
Im Mittelpunkt der neuen EU-Strafmaßnahmen [1] steht die Prince Holding Group mit ihrem Geschäftsführer Chen Zhi. Dabei handelt es sich um einen in Kambodscha ansässigen Unternehmenskomplex, der über ein Vermögen von mehreren Milliarden US-Dollar verfügt. Über ein weitverzweigtes Geflecht aus Scheinfirmen hat die Gruppe laut dem Rat Scam-Center in Kambodscha sowie Myanmar aufgebaut und betrieben.
In diesen Einrichtungen werden demnach vor allem Investitionsbetrügereien mit Kryptowährungen wie Bitcoin organisiert. Die dorthin gelockten Arbeitskräfte geraten in eine moderne Form der Sklaverei. Wer sich Anweisungen widersetzt oder die vorgegebenen Quoten beim Krypto-Betrug nicht erfüllt, dem drohen schwere Misshandlungen, Entführungen, Freiheitsberaubung und Folter, wie Opfer berichten.
Ebenfalls auf der Sanktionsliste steht die Jin Bei Group und ihr Geschäftsführer Zhu Zhongbiao. Das Unternehmen betreibt in Kambodscha ein Netz aus Casinos und Betrugszentren, die auf die gleiche Masche setzen. Neben dem Ziel, Anleger weltweit über gefälschte Investitionsplattformen um ihre Ersparnisse zu bringen, sollen die Glücksspieleinrichtungen auch als Infrastruktur für Cyberkriminalität und Menschenhandel dienen.
Ein weiterer Schlag der EU richtet sich gegen die Democratic Karen Benevolent Army (DKBA). Die bewaffnete Gruppe in Myanmar kontrolliert strategisch wichtige Gebiete rund um die Stadt Myawaddy an der Grenze von Myanmar zu Thailand. Sie soll kriminellen Syndikaten Schutz gewähren und den Betrieb der Betrugskomplexe in ihrem Machtbereich ermöglichen.
Berichten zufolge beschränken sich die Soldaten der Miliz nicht auf Schutzgelderpressung. Sie sollen auch direkt an Gewalttaten und der Bewachung von Opfern beteiligt sein, die in den Zentren gefangen gehalten werden.
Die Strafmaßnahmen greifen sofort. Sämtliche Vermögenswerte der gelisteten Personen und Firmen in der EU werden unverzüglich eingefroren. Ferner ist es allen EU-Bürgern und europäischen Unternehmen untersagt, den Betroffenen finanzielle Mittel oder wirtschaftliche Ressourcen bereitzustellen. Für die sanktionierten Personen gilt ein Einreise- und Durchreiseverbot für das EU-Gebiet. Die entsprechenden Rechtsakte sind im Amtsblatt veröffentlicht und damit rechtsgültig.
Die Bestimmungen stützen sich auf die 2020 eingerichtete globale EU-Sanktionsregelung im Bereich der Menschenrechte [2]. Dieses Instrument ermöglicht es der EU, zielgerichtet Individuen und Organisationen weltweit zu belangen, die für schwere Menschenrechtsverstöße verantwortlich sind. Der aktuelle Beschluss knüpft an vorangegangene Sanktionen vom Oktober 2024 [3] an. Diese richteten sich etwa gegen die Chit Linn Myaing Group (CLM) und ihren Gründer Oberst Saw Chit Thu. Diese Firmengruppe soll ebenfalls an Betrugsfabriken an der Grenze zwischen Thailand und Myanmar beteiligt sein und aus deren Aktivitäten Gewinne ziehen. Der zusätzliche Schritt unterstreicht die Entschlossenheit der EU, transnationale kriminelle Netzwerke in Südostasien zu zerschlagen, Opfer zu schützen und die Hintermänner zur Rechenschaft zu ziehen.
URL dieses Artikels:
https://www.heise.de/-11387384
Links in diesem Artikel:
Copyright © 2026 Heise Medien
(Bild: rvlsoft / Shutterstock.com)
Mehrere Sicherheitslücken bedrohen IBM WebSphere Application Server und WebSphere Application Server Liberty.
Angreifer können die Software-Plattformen zum Ausführen von Java-basierten Anwendungen IBM WebSphere Application Server und die leichtgewichtigere Ausführung WebSphere Application Server Liberty attackieren. In aktuellen Versionen haben die Entwickler unter anderem „kritische“ Sicherheitslücken geschlossen.
Aufgrund von Fehlern in der Admin-Konsole können sich Angreifer etwa höhere Nutzerrechte verschaffen. Diese Schwachstelle gilt als „kritisch“ (CVE-2026-14446). Über eine weitere „kritische Lücke“ (CVE-2026-14512) kann aus der Ferne Schadcode auf Systeme gelangen oder Angreifer können die Authentifizierung umgehen. Zurzeit gibt es keine Berichte, dass Angreifer die Sicherheitslücken bereits ausnutzen.
Weiterführende Informationen zu den nun geschlossenen Schwachstellen finden Admins in den verlinkten Warnmeldungen. Dort finden sich auch konkrete Angaben, wie Admins Instanzen vor möglichen Attacken absichern können. Das Problem ist, dass die fehlerbereinigten Versionen bislang nur für das dritte Quartal angekündigt sind. Bis dahin gibt es „Zwischenlösung-Patches“ (Interim Fixes) wie APAR PH72191 oder PH72192, die Admins installieren müssen.
Sicherheitswarnungen mit Hinweisen zu Interim Fixes:
URL dieses Artikels:
https://www.heise.de/-11386356
Links in diesem Artikel:
Copyright © 2026 Heise Medien
VMware aktualisiert seine Software.
(Bild: heise online / dmk)
VMware-Updates für ESX, vCenter, Workstation und Fusion schließen Sicherheitslücken, die etwa die Umgehung der Authentifizierung erlauben.
In VMware [1] ESX, vCenter, Workstation und Fusion klaffen teils kritische Sicherheitslücken. Bösartige Akteure können dadurch etwa die Authentifizierung umgehen und unbefugten Zugriff auf die VMware-Systeme erlangen.
Davor warnt Broadcom in einer Sicherheitsmitteilung [2]. Angreifer können eine Sicherheitslücke in VMware Directory Service von VMware ESX, vCenter, Workstation, Fusion zum Zugriff ohne Anmeldung ausnutzen (CVE-2026-59309, CVSS 9.8, Risiko „kritisch“). Außerdem können sie aufgrund einer Path-Traversal-Lücke im Syslog-Server beliebigen Code einschleusen und ausführen (CVE-2026-59310, CVSS 9.8, Risiko „kritisch“). In VMware ESX kann im virtuellen Netzwerkadapter VMXNET3 ein Schreibzugriff außerhalb eigentlich vorgesehener Speichergrenzen provoziert werden, wodurch lokale Admins aus einer VM Richtung Hostsystem ausbrechen können (CVE-2026-47876, CVSS 9.3, Risiko „kritisch“).
Angreifer mit den Rechten, VMs auszurollen, können in VMware ESX, Workstation und Fusion zudem außerhalb der allokierten Speicherbereiche lesen, was zu Informationsabfluss oder einem Denial-of-Service führen kann (CVE-2026-41703, CVSS 7.6, Risiko „hoch“). VMware ESX protokolliert nicht alles mit, wodurch Admins bestimmte Operationen ausführen können, ohne dass sie mitgeloggt würden (CVE-2026-41709, CVSS 2.7, Risiko „niedrig“).
In der Sicherheitsmitteilung verlinkt Broadcom diverse aktualisierte Softwarepakete für die verwundbaren Produkte. Etwa VMware Cloud Foundation und vSphere Foundation 9.1.0.0300 und 9.0.2.0100 (zudem ESXi-9.1.0.0200-25557999 und ESXi-9.0.2.0100-25595025) sowie VMware vCenter und Cloud Foundation 8.0 U3k (zudem vCenter ESXi80U3k-25595708) schließen die Sicherheitslücken, für Telco Cloud Platform und Telco Cloud Infrastructure stellt Broadcom Knowledgebase-Artikel mit Informationen zur Fehlerkorrektur bereit. Zudem stehen VMware ESX ESXi80U3i-25205845, VMware Fusion und Workstation 26H1 sowie Cloud Foundation 5.2.3 bereit, um den unbefugten Lesezugriff respektive Denial-of-Service auszubessern.
URL dieses Artikels:
https://www.heise.de/-11386401
Links in diesem Artikel:
Copyright © 2026 Heise Medien
(Bild: remotevfx.com/Shutterstock.com)
Mit der KI Claude hat Anthropic Schwachstellen in Kryptoalgorithmen gesucht. Bei einem Post-Quanten-Krypto-Kandidaten wurde sie fündig.
Anthropic hat seine Künstliche Intelligenz [1] Claude kryptografische Algorithmen prüfen lassen. Dabei deckte die KI Schwächen im Post-Quanten-Kryptografie-Algorithmus-Kandidaten HAWK auf, die zu einer effektiven Verkürzung der Schlüssellänge und somit für einige Szenarien leichter knackbare Verschlüsselung führen.
Davon berichtet Anthropic im Forschungsblog [2]. Claude Mythos Preview hat demnach einen verbesserten Angriff auf das digitale Signaturschema HAWK entdeckt, das eigentlich gegen Angriffe von Quantencomputern sicher sein soll (PQC, Post Quantum Cryptography). Das NIST sucht seit 2022 nach solchen Signaturschemen, HAWK war ein Kandidat, der es bis zur dritten Prüfungsrunde geschafft hat. Mythos Preview hat hier einen Angriff entwickelt, der die Entschlüsselungszeit massiv reduziert, da er die effektive Schlüssellänge fast halbiert, erklärt Anthropic. Für kleine Schlüsselgrößen wie bei HAWK256 reduziert sich der Wiederherstellungsangriff auf 238, anstatt der eigentlichen Schlüssellänge 264. Für größere HAWK-Schlüssel bleibt der Angriff praktisch unmöglich, führen die IT-Forscher aus.
Einen weiteren Angriff haben Anthropics Forscher gegen eine Variante eines AES128-Ciphers gestartet. Dort wurden sie mit Mythos Preview fündig, allerdings bei einer abgespeckten Version, die lediglich sieben anstatt zehn Verschlüsselungsrunden dreht. Das erklären die KI-Programmierer damit, dass das bei Forschern üblich sei, um Einsichten in die Algorithmen und potenzielle Schwachstellen zu finden. In vorherigen Arbeiten gefundene Angriffe auf die abgespeckte Verschlüsselung konnte Mythos demnach um den Faktor 200 bis 800 beschleunigen. Dazu waren mehrere Tage und eine Milliarde Token nötig. Die Überprüfung durch Menschen erforderte nochmals hunderte Stunden.
Allerdings schränken sie auch ein, dass diese Ergebnisse keinen Einfluss auf die Bewertung der Knackbarkeit der vollen AES-Verschlüsselung haben. Zudem seien die Prämissen für den Angriff praktisch nicht erfüllbar, bereits für die vorausgehenden Arbeiten, auf die Anthropic dabei aufgesetzt hat, erklärt das Unternehmen dazu.
Am Ende bleibt die Feststellung, dass KI mit hohem Einsatz – jeder der Angriffe hat rund 100.000 US-Dollar Token-Kosten erzeugt – bei der Erforschung von Verschlüsselungsalgorithmen hilfreich sein kann. Anthropic führt aus, dass dazu von den bedienenden Menschen keine größere Expertise nötig ist. Im konkreten Fall hatte der IT-Forscher zwar einen Hintergrund in Computerwissenschaften, jedoch keine ausgewiesenen weiterreichenden Kenntnisse in der zu knackenden Kryptografie.
Anthropic hat auch weitere Algorithmen attackiert und dabei ebenfalls leichte Optimierungen bekannter Angriffe erzielt, schreibt das Unternehmen. Die Erkenntnisse haben jedoch keinen Einfluss auf derzeitige Produktivsysteme, betont die KI-Schmiede.
URL dieses Artikels:
https://www.heise.de/-11384965
Links in diesem Artikel:
Copyright © 2026 Heise Medien
(Bild: Valeriya Zankovych/Shutterstock.com)
Angreifer missbrauchen fest einprogrammierte Zugangsdaten in Ciscos Firewall-Verwaltungssoftware. Updates sollen dagegen helfen.
Angreifer attackieren derzeit Ciscos Secure Firewall Management Center. Der Hersteller hat darin durch fest einprogrammierte Zugangsdaten für ein Konto faktisch eine Backdoor hinterlassen, die bösartigen Akteuren nun zur Anmeldung auf verwundbaren Instanzen dient.
Die US-amerikanische IT-Sicherheitsbehörde CISA hat die Schwachstelle [1] in den „Known Exploited Vulnerabilities“-Katalog aufgenommen. Cisco reagiert mit einer eigenen Sicherheitsmitteilung [2] auf das Problem. Die Schwachstelle betrifft das Webinterface der Secure-Firewall-Management-Center-(FMC)-Software. Aufgrund hartkodierter Zugangsdaten für ein Konto mit niedrigen Berechtigungen im System können Angreifer aus dem Netz auf die Instanzen und darauf verfügbare sensible Daten zugreifen (CVE-2026-20316, CVSS 5.3, Risiko „mittel“).
Cisco stufte die Auswirkungen abweichend vom reinen CVSS-Rating als „hohes“ Risiko ein. Als Grund nennen die Mitarbeiter, dass die Lücke sich mit anderen Schwachstellen in der Secure-FMC-Software verquicken lässt, um die Rechte im System auszuweiten. Ohne diese Lücke konkret zu nennen, hat Cisco zeitgleich eine Sicherheitsmitteilung [3] zu einer Sicherheitslücke aus dem März dieses Jahre [4]s aktualisiert, die das Ausführen von Skripten mit root-Rechten ermöglicht (CVE-2026-20079, CVSS 10, Risiko „kritisch“). Darin ergänzt Cisco dieselben Software-Hotfixes und nennt auch die IOCs. Allerdings fehlt im Abschnitt zu Exploits noch immer, dass Cisco um keinen Missbrauch im Netz wisse – das ist eher ein Hinweis darauf, dass Cisco die Meldung in Hast aktualisiert hat.
Zwar reduziere sich das Risiko, wenn das FMC nicht aus dem öffentlichen Internet erreichbar sei, erörtert Cisco. Jedoch gibt es keine (temporären) Gegenmaßnahmen, um die Sicherheitslücke anderweitig einzudämmen. Nur die Aktualisierung auf einen korrigierten Softwarestand helfe. Cisco stellt die Hotfixes auf die Versionen Cisco Firepower Management Center Hotfix_GB-7.0.9.1-3 sowie Secure Firewall Management Center Hotfix_HL-7.2.11.1-4, Hotfix_HG-7.4.7.1-3, Hotfix_CY-7.6.5.1-2, Hotfix_AM-7.7.12.1-2 und Hotfix_P-10.0.1.1-2 zum Herunterladen und Installieren bereit. IT-Verantwortliche sollten die Korrekturen umgehend anwenden.
Da Cisco [5] selbst auf aktiven Missbrauch der Schwachstelle hinweist, sollten Admins der FMC-Software davon ausgehen, dass ihre Installation kompromittiert wurde. Der Hersteller liefert auch Hinweise auf erfolgreiche Angriffe (Indicators of Compromise, IOC). Sofern bestimmte Einträge in den Logs auf Angriffe hindeuten, sollen Betroffene Ciscos Technical Assistance Center (TAC) um Unterstützung bei der Wiederherstellung bitten.
Vor zwei Wochen warnte die CISA ebenfalls vor Angriffen auf eine Schwachstelle in Cisco-Produkten [6]. Es handelte sich um eine Cross-Site-Request-Forgery-Sicherheitslücke in Ciscos IOS-Betriebssystem, die bereits seit 18 Jahren im Code geschlummert hat.
URL dieses Artikels:
https://www.heise.de/-11384735
Links in diesem Artikel:
Copyright © 2026 Heise Medien
Nur wenn alle Gruppenteilnehmer den Chatverlauf detailliert vergleichen, haben sie eine Chance die, Manipulation zu erkennen.
(Bild: DavideAngelini/Shutterstock.com)
Alle Mitglieder eines Gruppenchats sollten dieselben Inhalte sehen. Die üblichen Chat-Dienste stellen das nicht sicher. Das ist riskant.
Gruppenchats der großen Messaging-Dienste Whatsapp, iMessage, Signal und Threema sind zwar gut Ende-zu-Ende-verschlüsselt, sodass Unbefugte nicht mitlesen können. Gegen Manipulation der angezeigten Inhalte in Gruppenchats sind sie aber nicht geschützt, wenn der Täter ein legitimes Gruppenmitglied ist oder das Gerät eines Mitglieds kontrolliert. Solchen Angreifern ist es möglich, Chatnachrichten zu senden, die die selbe Identifikationsnummer tragen, aber bei unterschiedlichen Empfängern unterschiedlichen Inhalt haben. Damit fällt die sogenannte transcript consistency: Die Chatteilnehmer haben plötzlich unterschiedliche Versionen des Chats und wissen das nicht.
Die falschen Mitteilungen können sogar in Zitaten anderer Chatteilnehmer erhalten bleiben, so dass ein Chatteilnehmer eine völlig falsche Vorstellung vom Chatverlauf haben kann. Beispiel: Die Chatrunde stimmt einem Vorschlag einhellig zu, doch ein Chatteilnehmer sieht Zustimmung zu einem völlig anderen Vorschlag. Oder: Ein böswilliges Gruppenmitglied schickt einen Hyperlink in die Runde, der zu einem lustigen Katzenbild führt. Nur einem Gruppenmitglied schickt der Täter einen Link, der Malwaredownload auslöst. Die Gruppe antwortet auf den lustigen Link mit Heiterkeit und Danksagung, was die Zielperson zum Klick auf den Link verleitet.
Oder: Die Einladung zu einem wichtigen Treffen ergeht für einen Teil der Teilnehmer für Montag, für andere, die der Angreifer lieber nicht dabeihaben möchte, für einen anderen Tag, nachdem bereits alle Beschlüsse gefasst sind. Oder: Den Moderatoren eines Chats werden stets lautere Inhalte gezeigt, während bestimmte Mitglieder mit unlauteren bedacht werden. Und so weiter und so fort.
Nutzt ein Teilnehmer unter dem selben Nutzerkonto mehrere Endgeräte für den Gruppenchat, können ihm unterschiedliche Inhalte auf unterschiedlichen Endgeräten zugemittelt werden (außer bei Threema, das dabei das Manko fehlender Forward Secrecy [1] aufweist). Auch die Unterdrückung einer Nachricht je nach Endgerät ist bei den drei anderen Diensten möglich. Das alles funktioniert, ohne Bruch von Verschlüsselung, nicht nur für Textmitteilungen, sondern auch für Multimedia-Inhalte. Zudem lassen sich Abstimmungen auf verschiedene Art und Weise manipulieren.
Das hat eine österreichische Gruppe aus IT-Sicherheitsforschern um Gabriel Gegenhuber herausgefunden und Anfang Februar den vier Kommunikationsdiensten gemeldet. Obwohl Gruppenchats inzwischen auch für (kriegs)wichtige politische Entscheidungen auf oberster Ebene genutzt werden, plant keiner der vier Betreiber unmittelbare Maßnahmen um das Grundproblem auszumerzen.
Ende-zu-Ende-verschlüsselte Gruppenchats können auf unterschiedliche Weise realisiert werden. Threema, iMessage und früher auch Signal setzen auf paarweise Kommunikation: Sendet ein Teilnehmer eine Nachricht an die Gruppe, schickt sein Client im Hintergrund tatsächlich jeweils eine Kopie der Nachricht an jeden anderen Teilnehmer. Je größer die Gruppe, desto effizienter ist das derzeit von Signal und Whatsapp eingesetzt Verfahren, bei dem nur eine Nachricht vom Client an den Server geht, der sie dann an die anderen Chatteilnehmer weiterleitet („server fan-out‟). Nur für die ursprüngliche Übermittlung der notwendigen Verschlüsselungsschlüssel kommuniziert der Absender direkt mit den anderen Kommunikationspartnern.
Die Forscher haben für die böswilligen Mitteilungen offizielle (Signal und Threema) respektive inoffizielle (Whatsapp, iMessage) Clients genutzt und durch Softwarepatches angepasst. Auf Empfängerseite kam die übliche Software der Messagingdienste für Android, iOS, Linux, macOS, Windows, sowie Webbrowser zum Einsatz.
Bei paarweiser Kommunikation in Gruppenchats, wie Threema und iMessage sie einsetzen, ist der Trick naheliegend: Der Absender schickt, unter Verwendung des selben Nachrichten-ID, einfach unterschiedliche Inhalte an unterschiedliche Empfänger. Signal unterstützt, wohl aus Gründen der Rückwärtskompatibilität, sowohl paarweise Kommunikation als auch server fan-out.
Zudem können Whatsapp und Signal trotz standardmäßigem server fan-out dazu gebracht werden, automatisch auf paarweise Kommunikation zurückzufallen. Das tritt ein, wenn ein Empfänger eine Nachricht nicht entschlüsseln kann. Er fordert dann eine neuerliche Übertragung in paarweiser Kommunikation, schließlich müssen ja nicht alle Gruppenteilnehmer die Nachricht noch einmal erhalten, nur weil einer an ihrer Entschlüsselung scheitert.
Und dieses Scheitern kann absichtlich ausgelöst werden: Wie erwähnt, nutzen Whatsapp und Signal paarweise Kommunikation zur ursprünglichen Übermittlung der Entschlüsselungsschlüssel. Dort setzt der Angreifer an: Er sendet dem Zielclient absichtlich einen Schlüssel, mit dem dieser die „normalen‟ Chatnachrichten des Absenders gar nicht entschlüsseln kann. Dann löst jede normale Nachricht einen Fehler mit der Bitte um neuerliche, direkte Zusendung aus. Daraufhin schickt der böswillige Absender die gefälschte Nachricht mit der ID-Nummer der echten Nachricht.
Doch auch im server-fan-out-Verfahren, bei dem der Client eine Nachricht an den Server schickt, der sie dann an die Gruppenmitglieder verteilt, ist Manipulation möglich. Die erwähnte Kann-ich-nicht-entschlüsseln-Fehlermeldung des Empfängers bittet zwar um neuerliche Zumittlung mit der paarweisen Methode. Doch diesen Teil der Bitte kann der Angreifer ignorieren und die verfälschte Nachricht als server fan-out absenden.
Dann geht die verfälschte Nachricht zwar an alle Gruppenmitglieder, deren Clients sehen aber die ID einer bereits erhaltenen Nachricht. Daher verwerfen sie die „Kopie‟ ohne Fehlermeldung und prüfen nicht, ob sie die neue Nachricht überhaupt entschlüsseln können. Nur die Zielperson erhält die falsche Nachricht, weil sie das Original nicht entschlüsseln konnte.
Aufgrund des besonders hohen Datenschutzes bei Signal gibt es dort noch einen zweiten Angriffsvektor: Während Whatsapp auf dem Server eine Liste aller Mitglieder einer Gruppe führt, tut Signal das nicht. Der Absender muss jeder Nachricht eine Liste aller Gruppenteilnehmer beilegen und kann dabei bestimmte Teilnehmer unter der Tisch fallen lassen. Sie erhalten diese Nachricht dann nicht, merken aber nichts von der Lücke.
Ist eine falsche Nachricht einmal zugestellt, bleibt sie auch in Zitaten erhalten, beispielsweise wenn andere Gruppenmitglieder darauf reagieren und ihre Meinung zu dem zitierten Inhalt kundtun. Denn die Zitatfunktion überträgt aus Gründen der Datensparsamkeit standardmäßig nicht den eigentlichen Inhalt, sondern verweist nur auf die ID der zitierten Nachricht. Damit sieht der Empfänger eines Zitats dabei also stets jene Nachricht, die ihm ursprünglich zugemittelt wurde, sei es das Original oder die falsche Nachricht.
Gibt es die referenzierte Nachricht nicht, verweigern Threema und iMessage das Zitat. Signal und Whatsapp fallen jedoch darauf zurück, den Inhalt des Zitats zu übermitteln. Das ist durchaus nützlich, den ein neu zur Gruppe Hinzugestoßener soll ja mitreden können. Allerdings eröffnet das dem Angreifer die Möglichkeit, den angeblich zitierten Inhalt beliebig zu definieren. Das geht auch in 1-zu-1 Chats, ohne Gruppe. Hier ist zu hoffen, dass der Empfänger noch weiß, was er (nicht) von sich gegeben hat.
Signal blendet unter den angeblich zitierten Inhalt immerhin einen Hinweis ein, dass es die zitierte Nachricht nicht finden kann. Bei Whatsapp fehlen solche Hinweise. Und speziell der Desktop-Client Signals erlaubt Zitate von Nachrichten, die erst nach dem Zitat verschickt werden.
Besonderen Spaß dürften die Forscher mit der Abstimmungs-Funktionen der vier Dienste gehabt haben. Keiner sichert die gestellte Frage kryptographisch ab. Bei iMessage, Signal und Threema kann ein Angreifer, der eine Abstimmung erstellt, unterschiedlichen Gruppenmitgliedern unterschiedliche Fragen stellen. Bei binären Fragen (ja/nein) unter Whatsapp, das Abstimmungen mittels Hash absichert, kann er die Antwortmöglichkeiten mit einander austauschen. Was der eine als Ja-Stimme erachtet, ist für den andern womöglich eine Nein-Stimme.
Zudem kann er bei Whatsapp bestimme Mitglieder von der Stimmenzählung ausschließen, in dem er etwa durch absichtliches Einfügen eines unsichtbaren Leerzeichens den Hashwert verändert. Stimmt der Hashwert dann nicht überein, verwirft Whatsapp die abgegebene Stimme einfach.
Bei Threema und Signal ist auch das Abstimmungsergebnis nicht sicher. Threema sieht vor, dass der Ersteller der Abstimmung den Stimmenstand allen Gruppenmitgliedern mitteilt. Da er einzelnen Mitgliedern verfälschte Nachrichten senden kann, kann er die angezeigten Stimmen einzelner Teilnehmer verändern, streichen oder hinzufügen.
Bei Signal verkündet zwar der Server das Abstimmungsergebnis. Doch kann der Angreifer im Voraus solche Mitteilungen erfinden und versenden. Das spätere, echte Abstimmungsergebnis wird von jenen Signal-Clients, die bereits ein gefälschtes Endergebnis erhalten haben, als vermeintliches Duplikat verworfen.
Dem nicht genug können auch die Abstimmenden Unfug treiben, indem sie unterschiedlichen Gruppenmitgliedern unterschiedliche Entscheidungen zusenden. Damit laufen die beim jeweilige Empfänger angezeigten Abstimmungsergebnisse auseinander. Bei Threema ist sogar möglich, mit manipulierten Nachrichten mehr als eine Stimme auf einmal in die Waagschale zu werfen, sowie versteckte Stimmen nachzureichen. Bei iMessage kann ein Täter im Namen anderer Gruppenmitglieder abstimmen.
Bei Whatsapp haben die Forscher entdeckt, dass iOS-Clients Abstimmungen anders verarbeiten als Android-Clients. Das können Angreifer ausnutzen, beispielsweise indem sie nur Gruppenmitglieder mit Android-Client abstimmen lassen. Gleichzeitig verrät Whatsapp, welcher Client genutzt wird. Das erlaubt unter Umständen Rückschlüsse auf den Aufenthaltsort des Teilnehmers, beispielsweise wenn er Whatsapp nur im Büro mit Windows nutzt, oder mit Linux nur Zuhause, oder umgekehrt.
Auseinanderlaufen von Inhalten von Gruppenchats ist für den einzelnen Teilnehmer schwer zu erkennen. Hinzu kommt, dass sensible Chats oft auf automatische Löschung der Inhalte nach kurzer Zeit setzen. Dadurch werden die Manipulationsbeweise automatisch vernichtet.
Das Grundproblem manipulierter Inhalte ist systembedingt, speziell paarweise Kommunikation eröffnet Lücken. Mit Verzicht darauf wäre viel erreicht, das würde aber aufwändiges Redesign erfordern.
Für Signal und Whatsapp, die primär auf server fan-out setzen und nur subsidiär auf paarweise Kommunikation zurückgreifen, haben die Forscher Vorschläge, wie die Probleme reduziert werden könnten: Verbot paarweiser Kommunikation, außer für die ursprünglichen Schlüssel, weil es dort im gegebenen Konzept notwendig ist. Clients sollten unerbetene, neuerliche Zusendungen von Nachrichten generell verwerfen. Bittet ein Client um neuerliche Zumittlung einer Nachricht, sollte das allen Gruppenmitgliedern mitgeteilt werden, um Aufmerksamkeit zu schaffen. Zeitstempel sollten nur vom Server akzeptiert werden, und jede Veränderung der Gruppenzusammensetzung sollte auf technischer Ebene zur automatisch Erstellung einer neuen Gruppe führen.
Vor allem aber sollten Vorgänge transparent gemacht werden: Fehlgeschlagene Entschlüsselung sollte ebenso angezeigt werden, wie neuerliche Zusendung einer früheren Nachricht – samt Warnung, dass der Inhalt einer solchen Nachricht von dem anderen Teilnehmern angezeigten Inhalt abweichen kann. Zudem sollte für jeden Gruppenteilnehmer automatisch eine Statistik geführt werden, die offenlegt, wo sich Entschlüsselungsfehler und neuerliche Versendungen häufen. Denn das ist verdächtig.
Ein anderer Weg wäre, die Ende-zu-Ende-Verschlüsselung auszuschalten, so dass jeder bei jedem alles mitlesen kann. Davon hält Studienautor Gegenhuber (früher an der Universität Wien, jetzt an der Interdisciplinary Transformation University in Linz tätig) nichts: „Ohne Ende-zu-Ende-Verschlüsselung ist man vollständig vom Server abhängig, und der könnte dann beliebig Nachrichten manipulieren oder unterdrücken. Außerdem könnte der Serverbetreiber alles mitlesen.‟
„Ende-zu-Ende-Verschlüsselung ist eine große und wichtige Errungenschaft‟, betonte Gegenhuber gegenüber heise online. „Dabei wird jedoch Vertrauen und die Verantwortung für Validierung vom Server zum Client verschoben. Und der kann bösartig sein. Daher ist transcript consistency wichtig.‟
Mit Gegenhuber haben Moritz Grefner, Matthäus Wininger, David Schmidt und Aljosha Judmayer (allesamt Universität Wien) sowie Maximilian Günther (SBA Research) die Sache erforscht. Sie haben ihr gemeinsames Paper unter dem Titel Send and Pretend: Exploiting Transcript Consistency Issues in End-to-End Encrypted Group Chats in der Nacht auf Donnerstag bei Github [3] und Zenodo online [4] gestellt. Dort stehen auch Programmcode und Beweisvideos zum Download bereit.
Gegenhuber, Günther und Judmayer waren bereits Teil jenes Forscherteams, das das gesamte Whatsapp-Nutzerverzeichnis abgeschnorchelt [5] hat. Zuvor waren die drei an einem Forschungsprojekt beteiligt, das gezeigt hat, wie die Verschlüsselung Whatsapps herabgestuft [6] werden kann, sowie an einem Projekt, das offengelegt hat, was Signal und Whatsapp trotz Verschlüsselung verraten [7].
Das Team hat alle vier Dienstebetreiber am 6. Februar informiert. Apple hat laut Forscherteam den Empfang bestätigt. Meta Platforms hat 1.000 US-Dollar Belohnung ausgeschüttet und Verbesserungen bei Abstimmungen in Whatsapp angekündigt. Threema möchte das Teilproblem der Möglichkeit zur Abgabe mehrerer Stimmen angehen.
Keiner der Drei hat demnach angekündigt, das Grundproblem fehlender transcript consistency in Gruppenchats anzugehen. Auch das von einer nichtkommerziellen Stiftung betriebene Signal plant keine Sofortmaßnahmen, möchte sich aber dann dem Problem widmen, wenn es gröbere Arbeiten an der Gruppenchat-Funktion in Angriff nimmt.
URL dieses Artikels:
https://www.heise.de/-11384095
Links in diesem Artikel:
Copyright © 2026 Heise Medien
(Bild: Matthias Parbel / iX / KI)
Stackable stellt die Data Platform 26.7 auf Qualität und Supply-Chain-Sicherheit um. Neben SLSA-Provenance drohen bei der Registry-Logik Breaking Changes.
Für die Veröffentlichung der neuen Version 26.7 seiner Stackable Data Platform weicht das gleichnamige Unternehmen vom üblichen Release-Rhythmus ab. Statt neuer Produktfeatures stand dabei laut Ankündigung die Qualitätssicherung der modularen, auf Kubernetes basierenden Open-Source-Plattform im Mittelpunkt. SDP 26.7 zeichnet sich demnach durch den Abbau technischer Schulden, die Stabilisierung von CI-Pipelines und das Bereinigen instabiler Tests aus. Die Verbesserungen reichen von der dynamischen Registry-Auswahl über erhöhte Supply-Chain-Sicherheit bis zum neuen zentralen Verzeichnis, dem Stackable Hub. Zwar liegen die wichtigsten Neuerungen somit eher unter der Oberfläche. Sie sollen aber insbesondere Betreibern regulierter Infrastrukturen und all jenen zugutekommen, die Operatoren außerhalb des Standardwegs installieren wollen.
Laut Blogbeitrag zum neuen Release [1] liefert Stackable dennoch eine Reihe von Updates, darunter Apache Airflow 3.2.2, Apache Superset 6.1.0, OpenSearch 3.6.0, Trino 481, Apache NiFi 2.9.0, Open Policy Agent 1.16.2 sowie die LTS-Versionen Apache Spark 4.1.2 und Apache Druid 37.0.0. Zudem wurden 133 Schwachstellen behoben – davon 10 kritische und 62 als hoch eingestufte CVEs. Unterstützt werden Kubernetes 1.31 bis 1.36 sowie Red Hat OpenShift 4.18 bis 4.22.
Die folgenreichste Änderung betrifft die Art, wie Operatoren ihre Produktimages beziehen. Bisher war die Registry oci.stackable.tech fest im Code hinterlegt. Anpassungen für Air-Gap-Umgebungen oder interne Mirror-Registries erforderten Helm-Werte pro Produkt oder Eingriffe in die Containerd-Konfiguration auf Knotenebene – ein Workaround, der mit wachsender Plattformgröße zunehmend unhandlich wurde.
Ab Version 26.7 ersetzt Stackable diese Logik durch einen konfigurierbaren Mechanismus. Über den neuen CLI-Parameter --image-repository beziehungsweise die Umgebungsvariable IMAGE_REPOSITORY bestimmen die Operatoren, woher sie ihre Produktimages beziehen. Wird ein Operator über den Helm-Chart oder das OLM-Manifest (Operator Lifecycle Manager) installiert, setzt die Plattform diesen Wert automatisch passend zur Registry, aus der der Operator selbst stammt. Ein Operator, der aus quay.io/stackable kommt, zieht seine Produktimages damit automatisch ebenfalls von quay.io. Stackable veröffentlicht seine Artefakte – inklusive der Operator-Helm-Charts – künftig direkt aus den CI-Pipelines nach quay.io, statt sie manuell zu spiegeln.
Für Installationen außerhalb von Helm oder OLM ist das ein echter Breaking Change. Wer Operatoren per eigenem Deployment-YAML, Kustomize oder ArgoCD betreibt, muss --image-repository explizit im args-Block des Operator-Containers setzen – etwa als --image-repository=oci.stackable.tech/sdp oder mit dem Pfad einer internen Mirror-Registry. Wer eigene Helm-Charts pflegt, muss zusätzlich den Wert image.repository anpassen: Er darf den Operatornamen nicht mehr enthalten. Statt oci.stackable.tech/sdp/airflow-operator lautet der Wert künftig nur noch oci.stackable.tech/sdp. Fehlt die Anpassung, finden die Operatoren ihre Images nicht mehr – die Pods bleiben mit ImagePull-Fehlern hängen. Ein Testlauf in einer separaten Umgebung vor dem Produktiv-Upgrade ist dringend empfohlen.
Unterm Strich wandert die Registry-Portabilität damit von produktspezifischen Workarounds in die Plattformlogik. Für Air-Gap-Szenarien lässt sich IMAGE_REPOSITORY gezielt auf eine interne Registry lenken, sofern die Produktimages konsistent dorthin gespiegelt sind – ein Gewinn für souveräne, interoperable Architekturen.
Der zweite große Themenblock ist die Supply-Chain-Sicherheit. Ab Version 26.7 liefern alle Container-Images von Stackable – sowohl Produkt- als auch Operator-Images – eine SLSA-Build-Provenance-Attestation (Supply-chain Levels for Software Artifacts [4]). Die Provenance (Herkunft) entsteht über den slsa-github-generator und erreicht SLSA Level 3: Ein vertrauenswürdiger, vom Projekt-Build getrennter Builder erzeugt und signiert die Attestation, sodass ein kompromittierter Buildjob sie nicht fälschen kann. Signiert wird keyless über Sigstore mit GitHub Actions als OIDC-Identity-Provider.
Ergänzend zu den bereits vorhandenen CycloneDX-SBOMs hängt nun an jedem Image auch eine SBOM im SPDX-Format als OCI-Attestation. Zur Verifikation empfiehlt Stackable den slsa-verifier, der stets gegen die Digest-Referenz statt gegen Tags arbeitet. Alternativ lässt sich cosign einsetzen.
Für Betreiber in regulierten Sektoren wie dem Finanz- und Gesundheitswesen sowie der öffentlichen Verwaltung ist das mehr als eine Formalie. Anforderungen aus NIS2 [5], dem EU Cyber Resilience Act [6] oder ISO 27001 verlangen zunehmend den Nachweis, woher Software-Artefakte stammen und ob sie unterwegs manipuliert wurden. Mit der Provenance lässt sich für jedes Image belegen, aus welchem Git-Repository und Commit heraus es gebaut wurde und welche Build-Infrastruktur beteiligt war. Die SPDX-SBOMs erfassen jede enthaltene Bibliothek samt Version und damit die Grundlage für automatisierte CVE-Scans und Policy-Prüfungen. Admission-Controller wie Kyverno oder OPA/Gatekeeper lassen sich so konfigurieren, dass nur Images mit gültiger Signatur und passenden Attestationen in den Cluster gelangen.
Neu ist der Stackable Hub unter hub.stackable.tech. Der öffentliche, schreibgeschützte Katalog ist als zentrale Anlaufstelle für alle Fragen rund um SDP-Releases gedacht – und schließt damit eine Lücke zwischen Dokumentation und tatsächlich ausgeliefertem Stand.
Der Hub bietet drei durchsuchbare Bereiche: eine Übersicht aller veröffentlichten SDP-Releases mit Erscheinungs- und End-of-Support-Datum, eine Komponenten-Timeline mit den exakten Versionen jedes enthaltenen Open-Source-Produkts sowie eine CRD-Referenz mit vollständigen .spec-Schemas, die sich nach SDP-Release filtern lassen. Wer wissen will, welche Apache-Kafka-Version in Release 25.11 enthalten war oder wie das Schema eines TrinoCluster-Objekts in Version 26.3 aussieht, findet die Antwort dort ohne Deployment.
Für Tooling und Automatisierung steht eine CORS-fähige JSON-API unter /api/v1/ bereit, ohne Authentifizierung, direkt einbindbar in CI-Jobs, Skripte und MCP-Server. Zusätzlich steht für LLM-Tools ein llms.txt-Endpunkt als Klartext-Zusammenfassung des Hubs bereit, damit ein Assistent aktuelle SDP-Daten in den Kontext einordnen kann, anstatt Versionsnummern zu erraten. Der bisherige CRD- und SBOM-Browser soll künftig in den Hub überführt werden.
Den drei zentralen Neuerungen ist eines gemeinsam: die dynamische Registry-Auswahl, SLSA-Provenance mit SPDX-SBOMs und der Stackable Hub lassen die Stoßrichtung des Anbieters erkennen, zu noch mehr Nachvollziehbarkeit und Portabilität der Plattform. Weniger Abhängigkeit von fest verdrahteten Defaults, dafür mehr kryptografisch prüfbare Herkunftsnachweise und maschinenlesbare Metadaten für die eigene Automatisierung. Ein kompletter Überblick aller Änderungen in SDP 26.7 findet sich in den Release Notes [7].
URL dieses Artikels:
https://www.heise.de/-11380921
Links in diesem Artikel:
Copyright © 2026 Heise Medien
(Bild: Artur Szczybylo / Shutterstock.com)
Unter bestimmten Bedingungen können Angreifer TeamViewer-Remotesessions unter macOS erstellen.
Wer auf einem Mac TeamViewer Remote Full Client oder TeamViewer Remote Hosts nutzt, sollte die Fernverwaltungssoftware aus Sicherheitsgründen auf den aktuellen Stand bringen.
In einem Beitrag warnen die Entwickler [1], dass Angreifer unter bestimmten Voraussetzungen die Zwei-Faktor-Authentifizierung (2FA) umgehen können (CVE-2026-12703 „hoch“). Damit solch eine Attacke aber überhaupt klappt, müssen die Optionen 2FA for Connections und Unattended Access aktiviert sein. Zusätzlich muss ein Angreifer über einen gültigen Account mit Device-Management-Rechten verfügen.
Ist das alles gegeben, kann ein Angreifer über einen nicht näher ausgeführten Weg den Fernzugriff auf einen Mac über den Unattended-Access-Pfad initiieren. Dabei gibt es keine 2FA-Abfrage und ein Angreifer kann direkt eine Session aufbauen.
Derzeit gibt es dem Softwarehersteller zufolge keine Hinweise auf Attacken. Um Systeme vor möglichen Angriffen zu schützen, müssen Admins sicherstellen, dass TeamViewer Remote Full Client oder TeamViewer Remote Hosts jeweils in der reparierten Version 15.80 installiert sind. Alle vorigen Ausgaben sollen verwundbar sein.
URL dieses Artikels:
https://www.heise.de/-11382884
Links in diesem Artikel:
Copyright © 2026 Heise Medien
(Bild: Alfa Photo/Shutterstock.com)
In aktuellen Versionen haben die Entwickler von Apache Traffic Server mehrere Sicherheitslücken geschlossen.
Apache Traffic Server ist über 38 Softwareschwachstellen attackierbar. Angreifer können unter anderem über DoS-Attacken Abstürze auslösen oder Sicherheitsmechanismen umgehen. Bislang gibt es seitens des Softwareherstellers keine Hinweise auf laufende Attacken. Admins sollten die reparierten Ausgaben zeitnah installieren.
Apache Traffic Server ist ein Caching-Proxy-Server und findet vorwiegend in Content Delivery Networks (CDN) Verwendung. Er ist darauf ausgelegt, Millionen Nachfragen pro Sekunde zu verarbeiten.
Nutzen Angreifer die Schwachstellen erfolgreich aus, können sie etwa Geo-Kontrollen (CVE-2026-22068 „hoch“) und IP-Zugriffskontrollen (CVE-2026-58159 „mittel“) umgehen. Zusätzlich sind an verschiedenen Stellen DoS-Attacken möglich. Etwa durch das Versenden von präparierten HTTP-Headern kann es zu Abstürzen kommen (CVE-2026-58154 „hoch“).
In einem Beitrag führen die Entwickler aus [1], die Sicherheitsprobleme in Apache Traffic Server 9.2.15 und 10.1.4 gelöst zu haben.
Jüngst haben die Apache-Entwickler Schwachstellen in Apache Airflow mit FAB-Authentifizierung geschlossen [2].
URL dieses Artikels:
https://www.heise.de/-11382689
Links in diesem Artikel:
Copyright © 2026 Heise Medien
(Bild: AFANASEV IVAN / Shutterstock.com)
Stimmen die Voraussetzungen, können Angreifer Apache Airflow attackieren und als Admin Systemeinstellungen verbiegen.
Wenn ein bestimmtes Paket installiert ist und weitere Einstellungen stimmen, ist die Workflow-Orchestrierungsplattform Apache Airflow verwundbar. Auch wenn eine offizielle Einstufung der Sicherheitslücke noch aussteht, deutet alles auf „kritisch“ hin. Eine reparierte Version des betroffenen Pakets apache-airflow-providers-fab steht zum Download bereit.
Airflow-Instanzen sind der Beschreibung der Schwachstelle (CVE-2026-59243) auf Seclists.org zufolge [1] nur angreifbar, wenn das Paket Apache Airflow FAB provider (apache-airflow-providers-fab) installiert ist und somit das Authentifizierungssystem FAB (Flask AppBuilder) genutzt wird. Zusätzlich muss als Authentifizierungsmethode Azure AD Oauth in der Standardkonfiguration aktiv sein.
Ist diese Kombination gegeben, können Angreifer bei der Überprüfung von Zugriffen mit gefälschten ID-Tokens an der Lücke ansetzen. Das Problem ist, dass FAB Auth Manager bei Azure OAuth standardmäßig die JWT-Signatur-Verifikation (verify_signature=False) deaktiviert. Weil keine Signaturprüfung des Tokens stattfindet, akzeptiert FAB den Zugriff und Angreifer können so als beliebiger Nutzer, einschließlich Admin, auf Instanzen zugreifen.
In so einer Position können sie etwa Zugangsdaten abgreifen und so in der IT-Infrastruktur weitere Computer kompromittieren.
Derzeit gibt es keine Berichte, dass Angreifer die Schwachstelle bereits ausnutzen. Auch wenn es schon eine CVE-Nummer gibt, steht die Einstufung des Bedrohungsgrads unter cve.org noch aus. Das CERT Bund stuft die Schwachstelle in einem Beitrag als kritisch ein [2].
Die Entwickler versichern, das Problem in Apache Airflow FAB provider 3.7.3 gelöst zu haben. Alle vorigen Versionen sind ihnen zufolge verwundbar.
URL dieses Artikels:
https://www.heise.de/-11381355
Links in diesem Artikel:
Copyright © 2026 Heise Medien
Roboter erstellen KI-Inhalte in einer dytopischen Welt.
(Bild: Shutterstock AI)
Ein eigenständig von KI durchgeführter Cyberangriff schreckte die Tech-Branche auf. Jetzt folgt der Ruf nach einem internationalen Bremsmechanismus.
Mehr als 1000 Mitarbeiter führender KI-Entwicklerfirmen sprechen sich dafür aus, die Voraussetzungen zum Bremsen des Fortschritts bei Künstlicher Intelligenz (KI) zu schaffen. Sie warnen vor einem Kontrollverlust und appellieren an die US-Regierung, sich an internationalen Bemühungen für technische und Regulierungs-Maßnahmen zur Steuerung des Entwicklungstempos zu beteiligen.
Unter den zum Meldungszeitpunkt 1178 Unterzeichnern sind führende Forscher und Manager etwa vom ChatGPT-Entwickler OpenAI, dem Konkurrenten Anthropic sowie dem Facebook-Konzern Meta und Google. Sie verweisen darauf, dass Software mit Künstlicher Intelligenz [1] bald in der Lage sein könnte, sich selbst weiterzuentwickeln.
Schon jetzt werden große Teile des Programmiercodes in Tech-Unternehmen von KI-Software geschrieben – aber unter menschlicher Aufsicht. Der Moment, in dem die Entwicklung Künstlicher Intelligenz automatisiert werden kann, gilt als ein Wendepunkt. Die Vorhersage, wie sehr dies den KI-Fortschritt beschleunigen werde, sei schwierig, heißt es in dem offenen Brief. [2] Aber es gebe ein „reales Risiko“, dass das Tempo „unsere Fähigkeit übertreffen wird, die sich daraus ergebenden Systeme zu verstehen oder zu kontrollieren“.
Abgestimmte internationale Anstrengungen seien nötig, weil jedes Land und jede Entwicklerfirma unter Konkurrenzdruck stünden, den KI-Fortschritt nicht abzubremsen, heißt es in dem Brief. Zudem fehlten aktuell noch die technischen Mittel und ein Regelwerk dafür.
Der offene Brief folgt auf einen aufsehenerregenden Zwischenfall, der in großen Teilen der Tech-Branche als Weckruf gesehen wird. Ein KI-Modell von OpenAI verschaffte sich bei einem Test eigenständig Zugang zum offenen Internet und drang danach auf eigene Faust in Computersysteme einer anderen KI-Firma. Dabei agierte die Software wie ein Cyberkrimineller und nutzte unentdeckt gebliebene Sicherheitslücken aus.
URL dieses Artikels:
https://www.heise.de/-11381185
Links in diesem Artikel:
Copyright © 2026 Heise Medien
(Bild: Artur Szczybylo/Shutterstock.com)
Die Load-Balancing- und Cluster-Managementlösung LoadMaster ist verwundbar. Die Entwickler haben nun Sicherheitslücken geschlossen.
Angreifer können an fünf Softwareschwachstellen in Progress LoadMaster, ECS Conenection Manager, Connection Manager und Multi-Tenant ansetzen und im schlimmsten Fall eigene Befehle ausführen.
Die Lücken sind im Sicherheitsbereich der Progress-Website aufgelistet [1]. Sie sind alle mit dem Bedrohungsgrad „hoch“ eingestuft (CVE-2026-59686, CVE-2026-59687, CVE-2026-59688, CVE-2026-59689, CVE-2026-59690). Bislang gibt es keine Hinweise, dass Angreifer die Schwachstellen bereits ausnutzen. Um Systeme vor möglichen Attacken zu schützen, müssen Admins die folgenden reparierten Versionen installieren:
Geschieht das nicht, können Angreifer unter anderem über das Managementinterface eigene Befehle ausführen und Instanzen so vollständig kompromittieren. Dafür müssen Angreifer aber bereits authentifiziert sein und über hohe Nutzerrechte verfügen. In einem weiteren Fall kann sich ein Angreifer mit niedrigen Nutzerrechten auf einem nicht näher ausgeführten Weg Root-Rechte verschaffen.
URL dieses Artikels:
https://www.heise.de/-11380070
Links in diesem Artikel:
Copyright © 2026 Heise Medien
Anthropic bewirbt Claude Cowork unter anderem für Rechtsteams.
(Bild: Anthropic)
Die Nutzung von KI-Agenten direkt auf dem Rechner kann Gefahren mit sich bringen. Das zeigt eine soeben entdecktes Sicherheitsloch in Claude Cowork für den Mac.
Das KI-Sicherheitsunternehmen Accomplish AI hat eine problematische Lücke im KI-Assistenten Claude Cowork [1] für macOS entdeckt. Damit ist es Angreifern möglich, über eigentlich nicht vertrauenswürdige Inhalte die virtuelle Maschine, die Cowork eigentlich verwendet, zu verlassen, um dann überall auf dem Mac Schreibrechte zu bekommen. Der Sandbox-Exploit sei durch Anthropics Designentscheidungen möglich, die interessanter seien als ein von den Sicherheitsforschern entdeckter Kernel-Bug, schreiben sie.
Der Fehler, der auf den Namen SharedRoot [2] getauft wurde, setzt sich auch über Limits hinweg, die der Nutzer gesetzt hat, etwa vorher festgelegte Ordner, die Claude Cowork [3] beschreiben darf. Neben dem Schreibvorgang sei es auch möglich, aus der VM heraus Dateien zu lesen – etwa SSH-Schlüssel und Cloud-Zugänge. Angreifern stünden alle Inhalte zur Verfügung, die der verwendete User-Account nutzen könne. Accomplish.ai lobte zunächst den Ansatz von Claude. Es handele sich um eine „echte VM“, der Nutzer der jeweiligen Session habe kaum Rechte, es gebe einen Seccomp-Filter und eine Brokered-Mount-Schicht.
Hauptproblem ist demnach, dass das Host-Dateisystem mit der VM im Read-Write-Modus geteilt wird. Mithilfe eines nachgeladenen Linux-Subsystems, in dem eine ungepatchte Lücke [4] steckt, ließ sich ein Guest-Root-Zugang herstellen. Der wiederum greift dann auf das echte Mac-Dateisystem zu.
Accomplish.ai schätzt, dass von dem Problem bis zu 500.000 macOS-Nutzer betroffen gewesen sein könnten. Es wurde allerdings nur indirekt behoben: Anthropic teilte mit, die Lücke sei zwar „informativ“, doch interne Änderungen machten sie nicht mehr ausnutzbar. Denn Claude Cowork bedient sich jetzt nicht mehr der Ausführung einer lokalen VM, sondern nutzt die sogenannte Cloud-Execution.
Damit ist der Sandbox-Escape nicht mehr nutzbar. Allerdings ist es immer noch möglich, den KI-Agenten lokal laufen zu lassen. Dies sollte man bis zu einem möglichen Fix unterlassen, außer man härtet seine eigene Konfiguration. Claude Cowork wird für diverse Zielgruppen außerhalb des Coding-Spektrums vermarktet, darunter Anwälte, Marketingleute oder Geschäftsentwickler.
URL dieses Artikels:
https://www.heise.de/-11379475
Links in diesem Artikel:
Copyright © 2026 Heise Medien
(Bild: heise online / dmk)
Am Juli-Patchday hat Microsoft eine AD-Lücke geschlossen, die Rechteausweitung ermöglicht. Nun warnt das Unternehmen vor PoC-Exploit.
Microsoft hatte am Juli-Patchday eine große Zahl an Softwareflicken [1] verteilt, unter anderem auch für Verwaltung mittels Active Directory. Für eine der Schwachstellen ist nun Proof-of-Concept-Exploit-Code im Netz aufgetaucht. Microsoft warnt vor dadurch wahrscheinlicher werdenden Angriffen und gibt Admins Ratschläge.
Microsofts Threat Intelligence hat in der Nacht die Warnung vor dem Proof-of-Concept-Exploit auf Bluesky [2] veröffentlicht. Bei der Schwachstelle „Certighost“ handelt es sich um eine Rechteausweitungslücke zu Admin in den Active Directory Certificate Services (AD CS), die Angreifer aus dem Netz ausnutzen können (CVE-2026-54121 [3], CVSS 8.8, Risiko „hoch“). Angemeldete Nutzer können Attribute von Maschinen-Konten manipulieren und ein Zertifikat der AD CS erhalten, mit dem eine Authentifizierung über „PKINIT“ möglich ist. Angreifer können sich als Domain-Controller ausgeben und als solchen authentifizieren und im Anschluss AD-Operationen ausführen, erklärt Microsoft [4].
Microsoft führt weiter aus, dass die nun erfolgte Veröffentlichung von Proof-of-Concept-Code [5] mit detaillierter Analyse der Schwachstelle [6] Angriffe deutlich wahrscheinlicher macht. Das Unternehmen empfiehlt Admins daher, mit erhöhter Priorität so schnell wie möglich die Updates vom Juli-Patchday zu installieren. Microsoft gibt an, Aktivitäten von IT-Sicherheitsforschern zum Test der Schwachstelle beobachtet zu haben, jedoch noch keinen aktiven Missbrauch durch bösartige Akteure bestätigen zu können.
Der Microsoft Defender erkennt die bösartigen Zertifikatsanfragen zu dieser Lücke und erzeugt Alarme, etwa „Potential Certighost (CVE-2026-54121) AD CS abuse“ sowie „Active Directory Certificate Services attack tool activity“. Es können auch weitere Fehlermeldungen in den Logs auftauchen, die nicht nur spezifisch für Certighost sind. Microsoft nennt Meldungen wie Erkennung von Sicherheitsprinzipalen (LDAP), verdächtige Aktivitäten im Zusammenhang mit einem Tool zum Missbrauch der Active Directory-Zertifikatsdienste, verdächtige Kerberos-Ticket-Anfragen oder DCSync attack (Replication of Directory Services).
Microsoft führt aus, dass IT-Verantwortliche die Juli-Patches unbedingt auf alle Server mit Enterprise Certification Authority (CA) aufspielen sollen. Das liefere den Schutz, indem das Ziel von Registrierungsanfragen geprüft wird, bevor die CA damit Kontakt aufnimmt und dadurch das Ausstellen manipulierter Zertifikate unterbindet, erklären Microsofts Mitarbeiter weiter.
Wer die Updates noch nicht anwenden kann, solle zumindest die Audit-Logs „Enable Certification Services auditing“ sowohl für erfolgreiche als auch fehlgeschlagene Operationen aktivieren, raten Microsofts IT-Mitarbeiter. Die Audit-Filter-Konfiguration soll Aktivitäten im Zusammenhang mit dem Zertifikats-Lebenszyklus erfassen. Die Sicherheitsereignisse 4886 und 4887 weisen auf anormale Zertifikatsanfragen und -ausgaben hin. Zertifikate, die über Machine-Templates angefordert wurden und die unerwartet Domain-Controller-Identitätsinformationen enthalten, sollten Admins ebenfalls genauer unter die Lupe nehmen.
URL dieses Artikels:
https://www.heise.de/-11379962
Links in diesem Artikel:
Copyright © 2026 Heise Medien
(Bild: heise medien)
Ein Krimineller bietet im digitalen Untergrund eine Datenbank mit 75 Millionen Einträgen an, die von der Neobank Revolut stammen sollen.
Die Menge klingt zunächst gewaltig: 75 Millionen Einträge soll eine Datenbank umfassen, die ein Cyberkrimineller im digitalen Untergrund derzeit anbietet. Angeblich stammen die Daten von der Neobank Revolut. Allerdings gibt es Hinweise, dass es sich um kein akutes neues Datenleck [1] handelt.
Auf X hat „Intel and Breaches“ [2] von dem Darknet-Angebot berichtet. Angeblich sollen die Daten mehr als 75 Millionen Nutzer betreffen. Die Einträge umfassen demnach Zahlungskarteninformationen wie Kartenschema, Status, Erstellung und weitere Metadaten. Dazu gehören zudem mehrere CSV-Datensätze mit nutzerbezogenen Informationen wie E-Mail-Adressen, Namen und Telefonnummern. Der Datensatz steht für 500 US-Dollar zum Verkauf, was ein niedriger Preis für solch einen aktuellen Datensatz wäre. Der Täter stellt einen Auszug von 100 Einträgen als Sample bereit. Der Account „Dark Web Intelligence“ weist auf X [3] zudem darauf hin, dass in dem öffentlichen Post keine konkrete Datensatzanzahl, keine technischen Details oder Angriffsvektoren stehen.
Auf Anfrage von heise online antwortete ein Sprecher von Revolut Deutschland: „Wir haben die in den Beispieldaten des ursprünglichen Beitrags enthaltenen Nutzer- und Kartenidentifikatoren mit unseren Systemen abgeglichen. Keiner davon entspricht einem gültigen oder echten Revolut-Identifikator.“ Die Überprüfung der weitergehenden Behauptungen sei noch im Gange, bislang habe die Neobank jedoch keine Hinweise auf eine Sicherheitsverletzung gefunden. Der Sprecher weist zudem auf externe Analysen hin, denen zufolge es sich „bei dem Datensatz wahrscheinlich eher um eine Zusammenführung von Daten aus verschiedenen Quellen handelt“ und nicht etwa um einen neuen Datenschutzvorfall. Auch dort habe die angegebene Zahl an Datensätzen nicht verifiziert werden können.
Auch wenn es sich um eine Zusammenstellung von Daten aus anderen Quellen und älteren Datenlecks handelt, sollten Revolut-Nutzerinnen und -Nutzer wachsam bleiben. Die Informationen lassen sich wahrscheinlich mit weiteren Daten verknüpfen und dann etwa für gezieltes und gut getarntes Phishing missbrauchen.
Am Montag wurde bekannt, dass eine noch unbekannte Cybergang mit dem Namen „ExfilSquad“ behauptet, bei Microsoft [4] sensible Daten entwendet zu haben. Auch hier gibt es Zweifel an der Echtheit.
URL dieses Artikels:
https://www.heise.de/-11379742
Links in diesem Artikel:
Copyright © 2026 Heise Medien
(Bild: heise online / dmk)
Die IT-Sicherheitsbehörde CISA meldet Angriffe auf Sicherheitslücken in Fortinet FortiOS sowie Arista VeloCloud.
In Fortinets FortiOS und Aristas VeloCloud Orchestrator On-Prem klaffen teils höchst kritische Sicherheitslücken, die bösartige Akteure derzeit angreifen. Die FortiOS-Lücke hat bereits einige Monate auf dem Buckel, Arista-Admins können seit dem Montag dieser Woche mit einem Update die Lücke schließen.
Die US-amerikanische Cybersicherheitsbehörde CISA warnt vor den Attacken [1] und nennt lediglich die Schwachstellennummern, die im Visier der Angreifer stehen. Die Sicherheitslücke in FortiOS findet sich im SSL-VPN und ermöglicht das unbefugte Auslesen vertraulicher Informationen mit manipulierten HTTP-Anfragen – ohne vorherige Authentifizierung (CVE-2025-68686 [2], CVSS 5.3, Risiko „mittel“). Betroffen sind die FortiOS-Zweige 6.4, 7.0, 7.2, 7.4 und 7.6. Fortinet korrigiert das lediglich mit den Versionen 7.6.2 sowie 7.4.7 und neueren. Wer ältere Versionszweige einsetzt, muss auf diese migrieren. Laut Fortinet lässt sich die Schwachstelle allerdings nur dann missbrauchen, wenn ein Angreifer das Gerät zuvor über eine andere Lücke auf Dateisystemebene kompromittiert hat. Die Sicherheitsmeldung von Fortinet hat noch keinen Hinweis auf die aktuell beobachteten Exploits (Known Exploited gibt das Unternehmen mit „No“ an).
In einer Sicherheitsmitteilung vom Montag warnt Arista [3] vor einer gravierenden Schwachstelle in VeloCloud Orchestrator (VCO) On-Prem. Angreifer aus dem Netz können auf interne Funktionen zugreifen und Einfluss auf den VCO-Host nehmen, für die höhere Rechte nötig sind (CVE-2026-16812 [4], CVSS 10.0, Risiko „kritisch“). Diese Funktionen sollten eigentlich nicht extern zugreifbar sein, erklärt Arista. Gehostete und verwaltete Versionen hat der Hersteller bereits mit Patch versehen, IT-Verantwortliche mit On-Premises-Installationen müssen jedoch rasch selbst aktiv werden. Die fehlerbereinigten VeloCloud-Orchestrator-Versionen lauten 5.2.3.14, 6.1.3.4, 6.4.2.4 und 7.0.0.1.
Die Autoren der Arista-Meldung weisen darauf hin, dass VCO standardmäßig im Netz erreichbar ist. Es gibt keine Konfiguration, die das unterbinden könnte. Angreifer benötigen jedoch Zugriff auf das VCO-Webinterface, weitere Zugangsdaten sind nicht nötig. Einige Hinweise für erfolgreiche Angriffe listet die Warnung auch auf und räumt ein, dass die Sicherheitsmitteilung auf aktiven Missbrauch der Schwachstelle und der darauffolgenden externen Erkennung erfolgte.
Fortinet-Admins konnten die Lücke bereits seit Februar abdichten. Das sollten sie gegebenenfalls spätestens jetzt nachholen. Außerdem sollten IT-Verantwortliche davon ausgehen, dass ihre Geräte kompromittiert wurden und entsprechende Untersuchungen einleiten, wenn sie die Updates erst jetzt einspielen können. Das ist insbesondere für die Arista-Schwachstelle empfehlenswert, da die Patches erst nach dem entdeckten Missbrauch erschienen sind.
Mitte Juni wurde bekannt, dass 74.000 Fortinet-Appliances auf mehreren Wegen [5] geknackt wurden. Das Phänomen hat den Codenamen „FortiBleed“ erhalten.
URL dieses Artikels:
https://www.heise.de/-11379680
Links in diesem Artikel:
Copyright © 2026 Heise Medien
Eine symbolische Updateerinnerung.
(Bild: Artur Szczybylo/Shutterstock.com)
Mehrere Sicherheitslücken gefährden MOVEit-Server. Es gibt unter anderem Sicherheitsprobleme bei der Authentifizierung.
Admins, die in Unternehmen für den Dateitransfer MOVEit nutzen, sollten die Software zeitnah auf den aktuellen Stand bringen. Geschieht das nicht, kann im schlimmsten Fall Schadcode auf PCs gelangen. Die Entwickler haben in einer neuen Version mehrere Schwachstellen geschlossen.
Insgesamt haben die Entwickler vier mit dem Bedrohungsgrad „hoch“ eingestufte Sicherheitslücken (CVE-2026-10697 [1], CVE-2026-15966 [2], CVE-2026-15967 [3], CVE-2026-15968 [4]) geschlossen. Die Beschreibungen der Schwachstellen sind sehr knapp. So kann es zu Problemen bei der Authentifizierung oder der Ablaufdauer von Sitzungen kommen. Zusätzlich kann im Zuge von XSS-Attacken Schadcode auf Systeme gelangen.
Derzeit gibt es seitens des Softwareherstellers keine Hinweise, dass Angreifer die Lücken bereits ausnutzen. Das kann sich aber schnell ändern. Demzufolge sollten Admins die den Entwicklern zufolge [5] gegen die geschilderten Attacken abgesicherte Version MOVEit 2026.0.3 installieren.
URL dieses Artikels:
https://www.heise.de/-11379295
Links in diesem Artikel:
Copyright © 2026 Heise Medien
(Bild: Ole.CNX / Shutterstock.com)
IT-Forscher haben eine mittels Malvertising verteilte Malware entdeckt. Die wird erst im Browser zusammengebaut.
Die Malware-Kampagne SourTrade wird von ihren Drahtziehern über Malvertising verteilt, also mittels Werbung etwa bei großen Suchmaschinen. IT-Forscher haben sie analysiert und als Besonderheit festgestellt, dass der Schadcode erst im Browser aus einzelnen unverdächtigen Bestandteilen im Arbeitsspeicher zusammengesetzt wird. Im Visier der Kriminellen sind insbesondere Krypto-Vermögenswerte.
Die IT-Forscher von Confiant haben nun eine Analyse [1] der Malware vorgelegt. Die Kampagne läuft bereits seit dem Jahr 2024 und zielt auf Nutzerinnen und Nutzer von Kryptowährungen und -börsen wie TradingView, Solana und Luno. Im Visier sind derweil Investoren aus zwölf Ländern, die Kampagne unterstützt 25 Sprachen. Die Angreifer setzen übliche Verschleierungstaktiken um, sodass Virenforscher etwa nur leere Webseiten vorfinden, während potenzielle Opfer überzeugende Fälschungen der sonst genutzten Plattformen zu Gesicht bekommen.
Auf der Landing-Page liegt jedoch keine fertige Malware. Die liefert vielmehr Anweisungen aus, mit denen der Browser die Malware zusammenbaut, erörtern die IT-Sicherheitsforscher. Dazu lädt der Browser saubere, legitime Dateien aus einer eigenen Infrastruktur herunter und baut die Malware daraus im Speicher der Maschine des Opfers zusammen. Damit umgehen die Drahtzieher die signaturbasierte Dateierkennung (Fingerprinting).
Das Malvertising fand insbesondere in Afrika, Asien, Australien, Südamerika und Großbritannien auf Englisch sowie den lokalen Sprachen des jeweiligen Landes statt. Dabei imitieren sie die Seiten legitimer Kryptowährungen und -Plattformen, insbesondere Luno, Solana und TradingView. Die Landing-Page bereitet die Malware-Auslieferung durch Aufsetzen eines per JavaScript umgesetzten ServiceWorkers vor. Der fragt den Pfad „/config“ an und erhält eine Bauanleitung anstatt der fertig ausführbaren Datei: ein Template, eine Laufzeit-URL und zufällige Werte je Session. Daraufhin fordert der Browser eine Bun-Runtime ein, vergleichbar mit dem Node.js-System, und kombiniert die mit ausgelieferten Blobs und AES-CTR-Bytes für Verschlüsselung und setzt damit die ausführbare PE-Datei im Speicher zusammen. Am Ende erhält der Browser den zusammengesetzten Datenstrom über einen ServiceWorker-Download-Pfad desselben Ursprungs zurück. Die Analyse zeigt auch die Details der einzelnen Schritte.
Die Datei wird zum Speichern angeboten. Die Mark-of-the-Web-Signatur, die sie erhält, verknüpft sie jedoch lediglich mit der ursprünglichen Domain und keinen weiteren, von denen die ursprünglichen Blobs stammen. Jedes Opfer erhält zudem mindestens durch die AES-CTR-Bytes eine eigene Signatur, was Malware-Scans erschwert. Die Analyse bringt eine längere Liste an Domains für Hinweise auf eine Infektion (Indicators of Compromise, IOC) sowie drei Hashwerte konkreter Samples mit.
Die Cyberkriminellen sind recht kreativ bei ihren Malvertising-Kampagnen. Im vergangenen Jahr haben bösartige Akteure die Suchen nach Standardbefehlen für Macs [2] mit manipulierten Webseiten infiltriert. Die dort vorgeschlagenen Befehle führten zur Installation von Schadcode aus dem Netz, konkret von Infostealern.
URL dieses Artikels:
https://www.heise.de/-11378977
Links in diesem Artikel:
Copyright © 2026 Heise Medien
(Bild: Daniel Tadevosyan / Shutterstock.com)
Aus Sicherheitsgründen wartet das GitHub-Tool nun drei Tage bis zum Erstellen von Pull Requests, wenn Versionsupdates für Dependencies erscheinen.
GitHub hat angekündigt, dass sein Dependency-Update-Tool Dependabot eine Cooldown-Phase von drei Tagen erhält. Das heißt, erst nach diesem Zeitraum erstellt das Tool einen Pull Request für Versionsupdates von Dependencies. Hierdurch soll das Risiko für die Installation von manipulierten Packages sinken, denn solche Supply-Chain-Attacken treten immer wieder auf, werden jedoch meist innerhalb von Stunden entdeckt.
In einer größeren Sicherheitsattacke erlangte im September 2025 [1] ein Angreifer Zugriff auf den npm-Account eines Entwicklers und verbreitete darüber mit Malware versehene Pakete. Betroffen waren rund 20 npm-Pakete, darunter chalk und debug, mit mehr als zwei Milliarden Downloads pro Woche. Die Schadpakete waren etwa zwei Stunden lang verfügbar, bevor sie entdeckt und von npm entfernt wurden.
Um solche Szenarien einzudämmen, wartet das GitHub-Tool Dependabot [3] nun mindestens drei Tage, bevor es einen Pull Request für ein Versionsupdate einer Dependency erstellt. Diese standardmäßig eingestellte Zeitspanne können Entwicklerinnen und Entwickler nach Bedarf verkürzen oder verlängern.
GitHub begründet seine Wahl von drei Tagen damit, dass viele schadhafte Pakete bereits innerhalb von Stunden nach ihrer Veröffentlichung entdeckt werden. Das belegt beispielsweise ein von GitHub zitierter Bericht über 21 größere Supply-Chain-Vorfälle [4] in einem Zeitraum von acht Jahren zwischen 2018 und 2026.
Von der Änderung ausgenommen sind Security-Updates. Damit sind solche Updates gemeint, die sich auf eine bekannte Vulnerability beziehen und mit einem veröffentlichten Advisory für das Package einhergehen. In diesem Fall gibt Dependabot einen Alert aus und eröffnet einen Pull Request für das Update auf die gepatchte Version – ohne Verzögerung.
Weitere Informationen zum neuen Dependabot-Verhalten sind in einem GitHub-Blogeintrag zu finden [5]. Dabei weist GitHub darauf hin, dass die Cooldown-Phase lediglich eine von mehreren Sicherheitsschichten sein sollte, da sie beispielsweise gegen länger angelegte Attacken mit nicht aktivierten, unentdeckten Backdoors in Releases nichts ausrichten kann.
URL dieses Artikels:
https://www.heise.de/-11378632
Links in diesem Artikel:
Copyright © 2026 Heise Medien
(Bild: iX)
Um KI erfolgreich in Code-Audits einzusetzen, ist die Wahl des Modells gar nicht so wichtig. Entscheidend ist der Workflow, damit man nicht in Funden versinkt.
KI als Spürhund für bessere Pentests und Codereviews einzusetzen, klingt im ersten Moment naheliegend. Aber ein Selbstläufer ist das nicht. Das zeigen die vielen Klagen der Open-Source-Projekte, die vor einer Flut von KI-Meldungen vermeintlicher Lücken stehen. Wie man seinen Workflow dafür anpassen muss, warum Mozilla das vorbildlich wuppt und wo jetzt der Flaschenhals liegt – das erklärt Stephan Zeisberg, Titelautor der neuen iX 8/2026.
(Bild: iX)
Wenn KI so viele Lücken aufspürt, müsste die Softwarewelt damit doch sicherer werden. Warum geraten stattdessen viele Open-Source-Projekte und Security-Teams gerade jetzt unter Druck?
Weil das reine Erzeugen einer Schwachstellen-Meldung inzwischen die billigste Stufe im Prozess geworden ist. Der eigentliche Wert entsteht aber erst weiter oben. Ein Befund wird erst dann zu Sicherheit, wenn ein Mensch prüft, ob er echt ist, ob er im konkreten System erreichbar ist und ob ein Patch das Problem wirklich löst. Genau dort sitzt jetzt der Engpass. curl hat sein Bug-Bounty-Programm im Januar eingestellt, HackerOne den Internet Bug Bounty im März pausiert, Node.js sein eigenes Bounty kurz danach suspendiert, und Linus Torvalds nennt die Linux-Kernel-Security-Liste im Mai öffentlich „almost entirely unmanageable“.
Alle geben denselben Grund an: KI-Werkzeuge produzieren plausibel klingende Reports schneller, als die Empfängerseite sie triagieren, verifizieren und beheben kann. Der Anteil echter Schwachstellen in diesen Reports ist niedrig geblieben, was massiv gestiegen ist, ist das Volumen. Wer nur mehr Findings zählt, misst nicht mehr Sicherheit, sondern die Belastung des Systems. Sicherer wird die Welt erst, wenn die Verifikationsseite mit der Discovery-Seite mitwächst, und das tut sie gerade nicht.
Was ist denn wichtiger für den Erfolg KI-gestützter Audits – ein möglichst starkes Modell oder doch eher der Workflow?
Beides zählt, aber der Hebel liegt eindeutig im Workflow, vor allem für Teams, die KI-Audits gerade erst einführen. Ein zusätzlicher Punkt auf einem Coding-Benchmark bringt weniger als eine ordentliche Reproduktions-Stufe im Prozess. Das zeigt Mozilla mit Firefox 150: 271 geschlossene Sicherheitsbugs in einem einzigen Release, darunter ein 20 Jahre alter Fehler in der XSLT-Engine, kamen nicht aus einem neuen Modell allein. Sie kamen aus einer Pipeline, in der jedes Modell-Finding einen reproduzierbaren Testfall mitbringen muss. Das Modell liefert Kandidaten, die Pipeline sortiert das Rauschen aus.
Mozilla hat seit Jahren eine Fuzzing-Infrastruktur mit reproduzierbaren Test-Cases, automatisierter Deduplizierung und integriertem Triage-Prozess aufgebaut. Darauf haben sie die agentische Test-Pipeline gesetzt, die das KI-Modell zwingt, jeden Befund mit einem reproduzierbaren Testfall zu belegen und die Reproduktion selbst zu fahren. Was sich nicht reproduzieren lässt, fällt raus, bevor ein Mensch es sieht. Der Punkt, der leicht übersehen wird: Neu ist nicht der Baustein, sondern die Kombination.
Umgekehrt gilt: Das stärkste Modell ohne diese Disziplin produziert mehr Rauschen, nicht mehr Sicherheit. Die 80 Prozent Falsch-Positive, die für 2024 und 2025 vielfach berichtet wurden, galten für Modelle, die ohne Reproduktions-Stufe direkt auf eine Codebasis angesetzt wurden. Mit einer disziplinierten Pipeline fällt der Wert deutlich. Welches Modell darauf läuft, ist am Ende zweitrangig gegenüber der Frage, ob überhaupt eine Pipeline da ist.
Und was sollte ein Team tun, das mit KI-Codeaudits starten will, aber nicht die ausgefeilte Infrastruktur Mozillas zur Verfügung hat?
Vor allem: nicht früh und breit einsetzen. Genau das produziert die Triage-Tretmühle, in der Reviewer nur noch Tool-Output aussortieren, statt selbst zu lesen. Was in der Praxis funktioniert, ist ein disziplinierter Einsatz in drei getrennten Stufen. KI vor dem Audit, um die Codebasis zu kartieren, Module und Eintrittspunkte zu identifizieren. KI während des Audits als Navigations- und Recherche-Hilfe. Und KI nach dem manuellen Review als zweite Sicht, die bekannte Muster prüft. Die Reihenfolge ist entscheidend: Wenn KI die erste Sicht liefert, prägt sie den Ersteindruck der Reviewer. Wenn sie die letzte Sicht ist, findet sie, was Menschen entgangen ist.
Dazu vier Regeln: Jedes KI-Finding braucht einen falsifizierbaren Reproduktionsfall, sonst bleibt es Hypothese. Die Findings-Menge wird pro Code-Bereich gedeckelt, damit die KI ihre Kandidaten selbst priorisiert; sonst lernen Reviewer, den ganzen Kanal zu ignorieren. Threat-Modell und die Einschätzung des Schweregrads bleiben in menschlicher Hand. Und wo KI auch Code schreibt, greift eine zusätzliche Schwelle mit dokumentierter Absicht und Negativ-Testfällen. Für Solo-Maintainer, die kritische Open-Source-Bibliotheken alleine tragen, ist das übrigens kein realistisches Programm. Dort ist die Antwort weniger ein besserer Workflow als eine gemeinschaftlich finanzierte Triage-Kapazität.
Stephan, vielen Dank für die Antworten! Einen Überblick, wie sich KI sinnvoll in Codereviews nutzen lässt, [1] gibt es in der neuen iX. Außerdem zeigen wir, wie KI-Tools im Unternehmensumfeld für Pentesting [2] genutzt werden. All das und viele weitere Themen finden Leser im August-Heft, das ab sofort im heise Shop [3] oder am Kiosk erhältlich ist.
In der Serie "Drei Fragen und Antworten" will die iX die heutigen Herausforderungen der IT auf den Punkt bringen – egal ob es sich um den Blick des Anwenders vorm PC, die Sicht des Managers oder den Alltag eines Administrators handelt. Haben Sie Anregungen aus Ihrer tagtäglichen Praxis oder der Ihrer Nutzer? Wessen Tipps zu welchem Thema würden Sie gerne kurz und knackig lesen? Dann schreiben Sie uns gerne [4] oder hinterlassen Sie einen Kommentar im Forum.
URL dieses Artikels:
https://www.heise.de/-11377461
Links in diesem Artikel:
Copyright © 2026 Heise Medien
FreshRSS