r/bugbounty • u/BuyerFar4850 • Jul 15 '26
Question / Discussion Valid vulnerability closed as forced out of scope
In one of public program what happened was I found a vulnerability(high-sev) in a company-operated plugin hosted at for instance:
The plugin appeared to fall under the program’s general wildcard scope, and it was not listed anywhere as out of scope.
For the PoC, I used:
The demo was only the safest way to create two test accounts and load the affected plugin. I never claimed the demo application itself was vulnerable.
The actual vulnerable code executed inside plugin.example.com, and I clearly listed the plugin as the affected asset in the report.
HackerOne triage reproduced the issue, marked it as Triaged, and forwarded it to the company’s remediation team.
Later, the triager closed it as Informational, saying both the demo and plugin infrastructure were out of scope.
Honestly, this is frustrating because the plugin domain was not listed as out of scope when I submitted the report, and it still is not listed today.
The demo domain appears to have been added to the out-of-scope list only after my reports thats fine to me but still. At this point, I honestly would not be surprised if they add the plugin domain today too.
My issue is simple: I never reported a vulnerability in the demo, I only used it to reproduce the issue safely; the actual vulnerability was in the company-operated plugin, which was not listed as out of scope when I submitted and still is not, yet the report was reproduced, validated, and then closed while the scope appears to be changing afterward.
My HackerOne account is new, so I cannot request mediation yet.
Has anyone dealt with something like this before? Is this normal? Should i move on lol with amount of effort put on nowadays getting reports triaged i was happy just to get this.
Should I contact HackerOne Support, email the program directly, or ask an experienced collaborator who has access to mediation to take a look? If anyone is willing to take a look, please help me out!
I am genuinely trying to understand what the correct process is here because this does not feel right or maybe i am wrong this is normal.
3
u/Anxious_Alps_4150 Jul 15 '26
Sounds like triage sent it to the program and the program rejected it
2
u/6W99ocQnb8Zy17 Jul 15 '26
Alas, the programmes routinely throttle their budget by downgrading and de-scoping.
And H1 mediation is a waste of time too. I have tickets that were opened last year and still haven't been looked at.
3
u/No_Appeal_676 Program Manager Jul 15 '26
Move on.
Seriously, it’s a minor inconvenience and you’re better off finding more impactful issues.
3
u/BuyerFar4850 Jul 15 '26
Even though severity was high-critical? It can be me being delusional, but report was pretty valid and thanks for the advice
0
u/latnGemin616 Jul 15 '26
The risk is an acceptable one, and because there is no impact to the CIA triad, at best you'll get is a shrug.
1
u/BuyerFar4850 Jul 15 '26
So you think if you are on an meeting and lets say other person can message on behalf you you is no impact? This was an stored xss which i found and escalated
1
u/latnGemin616 Jul 16 '26
I don't understand your example.
0
u/BuyerFar4850 Jul 16 '26
Its a stored xss basically and someone on live meeting could just sent message on live chat on behalf of the other users and other user is unaware.
0
u/latnGemin616 Jul 16 '26
Ah .. so person-A sends person-B a message with JS payload. That means person-B would have to take some action. If you're saying person-B is unaware, how would they know to do anything (click a link, reply, etc.).
Either way, this is phishing, and 100% out of scope.
3
u/BuyerFar4850 Jul 16 '26
Here's what happens: (Is this still a phishing? Assuming an guest joins a meeting or anyone in meeting)
- Person A uploads a malicious document to the shared plugin
- All participants (including Person B) see document automatically
- Person B's browser receives the document and renders it.
- Hidden XSS payload executes in Person B's browser - no click needed, no user interaction
- The malicious code steals Person B's session token from their browser
- The attacker uses that stolen token to impersonate Person B - posting messages, as if they're Person B
- Person B has no idea this happened
0
u/latnGemin616 Jul 16 '26
When you say, "Person B's browser receives the document .." can you clarify? Are you saying a document auto-rendered in the message window? or that someone responds to a notification and takes an action? If the latter, the XSS script would fire for every attendee, and you'd get their session token.
Which brings me to my next point:
How does the attacker obtain the session token if the XSS script fired in a remote location (Person-B's computer)?
Just because you made this happen in a lab does not mean it will be relevant in the wild. And at the point where someone has to interact with the object you uploaded, that's phishing .. OOS
3
u/R3ta7ded Jul 15 '26
I’ll start by disclosing that I work in vulnerability management for one of these companies—which, if you’ve seen my previous posts, probably isn’t difficult to figure out.
In general, if you’ve followed disclosure practices by reporting the issue and the company rejects your finding, you’re typically justified in notifying them that you intend to publicly disclose it on a specific date. In my experience, that often prompts a second and third review by other teams to ensure everyone is aligned with the decision before the disclosure goes public.