Connect with us

Datenschutz & Sicherheit

Undurchsichtige Gesundheitsdatenbank-Pläne nach Brandbrief vorerst gestoppt



Die rot-schwarze Koalition in Berlin wollte die Charité dazu befähigen, auf Basis eines reformierten Universitätsmedizingesetzes eine neue Gesundheitsdatenbank aufzubauen. Ziel ist es, den Standort Berlin als Zentrum für Wissenschaft, Forschung, Lehre und Innovation zwischen Hochschulen und Instituten zu fördern. Wie sensible personenbezogene Daten geschützt werden, bleibt in dem Vorhaben jedoch unklar, kritisiert die Berliner Datenschutzbeauftragte Meike Kamp.

Als dringliche Beschlussempfehlung hatten CDU und SPD am 15. Januar eine Änderungsvorlage ins Abgeordnetenhaus eingebracht, bevor sich Kamp am 20. Januar einschaltete. Nach scharfer Kritik in einem Brandbrief, den wir veröffentlichen, teilte der Sprecher für Inneres der SPD-Fraktion, Martin Matz, nun die vorläufige Verfahrenseinstellung mit.

Matz zeigte sich Kamps Kritik gegenüber offen. Die Datenbank-Pläne erachte er aber weiterhin als wichtig und will das Vorhaben bis 2029 verwirklichen. Wie es mit dem Vorhaben weitergeht, ist derzeit allerdings offen: In der heutigen Plenarsitzung stand das Thema auf der Tagesordnung, wurde dann aber kurzfristig vertagt.

Senat verstößt gegen Berliner Datenschutzgesetz

Betreffen neue Gesetzesvorhaben den sensiblen Bereich der personenbezogenen Datenverarbeitung – wie in diesem Fall von Gesundheitsdaten – schreibt das Berliner Datenschutzgesetz vor, die Datenschutzbeauftragte verpflichtend zu konsultieren.

Den Kontakt hatten in diesem Fall aber weder Senat noch Abgeordnetenhaus gesucht. Laut des Brandbriefs hatte die Koalition das vor dem parlamentarischen Beschluss auch nicht mehr vor. Schließlich hatten offenbar Teile der Opposition die Datenschutzbehörde auf den Änderungsentwurf hingewiesen.

Unklar ist bisher auch, warum die Charité als weitere betroffene Partei nicht in das Vorhaben einbezogen wurde. Schließlich wäre sie das ausführende Organ gewesen. Nach Angaben eines Sprechers der Charité war sie weder Initiator noch auf andere Weise in die Formulierung des Änderungsentwurfs eingebunden.

Zweck der Datenbank nicht ersichtlich

Kritisch beurteilte Kamp den Änderungsentwurf außerdem hinsichtlich unklarer und unverständlicher Inhalte. Die Datenbank soll mit nicht personenbezogenen Daten gefüttert werden, heißt es im ersten Absatz des neuen Paragraphen. Jedoch würden die folgenden Absätze dann nur Regelungen für den Umgang mit personenbezogenen Daten behandeln.

Es sei daher anzunehmen, dass an der Charité erhobene personenbezogene Daten in nicht personenbezogene Daten umgewandelt werden. Dafür wären dann Vorgaben für Anonymisierungsverfahren notwendig. Angaben, um welche Daten es konkret gehe, wer sie erheben soll und wie sie anonymisiert und in die Datenbank eingespeist werden sollen, fehlen jedoch.

Die jetzige Fassung sehe außerdem eine „staatenübergreifende Nutzung“ vor. Daten könnten somit auch an Dritte außerhalb der EU übermittelt werden. Handele es sich dann doch um personenbezogene Daten, greifen für diesen Fall bestehende Regelungen, unter anderem die Datenschutzgrundverordnung.

Die Notwendigkeit einer neuen Vorschrift bleibt unklar, urteilt Kamp. Erst einmal müsse der Zweck einer neuen Gesundheitsdatenbank verdeutlicht werden. Dann könne geprüft werden, ob dafür eine Erweiterung der bestehenden Gesetzeslage nötig wäre.

