Researcher Says Chrome Extension Can Bypass EU Age Verification Demo

Security consultant Paul Moore says he bypassed the latest EU age verification reference app using a Chrome extension that repeatedly presented an accepted proof of being over 18.

In a demonstration published on X, Moore tested Android release 2026.07-1 and argued that the verifier could not reliably distinguish the official mobile app from software running inside a browser extension.

The demonstration does not show a break in the credential’s cryptography. Instead, it raises questions about device binding, single-use enforcement, and how a website verifies that an anonymous age attestation comes from an approved app instance.

The software remains a reference implementation

The system tested by Moore is an open-source, white-label implementation of the European Commission’s age verification blueprint. Member States and other providers can customize the software before deploying their own services.

The Commission describes the solution as a “mini wallet” that lets people prove they meet an age threshold without revealing their identity, birth date, or other personal information. The EU age verification overview says the blueprint became feature-ready in April 2026.

However, the project’s source repository identifies the Android software as a demo and reference implementation. It says providers still need to complete production work involving app hardening, key management, secure storage, issuer configuration, enrollment security, and release signing.

Component	Current role
EU age verification blueprint	Technical framework for national and commercial implementations
Android reference app	Open-source white-label application for testing and customization
Attestation provider	Checks age evidence and issues proof-of-age credentials
Relying party	Website or service that requests and verifies an age proof
Trusted list	Identifies approved attestation providers and applications

How the claimed Chrome extension bypass works

Moore’s extension appears to act as an alternative credential presenter. When the test website requests proof that the visitor is over 18, the extension supplies information that the verifier accepts without requiring the official mobile application to complete a fresh presentation.

According to a report examining the demonstration, the proof of concept did not require a new passport scan, facial comparison, or hardware-backed device key. The same software-generated key could reportedly support repeated presentations.

Moore argues that the system’s single-use protection depends too heavily on compliant client software. If a modified client refuses to delete a credential after presenting it, the relying website may lack enough information to detect reuse.

1. A website sends a request for proof that the visitor is over 18.
2. The Chrome extension handles or intercepts the presentation process.
3. The extension supplies a credential or proof accepted by the test verifier.
4. The website receives an over-18 result without identifying the person.
5. The extension repeats the presentation during later requests.

Version 2026.07-1 added security and stability changes

The Android team released version 2026.07-1 on July 10. The official GitHub release notes list improvements to biometric authentication, error handling, cleartext traffic restrictions, passport scanning, and dependency security.

The update introduced a userAuthenticationRequired configuration option. It allows the wallet to skip a separate application authentication step when hardware-protected keys already require biometric approval.

Version 2026.07-1 also replaced the deprecated SpongyCastle cryptographic provider with BouncyCastle. Other changes reduced the risk of personal information appearing in logs and documented additional production-hardening work.

• New biometric authentication configuration
• Clearer errors when required biometrics are unavailable
• Cleartext network traffic disabled on older Android versions
• Protection against sensitive exception details appearing in logs
• Passport scanner crash fixes
• Updated cryptographic and Android dependencies

Earlier releases addressed local app weaknesses

Moore previously demonstrated a different attack involving local access to the Android application. That earlier test focused on editable settings, PIN protection, biometric checks, and locally stored data.

The project responded with multiple changes. Release 2026.04-2 encrypted app data, placed keys in hardware-backed storage when available, added checks for rooted devices, strengthened PIN rules, and changed the handling of passport images.

Later updates bound the encrypted database and biometric state to the wallet’s vault key. The Android app release history shows that these hardening changes addressed local storage and authentication, while Moore’s latest claim concerns credential presentation and verifier trust.

What the EU specification requires

The EU architecture separates age verification into issuance and presentation. An approved attestation provider first checks the user’s age through a national electronic identity system, an official document, or another trusted data source.

The provider then issues a proof-of-age attestation to an app instance. When the user visits restricted content, the app presents the attestation and the website checks its signature, requested age attribute, and issuing provider.

The EU technical specification includes several requirements intended to prevent untrusted clients and reused credentials:

