De 'hack' van de EU-leeftijdsverificatie-app uitgelegd voor verifiers

Wat er gebeurde op 15-16 april 2026

Op 15 april 2026 kondigde voorzitter van de Europese Commissie Ursula von der Leyen in Brussel aan dat de EU-leeftijdsverificatie-app - vaak "mini-wallet" genoemd omdat het een smalle subset is van de aankomende EU Digital Identity Wallet (EUDI Wallet) - technisch klaar was voor uitrol. Binnen 24 uur publiceerde beveiligingsconsultant Paul Moore een korte video op X waarin hij beweerde de beveiligingen van de app in minder dan twee minuten te kunnen omzeilen. Nieuwsmedia pikten het snel op, en het verhaal werd trending op Reddit met tienduizenden upvotes op r/europe, r/privacy, r/technology en r/BuyFromEU.

Als u een merchant-checkout, een verifier-backend of een leeftijdsgebonden platform draait, klinkt de kop "in 2 minuten gehackt" alarmerend. Ze is ook misleidend. Hier is het technisch nauwkeurige beeld.

De drie ontwerpfouten die de onderzoeker identificeerde

Moores analyse, gebaseerd op de publiek leesbare Android-broncode op eu-digital-identity-wallet/av-app-android-wallet-ui, richt zich op drie zwakke punten in hoe de app lokale status beheert op een Android-toestel.

1. PIN losgekoppeld van de identiteitskluis

De app slaat een versleutelde PIN op in haar lokale voorkeurenbestand. De versleutelingssleutel is echter niet cryptografisch gebonden aan de credential-kluis waar de ondertekende leeftijdsattestaties zich bevinden. Door de PIN-gerelateerde items in het configuratiebestand te verwijderen en de app opnieuw te starten, kan een aanvaller een gloednieuwe PIN instellen terwijl hij de credentials van de vorige gebruiker overneemt. De kluis accepteert de gereset PIN als een nieuwe legitieme toegangscontrole, omdat de PIN en de credentials nooit aan elkaar vergrendeld waren.

Dit is een echte ontwerpfout. Een privacy-first architectuur zou de opgeslagen credentials ongeldig moeten maken telkens wanneer de PIN wordt gereset.

2. Rate limiting opgeslagen als een leesbare teller

De app beschermt tegen brute-force PIN-gokken met een teller die bij elke mislukte poging oploopt. Die teller staat in hetzelfde bewerkbare configuratiebestand als de PIN-status. Zet hem terug op nul en de app vergeet elke eerdere poging.

3. Biometrische controle gestuurd door een booleaanse vlag

Biometrische verificatie wordt ingeschakeld of overgeslagen op basis van één true/false-vlag in de configuratie. Zet die op false en de biometrische stap wordt nooit uitgevoerd.

Het kritieke voorbehoud dat de koppen weglaten

Alle drie de omzeilingen vereisen fysieke toegang tot een gerootte, ontgrendelde Android-toestel. Op dat punt heeft de aanvaller al volledige lees-/schrijftoegang tot de private opslag van de app - hetzelfde toegangsniveau als de app zelf heeft. Dit is geen remote exploit. Ze kan niet via het netwerk worden getriggerd. Er lekken geen credentials van het toestel af. Geen enkele derde partij ontvangt persoonsgegevens als gevolg van de omzeiling.

De hoogst gewaardeerde reactie op de r/europe-thread verwoordde het simpel: "met fysieke toegang tot het ontgrendelde gerootte toestel - toch een vrij belangrijk detail." Die reactie behaalde binnen enkele uren 140 upvotes, precies omdat het technische publiek van Reddit door de framing heen prikte.

Wat dit betekent voor verifiers en merchants

Als u leeftijdsverificatie integreert in een checkout of een platform, is de relevante vraag: kan een aanvaller een frauduleuze leeftijdsattestatie aan mijn backend presenteren? Het antwoord, op basis van de huidige openbaarmaking, is nee. De omzeiling geeft de aanvaller toegang tot zijn eigen, eerder opgeslagen credentials onder een nieuwe PIN, op zijn eigen gecompromitteerde toestel. Ze stelt hem niet in staat een credential te vervalsen, een nieuwe aan te maken, of de ondertekende attestatie van iemand anders opnieuw af te spelen.

Het OpenID4VP-protocol dat aan de remote presentatieflow ten grondslag ligt, werkt nog altijd exact zoals gespecificeerd. Voor een diepere blik op hoe dat protocol verifiers beschermt tegen replay en credential-manipulatie, zie onze diepgaande uitleg over OpenID4VP en onze technische toelichting op de werking van eIDAS-verificatie.

