Microsoft Titan analytics flaw could have exposed an estimated 17.3 trillion rows

Faav, a security researcher who says he is 16, has published a write-up of a flaw in Titan, an internal Microsoft analytics service. Titan checked the contents of a login token (JWT) but never verified its signature. By his estimate, that let him claim an administrator's identity and submit SQL queries without real credentials, reaching about 17.3 trillion stored rows across a wide range of Microsoft datasets. He says he used only table descriptions, metadata and bounded sample rows to understand the scope, and that he never touched customer data or PII.

Two disclaimers open the post. The impact is hypothetical: it is what an attacker could have done. And Microsoft had editorial control over the post, cutting sections and figures and reshaping how the impact is described before publication. Microsoft's statement, quoted in the post, thanks Faav and says his coordinated vulnerability disclosure helped it better protect customers by hardening its services.

The hunt began on August 25, 2026, when Faav's personal AI hackbot, Antares, identified Titan. Its web interface sat behind a VPN-required page for Microsoft employees, but Antares searched Microsoft subdomains and found a separate API endpoint on an Azure Cloud Services host. Its public Swagger file listed four routes: GetConfiguration, GetOnboardedTables, v2/Query and v2/Insert. Three specified Azure AD bearer authentication. The exception was v2/Query, which also accepted raw SQL.

The query needed a tableName value, and Swagger gave no examples. Faav pulled 2023 snapshots of Titan's login and privacy pages from the Wayback Machine. The archived Superset configuration yielded 56 table definitions, including a routing value called TestData. A request without an authorization header returned 401 Unauthorized, so Antares began probing how Titan validated JWTs.

Over the next ten days, Antares worked through the checks one error at a time, starting from a token issued by Faav's external test tenant. A tenant error led to a changed tenant, which led to an audience error, then an application allowlist error, then finally a user lookup. The payload kept changing while the signature stayed the same, and Titan kept accepting it. Faav then built a synthetic token with an algorithm-none header and an empty signature section. That cleared the tenant, audience and application checks and returned a user-not-found error for the upn value he supplied.

Antares, running Codex and Claude, kept trying email-formatted identities such as placeholders, service aliases and employee-style addresses, and found no upn Titan recognized. Early on Saturday, September 5, after 1 AM and a Friday of schoolwork, Faav tried a different idea: maybe the backend used upn as a local application username rather than an email identity. He set it to admin. The query returned the number 1. Titan had used the unsigned upn claim as a local username; admin resolved to local user ID 1, which held the Admin role, and the SQL ran.

Inside, TestData held only test cases. A broader table listing revealed the rest, including Titan's platform metadata database. There Faav counted approximately 25,000 account and email records, 17,990 employee email records, 15,001 employee organization records, 355 database configurations, 20,979 virtual-dataset SQL definitions, and 24,569 dashboards, 425,891 charts and 27,347 dataset definitions. The user directory exposed job titles, departments and management hierarchy for staff associated with Titan, a subset of Microsoft employees and not the full directory. The password field in one sampled user record held a placeholder hash from Superset's local user model, not a real Microsoft credential.

Faav then noticed a separate Bing analytics source. He ran two one-row samples against the latest available partition, which showed Bing search analytics were reachable. A sampled record held search, identifier and high-level location fields; the locations were country or state level from reverse IP, not precise. Because shared identifiers appeared in more than one dataset, he says correlating user activity across services was plausible, though he says he never did it, never identified anyone and never linked records. After seeing the Bing data he reported the flaw immediately; he had started drafting the report to Microsoft's security response center once he found the employee records.

For the scale, Faav tested all 56 routing values and found 30 still active. They resolved through 24 configurations to 17 connected analytics databases spanning 9,863 unique table names. With no ready-made grand total, he had an AI sum metadata counts from the 17 databases, counting one replica per shard and cross-checking through two separate metadata paths. Both paths returned the same figure, 17,333,335,124,315. He describes it as a storage estimate from metadata that likely includes historical, duplicated and derived data.

Faav draws two lessons from the case. First, that AI and human intuition compounded here: Antares did ten days of enumeration and JWT probing that he didn't have to do himself, but it could not realize that upn was not actually functioning as an email-style identity, and the user-not-found error should have been the tell. Second, the underlying bug: Titan validated the tenant, audience, app ID and user claims but never the signature, so the rest of the checks meant nothing. He tells developers and AI coding agents alike that verifying signatures should come before anything else in an authentication check.

Key facts

• Titan, an internal Microsoft analytics service, validated JWT contents (tenant, audience, app ID, user) but never verified the signature, so an unsigned token with upn set to admin ran SQL as administrator.
• Faav estimates about 17.3 trillion stored rows (17,333,335,124,315 by metadata sum across 17 databases) were reachable; it is a storage estimate that likely includes historical, duplicated and derived data, not a count of records actually read.
• Platform metadata included approximately 25,000 account and email records and 17,990 employee email records; the only sample tied to customer data was two one-row Bing analytics queries, and Faav says he never touched customer data or PII.
• Antares, Faav's AI hackbot running Codex and Claude, spent ten days on the JWT checks; the admin guess that unlocked administrator access was the author's own hunch after 1 AM on September 5, 2026.
• Microsoft says the coordinated disclosure helped it harden its services; the author says Microsoft had editorial control over the post and cut sections and figures before publication.

Why it matters

The underlying flaw is simple to state: a service checked every field in a login token except the one field, the signature, that makes the rest trustworthy. What sets this case apart is scale. One internal analytics service sat in front of 17 connected databases spanning 9,863 unique table names, and the author's metadata-based estimate for what those databases held runs into the trillions of rows. The account also illustrates a specific division of labor between an AI tool and its operator: the author's hackbot Antares spent ten days grinding through authentication errors, but it took a human hunch, that the upn field was being used as a bare local username rather than an email identity, to turn a stalled lead into administrator access.

Who it affects

Microsoft owns Titan and the databases behind it. The employee records the author saw covered a subset of Microsoft staff associated with Titan, not the full company directory; he says that data could plausibly have helped an attacker craft social-engineering attempts, though he never tested that himself. Bing analytics data was reachable through two one-row samples, so the story also touches the users behind those search analytics records, though the author says he never identified anyone or built a profile from what he saw. Developers and AI coding agents writing authentication logic are the story's stated intended audience.

How to use it

There is no product or release here to use. The author's direct takeaway for developers, and for AI coding agents that write authentication code, is to verify token signatures before trusting any other claim in a JWT; checking tenant, audience, app ID and user without checking the signature leaves every other check meaningless, as it did in Titan.

How solid is it

The account comes from the researcher himself and names Microsoft, which is quoted thanking him for coordinated disclosure and saying the report helped it harden its services; Microsoft's statement does not itself confirm the 17.3 trillion figure, the admin access or the employee record counts. The author is explicit that the impact he describes is hypothetical, that he never touched customer data or PII, and that Microsoft had editorial control over the post and cut sections and figures before it ran. The 17.3 trillion number is his own metadata-based estimate, cross-checked through two independent counting paths that agreed, rather than a count of rows he actually read.

Risks and caveats

The headline figure is a storage estimate built from table metadata, not a record of data accessed; the author says it likely includes historical, duplicated and derived data and that he worked only from table descriptions, metadata and small bounded samples. The employee data he saw was a subset of Microsoft's workforce tied to Titan, not the full directory. He says correlating user activity across services via shared identifiers was plausible but that he never attempted it, and that the location data in his Bing sample was only country or state level, not precise. No bug bounty amount, severity rating, or exact patch date appear in the text provided.

“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.”

— Microsoft, statement quoted in the post