In early 2024, a 15-year-old who hunts bugs in his free time reported a vulnerability to Zendesk. The bug let anyone with a guessable ticket ID spoof an email and get themselves CC’d into another customer’s support tickets. Over half of the Fortune 500 used Zendesk. So this wasn’t just a Zendesk bug — it was a backdoor into the support correspondence of every customer of every major company that had ever opened a ticket. Account issues. Billing disputes. Identity verification documents people had attached to support requests. The full conversation thread.

Zendesk’s HackerOne program closed it as out-of-scope. Email spoofing was excluded.

Daniel — known online as hackermondev — didn’t drop it. He chained the bug into a full Slack workspace takeover by abusing Apple’s “Sign in with Apple” flow, then started reporting it directly to the individual Fortune 500 companies that were affected. Some patched. Some refused, claiming it was Zendesk’s problem. He earned over $50,000 across individual programs.

Zendesk eventually fixed the bug after pressure from their own customers. They paid Daniel zero. Their reasoning: he had violated HackerOne’s disclosure guidelines by reporting to the affected companies.

Later, Discord disclosed that it had been breached through Zendesk — exactly the supply-chain consequence that disclosure had warned about.

The bug stayed open long enough for someone with worse intentions to find the same path. Real users had their data exposed. The company that built the broken backend paid a 15-year-old nothing for catching it before the breach happened.

This is not an outlier. This is the bug bounty industry’s most quietly destructive pattern.

The pattern

Here’s the shape: a researcher does subdomain enumeration on a program in scope, finds something.organization.com, sees that it CNAMEs to a SaaS vendor (Zendesk, Salesforce, Drift, Greenhouse, Algolia — take your pick), exploits a vulnerability that exposes the organization’s customer data, and reports it. The triager closes it as Not Applicable “because the issue is on the third-party service.”

Every part of that response is wrong, and the bug bounty industry has known it’s wrong for at least a decade.

The cost of getting it wrong is not paid by the program. It’s not paid by the vendor. It’s not paid by the platform that runs the bounty. It’s paid by the customers — the people who signed up for the brand and never knew the vendor existed.

Why I’m writing this

I’m writing this as someone whose data has been in those breaches. Not in the abstract. Real notifications, real password resets, real fraud alerts. So when I do bug bounty after work, what I’m actually hunting is the next breach — the one that hasn’t happened yet, the one where someone else’s data ends up in the same kind of dump my data has been in.

That is the core security mindset. It’s not “find the bug, get paid.” It’s: find the bug before someone else does, and protect the people who don’t have the chance to evaluate the vendor stack behind the brand they trusted. People who don’t understand the technology. People who clicked sign-up and trusted that someone, somewhere, was looking out for them.

When a bug bounty program closes a real vulnerability as Not Applicable because “it’s on a third party,” the program is telling the researcher to stop hunting that part of the stack. So they do. And the next person who finds the same hole isn’t a researcher.

This post isn’t about hunters not getting paid. It’s about what happens to the customers when the program decides their vendor stack isn’t worth defending.

This isn’t new

In 2014, Patrik Ricafort found a vulnerability in Google Nest that exposed Nest customer credentials, payment cards, and scanned passport images. Google added him to their hall of fame and refused to pay, telling MIT Technology Review it was a third-party software vendor issue. The customer data was Nest’s. The brand was Nest’s. The trust relationship was Nest’s. The bounty was zero.

Read that list of data again — passport scans, payment cards, credentials. These are the documents people use to prove they exist to the rest of the system. The company on the receiving end of that data decided the bug that exposed it wasn’t theirs to pay for.

That was the first major version of this story. It has run continuously since.

It’s written into the policy

The carve-outs aren’t accidental. They’re documented.

Microsoft’s M365 Bounty page, as of writing, states that some third parties host sites under Microsoft-owned subdomains — and that those third parties are not in scope for the bounty program. The framing matters: it’s not the vulnerability that’s out of scope. It’s the third party. Even though the subdomain is *.microsoft.com and the customer who lands there sees Microsoft’s branding.

Meta excludes third-party apps and websites by default. Vulnerabilities in third-party assets are only eligible if found through passive observation with no manipulation, and only if generally affecting more than 200,000 Facebook users. SQLi, XSS, IDOR, and open redirects on third-party assets are explicitly out of scope. Whether Meta pays for any third-party finding is “completely within our discretion.”

Intel’s bug bounty excludes third-party products that do or do not contain Intel-branded technology. Only Intel-branded code root causes are eligible.

Intigriti’s own scoping guidance for programs advises that vulnerabilities in third-party SaaS or PaaS should be reported to the upstream vendor and treated as out of scope by default — even when the asset is on the org’s own domain.

