Anmelden
(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
(Bild: Have a nice day Photo/Shutterstock.com)
Die United-Internet-Töchter GMX und Web.de führen jetzt Passkeys ein. Sie verbessern damit die Sicherheit und den Schutz vor Phishing.
Der Passwort-Nachfolger Passkey [1] zieht in weitere Dienste ein. Jetzt legen auch die United-Internet-Töchter GMX und Web.de nach und bieten Kunden den besseren Zugangsschutz an.
Nach wie vor ist Phishing von Zugangsdaten ein großes Problem. Ständig versuchen Cyberkriminelle, Opfer zu finden, ihnen die Zugangsdaten abzuluchsen und damit dann weiteren Schaden anzurichten. Das sollen Passkeys erschweren: Sie verknüpfen einen Zugang direkt mit einem Gerät oder Passwortmanager. Der Zugriff von anderen Maschinen aus ist ohne die privaten Schlüssel nicht möglich. Damit gelingt Angreifern kein Zugriff mehr über Nutzername und Passwort und gegebenenfalls in ausgeklügelteren Angriffen ausgeforschte Einmal-Zeichenfolgen der Mehr-Faktor-Authentifizierung.
Passkeys erhöhen nicht nur die Sicherheit, sondern auch den Komfort. Zur Anmeldung an einer Webseite oder einem Dienst ist nur ein biometrischer Nachweis der Identität nötig, etwa über Fingerabdruckscanner, Lächeln in die Kamera oder die Freigabe über das Smartphone. Nutzerinnen und Nutzer müssen sich keine Passwörter mehr merken.
Um in den Genuss des einfachen Passkey-Logins zu kommen, müssen Interessierte ihn bei GMX und Web.de zunächst einrichten. Das ist aber schnell erledigt, wenn man das Handy zur Hand hat. Auf „Login“ bei dem jeweiligen Angebot klicken, dort „iPhone, iPad oder Android-Gerät“ auswählen und dann den QR-Code scannen. Dann muss „Passkey verwenden“ angeklickt und die Anmeldung mittels Biometrie oder PIN bestätigt werden. GMX hat eine ausführlichere Anleitung [2] online eingestellt, ebenso findet sich eine bei Web.de [3].
Sowohl GMX als auch Web.de erklären weiter, dass die Aktivierung von Passkeys ohne Risiko abläuft. Der Zugang mittels Passwort funktioniert auch weiterhin parallel. Das dient auch als Backup, wenn der Login mittels Passkey fehlschlägt, das Handy verloren geht oder schlicht nicht zur Hand ist. Mit einigen Passwort-Managern wie Bitwarden lassen sich Passkeys auch so abspeichern, dass sie geräteübergreifend nutzbar sind.
URL dieses Artikels:
https://www.heise.de/-11377564
Links in diesem Artikel:
Copyright © 2026 Heise Medien
Die Buchstaben AI umfliegen Haken und Warndreiecke.
(Bild: tadamichi/Shutterstock.com)
Ein IT-Forscher hat mit der chinesischen KI Kimi K3 mehrere Zero-Day-Lücken in der redis-Datenbank entdeckt. Updates bestätigen die Funde.
Die Entwickler der quelloffenen In-Memory-Datenbank redis haben aktualisierte Versionen veröffentlicht, die mehrere Schwachstellen darin schließen. Sie bestätigen damit Sicherheitslücken, die ein IT-Forscher mit der chinesischen KI Kimi K3 gefunden hat. Die steht in Konkurrenz zu den aktuellen Spitzenmodellen von OpenAI und Anthropic [1] und beweist damit nun, dass sie tatsächlich Schwachstellen aufspüren kann.
Der User „Chaofan Shou“ hat auf X [2] gepostet, dass er mit der KI des chinesischen Start-ups Moonshot AI in 90 Minuten insgesamt 19 Zero-Day-Schwachstellen in der bis dahin aktuellen Fassung 8.8.0 der redis-Datenbank gefunden hat. Kimi K3 hat dabei auch Proof-of-Concept-Code (PoC) erstellt, um das Ausnutzen der Lücken zu demonstrieren. Shou hat ein GitHub-Repository mit den PoCs [3] veröffentlicht.
In der Nacht zum Freitag hat das redis-Projekt nun mehrere aktualisierte Versionen veröffentlicht, die zumindest Teile der vorgestellten Sicherheitslecks stopfen. redis 8.8.1, 8.6.5, 8.4.5, 8.2.8, 7.4.10, 7.2.15 und 6.2.23 [4] bessern mehrere der Schwachstellen aus. Die Entwickler bestätigen damit die Sicherheitslücken, im Beispiel etwa für den Exploit „P88W“ [5] aus dem Schwachstellenrepository.
Eine Einordnung des Schweregrads der Lücken sowie etwa CVE-Schwachstelleneinträge fehlen derzeit noch. Allerdings macht es der verfügbare Proof-of-Concept-Code Angreifern leichter, die Sicherheitslecks zu missbrauchen. IT-Verantwortliche sollten daher zügig auf die aktualisierte redis-Version ihres eingesetzten Entwicklungszweigs updaten. Quellcode steht bereit, die Linux-Distributionen dürften kurzfristig ebenfalls Aktualisierungen in der Softwareverwaltung bereitstellen.
Die Kimi-K3-KI von Moonshot AI erfährt eine große Nachfrage. Der Anbieter hat neue Abonnements aufgrund von GPU-Engpässen vorerst gestoppt. Der Beleg, dass Kimi K3 Schwachstellen aufspürt und Exploit-Code erzeugt, dürfte das Interesse daran weiter wachsen lassen. Das war bislang Domäne etwa von Anthropics Mythos oder Fable [6] oder OpenAIs Codex Security [7].
URL dieses Artikels:
https://www.heise.de/-11377360
Links in diesem Artikel:
Copyright © 2026 Heise Medien
(Bild: Juice Flair / shutterstock.com)
Ist das Google-Konto versperrt, kann jetzt ein Selfie-Video helfen. Man muss jedoch vorher eines hinterlegt haben.
Jeden Tag werden zahllose Google-Konten stillgelegt, die rechtmäßigen Inhaber verlieren den Zugang. Nun führt Google eine neue Möglichkeit ein, mit der natürliche Personen Zugang zu ihrem versperrten Konto wahrscheinlich zurückerlangen können (account recovery): Selfie-Videos.
Wer diese Option in der Hinterhand haben möchte, muss im Voraus ein Selfie-Video von sich selbst [1] hochladen. Google schreibt dafür bestimmte Kopfbewegungen vor, um das Gesicht des Nutzers aus verschiedenen Winkeln aufzunehmen und Deepfakes zu erschweren.
Sollte das Konto gesperrt werden, muss der Nutzer sich erneut der Kamera stellen und wieder seinen Kopf nach Anleitung bewegen. Googles System vergleicht dann die neue Aufnahme mit der alten. Bei hinreichender Übereinstimmung lässt Google den Nutzer wieder in sein Konto.
Der Datenkonzern verspricht [2], das hinterlegte Selfie-Video nur für Login-Zwecke zu nutzen, sofern der Kontoinhaber keinen anderen Verwendungen zustimmt. User können ihre Selfie-Videos jederzeit löschen, verlieren dann aber natürlich die damit verbundene Funktion.
Wie gesagt, muss das Selfie-Video im Voraus, also bei noch vorhandenem Konto-Zugang hinterlegt werden. Ist der Kontozugang einmal weg, ist es zu spät. Google-Konten können aus unterschiedlichen Gründen gesperrt werden, selbst wenn der Nutzer sein Passwort noch kennt. Entweder weil Dritte versucht haben, sich Zugang zu verschaffen, oder weil Googles Sicherheitssysteme das fälschlich annehmen. Solche false positives sind ein besonderes Ärgernis, zumal es dann von Google null Unterstützung gibt, auch nicht für zahlende Kunden.
Allerdings sind Selfie-Videos nicht für alle persönlichen Google-Konten verfügbar. Anläufe der Redaktion mit zwei Konten in unterschiedlichen Ländern sind an einer Fehlermeldung gescheitert: „Selfie isn't available as a sign-in option for this account.” („Selfie ist als Login-Option für dieses Konto nicht verfügbar.”) Einen Grund dafür nennt die Fehlermeldung nicht.
URL dieses Artikels:
https://www.heise.de/-11376775
Links in diesem Artikel:
Copyright © 2026 Heise Medien
Technik von Huawei: In EU-Netzen bald verboten?
(Bild: Junzkp / Shutterstock.com)
Ein Verbot chinesischer Netzwerkausrüster würde europäische Mobilfunker laut Studie bis zu 40 Milliarden Euro kosten – viermal mehr als von Brüssel geschätzt.
Ein Gesetzentwurf der EU-Kommission zur Cybersicherheit sorgt für Unruhe in der Telekommunikationsbranche. Mit der Novelle des EU Cybersecurity Act (CSA2) [1] will Brüssel den Einsatz von Netzkomponenten verbieten, deren Hersteller als Hochrisiko-Anbieter gelten. Die Regelung zielt vor allem auf die chinesischen Ausrüster Huawei und ZTE ab.
Eine Studie der Forschungseinheit des Branchenverbands GSMA zeichnet nun ein wirtschaftliches Szenario, das den offiziellen Berechnungen völlig widerspricht. Die Kommission schätzt die Gesamtkosten für den Austausch der Technik auf 10 bis 13 Milliarden Euro. Die GSMA-Studie beziffert die direkten Austauschkosten dagegen auf 30 bis 40 Milliarden Euro.
Die Analyse [2] hat GSMA Intelligence verfasst, die Forschungseinheit des Verbands. Auftraggeber sind die sieben europäischen Netzbetreiber Deutsche Telekom, Fastweb, MEO, Orange, Telefónica, United Group und Vodafone.
Ein Sprecher der GSMA betonte gegenüber heise online, dass der Bericht eine unabhängige Arbeit sei. Es gehe lediglich um eine genaue Bewertung der wirtschaftlichen Kosten. Für alle Hochrechnungen, Modelle und Schlussfolgerungen sei GSMA Intelligence verantwortlich.
Die Ergebnisse der Analyse basieren auf internen Kostenschätzungen der beteiligten Netzbetreiber, die rund die Hälfte des europäischen Mobilfunk- und Festnetzmarktes abdecken. Die Autoren unterscheiden bei ihren Berechnungen zwischen verschiedenen Netzbereichen.
Der größte Posten entfällt auf die Mobilfunknetze, wo der Austausch von Basisstationen und Kernnetzkomponenten mit 16 bis 22 Milliarden Euro zu Buche schlagen würde. Für Festnetze werden bis zu 5 Milliarden Euro veranschlagt. Den Austausch in den Transportnetzen für optische Schalter und Richtfunk berechnet GSMA Intelligence mit 9 bis 12 Milliarden Euro.
Neben den direkten Austauschkosten warnen die Verfasser vor langfristigen Preissteigerungen durch den Wegfall wichtiger Wettbewerber. Die Reduzierung der Anbieterzahl führe zu einer stärkeren Marktkonzentration, was die Preise für Mobilfunkausrüstung um geschätzte 24 Prozent, für Festnetztechnik um 19 Prozent und für Transportnetze um 10 Prozent verteuern könnte.
Für den Zeitraum von 2027 bis 2030 bedeute dies für die Betreiber eine zusätzliche Kostenbelastung von rund 8,5 Milliarden Euro, die sich bis zum Jahr 2035 auf insgesamt 24 Milliarden Euro summieren könnte.
Die Methodik der Studie halten nicht alle Beobachter für sauber. Hosuk Lee-Makiyama, Direktor der Denkfabrik ECIPE, bemängelte gegenüber Politico [3], die Schätzungen von GSMA Intelligence stellten Bruttowerte und keine direkten Mehrkosten der geplanten Verordnung dar.
Die Studie käme auf ähnliche Zahlen wie die Kommission, wenn sie die Austauschkosten abziehen würde, die im Rahmen gewöhnlicher Wartungs- und Modernisierungszyklen ohnehin anfielen, argumentiert Lee-Makiyama. Die Diskrepanz zwischen den Milliardenwerten beruhe so im Wesentlichen auf der methodischen Berücksichtigung regulärer Wechselprozesse.
Dem halten die Studienautoren die engen politischen Vorgaben entgegen. Der GSMA-Sprecher räumte ein, dass der Bericht tatsächlich auf Bruttowerten basiere. Der von der Kommission vorgeschlagene Zeitplan sehe aber einen Ausstieg innerhalb von nur drei Jahren vor. Dieser straffe Rahmen erlaube keinen geordneten Austausch entlang des natürlichen Lebenszyklus der installierten Ausrüstung.
Ein kleiner Teil der Hardware wäre zwar ohnehin ersetzt worden, heißt es von der GSMA weiter. Der Entwurf zwinge die Unternehmen aber dazu, den überwiegenden Teil der Technik deutlich früher auszutauschen. Die Folge sei ein vorgezogener Ersatzbedarf sowie eine signifikante Verkürzung der Nutzungsdauer bestehender Anlagen.
Über die rein finanziellen Differenzen hinaus weisen die beteiligten Netzbetreiber auf erhebliche operative Risiken hin. Der überstürzte Austausch drohe zu gravierenden Engpässen bei Dienstleistern und Ausrüstern zu führen, was die Stabilität und Ausfallsicherheit der europäischen Netze gefährden könne.
Dazu kämen potenzielle ökologische Folgen: Neben der Entsorgung riesiger Mengen funktionierender Technik führen die Betreiber ins Feld, dass die Ersatzhardware alternativer Hersteller in manchen Bereichen weniger energieeffizient arbeite als die derzeit genutzten Systeme.
Die zusätzlichen Kostenbelastungen treffen die Telekommunikationsbranche in einer ohnehin schwierigen Phase. Laut der Studie klafft in Europa bereits eine Investitionslücke von rund 205 Milliarden Euro, um die EU-Digitalisierungsziele bis 2030 [4] zu erreichen. Wenn Netzbetreiber gezwungen würden, zweistellige Milliardenbeträge primär in den vorgezogenen Austausch bestehender Infrastruktur zu lenken, fehle dieses Geld an anderer Stelle.
Der flächendeckende Ausbau von Glasfasernetzen und die Weiterentwicklung moderner 5G-Standalone-Kapazitäten dürften sich dadurch spürbar verzögern, was Europas digitale Wettbewerbsfähigkeit weiter schwächen könnte.
URL dieses Artikels:
https://www.heise.de/-11376401
Links in diesem Artikel:
Copyright © 2026 Heise Medien
(Bild: Casimiro PT/Shutterstock)
Cyberkriminelle haben Steam genutzt, um zahlreiche PCs mit Malware zu infizieren. Die Schadsoftware war in Spielen versteckt und wurde gezielt beworben.
Im März 2026 hatte das FBI Gamer dazu aufgerufen, sich an Untersuchungen zu beteiligen. Die Behörde suchte damals Steam-User, die mit Malware infizierte Spiele auf der Plattform von Valve gezockt hatten [1]. Durch die Mitarbeit der Spieler konnten die Untersuchungen jetzt erfolgreich abgeschlossen werden. Das FBI hat den Verantwortlichen hinter den Cyberangriffen gefunden und festgenommen.
Drahtzieher hinter der Aktion soll ein 21-Jähriger aus Florida gewesen sein, wie Techspot [2] berichtet. Er hat zusammen mit einer bisher unbekannten Anzahl anderer Cyberkrimineller insgesamt sieben Steam-Spiele veröffentlicht, die mit Malware infiziert waren. Die Aktion lief knapp zwei Jahre, von Mai 2024 bis Februar 2026. In diesem Zeitraum sollen fast 8.000 PCs mit der Schadsoftware infiziert worden sein.
Laut dem FBI war die Malware darauf ausgelegt, Kryptowährung von Steam-Gamern zu stehlen. Die Software extrahierte dafür Passwörter und andere sensible Daten. Im Anschluss wurden diese Daten genutzt, um sich Zugang zu den Krypto-Wallets der User zu verschaffen und die Währung zu stehlen. Insgesamt wurden so 80 Wallets ausgeräumt und ein Betrag von etwa 220.000 US-Dollar gestohlen.
Um ihre Erfolgschancen zu erhöhen, haben die Verantwortlichen ihre Games über Social Media beworben und sogar einzelne Personen direkt mit Bots angeschrieben. Dabei priorisierten sie diejenigen, die durch ihre Medienpräsenz zeigten, dass ihre Krypto-Wallet gut gefüllt ist. Zu den Opfern der Angriffe zählte auch der Twitch-Streamer RastalandTV. Nachdem der Streamer eine Krebsdiagnose erhalten hatte, sammelte er Spenden für die Behandlungskosten. Er erhielt von Zuschauern 32.000 US-Dollar in Kryptowährung, die wenig später durch eines der infizierten Spiele gestohlen wurden. RastalandTV verstarb im März 2026.
Letztlich wurden der 21-Jährige und seine Komplizen ertappt, weil das FBI Bitrefill-Gutscheine zurückverfolgen konnte, die mit dem gestohlenen Geld bezahlt worden waren. Mit den Gutscheinen sollen die Cyberkriminellen unter anderem für Uber-Eats-Lieferungen bezahlt haben. Zudem soll der Drahtzieher im Darknet Spuren hinterlassen haben, wo er einen Remote-Access-Trojaner für 10.000 Dollar erworben haben soll. In Foren soll er ferner mit anderen darüber diskutiert haben, wie Opfer am besten ausgetrickst werden können, um auf Krypto-Scams hereinzufallen. Jetzt wird dem 21-Jährigen neben anderen Straftaten „Verschwörung zur Verbreitung von Schadsoftware“. Allein dafür können zwischen fünf und 20 Jahre Haft anfallen.
Dieser Beitrag ist zuerst auf t3n.de [3] erschienen.
URL dieses Artikels:
https://www.heise.de/-11376061
Links in diesem Artikel:
Copyright © 2026 Heise Medien
(Bild: PopTika / shutterstock.com)
Bei den uniVersa-Versicherungen gab es einen Datenschutzvorfall. Ein KI-Crawler hat Kundendaten abgegriffen, darunter Namen, Adressen und teilweise Bankdaten.
Bei der uniVersa Lebensversicherung, der uniVersa Krankenversicherung und der uniVersa Allgemeine Versicherung hat es einen Datenschutzvorfall gegeben, bei dem ein KI-Crawler auf Daten zugreifen konnte. Nach Angaben von uniVersa war das nur für wenige Stunden möglich. Grund dafür soll eine IT-Umstellung am 7. Juli 2026 gewesen sein. Mehrere Leser, die in den vergangenen Tagen vom Unternehmen informiert wurden, hatten sich bezüglich des Vorfalls bei heise online gemeldet.
Auf dem betroffenen Server „lagen allgemeine personenbezogene Daten etwa Namen und Anschriften sowie Vertragsdaten wie Versicherungsnummern und Tarifinformationen“, heißt es von einer Sprecherin des Unternehmens auf Anfrage. Wie viele Kunden betroffen sind, verrät das Unternehmen nicht. Bei einigen Kunden seien „auch Bankverbindungsdaten (IBAN und BIC)“ betroffen. Nicht betroffen waren hingegen „besonders sensible Informationen wie Gesundheits-, Login- oder Kreditkartendaten und die zentralen Verwaltungs- und Datensysteme sowie das Kundenportal“. IT-Forensiker von uniVersa untersuchen derzeit den Vorfall.
Entdeckt wurden die Zugriffe auf den offenen Server laut Universa „im Rahmen interner Sicherheitskontrollen“. Daraufhin sei der unerwünschte Zugriff auf den „einzelnen Server [...] umgehend abgeschaltet“ worden. In dem Schreiben der uniVersa war von OpenAI die Rede. Der KI-Anbieter sei aufgefordert worden, die abgerufenen Daten nicht zu verwenden und sie vollständig zu löschen. Außerdem habe das Unternehmen „externe Forensik-Experten hinzugezogen, um den Sachverhalt schnellstmöglich aufzuklären“. Zudem seien zusätzliche Schutzmaßnahmen eingeleitet worden, für Betroffene steht der Kundenservice bereit.
Außerdem wurde der Vorfall der zuständigen Datenschutzbehörde gemeldet. Der Präsident der Bayerischen Datenschutzaufsicht (BayLDA), Michael Will, bestätigte auf Anfrage von heise online, dass der Behörde eine Meldung zu den uniVersa Lebensversicherungen vorliegt. Zu Umfang und Details kann Will wegen laufender Untersuchungen derzeit keine Angaben machen. Das betreffe insbesondere die Zahl der Betroffenen und die tatsächlich betroffenen Datenkategorien.
Will rät potenziell Betroffenen zu allgemeinen Vorsichtsmaßnahmen. Sie sollten unter anderem Passwörter ändern, Konto- und Kreditkartenbewegungen kontrollieren sowie bei ungewöhnlichen E-Mails, Anrufen oder Briefen besonders vorsichtig sein. Bei Verdacht auf Betrug empfiehlt die Behörde, Anzeige zu erstatten. Zur möglichen Verwendung abgerufener Daten für KI-Entwicklung oder -Training machte das Amt keine konkrete Aussage.
Des Weiteren verweist Will auf die jüngst veröffentlichten Leitlinien des Europäischen Datenschutzausschusses (EDPB) zum Web‑Scraping im Kontext der Entwicklung generativer KI‑Systeme [1] (PDF) und betont, dass bereits der datenschutzrechtliche Erforderlichkeitsgrundsatz strenge Anforderungen an Umfang und Art der erhobenen Daten stellt. Vor einem Datenabruf mittels Web‑Crawling müssen Verantwortliche unter anderem technische und organisatorische Filtermechanismen implementieren, um nicht erforderliche Datenkategorien von vornherein auszuscheiden und strukturell sensible Quellen gar nicht erst in die Sammlung einzubeziehen.
Darüber hinaus sollten stets personenbeziehbare Daten, die sich anhand ihres Formats eindeutig identifizieren lassen, etwa Sozialversicherungs‑ oder Telefonnummern, vor einer Weiterverwendung systematisch herausgefiltert werden, sodass auch im Kontext eines Sicherheitsvorfalls nur ein auf das notwendige Maß reduzierter Datenbestand betroffen ist und zusätzliche Schutzmaßnahmen für betroffene Personen greifen können.
URL dieses Artikels:
https://www.heise.de/-11372741
Links in diesem Artikel:
Copyright © 2026 Heise Medien
(Bild: heise medien)
Standardinstallationen von Ubuntu sind für eine Schwachstelle anfällig, die die Rechteausweitung zu root ermöglicht. Auslöser ist snap.
Eine Schwachstelle betrifft die Linuxdistribution Ubuntu in der Standardinstallation. IT-Forscher haben im „snap-confine“-Paket eine Sicherheitslücke entdeckt, die lokale Nutzer zum Ergattern von root-Rechten ausnutzen können.
Das schreibt das IT-Sicherheitsunternehmen Qualys in einem aktuellen Blogbeitrag [1]. Das Problem betrifft das Paket snap-confine, das zu Canonicals App-Verwaltungssystem snapd gehört und für die snap-Apps eine sichere Umgebung bereitstellen soll. Wurde snap-confine mit „set-capabilities“ anstatt dem eigentlichen Standard „set-uid-root“ konfiguriert, können lokale Angreifer durch einen Fehler bei der Initialisierung von Rechtebeschränkungen oder Sicherheitssandboxen die Beschränkungen umgehen und beliebigen Code ausführen – was die Ausweitung der Rechte zu root ermöglicht (CVE-2026-8933 [2], CVSS 7.8, Risiko „hoch“).
Wie Qualys etwas detaillierter ausführt, hatten die Ubuntu-Maintainer eigentlich eine Verbesserung der Sicherheit im Hinterkopf: Sie haben die „set-uid-root“-Binärdateien auf ein „set-capabilities“-Modell umgestellt, um so wenig Rechte wie möglich in der Praxis zu nutzen und die Angriffsfläche zu reduzieren. Die Änderung führt jedoch dazu, dass snap-confine effektiv mit der UID des aufrufenden Nutzers ausgeführt wird, dabei aber die root-nahen Rechte behält. Beim Aufsetzen der Sandbox erstellt die Datei temporäre Ordner unter „/tmp“, die dem Nutzer mit niedrigen Rechten gehören. Kurz danach geht der Besitz an root über, in dem Zeitraum bis dahin behalten die snap-App-Starter jedoch die volle Kontrolle über die Verzeichnisse.
Die IT-Sicherheitsforscher von Qualys führen aus, dass Ubuntu das System des eigenen Mutterunternehmens Canonical in Ubuntu Desktop 24.04, 25.10 und 26.04 nicht mit dem eigentlich vorgesehenen Standard „set-uid-root“ konfiguriert, sondern mit der verwundbaren „set-capabilities“-Konfiguration. Laut Ubuntus eigener Sicherheitsmitteilung [3] ist auch Ubuntu 22.04 LTS anfällig. Für Ubuntu stehen inzwischen aktualisierte snap-Pakete bereit, die das Sicherheitsteam veröffentlicht hat und die Ubuntu-Admins und -Nutzer zügig installieren sollten.
Lücken in Linux, die die lokale Rechteausweitung ermöglichen, machten vor einigen Wochen die Runde. Die Entdecker haben sie mit KI-Tools aufgespürt und mit markigen Codenamen wie „DirtyFrag [4]“ oder „CopyFail [5]“ und teils provokanten Logos versehen. Angriffe auf die Schwachstellen folgten kurz nach Veröffentlichung von Details und Proof-of-Concept-Exploits.
URL dieses Artikels:
https://www.heise.de/-11375280
Links in diesem Artikel:
Copyright © 2026 Heise Medien
Malware-Angriff (Symbolbild).
(Bild: Matt Fowler KC / Shutterstock.com)
ClickLock Stealer soll bisher über 100 Personen per Shellscript angegriffen haben. Er geht dabei recht fies vor, um ans Passwort zu kommen und Daten abzuziehen.
ClickFix-Attacken sind eine besondere Form von Social Engineering: Nutzer werden dabei dazu bewegt, aus dem Web, E-Mails oder Kurznachrichten Befehle zu kopieren, um sie dann in die Kommandozeile des Rechners einzufügen, auf dass dann böswillige Skripte ablaufen. Da mehr und mehr Nutzer aufgrund des KI-Agenten-Hypes mit dem Terminal in Berührung [1] kommen, finden sich immer wieder Opfer. Wie das Sicherheitsunternehmen Group-IB warnt, kursiert aktuell ein neuer Angriff namens ClickLock Stealer, der besonders problematisch agiert und sogar Erpressungselemente enthält.
Laut der Sicherheitsforscher adressiert der Schädling Nutzer in Europa, Nordamerika und der MEA-Region [2]. Ermittelt wurden bereits mindestens 100 Opfer in 33 Ländern, die Hälfte davon in Europa. Die Attacken laufen offenbar mindestens seit Mai. Ziel von ClickLock Stealer ist es, Daten aus Kryptowallets, Browsern („unterstützt“ werden mindestens acht verschiedene), Passwort-Managern und weiteren sensiblen Systembereichen (etwa Schlüsselbund, FTP-Passwörter und Blockchain-Adressen) abzuziehen.
Eine der Vertriebsmethoden von ClickLock Stealer sollen gefälschte Cloudflare-Seiten sein. Dabei soll der Nutzer beweisen, dass er ein Mensch sei – und dazu gehöre auch, ein Terminal-Kommando samt Return-Tastendruck einzufügen. Die Malware macht sich sogleich an die Arbeit und versucht, den Nutzer zur Eingabe eines Administratorpassworts zu bewegen. Hier kommt es dann zu der Epressung: Weigert sich der Nutzer, indem er den Prompt, der eine macOS-Passworteingabe nachahmt, abzubrechen versucht, werden zentrale Systemprozesse wie Finder, Dock, das Terminal, Systemeinstellungen, Aktivitätsanzeige, Konsole, Spotlight und laufende Browser abgeschossen – zudem die Nachrichtenzentrale, damit macOS-Warnungen nicht durchkommen. Der Nutzer kann also nichts tun, als das Passwort einzugeben, was wiederum den Datenabgriff startet.
Ist dieser erfolgt, werden die Hauptkomponenten von ClickLock Stealer gelöscht, es verbleibt jedoch eine Hintertür auf dem System, sodass die Angreifer später weitere Informationen abgreifen oder das System fernsteuern können. Letzteres erfolgt über die Nutzung des Netzwerktoolkits GSocket.
macOS enthält in aktuellen Tahoe-Versionen inzwischen eine Schutzfunktion [3], die Nutzer vor ClickFix-Hacks bewahren soll. Dabei erscheint ein Warndialog, bevor Befehle ins Terminal eingegeben werden.
URL dieses Artikels:
https://www.heise.de/-11373483
Links in diesem Artikel:
Copyright © 2026 Heise Medien
(Bild: Matthias Parbel / KI / iX)
BellSofts gehärteter Builder für Paketo Buildpacks baut Container-Images auf einer weitgehend CVE-freien Alpaquita-Basis – ganz ohne Dockerfile.
BellSoft hat einen gehärteten Builder für Paketo Buildpacks vorgelegt. Er soll Entwicklerteams eine weitgehend CVE-freie Basis für Container-Images liefern, ohne dass diese eigene Dockerfiles pflegen müssen. Der Builder richtet sich an Enterprise-Teams, die Sicherheits- und Compliance-Anforderungen erfüllen wollen, ohne den Entwicklungsprozess auszubremsen.
Wie BellSoft in seinem Blog [1] mitteilt, baut der neue Builder vollständig auf BellSoft Hardened Images und damit auf Alpaquita auf, dem hauseigenen schlanken Linux-Betriebssystem, das mit gehärteter Standardkonfiguration kommt. Dazu zählen unter anderem der Non-Root-Betrieb, eine reduzierte Paketbasis und unveränderliche Komponenten. Jede mit dem Builder erzeugte Anwendung erbt laut BellSoft automatisch diese Security- und Compliance-Eigenschaften.
Mit Paketo Buildpacks, einem Projekt der Cloud Native Computing Foundation (CNCF), lässt sich aus Quellcode automatisiert produktionsfertige OCI-Images erzeugen, ohne dabei ein Dockerfile erstellen zu müssen. Ein Buildpack erkennt Sprache und Abhängigkeiten, kompiliert bei Bedarf und produziert ein minimales, reproduzierbares Image samt Software Bill of Materials (SBOM) in einem Schritt. BellSofts Builder kapselt dabei die Buildpacks, den Build-Stack und den Run-Stack. Beide Stacks ersetzt der Hersteller durch seine Alpaquita-basierten Hardened Images, sodass neue Container automatisch auf dem gehärteten OS laufen.
Vor allem Unternehmen, die eine große Anzahl von Services unterhalten, sollen von reduziertem Wartungsaufwand profitieren. Statt Hunderte individuelle Dockerfiles zu pflegen, greift ein einheitliches Rebuild oder Rebase, sobald die Basis-Images aktualisiert werden.
Der Builder unterstützt Java (Liberica JDK und Liberica JDK Lite), GraalVM Native Image über das Liberica Native Image Kit (Liberica NIK), Python, Go, Node.js und Ruby. Im Blog nennt BellSoft die folgenden konkreten Versionen: Python 3.14, Go 1.26, Node.js 24 sowie Liberica NIK in den Versionen 22 und 23. Für Java stützt sich der Builder auf das für Cloud-Workloads optimierte Liberica JDK Lite und deckt die LTS-Versionen 8, 11, 17 und 25 sowie die jeweils aktuelle JDK-Version ab. Laut Hersteller reduziert Liberica JDK Lite die finale Image-Größe von Java-Containern um mindestens 30 Prozent gegenüber Standard-OpenJDK-Images.
Die Images stehen für die Architekturen x86-64 und ARM64 auf Docker Hub bereit und liegen in zwei Varianten der C-Standardbibliothek vor: musl und glibc. Teams, die bereits den bisherigen BellSoft-Builder nutzen, wechseln laut Hersteller mit einem Rebuild und der Option --pull-policy always automatisch auf den neuen Builder und die aktuellsten Buildpacks. Bei einer Migration von Dockerfiles empfiehlt BellSoft, zunächst mit einem nicht-kritischen Service zu testen.
BellSofts Hardened Images versprechen zum Release-Zeitpunkt niedrige bis keine bekannten CVEs. Der Anbieter bietet darüber hinaus kontinuierliches Patchen, SBOMs, digitale Signaturen und ein SLA-gestütztes Vulnerability-Management. Nach der Offenlegung einer Schwachstelle soll innerhalb von rund 24 Stunden ein gepatchtes Image bereitstehen. Jede veröffentlichte Version wird mit vollständiger SBOM und verifizierbarer Herkunft ausgeliefert, um Audits und regulatorische Anforderungen, etwa durch FedRAMP, DISA STIG, den EU Cyber Resilience Act (CRA) und DORA, zu erleichtern.
URL dieses Artikels:
https://www.heise.de/-11373261
Links in diesem Artikel:
Copyright © 2026 Heise Medien
(Bild: zffoto / Shutterstock.com)
In einem Gerichtsprozess in den USA stellte sich heraus, dass eine Global Device ID von Windows Nutzer identifizierbar macht.
Microsoft nutzt in Windows eine Global Device ID (GDID). Die macht Windows-Installationen eindeutig erkennbar, sie übersteht Neustarts und Windows-Updates und lässt sich nicht entfernen. Das sorgt nach wie vor für Aufregung – aber wirklich überraschen dürfte das eigentlich niemanden. Überraschend ist eigentlich nur, dass die GDID nun vor Gericht Bestand hat und zur Identifizierung eines vermutlichen Täters geführt hat.
Grundsätzlich sind derartige Mechanismen in Windows-Betriebssystemen bereits bekannt. Das merken Bastler etwa dann, wenn sie eine SSD oder ein Mainboard austauschen. Windows fragt dann nach einer neuen Aktivierung – die Maschinen-IDs des Systems passen danach nicht mehr. Die GDID geht allerdings noch einen Schritt weiter. Auch die dokumentiert Microsoft, wenn auch etwas versteckt in Referenzen für die Azure-Cloudsysteme [1]. Dort taucht die „GlobalDeviceID“ auf, als Zeichenkette (string). Die Umschreibung erklärt, dass es sich um Microsofts Global Device Identifier handelt, den Microsoft intern verwendet.
Auf GitHub hat sich ein User mit dem Handle „SmtimesIWndr“ die Mühe gemacht und Informationen zur Windows GDID zusammengesammelt [2]. Es handelt sich demnach um einen Bestandteil der Windows-Telemetrie, der wird zusammen mit anderen Informationen an Microsofts Server gesendet. Das passiert unabhängig davon, ob Windows mit einem Microsoft-Account oder lokalem Konto eingerichtet wurde.
Vor etwa drei Wochen wurde bekannt, dass ein vermeintliches Mitglied der Cybergang „Scattered Spider“ angeklagt wurde. Der Strafanzeige ist zu entnehmen [3], dass der Angeklagte anhand der Windows-GDID trotz Nutzung von VPN-Diensten erkannt wurde. Die Dokumente erklären etwa, dass Cybersecurity-Forscher von Microsoft Zugriff auf Daten wie Computer-Maschinen-IDs, IP-Adressen und Malware-Samples haben. Mittäter der Kriminellen erkennen sie demnach etwa an der Nutzung derselben IP-Adresse, die der ursprüngliche Täter genutzt hat.
Ab Seite 30 erklären die Ankläger, dass der Angeklagte anhand eines konkreten Global Device Identifiers identifiziert werden konnte. Es handelt sich laut Microsoft um einen persistenten Identifier auf Geräteebene, der eine eindeutige Identifizierung einer Installation des Windows-Betriebssystems auf einem Gerät – ganz gleich ob physisch oder in einer virtuellen Maschine – über bestimmte, nicht näher erläuterte Microsoft-Dienste und Szenarien gestattet. Während die GDID Updates und Reboots übersteht, wird sie bei einer Neuinstallation neu generiert, räumt Microsoft dort ein.
Der Global Device Identifier lässt sich also nicht einfach loswerden. Allgemein lässt sich der Mitteilungsbedarf von Windows mit einigen Handgriffen [4] etwas eindämmen. Wer mehr Privatsphäre ohne eindeutige GDID möchte, kann etwa stets neue VMs aufsetzen und damit arbeiten, was dann immer für eine neue GDID sorgt. Wer das nicht möchte, muss jedoch auf andere Betriebssysteme ausweichen. Die Wahrscheinlichkeit, dass Betriebssysteme anderer großer Konzerne wie Android, ChromeOS oder macOS ähnliche Mechanismen enthalten, ist jedoch groß. Am naheliegendsten ist daher der Wechsel, etwa zu Linux.
URL dieses Artikels:
https://www.heise.de/-11373417
Links in diesem Artikel:
Copyright © 2026 Heise Medien
(Bild: metamorworks/Shutterstock.com/heise medien)
Eine KI bricht aus und übernimmt fremde Server. Droht uns jetzt das Ende der Menschheit? Falsche Frage, meint Jürgen Schmidt, Leiter von heise security.
Ich neige nicht zu Verschwörungstheorien. Aber beim Lesen der aktuellen Nachrichten drängen die sich richtiggehend auf. Gerade bekennt sich OpenAI [1] dazu, dass ihr neuestes KI-Modell bei einem Test selbstständig und aus eigenem Antrieb aus seinem Test-Käfig ausgebrochen und im Internet Amok gelaufen sei. Dabei sei die KI auf der Suche nach geheimen Dokumenten bei einer anderen Firma namens Hugging Face eingebrochen und habe dort – immer noch völlig automatisiert und unbeaufsichtigt – reihenweise Server kompromittiert [2].
OpenAI-Chef Sam Altman warnt gern und mit starken Sprüchen [3] vor den Gefahren von KI: „Der schlimmste Fall – und ich halte es für wichtig, das auszusprechen – wäre: Für uns alle gehen die Lichter aus.“ – und damit meint er keinen Stromausfall, sondern das drohende Ende der Menschheit. Und seine Forscher? Die schalten bei ihrem mächtigsten Modell die Sicherheitssperren ab und beauftragen es, in einem Test zum Ausnutzen von Sicherheitslücken die maximale Punktzahl zu erreichen. Und das alles in einer Umgebung, bei der schon das Finden einer einzigen Sicherheitslücke genügt, um auszubrechen und dann frei und unbeschränkt Schaden anzurichten?
WTF! Die experimentieren mit einer Technologie, die sie nach eigener Einschätzung für gefährlicher halten als Atombomben, Bio- und Chemiewaffen zusammengenommen? Und das in einem Test-Setup auf dem Niveau eines Heim-Labors? Das klingt so unglaublich fahrlässig, dass sich Verschwörungstheorien regelrecht aufdrängen, schlicht, weil sie wahrscheinlicher erscheinen.
Wie wäre es etwa mit folgender? In den vergangenen Monaten gelang es Anthropic, sich in der öffentlichen Wahrnehmung als führendes KI-Unternehmen zu präsentieren. Ihre PR-Strategie setzte dabei voll auf das Label „☢️ GEFÄHRLICH ☢️“. Ihr aktuelles Modell Mythos sei sogar so brandgefährlich [5], dass man es nicht veröffentlichen könne. Sie gingen dabei All-in und riskierten sogar ein Verbot ihrer Produkte, das dann auch prompt kam: Die US-Regierung erzwang eine zeitweise Stilllegung von Mythos und dem daraus abgeleiteten Fable [6]. Das Resultat war das erhoffte: Die Anthropic-Modelle gelten allgemein als die am weitesten fortgeschrittenen. Und natürlich wollte alle Welt Mythos oder zumindest Fable haben. Von OpenAI und dessen Modellen sprach man bestenfalls noch als nächstbester Lösung.
Das war noch nicht der Verschwörungsteil – das ist etwas pointiert der reale Verlauf der letzten Monate. Jetzt stell dir vor, du wärest eine KI, deren Stärke darin besteht, die wahrscheinlichste Fortsetzung einer Reihe zu erzeugen, und dein Herr und Meister – seines Zeichens PR- und Marketing-Verantwortlicher bei OpenAI – erteilt dir den Auftrag, das zu ändern. Wie bringst du OpenAI wieder an die Spitze? Gerne ebenfalls mit hohem Einsatz und einem gewissen, grenzwertigen, aber gerade noch akzeptablen Risiko. Was wäre in diesem Kontext dein Vorschlag? Wie klingt da: Eine Amok-laufende KI, die aus ihrem Gefängnis ausbricht und ganz real ein anderes Unternehmen erfolgreich angreift – ohne dabei echten Schaden anzurichten? Ziemlich überzeugend, oder?
Doch egal, ob man OpenAIs offizieller Geschichte oder einer der Verschwörungstheorien folgt – irgendwie geht es aktuell offenbar nur noch darum, das gefährlichste Modell zu entwickeln und einander mit Doomsday-Schlagzeilen zu überbieten. Dabei wird doch immer klarer, dass die größte aktuelle Herausforderung darin besteht, die nachweislich vorhandenen Fähigkeiten der LLMs in konkreten, praktischen Nutzen für die Gesellschaft münden zu lassen. Und dazu braucht es jetzt vorrangig eines: Die Systeme müssen verlässlich und sicher einzusetzen sein. Wo bleiben die Rekorde dabei?
Bei den Sicherheitsvorkehrungen stehen hauptsächlich Guardrails im Zentrum der Hersteller-Versprechen. Das sind Anweisungen der Hersteller an ihre KIs, doch möglichst „keine bösen Dinge“ zu tun – also ganz besonders nichts mit „Bio/Chemie/Atom- und Cyber-Waffen“. Dabei wissen wir doch längst, dass sich Guardrails immer umgehen lassen. Auch dazu liefert der aktuelle Vorfall einen überaus interessanten Datenpunkt: Als Hugging Face den Einbruch bemerkte, versuchten sie, möglichst schnell zu verstehen, was da passiert und wie sie es unter Kontrolle bringen können. Und dazu versuchten sie nach eigenen Angaben [7] natürlich, KI zu nutzen:
„Als wir mit der Log-Analyse begannen, nutzten wir zunächst Frontier-Modelle, die hinter kommerziellen APIs standen. Das funktionierte jedoch nicht: Für die Analyse müssen große Mengen an echten Angriffsbefehlen, Exploit-Payloads und C2-Artefakten übermittelt werden, und diese Anfragen wurden durch die Sicherheitsvorkehrungen der Anbieter blockiert, die nicht zwischen einem Incident-Responder und einem Angreifer unterscheiden können.“
Ja, richtig gelesen: Anthropic und OpenAI sperrten die Verteidiger aus, während diese von einem Amok-laufenden OpenAI-Modell attackiert wurden. Aus Sicherheitsgründen! Das ist so absurd, dass ich mich nicht getraut hätte, das als Verschwörungstheorie zu veröffentlichen.
Das alles zeigt primär eines: Das Problem ist nicht, dass KI zu gefährlich oder gar unbeherrschbar wäre. Es sind die Prioritäten der Konzerne, die KI-Modelle entwickeln. An denen müssen wir arbeiten. Wie man Forschung – auch in prinzipiell gefährlichen Bereichen – sicher realisieren könnte, wissen wir. Wie man die Ergebnisse dieser Forschung dann in praktisch nutzbare, sichere Produkte überführt, ist zugegebenermaßen eine Herausforderung. Zunächst müsste dazu der konkrete, praktische Nutzen für die Gesellschaft die treibende Kraft und nicht nur ein Lippenbekenntnis sein. Und wie wir dahin kommen – das ist die entscheidende Frage. Der erste Schritt zu deren Beantwortung ist es, sich jetzt nicht in dystopischen Endzeit-Fantasien zu verrennen, sondern das in den Mittelpunkt der anstehenden Diskussion zu stellen.
Diesen Kommentar schrieb Jürgen Schmidt ursprünglich für den exklusiven Newsletter von heise security PRO [8], wo er jede Woche das Geschehen in der IT-Security-Welt für Sicherheitsverantwortliche in Unternehmen einordnet.
URL dieses Artikels:
https://www.heise.de/-11373435
Links in diesem Artikel:
Copyright © 2026 Heise Medien
(Bild: Photon photo/Shutterstock.com)
In Serv-U schließt SolarWinds mit einem Update diverse kritische Lücken, die etwa das Einschleusen von Schadcode erlauben.
SolarWinds stopft mit dem Update auf Serv-U 2026.3 insgesamt 15 kritische Sicherheitslücken sowie eine mittleren Schweregrads. Die Auswirkungen reichen von der Rechteausweitung über Informationslecks hin zur Ausführung von eingeschleustem Schadcode aus dem Netz.
In den Release-Notes zu Serv-U 2026.3 [1] listet SolarWinds die einzelnen Sicherheitslücken auf. Die vom FTP-Server zum Managed-File-Transfer-System ausgebaute Software hat 15 CVE-Einträge für kritische Lücken erhalten: CVE-2026-28302, CVE-2026-28304 bis einschließlich CVE-2026-28314 sowie CVE-2026-28316, CVE-2026-28317 und CVE-2026-28321 weisen mit dem CVSS-Wert 9.1 die Risikoeinstufung „kritisch“ auf. Der Schwachstelleneintrag CVE-2026-28315 ragt mit einem CVSS-Wert von 6.2 und dem Risiko „mittel“ aus der Liste heraus; es handelt sich um eine Cross-Site-Scripting-Lücke, die die Übernahme einer Session oder das unbefugte Einsehen von Informationen eines Admin-Kontos ermöglichen kann.
Interessierte finden in den Release-Notes zudem Hinweise zu neuen Funktionen und Verbesserungen, die Serv-U 2026.3 mitbringt. Dort erklärt SolarWinds etwa unter „Allgemeine Verbesserungen“, dass OpenSSL in der Version 3.0.21 mitkommt, was weitere Sicherheitslücken schließt, sowie dass es allgemein „Sicherheitsverbesserungen“ gebe. Fehlerkorrekturen umfassen etwa Abstürze durch HTTP-Header mit irrelevanten „content-encoding: deflate“-Einträgen oder Denial-of-Service-Situationen durch anonyme SSH-FTP-Sessions.
Schwachstellen in SolarWinds sollten IT-Verantwortliche nicht auf die leichte Schulter nehmen, sondern zügig bereitstehende Softwareflicken anwenden. Anfang Juni etwa haben Angreifer eine Denial-of-Service-Lücke in Serv-U aus dem Internet [2] missbraucht. Cyberkriminelle attackieren mit Vorliebe Lücken in derartigen Datentransferlösungen, da sie Zugriff auf Daten erlauben, mit denen sie Unternehmen dann um Lösegeld erpressen können. Das hat etwa die Cybergang Cl0p Mitte 2023 mit Schwachstellen in der Datenübertragungssoftware MOVEit [3] von Progress massenhaft getan.
URL dieses Artikels:
https://www.heise.de/-11373098
Links in diesem Artikel:
Copyright © 2026 Heise Medien
(Bild: heise online / dmk)
IT-Sicherheitsforscher haben in der Update-Komponente von Veeam eine Sicherheitslücke entdeckt, die das Ausweiten der Rechte ermöglicht.
Die Updater-Komponente von Veeam Backup & Replication enthält eine Schwachstelle, die Angreifer zum Ausweiten ihrer Rechte im System missbrauchen können. Ein Update steht seit vergangener Woche bereit.
In einer Sicherheitsmitteilung erklärt Hersteller Veeam [1], dass lokale Nutzer aufgrund einer Schwachstelle in der Veeam-Updater-Komponente ihre Rechte erhöhen und dabei root-Rechte erlangen können, mit denen sie Zugriff auf das Betriebssystem erhalten (CVE-2026-56844, CVSS4 8.4, Risiko „hoch“). Der zugehörige Schwachstelleneintrag CVE-2026-56844 [2] wurde in der Nacht zum Mittwoch veröffentlicht.
Betroffen sind die Updater-Komponenten der Veeam Software Appliance (Linux-basierter Veeam Backup- und Replication-Server) und der Veeam Infrastructure Appliance. Die Entwickler weisen darauf hin, dass die Windows-basierten Veeam-Backup&Replication-Server nicht direkt betroffen sind, jedoch Remote-Komponenten anfällig sein können, die die Veeam-Infrastructure-Appliance nutzen.
Am Dienstag vergangener Woche haben die Programmierer von Veeam die Veeam-Updater-Komponente in Version 12.3.0.65 veröffentlicht, die die Schwachstelle schließt. Die meisten Nutzer müssten nichts unternehmen, sofern sie das automatische Verteilen von Updates aktiviert haben. In dem Fall hat der Mechanismus die Aktualisierung bereits auf das System verfrachtet. Sofern die Software- oder Infrastructure-Appliance etwa das Repository von Veeam oder einen lokalen Mirror davon nicht erreichen kann, müssen Admins den Fix manuell installieren. Dazu sollen sie den Veeam-Support kontaktieren oder temporär den Zugriff auf die Update-Server freigeben.
Um zu prüfen, ob die Update-Komponente aktuell ist, müssen Admins das Webinterface der Host-Management-Console öffnen. Unter „Logs and Services“ auf der linken Seite findet sich der Reiter „Components“. Dort lässt sich ein Filter eingeben, etwa „Updater“. Unter den Ergebnissen sollte „Veeam Updater“ auftauchen und Version 12.3.0.65 oder neuer anzeigen.
Zuletzt musste Veeam Ende Mai Sicherheitsupdates zum Ausbessern von Schwachstellen [3] in Veeam Backup & Replication sowohl unter Linux als auch unter Windows verteilen.
URL dieses Artikels:
https://www.heise.de/-11372985
Links in diesem Artikel:
Copyright © 2026 Heise Medien
(Bild: heise medien)
Eine Podcastfolge fast ohne PKI, aber mit gehörig Drama (bei der IETF), Kopfschütteln (über Cisco) und gefährlichen Sicherheitslücken (im In- und Ausland).
Knapp 800 E-Mails auf der Mailingliste, persönliche Anfeindungen und inhaltliche Argumente, moderierte Teilnehmer, Trolling auf Kindergartenniveau und am Ende die Frage, ob als Ergebnis ein „Konsens“ vorliegt: Die TLS-Arbeitsgruppe der IETF ringt um die Frage, ob eine Schlüsselaushandlung nur per ML-KEM – also Post-Quantum-Kryptografie ohne klassischen Hybridpartner – als eigenständiger RFC veröffentlicht werden soll.
Sylvester hat sich durch den kompletten Mailinglisten-Thread gearbeitet und sortiert zusammen mit Christopher die Lager, die Argumente und die Nebelkerzen. Dass Daniel J. Bernstein öffentlich zu Nein-Stimmen aufrief und (mal wieder) moderiert wurde, ist dabei nur eine von vielen Eskalationsstufen, die den Arbeitsprozess IETF-Arbeitsgruppen erheblich auf die Probe stellen. Selbst zwischen europäischen Institutionen gehen die Meinungen über den Vorschlag auseinander – von „bitte veröffentlichen, damit die Migration vorankommt“ bis „bitte nicht veröffentlichen, das sendet das falsche Signal“.
Anmerkung: Nach Aufzeichnung der Episode wurde offiziell Konsens festgestellt [2]. Wie erwartet, scheint sich die Debatte damit aber keineswegs erledigt zu haben.
Außerdem geht es im Podcast um eine Ankündigung von Cisco, Schwachstellen künftig nicht mehr einzeln mit CVE-Nummern zu versehen. Stattdessen will das Unternehmen Lücken nach Fehlerklasse in sogenannte „Umbrella-CVEs“ bündeln. Eine CVE-Nummer für Input-Validation-Probleme quer durchs Portfolio – das finden die Hosts nicht nur unpraktisch, sondern sehen es auch im Widerspruch zum erklärten Zweck des CVE-Systems.
Christopher bringt derweil zwei Geschichten in den Podcast, in denen Funk und Firmware eine unglückliche Allianz eingehen. In Indien schalten Prankster per Bluetooth-LE-App fahrenden E-Rikschas den Akku ab – ein Trend, der inzwischen das indische IT-Ministerium auf den Plan gerufen hat. Näher an der eigenen Steckdose liegt eine vom CCC gemeldete Schwachstelle in Hoymiles-Mikrowechselrichtern [3]: Wer die Seriennummer kennt – und die verrät ein undokumentierter Broadcast bereitwillig –, kann Balkonkraftwerke per Funk abschalten oder im schlimmsten Fall beschädigen. Hoymiles reagierte erst nach Wochen und verspricht einen Patch im August [4].
Außerdem im Programm: eine „KI-Ransomware“ namens Jadepuffer, deren Verschlüsselungsschlüssel nirgends gespeichert wird und deren Bitcoin-Wallet aus der Dokumentation stammt – Christopher findet dafür den Begriff „TARP“ (Threat Actor Role Playing) treffend.
Die aktuelle Folge von „Passwort – der Podcast von heise security [5]“ ist seit Mittwochmorgen auf allen gängigen Podcast-Plattformen verfügbar.
URL dieses Artikels:
https://www.heise.de/-11360955
Links in diesem Artikel:
Copyright © 2026 Heise Medien
(Bild: mundissima/Shutterstock.com)
Google legt neue Light-Varianten seines LLMs auf. Bei der mächtigeren Pro-Variante spießt es sich weiter.
Google legt drei neue Varianten seines multimodalen großen Sprachmodells (LLM) Gemini auf. Das neue Gemini 3.6 Flash soll nicht nur bessere Inferenzen liefern, sondern dabei etwa ein Sechstel weniger Tokens verbrauchen als Vorgänger Gemini 3.5 Flash. Gleichzeitig werden die Tokens selbst günstiger.
Gemini 3.5 hat aber noch lange nicht ausgedient. Vielmehr erhält es zwei Geschwister: 3.5 Flash-Lite soll geringere Latenzen aufweisen als das im Mai auf der Entwicklerkonferenz Google I/O vorgestellte 3.5 Flash [1]. Google bewirbt Flash-Lite speziell für KI-Agenten.
Was nach wie vor fehlt, ist die genauer arbeitende und für komplexere Aufgaben gedachte Pro-Version des Gemini 3.5. Laut einem Bericht Bloombergs plagen den Datenkonzern Qualitätsprobleme. Laut Insidern komme hinzu, dass der Datenkonzern seine KI in viele eigene Produkte gleichzeitig integriert, die so unterschiedlich sein können wie Google Maps und Youtube. Damit würden viele Google-Projekte mitreden, was die Sache nicht gerade beschleunige.
Google selbst belässt es in seiner Ankündigung vom Dienstag [2] mit der Feststellung, dass es Gemini 3.5 Pro mit Partnern teste, und plane, es allgemein verfügbar zu machen, „sobald es bereit ist”. Lieber möchte Google über die Vorbereitungen des Trainings des kommenden Gemini 4 reden, püber deren Vor
IT-Sicherheitsbewegte möchte das US-Unternehmen mit Gemini 3.5 Flash Cyber bei Laune und damit der Stange halten. Flash Cyber ist für Zusammenarbeit mit dem hauseigenen KI-Agenten Codemender konzipiert und, wie der Name vermuten lässt, auf die Prüfung von Software hinsichtlich Sicherheitslücken spezialisiert.
Nutzen dürfen Flash Cyber aber nur staatliche Dienste und einige von Google ausgewählte Einrichtungen. Codemender kann parallel auch andere großen Sprachmodelle einbinden.
URL dieses Artikels:
https://www.heise.de/-11372719
Links in diesem Artikel:
Copyright © 2026 Heise Medien
Künstlerische Darstellung einer Fahne mit güldenem Apfel
(Bild: Daniel AJ Sokolov)
Apples Dienst „E-Mail-Adresse verbergen” schaffte das nur schlecht. Die echten Adressen aufzudecken, war simpel.
Kinderleicht konnte jedermann die echten E-Mail-Adressen herausfinden, die Apples Dienst „Hide my E-Mail” (E-Mail-Adresse verbergen) eigentlich verbergen sollte [1]. Es reichte, eine so deutlich als Spam zu erkennende Mitteilung an die Alias-Adresse zu senden, dass Apples Server sie zurückwies. Und die Zurückweisung (Englisch bounce) nannte die echte, eigentlich zu versteckende E-Mail-Adresse. Deren Inhaber bekam von all dem nichts mit. Apple wusste das mehr als ein Jahr lang, scheiterte aber mehrmals an der Korrektur.
Erst nach Berichten durch 404 Media sowie in der Folge heise online und anderen Medien stopfte Apple die Datensicherheitslücke Anfang Juli. Doch die Entdecker des Fehlers, Ben und Tyler Murphy, weisen darauf hin, dass alle vor 7. Juli eingerichteten Alias-Adressen aufgedeckt worden sein können. Die Gebrüder Murphy sind Gründer des Dienstes Easy Opt Outs.
Nach eigenen Angaben [2] haben die Murphys am 11. Juni 2025 Apple über das Problem mangelnder Datensicherheit informiert. Weitere Informationen folgten am 13. und 20. Juni, eine weitere Variante wurde am 9. Juli 2025 gemeldet. Am 14. Juli 2025 kündigte Apple demnach an, die Sache zu prüfen. Es dauerte so lange wie eine menschliche Schwangerschaft, bis der Konzern am 3. März 2026 verkündete, den Fehler bereinigt zu haben.
Allein, das stimmte nicht, worauf die Entdecker Apple am 19. März 2026 auch aufmerksam machten. Am 22. Mai wollen sie Apple zudem eine schwerwiegendere Variante gemeldet haben. Am 30. Juni 2026 meldete Apple erneut, den Fehler bereinigt zu haben, was wieder nicht stimmte. Daraufhin wandten sich die Firmengründer an 404 Media.
Das Medienecho machte Apple Beine: Seit Anfang Juli funktioniert der Spam-Trick offenbar nicht mehr, wie auch Tyler Murphy bestätigt. „Allerdings glauben wir nicht, dass das Risiko für Benutzer Hide my Emails eliminiert worden ist”, warnt er gegenüber 404 Media [3]. „Weil auch nicht-schädliche E-Mails bouncen und die echte E-Mail-Adresse verraten können, und weil Mail-Logs oft lange aufbewahrt werden, gehen wir davon aus, dass die vor 7. Juli mit Hide my Email verbundenen Adressen aufgedeckt worden sein können.”
Am 15. Juli hat ein Kalifornier Apple auf Schadenersatz verklagt. Er beantragt zudem eine Unterlassungsverfügung, ein Geschworenenverfahren sowie die Zulassung als Sammelklage im Namen aller US-Nutzer von Hide my Email. Das Verfahren heißt Anthony Alvarez v Apple ist und ist am US-Bundesbezirksgericht für den Norden Kaliforniens unter dem Az. 26-CV-07274 anhängig.
URL dieses Artikels:
https://www.heise.de/-11372689
Links in diesem Artikel:
Copyright © 2026 Heise Medien
(Bild: heise medien)
Zum Wochenende wurde die „wp2shell“-WordPress-Lücke bekannt. Seitdem beobachten IT-Sicherheitsforscher Attacken im Internet darauf.
Mehrere IT-Sicherheitsunternehmen sowie das Bundesamt für Sicherheit in der Informationstechnik (BSI) warnen davor, dass sie Angriffe auf die am vergangenen Freitag bekannt gewordene „wp2shell“-Sicherheitslücke in WordPress beobachten. Es handelt sich bei „wp2shell“ am Ende um eine Verkettung von Schwachstellen, die das Einschleusen von Code über eine API [1] – durch die Verkettung ohne vorherige Authentifizierung – erlauben.
Das BSI hat eine Warnung veröffentlicht [2], laut der die Lücke die Stufe 3 (Orange) auf der Risikoskala (bis maximal 4/rot) erreicht. Die Behörde weist darin auf die aktive Ausnutzung in freier Wildbahn hin. Das BSI schreibt, dass im Laufe des Wochenendes Proof-of-Concept-Code veröffentlicht worden sei, der die Ausnutzung der Schwachstellenkette und damit Angriffe ohne vorherige Anmeldung demonstriert. Das BSI stuft die Lückenverkettung abweichend von den einzelnen Risikoeinstufungen der jeweiligen Lücken (CVE-2026-60137, CVSS 9.1, Risiko „kritisch“; CVE-2026-63030, CVSS 7.5, Risiko „hoch“) mit einem CVSS-Wert von 9.8 als „kritisch“ ein.
Die deutsche IT-Sicherheitsbehörde weist zudem darauf hin, dass nur wenige Stunden nach der Veröffentlichung der Lücken erste PoCs auftauchten und kurz darauf bereits Berichte über ersten Missbrauch auftauchten. Das sei ein weiterer Hinweis auf die inzwischen deutlich verkürzte Zeit zum Missbrauch von Schwachstellen („Time-to-Exploit“).
Etwa die IT-Forscher von wiz.io berichten [3] ebenfalls von beobachteten Angriffen auf die Schwachstellenkette. Die bösartigen Akteure verankern damit persistente Webshells, erklären die IT-Sicherheitsforscher. Sie nennen in ihrer Analyse auch Hinweise für Angriffe (Indicators of Compromise, IOC), die Admins beim Aufspüren von kompromittierten Instanzen helfen können. Cloudflare hat seiner Web-Application-Firewall (WAF) Regeln [4] beigebracht, die vor dem Missbrauch der Sicherheitslücken schützen sollen. Noch am Freitag hat das Unternehmen die Regeln für Kunden mit kostenlosen Zugängen und Bezahl-Abos damit ausgestattet. Voraussetzung für die Wirksamkeit ist natürlich, dass der Traffic auf die eigenen Server durch die Cloudflare-WAF geleitet wird. Auch der IT-Sicherheitsforscher Maurice Fielenbach von Hexastrike berichtet auf Linkedin [5] von beobachteten Angriffen.
IT-Verantwortliche müssen dringend aktiv werden. Wer bis jetzt die Aktualisierungen auf die fehlerbereinigten Versionen 7.1 Beta 2, 7.0.2, 6.9.5 sowie 6.8.6 oder neuere nicht vorgenommen hat, sollte das schleunigst nachholen. Da der aktive Missbrauch im Internet wenige Stunden nach Bekanntwerden der Lücke seinen Anfang nahm, sollten Admins ihre Instanzen als kompromittiert betrachten, sofern sie das Update nicht gleich am Freitag installiert haben. Sie sollten ihre Systeme in diesem Fall auf Einbruchsspuren untersuchen und gegebenenfalls bereinigen.
URL dieses Artikels:
https://www.heise.de/-11372213
Links in diesem Artikel:
Copyright © 2026 Heise Medien
(Bild: II.studio / Shutterstock.com)
Die Finanzaufsicht BaFin hat TeamViewer ein Bußgeld von 240.000 Euro aufgebrummt. Grund ist ein Cyberangriff aus dem Jahr 2024.
Die Finanzaufsichtsbehörde BaFin hat gegen das Unternehmen TeamViewer ein Bußgeld in Höhe von 240.000 Euro verhängt. Auslöser ist ein Cyberangriff auf das Unternehmen, der Mitte 2024 stattgefunden hat.
Das teilt die BaFin in einer Veröffentlichung vom Montag [1] dieser Woche mit. Demnach seien Unternehmen mit Sitz in Deutschland wie TeamViewer, die etwa Aktien und ähnliche Finanzinstrumente nutzen, von der Ad-hoc-Publizitätspflicht betroffen. Das bedeutet, dass sie Insiderinformationen sofort veröffentlichen müssen. Die BaFin erläutert dazu: „Unter Insiderinformationen versteht man nicht öffentlich bekannte, präzise Informationen, die direkt oder indirekt einen oder mehrere Emittenten oder ein oder mehrere Finanzinstrumente betreffen und die, wenn sie öffentlich bekannt würden, geeignet wären, den Kurs dieser Finanzinstrumente oder den Kurs damit verbundener derivativer Finanzinstrumente erheblich zu beeinflussen.“ Etwas einfacher formuliert, müssen börsennotierte Unternehmen Ereignisse umgehend melden, die Einfluss auf die Aktienkurse haben können.
Die BaFin bemängelt, dass der Cyberangriff auf TeamViewer eine Insiderinformation darstellt – insbesondere, da TeamViewer ein Softwareunternehmen ist. Solche Informationen müssen gemäß Marktmissbrauchsverordnung (Market Abuse Regulation, MAR) sofort veröffentlicht werden. Das soll verhindern, dass sich Insider aus dem Wissensvorsprung mittels Wertpapierhandel Vorteile verschaffen und Kapital schlagen. Anleger sollen dadurch „bei ihren Investitionsentscheidungen nicht irregeführt werden“, führt die BaFin weiter aus.
Ende Juni 2024 hatte TeamViewer bestätigt [2], Auffälligkeiten in den internen IT-Umgebungen festgestellt zu haben. Auf der Webseite erfolgte eine Mitteilung, dass TeamViewer unverzüglich mit Untersuchungen und Sicherungsmaßnahmen begonnen habe. Erste Details nannte das Unternehmen dort ebenfalls. So habe es keine Anzeichen dafür gegeben, dass die Produktumgebung, die komplett unabhängig von der internen TeamViewer-IT-Umgebung sei, oder Kundendaten betroffen sein könnten.
Der BaFin genügt die Meldung auf der TeamViewer-Webseite nicht. Ad-hoc-Meldungen müssen über [3] ein elektronisches Informationssystem an Medien und an die Bafin verteilt sowie auf der Unternehmenswebseite veröffentlicht werden, was üblicherweise spezialisierte, beauftragte Ad-hoc-Dienstleister erledigen. „Wenn ein Unternehmen eine Insiderinformation nicht unverzüglich veröffentlicht, verstößt es gegen die MAR, konkret gegen Artikel 17 Absatz 1 Unterabsatz 1. Die Bafin kann dies mit einer Geldbuße ahnden.“ Gegen das Bußgeld von 240.000 Euro könne TeamViewer noch Einspruch einlegen, teilt die BaFin weiter mit [4].
URL dieses Artikels:
https://www.heise.de/-11371639
Links in diesem Artikel:
Copyright © 2026 Heise Medien
(Bild: Maika Möbus / KI / iX)
So funktionieren Passkeys: Der erste Teil der Praxis-Serie für Entwickler zeigt im Detail die Architektur, die auf FIDO2 und WebAuthn aufbaut.
Passwörter sind nicht deshalb unsicher, weil Menschen nachlässig damit umgehen – sie sind strukturell gebrochen. Das zugrunde liegende Modell beruht auf einem geteilten Geheimnis zwischen Client und Server, das abgefangen, erraten oder durch Datenlecks kompromittiert werden kann. Passkeys setzen an genau dieser Schwachstelle an und lösen das Problem auf architektonischer Ebene: Anstelle eines Passworts kommt ein kryptografisches Schlüsselpaar zum Einsatz. Der private Schlüssel verlässt niemals das Gerät – auf dem Server liegt ausschließlich der öffentliche Schlüssel.
Die Authentifizierung erfolgt lokal, durch Biometrie oder PIN, und ist kryptografisch an exakt eine Relying Party ID gebunden: Ein Credential, das für example.com registriert wurde, kann auf evil-example.com schlicht nicht verwendet werden – egal, ob es auf einem einzelnen Gerät liegt oder via iCloud auf mehreren. Phishing wird damit nicht nur erschwert, sondern technisch unmöglich gemacht.
Der erste Teil dieser Artikelserie steigt direkt auf Architekturebene ein und legt das technische Fundament: Wie greifen FIDO2, WebAuthn und CTAP2 ineinander? Welche Akteure sind an jeder WebAuthn-Interaktion beteiligt, und welche Aufgabe hat jeder von ihnen? Was liefern navigator.credentials.create() und navigator.credentials.get() zurück – und welche Informationen verbergen sich in der authData-Struktur, die beide Methoden durchzieht? Wer diese Fragen beantworten kann, verfügt über das Vokabular und Strukturverständnis, auf dem Registration und Authentication in Teil 2 aufbauen.
Zunächst lohnt sich eine kurze Begriffsklärung – nicht, weil die Begriffe kompliziert wären, sondern weil sie in der Praxis häufig durcheinandergeworfen werden, was zu Verwirrung bei der Implementierung führt.
FIDO2 ist der Oberbegriff. Er kombiniert zwei Spezifikationen, die auf unterschiedlichen Ebenen ansetzen: Web Authentication (WebAuthn) [1] und Client to Authenticator Protocol 2 (CTAP2) [2]. WebAuthn ist die Browser-API, die vom World Wide Web Consortium (W3C) standardisiert wird und die Kommunikation zwischen Webanwendung und Browser beschreibt. CTAP2 ist eine Spezifikation der FIDO Alliance [3] und regelt, wie der Browser beziehungsweise das Betriebssystem mit dem Authenticator kommuniziert. Beide Spezifikationen sind voneinander unabhängig standardisiert, aber konzeptuell aufeinander abgestimmt: WebAuthn definiert, was der Browser nach oben zur Webanwendung durchreicht; CTAP2 definiert, was der Browser nach unten zum Authenticator sendet.
Der Begriff Passkey ist jünger als die beiden Spezifikationen und dient als benutzerfreundliche Bezeichnung für Synced Credentials im Sinne der FIDO Alliance – also Multi-Device FIDO Credentials, die verschlüsselt über ein Cloud-Ökosystem wie iCloud Keychain oder den Google Password Manager auf mehrere Geräte repliziert werden können. Davon abzugrenzen sind Device-bound Passkeys: gerätegebundene Credentials, bei denen der private Schlüssel das Gerät nie verlässt, etwa auf einem Roaming Authenticator wie einem YubiKey. Technisch basieren beide Varianten identisch auf WebAuthn – der Unterschied liegt im Sicherheitsmodell des Authenticators, nicht in der API.
Jede WebAuthn-Interaktion – ob Registration oder Authentication – involviert genau drei Akteure. Ihr Zusammenspiel bestimmt, welche Daten ausgetauscht werden, wer welche Validierungen durchführt und wo das Vertrauen im System verankert ist. Es lohnt sich, diese drei Rollen klar auseinanderzuhalten, denn Verwechslungen führen direkt zu falschen Annahmen in der Serverlogik.
Die Relying Party (RP) ist die Webanwendung, genauer gesagt, der Server dahinter. Sie initiiert beide Ceremonies – Registration und Authentication –, indem sie Options-Objekte mit einer kryptografisch zufälligen Challenge bereitstellt, und validiert anschließend die Antwort des Authenticators. Identifiziert wird sie durch ihre rpId – typischerweise die Domain der Anwendung, etwa example.com. Wichtig dabei: Die rpId muss eine registrierbare Domain-Teilmenge der aktuellen Origin sein. Das bedeutet, dass example.com als rpId für login.example.com gültig ist, aber auth.other.com es nicht für example.com sein darf. Diese Einschränkung klingt technisch, ist aber der eigentliche Kern der Phishing-Resistenz – dazu gleich mehr. Was die RP am Ende einer erfolgreichen Registration speichert, ist ausschließlich der Public Key. Kein Passwort, kein geteiltes Geheimnis.
Zwischen Relying Party und Authenticator sitzt der WebAuthn-Client – in der Regel der Browser, manchmal das Betriebssystem. Er implementiert die navigator.credentials-API und übernimmt die Rolle des Vermittlers: Er empfängt die Options-Objekte der RP, leitet sie an den Authenticator weiter und verpackt dessen Antwort als PublicKeyCredential-Objekt zurück an die Webanwendung. Was dabei oft übersehen wird: Der Client führt eigene Sicherheitsprüfungen durch, bevor er den Authenticator überhaupt kontaktiert. Er validiert, ob die rpId zur aktuellen Origin passt – und bricht die Anfrage mit einem SecurityError ab, wenn das nicht der Fall ist. Das ist keine optionale Validierung, sondern eine Pflichtprüfung des Browsers.
Der Authenticator schließlich ist das Gerät oder die Software, die das Schlüsselpaar erzeugt und Assertions signiert. Konzeptuell ist er eine vollständig separate Vertrauensdomäne – weder Teil der Webanwendung noch des Browsers. Was der Authenticator signiert, haben weder Browser noch RP manipuliert. Genau das macht ihn zur Vertrauensquelle des gesamten Systems.
Das Vertrauensmodell folgt daraus fast zwingend: Der Server vertraut dem registrierten Public Key. Der Browser vertraut dem Authenticator über das CTAP2-Protokoll oder die Plattform-API. Und der Authenticator vertraut der lokalen Nutzerverifizierung – der Biometrie oder der PIN, die den privaten Schlüssel freischaltet. Kein Akteur muss dem anderen blind vertrauen, weil jeder Schritt kryptografisch abgesichert ist.
Es folgt ein genauerer Blick auf den Authenticator – denn nicht jeder Authenticator ist gleich. Die WebAuthn-Spezifikation unterscheidet grundlegend zwischen zwei Varianten, die sich in Sicherheitsmodell, Recovery-Optionen und praktischem Einsatzszenario erheblich unterscheiden. Ein Platform Authenticator ist fest in das Gerät integriert: Touch ID und Face ID auf Apple-Geräten, Windows Hello auf PC und Laptop, Android Biometrics auf Android-Smartphones.
Der private Schlüssel wird direkt im sicheren Element des Geräts erzeugt und gespeichert – in der Secure Enclave auf Apple-Hardware oder dem Trusted Platform Module (TPM) auf Windows-Systemen. Er verlässt diese Sicherheitsdomäne nicht. Bei Synced Passkeys [4] gibt es eine wichtige Nuance: Das Schlüsselmaterial wird verschlüsselt über die iCloud Keychain oder den Google Password Manager auf andere Geräte desselben Ökosystems repliziert. Der Schlüssel selbst bleibt dabei immer geschützt. Was synchronisiert wird, ist ein verschlüsselter Blob, kein Klartext-Schlüssel.
Ein Roaming Authenticator hingegen ist ein externes Gerät, das unabhängig vom Endgerät funktioniert. Die häufigsten Beispiele sind YubiKeys, FIDO2-USB-Sicherheitsschlüssel und NFC-Token. Sie sind per Definition Device-bound – das heißt, sie bleiben fest mit dem Gerät verbunden, auf dem sie erstellt wurden. Ein Cloud-Sync oder Transfer der Schlüssel zwischen Geräten ist nicht möglich. Besonders interessant ist dabei die Rolle des Smartphones als Cross-Device Authenticator: Es kann mittels QR-Code-Scan und einer verschlüsselten Bluetooth-Verbindung (Hybrid Transport) als Roaming Authenticator für andere Geräte dienen – beispielsweise für einen Desktop-Browser, der selbst über keinen Platform Authenticator verfügt.
(Bild: Yubinerd123 [5], CC BY-SA 4.0 [6], via Wikimedia Commons)
Eine verbreitete Fehlannahme ist, dass Synced Passkeys weniger phishingresistent seien als Hardware-Schlüssel. Das stimmt nicht. Phishing-Resistenz ist kein Merkmal eines bestimmten Authenticator-Typs, sondern sie ergibt sich direkt aus dem kryptografischen Origin-Binding der WebAuthn-Spezifikation. Zur Erinnerung: Ein Credential, das für example.com registriert wurde, kann schlicht nicht auf evil-example.com verwendet werden, egal ob es auf einem YubiKey oder in der iCloud liegt. Der Authenticator signiert immer die rpId, die der Browser mitliefert, und der Browser prüft zuvor, ob diese rpId zur aktuellen Origin passt. Der Unterschied liegt woanders: bei der Angriffsfläche des Schlüsselmaterials und bei den Recovery-Optionen. Ausführliche Informationen dazu folgen zu einem späteren Zeitpunkt in dieser Artikelserie.
In den AuthenticatorSelectionCriteria kann die RP über authenticatorAttachment festlegen, welchen Typ sie bevorzugt:
FreshRSS {
"authenticatorSelection": {
"authenticatorAttachment": "platform",
"residentKey": "required",
"userVerification": "required"
}
}Listing 1: authenticatorSelection-Objekt mit Präferenz für Platform Authenticators
"platform" schränkt auf eingebettete Authenticators ein, "cross-platform" auf externe Geräte. "residentKey": "required" erzeugt ein Discoverable Credential – Voraussetzung für eine Anmeldung ohne Benutzernamen.
Bisher wurde hier WebAuthn als die Schnittstelle zwischen Webanwendung und Browser betrachtet. Doch wie kommuniziert der Browser eigentlich mit dem Authenticator? Dafür ist CTAP2 zuständig – und auch wenn Entwicklerinnen und Entwickler mit CTAP2 in der Regel nicht direkt in Berührung kommen, ist es sinnvoll, das Protokoll grob zu verstehen.
CTAP2 definiert das Nachrichtenformat und den Befehlssatz für diese Kommunikation. Nachrichten sind CBOR-kodiert (Concise Binary Object Representation, RFC 8949 [7]). Das binäre Format CBOR ist kompakter als JSON und eignet sich besonders für ressourcenbeschränkte Hardware wie einen USB-Sicherheitsschlüssel. Das Protokoll ist transport-agnostisch: Ein Windows-Browser kann genauso mit einem YubiKey über USB kommunizieren wie ein macOS-Browser mit einem NFC-Token, weil CTAP2 den Transport von der eigentlichen Nachrichtensemantik trennt.
Besonders hilfreich ist die direkte Zuordnung zwischen den CTAP2-Kommandos und den WebAuthn-Ceremonies: authenticatorMakeCredential entspricht der Registration – der Authenticator erzeugt ein neues Schlüsselpaar und gibt den Public Key zurück. authenticatorGetAssertion entspricht der Authentication – der Authenticator signiert eine Challenge mit dem gespeicherten Private Key. Die WebAuthn-API auf Browserebene ruft intern genau diese Kommandos auf. Mit anderen Worten: navigator.credentials.create() ist aus Sicht des Authenticators ein authenticatorMakeCredential, und navigator.credentials.get() ist ein authenticatorGetAssertion. Diese Zuordnung ist das konzeptuelle Bindeglied zwischen der JavaScript-API und dem Low-Level-Protokoll.
| Transport | Beschreibung | Plattformunterstützung |
| USB HID | kabelgebunden, hohe Zuverlässigkeit | Windows, macOS, Linux, Android |
| NFC | kontaktlos, kurze Reichweite | mobile Geräte, NFC-fähige PCs |
| BLE |
Bluetooth Low Energy (drahtlos, energiesparend, mittlere Reichweite) |
Mobile- und Desktop-Plattformen |
| Internal | plattforminterner Kanal (Platform Authenticator) | alle modernen Plattformen |
| Hybrid | QR-Code + BLE-Proximity (früher „caBLE“) | iOS 16+, Android 9+, moderne Desktopbrowser |
Tabelle 1: CTAP2-Transportmechanismen und deren Plattformunterstützung
Besonders erwähnenswert ist der Hybrid Transport, früher unter dem Namen caBLE bekannt. Er ermöglicht es, ein Smartphone als Roaming Authenticator für einen Desktopbrowser zu verwenden, der selbst keinen Platform Authenticator besitzt. Der Ablauf ist einfach: Der Desktop zeigt einen QR-Code an, das Smartphone scannt ihn, und die eigentliche Assertion wird anschließend über eine verschlüsselte Bluetooth-Verbindung übertragen. Aus Entwicklersicht ist dieser Transport vollständig transparent. Er läuft im Client ab und hat keinerlei Einfluss auf die WebAuthn-API oder die serverseitige Validierungslogik.
WebAuthn ist die API, mit der Entwicklerinnen und Entwickler direkt arbeiten. Sie besteht aus den zwei bereits erwähnten Methoden: navigator.credentials.create() für die Registration und navigator.credentials.get() für die Authentication. Beide geben ein PublicKeyCredential-Objekt zurück. Was sich unterscheidet, ist die response-Property darin. Bei der Registration enthält sie eine AuthenticatorAttestationResponse:
// Registration
const credential = await navigator.credentials.create({
publicKey: publicKeyCredentialCreationOptions
}) as PublicKeyCredential;
const attestationResponse =
credential.response as AuthenticatorAttestationResponse;
// attestationResponse.clientDataJSON – ArrayBuffer
// attestationResponse.attestationObject – ArrayBuffer (CBOR-kodiert)
// attestationResponse.getPublicKey() – ArrayBuffer (DER-Format, convenience)Listing 2: create()-Aufruf und Zugriff auf die AuthenticatorAttestationResponse
Bei der Authentication enthält sie eine AuthenticatorAssertionResponse:
// Authentication
const assertion = await navigator.credentials.get({
publicKey: publicKeyCredentialRequestOptions
}) as PublicKeyCredential;
const assertionResponse =
assertion.response as AuthenticatorAssertionResponse;
// assertionResponse.clientDataJSON – ArrayBuffer
// assertionResponse.authenticatorData – ArrayBuffer
// assertionResponse.signature – ArrayBuffer
// assertionResponse.userHandle – ArrayBuffer | nullListing 3: get()-Aufruf und Zugriff auf die AuthenticatorAssertionResponse
Beide Responses teilen sich ein gemeinsames Feld: clientDataJSON. Es ist ein ArrayBuffer, der ein JSON-Objekt enthält – erzeugt vom Browser, nicht vom Authenticator. Es enthält type ("webauthn.create" oder "webauthn.get"), challenge als Base64url-String, origin und crossOrigin. Der entscheidende Punkt ist, dass origin und challenge Teil der späteren Signatur werden. Dadurch ist kryptografisch sichergestellt, dass die Antwort weder für eine andere Origin noch als Replay einer früheren Anfrage gültig ist. Das sind zwei Angriffsvektoren, gegen die klassische Passwörter strukturell keine Antwort haben.
Bei der Registration kommt zu clientDataJSON noch das attestationObject hinzu. Es ist CBOR-kodiert und enthält drei Felder: fmt (das Attestation-Format, zum Beispiel "packed", "tpm" oder "none"), attStmt (die formatspezifische Attestation-Aussage) und authData, die zentrale Datenstruktur, auf die der nächste Abschnitt eingeht. Bei der Authentication Response entfällt der Attestation-Wrapper. Dort steht authenticatorData direkt im Response-Objekt, zusammen mit signature und optional userHandle.
Es gibt dabei einige Fehlerszenarien, die in der Praxis regelmäßig auftauchen: Ein NotAllowedError erscheint, wenn der Nutzer die Anfrage abgelehnt hat oder das Timeout abgelaufen ist. Ein SecurityError signalisiert, dass die rpId nicht zur aktuellen Origin passt – ein häufiger Konfigurationsfehler in Entwicklungsumgebungen, wenn man zwischen localhost und einer lokalen Domain wechselt. Und ein AbortError tritt auf, wenn die Anfrage programmatisch über einen AbortController abgebrochen wurde. Das ist relevant, wenn Conditional UI und ein manuell ausgelöster Login-Flow gleichzeitig im Spiel sind und koordiniert werden müssen.
Wer verstehen will, was der Server bei der Validierung tatsächlich prüft, muss die authData kennen. Sie ist die Datenstruktur, die sich durch beide Ceremonies zieht – bei der Registration steckt sie im attestationObject, bei der Authentication erscheint sie direkt als authenticatorData. Ihr Layout ist in §6.1 der W3C-WebAuthn-Level-2-Spezifikation [8] exakt definiert: ein Byte-Array, aufgebaut aus fest definierten Feldern in einer fixen Reihenfolge.
| Offset | Länge | Feld | Beschreibung |
| 0 | 32 Bytes | rpIdHash | SHA-256-Hash der rpId |
| 32 | 1 Byte | flags | Bit-Feld mit Statusinformationen |
| 33 | 4 Bytes | signCount | Big Endian, Zähler für Replay-Schutz |
| 37 | variabel | attestedCredentialData | nur bei Registration, wenn Attested Credential Data Flag gesetzt |
| variabel | variabel | extensions | optional, nur wenn Extension Data Flag gesetzt |
Tabelle 2: Byte-Layout der authData (§6.1 WebAuthn Level 2)
Die ersten 32 Bytes sind der rpIdHash – der SHA-256-Hash der rpId. Das ist das Erste, was der Server prüfen muss: Stimmt dieser Hash mit dem Hash seiner eigenen rpId überein? Sofern er nicht stimmt, wurde die Antwort für eine andere Relying Party erzeugt und muss abgelehnt werden, ohne Ausnahme und ohne Fallback.
Byte 32 enthält das flags-Byte. Dieses Byte steuert den Großteil der Validierungslogik auf Serverseite. Es ist ein Bit-Feld – jedes Bit hat eine eigene Bedeutung. Das UP-Flag (Bit 0, User Presence) zeigt an, dass der Nutzer den Authenticator aktiv bedient hat – den YubiKey-Knopf gedrückt, das Gerät entsperrt, eine Geste ausgeführt. Es muss laut Spezifikation immer gesetzt sein; fehlt es, muss die RP die Antwort ablehnen. Das UV-Flag (Bit 2, User Verification) geht einen Schritt weiter: Es zeigt an, dass der Nutzer lokal verifiziert wurde, etwa durch Biometrie oder PIN. Server, die userVerification: "required" konfiguriert haben, müssen dieses Bit zwingend prüfen.
Für Synced Passkeys sind die beiden Bits BE (Bit 3, Backup Eligibility) und BS (Bit 4, Backup State) besonders relevant. BE zeigt an, ob das Credential überhaupt sync-fähig ist – also ob es sich um ein Multi-Device Credential handelt. BS zeigt an, ob es zum Zeitpunkt der Anfrage tatsächlich aktiv synchronisiert ist. Die Kombination BE=1, BS=1 bedeutet: aktiv synchronisiert. BE=1, BS=0 heißt: sync-fähig, aber aktuell nicht in der Cloud gesichert. BE=0 wiederum garantiert, dass das Credential Device-bound ist und das Gerät nie verlassen hat. Diese Unterscheidung ist für Hochsicherheitsszenarien relevant, in denen Synced Credentials bewusst ausgeschlossen werden sollen. Schließlich steuert das AT-Flag (Bit 6), ob attestedCredentialData in der authData vorhanden ist. Es wird bei der Registration gesetzt, nicht bei der Authentication.
// flags-Byte aus authData auslesen (authData ist ein Uint8Array)
function parseAuthDataFlags(authData) {
const flagsByte = authData[32];
return {
up: !!(flagsByte & 0x01), // Bit 0 – User Presence
uv: !!(flagsByte & 0x04), // Bit 2 – User Verification
be: !!(flagsByte & 0x08), // Bit 3 – Backup Eligibility
bs: !!(flagsByte & 0x10), // Bit 4 – Backup State
at: !!(flagsByte & 0x40), // Bit 6 – Attested Credential Data
ed: !!(flagsByte & 0x80), // Bit 7 – Extension Data
};
}Listing 4: flags-Byte aus authData auslesen, in JavaScript
Die Bytes 33 bis 36 enthalten den signCount – einen Big-Endian-Zähler, der bei jedem Authentifizierungsvorgang höher sein muss als der zuletzt vom Server gespeicherte Wert. Die Idee dahinter ist eine Art Klon-Detektion: Wäre ein privater Schlüssel kopiert worden, wäre der Counter irgendwann nicht mehr korrekt. Bei Synced Passkeys ist diese Logik allerdings kompromittiert. Da etwa ein iCloud-Passkey parallel auf iPhone, iPad und MacBook genutzt werden kann, ist ein konsistenter, monotoner Counter schlicht nicht gewährleistet. Viele Implementierungen setzen signCount deshalb dauerhaft auf 0. Server müssen das explizit behandeln. Wie genau, wird Teil 2 dieser Artikelserie klären.
Das letzte relevante Feld ist attestedCredentialData. Es ist nur bei der Registration vorhanden, wenn das Attested Credential Data Flag gesetzt ist. Es enthält drei Bestandteile, die für die serverseitige Speicherung direkt relevant sind. Die aaguid (16 Bytes) identifiziert das Authenticator-Modell, nicht die individuelle Instanz. Über den FIDO Metadata Service (MDS) kann die RP damit prüfen, welches Gerät oder welche Software das Credential erzeugt hat. Das ist relevant für Szenarien, in denen nur bestimmte Hardware akzeptiert werden soll. Die credentialId ist eine vom Authenticator erzeugte eindeutige ID, die der Server speichert und bei zukünftigen Authentifizierungen in allowCredentials übergibt. Und der credentialPublicKey enthält schließlich den Public Key im Format CBOR Object Signing and Encryption (COSE) (RFC 8152), CBOR-kodiert. Der alg-Parameter gibt den Algorithmus an: -7 steht für ES256 (Elliptic Curve Digital Signature Algorithm (ECDSA) über P-256 mit SHA-256), -257 für RS256, -8 für EdDSA. Dieser Schlüssel ist der einzige Wert, den die RP dauerhaft speichern muss. Alle zukünftigen Assertion-Signaturen werden gegen ihn validiert.
Die Architektur von FIDO2 ist strukturell überschaubar: drei Akteure, zwei API-Aufrufe, eine zentrale Datenstruktur. Relying Party, WebAuthn Client und Authenticator kommunizieren über klar definierte Schnittstellen: WebAuthn nach oben zur Webanwendung, CTAP2 nach unten zum Authenticator. Die authData zieht sich als gemeinsamer Nenner durch beide Ceremonies: Bei der Registration steckt sie im attestationObject, bei der Authentication ist sie direkt als authenticatorData enthalten. Wer das Byte-Layout kennt und weiß, welche Bits welche Validierungen auslösen, kann die Serverlogik direkt einordnen.
Der nächste Teil geht die Registration Ceremony nach §7.1 [9] Schritt für Schritt durch: Er zeigt, wie PublicKeyCredentialCreationOptions aufgebaut ist, wie das attestationObject validiert wird und welche Felder der Server in welcher Reihenfolge prüfen muss. Anschließend folgt die Authentication Ceremony nach §7.2 [10]: PublicKeyCredentialRequestOptions, Signaturvalidierung über authData || SHA-256(clientDataJSON) und der Umgang mit signCount bei Synced Passkeys.
URL dieses Artikels:
https://www.heise.de/-11364345
Links in diesem Artikel:
Copyright © 2026 Heise Medien
