In tests, N-able Passportal 3.49.5 handed authentication tokens to any website or iframe shown to a signed-in user. Am I Being Pwned researcher James Arnott demonstrated that the page could then retrieve decrypted passwords and live two-factor codes from the user’s vault. N-able fixed the leak in 3.49.6 within 24 hours of receiving the detailed report.
The flaw is CVE-2026-15580. It required a user to visit attacker-controlled content while the extension was active. Arnott reported no known exploitation, and CISA’s entry in the NVD record marks exploitation as none. The researcher’s 9.4 severity score differs from N-able’s 6.9 Medium CNA score, which records active user interaction, high confidentiality impact, and no integrity or availability impact.
Any page could request tokens
Passportal used a content script to communicate with an extension iframe through window.postMessage. That browser API is designed for communication across window and frame boundaries, but the receiving handler trusted messages without checking the sender’s origin. Arnott summarized the discovery plainly: “Any page could simply run this line” and listen for the token response.
The iframe needed token material because Passportal’s server performed password decryption. The content script passed access and refresh tokens into the extension page, and the JWT access token also carried key material used in password and TOTP requests. A web page could send the same getPasswords method name and receive the response intended for the extension iframe.
The page still needed a signed-in user and an opportunity to run JavaScript in a site or embedded iframe that the user loaded. The report did not establish that every website could read an inactive vault, that attackers exploited the issue, or that any customer lost credentials.
Tokens unlocked the full vault
The demonstrated response crossed a consequential boundary. With the returned token material, the researchers enumerated active password entries, requested individual entries with server-side decryption, and obtained live TOTP codes. The refresh token could preserve that access for as long as 100 days. That duration is a demonstrated token limit, rather than observed attacker dwell time.
Figure details
The upper lane shows versions before 3.49.6: an untrusted web page sends a getPasswords postMessage request, the Passportal content script accepts it without an origin check, and token material crosses into the page. Those tokens can then be used with the Passportal vault API to request decrypted passwords and live TOTP codes. The lower lane shows version 3.49.6 and later: the content script checks the extension origin, confirms that the sender is a registered trusted frame, and validates a nonce before dispatching a sensitive method. A request from an ordinary page fails those checks and does not receive vault tokens. The figure describes the demonstrated trust-boundary change; the sources report no observed exploitation.
Arnott’s team nearly set the finding aside because it could not verify the behavior without an account. N-able supplied one, allowing the researchers to reproduce the vault access. The company then added three controls to the message handler: the sender had to use the extension’s origin, match a registered trusted frame, and supply the expected nonce before a sensitive method could run.
The researchers say that patch “fully fixed the token leaking issue.” They separately recommended replacing the page-visible messaging design with browser extension messaging and moving decryption to the client. N-able told them the architecture recommendation had been forwarded for review. That longer-term concern does not change the fixed-version boundary for CVE-2026-15580.
Version 3.49.6 closes the channel
N-able’s CNA record identifies every Passportal browser extension version before 3.49.6 as affected. Version 3.49.6 is the first fixed build, and every later build supersedes it.
That version is the remediation boundary.
The researchers counted more than 73,000 weekly active extension users at disclosure. The source did not quantify how many were signed in while visiting untrusted content.
Extension inventory needs product-specific identifiers because a display name can change. Chrome deployments use nakcddgmfmjmdbfahkkiijejmmfkfipc; the Microsoft Edge listing uses cnepdmlonnfpdpkkglplkpcgdpjkobkc. Managed-browser reporting should return an installed version for each present identifier and show 3.49.6 or later.
Verify versions and scope exposure
Export Chrome and Edge extension inventory from the management system that enforces browser policy. Find both Passportal identifiers, record every installed version, and remediate any result below 3.49.6. Confirm that unmanaged browser profiles and devices are included. Later builds supersede the first fixed version; the acceptance boundary remains 3.49.6 or later.
A current version proves that the vulnerable handler is gone. It does not reconstruct earlier page-to-extension messages. For users who had 3.49.5 or earlier, preserve browser history, extension update state, secure web gateway records, and available Passportal audit exports for the period before the fixed build arrived. Prioritize untrusted advertising, injected third-party frames, and suspicious sites viewed while Passportal was signed in. The public sources do not name an audit event that conclusively records the historical postMessage request, so a clean current inventory cannot clear past exposure by itself.
Rotate privileged passwords, TOTP seeds, and durable sessions when the affected user’s browsing history or extension-update time cannot bound exposure. Start with credentials that grant administrative, remote-management, cloud, directory, and backup access. Then verify that previous passwords and sessions fail, and that codes generated from each previous TOTP seed are rejected.
Run the final check from managed inventory, rather than a single workstation. The expected result is that every reported Chrome or Edge Passportal instance is 3.49.6 or later, unmanaged installations are either brought under policy or removed, and each account selected for rotation rejects its previous password, codes generated from its previous TOTP seed, and its previous session. That result closes the vulnerable message channel and proves the chosen credentials no longer depend on potentially exposed token material.