Datenschutz zuerst

Tobias Schulze, Fraktionsvorsitzender für die Linke im Berliner Abgeordnetenhaus, schließt sich der geäußerten Kritik an: „Solche Nachlässigkeiten können wir uns besonders in dem sensiblen Bereich von Gesundheitsdaten nicht leisten. Forschung mit Gesundheitsdaten kann sinnvolle Dienste leisten. Gerade damit dieser Mehrwert nicht delegitimiert wird, ist wirkungsvoller Datenschutz besonders wichtig.“

Anonymisierung und Pseudonymisierung sind entscheidende Schritte auf dem Weg dahin, da sie „wichtige Maßnahmen für eine datenschutzkonforme und datensparsame Datenverarbeitung“ darstellen, betont Simon Rebiger, Pressesprecher der Berliner Datenschutzbeauftragten gegenüber netzpolitik.org.

Anonymisierte Daten dürfen nicht mit verfügbaren Zusatzinformationen auf eine betroffene Person zurückzuführen sein, betont Rebiger. Bei vielen Methoden verbleiben jedoch Restrisiken. Schätzen Verantwortliche diese nach allgemeinem Ermessen als unbeachtlich ein, gelten Daten als anonym und unterliegen nicht mehr dem Datenschutzrecht.

Im Unterschied dazu müsse bei der Pseudonymisierung nur sichergestellt sein, dass eine bestimmte Personengruppe, der die Daten zugänglich gemacht wird, Betroffene in keinem Fall identifizieren kann, so Rebiger. In solchen Fällen können pseudonymisierte Daten unter bestimmten Umständen als anonym gelten. Ansonsten bleiben die Daten personenbezogen und sind datenschutzrechtlich beschränkt.

Derzeit erarbeitet die Datenschutzkonferenz praktische Hilfestellungen für auf Einzelfälle zugeschnittene Verfahren. Sensible Gesundheitsdaten werden zum Beispiel bei der Übermittlung von Daten aus dem Krebsregister erfasst oder wenn KI-Modelle mit radiometrischen Aufnahmen trainiert werden.


Hier das Dokument in Volltext:


Viertes Gesetz zur Änderung des Berliner Universitätsmedizingesetzes (Drucksache 19/2763)

Änderungsantrag der Fraktion der CDU und der Fraktion der SPD
Dringliche Beschlussempfehlung des Ausschusses für Wissenschaft und Forschung vom 12. Januar 2026
Hier: § 38 Zentrale Gesundheitsdatenbank

Sehr geehrte Frau Präsidentin,
sehr geehrte Vorsitzende der Ausschüsse des Abgeordnetenhauses von Berlin,

ich nehme Bezug auf einen Änderungsantrag zum Vierten Gesetz zur Änderung des Berliner Universitätsmedizingesetzes der Fraktion der CDU und der Fraktion der SPD, der im Ausschuss für Wissenschaft und Forschung am 12. Januar 2026 angenommen und zur dringlichen Beschlussfassung in die 78. Plenarsitzung am 15. Januar 2026 eingebracht wurde.

Die dringliche Beschlussempfehlung sieht durch Einfügung eines neuen § 38 in das Berliner Universitätsmedizingesetz die Errichtung einer zentralen Gesundheitsdatenbank durch die Charité vor, die entsprechend mit Verarbeitungen von Gesundheitsdaten einhergeht. Ich bin entgegen der Vorgaben aus § 11 Abs. 2 Satz 2 Berliner Datenschutzgesetz bisher nicht zu diesem Gesetzesentwurf beteiligt bzw. angehört worden, obwohl die mit der Vorschrift vorgesehenen Errichtung einer zentralen Gesundheitsdatenbank auch die Verarbeitung von personenbezogenen Gesundheitsdaten und damit besonders sensible Bereiche der personenbezogenen Datenverarbeitung betrifft. Irritierend ist insbesondere, dass – wie die Erörterung in der Sitzung des Ausschusses für Wissenschaft und Forschung zeigte – die Beteiligung meiner Behörde auch vor Beschlussfassung im Parlament bewusst nicht mehr vorgesehen ist.

