← Back to blog

August 10, 2026 Vulnerability Research

Browser Extension Security Lessons From the Belgian eID Flaws

A missing origin check in Belgium’s eID browser extension lets any web page forge legally binding signatures, steal identity and payment data, capture a user’s PIN, and run code on the machine. The software served over 2 million people, 8 of Belgium’s 10 largest banks, and 60-plus government agencies, so the impact reached far past the software itself. These are trust boundary flaws that automated scanners rarely catch, and this guide explains how each one worked and how to test for the same class of weakness in your own browser extensions and companion apps.

This guide explains how each flaw worked, why this class of bug slips past automated scanners, and how to test for the same weakness in your own browser extensions and companion apps. None of it requires a specific product to act on. By the end, you will know the vulnerability-to-test map for this flaw class, the design principles that prevent it, and the checklist to run against your own environment.

Table of Contents

Key Takeaways On Browser Extension Security

The points below summarize what the Belgian eID flaws teach about browser extension security, before the detailed walkthrough.

Browser extension security depends on origin validation. If a browser extension or its native messaging host does not verify which website is calling, any site the user visits can reach it.
Security prompts must show their origin. A dialog that lets a web page write its own text without displaying the requesting domain is a phishing tool waiting to be used.
Secrets should never return to the caller. Sending a PIN, token, or key back to the requesting page turns an authentication step into a theft.
These are business logic and trust boundary flaws, so a clean automated scan does not mean the browser extension is safe. A person has to reason about what the software should and should not trust.
The blast radius extends to everything downstream. Services that trusted eID signatures were exposed even though they had no flaws of their own.

What Happened In The Belgian eID Browser Extension Disclosure

According to a report by SecurityWeek, security researcher James Arnott, founder of Bay Area Labs, disclosed the findings at DEF CON and published a technical write-up. The affected software is the Connective digital identity system from Nitro Software Belgium, a browser extension used by more than 2 million people to manage digital identity authentication and to execute legally binding electronic signatures. Eight of Belgium’s 10 largest banks and over 60 government agencies relied on it.

The central weakness was that the software failed to verify which website was attempting to communicate with the user’s computer. Because that check was missing, any website, and even an embedded online advertisement, could interact directly with the Connective application on a victim’s machine without the user’s knowledge or permission. From that foundation, the researcher demonstrated identity theft, signature forgery, and remote code execution. Nitro remediated the issues 146 days after the initial report, deployed updates to block unauthorized origin requests and to secure PIN handling, and completed its final security enforcement in late July. The company awarded a $200 bug bounty, and no CVEs appear to have been assigned.

How The Belgian eID Browser Extension And Its Companion App Worked

Software that connects a web page to a smart card follows a recognizable pattern, and understanding it makes the flaws easier to follow. A browser extension sits inside the browser and acts as a bridge. Behind it, a locally installed companion application talks to the smart card reader that holds the physical eID card. When a website needs the user to authenticate or sign, it calls the extension, the extension passes the request to the companion application, often through a channel such as browser native messaging, and the companion application drives the card reader.

This bridge design is common well beyond eID. Password managers, hardware security keys, hardware wallets, document signing tools, and antivirus consoles all use some version of a browser component talking to a local helper. The security of the whole arrangement rests on two guarantees. The bridge must accept requests only from callers it is meant to serve, and it must never hand sensitive material back to a caller that has no right to it. The Belgian eID software broke both guarantees, which is why a browser extension flaw became a national identity problem.

The Missing Origin Validation That Let Any Website Connect

Browsers keep websites apart through the same-origin policy, which stops one site from reading another site’s data. A companion application does not automatically inherit that protection. Whether the bridge is built on browser native messaging, a local network socket, or a localhost service, the helper has to decide for itself which callers to trust. The OWASP Browser Extension Vulnerabilities cheat sheet makes the rule explicit: an extension must validate the sender origin or URL of every message, and a native messaging host must pin the exact callers it will accept.

The Connective software performed no such check, so it answered to whoever called. A page the victim never intended to grant any authority, including a malicious advertisement loaded inside an ordinary website, could speak to the eID application as if it were a trusted banking portal. This is not a one-off. The same class of flaw was disclosed in the Pega Browser Extension as CVE-2026-1079, where a native messaging host failed to validate the origin of incoming messages, so a malicious website could send it crafted commands. Origin validation is the first control a tester should look for in any browser extension or companion app, because its absence undermines every control that follows.

Related read: CVE-2026-10753: A Broken Access Control Flaw CredShields Found in Google’s Site Kit, a different surface with the same root cause: a caller that should never have been trusted, was.

How the eID PIN Theft and Signature Forgery Worked

Two design choices turned the missing origin check into full identity compromise. The first was that the software let web pages customize the text inside its authentication dialogs without displaying the domain making the request. A user faced with an official-looking prompt had no reliable way to tell a genuine bank request from an attacker’s copy, because the one piece of information that would settle it, the requesting domain, was never shown.