Immunefi, the largest Web3 bug bounty platform, has published — in writing — a policy of marking subdomain takeovers as Not Applicable by default unless the researcher demonstrates impact on the core application.

The customer who signed up for the service doesn’t read the bug bounty policy. They have no way to know that the part of the platform handling their support tickets, their payment, or their identity verification is in a documented carve-out. They trust the brand. The brand has decided that part of itself isn’t worth auditing.

The pattern goes far beyond subdomain takeovers

Most of the public conversation about this issue focuses on subdomain takeovers, but that’s just the most visible vulnerability class. The same pattern shows up in every place a vendor sits between an organization and its customers.

SaaS misconfiguration on org-owned domains. In 2025, the threat actor group ShinyHunters scanned Salesforce Experience Cloud sites — the customer-portal product Salesforce sells — and extracted records from roughly 400 organizations through misconfigured guest user permissions. The attack didn’t exploit a bug in Salesforce’s platform code. It exploited the way each individual customer had configured the platform that holds their own customers’ data. Salesforce’s response framed the issue as customer-side configuration rather than a platform flaw. At least 14 lawsuits have since been filed against Salesforce over the breach wave. The plaintiffs disagree about who’s responsible.

OAuth integration flaws. In August 2025, attackers stole OAuth tokens from the Salesloft Drift integration and used them to compromise more than 700 Salesforce customer environments, including FedEx, Disney, Google, Marriott, Toyota, and Chanel. The vulnerable integration was Drift’s. The data exfiltrated belonged to each of those customers’ own customers. Every one of those 700 organizations had Drift OAuth tokens in scope for their attack surface, regardless of where the bug technically lived.

Email and messaging systems. The Zendesk case described above is one example. The same risk exists for Intercom, Drift, Freshdesk, Help Scout, and every other support tool that holds customer correspondence on the org’s domain. A bug in the messaging tool is a bug in the brand’s customer-trust surface.

Payment integration. A bug in how a company integrates with Stripe, PayPal, or another processor can let an attacker bypass payment, manipulate amounts, or exfiltrate payment metadata. The hunter who writes as Illoy Scizceneghposter opens their payment-bypass research guide by explaining they had been reluctant to test payment functionality at all — because payment surfaces involve third-party services that often pay nothing. The class of bug most likely to result in actual financial loss to the brand’s customers is also one of the classes most likely to result in zero researcher engagement.

Identity providers and SSO. Misconfigured SSO setups on customer-facing apps can allow account takeover at scale. The vulnerability is often in how the org integrated with the identity provider. The data exposed belongs to the customers.

Marketing automation and analytics. Tools like HubSpot, Marketo, and various analytics SDKs run on the org’s domain, hold customer email addresses and behavioral data, and frequently fall under the same “third party” carve-out. The customer who fills out the marketing form has no idea their data is now in three different vendor systems.

The common thread isn’t the bug class. It’s the position the vendor occupies — between the brand the customer trusts and the data the customer entrusted to that brand.

What the hunters actually say

Hunters have been talking about this in the open for years.

In January 2025, the security researcher who blogs as SirHaxAlot published “Bug Bounty Platforms are a Scam (Mostly)” on Medium. The most damning anecdote: a private program from a large commercial retailer had two contradictory rules — third-party systems were out of scope, and third-party systems without a PoC were out of scope. He submitted a working PoC for a websocket hijack that escalated to admin and exposed user conversations. The company had over 90% of its online surface integrated with third-party systems running on default settings. None of the findings were accepted. Their customers’ conversations were left exposed.

Mike Sheward — who has spent a decade triaging bug bounty submissions on the program side — confirms the pattern from inside the triage chair. His blunt advice to researchers: bugs in third-party products that impact a company are usually not in scope.

Patrik Hudak (0xpatrik), one of the most respected researchers on subdomain takeovers, describes companies as “taking a blindfolded view about the impact” of takeovers in their own infrastructure.

The hunter who blogs as “Friendly” found a subdomain takeover on feedback.owncloud.com — a domain that demonstrably belongs to ownCloud. Bounty: $200, because per the program “ownCloud was out of scope.” Their parting line: “the company has ‘more rights’ to your inputs than you yourself.” The takeover let an attacker host content on ownCloud’s customer-facing infrastructure. The bounty said the work to find that wasn’t worth more. The customers using that subdomain learned nothing about the risk that almost reached them.

These aren’t outliers complaining about edge cases. They’re the people doing the actual work to find what attackers will find next.

The HackerOne problem specifically

If you spend any time in bug bounty discourse, you’ll notice HackerOne shows up in these stories more than any other platform. That’s not coincidence.

In 2022, TechTarget published a long piece on researcher dissatisfaction with HackerOne’s triage and mediation. The on-record sources:

