Microsoft Titan JWT Flaw: Unsigned Admin Tokens Exposed Internal SQL API

The headline number is real, but it needs a lot of qualification. The lesson for anyone who builds or runs JWT-based services is simpler: checking what a token says is not the same as checking who issued it.

What Titan was and how it was exposed​

Titan is an internal Microsoft analytics platform, not a product customers use. In Faav's disclosure, published September 25, his AI-assisted tool Antares found Titan's API on August 25. The API sat behind a publicly reachable Azure host, even though the service's web interface displayed a VPN-required page.

So the front door was locked and a side door was open. The API documentation listed four routes. Three specified Azure Active Directory bearer authentication; the fourth, /v2/Query, accepted raw SQL and did not specify the same requirement. Old material helped him get further. According to iTnews, he recovered 56 archived table names from a 2023 snapshot of Titan's login pages on the Wayback Machine, which gave him real routing values to test.

The basic hygiene held up at first. CyberSecurityNews reported that requests without an authorization header correctly returned HTTP 401. The weakness only appeared once a token was presented.

Summary: An API without VPN protection sat behind a VPN-protected interface, and a public Swagger document described it, including a SQL-execution route.

The bug: many checks, none of them on the signature​

A JWT has three parts: a header, a payload of claims, and a signature. The header and payload are only encoded. Anyone can decode and edit them. The signature is what proves the token came from a trusted issuer and hasn't been changed.

Titan did check claims. It reportedly checked token claims such as tenant ID, audience, application ID, and user identity. Over about ten days, Antares edited claims and read the error messages, clearing a tenant mismatch, then an audience mismatch, then an application allowlist rejection. The signature never mattered. In Faav's own words, "The payload kept changing while the signature stayed exactly the same, and Titan kept accepting the new claims, like a bouncer checking the name on every ID but never looking at the photo."

He then removed the signature entirely. Faav created a synthetic token with its algorithm set to "none" and an empty signature. Titan accepted it. His write-up describes the token as ending in a bare period, because the signature section was empty.

The last step came from the researcher, not the tool. Antares stalled because it treated the upn claim as a conventional email-formatted Entra identity. Faav's manual intervention led to the pivotal test: changing the claim value to admin. Titan mapped the value to local user ID 1, assigned the Admin role, and successfully executed a SELECT 1 query.

Faav summed it up bluntly: Titan "validated the contents of the JWT (tenant, audience, app ID, user) but never verified the signature." GBHackers made the same point: the several claim checks did nothing because the signature was never verified before the claims were trusted, and the vulnerability did not result from stolen credentials, brute-force attacks, or an account compromise.

Summary: The service ran every claim check except the one that counts. Once the signature is ignored, tenant, audience and app-ID checks are only a to-do list for the attacker.

About "17 trillion records"​

The Rescana report's headline says Titan "exposed 17 trillion internal records." That overstates what the evidence shows. Here is what the reporting supports:

Faav got the total by testing the archived routes. Thirty remained active, resolving through 24 configurations to 17 ClickHouse analytics databases covering 9,863 unique table names. He summed row counts from the databases' own metadata to reach 17,333,335,124,315.

He also says plainly what the number is not. The estimate includes historical, duplicated, and derived data rather than unique customer records or individuals. GBHackers adds that it does not indicate the number of records accessed, exfiltrated, or unique individuals involved.

Other metadata categories listed in the reporting include 355 database configurations, 20,979 virtual-dataset SQL definitions, 24,569 dashboards, 425,891 charts and 27,347 dataset definitions. These are inventories of the platform itself. They are not evidence that data was taken.

There is one more caveat worth knowing. iTnews reported that Faav said Microsoft had editorial input into his published account, including cut sections, redacted images and changes to the description of the impact. That's normal in coordinated disclosure, but it means the public version is the one Microsoft approved.

Summary: "17 trillion" is how much data was in reach. It is not a breach tally. The access Faav confirmed was platform metadata and two sample rows.

