Connect with us

Entwicklung & Code

KI Navigator #14: Muss KI gläsern sein? Zwischen Regulierung und Realität


Willkommen zur vierzehnten Ausgabe der KI-Navigator-Kolumne der DOAG KI Community!

Weiterlesen nach der Anzeige


Kolumne KI-Navigator - Benjamin Linnik

Kolumne KI-Navigator - Benjamin Linnik

Dr. Benjamin Linnik, promoviert in Kernphysik, vereint Expertise in Data Science, Software Engineering und Beratung. Als AI Tech Lead transformiert er Organisationen durch praktische AI-First-Ansätze – und schlägt dabei die Brücke zwischen technologischen Möglichkeiten und geschäftlichen Realitäten. Privat entspannt er gerne mit seiner Familie, umgeben von zwei Katzen und automatisiert gerne sein Smart-Home.




Dr. Alex Meistrenko hat als Unternehmensberater mit Fokus auf IT-Projekte in der Finanz- und Versicherungsbranche seine Leidenschaft für Systemarchitekturen, Datenmodellierung und Datenanalyse zum Beruf gemacht. Der promovierte Physiker und Mathematiker beschäftigt sich seit vielen Jahren mit der anwendungsorientierten Entwicklung von KI-Systemen – ebenso wie mit den mathematischen Prinzipien, auf denen sie beruhen.

Die EU-KI-Regulierung erinnert uns Physiker an eine berühmte Debatte aus der Geschichte der Wissenschaft: Ende des 19. Jahrhunderts standen sich zwei Giganten der Physik gegenüber: Ludwig Boltzmann und Ernst Mach. Der einflussreiche Positivist Mach weigerte sich, Boltzmanns statistische Mechanik zu akzeptieren. „Ham’s aans g’sehn?“ (Haben Sie eins gesehen?), rief er provokant aus dem Publikum während einer von Boltzmanns Vorlesungen über Atome. Doch Boltzmann zeigte: Auch wenn jedes einzelne Molekül real ist und chaotisch wirkt, entstehen makroskopische Eigenschaften wie Temperatur und Druck aus statistischen Gesetzmäßigkeiten – ohne dass wir jeden einzelnen Molekülstoß verfolgen müssen.

Die EU verlangt von KI-Systemen eine transparente Nachvollziehbarkeit – aber was heißt das konkret? Es geht nicht darum, die Berechnung jedes einzelnen Tokens offenzulegen, sondern die Regulierung fordert, dass wir die Ergebnisse von KI-Systemen nachvollziehen und interpretieren können – so wie ein Physiker nicht die Bahn jedes einzelnen Gasmoleküls kennt, aber über Druck, Temperatur und Volumen das Verhalten des Gases zuverlässig beschreiben und steuern kann. Nicht mikroskopische Durchleuchtung, sondern makroskopisches Verständnis und Kontrolle sind das Ziel.

Die historische Parallele ist verblüffend: Damals wie heute geht es um dieselbe methodische Einsicht. In der Thermodynamik lehrt Boltzmann, dass man komplexe Systeme durch emergente statistische Eigenschaften verstehen und ihr Verhalten kontrollieren kann, ohne jeden Einzelprozess zu verfolgen. Bei der KI müssen wir ebenso akzeptieren, dass wir nicht jeden einzelnen Verarbeitungsschritt erklären müssen, sondern das Gesamtverhalten eines KI-Systems anhand der statistischen Gesetzmäßigkeiten und emergenten Eigenschaften überwachen und kontrollieren können.

Weiterlesen nach der Anzeige

Die Kernfrage ist: Wie schaffen wir Vertrauen in Systeme, deren inneres Verhalten wir nicht vollständig verstehen und kontrollieren können? Dabei liegt die Antwort nicht in der unmöglichen Aufgabe, jeden Schritt zu erklären, sondern in der intelligenten Überwachung des Gesamtsystems – genau wie bei einem Motor, wo wir nicht jede Molekülbewegung im Brennraum verfolgen, aber sehr wohl die kritischen Parameter überwachen. Die Lösung liegt nicht in der Rückkehr zu deterministischen Ansätzen, sondern in der Entwicklung neuer Methoden für die Überwachung probabilistischer KI-Systeme.

