Stimmen die Voraussetzungen, können Angreifer auf einer Node.js-Instanz aus der vm2-Sandbox ausbrechen und Schadcode ausführen. Ein Proof-of-Concept-Exploit ist öffentlich, bislang gibt es aber keine Berichte, dass Angreifer die Lücke bereits ausnutzen. Mittlerweile haben die Entwickler ein Sicherheitsupdate veröffentlicht.

Details zur Sicherheitslücke

Aus einer Warnmeldung auf GitHub geht hervor, dass die Schwachstelle (CVE-2026-26956) mit dem Bedrohungsgrad „kritisch“ eingestuft ist. Die Entwickler versichern, dass davon ausschließlich Node.js 25 bedroht ist. Sie geben an, die Lücke in v25.6.1 erfolgreich reproduziert zu haben. Von vm2 ist konkret die Versoin 3.10.4 verwundbar. Die Schwachstelle wurde in Version 3.10.5 geschlossen. Instanzen sind aber nur angreifbar, wenn WebAssembly exception handling und JSTag support aktiv sind.

Ist das gegeben, können Angreifer mit präparierten Anfragen Fehler auslösen, wodurch die vm2-Sicherheitsfilter umgangen werden. Im Anschluss können sie eigenen Code im Hostsystem ausführen. Aufgrund der Einstufung ist davon auszugehen, dass Systeme im Anschluss als vollständig kompromittiert gelten. Weitere Details zur Lücke und einem möglichen Ablauf von Attacken führen die Entwickler in der Warnmeldung aus.

(des)

Mit der wöchentlichen Aktualisierung in der Nacht zum Mittwoch hat Google den Webbrowser Chrome auf den Versionszweig 148 gebracht. Zunächst blieb die Versionsankündigung leer – inzwischen ist klar: Darin haben die Entwickler 127 Sicherheitslücken gestopft.

In der Versionsankündigung reißen die Chrome-Programmierer wie üblich kurz an, welche Schwachstellen von externen IT-Forschern gemeldet wurden. Drei erreichen die Risikoeinstufung „kritisch“, für eine davon ist auch die Prämie für die Meldenden klar: 43.000 US-Dollar erhalten sie dafür. Es handelt sich dabei um einen Integer-Überlauf in der Rendering-Engine Blink (CVE-2026-7896, CVSS laut CISA 8.8, Risiko laut Google „kritisch“). Unter iOS haben die Entwickler sich um eine Use-after-free-Lücke gekümmert (CVE-2026-7897, CVSS laut CISA 7.5, Risiko laut Google „kritisch“). Das eingebaute Remote-Desktop-Tool Chromoting weist ebenfalls eine Use-after-free-Schwachstelle auf (CVE-2026-7898, CVSS laut CISA 8.8, Risiko laut Google „kritisch“).

Bei einer Use-after-free-Schwachstelle greift der Programmcode auf bereits freigegebene Ressourcen zu. Deren Inhalte sind dadurch undefiniert; Angreifer können solche Lücken oftmals zum Einschleusen und Ausführen von Schadcode missbrauchen. Dazu genügt bei Webbrowsern in der Regel das Anzeigen von sorgsam präparierten Webseiten. Weitere 31 Sicherheitslücken gelten als Risiko „hoch“, 66 als „mittlerer“ Bedrohungsgrad und 27 noch als „niedrige“ Risikostufe.

Die Sicherheitslücken schließen die Chrome-Versionen 148.0.7778.120 für Android, 148.0.7778.96 für Linux und 148.0.7778.96/97 für macOS und Windows. Wer Chrome einsetzt, sollte rasch sicherstellen, dass der Webbrowser auf aktuellem Stand ist. Bislang scheint noch keine der Schwachstellen missbraucht zu werden, zumindest schreibt Google nichts davon.

Aktualisierung installieren

