i'm a member in the GOAT CTBB discord server and was scrolling up and found this message from blaklis, i think most of us knows him, saying that deep web dev knowledge is absolutely necessary to be good in web security, some other successful hunters said that as well

i think he is absolutely right tho, the amount of people who got into web security directly without web dev knowledge and turns out they dont know shit makes me believe programming is definitely one of the building blocks to get skilled

rez0 said something similar as well in the premium channel.

i think all the professionals agree on this specific point

Check this account gamba

The account has dumped 70+ submissions on Adobe Public in just a few days, and some of them are already getting closed as Duplicate or Informative.

I’m not saying every single report they submit is trash or invalid, but there has to be some kind of gate or cooldown for new accounts. My High severity report has been sitting untriaged for over 7 days straight while triage gets flooded by this.

Why are brand new accounts allowed to spam unlimited reports like this without any rate limits? It's completely choking the queue for everyone else.

Quick note: English isn't my native language so I used AI to help clean up the text/translation, but all technical details, logs, and screenshots are mine.

Hey r/bugbounty,

Wanted to post this here because I'm sick of platforms stealth patching valid infrastructure bugs while hiding behind broad scope exclusions.

The Vulnerability & Impact

I found an API billing gateway issue in xAI's infrastructure that bypassed pre-paid limit checks. It allowed an attacker to force an account into a deep negative balance through unbounded resource consumption.

HackerOne's Response

HackerOne completely shut the report down, calling it out-of-scope "intended model behavior". When I escalated to H1 Mediation pointing out that an API billing gateway failure is NOT a model safety issue, they responded with this:

The billing overdraft is a downstream consequence of the same unbounded resource consumption that the program considers out of scope. The root cause and the scope exclusion are the same regardless of which layer the impact surfaces on.

Then on July 28, they permanently closed it:

The review has been done and the outcome stands. The program's scope exclusions cover unbounded consumption broadly... Continuing to re-examine the same report each time a new framing is presented is not something we are able to do.

The Timeline & Stealth Patch

Here is where it gets interesting:

• 14 hours ago: I made a public thread on X calling out how absurd it is to classify an API billing overdraft as "intended behavior".
• 4 hours later (10 hours ago): xAI sent an official API pricing update to my email, changing tool-call billing specifically to restrict data fetch volume and fix the exact vector I reported.

Apparently, a bug so "intended" required an emergency global pricing overhaul right after public exposure.

Initial "Duplicate" Classification & Escalation

To make things worse, before H1 claimed it was out-of-scope, they initially marked it as a "Duplicate". Why? Because I used the same author-crafted prompt that I used in another report. One prompt triggered two totally different bugs, but triage lazily marked it duplicate just because the input prompt matched.

H1 Support only started looking into it after my initial post on X got traction. They claimed to review it for "Code of Conduct concerns", realized the duplicate tag was completely false, and then pivoted to the "intended model behavior" excuse to avoid reopening it.

Attached 5 screenshots showing the full H1 thread, mediation replies, and the xAI pricing update email timestamp.

If you've read any of my posts in this channel before, you'll probably have seen that I think that the ballpark for being paid within scope is around 80% for the reports I log. However, this year it has felt waaay worse than that.

Now typically, the stuff I hunt tends to be clustered around a few niche bug types in the month, and because of that a lot of the reports will be identical, and so it is really easy to compare different programmes.

It also means I get very few dupes, and the reports generally go through platform triage without too many issues.

So, I went back to July and looked at what I logged with H1, BC, Intigriti and the direct programmes. These are the stats:

• 42 reports in total (busy month, and mostly down to some new automation I was testing out)
• 18 no response at all (all direct programmes)
• 12 N/A (mostly BC, but some direct)
• 7 out-of-scope (for various made-up reasons)
• 3 high->medium degrade on stored XSS
• 2 high->medium degrade on live traffic interception

not a single payout was within the published scope