Large Language Models (LLMs) sind probabilistische Systeme, deren Ausgabe nie deterministisch ist. LLMs verhalten sich wie ein komplexes Gas aus vielen Teilchen: Einzelne Token sind unvorhersehbar, aber das Gesamtverhalten lässt sich durch makroskopische Größen beschreiben und kontrollieren.

Statt jeden einzelnen Schritt zu prüfen, überwachen moderne KI-Systeme makroskopische Metriken:

  • Lösungsqualität: Wie gut löst das System die anvertrauten Aufgaben faktisch korrekt und relevant über Zeit und Anwendungsbereiche?
  • Zuverlässigkeit: Wie konsistent sind die Antworten bei wiederholter Ausführung und unter gleichen Bedingungen?
  • Durchsatz: Wie viele Aufgaben kann das System pro Zeiteinheit bearbeiten?
  • Effizienz: Wie viel Rechenleistung und Kosten verursacht das System für nützliche Ergebnisse?
  • Quellentreue (Faithfulness): Wie treu bleibt die generierte Antwort den bereitgestellten Quelldokumenten, ohne unbelegte Informationen hinzuzufügen?

Diese exemplarischen Metriken erklären nicht jeden einzelnen Prozess, geben aber ein klares Bild vom Gesamtzustand des Systems. Zusätzliche Metriken lassen sich je nach Anwendungsfall heranziehen, etwa Fairness bei verschiedenen Nutzergruppen, Latenz bei Echtzeitanwendungen oder Robustheit gegen Angriffe bei sicherheitskritischen Systemen.

In der Praxis werden makroskopische KI-Metriken durch eine Kombination bewährter Methoden erfasst, die drei zentrale Säulen umfassen:

  • stichprobenartige Bewertung mit menschlichen Experten
  • LLM-as-a-Judge
  • Distributed Tracing

Stichprobenartige Bewertung mit menschlichen Experten: Statt jeden einzelnen Output zu prüfen, bewerten Fachexpertinnen und -experten repräsentative Stichproben in Testsystemen. Moderne Plattformen wie LangSmith oder Langfuse bieten Annotation Queues – strukturierte Warteschlangen, in denen Experten systematisch KI-Ausgaben nach vordefinierten Kriterien bewerten können. Diese Bewertungen schaffen Referenzdatensätze, um automatische Systeme zu kalibrieren.

LLM-as-a-Judge: skalierbare automatische Bewertung. Bei dieser Methode werden vordefinierte Testszenarien mit bekannten Sollergebnissen (Ground Truth) durch das zu testende System verarbeitet. Ein KI-System in der Richterrolle vergleicht dann die tatsächlichen Ausgaben mit den erwarteten Ergebnissen anhand festgelegter Bewertungskriterien wie Faktentreue und Relevanz. Dies ermöglicht eine konsistente und skalierbare Bewertung großer Datenmengen. Entscheidend ist die sorgfältige Auswahl und kontinuierliche Verfeinerung der Judge-Szenarien.

Distributed Tracing: Systemverhalten sichtbar machen. Moderne KI-Systeme nutzen OpenTelemetry und ähnliche Frameworks für Distributed Tracing. Wie ein Thermometer die Temperatur misst, ohne jedes Molekül zu erfassen, tracken diese Systeme Anfragen durch komplexe KI-Pipelines und sammeln dabei makroskopische Metriken wie Latenz, Durchsatz, Fehlerrate und Ressourcenverbrauch. Sie erfassen jeden Schritt im KI-System – vom Prompt über die Toolauswahl bis hin zur Modellausführung und Antwort – als „Span“ und verknüpfen sie zu einem „Trace“.

