On 22 July I got this email from Bugcrowd:
Your request for a response expired without an answer for the following submission:
[title redacted]
Request reason: Duplicate state Request expired on: 22 Jul 2026 20:32:24 (UTC) Requests available: 1 out of 2
I’ve redacted the submission title. This post isn’t about that finding.
By then, I had been waiting three weeks for someone to address the question I had raised about the duplicate verdict.
I had replied in the submission itself first, and waited a week. Then I used Bugcrowd’s official “request a response” feature and waited another 14 days. Nothing in the email addressed the question. It just told me that my request had expired and that I had my slot back.
A few days later, the same thing happened with a second report on a different program.
I may be wrong about both duplicate verdicts. Bugcrowd may have perfectly good evidence that I cannot see. That’s why I asked.
Disputing a duplicate
I’ve had reports marked as duplicates before. On HackerOne, I’ve had quick responses, and when they told me I had duplicated an earlier finding, they were right: I simply hadn’t found something novel. No complaint there.
I don’t think every duplicate verdict is suspicious, and I don’t expect Bugcrowd to show me another researcher’s confidential submission. But Bugcrowd does show some information about the report you’re duplicated against, and in these two cases, what I could see appeared different enough from what I had reported that I thought the decisions deserved another look.
So I replied and explained why. I did not immediately use the escalation mechanism; in both cases I raised the issue in the submission first and gave the triager time to respond. When that produced no answer, I used the feature Bugcrowd provides for exactly this situation: “request a response.”
Both requests eventually expired without one.
For what it’s worth, the same Mattermost program rewarded a different finding of mine. This isn’t about not getting paid, it’s about not getting answered.
Case 1: 21 days
Bugcrowd marked my Mattermost submission as a duplicate on 30 June. Based on the information I could see about the earlier report, I believed it described a different vulnerability.
On 1 July, I replied in the submission and explained why. I also made the limit of my knowledge explicit: if there was an earlier report that actually covered the same issue, I was happy to accept the duplicate. I asked Bugcrowd to check.
Nobody replied. I waited seven days.
On 8 July, I submitted a formal response request with the reason “Duplicate state.” I explained the disagreement again and asked Bugcrowd to verify that the report I had been duplicated against actually covered the same issue. Then I waited another 14 days.
On 22 July, the system marked the request as expired. There was still no response.
From my first objection to the expiry, 21 days had passed, and I still didn’t know whether anyone had even looked at the disagreement.
Case 2: 18 days
The second case, on the ClickHouse program, followed almost the same sequence, but the report was significantly more serious: my reproduction demonstrated a path from a low-privileged user to a persistent administrator account.
Bugcrowd asked me for a complete reproduction package that would work on a default Docker setup: a compose file, a walkthrough, and scripts. I built it and sent it. The next day, the report was triaged and then marked as a duplicate.
Based on the information shown for the earlier report, I believed the two findings involved different access-control failures and would require different fixes. I replied that same day and explained why. I wasn’t asking them to take my word for it. I asked them to compare the two reports, which they could see and I could not, and confirm whether the earlier submission actually covered what I had reported.
Nobody replied. I waited four days.
On 11 July, I used “request a response” and asked again. Then I waited another 14 days.
On 25 July, the request expired. No response. The same email, for the second time:
Your request for a response expired without an answer for the following submission:
Low-privileged user gains admin SQL execution & full data read (+ persistent backdoor) via [mechanism redacted]
Request sent to Bugcrowd
Request reason: Duplicate state Request expired on: 25 Jul 2026 (UTC) Requests available: 2 out of 2
I’ve redacted the part of the title that names the mechanism, because the issue is still unpatched. The impact is quoted as I wrote it in the report.
Note the last line. Both of my request slots are now free, which is the only thing that changed.
From my first objection to the expiry, 18 days had passed. Once again, I had no way of knowing whether anyone had actually compared the two reports.
Two programs, two triagers
These were different programs and different triagers. That’s why I’m not naming either triager: I don’t know enough about what happened internally to blame either individual. People miss things. People get overloaded. There may also be limits on what a triager is allowed to disclose about another researcher’s report.
What I can see is the process I interacted with. In both cases I received a duplicate verdict I had concrete reasons to question. In both cases I explained those reasons in the submission itself. I waited. When nobody answered, I used Bugcrowd’s formal mechanism for requesting a response.
Both requests expired without one.
Severity doesn’t seem to change the path
There is an important difference between the two cases.
The Mattermost finding was rated P3. The ClickHouse finding demonstrated a path from a low-privileged user to a persistent administrator account, and I argued that the report I had been duplicated against did not appear to cover that escalation.
The earlier report may contain exactly the same impact. That was the question I was asking Bugcrowd to check.
I want to be careful about one thing here. The fact that the issue is still unpatched does not, by itself, make the duplicate verdict wrong. Patching takes time, and a report can be a genuine duplicate while the fix is still in progress. But it does speak to what is at stake: when I published this post on 28 July 2026, the fix had not landed on ClickHouse’s public master branch. This is not a theoretical or already-resolved issue. It is a live, unpatched access-control bypass that I reported with a working reproduction, and the mechanism for questioning its classification produced no response.
From my side, however, the dispute followed exactly the same path as the P3 Mattermost report. I replied in the submission, waited, requested a response, and waited for the same timer to expire.
I don’t know what ClickHouse itself was notified about, or what anyone on their side could see internally, so I don’t want to speculate about that. What I do know is that the process available to me produced no response to a disputed duplicate involving a claimed administrator takeover.
That worries me more than the silence on any single report.
Triage exists for a good reason. Someone has to filter invalid reports, reproduce findings, identify duplicates, and keep obvious noise away from the people who eventually have to fix things. But that also makes a wrong duplicate decision consequential.
If a report is incorrectly classified as already known, there needs to be a reliable way to challenge that decision. And if the disputed report describes a potentially serious compromise, I would expect that challenge to receive more urgent attention than an ordinary classification disagreement.
I saw no sign of that here.
What happens while you wait
I don’t know whether any of this is intentional, and I have no evidence that it is. I can only describe the process from my side.
You receive a decision you think may be wrong, so you explain why. You wait. Nothing happens.
You use the platform’s formal mechanism for requesting a response. Bugcrowd allows each researcher to have two response requests open at once, so submitting one occupies half of that account-wide quota until someone answers or the request expires.
Then you wait another two weeks.
During that time, you start wondering whether you’re the problem. Maybe the duplicate is obvious from something you can’t see. Maybe you’re wasting people’s time. Maybe there is a perfectly good reason nobody has answered yet. Maybe pushing again would just make you look difficult.
Then the timer runs out.
The dispute hasn’t been resolved. Nobody has explained the decision. You don’t know whether your objection was reviewed.
You just get your request slot back.
I don’t think that’s a useful dispute process.
What Bugcrowd originally promised
When Bugcrowd introduced Request a Response in May 2023, it described the feature as a solution to comments and questions going unanswered. Bugcrowd said a response was “ensured within 48–96 hours” and ended the announcement by promising “guaranteed responses.”
That changed in November 2025. An unanswered request now expires automatically after ten business days, and the occupied request slot is returned to the researcher. That is what happened to both of mine.
The expiry behavior is documented. What I don’t understand is how it serves the feature’s original purpose: a mechanism introduced to prevent questions from going unanswered can now end with no answer at all.
What I would change
I don’t expect Bugcrowd to reopen a report every time a researcher disagrees with a duplicate.
I would change four things:
- A response request should require a response. The answer can be “we reviewed this and the duplicate stands.” But the mechanism should not be able to end because nobody responded before the timer expired.
- A contested duplicate should get a minimal explanation. Nobody needs to reveal the confidential report. A sentence confirming that the same underlying issue or root cause is covered would be enough in many cases.
- There should be a way to ask for a second look. When a researcher gives concrete reasons why two reports may be different, someone other than the original decision-maker should be able to review the disagreement.
- The escalation path should take severity into account. A disputed duplicate involving a credible administrator compromise should not quietly follow the same path to expiry as a routine classification disagreement.
The researcher does not need to come out of that process with the decision they wanted. They should come out of it knowing that someone considered the disagreement and answered it.
Why I’m writing this
I may be wrong about both duplicate verdicts. Bugcrowd may have perfectly good evidence that I cannot see.
I used the mechanism they provide to ask.
It expired.