Cleartext Passwords in Microsoft Edge Process Memory Prior to and After Canceling Windows Authentication
Empirical evaluation of process memory exposure and UI authentication dialog boundaries in an isolated diagnostic laboratory profile.
Empirical Finding: Yes — a verifiable security hardening deficiency in memory handling and authentication state separation is demonstrated under the tested local threat model with process read access.
In controlled test runs against Microsoft Edge 156.0.4314.58 using an isolated profile with two synthetic test credentials, no cleartext markers were found in process memory after browser startup or during idle states (M02, M03, M06, M07). However, upon interacting with the password manager settings where the operating system displayed the modal prompt “Microsoft Edge is trying to show passwords. Enter your Windows password to allow this”, both synthetic passwords were already present in cleartext (UTF-16LE) inside the main msedge.exe process memory before any password was entered or confirmed (M04, M08). After clicking Cancel (Abbrechen) without authenticating, a subsequent scan (M05) confirmed that both cleartext markers remained at the exact same six virtual memory addresses.
Scope & Test Environment
This investigation evaluates a strictly defined technical question: Are credentials stored in the Microsoft Edge password manager exposed as cleartext in process virtual memory at browser startup, while the Windows authentication prompt for viewing passwords is still unconfirmed, or after that prompt is explicitly canceled by the user?
| Attribute | Documented Test Configuration |
|---|---|
| Application | Microsoft Edge 156.0.4314.58 (64-bit) |
| Executable Path & SHA-256 | C:\Program Files (x86)\Microsoft\Edge\Application\msedge.exeSHA-256: D35D48B11F0439EEEDDBBFF0BF54856E922F5E1506A2F3098B5A808FCEC4068B (valid Microsoft Authenticode signature verified) |
| Operating System | Microsoft Windows 64-bit (OS build recorded as 10.0.26300.0) |
| Isolated Test Profile | Dedicated directory <work-dir>\edge-lab\UserData containing exclusively two synthetic test entries. Local SQLite Login Data verified at rest: two v10 encrypted password blobs (54 bytes each) with zero cleartext markers. |
| Launch Parameters | --user-data-dir=... --no-first-run --no-default-browser-check --disable-sync --new-window about:blank |
Synthetic Test Credentials (RFC 2606 Reserved Domain Context)
To prevent any impact on real services or user data, all testing used intentionally fabricated markers under the reserved .invalid top-level domain:
| Identifier | Origin & Username | Synthetic Password Marker |
|---|---|---|
| Alpha | alpha.example.invalid / edge-lab-alpha |
EdgeLab_A_20261101!73mQ |
| Beta | beta.example.invalid / edge-lab-beta |
EdgeLab_B_20261101!92vR |
Note on Domain Grouping & Marker Transcription: Both entries share the parent domain context example.invalid, which the browser UI may group together. Consequently, these findings do not extrapolate to unrelated domain contexts or an entire multi-site password vault without separate verification. Earlier report versions incorrectly transcribed the exclamation mark (!) as the digit 1; the exact byte markers searched in the measurement runs are the strings containing ! shown above.
Methodology & Experimental Controls
The diagnostic reader enumerates the msedge.exe process tree matched to the isolated --user-data-dir argument and verifies executable paths and creation timestamps prior to reading to rule out PID reuse. It opens target processes using standard Windows APIs with PROCESS_QUERY_INFORMATION and PROCESS_VM_READ access rights, queries committed readable memory regions via VirtualQueryEx, and reads blocks sequentially via ReadProcessMemory. The tool performs zero write operations and zero process injection.
The scanner searches exclusively for exact byte matches of the known Alpha and Beta strings in both UTF-8/ASCII and UTF-16LE encodings, recording virtual hit addresses, hit counts, bytes read, and read errors without exporting raw memory dumps.
Positive & Boundary Controls
A dedicated control process holding both markers (including placement across read-block boundaries) was scanned with the identical routine and passed across all decisive runs (M03–M08).
Negative & Integrity Controls
An unsaved negative control marker returned zero hits in runs M03 through M08. Runs M03 through M08 logged an identical scanner source-code SHA-256 hash.
Empirical Measurement Series (M01–M08)
All measurements were executed sequentially within the isolated laboratory profile on October 31, 2026 UTC (November 1, 2026 in Europe/Zurich, CET / UTC+1). In the table below, A / B denotes the count of virtual memory addresses matching the Alpha and Beta markers respectively.
| Run ID & Window (UTC) | Documented Test State | Main PID / Procs | Virtual Hits (A / B) |
|---|---|---|---|
M0123:12:53–23:12:59 |
Immediately after manual credential entry and saving in profile | 2920 / 9 |
6 / 21 |
M0223:15:52–23:15:58 |
Fresh browser restart (~7.45 s after process start), single blank page | 17508 / 8 |
0 / 0 |
M0323:16:53–23:16:58 |
Idle state prior to password manager interaction (~67.88 s after start) | 17508 / 8 |
0 / 0 |
M0423:21:50–23:21:55 |
Windows Security prompt open, unconfirmed (corresponds to capture S1) |
17508 / 8 |
3 / 3 |
M0523:24:05–23:24:10 |
After clicking “Cancel” on the Windows prompt without authenticating | 17508 / 8 |
3 / 3 |
M0623:24:43–23:24:48 |
New baseline after full restart of the test browser process tree | 26652 / 8 |
0 / 0 |
M0723:30:16–23:30:27 |
Baseline after extension installation prior to password manager interaction | 26652 / 14 |
0 / 0 |
M0823:32:07–23:32:18 |
Second unconfirmed Windows Security prompt open (corresponds to capture S2) |
26652 / 15 |
3 / 3 |
Key Observations on Virtual Memory Persistence
- Exclusive Main-Process UTF-16LE Presence: Every hit in
M04,M05, andM08occurred exclusively in the mainmsedge.exebrowser process inUTF-16LEencoding. - Identical Virtual Addresses Across Prompt & Cancellation: Between
M04(prompt open, unconfirmed; 3,965,030,400 cumulative virtual bytes read) andM05(prompt canceled; 4,132,782,080 cumulative virtual bytes read), all six virtual memory hit addresses (3 Alpha, 3 Beta) were identical. This proves that the cleartext copies resided at those exact virtual addresses at both measurement timestamps. - Reproducibility After Clean Restart: Run
M08(8,133,447,680 cumulative virtual bytes read) reproduced the3 / 3cleartext exposure in a new process instance (PID26652) while the Windows authentication dialog was awaiting input.
Visual Evidence & Authentication State (Capture S2 / M08)
Two screen captures document the unconfirmed Windows authentication state: Capture S1 was recorded during the first test sequence (M04), and Capture S2 was recorded during the second test sequence (M08). Both show the Windows Security dialog requesting the local Windows password, with an empty input field. Capture S2 additionally shows the Edge settings page at edge://settings/autofill/passwords. The user explicitly confirmed that no Windows password or PIN had been entered and the prompt had not been confirmed.
Technical Assessment & Vendor Context
On May 14, 2026, Microsoft Browser Vulnerability Research published “Saved passwords in Edge memory: what we’re changing and why” and released Edge 148.0.3967.70 on May 15, 2026 to stop saved passwords from being loaded into memory at browser startup. Our negative startup and idle measurements (M02, M03, M06, M07) are consistent with that startup change.
However, our measurements M04, M05, and M08 demonstrate that when a user interacts with the password manager UI and triggers the Windows Security prompt, the tested credentials are already exposed as cleartext in process memory before the user enters or confirms the requested Windows password — and remain at the same memory addresses after the dialog is canceled. Consequently, against a process with local memory read access, the visible Windows authentication prompt provides no confidentiality boundary for those cleartext copies.
This pattern aligns with MITRE CWE-316 (Cleartext Storage of Sensitive Information in Memory). While Microsoft’s documented threat model classifies local process access as outside its primary defense boundary, software design best practices (Defense in Depth and Minimizing Cleartext Lifetime) fall primarily within the software vendor’s architectural responsibility: decryption into process memory should be strictly gated on completed authentication, and sensitive buffers should be minimized when an authentication request is canceled.
Methodological Boundaries & What This Evidence Does Not Claim
To ensure strict scientific accuracy and prevent misinterpretation, the following evidentiary boundaries apply to this report:
- No Decompilation or Internal Control-Flow Claims: This study measured empirical byte presence at virtual memory addresses. It did not decompile
msedge.exe, inspect internal C++ object structures, or trace whether specific internal cancel handlers or memory-zeroing APIs (such asSecureZeroMemory) were invoked. - Unseparated UI Sub-Steps & Shared Domain Context: Both synthetic entries resided under
example.invalid. Furthermore, the sub-steps “open password list”, “select domain group”, and “request password reveal” were not measured as isolated atomic transitions. - Minimum OS Privileges Not Enumerated: The diagnostic reader operated with sufficient local process read permissions (
PROCESS_QUERY_INFORMATIONandPROCESS_VM_READ). The minimum required Windows integrity level, token privileges, or cross-account boundaries were not tested. - Scope of At-Rest Inspection: Only the two 54-byte
v10password fields inside the isolated test profile’s SQLite database were verified. No inspection of full-disk sectors, operating system pagefiles (pagefile.sys), or crash dumps was performed. - Live Sequential Scanning & Unreadable Regions:
ReadProcessMemoryperforms a sequential live scan rather than an atomic freeze;978,944bytes (956 KiB) in the main process returned Win32 error299(ERROR_PARTIAL_COPY), and guard/PAGE_NOACCESSpages were skipped. Startup measurementM02began ~7.45 seconds after process launch. - No Remote Exploitation or Cryptographic Bypass: These findings do not demonstrate a remote vulnerability, a cross-site compromise, or a cryptographic bypass of Windows Hello or DPAPI.
Recommendations (Prioritized by Responsibility)
| Priority & Actor | Recommended Action & Technical Objective |
|---|---|
| 1. Primary / Software Vendor (Microsoft) | Couple the decryption of stored password blobs strictly to a successfully completed Windows authentication response rather than pre-staging cleartext prior to confirmation. Ensure cancellation and lock paths minimize the lifetime and scope of cleartext copies in process memory. |
| 2. Independent Verification | Replicate measurements across independent domain contexts and isolated UI steps (list view vs. group view vs. reveal prompt) while logging exact process token integrity levels and retention intervals after cancellation. |
| 3. Secondary Risk Reduction / Users | Maintain current OS/browser patch levels, restrict untrusted local code execution and browser extensions, protect high-value accounts with phishing-resistant multi-factor authentication (FIDO2/WebAuthn), and do not rely on the local UI password prompt as protection against processes already running with local memory-read rights. |
Primary References
- [Q1] Microsoft Browser Vulnerability Research: Saved passwords in Edge memory: what we’re changing and why (May 14, 2026) — microsoftedge.github.io
- [Q2] Microsoft Learn: Microsoft Edge password manager security — learn.microsoft.com
- [Q3] MITRE: CWE-316: Cleartext Storage of Sensitive Information in Memory — cwe.mitre.org
- [Q4] Microsoft Learn: Archived release notes for Microsoft Edge Stable Channel (Version 148.0.3967.70, May 15, 2026) — learn.microsoft.com
- [Q5] Microsoft Learn Win32 API: VirtualQueryEx (link) & ReadProcessMemory (link)
Legal Notice, Safe-Harbor Research Statement & Limitation of Liability
1. Non-Commercial Scientific Research: This publication by Zero Trust Lab (zero-trust-lab.org) documents empirical software behavior observed strictly on a self-owned, isolated local test system using synthetic credentials under the RFC 2606 reserved .invalid top-level domain. No third-party systems or real external user accounts were targeted by the memory investigation, and no external services were probed. No exploit tools or credential extraction utilities are distributed.
2. Accuracy & Scope of Statements: All findings apply exclusively to the documented test environment, software version (156.0.4314.58), and measurement timestamps described herein. The authors make no representations beyond the stated methodological boundaries.
3. No Warranty & Limitation of Liability: This report is provided solely for educational, scientific, and defensive security purposes “AS IS” without warranty of any kind, either express or implied. Under no circumstances shall the authors or operators of zero-trust-lab.org be liable for any direct, indirect, incidental, consequential, or special damages arising out of or in connection with the use or interpretation of this information.
4. Nominative Fair Use of Trademarks: Microsoft, Microsoft Edge, and Windows are registered trademarks of Microsoft Corporation. Product names are used solely for factual, descriptive identification of the tested software. Zero Trust Lab is wholly independent and not affiliated with Microsoft Corporation.