Dabei gilt die Unterscheidung zwischen Test- und Produktivsystem: Ein Mensch könnte im Prinzip jeden Pfad nachvollziehen, den ein KI-System genommen hat – das ist jedoch in Produktivsystemen weder praktikabel noch erwünscht. Aus Kostengründen wäre die manuelle Prüfung von Millionen von Traces unwirtschaftlich, und aus Datenschutzgründen ist es verboten, persönliche Nutzerdaten in den Traces für manuelle Inspektion zu speichern.

Stattdessen werden diese Trace-Daten automatisch zu makroskopischen Kennzahlen aggregiert: durchschnittliche Antwortzeiten, Fehlerquoten pro Zeitraum oder Ressourcenverbrauch nach Systemkomponenten. KI-Monitoring konzentriert sich auf datenschutzkonforme Aggregatdaten statt auf individuelle Nutzerinteraktionen.

Die drei Methoden ergänzen einander: Menschliche Bewertungen schaffen den Sollzustand während der Entwicklung in kontrollierten Testsystemen, LLM-Judges stellen sicher, dass die Qualität mit der Zeit nicht schlechter wird und Tracing-Systeme überwachen das laufende Systemverhalten in Produktivsystemen.

Das globale Regulierungsumfeld für KI zeigt klare prinzipielle Unterschiede zwischen den Regionen. Während die EU im Rahmen des ersten weltweiten KI-Gesetzes (EU AI Act Regulation) auf explizite Erklärbarkeit setzt, bevorzugen die USA, Australien, aber auch internationale Standards, System-Level Assurance – einen Ansatz, der makroskopische Metriken über mikroskopische Erklärbarkeit stellt und die Erklärung emergenter Eigenschaften des Gesamtsystems ohne detaillierte Kenntnis einzelner Entscheidungen zum Ziel hat.

Makroskopische Metriken für stochastische KI-Systeme sind technisch umsetzbar und bewährt. Beispiele hierfür sind durch die Standards und Methoden wie Assurance of AI-Enabled Systems und Artificial Intelligence Risk Management Framework (AI RMF 1.0) gegeben und zeigen insbesondere, dass System-Level Assurance auch im Bereich von KI-Systemen funktioniert.

Der EU-Weg ist technisch herausfordernder, aber nicht unmöglich, solange keine lückenlose mathematische Erklärung aller mikroskopischen Entscheidungen vorliegen muss – er erfordert jedoch andere technische Lösungen, die über makroskopische Metriken hinausgehen und möglicherweise höhere Entwicklungskosten zur Folge haben. Insbesondere lässt der EU-Weg aber auch viel Interpretationsspielraum für die Bedeutung einer transparenten und erklärbaren KI zu.

Darüber hinaus ist davon auszugehen, dass eine zweifelsfreie Klassifizierung eines KI-Systems als Hochrisiko-System (EU AI Act Art. 6) in der Praxis oft auf Schwierigkeiten stoßen wird. Folglich könnte die EU-Regulierung Innovation behindern oder zu alternativen technischen Entwicklungspfaden führen, in denen der KI-Einsatz im Bereich von Hochrisiko-Systemen auf grundlegende klassische ML-Verfahren beschränkt bleibt und somit die Erklärbarkeit von rückgekoppelten, nicht-linearen und tiefen neuronalen Netzen vermieden wird.

Hier ist davon auszugehen, dass sich solch eine Entwicklung zu einem enormen Wettbewerbsnachteil bspw. im Energiesektor entwickeln wird, der längerfristig in einer wiederholten Abhängigkeit von den führenden Tech-Giganten, vorwiegend aus den USA, resultieren wird, wie wir es auch schon im Bereich des Cloud-Computing erlebt haben.

Der Übergang von traditioneller zur AI-First-Entwicklung greift tiefer, als neue Tools einzuführen. In der traditionellen Entwicklung schreiben Developer den Code, führen manuelle Code-Reviews durch und pflegen separate Dokumentationen. AI-First-Entwicklung hingegen basiert auf natürlicher Sprache, automatisierten Abnahmetests, Everything-as-Code (inklusive Dokumentation) und autonomer Fehlerbehebung.