Auch inhaltlich ist die vorgeschlagene Regelung zu kritisieren: Abgesehen davon, dass die Beschlussempfehlung und der Änderungsantrag keine Begründung enthalten, aus welchen Grün- den aus Sicht des Gesetzgebers die Errichtung einer Gesundheitsdatenbank notwendig erscheint, ist der Gesetzesentwurf in seiner derzeitigen Form unklar und unverständlich. Meinen für den Bereich Wissenschaft und Forschung zuständigen Mitarbeiter:innen, die eine besondere Expertise in Bezug auf die Voraussetzungen für die Zulässigkeit der Verarbeitung personenbezogener Gesundheitsdaten haben, erschließt sich der konkrete Regelungsgehalt des § 38 des Entwurfs nicht. Ich habe daher erhebliche Zweifel, ob den Rechtsanwender:innen, insbesondere in der Charité und unter den Forschenden, die Voraussetzungen der Norm in der derzeitigen Fassung verständlich werden wird.

Dies möchte ich im Einzelnen erläutern:

  • Nach Abs. 1 soll eine zentrale Datenbank mit „nicht personenbezogenen Gesundheitsdaten“ errichtet werden. Aus der Vorschrift wird nicht klar, was hierunter zu verstehen ist und woher diese Daten stammen. Es ist davon auszugehen, dass es sich um die Gesundheitsdaten handelt, die die Charité im Rahmen der Behandlung und Versorgung ihrer Patient:innen erhoben hat. Damit diese personenbezogenen Daten nicht mehr personenbezogen sind, muss zunächst eine Anonymisierung durch die Charité erfolgen. Dies setzt eine Regelung voraus, die die Verarbeitung der Daten zum Zweck der Anonymisierung zum Gegenstand hat. Eine solche enthält die Vorschrift jedoch nicht.
  • Abs. 3 legt fest, dass eine „staatenübergreifende Nutzung“ der Datenbank zulässig sein soll, sofern die „Vorgaben des Datenschutzes“ eingehalten werden. Fragen wirft an dieser Stelle bereits auf, dass in Absatz 1 der Vorschrift von einer Datenbank mit nicht personenbezogenen Daten die Rede ist, hier jedoch auf die Vor- gaben des Datenschutzes hingewiesen wird. Zudem ist die Vorschrift unbestimmt und zeigt keinen klaren Regelungsinhalt auf. Eine „staatenübergreifende Nutzung“ ist nichts anderes als eine Übermittlung oder eine Offenlegung der entsprechenden Daten an Dritte außerhalb Deutschlands oder der EU. Entsprechende Regelungen finden sich bereits in § 25 LKG bzw. in § 6 Abs. 3 GDNG sowie bei möglicher Drittstaatenübermittlung in Kapitel V der DSGVO.
  • Abs. 4 S. 1 regelt sodann, dass auch personenbezogene Daten „im Rahmen einer Nutzungsvereinbarung“ zu erheben sind. Gänzlich unklar bleibt, was unter einer solchen Nutzungsvereinbarung verstanden und zwischen wem eine solche Nutzungsvereinbarung geschlossen werden soll. Ferner bleibt unklar, durch wen hier- bei welche Stellen personenbezogenen Daten erhoben werden sollen, und ob und inwieweit diese in die Gesundheitsdatenbank aufzunehmen sind
  • Ferner sind nach Abs. 4 S. 2 „anderweitig erhobene und für Forschung und Lehre relevante Daten unter den Voraussetzungen des § 17 BlnDSG […] in die Gesundheitsdatenbank aufzunehmen“. Diese Vorschrift ist ebenfalls unbestimmt und erfüllt den verfassungsgemäßen Grundsatz der Bestimmtheit des Gesetzes nicht. Zunächst ist unklar, welche Daten in die Gesundheitsdatenbank aufgenommen werden sollen. Aus der Formulierung „anderweitig erhoben“ wird nicht deutlich, wer diese Daten erhoben haben soll (ggf. die Charité). Ferner ist unklar, in welchen Kontexten die Daten erhoben worden sein sollen. Darüber hinaus ist nicht klar, ob es sich um Gesundheitsdaten handeln soll, was ausdrücklich im Gesetzestext zu benennen wäre. Um dem verfassungsrechtlichen Bestimmtheitsgebot gerecht zu werden, müsste explizit beschrieben werden, in welchem Zusammenhang von wem welche personenbezogenen Daten erhoben worden sind.
  • Die Formulierung, dass „für Forschung Lehre relevante Daten“ aufzunehmen sind, ist ebenfalls zu unbestimmt. Unklar bleibt, was unter „Relevanz“ zu verstehen ist und wer über diese Relevanz entscheidet.
  • Auch der Verweis auf § 17 BlnDSG ist nicht verständlich. Zunächst ist anzumerken, dass das BlnDSG nach § 2 Abs. 1 BlnDSG für die Verarbeitung personenbezogener Daten durch Behörden und sonstige öffentliche Stellen des Landes Berlin gilt. Sollte hiermit die Charité angesprochen werden, ist § 25 LKG eine speziellere Norm, die vorrangig anzuwenden wäre. Für Forschende, Studierende oder sonstige Nutzende kann § 17 BlnDSG keine Anwendung finden, weil es sich bei diesem Personenkreis um keine öffentlichen Stellen des Landes Berlin handelt, für die das BlnDSG ausschließlich Anwendung findet (§ 2 Abs. 1 BlnDSG).
  • Ferner enthält Abs. 4 S. 2 eigene Voraussetzungen, die vor Aufnahme der Daten in die Gesundheitsdatenbank zu beachten sind. Gänzlich unklar bleibt das Verhältnis dieser Voraussetzungen zu den in § 17 BlnDSG und § 25 LKG formulierten Voraussetzungen, die die Verarbeitung von (Gesundheits-)Daten zu wissenschaftlichen Forschungszwecken zum Gegenstand haben. Es wird nicht deutlich, welche Regelungen des § 17 BlnDSG und § 25 LKG entsprechend gelten sollen und in welchem Verhältnis diese Rechtsgrundlagen zur Verarbeitung der Daten in der Gesundheitsdatenbank stehen. Hierbei ist ebenfalls nicht nachvollziehbar, wie diese Voraussetzungen erfüllt werden können oder welche Voraussetzungen konkret zu erfüllen sind.
  • Abs. 4 S. 2 regelt ausdrücklich die Aufnahme der Daten in die Gesundheitsdatenbank, nicht die erst nachgelagerte Nutzung durch Forschende oder Studierende. Abs. 4 S. 2 Nr. 2 regelt jedoch beispielsweise als Voraussetzung, dass „der Forschungszweck die Möglichkeit der Zuordnung erfordert, die betroffene Person zu diesem Zweck eingewilligt hat“. Diese Voraussetzung kann jedoch erst dann geprüft werden und erfüllt sein, wenn eine Nutzung der Datenbank für ein Forschungsvorhaben erfolgen soll. Der Forschungszweck ergibt sich nämlich erst aus einem konkreten Forschungsvorhaben, für das eine Nutzung der in der Gesundheitsdatenbank aufgenommenen Daten beantragt wird. Für die vorgelagerte und hier ausschließlich geregelte Aufnahme der Daten in die Gesundheitsdatenbank kann die Voraussetzung des Nr. 2 daher nicht geprüft werden. Dasselbe gilt für die Voraussetzung Nr. 3, nach der das öffentliche Interesse an der Durchführung eines konkreten Forschungsvorhabens überwiegen muss und der konkrete Forschungszweck nicht auf andere Weise zu erreichen ist.
  • Gänzlich unbeachtet bleibt bei Abs. 4 S. 2 auch, dass die Datenbank nach Abs. 2 nicht nur zu wissenschaftlichen und forschungsbezogenen, sondern auch zu lehrbezogenen und innovationsorientierten Zwecken genutzt werden soll, über die Nutzung zu (wissenschaftlichen) Forschungszwecken also hinausgeht.
  • Ferner enthält Abs. 4 S. 3 die Regelung, dass personenbezogene Daten, soweit dies nach dem Forschungszweck erforderlich ist, zu anonymisieren sind. Auch hier stellt sich das Problem, dass auf einen konkreten Forschungszweck abgestellt wird, und nicht auf die grundsätzliche Aufnahme / Verarbeitung der personenbezogenen Daten in der Datenbank.
  • Schließlich sei insgesamt anzumerken, dass zwar Abs. 1 ausdrücklich regelt, dass eine zentrale Datenbank mit nicht personenbezogenen Daten errichtet werden soll, die weiteren Absätze jedoch nur Regelungen zu personenbezogenen Daten enthalten. Ich empfehle daher dringend, die Vorschrift erheblich zu überarbeiten. Dabei wäre es zunächst erforderlich, die mit der Errichtung der Gesundheitsdatenbank verfolgten Zwecke klarzustellen, und dabei auch zu überprüfen, ob die Vorschrift vor dem Hintergrund bereits bestehender gesetzlicher Regelungen überhaupt notwendig ist.

