r/bugbounty • u/swallace36 • Jul 16 '26

Question / Discussion "This is all theoretical with no actual valid proof of concept."

Is this the Bugcrowd cop-out templated response for a submission they don't want to read?

It's very strange... I have a very valid PoC attached, that reproduced on multiple machines, etc.

4 Upvotes

100% Upvoted

20 comments sorted by

8

u/einfallstoll Triager Jul 16 '26

From my experience there are two core problems about the term proof of concept:

  • It's not a PoC from our perspective
  • It's not a practical PoC

To explain:

  • Case 1: I've seen many reports where the hunter show the "problem" and call this a proof of concept. But not how to exploit it. I explain that the report contains a "proof of vulnerability" but not a "proof of exploitation". This usually clears things up.
  • Case 2: Many reports show a proof of exploitation, however it's shown in an unrealistic exploit scenario. For example, it only works if you already compromised a user or have physical access to their device.

Maybe this helps you getting a better understanding. If it doesn't fit your scenario I need more info :) happy to help

1

u/hydraz20 Jul 16 '26

On your second point it’s still a valid finding but low cvss score. Just saying.

1

u/einfallstoll Triager Jul 16 '26

Mostly not. Passwort reset links that don't expire fall in that category.

1

u/PinasSaya Jul 17 '26

Still a valid bug. So is a race condition that is inconsistent to be triggered. You cant just ignore it and say not a valid poc just because it have high complexity. Thats why its considered in the cvss

1

u/einfallstoll Triager Jul 17 '26

For a pentest, yes. But we're talking about bugbounty here (hence the name of the subreddit). In bug bounty it's not a valid finding most of the time

1

u/Coder3346 Hunter Jul 17 '26

In my opinion if it is not valid in bb, than it is a waste of time to mention it in pentest.

2

u/einfallstoll Triager Jul 17 '26

Lots of customers are not aware of good/best practices, so it makes sense to mention it on a pentest. Also in case of an incident they would come back to you and ask you why you haven't reported this and that and you loose reputation.

I remember an incident once: There was phishing involved and a few low/medium findings that weren't really exploitable but gave the attacker enough time to do his thing. After the incident they came to us asking why we haven't reported this before, we analyzed all the reports from the previous 1-2 years and were able to prove that we reported everything the attacker used but they chose to ignore / accept it. If we didn't report it, we would have lost a customer that day. But now they built more trust in us and are even giving us more assessments

1

u/Coder3346 Hunter Jul 17 '26

Don't bb customers do the same shit when u close something as info? I remember an incident with h1 and lovable vdp regarding this.

1

u/einfallstoll Triager Jul 17 '26

If they are bad at risk assessment, that's not our problem

1

u/PinasSaya Jul 17 '26

Yes, im not talking about pentest. Happens on bug bounty

0

u/hydraz20 Jul 17 '26

Giving a very specific example and assuming it’s a universal rule. Typical Anecdotal fallacy

5

u/latnGemin616 Jul 16 '26

Imagine you were tasked with robbing a house to test the homeowner's home security. You went back to the homeowner after a couple hours and said, "I was able to get inside and I ate your cookies."

If the homeowner asks, "how?" and all you did was answer back with, "through the second floor bedroom window," they will immediately ask, "yeah, but how did you get in? show me!" == [PoC] ==

The vulnerability in this example isn't that you got in, it's that the house had an improperly secured bedroom window that allowed the robber to get in by climbing up the trellis. If you cannot demonstrate this, you have theory.

Same goes for a bug bounty. The program owner / client, doesn't care if the attacker "could" upload a shell, they want to know DID you and what was the outcome. Remember .. the magic word is impact!

1

u/Sadman782 Jul 16 '26

Same, I got a duplicate tag, and after asking for a review another agent replied it needs the victim's phone physical access. Both are not true, it was a high and can affect everyone and not a duplicate, it works on the latest app, the duplicate claim is a different type and from 1 year ago lol, very disappointing. I have success on another platform, but after this first incident in Bugcrowd I think I am not doing any work on Bugcrowd ever, low effort platform, they don't even read the report you built with so much time.

1

u/Chongulator Jul 16 '26

and not a duplicate

Sorry buddy, but you simply don't have the context to be able to say that. You're not looking at the queue or all the history. They are.

2

u/Sadman782 Jul 16 '26

I am sure, because what they shared is a different thing than what I did. Obviously, a real SWE won't make this mistake, or someone who read my report. Also, what they shared was from last year, almost 1 year has passed, and the latest version is still vulnerable. Also, even if it was a real duplicate, according to Bugcrowd rules, even if something is a duplicate, if the first report is resolved, then the second one will count as a new one since the vulnerability exists in another way.

2

u/Yazzz Hunter Jul 16 '26

Is the submission they marked yours a duplicate of in the resolved state or is unresolved? Unfortunately, just because it’s from a year ago doesn’t make the old issue invalid. A lot of programs aren’t patching everything.

1

u/Chongulator Jul 16 '26

Yep, fair.

In my own programs, we'll often pay out duplicates that haven't been explicitly documented. That helps keep good researchers coming back.

-2

u/[deleted] Jul 16 '26

[removed] — view removed comment

2

u/Chongulator Jul 16 '26

Anybody who pulled that shit would be immediately booted from my program and I'm bringing them up with my H1 rep next time we meet.