Potential Exposure of 17 Trillion Microsoft Records

An internal analytics service at Microsoft once left a door wide open to approximately $1.73 \times 10^{13}$ (17.3 trillion) rows of data. The vulnerability was simple yet catastrophic: the service failed to verify the signature of login tokens.

This oversight allowed me to impersonate an administrator and execute unauthorized SQL queries without possessing any valid credentials. By analyzing metadata, table descriptions, and small sample sets, I determined the massive scale of the potential breach.

---

Disclaimer: I acted as a white-hat researcher. I reported the bug immediately and never accessed private customer data or PII. Furthermore, Microsoft exercised editorial oversight on this report, modifying certain figures and sections before its release.

Official Response from Microsoft

“We appreciate the opportunity to investigate the findings reported by Faav. Their submission and coordinated vulnerability disclosure helped us to better protect our customers by hardening our services. We value and appreciate safe security research under the terms of the Microsoft Bug Bounty Program and look forward to continuing to work with Faav in the future.”

---

Background: The Journey to Titan

About a year ago, at age 15, I released my first major finding regarding PII leaks in Microsoft's Guest Check-In system. Since then, I've spent my free time—balancing school and hacking—finding vulnerabilities in giants like Google, Adobe, and Amazon.

To scale my efforts, I developed Antares, a custom AI-driven "hackbot." This specific discovery began as an automated lead that Antares couldn't quite close, which I eventually finished during a late-night session.

The Discovery Process

On August 25, 2026, Antares flagged an internal service dubbed "Titan."

1. The Barrier: The main web interface was protected by a "VPN REQUIRED" landing page.
2. The Loophole: While the frontend was blocked, the API was not. Antares scanned subdomains and located an endpoint hosted on Azure Cloud Services.

The API's public Swagger documentation revealed four primary routes:

The /v2/Query route was the most interesting because it accepted raw SQL, but it required a tableName—which the documentation didn't provide. To find a valid table, I used the Wayback Machine to examine 2023 snapshots of Titan's privacy and login pages. I managed to recover 56 table definitions, one of which was named TestData.

Initial Testing

I attempted a basic request to see if the API was open:

POST /v2/Query HTTP/1.1
Host: [redacted]
Content-Type: application/json

{
  "query": "SELECT 1",
  "tableName": "TestData",
  "rowLimit": 1
}

The server responded with 401 Unauthorized. This is where Antares began probing the JSON Web Token (JWT) validation logic.

---

Breaking the Authentication

Antares spent ten days iteratively testing the JWT implementation. It started with a token from my own external Entra test tenant. When the tenant ID was changed to Microsoft's, the system threw an "audience error."

However, I noticed a critical flaw: the system accepted changes to the payload as long as the signature remained the same. It was like a security guard who checks the name on an ID but forgets to check the holographic seal.

The "None" Algorithm Attack

I decided to test an unsigned JWT bypass. I crafted a synthetic token with the following header:

{
  "alg": "none",
  "typ": "JWT"
}

A standard JWT follows the structure: header.payload.signature. My forged token ended with a trailing period and an empty signature section: base64url(header).base64url(payload).

I populated the payload with the expected claims:

• aud: [redacted]
• tid: [redacted]
• appid: [redacted]
• upn: [email protected]
• oid: 00000000-0000-0000-0000-000000000000

The server accepted the token but returned: User '[email protected]' not found.

The "Aha!" Moment

Antares (using Claude and Codex) tried various employee-style emails and aliases, but nothing worked. On September 5, at 1 AM, I stepped in. I stopped treating the upn field as a mandatory email address and wondered if the backend was actually looking for a local username.

I changed the upn to: admin.

The result: The server returned 1.

The system had mapped the string admin to Local User ID 1, which possessed full Administrative privileges.

---

Attack Vector Summary

Final Checklist of the Exploit

• Locate public API endpoint.
• Identify SQL injection point (/v2/Query).
• Discover valid table names via archives.
• Bypass JWT signature verification using alg: none.
• Escalate privileges by spoofing the admin UPN.

I first tested this on the TestData table, which contained only dummy test cases. However, the potential was clear: I had the keys to the kingdom.