Ich empfehle daher dringend, die Vorschrift erheblich zu überarbeiten. Dabei wäre es zunächst erforderlich, die mit der Errichtung der Gesundheitsdatenbank verfolgten Zwecke klarzustellen, und dabei auch zu überprüfen, ob die Vorschrift vor dem Hintergrund bereits bestehender gesetzlicher Regelungen überhaupt notwendig ist.



Source link

Datenschutz & Sicherheit

Google zieht Millionen Geräte aus IPIDEA-Residential-Proxy-Netz


close notice

This article is also available in
English.

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

Residential Proxies verteilen Netzwerkverkehr von Kunden auf Geräte, die bei Internetprovidern in den Endkundenbereichen stehen. Darüber leiten vielfach Cyberkriminelle ihre Daten, um ihre Herkunft zu verschleiern. Nun ist Googles Threat Intelligence Team ein empfindlicher Schlag gegen das als bislang größte Residential-Proxy-Netzwerk IPIDEA gelungen.

Weiterlesen nach der Anzeige

Einerseits hat Google zusammen mit Partnern Domains vom Netz genommen, die zur Steuerung von Geräten und Proxy-Traffic dadurch genutzt wurden. Andererseits haben die IT-Forscher technische Informationen zu Software-Development-Kits (SDKs) und damit entwickelter Proxy-Software für das IPIDEA-Netz an Plattformanbieter, Strafverfolger und Forschungseinrichtungen weitergereicht, um ein Bewusstsein bei allen potenziell Betroffenen zu schaffen.

