8 out of 10 Banks in Belgium HATE This One Weird eID RCE - Am I Being Pwned?

← Back to blogTL;DR. The Connective signing extension has over 2 million users, primarily in Belgium, and lets websites talk to electronic ID (eID) and Maestro payment cards. It was used by "8 of the 10 largest banks in Belgium and 60+ Belgian government agencies and departments"1, and it underpins eIDAS qualified signatures, a signature format legally trusted by governments and organisations.

We found multiple major issues. Any site or iframe could read the user's eID and Maestro card data, and recover their eID PIN, which the binary handed back to the page inside a token that carried both the ciphertext and the key to decrypt it. Worst of all, any site could trigger a drive-by RCE by getting the native binary to load and run an attacker-supplied library. All the user sees is a file download, such as a PDF, while they are getting RCE'd.

The company behind it, Nitro Software Belgium, is a Qualified Trust Service Provider on the EU eIDAS Trusted List, the highest trust tier the regulation defines. Fixed 146 days after the first report.

We presented this research at DEF CON:

What is the Connective signing system?

The Connective signing system has two parts, the extension and the native host. Web pages use the extension to talk to the native host, which then talks to the smart card readers attached to the machine to complete tasks like digital signing.

The extension is thin, acting as just a communication layer between the web pages and the native host, forwarding all messages.

It's used to authenticate with sites and to sign documents. With 2M+ users, it was stated in 2021 that Connective was used across 60+ government services and over 1,000 enterprises. We can't confirm that the Connective signing extension was explicitly used by all of these organisations, but we can confirm the 2M+ weekly active user count.

A sample eID

Why did we look into this?

The Connective signing extension was flagged to us after it was scanned and found to not be forwarding the origin of the request to the native host. This meant the program running on the computer didn't know which site it was speaking to, so we knew something was up.

None of the team is from Belgium, but that didn't stop us. It did present a few challenges, as we had to make a mock eID to test with.

We did see there was a token required to run all but a "version" command, which returned the version of the native host and the extension. Even with this required activationToken, we found it suspicious that the origin of the message was never forwarded to the native host, which prompted us to look further, as there was no way the native host could know the origin of the site that was messaging it.

We were actually using it as test data for our full-stack automated extension + native host scanning functionality, which is why we looked into it so much relative to our other discoveries.

Breakdown of the activationToken and token flow

The activationToken is a token cryptographically signed with RSA 2048, provided by the partnered sites that use the Connective signing extension, to give permission for a site to use the Connective system on the user's machine.

It's essentially the gateway to all of the fun commands.

This token, in its raw form, looks like this:

Lhx4xKzCIJfSRAaP2jdgdM4WYmjQ/Sremo9v/Db/8T9A+NQd6Or3NO0V3nk4Rx9OPL8oDFQfrrZETRlm1dvTt30TBaua4W0OOYuR...

Decoded via RSA signature recovery, we get this:

"token": "b138fcf4-4619-47eb-846a-dc9cbeb7714d", // UUID - not used<br>"ttl": 1773811513534, // 2026-03-18 05:25:13 UTC<br>"features": 7 // all bits set = all ops allowed

This token includes a UUID, which we did not observe serving a purpose, alongside a TTL and a features bitmask. The features bitmask flags different "features" on and off:

BitEnablesbit 0GET_READERS, READ_FILE, PIN_PAD_AVAILABLE, VERIFY_PIN, COMPUTE_SIGNATURE, COMPUTE_AUTHENTICATIONbit 1unused / reservedbit 2COMPUTE_SIGN_CHALLENGE, SELECT_MAESTRO, GET_PROCESSING_OPTIONS, READ_RECORD<br>The oracle we used to get these tokens was from Doccle.be, and their tokens allowed all operations and had a TTL of 24 hours.

Obviously, after decoding these activationTokens, it's clear to see they're missing the origin too. That means any web page can just replay these tokens and get full access to the Connective system on the user's machine.

Reading eIDs and Maestro cards without any permissions

So, now we have this activation token which is not tied to the origin, we can read connected eIDs and Maestro cards without the user's consent or knowledge.

The PIN token, and the attacker-controlled dialog

When we discovered how the pinToken worked, we realised this wasn't just a single mistake from a developer, we realised the developer didn't know what they were doing.

The pinToken was sent from the native host to the extension to the web page when the user entered their PIN into the native Connective dialog, so it was...