Die zentrale Frage lautet: Wie baut man Vertrauen in autonome KI-Systeme auf, damit sie sicher autonom arbeiten können? Die Antwort liegt in Quality Gates und makroskopischen Metriken, die emergente Eigenschaften des Gesamtsystems messen. Autonome Fehlererkennung und ausgeklügelte Quality Gates helfen dem KI-System, Fehler zu identifizieren und zu beheben.

Developer entwickeln sich zu KI-Kuratoren – eine zukunftsweisende Rolle, die weit über traditionelle Programmierung hinausgeht. Statt Code Zeile für Zeile zu schreiben, orchestrieren KI-Kuratoren intelligente Systeme: Sie definieren Architektur, etablieren Qualitätsstandards und schaffen adaptive Frameworks, während KI-Systeme die eigentliche Codegenerierung übernehmen.

KI-Kuratoren befähigen ihre Systeme zur selbstständigen Weiterentwicklung: Sie implementieren Lernmechanismen, die es dem System ermöglichen, aus Fehlern zu lernen, neue Technologien zu integrieren, sich an veränderte Anforderungen anzupassen und eigenständig Fähigkeiten zu erweitern. Durch kontinuierliche Validierung und strategische Führung entstehen Systeme, die nicht nur funktionieren, sondern sich proaktiv verbessern und mit dem Puls der Zeit entwickeln.

Als Beispiel für AI-First-Arbeitsweise: Das Recruiting-Startup Mercor erzielte mit 30 Mitarbeitern 100 Millionen US-Dollar jährliche Umsatzrate. Dieses technologienahe Startup ist ein Sonderfall und als AI-natives Unternehmen besonders früh dran – das Beispiel illustriert jedoch, in welche Richtung sich Automatisierungsgrade entwickeln könnten, auch wenn solche Ergebnisse noch nicht branchenübergreifend Standard sind.



Source link

Entwicklung & Code

Rust Coreutils 0.5.0 erreicht 88 Prozent GNU-Kompatibilität


Das Projekt uutils hat Version 0.5.0 seiner Rust Coreutils veröffentlicht. Die in Rust geschriebene Neuimplementierung klassischer Unix-Kommandozeilenprogramme erreicht damit 87,75 Prozent Kompatibilität zur GNU-Test-Suite – ein Anstieg um knapp zwei Prozentpunkte gegenüber Version 0.4.0. Von insgesamt 645 Tests bestehen die Rust Coreutils nun 566, während 55 fehlschlagen, 23 übersprungen werden und einer zu einem Fehler führt.

Weiterlesen nach der Anzeige

Die Entwickler haben die Referenz-Test-Suite von GNU Coreutils 9.8 auf 9.9 aktualisiert, wodurch elf neue Tests hinzukamen. Trotz dieser zusätzlichen Prüfungen konnten 22 weitere Tests erfolgreich absolviert werden. Besonders hervorzuheben sind Verbesserungen bei den Utilities fold, cksum, install, numfmt und seq. Das Tool fold unterstützt nun kombinierende Unicode-Zeichen für korrekte Textumbrüche, während cksum mit hashsum zusammengeführt wurde und nun eine einheitliche Checksum-Funktion bietet.

Mit Version 0.5.0 erweitert das Projekt seinen Plattform-Support erheblich. OpenBSD wurde in die CI-Pipeline aufgenommen, die Redox-OS-Unterstützung reaktiviert und der Cygwin-Support in der uucore-Bibliothek verbessert. Als Folge hiervon können nun zehn zuvor übersprungene Tests ausgeführt werden. Die Rust Coreutils laufen damit offiziell auf Linux-Distributionen wie Ubuntu 25.10, FreeBSD, OpenBSD, Windows via Cygwin und dem experimentellen Betriebssystem Redox.

