I Found Critical Vulnerabilities in a Shark Tank Brand’s Website. They Never Wrote Back.

Let me back up.

I was watching Shark Tank — the kind of late-night, half-distracted watching where you're on your phone more than the screen. A product came on. The pitch was slick. The founders were confident. One of the sharks bit. I got curious enough to open their website.

First impression: clean. Branded well. The kind of site that makes you think someone spent real money on it.

Then I noticed something.

The discount field on the checkout page behaved strangely. I entered a random string. The price dropped. Not to zero — but noticeably. I tried a different string. It dropped further. That's not supposed to happen. Discount codes should validate server-side against a whitelist. What I was seeing suggested the validation was either client-side, pattern-based, or both.

I didn't check out. I opened DevTools instead.

The site was built on Shopify — obvious from the asset URLs and the cdn.shopify.com references in the network tab. Shopify itself is solid. The vulnerability wasn't in Shopify. It was in how the store had been configured.

Here's what I found over the next hour:

1. Discount code logic with no server-side rate limiting. Shopify lets you create discount codes programmatically. This store had auto-generated codes following a pattern — likely created by a Shopify app for influencer campaigns or affiliate links. The pattern wasn't random enough. A simple enumeration would surface valid codes in under 500 requests. No CAPTCHA on the discount field. No lockout after failed attempts.

2. A percentage-off metafield being passed in the cart URL. This one was worse. Cart permalink URLs on Shopify can carry attributes. This store had a discount parameter in their cart links — probably set up for a marketing campaign — that accepted a numeric value and applied it as a percentage discount directly. The parameter wasn't validated beyond "is this a number." Passing 95 gave you 95% off. Passing 100 threw an error (Shopify blocks free orders by default), but 95 went through clean.

3. No anomaly detection on order value. A ₹4,000 product processing at ₹200 should trigger something — a fraud flag, a manual review queue, an automated hold. Nothing happened. The order confirmed immediately.

I closed the tab without completing the checkout. Then I wrote them an email.

The email wasn't long. I explained what I found, attached screenshots of the DevTools session and the cart URL behavior, and said I'd give them two weeks before I wrote anything publicly. I offered to hop on a call if they wanted to walk through the fix.

That was two weeks ago.

No reply. Not even an automated acknowledgment.

I'm not going to speculate on why they didn't respond. Maybe the email went to spam. Maybe their support inbox routes to someone who doesn't know what a metafield is. Maybe the founders are heads-down on post-Shark-Tank fulfillment chaos and security is genuinely the last thing on their list right now.

All of those are real possibilities. Building a consumer brand is brutal, and a Shark Tank appearance usually means a sudden 10x order volume with the same infrastructure you had before.

But here's the thing: the vulnerability I found isn't obscure. It's not a zero-day. It's a configuration mistake that any developer who has spent a week on Shopify should know to avoid. The cart URL discount parameter is documented in Shopify's own developer docs with explicit guidance on sanitizing it. The pattern-based discount code generation is a known bad practice. These are solved problems.

The reason they go unfixed isn't usually ignorance — it's that founders building fast, often with vibe-coded storefronts or off-the-shelf Shopify themes, don't have anyone reviewing configuration choices from a security perspective. The developer who set up the affiliate discount app and the developer who built the cart experience were probably different people, or the same person on different days, and nobody owned the full picture.

There's a class of vulnerability specific to founder-built or AI-assisted storefronts that I keep seeing. It's not XSS. It's not SQL injection. It's business logic — the gap between what the code does and what the business intends.

The code worked exactly as written. The discount parameter accepted a number and applied it. That's correct behavior from the Shopify SDK's perspective. The mistake was upstream: someone configured a system without thinking through what an adversarial user would do with it.

Business logic bugs are harder to catch than technical bugs because they don't show up in a linter or a security scanner. You have to think like someone who wants to break the thing, not just someone who wants to build it.

Most early-stage brands don't have that person on the team.

I'll give them another week. If there's still no response, I'll file a report through Shopify's merchant support channel, which has a path for third-party security disclosures. It's slower than a direct email, but it works.

The product, for what it's worth, is good. I'll probably order it again at full price once the vulnerability is patched.

If you're building on Shopify — or on any platform where business logic lives partly in configuration — here's the short checklist I wish more people kept on hand:

Validate discount inputs server-side, not just in the UI. Rate-limit discount field attempts. If you're using URL parameters to pass pricing logic for campaigns, scope them to a session token, not an open numeric value. Set up order value anomaly alerts. And if someone emails you about a security issue, at least acknowledge the email.

They took time to find it and tell you. That's worth a reply.