From $0 to $5000 in One Bug Bounty Win - Case

From $0 to $5000 in One Bug Bounty!
I found a bug that paid $5,000 - and the root cause was embarrassingly simple: the production site accepted test credit cards meant only for staging. That meant premium features could be unlocked without payment. I reported it through the vendor’s bug bounty program and earned a five-thousand-dollar payout. Cool? Absolutely. Dangerous? Also absolutely.

This post breaks down the story (high level), the real risks, defensive controls every engineering team should implement, and a safe checklist for security researchers and bounty hunters. No exploit recipes - only lessons and protections.

What actually happened (high level) ​

While testing a target with permission, I noticed premium routes were unlocked after a payment step that should have validated a real card. The system appeared to accept test card numbers - the same sample cards developers use with sandboxed payment gateways - even on the live production environment.

That meant:

• Anyone with the test numbers could access premium content without being charged.
• Attackers could automate signups and unlock features at scale, causing revenue loss.
• If abused in bulk, the company could lose thousands or more before noticing.

I reported it responsibly through their bug bounty program, provided a clear impact statement and a repeatable (but non-exploit) demo on a staging instance, and got paid $5k for the finding.

---

Why this is worse than “free stuff” ​

This isn’t just piracy or an adventurous user - it’s a business logic flaw with real operational and security consequences:

• Revenue leakage: Premium features unlocked for free directly hit the bottom line.
• Fraud & chargebacks: Unauthorized free access may lead to later disputes and chargebacks.
• Trust & compliance risk: If payment processing fails validation, compliance with payment rules (PCI-DSS) may be affected.
• Escalation risk: Flaws in payment logic often let attackers chain into other flows (account upgrades, refunds, or privileged APIs).
• Reputational damage: Customers and partners lose trust in the product’s reliability.

---

How test cards end up in production (common causes) ​

Development and ops realities make this mistake surprisingly common:

• Misconfigured environment keys: Using sandbox API keys in production or shipping test credentials in environment variables.
• Shared code paths: Staging and prod share the same payment validation branches without environment gating.
• Leftover test flags: Feature flags or debug toggles controlling validation are left enabled.
• Manual overrides: Admin tools allow quick testing but aren’t restricted to staging.
• Inadequate CI checks: No automated guardrails to prevent test artifacts from being deployed to production.

---

Defensive checklist - how teams should prevent this ​

Here’s a practical list engineers and security teams can implement immediately.

1. Separate keys & environments
   Never use sandbox keys in production. Enforce environment-specific secrets using secret management (Vault, AWS Secrets Manager, etc.).
2. Fail-safe payment validation
   Accept only tokens returned by the payment gateway (e.g., Stripe tokens) and verify them server-side with the gateway’s API before granting premium access.
3. Detect test card patterns
   Block well-known test card numbers server-side (and log attempts). But don’t rely on number lists alone — validate tokens with the gateway.
4. Harden admin/testing endpoints
   Admin/test endpoints must be disabled in production or protected by strong auth and IP allowlists.
5. CI/CD policy gates
   Prevent commits or deploys that contain keywords like TEST_KEY, sandbox, or fake_card into production branches via pre-merge checks.
6. Monitoring & alerting
   Watch for unusual activity: spikes in premium activations, repeated failed charges, or many different payment tokens from a small set of IPs.
7. Regular reviews & pentesting
   Include payment flows in regular security reviews and bug bounty scopes.

---

Defensive code patterns (safe examples) ​

Below are safe, high-level snippets showing defensive checks - not exploit steps. These show how to avoid using test keys or accepting test cards in production.

Example: verify token server-side (Python, pseudo)​

import os
import requests

PAYMENT_API_KEY = os.getenv("PAYMENT_API_KEY")  # production key
ENV = os.getenv("ENV", "dev")

def verify_payment(token):
    # Call the payment gateway to validate the token before granting access
    resp = requests.post(
        "https://api.payment.example.com/v1/charges/verify",
        headers={"Authorization": f"Bearer {PAYMENT_API_KEY}"},
        json={"token": token},
        timeout=10
    )
    return resp.status_code == 200 and resp.json().get("status") == "valid"

def grant_premium(user, token):
    if ENV == "production" and "test_" in PAYMENT_API_KEY:
        raise RuntimeError("Sandbox key used in production!")
    if verify_payment(token):
        user.upgrade_plan("premium")
    else:
        raise ValueError("Payment verification failed")

Example: CI/CD pre-deploy check (shell pseudo)​

#!/bin/bash
# simple check to block sandbox keys in prod env file
if grep -q "TEST_KEY" prod.env; then
  echo "ERROR: Test key present in prod.env"
  exit 1
fi

Both examples are defensive patterns - validate tokens with the payment provider and prevent test keys from reaching production.

---

What researchers should do (safe & ethical) ​

If you discover a similar issue:

1. Don’t abuse it. Don’t attempt mass exploitation or access other customers’ data.
2. Document your finding clearly. Give reproducible, non-destructive steps and a severity estimate.
3. Use official channels. Report via the vendor’s bug bounty program, security@ email, or an established disclosure policy.
4. Offer remediation hints, not exploits. Explain root cause and suggested fixes (e.g., validate tokens with gateway).
5. Respect legal boundaries. If no program exists, prefer coordinated disclosure and legal counsel where appropriate.

Responsible reporting keeps you safe and helps the vendor fix the issue faster.

---

Post-report: what companies usually do ​

After a report like this companies typically:

• Revoke sandbox keys and rotate production credentials.
• Patch code to validate tokens server-side.
• Add CI checks to block test artifacts.
• Roll out logging and alerts for suspicious premium activations.
• Sometimes offer a bounty and public credit (if the researcher consents).

---

Lessons learned - for builders and hunters ​

• Simplicity often wins. The biggest bounties can come from simple oversights. Don’t ignore the basics during testing.
• Defense-in-depth works. Tokens + server-side verification + environment isolation + monitoring = much lower risk.
• Communication matters. Clear disclosure and remediation steps speed fixes and increase chances of reward.
• Automate hygiene. CI/CD, secret scanning, and policy-as-code reduce human error.

TL;DR - The two-sentence takeaway ​

A production system accidentally accepting test credit cards led to a $5,000 bug bounty after responsible disclosure. Prevent this with strong environment separation, token-based server-side verification, CI gates, and good monitoring.