Canonical hatte bereits angekündigt, die Rust Coreutils in Ubuntu standardmäßig einzusetzen – primär aufgrund der Vorteile von Rust in puncto Speichersicherheit. Die Version 0.3.0 hatte bereits gezeigt, dass das sort-Tool in CPU-lastigen Szenarien bis zu 3,7-mal schneller arbeitet als sein GNU-Pendant – andere Tools wie expand (1,8×) oder nl (1,57×) zeigen ebenfalls deutliche Geschwindigkeitsgewinne als die GNU-Pendants. Bei IO-gebundenen Operationen fallen die Unterschiede geringer aus.

Trotz der Fortschritte gibt es weiterhin Herausforderungen. Von den 55 fehlgeschlagenen Tests betreffen einige kritische Edge-Cases bei Tools wie cksum (crc32b mit --raw-Flag), od (Floating-Point-Operationen) und chroot. Auf GitHub verzeichnet das Projekt rund 380 offene Issues, die sich mit verbliebenen Inkompatibilitäten befassen. Für Administratoren, die einen produktiven Einsatz erwägen, empfehlen sich umfangreiche Tests der eigenen Skripte – insbesondere solche mit GNU-spezifischen Flags oder ungewöhnlichen Optionskombinationen.

Weiterlesen nach der Anzeige

Die Sicherheitsvorteile von Rust kommen bei den Coreutils zum Tragen: Speicherfehler wie Buffer-Overflows und unsichere Path-Traversal-Operationen gehören der Vergangenheit an. Tools wie chmod nutzen bereits sichere Traversierungsmethoden. Allerdings warnen Kritiker vor neuen Fehlerklassen, die durch Rust-spezifische Ownership-Semantik entstehen könnten. Im Gegensatz zu den jahrzehntelang gehärteten GNU Coreutils ist die Rust-Variante noch vergleichsweise jung.

An Version 0.5.0 haben sechs neue Contributor mitgewirkt. Das Projekt ruft zu Übersetzungen via Weblate auf und bittet um Unterstützung über GitHub Sponsors. Die Maintainer-Basis umfasst etablierte Entwickler wie Sylvestre Ledru von Debian und Daniel Hofstetter, der in einem iX-Interview die langfristigen Ziele des Projekts erläuterte.

Für Distributionen stellt sich die Frage nach der Paketierung: Ubuntu 25.10 setzt die Rust Coreutils standardmäßig ein, Nutzer können per apt purge coreutils-from-uutils zu den GNU-Varianten zurückkehren. FreeBSD bietet einen Port über FreshPorts an. Die MIT-Lizenz der Rust Coreutils ist mit der GPL der GNU Coreutils kompatibel und erlaubt eine problemlose Integration in Distributionen.

Die Download-Binaries für Version 0.5.0 stehen auf der Projekt-Website und über die GitHub-Releases bereit. Anwender sollten vor einem produktiven Einsatz die Test-Coverage-Dokumentation konsultieren und kritische Workflows prüfen.


(fo)



Source link

Weiterlesen

Entwicklung & Code

Verbindungsabbrüche bei heise online durch Cookies – eine Spurensuche


close notice

This article is also available in
English.

It was translated with technical assistance and editorially reviewed before publication.

In der Webentwicklung schreiben wir nicht nur neue Software, sondern es erreichen uns natürlich auch Fehlermeldungen. Meistens können wir schnell helfen oder den Bugfix auf jeden Fall für einen der nächsten Sprints einplanen. Aber manche Fehler sind hartnäckiger und haben am Ende eine ganz simple Ursache. Um solch einen Fehler geht es heute.

Weiterlesen nach der Anzeige


Ich roll dann mal aus - Hilko Holweg

Ich roll dann mal aus - Hilko Holweg

Hilko Holweg ist Frontend-Developer bei Heise Medien, wo es ihm besonders die Web-Performance angetan hat. Neben dem Frontend interessiert er sich auch für vieles mehr, das mit Technik zu tun hat. So schrieb er beispielsweise für die c’t einen Artikel über einen digitalen Assistenten mit Offline-Spracherkennung auf Basis des Raspberry Pi.

