TL;DR. Signer Digital forwards any postMessage to its native host with no origin check. The host glues your input onto C:\Windows\System32\ and LoadLibrary s the result, so a ..\..\ traversal loads any file on disk and runs its DllMain - code execution from a web page. (Its error messages also leak a file-existence oracle, which we used to find the victim's Downloads path.) Affected: extension glghokcicpikglmflbbelbgeafpijkkf v5.1.2 / native host v5.1.1.0; fixed in host v6.0.0.0 (with extension v5.2.0) on 26 June 2026 - but the host update is the one that counts. CVSS 9.3 3 | CVE pending. Intro Signer.Digital is a digital-signing browser extension by Chartered Information Systems (CISPL), used across India for government portals, GST and income tax filings, and internet-banking - over 3 million users 1 , on a published client list that includes banks, healthcare, government, NVIDIA, Amazon and Cisco 2 . It pairs a Chrome extension with a native Windows helper that talks to your signing hardware. Until we reported it, any web page you visited could use that helper to run code on your machine. Its own security page sells the product on "Unmatched Security" from "an ISO 27001 Certified Development Center". This isn't a theoretical RCE, a drive-by page ran an attacker-controlled DLL on your PC with no clicks, and from there a single UAC click - the kind people approve for routine updates - walked it up to administrator. We did not look for evidence anyone exploited it in the wild before the fix There's a patch now, but don't count on it reaching you: it lives in the native host, not the auto-updating extension, and the host's own updater is a dead channel (more below). If you have Signer.Digital installed, assume the auto-update hasn't saved you; the only sure fix is reinstalling the host by hand. The Exploit The extension's content script listens for messages from the page and forwards them straight to the native host. The "authentication" is one hardcoded string, src: "user_page.js" : window.addEventListener( "message", function (event) { if (event.source !== window) return; if (event.data.src && event.data.src === "user_page.js") { chrome.runtime.sendMessage(event.data, function (resp) {}); } }, false, ); No origin check and no allow-list of which actions a page is allowed to call. The content script is injected on every site you visit, so any frame, on any origin, can hand any command to the native host - including the high-risk ones like GetSCDetailsAndCerts , GenCSR and ImportCER . It's the same trust-the-page mistake we found in Urban VPN and MultiPassword , only here the sink isn't a VPN command or your saved passwords, it's LoadLibrary . The licensing checks Signer.Digital does have all run in the page world, so an attacker page just skips them and builds the message itself. So a web page sends this: window.postMessage( { src: "user_page.js", // the only "password" action: "GetSCDetailsAndCerts", PKCS11Lib: "..\\..\\Users\\<USER>\\Downloads\\reminder.pdf", nonce: "abcd...", origin: location.origin, browser: "chrome", }, "*", ); And on the other side, the native host does this (reconstructed from the .NET IL): public TxnResp GetSCDetailsAndCerts(string PKCS11Lib) { var resp = new TxnResp { IsSuccess = true }; string path = "C:\\Windows\\System32\\" + PKCS11Lib; // <- unsanitised concat if (!File.Exists(path)) { resp.IsSuccess = false; resp.TxnOutcome = "Required Smartcard driver " + path + " not found..."; return resp; } var lib = Factories.Pkcs11LibraryFactory .LoadPkcs11Library(Factories, path, AppType.MultiThreaded); // <- LoadLibrary // ... } String.Concat is the entire defence. A leading ..\..\ escapes System32\ and points LoadPkcs11Library (which calls Win32 LoadLibrary via Pkcs11Interop) at any file the user can read. And the loader runs a DLL's DllMain as part of loading it, before Pkcs11Interop ever calls C_GetFunctionList and long before the host checks whether the file is a real smartcard driver. The code runs whether or not the file is a real driver. It just has to be a DLL. Page to native code execution, with nothing in between checking who's asking Getting Your DLL onto the Disk Path traversal lets the host load a file. You still need a file to load, at a path you can predict. That's one download. The attacker serves the stage-1 DLL named reminder.pdf and typed as application/pdf . LoadLibrary ignores the extension, but Chrome doesn't: a .dll or .exe download trips its dangerous-file warning, while a .pdf sails through. Chrome drops it in %USERPROFILE%\Downloads , and the first programmatic download per navigation lands without a click; a download chip shows in the toolbar, but the victim never has to approve it. (You can go further and build a true PE/PDF polyglot that also renders as a real document, so it stays innocuous if the victim opens it; for the load itself the rename is enough, and that's what we tested.) Now you need the username to build ..\..\Users\<USER>\Downloads\reminder.p...