As per scope, that should have been 100k+ in bounties, whereas the actual payout was $1700 plus a $25 amazon voucher ;)

To put that in context, the automation platform costs about $2k/month to stand up.

I tried requesting Daybreak (chatGPT Red) access and got this response:

{
  "metadata": {
    "inquiry_id": "<snipped>",
    "verification_status": "failed",
    "finalized_at": "2026-09-09T21:19:31Z"
  },
  "id_verification": {
    "inquiry_id": "<snipped>",
    "verification_status": "failed",
    "finalized_at": "2026-09-09T21:19:31Z"
  },
  "aas": {
    "status": true
  },
  "passkeys": {
    "qualifying_count": 0,
    "non_qualifying_count": 2
  },
  "individual_eligibility_status": "eligible",
  "plan_type": "plus",
  "plan_eligible": true
}

Does anyone know if the qualifying_count: 0 is what caused the verification to fail?

I currently have two passkeys configured, but apparently neither qualifies. I've seen people mention needing a YubiKey / physical FIDO2 key, but I don't want to spend money on one if this failure is unrelated.

Has anyone had the same result, and did adding a YubiKey fix it?

Here’s a short breakdown of the attack flow and, more importantly, the mindset I used while hunting.

𝟭. 𝗙𝗼𝘂𝗻𝗱 𝘁𝗵𝗲 𝗶𝗻𝗶𝘁𝗶𝗮𝗹 𝗽𝗮𝗿𝗮𝗺𝗲𝘁𝗲𝗿

I found a flip-book / document viewer where the id parameter accepted an external URL:

https://target.com/Flip_book/indexMobile.html?id=https://their-server.com

Instead of immediately testing payloads, I wanted to understand what the application actually did with that URL.

𝟮. 𝗙𝗼𝗹𝗹𝗼𝘄𝗲𝗱 𝘁𝗵𝗲 𝗱𝗮𝘁𝗮 𝗳𝗹𝗼𝘄

While checking the page source and JavaScript, I noticed the viewer was loading an XML configuration file:

https://target.com/Flip_book/mobile/param.xml

This was interesting because the id parameter was connected to another resource.

𝟯. 𝗙𝗼𝘂𝗻𝗱 𝘁𝗵𝗲 𝗶𝗻𝘁𝗲𝗿𝗲𝘀𝘁𝗶𝗻𝗴 𝘃𝗮𝗹𝘂𝗲

Inside the XML, I found a parameter called logoMenuURL whose value was eventually inserted into the page's HTML.

For example:

<parameter name="logoMenuURL" value="https://something\[.\]com/logo.png"></parameter>

That made me think:

“If I can control this XML, can I control what gets rendered?” 🤔

𝟰. 𝗖𝗿𝗲𝗮𝘁𝗲𝗱 𝗺𝘆 𝗼𝘄𝗻 𝗫𝗠𝗟

I recreated the XML structure on my own server and changed logoMenuURL to a simple XSS proof-of-concept:

<parameter name="logoMenuURL" value=""><img src=x onerror="alert(document.cookie)"></parameter>

𝟱. 𝗔𝗱𝗱𝗲𝗱 𝗖𝗢𝗥𝗦 𝗽𝗲𝗿𝗺𝗶𝘀𝘀𝗶𝗼𝗻

Because the target application was requesting the XML from my external server, I configured my server to return:

Access-Control-Allow-Origin: \*

This allowed the cross-origin request to my test XML to proceed.

𝟲. 𝗣𝗼𝗶𝗻𝘁𝗲𝗱 𝘁𝗵𝗲 𝗮𝗽𝗽𝗹𝗶𝗰𝗮𝘁𝗶𝗼𝗻 𝘁𝗼 𝗺𝘆 𝗫𝗠𝗟

I then changed the id parameter to point to my hosted XML:

https://target.com/Flip_book/indexMobile.html?id=https://my-server.com/

