Der 'Hack' der EU-Altersverifikations-App erklärt

Was am 15. und 16. April 2026 geschah

Am 15. April 2026 kündigte EU-Kommissionspräsidentin Ursula von der Leyen in Brüssel an, dass die EU-Altersverifikations-App — oft als "Mini-Wallet" bezeichnet, weil sie eine eng umrissene Teilmenge der kommenden EU Digital Identity Wallet (EUDI Wallet) darstellt — technisch einsatzbereit sei. Innerhalb von 24 Stunden veröffentlichte der Sicherheitsberater Paul Moore ein kurzes Video auf X, in dem er behauptete, die Schutzmechanismen der App ließen sich in weniger als zwei Minuten umgehen. Medien griffen die Nachricht schnell auf, und die Geschichte wurde auf Reddit mit zehntausenden Upvotes zum Trend — auf r/europe, r/privacy, r/technology und r/BuyFromEU.

Wer einen Händler-Checkout, ein Verifier-Backend oder eine altersbeschränkte Plattform betreibt, für den klingt die Schlagzeile "in 2 Minuten gehackt" alarmierend. Sie ist zugleich irreführend. Hier ist das technisch akkurate Bild.

Die drei Design-Schwachstellen des Forschers

Moores Analyse, gestützt auf den öffentlich einsehbaren Android-Quellcode unter eu-digital-identity-wallet/av-app-android-wallet-ui, konzentriert sich auf drei Schwächen in der Art, wie die App den lokalen Zustand auf einem Android-Gerät verwaltet.

1. PIN nicht mit dem Credential-Vault verknüpft

Die App speichert eine verschlüsselte PIN in ihrer lokalen Präferenzdatei. Der Schlüssel zur Verschlüsselung ist jedoch kryptografisch nicht an den Credential-Vault gebunden, in dem die signierten Altersattestierungen liegen. Löscht ein Angreifer die PIN-Einträge in der Konfigurationsdatei und startet die App neu, kann er eine brandneue PIN vergeben und erbt dabei die Credentials des Vorgängers. Der Vault akzeptiert die neue PIN als legitime Zugangskontrolle, weil PIN und Credentials nie fest aneinander gekoppelt waren.

Das ist eine echte Design-Schwachstelle. Eine datenschutzorientierte Architektur müsste die gespeicherten Credentials bei jedem PIN-Reset ungültig machen.

2. Rate-Limit als Klartext-Zähler

Gegen Brute-Force-Angriffe auf die PIN schützt ein Zähler, der bei jedem Fehlversuch inkrementiert. Dieser Zähler liegt in derselben editierbaren Konfigurationsdatei wie der PIN-Status. Wird er auf Null zurückgesetzt, vergisst die App alle bisherigen Versuche.

3. Biometrie-Prüfung durch Boolean-Flag steuerbar

Die biometrische Verifikation wird durch ein einziges true/false-Flag in der Konfiguration aktiviert oder übersprungen. Setzt man es auf false, wird der biometrische Schritt schlicht nicht mehr ausgeführt.

Der entscheidende Vorbehalt, den die Schlagzeilen unterschlagen

Alle drei Umgehungen erfordern physischen Zugriff auf ein gerootetes, entsperrtes Android-Gerät. An diesem Punkt hat der Angreifer bereits vollen Lese- und Schreibzugriff auf den privaten Speicher der App — dieselbe Zugriffsebene, die die App selbst hat. Das ist kein Remote-Exploit. Er lässt sich nicht über das Netzwerk auslösen. Es werden keine Credentials vom Gerät exfiltriert. Kein Dritter erhält in Folge der Umgehung personenbezogene Daten.

Der meistgelikete Kommentar im r/europe-Thread brachte es auf den Punkt: "mit physischem Zugriff auf das entsperrte, gerootete Gerät — ein eher wichtiger Teil der Geschichte." Dieser Kommentar erreichte innerhalb weniger Stunden 140 Upvotes, gerade weil das technische Publikum auf Reddit die Dramatisierung durchschaut hat.

Was das für Verifier und Händler bedeutet

Wer Altersverifikation in einen Checkout oder eine Plattform integriert, muss sich die richtige Frage stellen: Kann ein Angreifer meinem Backend eine gefälschte Altersattestierung präsentieren? Die Antwort lautet nach aktuellem Stand: nein. Die Umgehung erlaubt es dem Angreifer lediglich, auf seine eigenen, bereits zuvor gespeicherten Credentials unter einer neuen PIN auf seinem eigenen kompromittierten Gerät zuzugreifen. Sie erlaubt es ihm nicht, Credentials zu fälschen, neue zu erzeugen oder eine signierte Attestierung einer fremden Person wiederabzuspielen.

Das OpenID4VP-Protokoll, das dem Remote-Präsentationsfluss zugrunde liegt, funktioniert weiterhin exakt wie spezifiziert. Für einen tieferen Blick darauf, wie dieses Protokoll Verifier vor Replay-Angriffen und Credential-Manipulation schützt, lesen Sie unseren OpenID4VP-Tiefgang und unsere technische Erläuterung zur Funktionsweise der eIDAS-Verifikation.

