Data Breach Update

Data Breach Update: Microsoft Titan Flaw Exposed 17T Rows

Published September 29, 2026 · DNS Benchmark Pro Editorial · Reading time: 7 minutes

Most items in a data breach update describe data that has already left the building. This one describes the four days in which it could have, and that makes it more useful. There is no CVE, no patch to deploy and no vendor advisory to chase — the defect lived in one organisation's internal server infrastructure, in a service almost nobody outside Microsoft had heard of. Which is precisely why every enterprise IT security team should read it as a description of their own estate.

An internal service that was not internal

Titan is an analytics platform: dashboards, saved queries, virtual datasets, the usual internal business-intelligence furniture. Its front end was gated behind a corporate VPN. Its API was not. The researcher found it through automated reconnaissance on 25 August 2026, and the endpoint served a Swagger document advertising four routes — /GetConfiguration, /GetOnwardedTables, /v2/Query and /v2/Insert.

That gap between the interface and the API is the most transferable part of the story. A login page is a control that humans see. An API hostname resolving on the public internet is a control that nobody sees unless someone is looking. The banner claiming VPN was required was accurate about the UI and irrelevant to the machine-readable half of the same service.

The bypass: claims read, signature ignored

Unauthenticated requests to /v2/Query returned HTTP 401, so the route did check something. Over roughly ten days the researcher mutated token payloads while leaving the signature block untouched — and Titan kept accepting the new claims. As Faav put it, the service was “like a bouncer checking the name on every ID but never looking at the photo.”

The final step removed the signature entirely. A JWT whose header declares alg: "none" is serialised as base64url header, dot, base64url payload, dot, nothing:

This is not an exotic zero-day vulnerability. The unsigned-token trick is roughly a decade old and sits in every JWT hardening checklist. It survives because internal services inherit an assumption — that only trusted callers can reach them — and then that assumption quietly stops being true when a hostname is published.

What 17.3 trillion rows does and does not mean

The headline figure is a sum of row counts across 17 ClickHouse databases, including historical partitions, replicas and derived aggregates. It is not 17 trillion people. The researcher deliberately stayed at metadata level and pulled only bounded single-row samples, but the metadata alone is uncomfortable: about 25,000 account and email records, 17,990 employee email entries, 15,001 employee organisation records with job titles and reporting lines, 355 database configurations, 20,979 virtual-dataset SQL definitions, 24,569 dashboards and 425,891 charts. Bing search analytics were reachable too.

An org chart plus a directory is the raw material for credible spear-phishing. The saved SQL definitions are a map of where the valuable data lives. In cloud security terms, the metadata was arguably the more dangerous half.

Why this is a DNS security problem too

Nobody attacked Titan through DNS. But nobody would have found Titan without it either. Modern reconnaissance against an organisation is largely a name-discovery exercise: certificate transparency logs, passive DNS, brute-forced subdomains and cloud-provider naming conventions. Every internal service you publish gets a name, and every name is public the moment a certificate is issued for it.

That gives defenders a concrete action. Enumerate your own zones the way an attacker would, then reconcile the result against your asset inventory. Anything resolving that nobody owns is the same category of finding as Titan. Feeding that list into your protective DNS tier closes the loop, and if your resolvers now speak encrypted transports, our explainer on DNS over HTTPS and DoT covers what that changes about the telemetry you keep.

The checklist for your own internal APIs

1. Reject unsigned tokens outright. Pin an allow-list of algorithms server-side and treat none as a parse failure, not an option.
2. Verify the signature before reading any claim. Validate issuer, audience and expiry as well — a correctly signed token from the wrong issuer is still the wrong token.
3. Never map an attacker-controlled claim to a privileged local account. A upn of admin should not be able to become user ID 1.
4. Do not let a UI-level gate stand in for network policy. If the service is internal, the API hostname should not resolve or answer from the internet.
5. Treat published Swagger as part of your attack surface. Remove it from unauthenticated paths, and audit archived route definitions — 30 of 56 stale routing values were still live here.
6. Separate raw-SQL endpoints from everything else. A route that executes arbitrary queries needs its own authentication path, allow-list and audit trail.
7. Sweep DNS and certificate transparency monthly and reconcile against inventory, as an attack-surface control rather than a compliance artefact.

Industry impact

The instructive contrast is with the rest of this month's enterprise IT news: edge appliances with CVSS 9.5 scores, emergency federal deadlines and vendors shipping builds overnight. Titan had none of that apparatus, because internal tools are not products. There is no advisory to subscribe to, no KEV entry to trigger your patch process and no vendor to escalate to. The only thing standing between that class of service and the internet is an inventory someone maintains.

It also says something about economics. A $5,000 bounty for an authentication bypass reaching an employee directory and a petabyte-class analytics estate is, by any reasonable measure, cheap — and the finding came from a teenager running his own automation, not from a red team engagement. The disclosure was coordinated and Microsoft's remediation was fast, which is the outcome the system is designed to produce. But the same reconnaissance is available to people who will not file a report.

The durable lesson of this data breach update is unglamorous: cryptographic verification is not optional because a service is internal, and “internal” is a claim about your network that only your DNS and your certificate logs can actually confirm. Teams that already validate token signatures at the gateway, keep raw-query endpoints off shared authentication paths and reconcile resolving names against inventory did not need this week's news. Everyone else has a list to write.

Sources

• Faav — How I could've accessed 17 trillion Microsoft records (researcher write-up)
• Help Net Security — 16-year-old researcher breaks into Microsoft analytics service with access to 17 trillion rows of data
• Cyber Security News — 16-year-old researcher finds Microsoft auth vulnerability exposing 17.3 trillion stored records
• GBHackers — 16-year-old researcher discovers Microsoft authentication bug exposing 17.3 trillion records
• IT-Connect — Unsigned JWT vulnerability in Microsoft Titan exposed 17.3T rows
• IETF RFC 8725 — JSON Web Token best current practices

Independent editorial analysis published by DNS Benchmark Pro / Genext Information Systems. The Microsoft Building 92 photograph is by Coolcaesar, licensed CC BY-SA 4.0 via Wikimedia Commons; the Microsoft wordmark is the company's official logo, public domain, via Wikimedia Commons; the benchmark screenshots are original captures of the DNS Benchmark Pro engine. No images on this page are AI-generated.