Die Sicherheitsforscher Sam Curry und Shubham Shah konnten die App-Konten zweier Autohersteller übernehmen und deren vernetzte Fahrzeuge aus der Ferne entriegeln und starten. Das schreiben sie in zwei Beiträgen, die am 7. November 2026 erschienen sind. Die Lücke steckte weder im Auto noch in der App, sondern in der Zugriffsverwaltung für die Kundenkonten: Über die Anmeldeserver der Hersteller konnten die Forscher nach eigenen Angaben für jedes dort verwaltete Konto eine gültige Sitzung erzeugen. War ein vernetztes Fahrzeug verknüpft, hatten sie damit dieselben Rechte wie der Besitzer in der App, also Standort und Fahrzeugdaten, Türen auf und zu, Motor an und aus. Beide Hersteller haben die Lücke laut Curry etwa zwei Stunden nach der Meldung geschlossen und die betroffenen Zugangsdaten ausgetauscht.

Wer die Hersteller sind, bleibt offen. Sie haben darum gebeten, nicht genannt zu werden, und Curry respektiert das ausdrücklich. Die beiden sind in diesem Feld keine Unbekannten: 2024 zeigten sie, dass sich Kia-Fahrzeuge allein über das Kennzeichen fernsteuern ließen, Ende 2024 fanden sie eine Lücke im Subaru-Dienst STARLINK. Laut Curry gelang ihnen in den vergangenen Jahren auch der Fernzugriff auf Fahrzeuge von Honda, Nissan, Hyundai, Ford, Porsche und weiteren Marken.

Die Schwachstelle lag in der Kontenverwaltung, nicht im Auto

Beide Hersteller verwalten die Konten ihrer App-Nutzer mit ForgeRock. Die Identitätsplattform gehört seit 2023 zu Ping Identity. Die Apps der beiden Marken führten zur selben Anmeldeplattform, nur mit unterschiedlichem Markenauftritt. Auf deren Servern stießen die Forscher auf eine Verwaltungskonsole, die eigentlich gar nicht erreichbar sein sollte. Vor den Servern stand zwar eine Web Application Firewall, die solche Adressen blockierte. Mit einer speziell kodierten Adresse kamen die Forscher aber trotzdem an der Firewall vorbei, weil Firewall und Server dieselbe Adresse unterschiedlich interpretierten. Die Konsole akzeptierte dann noch die Zugangsdaten aus der Werkseinstellung.

Das ist kein unbekanntes Risiko. Ping Identitys Härtungsanleitung für die Identitätsverwaltung IDM verlangt, diese Entwicklungs- und Debug-Konsole vor dem Produktivbetrieb zu entfernen oder abzusichern. Sie weist auch darauf hin, dass die Anmeldung an der Konsole nicht an die übrige Benutzerverwaltung gekoppelt ist. Über die Konsole konnten Curry und Shah eigenen Code auf den Identitätsservern ausführen und an die Administratorrechte für das Kundenverzeichnis gelangen. Dort ließ sich jedes Konto nach Name, E-Mail-Adresse, Telefonnummer oder Kunden-ID finden und ändern.

Für ihre Vorführung tauschten die Forscher bei einem Testkonto die E-Mail-Adresse und das Passwort aus und meldeten sich über den ganz normalen Login der App an. Den Bestätigungscode schickte das System an die neue Adresse. Danach hatten sie dieselben Zugangstoken, die auch die offizielle App bekommt, und damit Zugriff auf die verknüpften Fahrzeuge. Nach Currys Darstellung hat Shah an einem Testwagen, dessen Besitzer daneben stand, die Türen entriegelt und den Motor gestartet und danach alles wieder rückgängig gemacht. Ob sich ein so gestartetes Auto ohne Schlüssel auch fahren ließe, beschreiben die Forscher nicht. Die Systeme bedienten Kunden in mehreren Regionen. Die komplette Kette haben die Forscher nur mit US-Konten und US-Fahrzeugen getestet.

Symbolbild: Anmeldemaske mit Feldern für Benutzername und Passwort auf einem Bildschirm

Bild: Symbolbild – Username and password von Santeri Viinamäki, Lizenz CC BY-SA 4.0, via Wikimedia Commons

Besitzer hätten wenig davon bemerkt

Die Änderung von E-Mail-Adresse und Passwort hat laut Curry die laufende App-Sitzung des Besitzers nicht beendet. Die Forscher konnten die ursprüngliche E-Mail-Adresse wiederherstellen, ohne dass ihre eigene Sitzung ungültig wurde. Weil die App selbst meldet, an welches Gerät Push-Nachrichten gehen sollen, ließen sich die Benachrichtigungen außerdem vom Handy des Besitzers weglenken. Nur am Passwort hätte man etwas merken können: Das alte funktionierte nicht mehr, denn wiederherstellen konnten die Forscher es nicht, weil sie es nie kannten.

Zweite Kette in Australien: Das Kennzeichen reichte