The second choice was more direct. When a user entered a PIN into a prompt, the application transmitted that PIN back to the requesting web page. With the PIN in hand and the physical card present in the reader, an attacker could generate unauthorized approval tokens and forge legally binding electronic signatures. A security step meant to prove the user’s identity instead delivered the user’s secret to the attacker. The lesson generalizes cleanly: a browser extension and its companion app should treat a PIN, a token, or a private key as something that goes into the local trust boundary and never comes back out to the caller.

The Remote Code Execution Flaw In The Companion App File Handling

Alongside the identity flaws, the researcher found a remote code execution vulnerability that worked whether or not an eID card was plugged in. By abusing the way the companion application processed files on the local computer, a malicious website could force the software to run attacker-controlled code at the user level.

The delivery method made this practical rather than theoretical. An attacker could trick a user into downloading a file disguised as a standard document, then get the user to visit a web page that caused the application to process that file. No special permissions were required. File handling is a recurring source of code execution across desktop software, because parsing untrusted input pulls in format libraries, path logic, and sometimes deserialization, each of which can be turned against the program. When a web page can steer which files a companion application opens, that whole surface becomes reachable from the internet.

Why The Browser Extension Flaw Could Spread Like A Worm

The code execution flaw carried an additional risk that raises its severity. Because it required no special permissions and could hijack user credentials, it could spread like a self-propagating worm by using a compromised machine to send malicious links to other potential victims.

Worm behavior changes the shape of an incident. A flaw that compromises one machine at a time is serious. A flaw that uses each compromised machine to reach the next grows on its own without further attacker effort. For software installed on millions of endpoints across a country’s banking and government population, self-propagation is the difference between a contained event and a national one. This is why the drive-by nature of the flaw, needing only a downloaded file and a web visit, matters as much as the code execution itself.

Why Scanners Miss Browser Extension And Business Logic Flaws

Automated scanners do a defined job well. They match known vulnerable patterns, flag outdated components, and catch common injection classes quickly and at scale, which makes them a sensible first pass on any codebase or browser extension.

The Belgian eID flaws sit outside that job. Whether a browser extension should trust any caller, whether a PIN should ever travel back to the page that asked for it, and whether a security dialog should display its origin are all questions about intended behavior. A scanner holds no model of what the software is supposed to allow, so a trust boundary flaw like this can pass a clean scan while still handing an attacker a legally binding signature. Finding it depends on a person who understands the trust boundaries and probes them on purpose, which is the core of manual, human-led testing.

Related read: From Vulnerable to SOC 2 Ready: A Complete API Security Overhaul for a Fintech Startup, a worked example of a CredShields engagement that surfaced business logic flaws automated scanners do not catch.

How the eID Flaws Spread Across the Identity Trust Chain

The impact reached well past the Connective software because so much of Belgium’s digital ecosystem trusts eID signatures to establish who a user is. Government portals such as CSAM.be and third-party identity providers such as Itsme relied on those signatures.

Both of those services were well built, and the disclosure attributes no flaws to either. Their exposure came entirely from what they trusted. Because an attacker could forge a valid eID signature, that attacker could register or hijack digital identity accounts on services that accepted the signature as proof of identity. One weak browser extension turned into risk across everything that depended on it. Any organization that delegates identity to an external provider inherits that provider’s security posture, which is why the trust boundary between you and any identity signal deserves testing and monitoring of its own.

Related read: What MAS Auditors Look for in Your Identity and Access Architecture, which covers how regulators treat third-party and vendor access under the MAS TRM Guidelines.

The Browser Extension Vulnerability-To-Test Map

The table below maps each flaw class from the Belgian eID case to what an attacker does with it and how a tester confirms whether the same weakness exists in your software. It is the single most useful reference to keep beside a browser extension review.

Flaw class	What an attacker does	How a tester checks it
Missing origin validation	Calls the browser extension or native messaging host from any website the victim visits, including a malicious ad	Enumerates the extension messaging surface and native messaging host, then attempts cross-origin calls from an attacker-controlled page
Origin-hiding security prompts	Presents an official-looking dialog that hides the requesting domain	Inspects whether every security prompt displays the true origin and whether page-supplied text can impersonate a trusted party
Secret returned to caller	Receives the PIN, token, or key back from the application	Traces where secrets flow after entry and confirms none are returned to the requesting page
Signature or action invoked cross-origin	Forges a legally binding signature while the card is present	Attempts to trigger signing or other privileged actions from an untrusted origin
Unsafe local file handling	Forces the companion app to run attacker-controlled code	Fuzzes file parsing and reviews how web requests influence which files are opened
Drive-by and worm potential	Chains a download and a web visit into self-propagating compromise	Assesses required permissions and whether a single compromise can reach further victims

How To Run Browser Extension And Companion App Penetration Testing

A penetration test scoped only to a web application will confirm that the web tier is sound and reveal nothing about the browser extension, the companion app, or the bridge between them. The Belgian eID flaws lived precisely in that gap. Effective browser extension penetration testing therefore has to include the extension, the native messaging host or local service, the companion application, and the trust decisions made at each step.

