CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N/E:P/RL:O/RC:C
Score: 9.1 (Critical)
| Metric | Value | Description |
|---|---|---|
| Attack Vector (AV) | Network (N) | Exploitable remotely over the internet |
| Attack Complexity (AC) | Low (L) | No special conditions required beyond standard reconnaissance |
| Privileges Required (PR) | None (N) | Attacker needs no prior access to the target |
| User Interaction (UI) | None (N) | Target does not need to click anything or take any action |
| Scope (S) | Unchanged (U) | Vulnerability affects only the vulnerable component |
| Confidentiality (C) | High (H) | Full access to emails, files, messages, and personal data |
| Integrity (I) | High (H) | Attacker can change password and fully control the account |
| Availability (A) | None (N) | Service remains available; no denial of service |
| Exploit Maturity (E) | Proof-of-Concept (P) | Exploit exists and has been demonstrated successfully |
| Remediation Level (RL) | Official Fix (O) | Microsoft should provide an official fix |
| Report Confidence (RC) | Confirmed (C) | Vulnerability has been verified by the reporter |
Discoverer: Taylor Christian Newsome
Discovery Date: 01/08/2011
Last Verified: 03/07/2026
Submission Date: 03/07/2026
This report documents a critical vulnerability in the Microsoft Account password recovery workflow, discovered by Taylor Christian Newsome in 2011 and confirmed as still functional as of October 2023. The flaw allows an unauthorized attacker to completely bypass standard account verification methods and gain full control of a target Microsoft account through a race condition in the recovery process.
The vulnerability enables an attacker to receive a complete, unmasked password reset code at an email address they control, effectively neutralizing Microsoft's security controls. Successful exploitation grants persistent access to the victim's Microsoft account and all linked services, including Outlook.com, OneDrive, Xbox Live, Skype, Microsoft Teams, and any other Microsoft properties associated with the account.
This issue represents a critical security gap that has remained unaddressed for over a decade, posing significant risk to millions of Microsoft account holders.
- Primary Classification: Race Condition (CWE-362)
- Secondary Classification: Information Exposure (CWE-200)
- Impact Type: Authentication Bypass / Account Takeover
| Product | Component | Location |
|---|---|---|
| Microsoft Account (MSA) | Password Recovery | https://account.live.com/resetpassword.aspx |
| Skype | Friends List Integration | Account Recovery Contact Verification |
| Microsoft Teams | Contacts Integration | Account Recovery Contact Verification |
9.1 (Critical) - CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N/E:P/RL:O/RC:C
The Microsoft Account password recovery process contains a race condition that occurs when an attacker submits multiple identical recovery requests in rapid succession. During a standard recovery flow, Microsoft sends verification codes to a partially masked email address (e.g., po*****@gmail.com) to protect the user's privacy. However, when two recovery forms are submitted simultaneously across different browser tabs with accurate target information, the system experiences a synchronization error in its request handling.
This race condition causes the system to deliver the full, unmasked password reset link or code directly to the attacker-controlled email address specified in the contact field, bypassing the intended security masking.
The underlying issue appears to be improper session management or request queuing in the account recovery service. When multiple recovery requests for the same account are processed concurrently, the system fails to maintain consistent state tracking, leading to:
- Loss of email masking context - The system "forgets" to apply privacy masking to the verification email
- Incorrect delivery routing - The reset code is sent to the attacker's email instead of being properly verified against the account owner
- Race condition window - The vulnerability window exists during the milliseconds between concurrent request processing
To successfully exploit this vulnerability, an attacker must first gather specific information about the target:
| Required Information | Purpose |
|---|---|
| Target's Microsoft account email | Primary identifier for recovery |
| First name, last name | Identity verification |
| City, state, zip code | Location verification |
| Three Skype/Teams contacts | Secondary verification factor |
While these requirements increase attack complexity, they do not prevent exploitation given the prevalence of personal information available through data breaches, social media, and OSINT (Open Source Intelligence) techniques.
The following steps demonstrate successful exploitation on a test account. These steps should only be performed on accounts you own or have explicit permission to test.
- Navigate to
https://account.live.com/resetpassword.aspx - Enter the target account's email address
- Click "Next"
- When prompted for verification, click "Use a different verification option"
- Click "Show more verification methods"
- Select "I don't have any of these" to proceed to the full recovery form
- If asked "Do you have an account recovery code?", click "No"
- "What Microsoft account are you trying to get back into?" - Enter target email
- "Where should we contact you?" - Enter attacker-controlled email address
- Complete the CAPTCHA
- Click "Next"
- When prompted, enter the three pre-identified Skype/Teams contact names
- Do not submit yet - Leave this tab ready
- Open a second browser tab (new incognito/private window)
- Repeat Steps 1-12 exactly, using the same target information
- Leave both tabs open with the final "Submit" button ready
- Position both browser tabs side-by-side
- Click the final "Submit" button on both tabs simultaneously
- The clicks should occur within milliseconds of each other
- Check the attacker-controlled email inbox
- If successful: A password reset email arrives containing a full, unmasked reset link or code
- The email address in the "To:" field shows the complete address (e.g.,
target@gmail.comnotta****@gmail.com)
- Click the reset link or enter the code
- Set a new password for the target account
- Log in with the new credentials
- Verify access to Outlook, Skype, OneDrive, Xbox, and other Microsoft services
| Scenario | Expected Behavior | Observed Behavior (Vulnerable) |
|---|---|---|
| Single recovery request | Masked email (po****@gmail.com) receives reset code | Masked email receives reset code |
| Concurrent recovery requests | Both requests handled sequentially with masking | One request "glitches" and sends unmasked code to attacker email |
The following videos demonstrate the method successfully compromising target accounts:
Note: These videos are provided as evidence of exploit viability. The technical methodology has not been publicly disclosed until this report.
- Affected User Base: All Microsoft Accounts with linked Skype or Teams contacts
- Account Types: Personal Microsoft accounts (Outlook.com, Live.com, Hotmail.com)
- Associated Services: Outlook, OneDrive, Xbox Live, Skype, Microsoft Teams, Office 365, Bing, MSN
| Impact Category | Description |
|---|---|
| Confidentiality | Full access to victim's emails, private messages, cloud files (OneDrive), photos, purchase history, and personal information |
| Integrity | Attacker can change password, add new recovery options, modify account settings, and lock out legitimate owner |
| Availability | Victim loses access to all Microsoft services; attacker can maintain persistence indefinitely |
| Lateral Movement | Compromised account can be used for phishing attacks against the victim's contacts, identity theft, or accessing other platforms using Microsoft SSO |
The discoverer, Taylor Christian Newsome, reports that this method has been successfully used to compromise high-profile accounts, including:
- A major YouTube channel
- Xbox and Skype accounts belonging to prominent individuals
The method has reportedly been in active use since 2011, indicating prolonged exploitation of this vulnerability.
According to the reporter, Microsoft has previously classified similar reports as "social engineering" rather than a technical vulnerability. However, the core issue is demonstrably a technical flaw:
- Social engineering would require tricking the user or support personnel
- This exploit requires no interaction from the target and relies purely on a race condition in Microsoft's systems
- The unmasking of email addresses and delivery to an attacker-controlled address is a server-side technical failure, not a social engineering artifact
The distinction is critical: while reconnaissance is required, the actual bypass occurs due to improper request handling, not user manipulation.
| Recommendation | Priority | Implementation |
|---|---|---|
| Rate Limiting | Critical | Enforce strict rate-limiting on recovery form submissions. Block or delay multiple identical recovery requests for the same account within a short time window (e.g., 1 attempt per 15 minutes per account). |
| Request Queuing | Critical | Implement server-side session locking to ensure concurrent requests are processed sequentially, not in parallel. |
| Consistent Masking | High | Ensure all reset codes and recovery emails are consistently masked at the point of generation, regardless of request concurrency. The unmasked value should never exist in email delivery queues. |
| Recommendation | Priority | Implementation |
|---|---|---|
| 2FA Enforcement | High | Mandate two-factor authentication for all recovery paths. Block recovery attempts entirely if 2FA is enabled without hardware token verification. |
| Contact Verification Enhancement | Medium | Validate Skype/Teams contact information against additional account ownership proofs beyond self-reported data. Consider challenge-response verification. |
| Reconnaissance Resistance | Medium | Limit public exposure of Skype/Teams contacts by making them private by default and requiring authorization for visibility. |
| Recommendation | Priority | Implementation |
|---|---|---|
| Session Binding | Medium | Bind recovery sessions to specific browser fingerprints or IP addresses to prevent multi-tab exploits across different contexts. |
| Recovery Workflow Redesign | Medium | Redesign the account recovery process to eliminate reliance on easily obtainable personal information. Implement cryptographic verification methods. |
| Automated Testing | Low | Conduct regular automated fuzzing of recovery workflows to detect similar race conditions and concurrency issues. |
| Date | Event |
|---|---|
| 2011 | Vulnerability initially discovered by Taylor Christian Newsome |
| 2011-2023 | Method reportedly used in limited, targeted exploits |
| October 2023 | Last verified as functional on test account |
| [Current Date] | Formal disclosure to Microsoft MSRC |
| TBD | Microsoft investigation and validation |
| TBD | Coordinated public disclosure (if applicable) |
This vulnerability represents a critical security flaw in the Microsoft Account recovery system that has remained unpatched for over a decade. The ability for an attacker to receive an unmasked password reset code through a simple race condition undermines the security of millions of Microsoft accounts and associated services.
Immediate remediation is strongly recommended to prevent continued exploitation. The discoverer, Taylor Christian Newsome, is available to provide additional details, assist with reproduction, or participate in coordinated disclosure efforts.
Discoverer: Taylor Christian Newsome
Submission Method: Microsoft MSRC Researcher Portal
Preferred Acknowledgment: Taylor Christian Newsome
- [Link to Video 1: YouTube Channel Takeover Demonstration]
- [Link to Video 2: Xbox Account Takeover Demonstration]
- [Screenshots of successful exploit on test account - available upon request]
End of Report