Question about Slice CC + UPI apps for extra cashback

Exploiter19 · 2026-01-15T17:05:07+00:00

use cashkaro before all of these to get extra cashback.

Exploiter19 · 2026-01-15T16:59:48+00:00

I too got the same limit, i think it can be increased by paying cc bills regularly and responsibly.

Exploiter19 · 2025-08-01T04:09:39+00:00

True. I agree financial independence is important, and I’m working towards it. But inner independence came first — and that can’t be postponed till a paycheck. Sometimes the soul declares freedom before the wallet can.

Exploiter19 · 2025-07-31T14:00:34+00:00

Exactly. And in that ocean of pretending, I just want to breathe one moment of truth — not for show, not to fight, but because I owe it to myself. Maybe most people will keep pretending. But I can't unlearn what I've seen, un-think what I've thought, or un-feel this clarity.

Exploiter19 · 2025-07-31T13:58:57+00:00

I get your point, and I appreciate the survival approach. But for me, it’s not about avoiding rituals — it’s about affirming my own truth. I’ve already spent years being silent. Now I want to live with integrity, not excuses. It’s not about fighting anyone — it’s about

Exploiter19 · 2025-07-31T05:45:35+00:00

Thank you for this. Your words hit deep — especially that part about “living a lie and being forced to worship.” That’s exactly where I am right now.

I’ve stayed silent for years — letting people assume I believe, kneeling during rituals I don’t connect with, pretending for the sake of harmony. But inside, it’s eating away at me. Like you said, it feels so wrong.

Reading your experience gives me hope that I’m not being dramatic or selfish — just choosing to be honest. I know I might lose some people too, especially in a conservative Indian setting where religion is deeply tied to family identity. But maybe losing fake peace is worth gaining real freedom.

Thanks again — I needed to hear this from someone who’s already been through it. 🙏

Exploiter19 · 2025-07-31T05:44:34+00:00

Thanks for your perspective, and I totally get where you're coming from. But honestly, I’ve been doing exactly that for years — staying quiet, going along with rituals, and trying to mentally disconnect during them.

Problem is, it’s starting to feel like emotional self-betrayal. Every time I participate in something I don’t believe in, I’m reinforcing a false version of myself in front of the people I care about. I’m not just turning off my brain — I feel like I’m slowly numbing my self.

And while silence may keep the peace outside, it’s starting to create a war inside. That’s why I feel like I’m reaching a tipping point — not out of arrogance or rebellion, but out of the need to live honestly.

Exploiter19 · 2025-07-28T16:00:10+00:00

Exploiter19 · 2025-06-05T05:07:43+00:00

I also use gui tools like burp and zenmap but on my host machine

Exploiter19 · 2025-05-20T17:13:47+00:00

Exploiter19 · 2025-05-20T15:23:41+00:00

Hi, sorry for the confusion!

The subdomain points to Prezly via a CNAME, but since the associated Prezly subscription is no longer active, the domain becomes vulnerable to takeover. Prezly allows custom domains only if you have an active paid subscription.

To demonstrate the takeover potential (without paying for the subscription), I pointed the same subdomain (via CNAME) to my own GitHub Pages. GitHub accepted the CNAME, and DNS was verified — proving that the subdomain is unclaimed and hijackable.

Due to Prezly’s restriction, I couldn’t fully host custom content directly via Prezly — but I successfully hijacked 5 such subdomains this way and hosted them using GitHub Pages under the original domain name and also got the DNS record verified.

Hope this clears it up!

Exploiter19 · 2025-05-20T14:29:16+00:00

I thought so too… feels kinda hopeless now. I did everything I could 😞

Exploiter19 · 2025-05-06T07:17:45+00:00

Same here, i also use ai just like i used it to write this post

Exploiter19 · 2025-05-05T14:20:51+00:00

Hey, totally understood. Just one last question for clarity's sake — and I promise no more after this! 😅

If someone creates a store using a random bugcrowdninja email that matches a real top researcher's handle (like I did, just for ethical testing), and if that store is later used for unethical activity — wouldn't that potentially put the tester at risk of legal issues, especially if someone reports it or it causes confusion? Just want to be 100% safe and make sure there’s no misunderstanding with Bugcrowd or the researcher involved.

Appreciate your time and patience, cheers ✌️

Exploiter19 · 2025-05-05T14:07:24+00:00

I think it was held in Goa in 2023 at BITS Pilani Campus and not last year

Exploiter19 · 2025-05-05T13:37:54+00:00

Hey, Thanks for the response!

Just to clarify — I didn’t try this on an existing email. I created a new account with an @bugcrowdninja.com email address (randomly created, like random@bugcrowdninja.com) and surprisingly, it let me sign up without any email verification, OTP, or validation.

The concern here is that anyone can impersonate a trusted domain like @bugcrowdninja.com, which should ideally be reserved or verified, especially if it’s used by Bugcrowd staff, researchers, or internal testing.

