Microsoft Edge Loads All Saved Passwords into Cleartext Memory at Launch — Won’t Fix

A security researcher has disclosed that Microsoft Edge — Microsoft's Chromium-based browser — decrypts every password stored in its built-in password manager into plaintext process memory the moment the browser launches, and retains those cleartext credentials in memory for the duration of the session. The behavior persists regardless of whether the user ever visits the sites those credentials belong to. Disclosed on April 29, 2026, by researcher @L1v1ng0ffTh3L4N, the finding prompted a response from Microsoft that the behavior is "by design." No fix is planned.

How the Vulnerability Works

Microsoft Edge's password manager, like those of other Chromium-based browsers, stores saved passwords encrypted on disk using Windows DPAPI (Data Protection API — a Windows operating system facility that ties encryption keys to the logged-in user account, so that stored secrets can only be decrypted by that user on that machine). This on-disk encryption is the correct and expected baseline.

The problem is what happens at browser startup. According to CyberSecurityNews' analysis and GBHackers' coverage of the disclosure, Edge immediately decrypts the entire password vault into the browser process's memory as part of its initialization sequence — before any web page has loaded and before any autofill is needed. The cleartext passwords then remain in memory for the entire browser session, resident in the msedge.exe process address space.

What this means in practice: any process on the same Windows machine with sufficient privilege to read another process's memory can extract every password saved in Edge. The mechanisms available include:

• ReadProcessMemory() (a Windows API call — a system function that reads the memory of another process) used by any process running as the same user or as an administrator
• Memory dump tools like procdump or WinPMEM that write the entire process address space to disk
• Malware using LSASS-style (Local Security Authority Subsystem Service — the Windows process responsible for authentication) memory reading techniques applied to msedge.exe
• Post-exploitation tooling in pen testing frameworks (Metasploit, Cobalt Strike, Sliver) that target browser credential stores

The researcher tested every major Chromium-based browser and found that Edge is the only browser exhibiting this behavior. Google Chrome, Brave, Opera, and Vivaldi all implement on-demand decryption: credentials are decrypted only at the moment they are needed during autofill or when a user explicitly views a saved password in the browser's settings. Chrome additionally applies App-Bound Encryption (a security feature that cryptographically ties the browser's decryption capability to an authenticated Chrome process, preventing other processes from performing the same decryption even with the user's credentials) — a hardening measure that Edge lacks.

Microsoft's Response

When the researcher reported the finding through responsible disclosure, Microsoft's official response was that the behavior is "by design."

This response is technically defensible in a narrow sense: DPAPI protects the on-disk store from extraction when the machine is powered off or when accessing another user's account. If an attacker has already achieved code execution under the target user's account on a running machine, DPAPI-based protections do not prevent memory reading — that is a known limitation of DPAPI's threat model.

However, Microsoft's decision not to implement on-demand decryption (which Chrome has done) or App-Bound Encryption (which Chrome added as a hardening measure specifically because memory-reading attacks against browser credential stores are a real, documented threat) means that Edge provides meaningfully weaker credential security than its primary Chromium-based competitor.

The disclosure included a small verification tool that any user can run to confirm whether their Edge browser instance is currently holding cleartext credentials in process memory. The Hacker News thread on the disclosure generated substantial discussion from security professionals confirming the finding across multiple Windows versions.

The Terminal Server and RDP Scenario

The highest-risk scenario for this behavior is multi-user systems: Windows terminal servers, Remote Desktop (RDP — a protocol for accessing a Windows desktop remotely over a network) environments, and Citrix deployments where multiple users maintain simultaneous sessions.

If an attacker has compromised a user account with local administrative rights on a terminal server, they can use ReadProcessMemory() against every other user's running msedge.exe process — including users who are disconnected (sessions that are not actively displayed but remain running in the background with all processes still active). This means that a single lateral movement step to a terminal server, where dozens of employees have Edge open in their sessions, yields every password from every user's Edge vault in a single memory-reading operation.

This scenario is not hypothetical. The researcher included a video demonstration showing an attacker with administrative rights on a terminal server extracting stored credentials for two other logged-in (including a disconnected) users whose Edge sessions were running. The scale of credential exposure in an enterprise where Edge is the standard browser and terminal servers or Citrix are in use is significant.

