Als die KI nicht das schwache Glied war: die McHire-Bewerberdaten-Exposition

Was ist passiert?

Im Juni 2025 deckten die Sicherheitsforscher Ian Carroll und Sam Curry eine Schwachstellenkette in McHire auf, der Einstellungsplattform von McDonald's, die von Paradox.ai entwickelt und von der überwiegenden Mehrheit der McDonald's-Franchises genutzt wird. Öffentliche Berichte von Wired und BleepingComputer beziffern den exponierten Datensatz auf etwa 64 Millionen Bewerber, wobei Namen, E-Mail-Adressen, Telefonnummern und Chat-Transkripte für jeden zugänglich waren, der denselben Weg wie die Forscher einschlug.

Die Schlagzeile, die sich am schnellsten verbreitete, stellte dies als Prompt-Injection-Angriff auf den Chatbot „Olivia“ dar. Diese Darstellung ist falsch. Die Forscher gaben an, dass sie zuerst Prompt-Injection versucht hatten, und es scheiterte: Der Bot war streng auf vorgefertigte Antworten beschränkt und hatte nie Backend-Daten, die er durch Tricks preisgeben konnte. Der Kompromiss hatte nichts mit dem Sprachmodell zu tun.

Der eigentliche Einstiegspunkt war eine administrative Anmeldeseite von Paradox.ai auf McHire, die über das öffentliche Internet erreichbar war. Die Forscher versuchten die Anmeldeinformationen „123456“ / „123456“ auf einem Testkonto, das laut öffentlichen Berichten seit 2019 aktiv gewesen war. Sie gelangten hinein.

Einmal drinnen, ermöglichte ein klassischer Insecure Direct Object Reference (IDOR) auf der Bewerber-API das Inkrementieren einer numerischen ID und das Abrufen des Datensatzes jedes Bewerbers. Keine Ausnutzung des Modells, keine neuartige Technik, kein Zero-Day. Standard-Anmeldeinformationen plus eine unauthentifizierte Objekt-Referenz.

Warum sich dieses Muster wiederholt

Das interessante Versagen hier ist nicht technischer, sondern organisatorischer Natur. Der Chatbot war die sichtbare „KI“-Komponente, daher zog er die Sicherheitsaufmerksamkeit auf sich. Die langweilige Web-Administration dahinter war der eigentliche Schadensbereich, und fast niemand betrachtete es so.

Dies geschieht immer dann, wenn ein Käufer einen KI-Anbieter als KI-Produkt und nicht als SaaS-Anwendung behandelt, die zufällig ein Modell enthält. Das Modell erhält eine Red-Team-Überprüfung. Die Admin-Konsole, die Bewerber-API, der Speicher-Bucket, die Audit-Protokollierung, die Richtlinie zur Anmeldeinformationsrotation – die Dinge, die jahrzehntelange bekannte Fehlerursachen haben – werden als „Rohrleitungen“ behandelt.

Die Anreizstruktur der Lieferanten verstärkt dies. KI-Anbieter liefern schnell, oft bevor sie ein ausgereiftes Sicherheitsprogramm haben, und die Beschaffungsteams ihrer Kunden fragen nach dem Modellverhalten und nicht nach der umgebenden Anwendung. Ein Testkonto aus dem Jahr 2019 mit dem Passwort „123456“ überlebt diese Lücke jahrelang, weil niemand die Überprüfung darauf ausgelegt hat, es zu finden.

Die teuersten KI-Verletzungen der nächsten zwei Jahre werden keine Modell-Exploits sein. Es werden Web-Schwachstellen aus den 1990er Jahren in der Anwendung sein, die das Modell umgibt.

Der Angreifer-Playbook Schritt für Schritt

Die offengelegte Sequenz war kurz, und das ist der unangenehme Teil. Ein erfahrener Angreifer benötigte keine Kette neuartiger Primitive.

Schritt 1: Die Oberfläche des KI-Anbieters aufzählen

Identifizieren Sie den Drittanbieter hinter dem sichtbaren Chatbot. In diesem Fall identifizierte sich der Bot als von Paradox.ai erstellt, was auf eine separate administrative Oberfläche hinwies – eine Anmeldeseite auf derselben McHire-Domain.

Schritt 2: Die offensichtlichen Anmeldeinformationen ausprobieren

Standard- und schwache Anmeldeinformationen bleiben der ertragreichste Angriff gegen Admin-Panels von Anbietern. Berichten zufolge reichte ein einziges Testkonto mit „123456“ / „123456“ aus.

Schritt 3: Von Admin zu Daten schwenken

Die Admin-Rolle legte eine interne Bewerber-API offen. Die API verwendete einen sequenziellen numerischen Bezeichner und überprüfte nicht, ob das aufrufende Konto berechtigt war, jeden spezifischen Bewerber zu lesen. Das Iterieren der ID lieferte beliebige Datensätze zurück.

Schritt 4: Umfang bestätigen und offenlegen

Die Forscher stoppten beim Nachweis der Auswirkungen, validierten die Größe des Datensatzes und meldeten dies Paradox.ai und McDonald's. Paradox.ai deaktivierte das Testkonto und behob Berichten zufolge den IDOR innerhalb weniger Stunden nach der Offenlegung.