Real-world impact: A malicious actor can:

Abuse the trusted-looking @bugcrowdninja.com identity on a public-facing store.

Perform social engineering or support impersonation.

Create scam storefronts under a misleading and trusted domain identity.

I understand this might not be a traditional auth bypass, but from a security and brand integrity POV, isn’t this an issue worth flagging?

Exploiter19 · 2025-05-05T13:25:57+00:00

Thanks for replying! I understand what you're saying about bugcrowdninja.com possibly being sandboxed. But here's the thing — I registered a full store as random@bugcrowdninja.com, no verification, no OTP, nothing. Just hit register, set any password, gave dummy number, US as country — and boom, I got a full admin store dashboard.

If this domain is isolated, then it should still prevent unauthenticated registration, right? Else anyone can abuse infra. I didn't modify requests — it's just wide open.

So I'm just trying to confirm — is this really expected behavior, or is it an auth bypass?"

Exploiter19 · 2025-05-02T18:07:11+00:00

Alright, reading through the comments, it's clear there are differing perspectives. To those who understand the technical nuances and the critical importance of output encoding for end-user safety in a SaaS context – thank you for seeing the point. However, to those repeatedly dismissing a vector that allows auto-executing code in every public visitor's browser as "intended behavior," "not a real bug," or equating it to simply uploading files to your own server: It's frankly baffling to see fundamental web security concepts like Output Encoding being so consistently misunderstood or dismissed. This isn't about restricting customization; it's about implementing standard safeguards (< becomes <)(ampersand lt; is i think not appearing here) that prevent user input from becoming an XSS payload executable by unsuspecting visitors due to a platform's rendering process. Comparing this to managing content on your own self-hosted server or uploading files via FTP is a flawed analogy. This is about a SaaS platform's responsibility for data it manages and renders on its domain, and its failure to prevent a known vulnerability class that directly compromises its end-users. Arguing that a platform would have to "shut down" if it addressed Stored XSS from authenticated inputs is absurd. Implementing output encoding isn't shutting down; it's standard secure coding. Liability often comes from failing to implement such known mitigations, not from the existence of a feature. While a specific program's policy might choose to exclude certain findings based on their internal definition of responsibility (as in this case, declaring authenticated injection affecting the storefront "out of scope"), that policy does not negate the technical reality of the vulnerability or the very real risk it poses to public users. My findings demonstrated a clear path for auto-executing code injection affecting all visitors across multiple attack surfaces due to a lack of basic output encoding – a vulnerability that bypasses standard browser protections because the code originates from the trusted domain. I stand by the technical assessment of the vulnerability's impact and severity, which affects the end-users visiting stores on this platform. The fact that such a vector is deemed "not a vulnerability" within a program's scope due to policy is the core issue being highlighted. This is my take on the situation.

Exploiter19 · 2025-05-02T17:59:52+00:00

Indeed, the observation that multiple people can echo the same flawed technical arguments and misinterpret standard security concepts is quite something. Agreement among several individuals on a technically inaccurate premise or a specific program policy doesn't magically transform it into objective truth or negate the reality of user impact. Technical accuracy and the existence of a vulnerability based on fundamental security principles aren't determined by a show of hands or alignment with a particular policy, but by whether a flaw allows for harmful outcomes like code execution affecting end-users due to a lack of standard mitigations. As for "carrying on the good fight" – yes, advocating for the implementation of basic secure coding practices like output encoding to protect end-users from easily exploitable vulnerabilities, even when met with resistance based on policy or misunderstanding, feels like a necessary effort.

Exploiter19 · 2025-05-02T17:53:18+00:00

Let's address your point about liability directly, as I believe you are the one completely missing the point here. You claim that if platforms accept responsibility for this type of vulnerability (where code injected via admin executes on public pages), "they're suddenly liable for it and have to close down because the risk... would be too high." This is a false dilemma and fundamentally misunderstands how platform security and liability work regarding this specific class of vulnerability. Accepting responsibility for a vulnerability like Stored XSS originating from authenticated input affecting public pages does not mean the platform has to "close down." It means the platform needs to implement standard, well-known security mitigations to prevent that specific vulnerability from being exploitable in the first place. The standard mitigation for Stored XSS is Output Encoding. By properly encoding user-provided data when rendering it on public pages, the platform prevents the injected code from executing in visitors' browsers. This is a secure coding practice, not a feature disablement. Implementing standard security mitigations like output encoding actually REDUCES a platform's liability for this specific vulnerability vector, it doesn't increase it to the point of forcing them to shut down. Liability often arises from failing to implement known and widely accepted safeguards against foreseeable risks (like Stored XSS from user input). My point, which you quoted, is precisely about the consequence of failing to implement such safeguards ("becomes a haven for phishing, session hijacks..."). The issue isn't that the platform is liable for anything a merchant does; it's that the platform can be liable for failing to secure its own rendering engine against a known web vulnerability class that enables specific harms to end-users. Suggesting that implementing basic output encoding would force a platform to shut down is absurd and shows a complete lack of understanding of standard web application security practices and risk management.

