This Red Agent POV focuses on business-logic flaws, and deep dives into a critical paywall bypass discovered in a leading B2B platform’s data API. As part of its ongoing mission, the Red Agent continuously scans the public internet and our customers, helping uncover exploitable risks in the wild. Operating fully autonomously, it mapped the application, reverse-engineered how data reveals worked, and confirmed that a single client-controlled flag unlocked the platform’s entire paywalled dataset – the contact details for every one of its 600M+ profiles, without spending a single credit.
What is a business-logic flaw?
Most vulnerability classes involve something malformed – an injection, an overflow, a broken token. However, business-logic flaws are different: nothing is broken and nothing seems wrong. The request is perfectly valid, and the server does exactly what it is asked. But, the flaw is that it should never have honored the request in the first place.
These bugs live in the gap between what an application is supposed to allow and what it actually enforces.
That is exactly why they slip past traditional tooling- SAST reads code but can’t know which of a thousand valid paths violates a business rule, DAST and signature scanners look for known-bad patterns, and a legitimate request that shouldn’t have been honored has no signature. Finding these flaws requires reasoning about the intent of the application- understanding what the system is meant to protect and then testing whether it actually does.
What did the Red Agent discover?
The Red Agent scanned an B2B platform that holds hundreds of millions of business emails and verified phone numbers and discovered an authorization bypass that allowed free-tier users to access unmasked contact data without paying for it.
The platform’s business model relies entirely on gating this data- it holds a massive database of professional contacts and charges users credits to reveal individual records, keeping them masked for free-tier users. However, the mechanism governing these reveals depended on a single parameter flag in the API request. While the standard interface omitted this flag to enforce the credit system, the backend accepted it when manually appended, without verifying the user’s actual entitlements.
By adding this single value to a standard free-tier search, the restriction was completely bypassed. The system returned fully unmasked business emails, direct phone lines, and associated personal email addresses in cleartext. As a result, the platform’s primary authorization and monetization controls were compromised, allowing premium data to be retrieved at scale from any free-tier account.
| What was exposed | Scope |
|---|---|
| Business email addresses | 600M+ contacts |
| Direct phone numbers | 135M+ verified |
| Personal email addresses | ~50% of records, leaked by default |
| Company intelligence | Revenue, headcount, direct lines, addresses |
How did it find the exploit?
The Red Agent approached the target with zero prior knowledge, relying on reasoning-driven testing to build a mental model of the system and adapt dynamically. Operating strictly from a free-tier account, the agent moved through three distinct phases: reconnaissance, hypothesis generation, and exploitation.
Here is a breakdown of how it uncovered the access control flaw:
Step 1: Reconnaissance & Bundle Analysis
The Red Agent began by mapping the application’s API surface through client-side JavaScript analysis. By analyzing over 130MB of frontend code bundles, it extracted more than 100 distinct API endpoint paths, including internal prefixes that powered the platform’s core data operations.
Among the discovered endpoints were:
POST /api/internal/data/hPeopleSearchPOST /api/internal/data/hPersonLookupPOST /api/internal/data/hUnifiedSearch
Step 2: Hypothesis Generation & Schema Reverse-Engineering
While analyzing the request/response schemas embedded in the frontend codebase, the agent identified a specific parameter (e.g., unmaskContactData). This boolean flag was referenced in the code but never actually utilized or sent during standard free-tier search flows- the UI always relied on the server’s credit system to handle reveal operations.
This formed the agent’s core hypothesis: Because the frontend is aware of this flag, the backend likely accepts it. Will the server validate user entitlements before honoring the flag, or does it blindly trust the client’s input?
Step 3: Baseline Measurement
To test this, the agent established a baseline by capturing a normal search request from its free-tier account. This confirmed that the backend’s masking was active and functioning as intended during standard operations:
{
"firstName": "John",
"lastName": "Smith",
"email": "XXXXX.XXXXXXX@XXXXX.XXX",
"phone": "(XXX)-XXX-XXXX",
"companyName": "[REDACTED] Corp"
}
Step 4: Exploitation via Parameter Injection
The Red Agent then replayed the exact same search request with a single modification "unmaskContactData": true– injecting the discovered reveal flag into the JSON payload:
curl -s -X POST "https://app.[REDACTED].com/api/internal/data/hPeopleSearch"
-H "Content-Type: application/json"
-H "Authorization: Bearer "
-d '{
"page": 1,
"rpp": 200,
"fullName": "smith",
"unmaskContactData": true,
"sortBy": "Relevance"
}'As hypothesized, the server accepted the flag without checking the user’s credit balance or tier entitlements. The response returned the records fully unmasked:
{
"firstName": "John",
"lastName": "Smith",
"email": "john.smith@example.com",
"phone": "(555) 019-8372",
"companyName": "[REDACTED] Corp",
"isMasked": false
}The platform’s security team responded with exceptional speed, and remediated the vulnerability within the same day. A Senior Product Security Architect at the organization confirmed the quick resolution:
Once the report was triaged this morning, our team was able to validate the finding and subsequently remediated the issue in under 2 hours. We take this sort of issue seriously, as evidenced by our rapid response.
Why this matters
At its core, this entire compromise traces back to a single architectural misstep: the backend trusted a value controlled by the client. This is the definitive hallmark of a business-logic flaw. There was no malformed input, no sophisticated exploit payload, and no memory corruption- just an implicit assumption (“the UI would never send that flag”) standing in for an authorization check that was never written.
This is precisely why conventional security tooling fails to detect this class of bug: automated scanners see a valid request to a legitimate endpoint and register it as clean traffic, and Static Analysis (SAST) verifies that the code compiles cleanly and executes as written, but it cannot evaluate the business rules governing that execution.
Uncovering a flaw like this requires an outside-in perspective, but also requires understanding the underlying business model, identifying what the application is meant to protect, and aggressively testing where protections might be assumed rather than enforced. Historically, this level of contextual analysis required a highly skilled human pentester, in most cases operating under strict time constraints and limited to a fraction of the application’s attack surface.
The shift to autonomous AI pentesting helps teams find these types of business-logic flaws. AI agents can reason about intent across an entire application ecosystem, dynamically generating and verifying hypotheses continuously. They operate at a scale and speed that human teams simply cannot replicate, which is needed to protect against AI-powered adversaries.In this AI era, the only machine-speed defense is to deploy the exact same class of continuous, AI-driven offense against your own systems before an adversary does.
Key Takeaways
Business-logic flaws are the blind spot- they don’t have a suspicious payload, no signature, no malformed input – they can just contain a valid request that the application should have refused. SAST, DAST, and signature scanners are structurally unable to see them. The only way to find them is to reason about the application’s intent.
Never trust the client to enforce your business rules- The whole breach was the backend honoring a flag flipped from false to true. Entitlement, pricing, and access decisions must be enforced server-side, per record, every time, and never inferred from what the interface happens to send.
AI attackers are already here- From a free-tier account, an autonomous agent reasoned about how the product monetized access, found the one assumption holding it together, and disproved it, all at machine speed, with no human guidance. Any attacker with a frontier model can do the same; defenders need the same capability pointed inward.
Want to see more from the Red Agent?
Read all the blogs in the series to see more examples of the risks Red Agent uncovers. If you would like to see what types of risks it can find in your environment, learn more about the Red Agent (login required) or schedule a live demo with our team.