This isn’t just historical. Earlier this week, Lovable — the AI app builder — published an incident retrospective admitting that researchers had filed multiple valid reports about a real data exposure issue through their HackerOne program, and HackerOne triagers had closed those reports rather than escalating them. Lovable is now restructuring their entire HackerOne triage process and retraining triagers from scratch. The data the missed bugs exposed was customer data — chat histories and source code that should have been private.

When the program operator publicly confirms the platform’s triage missed real bugs, you have a system problem, not a one-off. And the cost of that system problem is paid by the customers whose data those missed bugs left exposed.

The platform contradicts itself

Here’s the inconsistency that makes the third-party Not Applicable pattern so obviously broken: HackerOne does pay bounties for vulnerabilities on third-party-hosted subdomains — when the bug class is subdomain takeover. Disclosed examples on HackerOne’s own platform:

In every one of those cases, the vulnerable surface was a third-party SaaS hosted on the org’s subdomain. Bounty paid. Report disclosed. The platform’s triage logic accepts that the subdomain belongs to the org even when it points to a vendor — but only for one specific vulnerability class.

Find an XSS, IDOR, or auth bypass on the same exact subdomain pointing to the same exact vendor? Out of scope.

There is no security reason that subdomain takeover deserves a bounty but a stored XSS on the same vendor-hosted asset doesn’t. Both let an attacker serve content from a domain the org’s customers trust. Both compromise customer data. Both reflect a failure of the org’s vendor management. Only one gets paid.

Meanwhile, Bugcrowd’s own VRT GitHub has had open debates about downgrading subdomain takeovers from base severity P2 to P5 — the lowest tier in their taxonomy. The line is moving the wrong way.

The payment-gateway pattern, in detail

CyberNews researchers reported six PayPal vulnerabilities in 2025 — including a 2FA bypass. PayPal/HackerOne marked them as duplicates and out-of-scope, refused to provide proof of duplicates, and removed the researchers’ reputation points even after the vulnerabilities were patched. The researchers’ summary of their experience: PayPal acknowledged the issues could be used to steal money from people’s accounts, but maintained that everything was out of scope. The bugs were patched. No bounty. No credit. No public disclosure of what could have happened. The customers using PayPal had no way to know any of this happened.

In 2013, Robert Kugler — a 17-year-old who found a critical bug on PayPal’s site — was denied a bounty because PayPal said he was too young to participate.

In November 2024, the security firm Trust Security reported a critical Web3 vulnerability through Immunefi that allowed live, unauthenticated theft of funds. Immunefi ruled it out of scope and offered only a “goodwill bounty.” Trust refused, citing transparency concerns, then went public on X. Immunefi suspended Trust Security from the platform. The bug allowed live theft. The platform’s response was to remove the people who reported it.

This is what the broken incentive looks like in practice: the highest-impact research areas are the ones hunters are systematically discouraged from doing. And the customers — the ones whose actual money the actual bugs could have actually stolen — never even know the discouragement happened.

Meanwhile, in the real world

While the bug bounty industry has been refining the art of the third-party Not Applicable, the courts and the breach reports have been moving in the exact opposite direction.

The Salesloft Drift breach already mentioned hit 700+ organizations. The Salesforce Experience Cloud wave hit roughly 400. Snowflake had its own version of this story in 2024 — AT&T, Ticketmaster, LendingTree, Advance Auto Parts, Neiman Marcus, and others were breached through Snowflake-hosted environments. Snowflake said the issue was customer-side credential hygiene. The customers paid the settlements anyway.

And, as already mentioned, Discord was eventually breached through Zendesk — the same Zendesk that paid hackermondev nothing for the bug that demonstrated the pathway.

The pattern is consistent. The third-party CNAME, integration, OAuth flow, or SaaS misconfiguration leaks customer data. The brand on the login page takes the regulatory hit, the lawsuits, and the press coverage. The vendor offers thoughts and prayers. The customers who never asked to know the vendor existed are left to deal with the consequences — fraud alerts, identity theft monitoring, credit freezes, and the long tail of risk that follows a leaked PII record around for years.

Vendor selection is a security control. Vendor risk management is the org’s job. The bug bounty programs that pretend otherwise are pretending alone.

Microsoft just changed sides

On December 11, 2025, at Black Hat Europe, Tom Gallagher — VP of Engineering at Microsoft Security Response Center — announced a policy change called “In Scope by Default”.

The new rule: any critical vulnerability with a direct, demonstrable impact on a Microsoft online service is eligible for a bounty. The code’s owner doesn’t matter. Microsoft will pay for vulnerabilities in third-party commercial software, in open-source libraries, in dependencies — anywhere the impact lands on Microsoft’s services, and therefore anywhere the impact lands on Microsoft’s customers.