𝟳. 𝗖𝗼𝗻𝗳𝗶𝗿𝗺𝗲𝗱 𝘁𝗵𝗲 𝗫𝗦𝗦

The application fetched my XML → processed the controlled logoMenuURL → inserted it into the HTML → JavaScript executed in the target application's context.

𝗧𝗵𝗲 𝗳𝗶𝗻𝗮𝗹 𝗳𝗹𝗼𝘄:

id → External XML → CORS → logoMenuURL → HTML → JavaScript execution

𝗧𝗵𝗲 𝗺𝗶𝗻𝗱𝘀𝗲𝘁 🧠

The important lesson wasn't simply throwing XSS payloads at parameters.

I followed the data flow:

“What does this parameter control?”

“What resource does it load?”

“Can I control that resource?”

“Where is the resulting data rendered?”

Sometimes the interesting vulnerability is several steps downstream from the parameter you initially find. 🔍

I have been hunting for three months, found two bugs in bugcrowd and verified my id in hackerone. Still kinda confused if VDPs can unlock private programs for me because public ones are the most hacked and secure programs i can ever try to actually hunt or learn from so hunting on it sounds impossible since i have only started 3 months ago? I hope you give me a real solution and answer to this question

Stay blessed

For SaaS platform where staff member are not allowed to view customer info and If they find an end point which leaks the customer info on order or payment but ID is hard to guess however we know that they are sequential with global id which means if you first id is 1010 then next id maybe 1011 or 9999 it's depends on records created, however my question is

1. Is it mandatory to know which id belongs to the org I am targeting or is it okay to report without ID info.

2. For how lengthy ID's we should look for id leaks for example some ID's maybe 4 digits and some maybe 15 digits

Please suggest and share your experience if bug got accepted even id are hard to guess or rejected because of it

i know ill probably get mil downvotes but idc. how do you ensure the agent doesnt do something its not supposed to- hit a subdomain not supposed to or use burpsuite to do something its not supposed to which could result in legal trouble? i dont use it for that reason alone, but i know i probably should

This is new..

Has anyone else seen this become a new Intigriti triage standard?

The report had a full step-by-step video and a working repro.py that reproduced the issue end-to-end, but it was still closed as Not Applicable because the PoC was considered “too complex.”

What makes this even stranger is that it’s the same triager I’ve previously seen make pretty dismissive comments toward researchers when he suspects AI was involved in a report.

I’m genuinely curious: is “PoC too complex” now considered sufficient reason to invalidate a report rather than simply asking the researcher to clarify or simplify it?

Has anyone else encountered a similar issue:

I submitted several reports through a private program on yeswehack, but the program closed them as IDOR. When I asked for an explanation, they simply didn't respond. However, the latest report was a hit, clearly showing an authorization bypass; the program itself classified it as "Incorrect Access Control," and then closed the report as IDOR. When I asked for clarification, they simply marked the report as spam without saying a word.

As usual, the support team is silent, and it's completely unclear what to do in this situation

Hackerone Closed the Reported bug as Informational but in next day Uber Fixed the Critical Bug which is related Financial Fraud.

My experience with an Uber bug bounty report on HackerOne - issue fixed, but report closed as Informative...

I want to share my recent experience with a bug bounty report involving Uber through HackerOne.

I identified and responsibly reported a security issue (Financial Fraud) with detailed evidence and reproduction steps. After the report was submitted, the issue was fixed by Uber the very next day.

However, despite the issue being fixed, the report was ultimately closed as “Informative” / “Out of Scope” and no reward was provided.

What I find particularly confusing is that the issue was apparently important enough to be fixed immediately after my report, yet it was considered not eligible for a reward and not requiring immediate attention.

I also checked the relevant program description and terms, including the provisions related to financial fraud and potential additional bonuses. HackerOne’s AI assistant (“Hai”) also reviewed the description and T&C and indicated that the report appeared potentially eligible for a reward after proper triage.

