Researcher James Arnott of Bay Area Labs disclosed severe, now-resolved flaws in the Connective digital identity system, a browser extension used by more than two million people in Belgium. The software failed to verify which website was communicating with the user’s computer, letting any website or embedded online ad interact directly with the Connective application. The findings, presented at DEF CON 34, affect infrastructure relied on by eight of Belgium’s ten largest banks and more than sixty government agencies.
Missing Origin Verification Opens the Connective Application to Any Website
The core defect was that Connective did not confirm which website was talking to the local application, so a malicious page could drive the extension without permission. That weakness produced a chain of consequences, from reading stored identity data to forging legally binding signatures.
Silent Reads of eID and Payment Card Details From a Malicious Page
A malicious website could silently read connected eID and payment card details, Arnott found. The information was accessible without any visible user interaction, meaning a user browsing a compromised page or viewing an embedded advertisement could have data harvested from the extension in the background.
Customizable Pop-Ups That Trick Users Into Revealing Their eID PIN
The researcher also showed how a site could trick users into revealing their eID PIN through official-looking authentication pop-ups. The dialogs’ text was customizable and did not display the requesting domain, so a user could not tell the prompt was not genuine. With a captured PIN, an attacker could generate unauthorized approval tokens to forge legally binding electronic signatures whenever the victim’s physical eID card was inserted into a card reader.
The Drive-By Remote Code Execution Vector
A separate remote code execution vulnerability worked regardless of whether an eID card was plugged in. A file-processing flaw let a malicious website force the software to run attacker-controlled code at user level through a drive-by attack, in which a user downloaded a file disguised as a standard document and then visited a page. Arnott noted that no special permissions were required and that the design carried a self-propagating, worm-like risk if credentials were hijacked.
The Undermined Trust Model for Belgian Digital Identity
The flaws weaken the foundation of Belgium’s digital trust infrastructure. Government portals such as CSAM.be and identity providers such as Itsme rely on eID signatures, and stolen signing capability could register or hijack digital identity accounts. Because the extension sits at the center of both government and banking authentication, a compromise of the signing flow reaches well beyond the individual user.
Nitro’s 146-Day Remediation and the Final Enforcement Window
Nitro Software Belgium fully remediated the issues 146 days after Arnott’s initial report and awarded a $200 bug bounty. The updates block unauthorized origin requests and secure PIN handling, with final enforcement completed in late July. No CVEs appear to have been assigned, so the public record of the incident rests on the researcher’s disclosure rather than a vulnerability identifier.
What Organizations Using Connective Should Verify Now
Organizations relying on Connective should confirm they are running the updated versions, re-audit their signing flows, and monitor identity-account registrations tied to eID signatures, according to the disclosure. The remediation is complete, but the audit trail for any signatures issued during the exposure window depends on matching activity logs against the fixed deployment.
The Customizable-Pop-Up Weakness and the Limits of UI Trust
The customizable-prompt weakness shows that trust in electronic signatures depends entirely on the integrity of the user interface that collects the PIN. When that interface can be impersonated by any webpage, the cryptographic strength of the signature becomes irrelevant. For developers of e-signature and identity software, the episode illustrates why origin verification for the local helper application is not a convenience feature but the security boundary itself.