Microsoft paid out more than $17 million in bounties in 2024 and explicitly expects that number to grow under the new policy. The rationale Gallagher gave is the same one hunters have been making for ten years: attackers don’t care who wrote the code, so the bounty program shouldn’t either. The customer doesn’t care either. They just want their data not to leak.

This is the largest software vendor on the planet — the same vendor whose old M365 carve-out is quoted earlier in this post — publicly conceding that the bug bounty industry got third-party scope wrong. Not a quiet policy update. A Black Hat keynote.

Every program that still closes “third-party impact on customer data” reports as Not Applicable is now lagging behind a Microsoft policy.

The cost is paid by the customers

When organizations close third-party-asset reports as Not Applicable, hunters stop submitting them. The vulnerabilities don’t go away — they just stop appearing in the queue, until someone less ethical finds the same hole. By the time it surfaces again, it surfaces in a breach notification.

The Zendesk → hackermondev → Discord chain is exactly that pattern playing out from start to finish. The bug was reported. It was dismissed. It was eventually fixed under pressure, with no bounty. The downstream breach happened anyway. Real Discord users had their data exposed. Nobody who’d been paying attention was surprised.

The customers don’t read bug bounty policies. They don’t know which subdomains are CNAMEd to which vendors. They don’t know that the part of the platform handling their support ticket is in scope for bounties but the part handling their identity verification isn’t. They trust the brand on the login page.

When that trust gets violated by a vendor, the customer’s loss is the same regardless of whose code was at fault. The bug bounty programs that built carve-outs for the vendor surface are not insulating themselves from that loss. They’re just making sure the loss happens after the customer has been hurt instead of before.

“But we don’t control the vendor’s code”

This is the standard rebuttal, and it doesn’t survive contact with the actual mechanics of running a business.

You chose the vendor. You CNAME’d your subdomain to them. You handed them your customer data. You decided which contract to sign and which security posture to accept. The vendor selection is your security control. It’s the whole control.

The vendor can fix the code. The org owes the researcher the report, the credit, and a bounty for finding it — because the alternative is sitting on a known weakness in your customer-facing surface until an attacker lands on it. If you genuinely can’t pay full bounty for vendor-side findings, the minimum acceptable response is partial credit, public acknowledgment, and a documented escalation to the vendor. Not Not Applicable.

A vendor who keeps producing vulnerabilities you can’t get fixed is information about that vendor. Use it.

What programs should actually do

Three things that aren’t difficult.

Treat findings on org-owned subdomains as in-scope by default. Microsoft just did this. Follow suit. If the asset resolves under your domain, the bug is yours, regardless of who hosts the backend. Your customers don’t see the vendor. Your bounty scope shouldn’t pretend otherwise.

Pay something, even if you forward upstream. A partial bounty or a documented Informative-with-credit beats Not Applicable every time. The reason isn’t to make researchers happy — it’s to keep the disclosure pipeline open, so the next vulnerability gets reported instead of getting found by an attacker.

Be explicit and consistent. If you’re going to exclude a class of bug, say so up front, and don’t reverse the logic for the bug classes that happen to be cheap. The Bugcrowd VRT debate to downgrade subdomain takeovers to P5 is the wrong direction. The HackerOne disclosure pattern of paying for takeovers but Not Applicable-ing other vulns on the same vendor surface is the wrong direction. Pick one rule and live with it.

Close

This is not really about bounty payouts.

The bug bounty industry has spent a decade telling researchers that the third-party CNAME at the edge of an organization’s attack surface is somebody else’s problem. Customers don’t see somebody else. They see the brand. The data they entrusted to the brand ends up in dumps and breach notifications either way, and the brand takes the lawsuits either way, and the customer’s pain is the same either way.

If your subdomain points to a vendor, and that vendor’s vulnerability exposes your customers’ data, the vulnerability is yours. The bounty should be yours. The accountability is already yours, whether you accept it or not.

I do bug bounty after work because I have been on the receiving end of those breaches. The motivation is not the payout. It is knowing that for every bug a researcher reports and a program takes seriously, there is a customer somewhere whose data did not end up in someone else’s hands. That is the core job of a security practitioner — keep data safe, keep people’s PII out of harm’s way, look out for the users who do not have the technical literacy to evaluate the vendor stack behind the brand they trusted.

Programs that close vendor-side reports as Not Applicable on the part of their stack their customers can’t see are choosing, knowingly or not, to take that protection away.

The cheapest way to find out which of your vendors is going to expose your customers is to pay attention to the people who keep telling you. The most expensive way is to keep closing their reports and waiting.

— Juliano Da Costa. Find me on X: @jdonsec.