• The app must authenticate its user before presenting an attestation.
• The app must use native cryptographic hardware when available.
• Each proof-of-age attestation must be used once and then removed.
• Attestation providers must issue credentials only to listed apps.
• Relying parties must verify authenticity and integrity.
• Relying parties must check that the issuer appears on the EU trusted list.

Why client-side single-use controls matter

The specification places the requirement to remove a used attestation on the age verification application. A compliant app should consume one proof and select another credential from a previously issued batch for the next request.

Moore’s criticism focuses on what happens when unofficial client software ignores this rule. A browser extension or modified wallet may attempt to retain a proof, reuse key material, or repeat an accepted presentation.

Bypassing the latest #EU #ageVerification app (2026.07-1) with a Chrome extension… again.

Despite 3 months of security hardening and genuine improvements across the board, the fundamental issue cannot be solved.

Anonymous age verification doesn't work. https://t.co/NSfvuQAeXz pic.twitter.com/hwRTxiZiwZ

— Paul Moore – Security Consultant  (@Paul_Reviews) July 14, 2026

A secure production deployment therefore needs more than a client instruction to delete local data. Issuers and verifiers may need mechanisms for detecting invalid applications, rejected wallet attestations, expired proofs, duplicated presentations, or credentials that do not satisfy the required trust policy.

Anonymity does not automatically make replay unavoidable

The demonstration does not prove that privacy-preserving age verification must identify every person to prevent abuse. A system can bind a proof to a device, transaction, verifier, session, challenge, or short validity period without sharing the person’s name with the website.

These protections require careful design because aggressive binding can create tracking risks. If the same persistent identifier appears on several websites, services could use it to link a person’s browsing activity.

The EU’s objective is to reveal only whether a person meets the required threshold. According to the Commission’s policy description, online services should not receive the user’s identity or exact age.

Security control	Purpose	Privacy consideration
Session challenge	Binds a proof to one request	Can avoid persistent identifiers
Verifier binding	Stops use on a different website	May reveal which service requested the proof
Hardware-backed key	Links presentation to an approved device	Must avoid cross-site device tracking
Short expiration	Limits the lifetime of copied material	Requires frequent credential issuance
Trusted app attestation	Rejects unauthorized wallet software	May depend on mobile platform providers

No production EU-wide service was breached

Moore demonstrated the behavior against the reference system and its test verifier. The published material does not show that an operational national deployment, government identity database, or production website suffered a breach.

The European Commission has not published a technical response confirming or rejecting the latest bypass claim. The project remains under active development, and national implementations may add controls that the public demo does not enforce.

Notes:
This PoC was created entirely by #ClaudeAI in a matter of minutes.
Don't focus on enrolment (that part is invalid in a test environment). Instead, focus on the presentation and the fact the verifier has *absolutely no information* other than an "over 18" attestation, so…

— Paul Moore – Security Consultant  (@Paul_Reviews) July 14, 2026

The public account of Moore’s test nevertheless highlights an important deployment issue. A verifier must validate the wallet, presentation context, issuer, and credential behavior, not just accept a correctly structured over-18 response.

What website operators should consider

Websites should avoid treating the reference demo as a finished compliance product. Operators need a production implementation with an approved issuer, trusted application checks, secure presentation protocols, logging, and abuse monitoring.

They should also test whether their verifier rejects repeated responses, modified wallet clients, stale challenges, unapproved issuers, and proofs intended for another service.

The age verification architecture provides a framework, but each implementer remains responsible for completing the security work required for a live deployment.

• Use unique cryptographic challenges for every verification request.
• Reject expired, duplicated, or incorrectly scoped presentations.
• Validate the issuer against the official trusted list.
• Confirm that credentials came from an approved app instance.
• Complete independent penetration testing before launch.
• Avoid persistent identifiers that allow cross-site tracking.
• Monitor failed and repeated verification attempts.

Moore’s latest proof-of-concept video adds pressure on the developers to explain how production verifiers will enforce single-use credentials and reject unauthorized presentation software without weakening the system’s privacy guarantees.

FAQ