In practice this means a tester enumerates the local components, maps how a web page can reach them, and then behaves like an attacker who owns an arbitrary website. The tester attempts cross-origin calls, checks whether security prompts reveal their origin, traces every secret to confirm none returns to the caller, and probes file handling for code execution. The most valuable findings come from chaining these steps the way an attacker would, then reproducing each step so the client can see how a small gap becomes a real attack. CredShields runs this work as named, human-led engagements in which every finding is reproduced and verified, and the report carries an accountable assessor rather than an anonymous tool output. The full technical write-up from the eID research shows the kind of chained proof this approach produces.

Choosing that assessor is its own decision, and the questions worth asking a prospective firm are covered in our guide to what to know before choosing a penetration testing vendor.

Related read: SOC 2 Penetration Testing: What You Should Expect Before an Audit, for how independent testing fits a compliance program.

Secure Design Principles For Browser Extension And Native Messaging Software

Teams that build or buy browser extensions and companion software can prevent this entire class of flaw with a short set of design rules. The principles below map directly to what went wrong in the Belgian eID case.

Principle	What it prevents
Verify the origin of every request	Stops any website from reaching the browser extension or helper
Pin the exact callers the native messaging host will serve	Removes the attacker’s page from the list of trusted origins
Always display the requesting domain in security prompts	Stops a page from impersonating a trusted party
Never return a secret to the caller	Keeps a PIN, token, or key inside the local trust boundary
Sandbox and validate all file handling	Closes the path from a downloaded file to code execution
Run the companion app at least privilege	Limits the damage if the helper is abused
Sign and verify updates, and protect logs centrally	Preserves integrity and a usable record of events

Stating these rules is easy, and evidencing them is what an assessment rewards. A team that can show origin validation in code, prompts that always display the domain, and a data flow proving secrets never leave the local boundary has answered most of a reviewer’s questions before they are asked.

What Security Leaders Can Do About Browser Extension Security Now

You can treat this disclosure as a prompt to check your own environment, whether or not you use eID software. Unlike a scheduled audit, there is no fixed date forcing the issue, which is exactly why it helps to phase the work rather than treat it as one long list.

This week: find out what you have. Inventory every browser extension and companion application your organization installs, and note which local resources or hardware each one can reach. You cannot assess a risk you have not listed.
This month: check the controls that matter most. For each item in the inventory, confirm it validates the origin of callers and does not answer to arbitrary websites. Check that any security prompt these tools display shows the true requesting domain and cannot be dressed up by a web page. Trace how secrets such as PINs, tokens, and keys move through these tools, and confirm none are returned to a calling page.
Ongoing: extend the check past your own software. List the external identity providers your systems trust, and make sure a forged or stolen identity signal would be detected downstream. Scope your next penetration test to include browser extensions, companion apps, and trust boundaries, and ask that findings be reproduced and verified by a named assessor.

Running these checks tells you whether a failure in something your users trust would stay contained or spread the way the eID flaw did in Belgium. For teams in banking and financial services, where eID and signing flows are common, CredShields fintech security testing covers these trust boundaries directly.

Frequently Asked Questions About Browser Extension Security

The questions below cover what teams most often ask after reading about the Belgian eID flaws.

Q1. What is browser extension security?

Browser extension security is the practice of securing an extension and any companion application it talks to, so that the pair cannot be abused by a malicious website. The central risks are that the extension trusts the wrong caller, hides the origin of its prompts, or leaks secrets back to a web page, which is exactly the pattern the Belgian eID flaws followed.

Q2. What is native messaging, and why is it a security risk?

Native messaging is the channel a browser extension uses to talk to a locally installed application, such as one that drives a smart card reader. It becomes a risk when the native messaging host does not pin the exact callers it will accept, because a malicious website can then reach a powerful local application, as the Belgian eID case and the Pega Browser Extension case both showed.

Q3. Can automated scanners find browser extension flaws like these?

Automated scanners rarely catch these flaws, because origin validation, prompt design, and secret handling are questions about intended behavior rather than known vulnerable patterns. Manual, human-led browser extension penetration testing is the method built to reason about trust boundaries and to chain small gaps into a full attack.

Q4. Were CSAM.be and Itsme vulnerable themselves?

The disclosure attributes no flaws to CSAM.be or Itsme. Their exposure came from trusting eID signatures, so an attacker who could forge a signature could act against them without exploiting any weakness in their own systems.

Q5. How do you test a browser extension and its companion app together?

You scope the test to include the extension, the native messaging host or local service, the companion application, and the channel between them, then behave like an attacker who controls an arbitrary website. The tester attempts cross-origin calls, checks whether prompts show their origin, confirms secrets never return to the caller, and probes file handling for code execution.

Q6. What is the single most important control for browser extension security?

Origin validation is the foundational control, because an extension or helper that cannot tell a legitimate caller from an attacker undermines every other protection it has. Displaying the requesting domain in security prompts and never returning secrets to the caller are the next two.

Q7. How long did it take to fix the Belgian eID flaws?

Nitro remediated the issues 146 days after the initial report, with final security enforcement completed in late July, and awarded the researcher a $200 bug bounty. Coordinated disclosure timelines vary by vendor and complexity, so this case is best read as a data point on how long trust boundary fixes can take across a large, regulated user base, not a universal benchmark.