Die SDKs werden etwa Entwicklern über mehrere Mobil- und Desktop-Plattformen angeboten und dienen dazu, Geräte von Nutzerinnen und Nutzern heimlich dem IPIDEA-Netzwerk hinzuzufügen. Das gemeinsame Vorgehen gegen diese SDK hilft, die Weiterverbreitung des Netzwerks einzudämmen. Auf zertifizierten Android-Geräten hat Google zudem die Sicherheitsmechanismen nachgeschärft. Google Play Protect soll seitdem User warnen und die Apps entfernen, die das IPIDEA-SDK enthalten – und ihre künftige Installation unterbinden.

IP-Adressen aus Ländern wie den USA, Kanada und Europa seien besonders begehrt, erklärt Google in der Analyse. Die Proxy-Software sei entweder auf den Geräten vorinstalliert oder komme mit trojanisierten App-Versionen auf die Smartphones, führt Google weiter aus. Einige Nutzerinnen und Nutzer könnten sich solche Software sogar willentlich installieren, angelockt von dem Versprechen, ihre verfügbare Bandbreite zu monetarisieren. Sind die Geräte erst einmal im Residential-Proxy-Netzwerk angemeldet, verkaufen die Betreiber Zugriff darauf an ihre Kunden.

Die Betreiber solcher Proxy-Netze betonen oft die Privatsphäre und freie Meinungsäußerung als Nutzen der Residential Proxies. Googles Untersuchungen zeigten jedoch, dass diese Netze zu einem überragenden Teil von bösartigen Akteuren genutzt werden. IPIDEA hat Bekanntheit dafür erlangt, mehrere Botnetze zu beherbergen. Das SDK spielt demnach eine Schlüsselrolle dabei, Geräte den Botnetzen hinzuzufügen. Das betreffe das Badbox-2.0-Botnetz, das Aisuru-Botnetz und das Kimwolf-Botnet sowie weitere.

