17 Trillion Rows, $5,000: How to Judge a Bug Bounty

Key takeaways

• A claim of access to 17 trillion rows does not establish that those records were stolen.
• The severity of a JWT authentication bypass depends on what an attacker could actually do.
• A $5,000 bounty is not a dollar estimate of the damage a vulnerability could cause.
• Judging a payout requires both the demonstrated impact and the criteria used to assess it.

Access to 17 trillion rows through a JWT authentication bypass in Microsoft Titan, rewarded with just $5,000: if that account holds up, it deserves scrutiny. The mismatch practically writes its own headline. But deciding whether the reward was fair takes more than dividing one enormous number by one small one.

Count the exposure, not just the rows

A database row is a record, not a person. One user can generate thousands of records simply by using a service. Seventeen trillion rows does not mean 17 trillion victims, or even 17 trillion pieces of personal information.

The contents matter just as much. A routine status entry and a secret used to reset an account password can each occupy one row. Their security implications are very different.

Then there is the distinction between storage and access. A system containing 17 trillion rows does not necessarily expose all of them through a vulnerable endpoint. Demonstrating access to a handful of records does not, by itself, prove access to the entire database.

That cuts both ways. A researcher might retrieve only a few records to demonstrate the problem without causing unnecessary harm. A small sample does not automatically mean a small vulnerability.

The useful measure is demonstrated access scope: what the researcher established an attacker could reach, under what conditions. Database size is context, not a verdict.

A broken badge check tells you only so much

JWT, short for JSON Web Token, is a format used to carry claims such as identity or permissions. Think of it as a digital office badge. The server needs to validate the badge before trusting what it says.

“JWT authentication bypass” describes a broad category of failure. It does not tell us whether the problem involved signature verification, checks on who issued the token, checks on its intended recipient, or something else. The phrase alone cannot establish what went wrong in Titan.

To assess the risk, start with what happened after the badge passed inspection:

• Could an attacker get in without an account, or did the exploit require existing access or special permissions?
• Could they reach only their own organization’s data, or cross into another organization’s?
• Could they only read records, or also modify and delete them?

Those distinctions determine both the difficulty of an attack and its potential damage.

A badge that opens the lobby and a badge that opens every tenant’s office represent very different failures. Calling both an authentication bypass does not make them equally severe.

A bounty is not an invoice for avoided damage

Bug bounty programs reward researchers for finding vulnerabilities and reporting them through an established process. They are not promises to pay a fixed percentage of whatever a breach might have cost.

A program may consider severity, exploitation requirements, and its published reward ranges. The applicable rules matter. A $5,000 payment alone cannot tell us how Microsoft assessed the issue.

But “the payment followed the rules” does not settle whether the rules produced a reasonable outcome. Program compliance and a reward researchers find credible are separate questions.

If a vulnerability required little preparation and exposed sensitive information across many organizations, a low payment would deserve scrutiny. If access was tightly constrained and the affected records were relatively innocuous, the same amount could look different.

Neither conclusion follows from the row count. Both depend on the actual conditions of exploitation and the consequences of successful access.

Show the reasoning behind the reward

A bounty program’s credibility rests partly on whether researchers can understand its decisions.

Consider a hypothetical disagreement: a researcher reports access to other organizations’ data, while the company concludes that only limited test data was affected. “The award reflects our internal criteria” would leave the central question unanswered.

A useful explanation would identify what access the company reproduced, where that access stopped, and how those findings informed the severity rating. It would also clarify whether the quoted payment was an initial award or the final total, including any additional compensation.

That does not require publishing a working exploit. It requires enough information to connect the accepted impact to the reward.

This matters to companies, too. Researchers deciding where to spend their time may consider more than the largest advertised payout. A program that evaluates findings consistently and explains disagreements gives them something useful to plan around.

The “17 trillion rows for $5,000” framing raises a legitimate question, but it cannot answer it. To judge the reward, we need to know what risk was demonstrated, what risk the company accepted, and how its criteria connected the two. The payout is a number; the explanation is what makes it defensible.