Die Updates lassen sich über den Versionsdialog anwenden. Nach Klick auf das Browser-Menü, das sich hinter dem Icon mit den drei aufeinander gestapelten Punkten verbirgt, und weiter über „Hilfe“ zu „Über Google Chrome“ öffnet er sich. Er zeigt den aktuell laufenden Softwarestand an und startet bei Verfügbarkeit die Installation der Aktualisierung. Unter Linux ist in der Regel die Softwareverwaltung der Distribution dafür aufzurufen. In den App-Stores der Mobiltelefone sind die neuen Fassungen in der Regel mit etwas Verzögerung verfügbar.

Da die Sicherheitslücken die Chromium-Basis betreffen, sollten auch Nutzerinnen und Nutzer der darauf aufbauenden Webbrowser wie Microsofts Edge schauen, ob für die Browser inzwischen eine Aktualisierung verfügbar ist.

Das Chrome-Update aus der vergangenen Woche hatte bereits 30 Schwachstellen ausgebessert. Die KI-Schwachstellensuche scheint sehr erfolgreich zu sein und den Entwicklern einige Arbeit zu bescheren. Am Ende bedeutet das jedoch, dass die Software deutlich sicherer wird.

(dmk)

Mit einer Handy-App sollen Menschen in der EU schon bald ihr Alter gegenüber Online-Diensten nachweisen können. Noch gibt es diese App nicht. Die EU-Kommission hat aber Code für Komponenten und Spezifikationen bereitgestellt, aus dem Entwickler:innen eigene Versionen der App bauen und auf den Markt bringen sollen. Die Alterskontroll-App könne ein weltweiter „Goldstandard“ werden, so die Hoffnung der Kommission.

Doch bei der App hat sich die Kommission für ein Verfahren zweier Software-Entwickler entschieden, die für den US-Konzern Google arbeiten. Die Technologie ist Open Source. Doch eine ebenfalls offene Alternative, die seit Jahren gut erforscht und nicht an ein kommerzielles Unternehmen gebunden ist, lehnte die Kommission ab.

Sicherheitsexpert:innen kritisieren die Entscheidung, weil die von der Kommission gewählten Verfahren weniger effizient und risikobehaftet seien. Außerdem fordern sie, Standards zu nutzen, die Abhängigkeiten von einzelnen Anbietern vermeiden. Nur so ließen sich bestimmte Funktionen und ein hohes Datenschutzniveau sicherstellen.

Der datensparsame Null-Wissen-Beweis

Die Alterskontroll-App ist quasi ein Vorläufer der geplanten EUDI-Wallet, die Ende 2026 EU-weit starten soll. Mit der App sollen Nutzer:innen gegenüber Online-Plattformen nachweisen können, dass sie ein bestimmtes Mindestalter erreicht haben.

Um ausschließlich die erforderliche Information – Mindestalter ja oder nein – zu offenbaren, lässt sich ein sogenannter Zero Knowledge Proof (ZKP) nutzen, zu Deutsch: Null-Wissen-Beweis. Das erlaubt eine datensparsame Verifizierung, ohne die zugrundeliegenden Daten der Nutzer:innen wie etwa das genaue Alter preiszugegeben.

Damit die Authentisierung sicher erfolgen kann, braucht es digitale Signaturen. Sie sichern weite Teile des Internets und die meisten digitalen Transaktionen ab, indem sie etwa – vergleichbar mit einer handschriftlichen Unterschrift – mathematisch beweisen, dass eine Nachricht von einem bestimmten Absender stammt.

Beweisen, dass es einen Beweis gibt

Bei der Alterskontroll-App wird das Attribut, das eine Person älter als X Jahre ist, vom sogenannten „Attestation Provider“ signiert. Diese Aufgabe können Banken, Mobilfunkanbieter oder staatliche Behörden übernehmen. Sie bestätigen so als vertrauenswürdige Stelle die Echtheit von Altersbestätigungen digital und geben diese an die App aus.

