Google verbaut in seinem Browser ein lokales KI-Modell, das Funktionen wie Betrugserkennung datenschutzfreundlicher ausführen soll. Eine eigene Javascript-API (Application Programming Interface) wird zudem Webseiten erlauben, mit dem Modell zu interagieren. Nun wirft eine Änderung in den KI-Einstellungen bei Chrome 148 Fragen auf: Funkt die lokale KI nach Hause und verrät dem Suchmaschinenriesen private Daten?

Vor wenigen Tagen berichteten verschiedene Medien über das Tohuwabohu um ungefragt heruntergeladene Daten, nun verglichen Redditoren die Konfigurationseinstellungen der lokalen KI zwischen Chrome 147 und dem kürzlich erschienenen Chrome 148. Sie fanden heraus, dass ein kurzer, aber wichtiger Halbsatz fehlt.

Deine Daten an Google-Server?

Hieß es in Chrome 147 noch: „[..] KI-Modelle verwenden, die direkt auf deinem Gerät ausgeführt werden, ohne deine Daten an Google-Server zu senden“, fehlt der letzte Halbsatz in der aktuellen Chrome-Version. Wir konnten das auf einem Redaktionsgerät mit macOS nachvollziehen, die Option findet sich in den Systemeinstellungen des Browsers (chrome://settings/system).

Der Zweck der Änderung ist unklar. Womöglich möchte sich Google tatsächlich das Recht einräumen, die lokale KI durch Ergebnisse der cloudbasierten LLM anzureichern, womöglich handelt es sich auch um die Vorbereitung auf das „Prompt API“, das man in Mountain View offenbar derzeit im Eiltempo in den Browser einbaut.

Skeptiker können das lokale KI-Modell abschalten, Google merkt jedoch in der Chrome-Hilfe an: Das spare zwar Speicherplatz, schränke aber KI-basierte Leistungsmerkmale ein. Das könnten etwa Hilfen beim Schreiben oder Umschreiben sein, Betrugswarnungen, Ordnung in Browsertabs oder Zusammenfassung von Webseiten.

(cku)

Die vm2-Sandbox ist im Kontext von Node.js-Umgebungen erneut löchrig und Angreifer können Schadcode ins Hostsystem schieben und ausführen. Admins sollten das Sicherheitsupdate zeitnah installieren.

Sandbox repariert

Wie aus einer Warnmeldung auf GitHub hervorgeht, hat die „kritische“ Lücke bislang noch keine CVE-Nummer bekommen. Aufgrund eines Fehlers können sich Angreifer eines Ereignisses aus dem Hostsystem bemächtigen und innerhalb der Sandbox die Kontrolle über einen Host-Prozess erlangen. Auf diesem Weg kann Schadcode ins Hostsystem gelangen. Wie eine Attacke konkret ablaufen könnte, ist bislang nicht bekannt. Auf der genannten GitHub-Website ist Proof-of-Concept-Code verfügbar. Die Entwickler versichern, die Schwachstelle in vm2 3.11.3 geschlossen zu haben.

Erst kürzlich sorgte eine Sandbox-Lücke in Node.js 25 für Schlagzeilen.

Siehe auch:

• Node.js: Download schnell und sicher von heise.de

(des)

Mit dem Update auf FTL 6.6.2 schließt das Pi-hole-Projekt mehrere Sicherheitslücken in dem DNS-basierten Werbeblocker für Raspberry Pis. Sie betreffen den mitgelieferten DHCP- und DNS-Server dnsmasq.

In der Release-Ankündigung zu Pi-hole FTL 6.6.2 erörtern die Entwickler, dass sie darin die Sicherheitslücken schließen, die in dnsmasq 2.92 und 2.93 bekannt wurden und vor denen etwa CERT.org seit dem Montag dieser Woche warnt. Die Einordnung des Risikos der Lücken etwa gemäß CVSS liegt noch nicht vor. Allerdings dürften viele Projekte in Kürze Updates zum Stopfen der dnsmasq-Lücken bereitstellen, wenn sogar das namhafte CERT warnt. Neben Pi-hole listet das CERT etwa Arch Linux, NixOS, Red Hat, SUSE Linux, Ubuntu und Wind River als betroffen auf.

Die Lücken umfassen etwa einen Pufferüberlauf auf dem Heap, der sich mit manipulierten DNS-Antworten auslösen lässt (CVE-2026-2291), einen Pufferüberlauf im DHCP-Helper-Script (CVE-2026-4892), Lesezugriffe über vorgesehene Speichergrenzen des Heaps hinaus (CVE-2026-5172), eine Umgehung einer Subnetz-Prüfung im EDNS-Client (CVE-2026-4893) sowie zwei Denial-of-Service-Schwachstellen in DNSSEC (CVE-2026-4890, CVE-2026-4891). Das CERT schreibt dazu, dass dadurch etwa Code ausgeführt werden könnte, mit root-Rechten, oder Angreifer den Cache manipulieren können (Cache Poisoning/Redirection). Das dnsmasq-Projekt stopft die Sicherheitslecks in den Versionen 2.92rel2 sowie 2.93.

Pi-hole: Aktualisierte Software

Bis zu welchem Softwarestand Pi-hole für die dnsmasq-Schwachstellen anfällig ist, konkretisieren die Maintainer nicht. Als Lösung sollten Pi-hole-Nutzerinnen und -Nutzer unbedingt auf die aktuelle 6er-Fassung migrieren. Das Update verfrachtet der Aufruf von sudo pihole -up am Terminal des genutzten Raspberry Pi auf das System.

Zuletzt hatte das Pi-hole-Projekt Ende April ein Sicherheitsupdate veröffentlicht. Damit haben die Programmierer zwei hochriskante Sicherheitslücken geschlossen. Auch da waren die Komponenten Pi-hole Core und FTL betroffen. Die Lücken ermöglichten Angreifern die Rechteausweitung. Sie betreffen die mitgelieferten Skripte von Pi-hole vor den Versionen Core 6.4.2 und FTL 6.6.1. Angreifer mit Pi-hole-Rechten – etwa durch Missbrauchen einer bislang unbekannten Sicherheitslücke im Webinterface – konnten sich dadurch root-Rechte aneignen (CVE-2026-41489, CVSS 8.8, Risiko „hoch“). Auf GitHub steht eine detailliertere Analyse der Lücke bereit, der zugehörige CVE-Eintrag wurde erst jetzt in der Nacht zum Dienstag in der NVD-Datenbank des NIST veröffentlicht.

Siehe auch:

(dmk)