Any Website Could Ask Passportal for the Tokens to the Vault. The Patch Stops the Leak, Not the Architecture.

The vulnerable extension did not require the attacker to compromise N-able, the managed service provider or the user’s device first. A page, advertisement or embedded iframe only needed to send a message that the extension trusted.

N-able fixed that token leak within 24 hours of receiving a confirmed report. The speed of the response deserves credit.

The deeper question remains: why did a browser token contain material that could unlock an entire vault through server-side decryption?

The extension trusted messages from any origin

Bay Area Labs researcher James Arnott disclosed the Passportal flaw on 20 August 2026 after coordinating with N-able in July.

Passportal uses a browser extension to suggest and retrieve stored credentials. Communication between a web page, an extension content script and the extension’s own interface relied on window.postMessage.

The vulnerable message handler checked that a message had a source, but it did not verify the origin of that source before dispatching the requested method. According to the research, any page could send a request for passwords and listen for the extension’s response.

The response included access and refresh tokens used by Passportal. Version 3.49.5 was affected. N-able released version 3.49.6 with origin, frame and nonce checks designed to restrict sensitive messages to trusted extension components.

The patch closes the demonstrated cross-origin route. It does not mean every organisation can assume that every installed browser updated immediately or that no token was exposed before the fix.

The token was more valuable than one password

The leaked access token was not limited to credentials for the website the user was visiting. The researcher demonstrated that it could be used to list vault entries, request decrypted passwords and obtain time-based one-time password codes.

The refresh token extended the value of that access. Bay Area Labs says the maximum refresh-token lifetime was 100 days, allowing an attacker holding a stolen token to request new access tokens after shorter-lived ones expired.

That turns one browser interaction into potential persistent access to the credential system. The researcher described full create, read, update and delete capability over the vault, not a one-time autofill leak.

No public evidence currently shows that attackers exploited this flaw against Passportal customers. The distinction matters. This is a demonstrated vulnerability with severe potential impact, not a confirmed mass breach.

Server-side decryption made the browser leak decisive

Many password managers are designed so that the service stores encrypted vault data but does not receive the secret needed to decrypt it. Decryption happens on the user’s device. A server breach or stolen service session should not automatically reveal every plaintext password.

The Passportal flow described by Bay Area Labs is different. The client sends an access token containing encoded organisation-key and phrase fields to the service. The service then returns decrypted passwords and one-time codes.

A JSON Web Token protects integrity through its signature. It does not normally conceal its claims. Putting sensitive key material inside a signed token does not encrypt that material from anyone who obtains the token.

The browser-extension bug and the vault architecture therefore amplified one another:

• The extension disclosed the tokens to an untrusted web origin.
• The access token carried material used in the server-side decryption path.
• The API allowed the holder to enumerate and retrieve credentials across the vault.
• The refresh token could preserve access for up to 100 days.

N-able told Dark Reading that it is committed to Passportal’s ongoing security and is evaluating further hardening. The public response did not announce a move to end-to-end encryption or client-side-only decryption.

An MSP vault is a downstream access map

Passportal is designed for managed service providers and IT service teams. Those organisations often store privileged credentials for many separate customers, including domain administrators, cloud tenants, network devices, backup systems and remote-management tools.

A compromise of one technician’s vault can therefore cross organisational boundaries. The immediate victim may be the MSP account, while the useful targets are the customer environments represented by the stored credentials.

Passportal also supports a branded password-management service that providers can deliver to customers. The researchers did not test every downstream deployment model, so it would be wrong to assume that every nested customer was exposed in the same way. The concentration risk is still clear: credential-management platforms aggregate the keys to otherwise separate systems.

What Passportal customers should verify

Organisations should not treat an automatically updating extension as an automatically verified control.

• Inventory Passportal extensions across managed Chrome and Edge profiles and confirm that no installation remains on version 3.49.5 or another earlier vulnerable build.
• Ask N-able whether all access and refresh tokens issued to vulnerable extension versions were invalidated. If they were not, revoke sessions through the supported administrative process.
• Review Passportal audit records for unusual vault enumeration, credential reads, exports, changes or access from unfamiliar infrastructure.
• Correlate Passportal activity with web-proxy, DNS, endpoint and browser telemetry around the period in which vulnerable versions were installed.
• Identify the most privileged credentials and one-time-password seeds held in affected vaults. Rotate them from clean systems if evidence suggests token theft or if the exposure cannot be bounded.
• Review whether a single technician account can reach more customer vaults than operationally necessary, and reduce that scope.
• Require extension version reporting and minimum-version enforcement through managed browser policies.

Organisations should also ask architectural questions during password-manager procurement. Where does decryption occur? Can the provider decrypt a vault? What does a session token contain? Can a stolen refresh token be revoked centrally? Which audit events reveal bulk credential access?

The patch fixed the message. Trust still depends on the design.

N-able’s response to the report was fast. Bay Area Labs says it received a test account on 8 July, reported the confirmed vulnerability that day and saw patched Chrome and Edge extensions on 9 July.

Fast remediation substantially reduced the opportunity for abuse. It should not erase the lesson.

A password vault is valuable because it concentrates trust. The same concentration makes a browser token, decryption service or overly broad technician account a possible route to many downstream systems at once.

The extension now checks who is asking. Customers still need assurance about what the answer can unlock.

Sources and further reading

• Bay Area Labs: Solar Winds Part 2 Avoided: N-Able Passportal Vault Leak, published 20 August 2026
• Dark Reading: N-able Bug Exposes Password Vault Master Keys, published 20 August 2026
• N-able Passportal documentation: data encryption and organisation-key architecture
• N-able Passportal extension for Google Chrome