Timeline and Microsoft's response​

• August 25, 2026: Antares finds the Titan API.
• September 5: Faav reports the vulnerability to the Microsoft Security Response Center, opening case 144051.
• September 9: Microsoft locks down the API endpoint.
• September 17: Microsoft awards a $5,000 bounty.

Microsoft thanked Faav for responsible disclosure and said the report helped it harden services and better protect customers. Four days from report to lockdown is quick for any vendor.

Two points on the paperwork. First, despite "CVE Analysis" in Rescana's title, none of the reporting shows that a CVE identifier was assigned. Treat this as a fixed flaw in an internal service, not a numbered advisory. Second, Rescana's references to APT29 and MITRE ATT&CK mappings aren't backed by any of the other accounts. They describe the general category of attack, not anything that happened here.

Summary: The flaw was reported, fixed in four days and paid out in twelve. There is no public CVE and no reported exploitation.

Do Windows users or Microsoft customers need to do anything?​

No. Titan is internal, and the sources do not point to any action required from users. Access went through an internal service and a forged token, not through account credentials. Faav limited validation to metadata and one-row queries, reporting no access to customer PII and no evidence that the issue was exploited maliciously.

You don't need to reset passwords, rotate Entra credentials or change tenant settings because of this. The "no exploitation" statement comes from the researcher and the press coverage. No independent forensic audit has been published.

For developers and admins: check your own token validation​

Unsigned-token acceptance ("alg: none") has been a well-known class of JWT bug for about a decade, and JWT libraries have added defaults to block it. It still turns up when custom code decodes a token and reads its claims without calling the library's full validation. Titan shows what that costs: applications must cryptographically verify every token signature, reject unsigned tokens, restrict approved algorithms, validate issuer and audience values, and avoid mapping attacker-controlled claims directly to privileged local accounts.

Here's a practical checklist. Items 1 through 4 follow directly from the reported flaw; items 5 and 6 are standard practice.

1. Verify the signature first. A claim check on a token you haven't verified proves nothing, because the sender wrote the claims.
2. Allow only specific algorithms. Configure the exact signing algorithms you expect on the server, and reject "none" outright.
3. Test for it. Send your API a token with the signature stripped and alg set to none. The only correct response is a rejection. Include this in your security regression tests.
4. Don't map raw claims to local superusers. A upn or sub value should never resolve to a built-in account like admin or user ID 1 without extra binding, such as a matched object ID from a verified issuer.
5. Treat Swagger/OpenAPI documents as reconnaissance material. Titan's public API description told an outsider exactly where the SQL endpoint was.
6. Keep network gates and identity checks on the same routes. A VPN-protected front end protects nothing if the backend API can be reached from the internet.

For .NET teams using Microsoft's identity libraries: the token validation parameters include settings that require signed tokens and validate the signing key (RequireSignedTokens and ValidateIssuerSigningKey). Check that nothing in your code turns these off or skips validation with a "just decode it" helper. That advice comes from general knowledge of the libraries, not from the Titan reports.

The AI angle​

Faav credits both himself and the tool. Antares handled the repetitive probing, and the breakthrough needed a person. "Antares wouldn't have gotten here alone, and neither would I. Its persistence, plus one human hunch, is what made this find possible." Tools like this can grind through ten days of error messages without getting tired, which suits routine checks well. They can also stall on a wrong assumption, as Antares did by treating upn as an email-style identity.

For defenders, this means attackers can now automate the patient, one-error-at-a-time probing that used to protect weak internal services simply because it was tedious. If your internal APIs rely on nobody bothering to look, assume someone is running a tool that will.

Bottom line​

This was a serious authentication failure in an internal Microsoft service, reported responsibly and fixed quickly. It was not a trillion-record breach, and customers don't need to take any action. The takeaway for anyone running JWT-based services is to verify the signature before trusting the claims.