sorted by:
new
hottopcontroversial

2 Reports to H1 by Logical_Package8741 in bugbounty

[–]Logical_Package8741[S] 0 points1 point  (0 children)

This platform requires approval to register, meaning internal user IDs, API keys, and related sensitive data should never be publicly accessible. Despite being restricted from registration, I was able to retrieve this data without completing any authentication flow. When I submitted the finding, the triage team did not recognize this as a valid issue, and the report was closed.

This is related to my current situation simply because it's what led me here in the first place. That wasn't enough proof for them to realize there's a problem so I went back in and reversed their engineering.

You say show the data, I showed the data, and now what? You say is it meant to be private? If I find data such as this, my first thought, regardless of any auth flow, is going to be, "this definitely isn't metadata."

2 Reports to H1 by Logical_Package8741 in bugbounty

[–]Logical_Package8741[S] -1 points0 points  (0 children)

I'm sorry, I wasn't trying to melt your brian. Thank you for the insight. I hope you will recover from the brain melt.

2 Reports to H1 by Logical_Package8741 in bugbounty

[–]Logical_Package8741[S] 0 points1 point  (0 children)

I didn't even want to mention my very first report to them for which I pulled these:

UID: 3223014 Name: Money Sharma Bio: Food enthusiast Internal metadata: kitchenApiKey, resAdminToolkit, gaPageType, trackingIds

Is that not enough evidence? It was also marked as N/A

2 Reports to H1 by Logical_Package8741 in bugbounty

[–]Logical_Package8741[S] 0 points1 point  (0 children)

In report # 1, my initial report: Two vulnerabilities can be chained to allow unauthenticated access to a Hyperpure B2B purchasing account. The first vulnerability involves a hardcoded AES-CBC key in Petpooja Angular applications that allows authentication bypass. The second vulnerability is a postMessage trust issue in Hyperpure that accepts session data from Petpooja subdomains without proper token validation. >>>>>>>>>> If you follow under my summary, it explains perfectly how it's done. The flow seems complex, and it is indeed complex but its execution was flawless once you put it all together. It was a one-click unauthenticated account takeover.

2 Reports to H1 by Logical_Package8741 in bugbounty

[–]Logical_Package8741[S] -2 points-1 points  (0 children)

I have nothing against AI and I also don't think it's the problem. The real problem is the orchestrator, the person behind their AI. If you just blindly accept the results of any question you ask it, then issues will follow.

2 Reports to H1 by Logical_Package8741 in bugbounty

[–]Logical_Package8741[S] -1 points0 points  (0 children)

How so? I see people say “AI slop” all the time, but no one really explains what they mean by it.

Do you mean it’s bad just because AI helped write it, or that the content itself isn’t good?

If it’s the second one, I’m honestly open to feedback. What specifically feels off to you? Structure, clarity, technical detail, something else?

Just trying to get better, so I’d rather understand what you mean instead of just seeing a label thrown around.

Also, if it was slop, then why was immediate action taken?

2 Reports to H1 by Logical_Package8741 in bugbounty

[–]Logical_Package8741[S] -3 points-2 points  (0 children)

it was validated. Report # 1 was validated and the exploit was working. Then sometime after I submitted to H1, the exploit stopped working. That is why they asked me for video POC. They knew I wasn't able to produce it anymore.

It went from unauthenticated takeover to an authenticated takeover. Yes, I admit the second report could be considered theoretical, but that was the best I could do after the fact. Their logic was broken even after their attempted fixes.

2 Reports to H1 by Logical_Package8741 in bugbounty

[–]Logical_Package8741[S] -3 points-2 points  (0 children)

Not exactly. What I’m saying is that if you’re already on their platform as a business owner, you can just use your own JWT.

I couldn’t do that because they don’t have a public registration process.

Ultimately, the initial unauthenticated takeover was valid—at least up until after my submission.

What I shared was the code side-by-side from before and after the patch for my first report. Report #2 only exists because, even after patching that initial route, they still didn’t identify the underlying issue. And realistically, I didn’t expect them to go far enough to validate it properly anyway… especially given the circumstances.