If you spend any time doing security research or submitting bug bounty reports, you quickly realize that the hardest part of the job isn't breaking into software. The hardest part is convincing a first-tier triage reviewer that a fundamental architectural flaw is actually real.

Case in point: a recent report I submitted for a U.S. university with multiple production and staging environment APIs.

What should have been a straightforward, goodwill heads-up regarding a severe resource exhaustion vector was closed in less than 20 hours with the classic, mindless copypasta: "We believe this issue to be a false-positive and as such, are closing this report."

Let us break down how an obvious application-level vulnerability gets labeled a "false positive", and why this trend is actively destroying the goodwill that keeps bug bounty ecosystems alive.

The Vulnerability: 13-Second Thread Hogs

While conducting standard reconnaissance on the university API target, I noticed a consistent, broken pattern across their development, staging, and production gateways.

Whenever a client hit unrouted or misconfigured API documentation endpoints (specifically missing /swagger/*.json files), the backend didn't return an immediate 404 Not Found. Instead, the server held the connection open for roughly 13 seconds before finally throwing a 504 Gateway Timeout.

HTTP Code: 504 | Time: 13.353s

From an application architecture standpoint, this is a massive red flag.

If an endpoint locks up a backend worker thread for 13 seconds for every unauthenticated incoming request, you don't need a massive botnet to bring the API to its knees. A single laptop running a simple loop of concurrent requests can rapidly exhaust the target's backend connection pool. It is a textbook Application-Level Denial of Service (Resource Exhaustion).

Knowing that generic DoS reports are often explicitly out of scope, I clearly flagged this as a goodwill report. I wasn't asking for a massive payout—I was pointing out a glaring configuration flaw that a malicious actor could exploit with zero effort using basic command-line tools.

The "False Positive" Copypasta

Here is where the triage circus begins.

Less than a day later, the report was marked as "Not applicable" with the following response:

"We believe this issue to be a false-positive and as such, are closing this report. Your effort is appreciated... If you still believe this to be a valid submission, please submit a new report which includes detailed information demonstrating and exploiting the security impact..."

Let that sink in.

A "false positive" implies that the reported behavior does not exist—that the scanner or researcher hallucinated the output. But a 13-second connection hang on a public API is a measurable, reproducible fact. You can verify it with a single curl command.

Calling a reproducible 13-second thread lock a "false positive" reveals one of two things:

1. The triager did not read or understand the report.
2. The platform uses automated macro-responses to clear ticket queues without evaluating technical context.

Telling a researcher to "demonstrate and exploit the security impact" on a DoS report is even more absurd. They are essentially asking you to actively degrade or crash their client's production environment just to prove that holding worker threads open for 13 seconds causes resource exhaustion.

Why Goodwill Reports are Dying

Bug bounty programs rely on a delicate contract: researchers provide free or low-cost intelligence on flaws that automated scanners miss, and platforms evaluate those findings with basic professional competence.

When triage teams treat legitimate, reproducible edge-case findings with copy-pasted dismissals, researchers simply stop submitting goodwill reports. Why spend 30 minutes documenting a subtle architecture flaw if a reviewer is going to mark it "N/A" in 30 seconds without reading past the title?

Platforms need to start holding their triage operations accountable. If an issue is out of policy scope, mark it as out of scope and explain why. But dumping valid, reproducible technical findings into the "false positive" wastebasket isn't triage—it's just laziness disguised as workflow management.