Google hat IPIDEA-Nutzung zudem zum Ausführen von Spionage und zum Verüben von Verbrechen durch Bedrohungsakteure beobachtet. Allein in einem siebentägigen Zeitraum im Januar hat Google mehr als 550 Cybergangs verfolgen können, die mit den IPIDEA-Exit-Knoten ihre Aktivitäten zu verschleiern versuchten. Darunter waren Gruppierungen aus China, Iran, Nordkorea und Russland. Sie haben damit unbefugt auf Security-as-a-Service-(SaaS)-Umgebungen und On-Premises-Infrastruktur von Opfern zugegriffen und Passwort-Spraying-Attacken gestartet.

Bei der Untersuchung haben Googles IT-Sicherheitsforscher 3075 ausführbare Windows-Dateien gefunden sowie mehr als 600 Android-Apps, die Verweise auf die Tier-1-Domains des Command-and-Control-Netzwerkes enthalten. Die mobilen Apps hatten zu einem großen Teil normale Funktionen von Tools, Spielen oder Inhaltsanzeigen, nutzten jedoch die IPIDEA-SDKs und aktivierten das Proxy-Verhalten zur Monetarisierung. Die Analyse schließt noch mit einigen Indizien für Infektionen (Indicators of Compromise, IOCs), mit denen Interessierte ihre Systeme auf möglichen Befall prüfen können.

Weiterlesen nach der Anzeige

Im Jahr 2024 warnte etwa der Identitätsverwaltungsdienstleister Okta davor, dass es zu vermehrten Credential-Stuffing-Angriffen kam. Diese gingen ebenfalls von Residential Proxies aus.


(dmk)



Source link

Weiterlesen

Datenschutz & Sicherheit

Sicherheitspatch: Authentifizierung von SolarWinds Web Help Desk umgehbar


Mehrere Softwareschwachstellen bedrohen Systeme mit SolarWinds Web Help Desk. Nutzen Angreifer die Lücken erfolgreich aus, können sie Systeme im schlimmsten Fall vollständig kompromittieren. Eine reparierte Ausgabe steht zum Download bereit.

Weiterlesen nach der Anzeige

In einem Beitrag zur gepatchten Version WHD 2026.1 sind unter anderem die Sicherheitslücken (CVE-2025-40536 „hoch“, CVE-2025-40537 „hoch“, CVE-2025-40551 „kritisch“, CVE-2025-40552 „kritisch“, CVE-2025-40553 „kritisch“, CVE-2025-40554 „kritisch“) aufgelistet. Admins sollten sicherstellen, dass sie die reparierte Ausgabe zeitnah installieren. Geschieht das nicht, könnten Angreifer nach erfolgreichen Attacken die volle Kontrolle über Systeme erlangen.

Über zwei kritische Schwachstellen können Angreifer Schadcode auf Hostsystemen ausführen. Die beiden verbleibenden kritischen Lücken betreffen die Authentifizierung, und Angreifer können etwa bestimmte Befehle ausführen, was eigentlich nur angemeldete Nutzer dürfen.