Allerdings gibt es noch ein Problem zu lösen: Wäre diese Bestätigung, die bei einem Altersnachweis mitgeliefert wird, immer gleich, lassen sich damit verschiedene Nachweisaktionen bei unterschiedlichen Behörden, Händlern oder Plattformen miteinander verknüpfen.

Das sollen „Anonymous Credentials“ verhindern, zu Deutsch: „anonyme Anmeldedaten“. Hier werden bei jeder Altersübermittlung neue, einmalige Beweise erzeugt, die an verschiedene Dienste, die den Nachweis prüfen, weitergegeben werden. Damit belegen Nutzer:innen, dass sie eine gültige Signatur für ihren Altersnachweis haben – ohne den Nachweis selbst oder die Signatur preiszugeben. Dank dieser wechselnden Beweise können die sogenannten Verifier nicht erkennen, dass es sich um dieselbe Person handelt – selbst wenn sie die Beweise untereinander vergleichen.

Zwei konkurrierende kryptografische Verfahren

Damit der Zero Knowledge Proof mit der Alterskontroll-App gelingt, kommen mehrere kryptografische Verfahren für Anonymous Credentials grundsätzlich infrage.

Aus Sicht vieler Kryptografen wäre etwa BBS ein etabliertes Verfahren. Es ist nach den Erfindern Dan Boneh, Xavier Boyen und Hovav Shacham benannt, wurde 2004 entwickelt und 2013 als ISO-Standard aufgenommen. BBS gilt als gut erforscht, ist allerdings bisher kaum im Praxiseinsatz.

Ein alternatives Verfahren baut auf ECDSA-Signaturen auf. Der „Elliptic Curve Digital Signature Algorithm“ ist als kryptografisches Verfahren weit verbreitet. Es wurde allerdings nicht dafür gebaut, um ZKP zu erstellen. Um einen Null-Wissen-Beweis auf Basis einer ECDSA-Signatur erzeugen zu können, braucht es technisch aufwendige Anpassungen. Im Vergleich zu BBS-basierten Verfahren gelten daher ECDSA-basierte Anonymous Credentials in der Fachwelt als langsamer und komplexer.

Kommission hat sich für ECDSA-Signaturen entschieden

Dennoch hat sich die Kommission bei ihrer Alterskontroll-App für ECDSA-basierte Anonymous Credentials entschieden. Laut dem technischen Blaupausen-Dokument hatte die Kommission zuvor fünf Optionen geprüft, drei von ihnen basieren auf BBS. „Unter diesen erscheinen ‚ECDSA Anonymous Credentials’ aufgrund ihrer Kompatibilität mit bestehenden Anmeldeformaten und Ausstellungsabläufen am vielversprechendsten“, schreibt die Kommission.

Anja Lehmann hält das für einen riskanten Ansatz. Sie ist Professorin am Hasso-Plattner-Institut der Universität Potsdam und forscht unter anderem zur datensparsamen Authentisierung in digitalen Wallets. „Nach außen wirkt der ECDSA-basierte Ansatz einfach, gerade weil er kompatibel mit bestehenden Systemen ist“, sagt Lehmann gegenüber netzpolitik.org. „Aber um diese Kompatibilität zu erreichen, braucht man ein kryptographisches Verfahren mit rund 20.000 Zeilen Code.“ Das sei langfristig eine große Herausforderung etwa für die Sicherheit und Standardisierung von kryptografischen Verfahren.

Auch Carmela Troncoso sieht die Entscheidung der Kommission kritisch: „Googles Ansatz ist neu, und obwohl er auf bekannter Kryptografie basiert, ist er noch nicht ausreichend erforscht“, sagt die IT-Sicherheitsexpertin vom Max-Planck-Institut für Sicherheit und Privatsphäre. „BBS ist hingegen eine etablierte Methode, um anonyme Zugangsdaten zu erzeugen, die wissenschaftlich gründlich untersucht wurde. Das ist ihr Hauptvorteil gegenüber Googles Verfahren.“