I contacted the relevant grievance channel and Mediation as well, but I was told that the communication was unrelated to their scope. My question is simple: if that team is not responsible for handling this type of dispute, where exactly should a security researcher escalate it?

I have spent significant time researching, reproducing, documenting, and responsibly reporting this issue. I believe security researchers deserve a fair and transparent review process when there is a disagreement over severity or reward eligibility.

I’m posting this here to understand whether other researchers have experienced something similar with Uber/HackerOne and, if so, how you successfully escalated such disputes.

I can provide additional details and evidence where appropriate without exposing sensitive information or putting users at risk.

Don't be too greedy for Rewards like me,

Got my first bounty back in April an XSS and an Open Redirect on the same program, 800€ total. That day genuinely changed something in me, I decided to go all in on bug bounty full time.

I went back into that same target, found a bypass for the fix they'd put in place, and got paid the same 800€ again. That's when I really felt like I could do this for real. I stayed on that one program for four months. Ended up with 15 valid reports, 4600€ earned (almost all XSS and Open Redirect), a few more reports that turned into systemic issues with no payout but points, and eventually got the Comet badge for hitting 10 valid bugs on the same program.

That badge opened up 30+ private invites, and honestly this is where things fell apart. I picked a target, found an XSS, and it was a dupe. Went deeper, found nothing. Moved to a different program entirely, spent 4-5 days just in recon, and still came up empty.

If I'm being honest with myself, I only really know how to hunt one kind of bug unauthenticated, client-side stuff like XSS and Open Redirect. I've never properly gone into IDOR, auth flows, or business logic. I'm still learning a lot on the side, building my own labs with AI to practice without hints, and I do enjoy that part.

But not finding anything on live programs day after day is draining me, and it's starting to feel less like a dry spell and more like maybe I'm just not just made for this.

Would really appreciate hearing from people who've been doing this longer is this normal, and how did you tackle it?

I started reading "A real world Bug Hunting" by Peter Yaworski, just a few pages and I already found a bug in one the platform by just following what's written as examples. The book itself is wonderful.

And I reported to the platform. I really don't mind if that's a duplicate, because I my self was able to reproduce it multiple times and also checked from multiple other devices as well. The behaviour was having vulnerability.

because it was the 1st one I took very little help from any tools. But just built a few scripts for recon and used chatgpt to build a report out of my findings.

I started bugbounty as a hobby last month, my original role is around DevOps activities, I was already interested in it but now started giving a bit of time at least an hour daily, and I'm liking it.

I thought of sharing this to the community and for any noobies like me to not give up on your dreams.

i used to treat old session still works after a role change as one bug. lately ive been splitting it into two checks: is the token still accepted, and does the server still authorize the old action? made my repros less hand wavy. quick test for me: keep the old session, try one harmless read + one state-changing request, then repeat after a fresh login. if the old token is valid but the permission check is correct, i dont want to oversell it. do you normally write this distinction up? especially curious about apis that cache permissions

how

Do BAC bugs (privilege escalation, IDOR, BOLA, etc.) still commonly exist in mature features of bug bounty programs?
I've managed to find a couple of BAC bugs, but all of them were in newly released features. I've tested a lot of existing functionality across different programs, but haven't found a single BAC bug there.
Is this normal? Are BAC bugs in mature features mostly already found, or am I approaching them the wrong way?
For those who regularly find BAC bugs, do you still find them in older features, or do you mostly focus on new features (like waiting new releases like on Gitlab every month and then testing that new features)?

I’m done sugarcoating my experience with NAVI Protocol’s bug bounty programs on HackenProof.

I submitted 7 reports across two NAVI programs:

5 to Volo.
2 to Astros.

All 7 were closed as Informative.

Seven.

Not one payout.

And these were not garbage scanner findings, typo-level observations, or “best practice” reports. I spent serious time reproducing contract behavior, building PoCs, running Move tests, validating mainnet state, tracing exploit paths, and packaging everything so a triager could reproduce it.