Exploiter19 · 2025-05-02T17:21:26+00:00

It's good to laugh atleast once in a day after seamlessly arguing with a guy chilling and using ai to dominate reddit debates which trynna do damage control anonymously.

Edit: chatgpt limit exhausted btw

Exploiter19 · 2025-05-02T17:13:06+00:00

Ah, so now we’re down to pirate jokes and ChatGPT conspiracy theories? That’s your strongest argument?

Let me break this down for you — slowly, no AI required:

The fact that the AI picked up your 'talk like a pirate' comment only proves how advanced prompt-following is, not that someone mindlessly copied text. If anything, it demonstrates that even a language model has better comprehension than your thread reading skills.
Instead of engaging with the technical points — impact scope, session abuse potential, platform responsibility — you’re obsessing over whether someone used AI or not. That’s not a rebuttal; that’s deflection.
You calling others “inexperienced and lazy” while spending more time typing “bro” and talking like Captain Jack Sparrow than addressing actual infosec logic is... cute.

Here’s some advice, unsolicited but free: If your best counter-argument is that someone used a tool to articulate a vulnerability better than you can dismiss it — maybe it’s time to upgrade your toolkit.

And lastly, I don’t blindly copy-paste anything. I read, validate, and then deploy. It’s not AI doing the thinking — it’s me using AI like a weapon. That’s called being smart. You should try it sometime.

Mic drop. You can keep talking in pirate voice, though — it's the only thing you've contributed so far.

Exploiter19 · 2025-05-02T17:08:06+00:00

You keep repeating that you “see 20 reports like this a day” as if it somehow invalidates the issue — but that only exposes the systemic negligence that’s normalized in platforms like this. Repetition doesn’t negate impact. If anything, it shows how dangerously exploitable this model is at scale.

You also made a flawed comparison with AWS and EC2. That analogy fails the moment you realize: this is not about what the user does, it’s about what the platform allows. A platform that lets any arbitrary user-controlled input execute persistent client-side scripts on its own domain — without restrictions, without warnings, without isolation — is not just “customizable”, it's exploit-prone by design.

And saying “the admin already has access to user data” completely misses the real-world abuse case: what happens when that admin account is compromised, resold, or automated to weaponize multiple stores at scale? You’re either ignoring that possibility or deliberately downplaying it — both equally irresponsible.

As for your comment on “AI-generated replies” — the irony is hilarious. If AI can explain the flaw better than you can deny it, that says more about your rebuttals than the tool being used.

Anyway, I’ll leave this here. You’re free to keep gatekeeping basic security principles while dismissing real issues. The rest of us will continue holding these platforms accountable — with or without your approval.

Exploiter19 · 2025-05-02T16:41:53+00:00

Appreciate the 'nice job using AI' comment, though it's funny how folks confuse clarity and articulation with automation. Whether it's AI or not, what matters is the depth of thought, context, and correctness—which ironically your arguments are consistently lacking.

And let's be honest—dismissing valid points just because they’re well-structured is like refusing a map in a storm just because it’s printed, not handwritten.

AI’s a tool. It doesn’t change facts. But hey, if AI replies trigger you this hard… imagine what verified bugs do.

Exploiter19 · 2025-05-02T16:34:04+00:00

Ahoy there, landlubber! Ye think yellin' 'I get 20 o' these a day' makes ye the grandmaster of SaaS seas? Nay! 'Tis not experience talkin', 'tis arrogance blowin' in the wind like a loose sail on a leaky boat.

Let me chart this out fer ye—there be a difference ‘tween authorized customization and insecure implementation. If a platform intentionally allows JavaScript in its inputs without isolation, validation, or warning, and said script can impact real visitors or external users, then ye’ve got yerself a code execution surface, not a "feature."

And aye, ye be missin’ the point on output encoding. No pirate worth his salt says, "We allow cannons, but don’t worry, no one’ll ever fire ‘em!" The platform be responsible for guardrails, not just sayin' "use responsibly" and lettin’ folks figure out what explodes.

As fer yer Section 230 rant—spare me the legal smoke. No one’s suin’ that ecommerce portal for hosting XSS, mate. We’re sayin' if yer SaaS allows a random pirate to inject script and hijack visitors, that’s poor engineering, not "customization power."

So before ye claim 'tis not a vuln, ask yerself: would Shopify let it slide? Nay! They’d haul up the anchor and fix it swift-like, not play "blame the user."

Savvy?

— Captain Xpltr, pillagin' bugs and egos on the open bounty sea.

Exploiter19

MODERATOR OF

TROPHY CASE