Beide IT-Sicherheitsfachleute gehören einer internationalen Gruppe von Kryptograf:innen an, die die EU-Kommission bereits im Juni 2024 dafür kritisierte, für die EUDI-Wallet veraltete Verschlüsselungsverfahren einsetzen zu wollen. Das Problem ließe sich nur beheben, wenn grundlegend andere kryptografische Lösungen wie BBS zum Einsatz kommen, lautete damals die Empfehlung der Kryptograf:innen.

Digitale Unabhängigkeit – mit Google?

Aus Sicht von Lehmann und Troncoso sprechen auch organisatorische Gründe gegen das Google-Verfahren. Entscheidet man sich für eine Lösung, die so komplex ist, dass die unterliegende Krypto-Bibliothek nur von sehr wenigen Fachleuten weiterentwickelt werden kann, begebe man sich in eine unnötige Abhängigkeit, warnt Lehmann. „Die Bibliothek bestimmt maßgeblich darüber, welche Funktionalität und welches Datenschutzniveau unterstützt wird“, sagt sie.

Dass die Technologie Open Source ist, verspricht aus Sicht von Carmela Troncoso nicht per se viel mehr Spielraum. „Google entscheidet darüber, was wie authentisiert und wie das angepasst werden kann“, sagt Troncoso. „Will man die hochgradig optimierten ZKP-Bibliotheken verändern, ist besonderes Fachwissen erforderlich, über das derzeit vor allem Google verfügt.“ Daher warnt Troncoso davor, „Google zum Herzen der europäischen Identitätsinfrastruktur zu machen“.

Die Kommission teilt diese Sorge offenkundig nicht. Auf Nachfrage von netzpolitik.org definiert sie digitale Souveränität als „operative Kontrolle“ etwa über Spezifikationen und die rechtlichen Rahmenbedingungen. Die ECDSA-basierten Verfahren erfüllten hier viele Anforderungen: Es gebe Open-Source-Implementierungen, eine unabhängige Sicherheitsüberprüfung durch die Internet Security Research Group und einen Standardisierungsprozess.

Tatsächlich ist ECDSA als Signaturverfahren standardisiert – „allerdings nicht das Anonymous-Credentials-Verfahren, das darauf aufbaut“, ordnet Anja Lehmann ein. Für BBS-Signaturen gebe es bereits seit 2013 einen ISO-Standard und auch eine aktuelle IRTF Standardisierung. Zwar decke der Standard nur ein einzelnes signiertes Attribut ab, eine Erweiterung auf mehrere Attribute sei aus kryptographischer Sicht aber trivial, so die Sicherheitsexpertin.

Mögliche Weichenstellung für die EUDI-Wallet

Ob die EU-Kommission mit ihrer Wahl für Google bei der Alterskontroll-App auch eine Weichenstellung für die EUDI-Wallet gewählt hat, wird sich vermutlich in den kommenden Monaten zeigen.

Eine Entscheidung will die Kommission nach einer Aussage erst dann treffen, wenn die technischen Arbeiten, die fortlaufende Überprüfung durch die European Cybersecurity Certification Group und die Konformitätswerkzeuge vorangeschritten sind. „Es wurde noch kein Termin festgelegt“, so ein Kommissionssprecher gegenüber netzpolitik.org.

Auch einen Vortrag von Paolo De Rosa will die Kommission nicht als Hinweis auf eine vorzeitige Richtungsentscheidung verstehen. De Rosa ist „EUDI-Wallet-CTO“ der EU-Kommission. Ende März präsentierte er gemeinsam mit Abhi Shelat die EUDI-Wallet auf einer IT-Sicherheitskonferenz in San Francisco. Shelat ist Co-Autor des ECDSA-basierten Anonymous-Credentials-Ansatzes und Entwickler bei Google.

Es gehöre zur Arbeitsweise der Kommission, direkt mit Forschenden zusammenzuarbeiten und mit ihnen „auf Augenhöhe“ Vorträge zu halten, schreibt die Kommission.