A flaw in Titan, an internal Microsoft analytics service, let an outside researcher reach employee records and Bing search analytics by posing as the service’s administrator. The researcher, a 16-year-old who goes by Faav, found that Titan did not verify the signature on its login tokens, which opened the door to running SQL queries across 17 connected databases holding an estimated 17.3 trillion rows.<\/p>\n
Faav did not work alone. He built Antares, an automated bug-hunting tool that flagged Titan and kept working through its login checks for ten days before he stepped in to take the final step himself. Reporting through the Microsoft Security Response Center led to a patch within days and a $5,000 bug bounty.<\/p>\n
Titan’s web interface was only reachable over a Microsoft VPN, but Antares found a separate API endpoint with public documentation. One of its routes, Antares kept returning to Titan while Faav chased other leads. The breakthrough came from a token originally created months earlier for testing against an external Entra tenant.<\/p>\n The token’s payload kept changing while the signature stayed exactly the same, and Titan kept accepting the new claims. The next test sent a token with the algorithm set to Antares spent days trying email-style addresses in the token’s UPN field. On September 5, Faav changed the value to Titan’s platform metadata database held roughly 25,000 account and email entries, 17,990 employee email records and 15,001 employee organization records, according to the write-up. The employee information included job titles, departments and management hierarchy for staff associated with Titan, and covered a subset of Microsoft’s workforce. In the wrong hands, that data could have supported targeted social engineering, though Faav did not test that angle.<\/p>\n The researcher also reached a Bing analytics source and pulled two one-row samples from its latest partition. The samples contained search, identifier and location fields, with country- or state-level information derived from reverse IP lookups. Because MUIDs (the identifiers Microsoft stores in users’ browsers) appeared in more than one dataset, user activity could plausibly have been correlated across services.<\/p>\n Faav called the 17.3 trillion row figure a storage estimate from database metadata that likely includes historical, duplicated and derived data.<\/p>\n Faav reported the vulnerability to the Microsoft Security Response Center on September 5. MSRC asked him to stop testing and requested his IP address to confirm there was no activity beyond his research. The endpoint was locked down on September 9, and the $5,000 bounty was paid on September 17.<\/p>\n Faav stressed that he never touched customer data or personal information, and did not use the two Bing samples to identify anyone, link records between datasets, or build profiles. He also revealed that Microsoft had editorial control over his write-up, with sections, figures and impact descriptions cut or reworded before publication.<\/p>\n The whole chain hinged on a single missing check: Titan accepted tokens whose signatures were absent or had never been verified. A token’s payload, including the user identity, tenant, audience and application ID, is meant to be sealed by a signature issued by the identity provider. If a service only inspects the contents of the token and never confirms that the signature is valid and trusted, any user can rewrite the contents and claim to be anyone, including the administrator.<\/p>\n Allowing the algorithm to be set to A 16-year-old researcher found that Titan, Microsoft’s internal analytics service, did not verify the signature on its login tokens. By rewriting token contents and setting the algorithm to none, he gained administrator access and could run SQL queries across databases holding an estimated 17.3 trillion rows.<\/p>\n The exposed data included around 25,000 account and email entries, 17,990 employee email records and 15,001 employee organization records, plus Bing analytics samples containing search, identifier and location fields. The researcher did not touch customer data or personal information.<\/p>\n The Microsoft Security Response Center received the report on September 5, asked the researcher to stop testing, locked down the endpoint on September 9, and paid a $5,000 bug bounty on September 17.<\/p>\n\/v2\/Query<\/code>, accepted raw SQL and refused requests without an authorization header.<\/p>\n\n
none<\/code> and an empty signature section. It passed every check and reached a user lookup that returned a user not found error.<\/p>\nReaching the admin account<\/h2>\n
admin<\/code>. Titan treated the field as a local username and matched it to user ID 1, which held the Admin role. That single change handed him administrator access and let him run SQL queries against the service.<\/p>\nWhat was inside the databases<\/h2>\n
Disclosure and Microsoft’s response<\/h2>\n
What the case shows about token validation<\/h2>\n
none<\/code> compounds the problem, since the service then has no signature to check at all. Hardening here means rejecting any token that does not carry a valid, currently trusted signature from the right issuer, regardless of what the payload says.<\/p>\nFAQ<\/h2>\n
What is the Titan vulnerability at Microsoft?<\/h3>\n
What data was exposed in the Titan flaw?<\/h3>\n
How did Microsoft respond to the Titan bug report?<\/h3>\n