ZERODAY CLOUD 2026, which is run by Wiz, is targeting vulnerabilities in critical open-source software used across cloud infrastructure, with AWS, Microsoft Security Response Center and Google Cloud Security involved. The event is tied to Black Hat Europe and has a prize pool just under $6.5M
Hi everyone.
I found an XSS and extended it to a full CSP bypass. Reported it on h1 and it got automatically closed by a hackerone-agent bot without any human review as a duplicate of a 5 months-old N/A issue. The current bug is live, report is human-written, video PoC is attached. Is there a way to request a human review or my only chance is to wait for mediation?
Thank you!
This is a fresh account for a reason. I've heard from other researchers that criticizing Intigriti on Reddit can lead to retaliation in how their reports are handled. I can't verify that firsthand, but I'm also not willing to test it with my main account.
Has anyone else been seeing wildly inconsistent triage lately?
Right now it feels like Russian roulette. Either you get a reasonably consistent triager who runs the PoC, asks for what is actually missing, and bases the decision on the evidence, or you get someone who decides in advance that any automation is *AI slop* and then simply denies the reality in front of them.
It feels like there is an internal anti-AI backlash, but with no consistent standard behind it. Some triagers assess automated PoCs normally. Others refuse even to run a self-contained Python file, demanding that everything be recreated manually in Burp.
This week I had two serious vulnerabilities, both with working PoCs and demonstrated impact. Both reports followed exactly the same pattern:
The triager refused to run the Python script and asked for manual steps.
I provided the steps plus a video showing the entire **MANUAL** process, from start to final impact.
Even then, they said they could not reproduce it.
The report was invalidated.
Company remains vulnerable.
I'm not defending unvalidated automated reports or giant scripts that nobody can reasonably audit. The issue is different: a deterministic PoC does not become invalid because it was written in Python, and a vulnerability does not disappear because the triager would rather click through every request in Burp.
At some point, this stops being healthy skepticism about AI and starts looking like denial of reality. Automation is part of modern security research. The standard should be: does the vulnerability exist, can it be reproduced, and does it have impact? Not: which tool sent the requests?
It is hard not to speculate about what is happening internally. Maybe there is an informal directive to crack down on anything that appears to involve AI. Maybe it is pressure from the volume of bad reports. Maybe it is an attempt to prove that human triage remains indispensable. And perhaps some triagers are reacting defensively because AI is already automating part of their work and there is a genuine fear of losing their jobs. Honestly, I can understand that insecurity. The entire market is changing. What I cannot accept is professional insecurity becoming a technical standard and reproducible evidence being dismissed by association with AI.
The irony is that [Intigriti itself promotes Triage Assist](https://www.intigriti.com/blog/product-updates/how-triage-assist-is-raising-the-bar-in-crowdsourced-security), a suite of AI tools that recommends decisions to triagers. So AI can help the platform evaluate our reports, but a researcher using automation makes a working PoC suspicious?
I've been seeing more and more reports of decisions like this, and it feels uncomfortably similar to the Lovable/HackerOne incident. Not because the technical details are identical, but because [Lovable itself acknowledged](https://lovable.dev/blog/our-response-to-the-april-2026-incident) that several valid reports were closed at triage and never reached its internal security team. The vulnerability only received the attention it deserved after the issue became public.
Is anyone else dealing with this on Intigriti? Is there a clear policy on scripts and AI-assisted PoCs, or has triage really become Russian roulette depending on who gets the report?
Hey everyone,
I submitted my first report on Intigriti recently and I'm a bit confused about how to handle this situation.
I reported a solid Blind SQL Injection vulnerability. I provided a full PoC including:
Proof of the vulnerability (100% confirmed).
Extracted database name.
Dumped schema showing sensitive columns to prove the impact.
Just a day after submitting, the vulnerability was completely fixed on the target application, but there is zero response on my report. No triage update, no status change, and no reply to the follow-up comment I left asking for an update.
Since I fully proved the impact and they clearly used the report to patch the issue, why is there complete silence? Is it normal for programs on Intigriti to patch issues silently before updating the triage status?
What’s the best way to escalate this with Intigriti support? Thanks!
I reported a vulnerability on H1 and it passed the first bot check, then after about 15 days an H1 analyst reached out and asked about further demonstration, we went back and forth and then he asked me to check if it still works on the latest version (this was for an opencore program and this version hadn't come out when I first reported the vuln, my report demonstrated the vuln on the latest version at that time), so I did so and sure enough the vuln still worked but in this new latest version they had tried to patch part of the primitive but failed to do so, so part of my argument for the vuln in the initial report was no longer true and I pointed that out and explained the change, the analyst told me he'll discuss it with the program team internally and get back to me, then a few days later it got marked as a duplicate, this was confusing to me because I assumed if an H1 analyst validated the bug it's just a question of severity then, I don't understand how they couldn't tell whether or not it was previously reported, the bug could have been reported in the initial version as my report before I did, which lead to the patch while my report wasn't triaged yet but then you'd expect mine to be marked as a duplicate immediately, it might be possible that it has been reported on both versions separately before my report was triaged and the dupe refers to the first version but then why would I be asked to see if it applies to the latest version as well? I'm just really confused by this whole ordeal, and of course they won't add me to the original report, is there anything I can do here?
Hey everyone,
Been testing a program lately The scope page only excluded Contributor/Light Agent issues and Admin impersonating users via API tokens Agent-level privesc wasn't mentioned anywhere.
Submitted 6 reports escalating privileges from an Agent account 2 came back Informative 4 OOS.
Opened a "Request a response" to ask for clarification since it wasn't clearly excluded
Has anyone dealt with something similar? Is it even worth pushing back or should I just move on?
I'm a noob trying to get into bug bounty hunting and a lot of people have expressed how important documentation and Proof-of-Concept is just as important as the vulnerability found. I always see posts about hunters getting feedback such as "you didn't show POC clearly" or "your POC is not valid". My question is, why not screen record the whole process and add documentation as a supplement? Is it not allowed? If it is allowed, wouldn't it makes everyone's life much easier (person that triages & hunter)?
A lot of these programs are going away, due to people flooding them with low quality reports. Was fun while it lasted.
Most of the IDOR advice out there boils down to "change the number in the URL." That catches maybe the easiest 10% of what's actually there.
The question that's actually moved the needle for me: "Who is supposed to reach this resource, and who can actually reach it?" Every access control bug — IDOR, broken function-level auth, privilege escalation — is a gap between those two answers. The ID or cookie or header is just the mechanism the gap happens to travel through.
A few patterns I keep running into that don't get talked about much:
- Multi-step forms that check auth on step 1 and never re-verify on steps 2-3
- Bulk/batch endpoints that check ownership on the first ID in an array and stop there
- API version drift — /v1/ enforces the check, /v2/ quietly doesn't because the check lived in the route handler, not a shared layer
Also something that took me a while to internalize: the exploit request rarely confirms itself. It's often a bare 302 with an empty body, not a helpful "success, you're admin now!" message. The signal is usually in what you sent, not what came back — and often only shows up when you compare two consecutive requests of the same shape.
Curious what patterns other people here run into most often that aren't in the "standard" IDOR writeups.
Has anyone had a YesWeHack/MangoPay withdrawal returned by their bank?
My Indian bank account received the transfer, but the bank is holding it due to insufficient purpose-of-remittance information. If bank returns the payment, will it automatically be credited back to my YesWeHack e-wallet? If this happened to you, how long did it take?
Thanks for your time.
Back in April I reported a bug to Binance's bug bounty program on Bugcrowd. It got triaged on May 5 and the fix was merged just 2 days later on May 7. It's now been 158 days with no monetary reward decision.
What I got instead:
- Five identical boilerplate holding responses over 5 months
- A RAR filed 45 days ago with zero Bugcrowd response
- Submission marked Resolved with only 5 auto-assigned points
- A commitment on August 26 to update severity after internal assessment which ofc didn't amount to anything
I've gone through every escalation path the platform offers. Has anyone dealt with Binance's program specifically taking this long? What actually moved things for you?
Hey folks, when a program has no wild card in scope items, but without adding any particular subdomain they add "example.com" that means other subdomains all are out of scope? and basically only www.example.com is in scope?
I a bit confused!
Almost half a month ago i submitted a report to a program on cantina i set the severity as high (remember this) then almost a week later the triager asked for a few extra things to continue the triaging i had some of the files he asked for but some i didn't had i honestly accepted that and in a later comment on the report i gave everything i had and also asked that i would be willing to downgrade the severity to medium(but i didn't change the original high) then few days later he marked my report as a duplicate of a rejected finding (as you can see the status of the report if it was rejected) not only this but he also upgraded the severity to critical now i was so confused and i submitted a ticket to cantina support team and also mailed them but 6 business days later no response had came yet i am seeking help or advice on this situation please yelp!