What happens to a Bugcrowd report if the affected Chrome extension is removed?

I reported a vulnerability in a Chrome extension through Bugcrowd.

After I reported it, the Chrome extension was removed from the Chrome Web Store, and my Bugcrowd report was later put into a blocker asking for a response.

Now the company has launched a new/beta Chrome extension, but I checked it and the vulnerability I originally reported is not present in the new beta version.

So I'm wondering what usually happens to the original report in this situation.

Does the removal of the old extension affect the validity of my report? Would the report normally still be considered valid and potentially rewarded if the vulnerable version was live when I reported it?

Would appreciate insights from anyone who has dealt with a similar situation on Bugcrowd.

https://preview.redd.it/zvfb7i3f1ekh1.png?width=750&format=png&auto=webp&s=8f30d892127e467f30cfce175f8e1fc3b2d71120

For anyone who has experience with the Swisscom bug bounty program: how long does it usually take to get a response after submitting a vulnerability?

Also is Swisscom still worth actively hunting on these days? Would appreciate hearing about your recent experiences

A payment decision was made for my report on HackerOne almost two weeks ago, but the payment has still not been made. My report was triaged, and I was later told that a payment decision had been made, but I have not received the payment yet.

I submit a valid P3 report. They agree that it is P3, but due to program policy, they are not accepting it. So, he asked me to chain this vulnerability to a P2 or P1 and closed my report as N/A.
After a lot of time, I finally escalated this to P2 and posted the entire chained report in the comments.
My real question is: since my original report is in a closed state, should I submit a new report, open an RAR, or leave the P2 chained report in the comments and wait a few days?

With the rise of AI on everything I am now convinced that you really need a clear understanding of what you are doing in order for AI to work, with exploit chaining where you need multiple attacks, AI will be halucinating. AI does not really understand bug bounty, it can flag something as a vulnerability, mostly because that is from a cve, but that cve would not qualify as a bounty concern, some cves says a nonce can not be exposed or password has to be a certain length and mixed characters, which really dont matter if the authentication is hardened enough. From watching the critical thinking podcast and following some hunters in twitter, one still needs to really understand hacking, spending time hacking blindly with AI seems to be just a circular race. AI can fail to solve a lab or give a working script from a lab solution or a CTF, let along the real target.

I’m conducting authorized testing for a HackerOne bug bounty program and I’m encountering an Akamai access-control/WAF block on several explicitly in-scope assets:

• www.meesho.com
• prod.meeshoapi.com
• supplier.meesho.com
• admin.meeshosupply.com

Interestingly, affiliate.meesho.com, which is also in scope, is reachable from the exact same testing environment.

Current diagnostics

I’m running Kali Linux in a VM.

So far:

• DNS resolution: working
• TCP/443 connectivity: working
• TLS 1.3 handshake: working
• HTTP requests: consistently return 403 Access Denied
• Response is served by Akamai
• Akamai Bot Manager cookies such as bm_* are returned
• The required HackerOne identification header is present: X-Hackerone: xplorertech00

For example:

curl -sS -D /tmp/meesho.headers \
  -o /tmp/meesho.body \
  -H 'X-Hackerone: xplorertech00' \
  https://prod.meeshoapi.com/

This consistently results in an HTTP/2 403 response from Akamai. The other affected hosts behave similarly.

I’ve already ruled out basic DNS, routing, TCP, and TLS problems. The denial appears to be occurring at the HTTP/Akamai layer.

I’m not trying to bypass the WAF. I want to remain fully within the bug bounty rules and find the correct, authorized way to perform testing when an in-scope target is unreachable from the current testing network.

Options I’m considering

• Test from another legitimate ISP/network that I control.
• Ask the program to allowlist my testing IP.
• Ask whether the program provides an approved testing egress, VPN, or testing environment.

Questions for other researchers

1. If an Akamai reputation/access-control block is responsible, does switching to another legitimate ISP/network generally resolve the issue?
2. Is there a standard workflow researchers use with HackerOne programs when an in-scope asset is inaccessible due to CDN/WAF restrictions?
3. Would you recommend contacting the program first to request IP allowlisting rather than repeatedly switching networks?
4. What diagnostic information should I collect before contacting the program so they can determine whether the block is intentional or an accidental restriction?

I’d especially appreciate advice from researchers who have dealt with Akamai restrictions during authorized bug bounty testing.

Hi everyone, I wanted to ask about your personal experience with one particular topic: reports about Information Disclosure.

I’m not talking about things like exposing a user’s personal data. I mean server-side errors that reveal hidden endpoints, server logic, internal infrastructure structure, and things like that.

Have you ever had a report accepted where you had exactly this kind of information in your hands? What kind of information was it, and was it enough on its own for the report to be accepted?

Hello Hunters,

I have been doing bug bounty for while but now I am feeling like I am learning nothing new. All I am doing is same thing everytime I am doing bug bounty also most of my work is done by AI (For anyone curious I am using openrouter API configured my agent in Hermes) I am thinking to leave the bug bounty and now focus on learning other things like AD, windows server I know basics of things but want to master in it. I want to go in offensive security thats my clear goal.

I need advice what should I do ? Should I leave bug bounty ?

