Edge Keeps Every Saved Password in Cleartext RAM — Even Idle Ones

What happened

Security researcher @L1v1ng0ffTh3L4N published findings showing that Microsoft Edge stores all saved passwords in cleartext in process memory — not just the credentials for the site you're currently visiting, but every password in your vault. The discovery, which racked up a score of 506 on Hacker News, was demonstrated by dumping the Edge browser process memory and searching for known credential strings. The passwords were sitting there, unencrypted, readable by any tool that can inspect process memory.

This isn't a buffer overflow or a crafted exploit. There's no CVE because, from Chromium's perspective, this is working as designed. The browser decrypts credentials from its on-disk database (protected by Windows DPAPI) and loads them into process memory for use. The problem is scope and duration: Edge appears to decrypt and retain credentials that aren't actively needed, keeping them resident in memory well beyond any reasonable use window.

The finding was reproducible using standard memory inspection tools — Process Hacker, simple memory dump utilities, or even a debugger attach. No elevated privileges required. If you can run a process as the same user who owns the Edge session, you can read the passwords.

Why it matters

Browser password managers have become the de facto credential store for hundreds of millions of users. Microsoft actively promotes Edge's built-in password manager as a secure alternative to third-party tools, integrating it with Microsoft accounts and syncing credentials across devices. The implicit promise is that your passwords are encrypted at rest and protected in transit — but "at rest" apparently doesn't include "sitting in RAM doing nothing."

The security model most users assume goes something like this: passwords are encrypted on disk, decrypted only when needed (autofill or manual copy), used briefly, then scrubbed from memory. What's actually happening is closer to: passwords are encrypted on disk, bulk-decrypted into process memory at some point during the browser session, and left there until the process exits. The distinction matters enormously.

Any malware operating at user privilege level — no admin rights, no kernel exploit, no UAC bypass — can read every saved password by dumping Edge's process memory. This is a bread-and-butter technique for infostealers. Tools like Mimikatz, RedLine Stealer, and Raccoon have been scraping browser memory for credentials for years. The finding confirms that Edge makes this trivially productive: you don't need to catch the user logging into a specific site, you just dump memory at any point and harvest everything.

The Hacker News discussion surfaced several important threads. Multiple commenters noted that this isn't unique to Edge — Chrome and other Chromium-based browsers have similar behavior, with CyberArk documenting Chrome's plaintext memory storage in 2023. However, Edge's implementation appears to be more aggressive about pre-loading credentials, expanding the window of exposure. Others pointed out that Google's position has historically been that if an attacker has user-level access to your machine, the browser's threat model is already broken — a stance that's technically defensible but practically unsatisfying when browsers are actively marketing their password managers as secure credential stores.

The counterargument deserves a fair hearing: once an attacker has arbitrary code execution at your user level, they can keylog, screen-capture, hook browser APIs, and install extensions. The cleartext memory issue is one attack vector among many at that privilege level — but it's the one that scales, because it gives the attacker every credential at once rather than waiting to capture them one by one. That's the difference between stealing a key and stealing the entire keyring.

What this means for your stack

If your organization relies on browser-native password managers — and statistically, many of your developers do, even if official policy says otherwise — this finding should inform your endpoint security posture.

For individual developers: Consider whether a dedicated password manager (1Password, Bitwarden, KeePassXC) offers meaningful improvement here. Most dedicated managers are more careful about memory hygiene: they encrypt entries in memory, use guard pages, scrub buffers after use, and minimize the window where plaintext exists. They're not invulnerable to memory inspection attacks, but they make the attacker's job measurably harder than "run strings on a memory dump." If you're storing credentials for production infrastructure, CI/CD pipelines, or cloud consoles in Edge's password manager, this is your cue to move them.

For security teams: This finding reinforces that browser process memory is a high-value target for endpoint detection. Memory scanning rules that flag credential-pattern strings in browser process dumps can catch infostealers in the act. If you're running EDR with memory scanning capabilities, ensure your rules cover Chromium-family process memory. Also consider application-level isolation: running browsers in sandboxed environments (VMs, containers, or Windows Sandbox for sensitive sessions) limits what a memory dump at the host level can capture.

For engineering leads: Audit your team's credential hygiene. The developer who stores the production database password in Edge's autofill is a single infostealer away from an incident. Hardware security keys, short-lived tokens, and zero-standing-privilege architectures aren't just compliance checkboxes — they're the controls that remain effective when the password layer is this porous.

It's worth noting what won't help: clearing browsing data doesn't necessarily scrub process memory. Locking your computer doesn't terminate the browser process. Even disabling the password manager going forward doesn't retroactively wipe credentials already loaded into memory from a previous session. The only reliable way to clear the memory is to fully quit and restart the browser.

Looking ahead

Microsoft hasn't publicly acknowledged this specific finding as a vulnerability, and given Chromium's longstanding position on user-level attackers, a patch isn't guaranteed. The more likely trajectory is that this becomes another data point in the slow migration away from browser-native password managers toward dedicated credential management — a migration that security teams have been advocating for years but that convenience has consistently defeated. The 506-point Hacker News score suggests the developer community is paying attention. Whether that attention converts to changed behavior is, as always, the open question.