Belgium’s Digital ID Trust Layer Was One Download Away From RCE
A browser extension used to connect Belgian electronic identity cards to government and banking websites contained a chain of severe trust failures. A malicious page could reach card data, recover a PIN and, with one downloaded file, run code on the user’s computer.
Researchers at Bay Area Labs have disclosed multiple vulnerabilities in the Connective signing extension and its native host application. The software allows websites to communicate with Belgian electronic ID cards and Maestro payment cards through a card reader attached to the computer.
The extension has more than two million weekly users according to its Chrome Web Store listing. Earlier vendor material said the Connective platform was used by more than 60 Belgian government agencies and departments, eight of the country’s ten largest banks and more than 1,000 enterprises. The researchers could confirm the user count, but not every organisation’s current use of the exact extension.
The weaknesses were fixed on 22 July 2026, 146 days after the first report. The research describes what the vulnerabilities made possible; it does not present evidence that attackers exploited them in the wild.
The trust check did not identify the website
The browser extension acts as a bridge. A web page sends a request through the extension to software running locally, and that native host performs operations involving the smart card. Because the browser deliberately isolates websites from local applications, this bridge is a highly privileged security boundary.
Connective required an activation token before a website could use sensitive commands. The token was signed, but it was not bound to the website that requested it. A token obtained from one legitimate service could therefore be replayed by another page or an embedded iframe.
With a valid token, a malicious site could issue commands to the Connective software without the native host knowing which origin was making the request. The researchers demonstrated access to data stored on connected Belgian eID and Maestro cards without meaningful permission from the user.
The PIN protection contained its own decryption key
The PIN flow introduced another failure. Connective returned a token containing the encrypted PIN to the web page—but the same token also carried the information needed to decrypt it. Encryption did not provide protection once both the ciphertext and key reached an untrusted page.
The website could also control the title and message displayed in the native PIN prompt. That would allow a malicious page to imitate a familiar tax, banking or government service while asking the user to enter a real eID PIN into a genuine-looking local dialog.
A stolen eID signature could have consequences beyond one session. The researchers described a scenario in which an attacker uses a victim’s signature to reset and re-register an itsme account with a different phone number, potentially creating persistent access to government, financial and commercial services connected to that identity.
From a browser page to local code execution
The most severe chain reached remote code execution. The native Connective application exposed a command that could load an arbitrary dynamic-link library. A malicious site could first cause an attacker-controlled DLL to be downloaded—perhaps presented as an ordinary PDF—and then instruct the native host to load it.
The victim did not have to be visiting a bank or government login page when this happened. The privileged bridge was available to ordinary web content, and the missing origin validation allowed a page to turn a local signing component into a code-execution path.
Why smart cards were not enough
Belgian eID authentication is designed around possession of a physical card, a reader and a PIN. Those factors remain strong only if every software layer preserves their meaning. Here, the browser extension and native host weakened the chain after the card had already proved its value.
This is a wider lesson for eIDAS signing tools, password managers, endpoint-security extensions and other products that connect web pages to native software. Browser extensions can see data across sites, while native messaging hosts can reach the operating system. If origin checks fail at that boundary, a low-trust website can inherit high-trust local capabilities.
What users and organisations should do
- Update both components. Confirm that the browser extension and native Connective software are on versions containing the July fixes.
- Restrict site access. Where browsers support it, configure the extension to run only on approved government, banking and signing domains instead of every website.
- Review managed-browser policy. Organisations using the extension should inventory installations, enforce the updated version and remove it from systems that no longer require card signing.
- Investigate suspicious downloads. Review unexpected DLL or document downloads followed by activity from the Connective native host, particularly during the period before remediation.
- Treat identity recovery as part of incident response. Affected users may need to review connected eID, itsme, banking and signing activity—not only scan the endpoint for malware.
The practical lesson
The Belgian eID vulnerability was not a failure of smart-card cryptography. It was a failure to preserve trust as the authentication process crossed from a website, through a browser extension, into native software.
That boundary deserves the same scrutiny as an Internet-facing API. A signed token is not sufficient if it does not identify the caller. Encryption is not protection if the decryption key travels with the secret. A native host should never execute a file simply because a browser extension asked it to. Strong identity systems remain only as strong as their least disciplined integration layer.
Sources and further reading
- Bay Area Labs: 8 out of 10 Banks in Belgium HATE This One Weird eID RCE
- Dark Reading: Belgium’s eID Authentication Opens Citizen Accounts to RCE
Continue the series: European National Cyber & Digital Law Series index