A depth-8 ftrace analysis of how the Linux kernel processes ICMP Timestamp (Type 13/14) requests — covering the full call chain, payload validation, conntrack behavior, and ts_ori echo mechanics.
————————

Most security tooling treats ICMP as a monolith: ping works, or it doesn’t. ICMP Timestamp (Type 13/14) sits in that overlooked middle ground — defined in RFC 792, implemented in every Linux kernel, but rarely scrutinized at the source level.
This post documents a depth-8 ftrace investigation of icmp_timestamp() on Linux kernel 6.17.13. Beyond cataloguing individual findings, the goal is to map the architectural reality of how the kernel processes ICMP Timestamp requests — every code path, every decision point, every place where the implementation diverges from what RFC 792 specifies.
What emerged was a set of concrete, reproducible behaviors: a silent payload threshold, a Code field that is never read, ts_ori that is echoed without any range check, and a netfilter pipeline that creates a conntrack entry for every single exchange.

I found a 2FA bypass where I can send concurrent requests via a single packet attack which bypasses the rate limit for predictable 5 digits, However the program policy has a very tight ceiling of the requests per second making that very time consuming to even record. Is there an alternative to record a POC without breaking the program's policy?

Hello ,
I reported a payment bypass through YesWeHack and successfully demonstrated it by placing 5 orders without payment, with video evidence.

After my report, the vulnerability was patched and the bypass stopped working. However, I was told they couldn’t reproduce the issue.

Has anyone experienced something similar? How can a vulnerability be considered non-reproducible after it was apparently fixed following the report?

For those who actively hunt bugs, I'm trying to understand whether Burp Pro is actually necessary.

I'm currently learning web security and considering using:

Burp Community — PortSwigger Academy/basic Burp work

Caido — primary manual HTTP testing

OWASP ZAP — scanning/automation

CLI tools — fuzzing/recon/specialized tasks

For people who have actually hunted with these tools:

What Burp Pro feature do you find genuinely difficult to replace?

I'm especially interested in things like Scanner, Intruder, Collaborator/OAST, HTTP/2 testing, Turbo Intruder, and extensions.

I'm not asking which tool is "best." I'm trying to understand whether the practical advantages of Burp Pro justify paying for it, or whether a combination of free/cheaper tools is sufficient for most bug-bounty work.

Hi all!

I’ve been working on building my own Cronus Zen.

In doing so I discovered a couple ways to get around Xbox controller pairing/handshake which then allows scriptable inputs that the console takes as controller inputs.

This has opened tons of doors. Aside from general scripting like you’d see with Cronus. You can pass commands from Computer Vision and effectively have an aimbot etc.

Would there be anyplace to disclose this or a bounty?
Cheers

So, I've been in the bug bounty game for almost 2 years. It's been hard to find bugs regularly, but I want to step up the game. Is there any other way than bug bounty where i could earn some simple money. Not as big as what bug bounty earned me, but something that does pay regularly. Any particular freelance methods or domains that particularly stand out. Where could I really put my skills into work for some easy money as a hacker other than bug bounty or a job

So I've been doing a lot of recon automation with bash scripts using subfinder, httpx, nuclei, etc. and it definitely saved me time on the basic stuff. But I'm kind of hitting a wall figuring out what's actually worth automating vs what I'm just wasting time on.

Right now I have a decent pipeline going subdomain enum, port scanning, service detection, then running nuclei templates on everything. Catches a lot of the easy wins like misconfigured headers, leaked tokens/credentials. But I have seen people talking about automating more aggressively.

What is your experience at automation and what is actually worth automating?

Hello,

For those who regularly find bugs, do most come from public or private programs?

I’ve never had a valid report on a private program, only dupes or info. Yet I’m ranked #1 on a public one.

People often say private programs are better, but in my experience they seem heavily tested.

Here is a story of how couple bad actor ruin a good program

I run a bug bounty program for a company. It's just literally me so sometime there is delays and such.

I've had some really good bugs coming in and had paid out > $5000 in total, some of the bugs are pretty good, although they are still ai slop, but good ai slop.

However, there are couple dudes that went crazy when they don't receive a response (to their ai slop "bug reports")

1. One dude starts emailing random company employees, including the CEO
2. The other dude threatens our community manager and scared them quite a lot
3. The same dude in No. 2 doxxed our employee and called them on mobile directly.

I personally respect the hustle, but doxxing is not it. Now the boss is mad and I have to change the bug bounty program to not give out cash to not incentivize those crazy behaviors. I might even have to shut it down completely.

I honestly feel sorry for other bug bounty hunters that I worked with., but some of your "peers" are destroying this whole thing with hope to get some quick cash.

While creating a test account on the target, I used a phone number from a service called "receive-smss" because the platform doesn't support phone numbers from my country.

After entering the OTP, the platform displayed a username along with a "Get OTP on your email" prompt.

The email address was masked, showing only the first letter and the domain extension but in this specific case, it was easily guessable for me.

I checked the program scope, and it explicitly lists "Username/email enumeration" under out-of-scope issues.

Since I haven't found a valid bug yet and this is the first time I've stumbled upon something like this, I'm really unsure and worried about whether I should report it or not.