De legitieme structurele zorgen

Los van de "hack" zelf heeft de openbaarmaking twee structurele kritiekpunten naar boven gebracht die moeilijker te weerleggen zijn.

Platformafhankelijkheid. Omdat de app steunt op besturingssysteem-attestatie en ondertekende binaries om integriteit aan te tonen, draait ze uitsluitend op ondertekende iOS- en Android-builds. Een r/privacy-post met veel upvotes stelt dat er nooit een libre client kan verschijnen, omdat elke zelf-gecompileerde binary zal falen bij de attestatie. Dat is relevant als u een Europese instelling bent wiens mandaat voor digitale soevereiniteit harde afhankelijkheden van de gatekeeping door Apple en Google verbiedt.

Afhankelijkheid van Google Play Services. Hongaarse ontwikkelaars op r/programmingHungary wezen erop dat de Android-build Google Play Services nodig heeft om te functioneren. Een EU-instrument voor digitale identiteit dat niet bruikbaar is zonder een Google-eindgebruikerslicentieovereenkomst te accepteren, past ongemakkelijk bij de door de EU uitgesproken onafhankelijkheid van Amerikaanse hyperscalers.

De technisch onderlegde Hongaarse discussie leverde ook de meest accurate positieve observatie: de onderliggende protocolstack - OpenID Verifiable Credentials plus selectieve openbaarmaking via OpenID4VP - is oprecht een van de meer privacyvriendelijke ontwerpen die momenteel voor leeftijdsverificatie worden ingezet. De implementatieproblemen zijn oplosbaar; de cryptografische architectuur is solide.

Waarom open source deze ronde wint

De openbaarmakingscyclus zelf is het sterkste argument voor de open-sourcekeuze van de EU. De fouten werden geïdentificeerd door een onafhankelijke onderzoeker die publieke broncode las, binnen 24 uur gereproduceerd, en gaan al door de normale fix-pipeline. Een gesloten implementatie zou met dezelfde bugs zijn uitgeleverd, en niemand buiten de leverancier zou het geweten hebben totdat een echt datalek zich voordeed.

We hebben uitgebreid geschreven over waarom we dezelfde aanpak kozen voor onze eigen SDK - zie OpenEUDI geïntroduceerd: onze open-source verificatie-SDK en de lessen die het EU-audit open-source walletbouwers leert.

Wat merchants vandaag moeten doen

1. Verander uw integratieplannen niet. De omzeiling raakt niet de OpenID4VP-presentatieflow die uw backend verifieert. Ondertekende attestaties blijven cryptografisch geldig.
2. Houd de fix-timeline in de gaten. De referentie-Android-app van de EU zal worden gepatcht; de drie bovenstaande problemen zijn eenvoudige software-fixes.
3. Scheid leeftijdsverificatie van accountherstel. Als uw checkout lokale status opslaat die aan een geverifieerde gebruiker is gekoppeld, pas dan de les toe: bind toegangscontroles (PIN, passkey) cryptografisch aan de data die ze beschermen.
4. Als u uw eigen verifier bouwt, gebruik dan ons privacy-first patroon - eenmalig verifiëren, alleen een boolean opslaan, geen documentafbeeldingen bewaren. Zie Privacy-first leeftijdsverificatie met OpenEUDI voor de referentie-implementatie.

Het bredere beeld

Dit verhaal vertelt ons drie dingen over waar het EUDI Wallet-ecosysteem in april 2026 staat. Ten eerste levert de EU oprecht auditeerbare code, en auditen onderzoekers die oprecht. Ten tweede worden de wallet-apps gebouwd met een aanzienlijke afhankelijkheid van platformattestatie - een afweging met serieuze implicaties voor soevereiniteit en overdraagbaarheid. Ten derde blijft de merchantgerichte verificatieflow ongemoeid door deze openbaarmaking. Als u van plan was EUDI Wallet-verificatie aan uw checkout toe te voegen, zou niets uit de afgelopen 72 uur dat plan moeten veranderen.

Voor een land-per-land overzicht van waar lidstaten nu staan met hun wallet-uitrol, zie onze EUDI Wallet-uitrolstatus van april 2026. Voor het juridische kader dat regelt hoe gebruikers instappen op deze wallets, zie onze uitleg van Uitvoeringsverordening 2026/798.

---

Op zoek naar een verifier-integratie die vandaag al klaar is voor de EUDI Wallet en automatisch opwaardeert naar productie? Zie de managed plannen van eIDAS Pro of lees de OpenEUDI SDK-quickstart.

Dit artikel is ook beschikbaar op Dev.to.