Comparison: Chrome vs. Edge Credential Security

| Security Control | Chrome | Microsoft Edge | |—|—|—| | On-disk encryption | DPAPI + App-Bound | DPAPI only | | Memory decryption timing | On-demand (autofill only) | All credentials at startup | | App-Bound Encryption | Yes (added 2024) | No | | Cleartext credentials in process memory | No (after App-Bound) | Yes (always) | | Multi-user session risk | Lower | Higher |

Who Is Affected

All users with saved passwords in Microsoft Edge on Windows are affected. The practical risk level depends on the environment:

• High risk: Enterprise terminal server and RDP environments with multiple users, shared workstations, any environment where local admin access could be obtained by an attacker
• Medium risk: Standard enterprise workstations where malware deployment is a realistic threat (phishing, drive-by, USB), post-exploitation credential harvesting
• Lower risk: Personal single-user devices with full-disk encryption and no admin-accessible second account

The risk is not a remote, unauthenticated attack against Edge directly. It requires either local code execution (malware) or local admin-level access. But both of these conditions are exactly what occur in typical enterprise intrusion scenarios following initial compromise.

What You Should Do Right Now

• Migrate saved passwords out of Edge to a dedicated password manager. Use Bitwarden, 1Password, or KeePassXC — these store credentials in their own encrypted vaults with separate access controls and do not expose all passwords in process memory at startup.
• Disable the Edge built-in password manager for corporate environments. Deploy via Group Policy: Computer Configuration → Policies → Administrative Templates → Microsoft Edge → Password Manager → set "Enable saving passwords to the Password Manager" to Disabled.
• Evaluate alternatives for enterprise browser deployment. If credential security in a multi-user or RDP/Citrix environment is a concern, Google Chrome with App-Bound Encryption enabled provides stronger in-memory credential protection.
• On terminal servers and Citrix, enforce browser logout before session disconnect. Preventing long-running disconnected Edge sessions limits the window during which cleartext passwords persist in memory.
• Monitor for suspicious ReadProcessMemory calls against msedge.exe. EDR platforms can detect anomalous process memory access. Configure alerts for non-Microsoft processes accessing Edge's memory space.
• Migrate from browser-stored passwords to hardware-backed authentication where possible. FIDO2 passkeys, stored in hardware security keys or platform authenticators (Windows Hello, Apple Secure Enclave), are not susceptible to memory-reading attacks and eliminate the password storage problem entirely.

Background: Understanding the Risk

Browser credential theft is one of the most productive post-exploitation techniques in modern intrusion campaigns. Groups from nation-state actors (Cozy Bear/APT29 routinely targets browser credential stores) to commodity ransomware operators (many ransomware groups include credential harvesting phases before encryption) use browser memory reading or DPAPI-based credential extraction as a standard step in their playbooks. The reason is simple: users store high-value credentials in browsers — banking, SaaS applications, corporate SSO portals — and extracting them from process memory is significantly easier than keylogging or phishing each credential individually.

Microsoft's "by design" response reflects a tension between backward compatibility and security. Loading the entire credential vault at startup may improve autofill performance or startup reliability in some configurations. But Chrome's implementation demonstrates that on-demand decryption is achievable in a Chromium codebase without sacrificing user experience — Google made this change precisely because in-memory credential exposure was being actively exploited.

The App-Bound Encryption addition to Chrome in 2024 was a direct response to infostealers (malware specifically designed to harvest credentials, cookies, and other sensitive data from browsers) that bypassed DPAPI by running as the same user as the browser. Edge's absence of this protection means that the entire ecosystem of infostealer tooling that targets "Chromium" browsers will successfully extract Edge credentials from memory.

Conclusion

Microsoft Edge decrypts all saved passwords into process memory at browser launch and retains them there for the entire session. Microsoft has confirmed this is intentional and no patch is planned. Chrome does not share this behavior, having implemented both on-demand decryption and App-Bound Encryption. The immediate and most practical remediation is to stop using Edge's built-in password manager and migrate credentials to a dedicated password manager application that applies stronger in-memory protections. Disable the Edge password manager via Group Policy in any enterprise environment, and prioritize this change on terminal servers and RDP deployments where the multi-user credential exposure risk is greatest.