Was die Verteidiger übersehen haben

Drei Dinge, in etwa abnehmender Reihenfolge der Schwere.

Erstens: keine Anmeldeinformationshygiene auf der Admin-Oberfläche des Anbieters. Ein Testkonto, das vor der Produktionsbereitstellung existierte, mit einem sechsstelligen numerischen Passwort, war fünf Jahre nach seiner Erstellung über das öffentliche Internet erreichbar. Jede regelmäßige Anmeldeinformationsprüfung hätte es gefunden.

Zweitens: keine Autorisierungsprüfung an der Bewerber-API. IDOR ist eine der ältesten, am besten dokumentierten Web-Schwachstellen im OWASP-Katalog. Die Tatsache, dass ein authentifizierter Admin-Aufruf beliebige Bewerberdatensätze zurückgab, bedeutet, dass die API Authentifizierung, aber keine Autorisierung durchsetzte.

Drittens: keine Sicherheitsüberprüfung der langweiligen Oberfläche. Der Chatbot erhielt Aufmerksamkeit, weil er die KI war. Die Admin-Anmeldung, das API-Gateway und die Speicherung von 64 Millionen PII-Datensätzen erhielten nicht die gleiche Prüfung – weder bei McDonald's, bei Paradox.ai noch bei den Franchisenehmern, die McHire einsetzten.

Eine praktische Checkliste für Verteidiger

Die Korrekturen sind unspektakulär. Sie hätten diesen Vorfall aber verhindert.

• Inventarisieren Sie jede Authentifizierungsoberfläche, die von einem von Ihnen verwendeten KI-Anbieter bereitgestellt wird, einschließlich Admin-Panels, Testumgebungen und Kundensupport-Tools. Behandeln Sie sie wie Kronjuwelen-Webanwendungen, nicht wie „Rohrleitungen“ für das Modell.
• Verlangen Sie von Anbietern eine schriftliche Bestätigung, dass in der Produktion keine Standard- oder gemeinsam genutzten Anmeldeinformationen existieren und dass während des Onboardings erstellte Testkonten bei der Inbetriebnahme gelöscht werden.
• Führen Sie authentifizierte IDOR/BOLA-Tests gegen jede vom Anbieter bereitgestellte API durch, insbesondere gegen APIs, die pro-Benutzer-Datensätze zurückgeben. Der OWASP API Security Top 10 listet dies aus gutem Grund auf Platz 1.
• Erzwingen Sie SSO mit Ihrem Identitätsprovider für jede Admin-Oberfläche des Anbieters, damit Anmeldeinformationen nicht unabhängig driften können und alte Konten sterben, wenn Mitarbeiter ausscheiden.
• Begrenzen Sie die Privilegien von Admin-Sitzungen, sodass ein einzelnes kompromittiertes Admin-Konto nicht den gesamten Bewerber- oder Kundendatensatz aufzählen kann.
• Verlangen Sie vom Anbieter, dass er Massenlesemuster gegen sensible APIs protokolliert und alarmiert. Das Abrufen von zig Millionen Bewerberdatensätzen sollte nicht wie ein normaler Tag aussehen.

Wie moderne offensive Tests dies entdeckt hätten

Ein gezieltes, autorisiertes offensives Engagement gegen die McHire-Anbieteroberfläche – nicht gegen den Chatbot – hätte dies am ersten Nachmittag gefunden. Die relevanten Prüfungen sind altbewährt: Credential-Spray gegen die Admin-Anmeldung, authentifizierte horizontale Zugriffskontrolle auf jede parametrisierte API und Überprüfung von Testkonten und Reset-Workflows.

Das Modell selbst braucht in dieser Geschichte kein Red Team. Das Modell verhielt sich korrekt. Die Schutzmechanismen des Chatbots hielten. Die Lektion ist, dass eine gründliche Anwendungssicherheitsüberprüfung des umgebenden Produkts jeden Schritt der Kill Chain markiert hätte, bevor er überhaupt live war.

Was als Nächstes zu beobachten ist

Erwarten Sie mehr davon. KI-Anbieter übernehmen immer sensiblere Arbeitsabläufe – Einstellung, Schadensfälle, Kundenservice, Terminplanung – und die administrativen Backend-Konsolen um diese Arbeitsabläufe herum enthalten nun Konzentrationen regulierter personenbezogener Daten, die zuvor in weniger zugänglichen Systemen lagen.

Zwei Dinge, die Sie in Ihrem eigenen Programm beobachten sollten: welche KI-Anbieter die höchste Konzentration regulierter personenbezogener Daten in Ihrem Namen halten und wie Ihr vertragliches Recht aussieht, deren Admin-Oberfläche zu testen. Wenn Sie keine authentifizierte Anwendungssicherheitsüberprüfung gegen das Panel des Anbieters durchführen können, vertrauen Sie darauf, dass das nächste Testkonto gelöscht wurde, die nächste API die Autorisierung durchsetzt und das nächste Standardpasswort geändert wurde. Die McHire-Offenlegung zeigt, was passiert, wenn dieses Vertrauen fehl am Platz ist.