Eine Zeit lang erreichten uns immer mal wieder Berichte, dass bei Usern die Verbindung zu www.heise.de mit der Meldung ERR_HTTP2_PROTOCOL_ERROR nicht zustande kam. Schnell kristallisierte sich heraus, dass die betroffenen User noch ein paar Gemeinsamkeiten hatten: Alle nutzten Chrome als Browser und waren regelmäßige Besucher unseres Angebots. Damit war der Fehler zwar schon etwas eingegrenzt, aber unser größtes Problem war: Wir selbst konnten den Fehler lange Zeit nicht nachstellen.

Die Überlegungen gingen dennoch weiter. Was sammeln User (leider heutzutage) zuhauf, wenn sie auf einem weitgehend werbefinanzierten Angebot wie heise online unterwegs sind? – Cookies. Ein Test mit betroffenen Usern sorgte dann immerhin für einen Workaround: Cookies löschen half.

Zunächst hatten wir die Cookie-Größe im Verdacht und testeten mit besonders großen Cookies, aber auch damit ließ sich das Problem für uns nicht reproduzieren. Doch dann meldete sich ein Kollege aus der Redaktion mit demselben Fehler – er bekam ihn sogar regelmäßig. Wir baten ihn um Hilfe bei der Lösung, und er gab Bescheid, sobald der Bug erneut auftrat. Endlich konnten wir das Problem direkt beobachten.

Mit tcpdump schnitten wir den Netzwerkverkehr zwischen uns und dem Browser auf dem Load-Balancer (BigIP) mit, der TLS und HTTP2 termininiert. Dabei stellte sich heraus, dass BigIP selbst die HTTP2-Verbindung wegen eines „Protokollfehlers“ beendete. Da heise online nicht einfach eine direkte Verbindung vom Browser des Users zu unserem Webserver hat, sondern noch diverse (Netzwerk-)Infrastruktur dazwischen liegt, war es für uns schon mal sehr hilfreich, den Punkt ausfindig zu machen, an dem die Verbindung bricht und welcher Teil in der Kette diesen Abbruch auslöst.

Weiterlesen nach der Anzeige

Mit den gewonnenen Erkenntnissen durchforsteten wir die Chrome-Bug-Reports. Bei einem Report war ein HTTP2-Protokoll-Mitschnitt angefügt, bei dem wir sehen konnten, dass Chrome jeden Cookie im HTTP2-Request mit einem separaten Set-Cookie-Header sendete. Das brachte uns auf die Idee, statt der Cookie-Größe einfach mit der schieren Anzahl zu experimentieren, und siehe da: Mit sehr vielen, kleinen Cookies ließ sich das Problem reproduzieren.

Ab hier wurde es dann einfach. Mithilfe unserer Admins fanden wir eine Einstellung in der BigIP, die die maximal zulässige Anzahl der Header setzte. Dieses Limit verschoben wir nun deutlich nach oben und schon war das Problem gelöst. Jedenfalls fürs Erste, denn natürlich ist das neue höhere Limit mit noch mehr Cookie-Headern ebenfalls wieder erreichbar, und der Fehler käme zurück.

Am Fehler sind aber noch ein paar Dinge interessant. In HTTP/1.x waren mehrere Cookie-Header noch unzulässig (siehe RFC 6265), in HTTP/2 hingegen kann der User Agent jedes Cookie als einzelnen Header senden (siehe RFC 7540) und genau das hat Chrome hier getan. Dieses Verhalten ist offensichtlich eine Optimierung, denn das Übertragen sich wiederholender Header lässt sich in HTTP/2 mit der HPACK-Header-Komprimierung (siehe RFC 7541) enorm optimieren. Das funktioniert aber nur für Header, die sich nicht ständig ändern. Ein großer Cookie-Header für alle Cookies müsste also immer wieder komplett neu übertragen werden, sobald sich auch nur ein einzelnes Cookie ändert.