Wie Attacken im Detail ablaufen können, ist bislang nicht bekannt. Unklar ist auch, an welchen Parametern Admins bereits attackierte Systeme erkennen können. In der Warnmeldung gibt es derzeit keine Hinweise, dass Angreifer die Lücken bereits ausnutzen.

Ferner haben die Entwickler in der aktuellen Ausgabe eigenen Angaben zufolge mehrere Bugs ausgemerzt. So komme es etwa in FIPS-Umgebungen nicht mehr zu Verschlüsselungsfehlern. Es gibt aber auch noch ungelöste Fehler. Derzeit ist der Linux- und macOS-Support wegen Next.js-Problemen nicht gegeben.

Zusätzlich haben die Entwickler das Interface grafisch überarbeitet. Die Auswahl der neuen Oberfläche ist optional.

Weiterlesen nach der Anzeige


(des)



Source link

Weiterlesen

Datenschutz & Sicherheit

JavaScript-Sandbox vm2: kritische Lücke erlaubt Ausbruch


vm2 ist eine JavaScript-Sandbox für Node.js. Deren Entwicklung wurde 2023 eigentlich eingestellt. In der Software wurde eine weitere Sicherheitslücke entdeckt, die den Ausbruch aus der gesicherten Umgebung und die Ausführung von beliebigem Code ermöglicht. Ein Update steht bereit.

Weiterlesen nach der Anzeige

In der Schwachstellenmeldung erklären die Autoren, dass die Filterung der Eingaben an die Callback-Funktionen von Promise.prototype.then und Promise.prototype.catch umgangen werden kann. Dadurch können Angreifer aus der Sandbox ausbrechen und eigenen Code starten (CVE-2026-22709, CVSS 9.8, Risiko „kritisch“). Während die Callback-Funktion von localPromise.prototype.then in „lib/setup-sandbox.js“ eine Filterung vornimmt, fehlt diese in globalPromise.prototype.then, erklären die Autoren weiter. Der Patch für die Datei ist recht übersichtlich und ergänzt die Filterung.

Die Version 3.10.2 von vm2 korrigiert den Fehler. Ein Proof-of-Concept-Exploit ist bereits verfügbar. Bösartige Akteure können die Lücke daher schnell in ihr Standard-Repertoire aufnehmen. Seit wenigen Tagen ist zudem die noch aktuellere Version 3.10.3 verfügbar. Die Korrekturen darin sollen ebenfalls etwa Ausbrüchen aus der Sandbox vorbeugen. Entwickler sollten daher auf diese Version aktualisieren, sofern sie noch vm2 einsetzen.

Der Initiator des vm2-Projekts, Patrik Simek, hatte Mitte 2023 eigentlich das Ende des Projekts verkündet. Kurz zuvor wurde eine kritische Sicherheitslücke gefunden, für die keine Fehlerkorrektur programmiert wurde. Simek hatte daher Entwicklern empfohlen, stattdessen auf das ebenfalls quelloffene isolated-vm zu wechseln.

Bislang eher unbemerkt blieben neue Commits im Projekt von Ende Oktober 2025. Unter dem Titel „Resurrection“ hat Simek damit die Weiterentwicklung von vm2 mit Versionssprung auf 3.10 angestoßen. Während Simek sich ursprünglich deutlich zu den Gründen für das Aus geäußert hatte – die wachsende Komplexität von Node.js sei nicht mehr handhabbar –, finden sich keine Hinweise für die Motivation, nach mehr als zwei Jahren doch wieder weiterzumachen.

Wer bisher das Ende des Projekts nicht mitbekommen und daher eine veraltete, mit Sicherheitslücken gespickte Version von vm2 im Einsatz hat, sollte zügig auf die fehlerkorrigierte Fassung umsteigen.

Weiterlesen nach der Anzeige


(dmk)



Source link

Weiterlesen

Beliebt