An April 29 disclosure published by security researcher Tom Jøran Sønstebyseter Rønning (@L1v1ng0ffTh3L4N) has been making the rounds. Having systematically tested every major Chromium-based browser for how they handle credentials in memory, the researcher found that Edge was the only one loading the entire password vault into plaintext process memory at startup, where it remains for the duration of the session.
That means every saved credential—for every site, whether you plan to visit it or not—is sitting in memory from the moment Edge opens.
When the researcher reported this to Microsoft, the company’s official response was that the behavior is “by design.” That response is worth sitting with. It tells you something important: This is beyond a bug waiting for a patch. It’s exposing an architectural decision, and understanding why it matters requires looking past the headline.
Microsoft Edge plaintext passwords vulnerability explained
The typical defense of browser password managers goes something like this: Passwords are encrypted on disk, tied to your user account, and protected by the operating system. All of that is true.
But encryption at rest only protects data while it’s sitting still. Browsers are storing passwords so they can be used rather than for safekeeping. And passwords have to be decrypted before they can be used.
The question is what happens after that decryption step, and for how long.
Chrome decrypts passwords strictly on demand, one at a time, only when autofill fires or when a user explicitly opens the password manager. Chrome also protects its decryption keys using App-Bound Encryption, which ties those keys to the Chrome process itself.
Even if another program on the same machine tries to grab them, it gets nothing useful back. App-Bound Encryption was added in Chrome 127 in 2024 in response to the growth of infostealer malware. As those attacks became more common, and better understood, Chrome updated its architecture to make credential theft more difficult.
Firefox sits somewhere in the middle of this picture. Unlike Edge, it doesn’t load the entire password vault into memory at launch. But it’s not immune to the same class of attack.
Academic research published in 2024 assessed two dozen password managers, including browser-based plugins, and found that the majority stored plaintext passwords in system memory across multiple test scenarios. Firefox was among those affected under certain conditions, and the research found that once notified, most vendors chose to treat the behavior as by design rather than a vulnerability—the same position Microsoft is now taking with Edge.
The distinction between browsers isn’t whether credentials end up in memory at some point. It’s how much of the vault is exposed, for how long, and how aggressively the keys are protected. Edge currently sits at one end of that spectrum.
Edge offers none of the protections seen in Chrome. From launch, all saved credentials are loaded into the browser’s process memory in plaintext, with no on-demand decryption or key binding. Most notably, Edge continues to require authentication before revealing passwords in its UI, even though those credentials are already accessible in memory prior to that step.
The authentication prompt is theater. The credentials are already there.
How the attack path works
This is where the real conversation starts. The disclosure included a working proof-of- concept tool, and the attack it demonstrates doesn’t rely on zero-days or complex exploitation. It relies on the ability to read process memory, something any process running in a user context can do.
The path looks like this: An attacker gets code execution on a machine. Maybe through phishing, a malicious download, or abuse of a legitimate remote management tool. That code runs in the same session as Edge. It reads process memory. Credentials come out in plaintext. No cryptography is broken. Nothing unusual happens from the browser’s perspective. The attacker is simply reading data that was already decrypted and waiting.
This isn’t a theoretical scenario. A category of malware called infostealers is doing exactly this at scale. In the first half of 2025 alone, 1.8 billion credentials were stolen this way globally. These tools can be rented through underground forums for around $200 a month, require no technical background to operate, and are already built to harvest credentials out of browser memory.
Edge, which keeps every saved password decrypted in memory from the moment it opens, is an easier target in this scenario than Chrome.
Why plaintext credentials pose a threat to enterprise environments
Most security discussions about memory-based credential theft focus on the individual user. But there’s a second scenario that deserves more attention, and it’s the one most relevant to IT and security teams managing real enterprise environments.
In a terminal server environment, if an attacker gains administrative rights, they can read the memory of every user process currently running on the machine—including users whose sessions are disconnected. A single administrative-level compromise doesn’t yield one user’s credentials. It yields every credential stored in Edge for every user currently running a session on that server.
The proof-of-concept video published alongside this disclosure demonstrates exactly that.
A compromised admin account pulls stored credentials from two other logged-on users simultaneously. This is not a corner case. It directly reflects how attackers move in real enterprise environments: They find a foothold, they escalate privileges, and then they harvest. Browser-stored credentials sitting in plaintext make that harvest trivially easy.
This is particularly worth considering in environments running Remote Desktop Services, VDI, shared admin workstations, or any system where multiple users have active sessions. The blast radius of a single administrative compromise expands significantly when every user on that system is storing credentials in Edge.
Standalone password managers are superior to built-ins
The conversation around this disclosure has been somewhat muddied by arguments along the lines of “if an attacker can read your memory, you’re already compromised.”
That’s technically true, and it’s also somewhat beside the point.
The relevant question isn’t whether memory access represents a compromise. It does. The question is whether the data sitting in memory makes the attacker’s job easier once they have that access.
Edge creates a persistent, wide-surface extraction target for any attacker who can read process memory. Chrome, through on-demand decryption and App-Bound Encryption, shrinks that target. The difference matters in practice.
Browser-integrated password managers are convenient, and they’re generally better than the alternatives most users would fall back on without them. But they also centralize every credential a user has into a single location, decrypt them into a shared memory space, and in Edge’s case, make them available from the moment the browser opens. That’s a meaningful exposure window. Instead of using built-in browser password managers, using dedicated, standalone password managers often offers superior security.
Protect access with Zero Trust controls
The controls that reduce risk here are the ones that focus on execution, not storage. If untrusted code can’t run in a user session in the first place, it can’t read memory.
The most direct mitigation is simple: Stop using Edge’s built-in password manager.
Move credentials to a dedicated standalone password manager instead. Browser-integrated managers are convenient, but as this disclosure makes clear, Edge’s implementation centralizes your entire credential vault into an always-decrypted memory surface. A standalone manager avoids that exposure entirely.
For ThreatLocker customers, a few controls help address this.
The ThreatLocker Community Policy, TL.SC.012 (Block Browser Passwords), uses a Data Storage Access Control policy to block read and write operations to the saved password file directories for Chrome, Edge, Opera, and Firefox, reducing the ability to view or save credentials in those browsers. To audit your environment for this exposure, the relevant DAC check is “Password Prompting Blocked from Edge and/or Chrome.”
Using deny-by-default Allowlisting blocks any unauthorized scripts, code, or applications from executing within a user session, removing the ability to access the browser. Restricting administrative privileges further limits the risk of accessing credentials across user sessions.
The broader takeaway from this disclosure isn’t that Edge is uniquely broken or that all password managers should be abandoned. It’s that security doesn’t end when data is encrypted on disk.
Once credentials are in memory, they’re only as safe as what else is allowed to run alongside them. In environments where endpoints are shared, sessions are active across multiple users, and a single admin-level compromise can cascade into something much larger, that distinction matters.
ABOUT THE AUTHOR
Andrea Pomaranski is a Special Projects IT Engineer at ThreatLocker, working on R&D‑focused technical initiatives across enterprise systems, identity infrastructure, and platform integrations. She studied Computer Science at the University of Florida and began her career in IT before moving into software development, supporting mission‑critical systems in highly regulated production environments. A longtime CTF competitor, Andrea honed her security skills through university, independent study, and past workplaces, including as an active member of UF’s Security and Information Technology (SIT) organization. Outside of work, she maintains a hands‑on homelab where she experiments with hardware and operating systems. She brings a builder’s mindset and a deep interest in how vulnerabilities emerge in real‑world systems to product research and technical investigation.