Chrome zeigte leider in den Developer-Tools nichts davon an. Dort wird immer nur ein Cookie-Header gelistet, was die Fehlersuche nicht unbedingt erleichtert hat.

Ob das nun eine Problemlösung oder lediglich ein großes Pflaster ist, wird die Zeit zeigen. Die Ursachenforschung war aber definitiv mal wieder eine der interessanteren Recherchen im Developer-Alltag.


(rme)



Source link

Weiterlesen

Entwicklung & Code

React2Shell-Patch unzureichend, Angriffe weiten sich aus


Die Patches zum Schließen einer kritischen Sicherheitslücke im React-Server sind unvollständig, erklärt Meta. Admins sollen umgehend die neuen Aktualisierungen anwenden, um weitere entdeckte Sicherheitsprobleme auszubessern, empfiehlt das Unternehmen.

Weiterlesen nach der Anzeige

In einem Blog-Beitrag erklären die React-Entwickler, dass die zuvor veröffentlichten Patches anfällig sind. „Wenn du bereits die Updates gegen die kritische Sicherheitslücke in der vergangenen Woche angewendet hast, musst du nochmal aktualisieren“, schreiben sie in einem hervorgehobenen Eintrag. „Wenn du auf 19.0.2, 19.1.3 oder 19.2.2 aktualisiert hast, sind diese [Patches] unvollständig und du musst noch einmal aktualisieren“, präzisieren sie.

IT-Sicherheitsforscher haben demnach drei weitere Sicherheitslücken in den React-Server-Komponenten entdeckt, als sie versucht haben, die Patches aus der Vorwoche zu missbrauchen. Die neuen Schwachstellen ermöglichen kein Einschleusen und Ausführen von Schadcode, die bisherigen Patches unterbinden diesen Angriff zudem effektiv, ergänzen die React-Entwickler. Neu sind Denial-of-Service-Lücken (CVE-2025-55184, CVE-2025-67779, CVSS 7.5, Risiko „hoch“) und eine Schwachstelle, die Sourcecode exponieren kann (CVE-2025-55183, CVSS 5.3, Risiko „mittel“). Die Schwachstellen finden sich in denselben Paketen und Versionen wie die bereits aktiv missbrauchte Sicherheitslücke (CVE-2025-55182, CVSS 10.0, Risiko „kritisch“).

Betroffen sind die Versionen 19.0.0, 19.0.1, 19.0.2, 19.1.0, 19.1.1, 19.1.2, 19.2.0, 19.2.1 und 19.2.2 von „react-server-dom-webpack“, „react-server-dom-parcel“ und „react-server-dom-turbopack“. In den Fassungen 19.0.3, 19.1.4 und 19.2.3 haben die Programmierer die sicherheitsrelevanten Fehler korrigiert.

​Googles Threat-Intelligence-Team hat zum vergangenen Wochenende Erkenntnisse über laufende Angriffe auf die „React2Shell“ genannte Lücke CVE-2025-55182 zusammengefasst. Demnach hat Google kurz nach Bekanntwerden des Sicherheitslecks Anfang Dezember weitreichende Exploit-Versuche auf viele Cluster beobachtet, die von opportunistischem Cybercrime bis zu der Spionage verdächtigen Gruppierungen ausgehen. Google nennt von China ausgehende Spionageversuche, finanziell motivierte Aktivitäten und auch Attacken aus dem Iran. In den Kampagnen haben die Täter versucht, etwa Minocat-Tunneler, Snowlight-Downloader, Hisonic- und Compood-Backdoors sowie Krypto-Miner zu installieren. Einige der Beobachtungen überschneiden sich mit denen des IT-Sicherheitsunternehmens Huntress sowie mit weiteren bereits beobachteten Angriffen auf die Lücke.


(dmk)



Source link

Weiterlesen

Beliebt