Die legitimen strukturellen Bedenken

Abseits des "Hacks" selbst hat die Offenlegung zwei strukturelle Kritikpunkte zutage gefördert, die schwieriger von der Hand zu weisen sind.

Plattform-Abhängigkeit. Weil die App auf Betriebssystem-Attestierung und signierte Binaries setzt, um ihre Integrität nachzuweisen, läuft sie ausschließlich auf signierten iOS- und Android-Builds. Ein stark geupvoteter r/privacy-Beitrag argumentiert, dass niemals ein freier Client erscheinen könne, weil jedes selbst kompilierte Binary an der Attestierung scheitern würde. Das ist relevant für europäische Institutionen, deren Mandat zur digitalen Souveränität harte Abhängigkeiten von Apples und Googles Gatekeeper-Rollen eigentlich ausschließt.

Abhängigkeit von Google Play Services. Ungarische Entwickler auf r/programmingHungary wiesen darauf hin, dass der Android-Build auf Google Play Services angewiesen ist, um zu funktionieren. Ein EU-Werkzeug für digitale Identität, das ohne die Zustimmung zu einer Endnutzer-Lizenzvereinbarung von Google nicht nutzbar ist, passt nur schwer zum erklärten Anspruch der EU, sich von US-Hyperscalern zu emanzipieren.

Die technisch fundierte ungarische Diskussion lieferte zugleich die treffendste positive Beobachtung: der zugrundeliegende Protokoll-Stack — OpenID Verifiable Credentials kombiniert mit selektiver Offenlegung via OpenID4VP — gehört tatsächlich zu den derzeit am wenigsten invasiven Designs für Altersverifikation. Die Implementierungsprobleme sind behebbar; die kryptografische Architektur ist solide.

Warum Open Source diese Runde gewinnt

Gerade der Offenlegungszyklus selbst ist das stärkste Argument für die Open-Source-Entscheidung der EU. Die Schwachstellen wurden von einem unabhängigen Forscher gefunden, der öffentlichen Quellcode gelesen hat, binnen 24 Stunden reproduziert und befinden sich bereits im regulären Fix-Prozess. Eine geschlossene Implementierung wäre mit denselben Fehlern ausgeliefert worden, und niemand außerhalb des Herstellers hätte davon gewusst, bis ein echter Breach sie erzwungen hätte.

Wir haben ausführlich dargelegt, warum wir denselben Ansatz für unser eigenes SDK gewählt haben — siehe OpenEUDI vorgestellt: unser Open-Source-Verifikations-SDK und Was das EU-Audit Entwicklern von Open-Source-Wallets beibringt.

Was Händler heute tun sollten

1. Ändern Sie Ihre Integrationspläne nicht. Die Umgehung betrifft nicht den OpenID4VP-Präsentationsfluss, den Ihr Backend prüft. Signierte Attestierungen sind kryptografisch weiterhin gültig.
2. Beobachten Sie die Fix-Timeline. Die Referenz-Android-App der EU wird gepatcht; die drei genannten Punkte sind unkomplizierte Software-Fixes.
3. Trennen Sie Altersverifikation von Account-Recovery. Falls Ihr Checkout lokalen Zustand zu einem verifizierten Nutzer speichert, ziehen Sie die Lehre: Binden Sie Zugangskontrollen (PIN, Passkey) kryptografisch an die Daten, die sie schützen sollen.
4. Wenn Sie einen eigenen Verifier bauen, folgen Sie unserem datenschutzorientierten Muster — einmal verifizieren, nur einen Bool speichern, keine Dokumentenbilder aufbewahren. Die Referenzimplementierung finden Sie unter Datenschutzorientierte Altersverifikation mit OpenEUDI.

Das größere Bild

Diese Geschichte sagt uns drei Dinge darüber, wo das EUDI-Wallet-Ökosystem im April 2026 steht. Erstens: Die EU liefert tatsächlich auditierbaren Code, und Forscher auditieren ihn tatsächlich. Zweitens: Die Wallet-Apps werden in erheblicher Abhängigkeit von Plattform-Attestierung gebaut — ein Kompromiss mit spürbaren Folgen für Souveränität und Portabilität. Drittens: Der händlerseitige Verifikationsfluss ist von dieser Offenlegung unberührt. Wer geplant hat, EUDI-Wallet-Verifikation in seinen Checkout aufzunehmen, sollte durch nichts aus den letzten 72 Stunden von diesem Plan abrücken.

Einen länderspezifischen Blick darauf, wo die Mitgliedstaaten aktuell mit ihrem Wallet-Rollout stehen, bietet unser EUDI-Wallet-Rolloutstatus im April 2026. Den rechtlichen Rahmen für das Onboarding der Nutzer in diese Wallets erläutert unsere Analyse der Durchführungsverordnung 2026/798.

---

Suchen Sie eine Verifier-Integration, die heute schon für die EUDI Wallet bereit ist und automatisch produktionsreif wird? Siehe eIDAS Pros Managed Plans oder den OpenEUDI SDK Quickstart.