Shah beschreibt in einem eigenen Beitrag einen zweiten Angriffsweg, der auf die australischen Systeme zielte. Er spricht dabei nicht von zwei Herstellern, sondern von einem großen Autokonzern mit zwei Marken, ohne Namen zu nennen. Ausgangspunkt war ein öffentlich erreichbares internes Verwaltungswerkzeug. In einem JavaScript-Paket steckten Administrator-Zugangsdaten für die Identitätsverwaltung, die laut Shah eigentlich für eine Testumgebung gedacht waren, aber auch in der Produktion funktionierten. Zusammen mit einem Umweg um die Firewall und einer Anmeldung, bei der die Zwei-Faktor-Abfrage übersprungen werden konnte, reichte am Ende das Kennzeichen: Darüber kommt man in Australien legal an die Fahrgestellnummer, darüber ans Kundenkonto. So hätten die Forscher nach Shahs Angaben Befehle an jedes Fahrzeug des Konzerns in Australien schicken können, bei beiden Marken.

Bemerkenswert ist, wie die beiden an der Firewall vorbeigekommen sind. Die entscheidende Adressvariante hat nach Shahs Schilderung ein KI-Modell gefunden, das er als „GPT 5.6 Sol Ultra“ bezeichnet. Es hatte rund sechs Stunden lang den Quellcode der passenden Softwareversion untersucht. Dass KI-Modelle bei der Suche nach Lücken eine immer größere Rolle spielen, zeigt auch OpenAIs jüngste Meldung zu GPT-6 Cyber. Zusammen decken die beiden Beiträge nach Shah Fahrzeuge in Australien, den USA und Kanada ab. Die Umgebungen in den USA, Kanada und Europa waren laut Shah deutlich besser geschützt als die australische.

Was offen bleibt

Viele Angaben lassen sich nicht unabhängig prüfen. Von den anonymen Herstellern gibt es keine Stellungnahmen, und die bisherige Berichterstattung, etwa bei Privacy Affairs, gibt im Wesentlichen die Blogbeiträge wieder. Ob Dritte die Lücke ausgenutzt haben, sagen die Forscher nicht. In ihren Beiträgen zu Kia und Subaru stand dagegen ausdrücklich, dass es keinen Missbrauch gegeben habe. Wie viele Konten und Fahrzeuge betroffen waren, ist ebenfalls unbekannt. Eine CVE-Nummer gibt es nicht, denn die Ursache war eine unsichere Einrichtung beim Betreiber und keine Lücke in einem Produkt.

Auch der Zeitpunkt ist nicht ganz eindeutig. Curry nennt „Anfang 2026“, die Serverantworten in seinem Beitrag tragen das Datum 17. Februar 2026. Shah schreibt dagegen, die Zusammenarbeit habe „diesen Juli“ begonnen. Ob und wann die australische Kette gemeldet und geschlossen wurde, geht aus seinem Beitrag nicht hervor.

Was du jetzt tun solltest

Gegen diese Lücke hättest du als Autobesitzer nichts ausrichten können. Sie steckte in den Servern der Hersteller. Ein starkes Passwort und die Zwei-Faktor-Anmeldung hätten nicht geholfen, weil die Angreifer Passwort und E-Mail-Adresse direkt im Kundenverzeichnis überschreiben konnten. Ein paar Dinge kannst du trotzdem tun:

  • Kontodaten prüfen: Schau in der Hersteller-App nach, ob E-Mail-Adresse und Telefonnummer stimmen. Wenn dein Passwort plötzlich nicht mehr funktioniert oder Bestätigungscodes kommen, die du nicht angefordert hast, wende dich an den Kundendienst des Herstellers.
  • Geteilte Zugänge und Geräte prüfen: Viele Apps zeigen weitere Fahrer, Zweitnutzer und angemeldete Geräte an. Entferne alles, was du nicht kennst. Beim Verkauf des Autos solltest du es aus deinem Konto löschen.
  • Passwort und Zwei-Faktor-Anmeldung trotzdem nutzen: Beides schützt vor den üblichen Angriffen wie Phishing oder wiederverwendeten Passwörtern.
  • Nicht benötigte Fernfunktionen abschalten: Brauchst du Fernstart oder Fernentriegelung nicht, schalte sie ab, wenn App oder Fahrzeug das erlauben. Welche Möglichkeiten es gibt, hängt vom Hersteller ab.
  • Updates einspielen: Halte die App aktuell. Lücken auf den Servern behebt das allerdings nicht, die muss der Hersteller selbst schließen.

Wie sicher die Server eines Herstellers sind, kannst du als Kunde nicht prüfen. In der EU kannst du aber nach Art. 15 DSGVO fragen, welche Daten der Hersteller über dich und dein Fahrzeug speichert.

Wer selbst ForgeRock oder PingIDM betreibt, sollte nachsehen, ob die Felix-Webkonsole noch installiert ist. Ping Identity empfiehlt, sie im Produktivbetrieb zu entfernen. Für IDM 7.2 sieht das so aus (Pfade und Dateinamen hängen von der Version ab):

# Webkonsole und zugehörige Plugins entfernen
rm /path/to/openidm/bundle/org.apache.felix.webconsole*.jar
rm /path/to/openidm/bundle/openidm-felix-webconsole-*.jar
# Konfigurationsdatei der Konsole entfernen
rm /path/to/project-dir/conf/felix.webconsole.json

Soll die Konsole bleiben, gehören eigene, starke Zugangsdaten in conf/felix.webconsole.json. Und der Fall zeigt: Ein Pfadfilter in der Firewall ist kein Ersatz dafür, Verwaltungsoberflächen gar nicht erst ins Netz zu stellen.

Quellen

Bildnachweis