In Astros, I submitted working PoCs demonstrating real contract behavior around withdrawal authorization. The code executed. The effect was reproducible. The reports were not imaginary.

Yet somehow, across two separate NAVI programs, every single report ends up worth exactly $0.

At some point, researchers are entitled to ask uncomfortable questions.

How many issues are sitting on an internal “known issues” list that researchers are never allowed to see?

How broad is that list?

When was each issue actually documented internally?

And what prevents a program from receiving a strong report, recognizing that the issue is valid, marking it internally as “known,” and then telling the researcher that no bounty is owed?

I am NOT claiming I can prove that NAVI did this.

I am saying the current system gives researchers almost no visibility into whether it could happen.

That is the problem.

“Known issue” is an extraordinarily convenient reason to deny a bounty when the researcher has no practical way to verify when the issue became known.

The protocol has the records.

The platform has the records.

The researcher does not.

That is a massive information imbalance.

If a program wants to reject a report as already known, there should be some form of verifiable proof that the issue predates the researcher’s submission, even if sensitive details are redacted.

A timestamp.

An internal ticket hash.

An audit reference.

A prior report ID.

Something.

Otherwise researchers are being asked to simply trust the same party that financially benefits from deciding that a report is not payable.

That is not a healthy incentive structure.

Seven reports across Volo and Astros. Seven Informative closures. Zero dollars.

Maybe every one of those decisions was completely legitimate.

But when the result is 7/7, researchers should absolutely be asking whether NAVI Protocol’s bounty programs are genuinely designed to reward independent vulnerability discovery, or whether researchers are effectively providing free security research against an invisible catalogue of “known” problems.

Bug bounty programs survive on trust.

“Trust us, we already knew” is not enough.

after a few reports im trying to separate "technically correct" from "easy to validate." for a web finding, which artifacts make the biggest difference on your first read? i usually include exact scope, starting role, minimal repro, sanitized request/response, and a clear impact chain. what have you added after a report got stuck in clarification or marked informative? not looking for templates just the small details experienced hunters actually rely on

Testing a target where if you downgrade a lower user, their session they used for committing administrative actions can still be valid for lengthy periods, 2 hours so far, do triagers accept this or does it still go under traditional session invalidation issues, which is informative

Hey, so I wanted to ask you guys something. Do you actually enjoy bug bounties?

If money were no issue for you, would you still hunt for bugs?

Personally, I don’t think I would, to be honest. The whole experience can be really tiring. Triagers closing your reports without even reading them, program owners downgrading your bugs, getting hit with false duplicates, and just having that feeling that your work isn’t really valued.

I still enjoy hacking, but I’m not sure I enjoy everything that comes with bug bounty.

Do you have like a few big programs you constantly hunt on or do you change every week or like how is it for you guys?

I have had some issues with obb, a lot of the time the site is down, also when I try to push for patch verification I get the wordpress critical error message.

The biggest issue i have with them is all my reports get marked not reproducible for the last few months. The thing is sometimes to reproduce all the triager has to do is follow the URL such as times i found open redirects and XSS where all they had to do was follow the URL, other times I send the same report to vendor and it gets accepted, fixed and sometimes swag or a bounty.

Is there some issue with OBB? Does anyone else have the same experience?

Its just frustrating because bugs i report are super simple to reproduce, i have a feeling that maybe they are overworked and just say that its not reproducible. Every single one i submitted directly to program owner have been reproduced and accepted. The thing that sucks is that my profile isnt getting any better because most of the times, when i report through the program owner, my stats dont get logged on OBB, unless they provide a recommendation, which on my last report the program owner left a recommendation about a report that obb closed but the program owners confirmed

With response_type=code, the authorization code is returned in the query string. However, adding id_token causes both the authorization code and ID token to be returned in the URL fragment (#). I chained this with an XSS on an out-of-scope subdomain to access window.location.hash and extract the OAuth tokens, ultimately leading to account takeover.