Security Advisory - Published 2026-06-08 - Payment webhook

BeikeShop Stripe CVE-2026-11462: Webhook Signature Self-Check

CVE-2026-11462 affects the Stripe payment plugin in BeikeShop. The risky path is the Stripe callback handler: if it processes webhook data without verifying the Stripe-Signature header, an order can be moved into a paid state even when Stripe did not confirm the payment.

Scope: This is a defensive guide for store owners and developers. It does not include a forged webhook body or exploit request. Use it to check whether your store verifies Stripe callbacks, whether the webhook secret is configured, and whether paid orders need reconciliation.

What is affected

  • Product: BeikeShop with the Stripe payment plugin enabled
  • CVE: CVE-2026-11462
  • Weakness: missing or improper Stripe webhook signature verification
  • Component: plugins/Stripe/Controllers/StripeController.php
  • Callback route: Stripe payment callback / webhook route
  • Reported affected versions: BeikeShop through 1.6.0 / 1.6.0.22 in public references
  • Public exploit signal: yes
  • Known exploited in CISA KEV: no, as of this publication

The upstream fix adds webhook-secret configuration, reads the Stripe-Signature header, and uses Stripe's webhook verification path before converting the event into order data. That is the correct shape: Stripe callbacks should be treated as untrusted input until their signature is verified.

Why store owners should care

A payment webhook is not just another form submit. Your store uses it as proof that Stripe accepted money. If the callback accepts unsigned JSON, the practical damage can be very ordinary and very expensive: shipped products, unlocked downloads, false revenue numbers, support refunds, and a messy accounting trail.

10-minute self-check

Step 1: Confirm BeikeShop and Stripe are in use

Check your store admin, deployment notes, plugin list, or source tree. If the Stripe plugin is not installed or not enabled, this specific callback issue is not your active payment path.

Step 2: Look for signature verification in the Stripe plugin

From the BeikeShop application root, search the Stripe plugin code:

cd /path/to/beikeshop
grep -R "webhook_secret\|Stripe-Signature\|Webhook::constructEvent" plugins/Stripe -n

A patched implementation should have a webhook secret setting and should call Stripe's webhook construction / signature verification function before it trusts the callback event. If none of those strings appear, treat the store as unpatched until a developer confirms otherwise.

Step 3: Confirm the Stripe webhook secret is configured

In Stripe Dashboard, open the webhook endpoint used by BeikeShop and reveal the endpoint signing secret. It should start with whsec_. Do not paste a live API key such as sk_live_ into the webhook-secret field. The webhook secret and the API secret are different credentials.

Step 4: Review callback logs

Search web-server logs for Stripe callback traffic:

grep -R "/callback/stripe" /var/log/nginx /var/log/apache2 /usr/local/apache/logs 2>/dev/null

Then search application logs for failed or missing signature messages:

grep -R "Stripe callback missing signature\|Stripe signature verification failed\|webhook secret" storage/logs 2>/dev/null

Failed signatures after patching can be normal if scanners are testing the route. Successful paid-order transitions before you had signature verification deserve a closer look.

Step 5: Match paid orders against Stripe

Pick recent paid orders and compare them with Stripe Dashboard. Focus on these patterns:

  • Order marked paid in BeikeShop, but no matching Stripe payment exists
  • Amount or currency differs between BeikeShop and Stripe
  • Paid-state transition happened right after unusual callback traffic
  • Digital goods, license keys, or fulfillment were released automatically
  • Callbacks came from networks that do not match your normal Stripe traffic pattern

Safe fix path

  1. Patch BeikeShop and the Stripe plugin. Use the vendor's fixed code path that verifies webhook signatures.
  2. Configure the webhook signing secret. Use the whsec_ secret from the exact Stripe webhook endpoint used by the store.
  3. Test with Stripe's dashboard tools. A legitimate test event should pass; a request without a valid signature should fail.
  4. Review recent paid orders. Reconcile BeikeShop paid orders against Stripe before shipping delayed orders.
  5. Rotate exposed secrets. If API keys or webhook secrets were pasted into the wrong field, rotate them in Stripe.
  6. Preserve logs. Keep web and application logs before cleanup if you suspect unpaid orders were marked paid.

Temporary mitigation

If you cannot patch immediately, disable Stripe payments temporarily or switch to manual order review. Do not blindly block the callback route without testing: blocking every callback can stop legitimate payments from confirming and create a different support problem.

When to treat this as an incident

  • The store accepted Stripe payments before signature verification was in place.
  • Unknown IPs hit the callback route before or during paid-order transitions.
  • Paid orders do not match Stripe payment records.
  • Automatic fulfillment released goods, downloads, or license keys.
  • You cannot tell whether the webhook secret was configured correctly.

Ping7 repair path

Ping7 can run a defensive BeikeShop payment-callback review: confirm the patch, verify webhook-secret configuration, search callback logs, and reconcile suspicious paid orders. Start from CVE Repair and include the domain, BeikeShop version, and whether Stripe is currently enabled.

References

Author: Ping7 security team - Published: 2026-06-08 - CVE-2026-11462 - Defensive self-check only.