WooCommerce Payment Skimmer 'sender.js' Uses Checkout Backdoor to Steal Card Data — Threadlinqs Intelligence
As of 2026-06-10, WooCommerce Payment Skimmer 'sender.js' Uses Checkout Backdoor to Steal Card Data is a high-severity malware threat, tracked by Threadlinqs Intelligence with 9 detection rules (Splunk SPL, Microsoft KQL, Sigma) and 14 indicators of compromise.
Threat ID: TL-2026-2169 · Severity: HIGH · Status: ACTIVE · Category: MALWARE
CloudSEK recovered an obfuscated client-side JavaScript skimmer, 'sender.js', from a compromised WooCommerce store running WooCommerce Payments (Stripe). After gaining web-shell access via a
CloudSEK's HUMINT engagements with operators active on carding marketplaces (Savastan0, Cvvhub, Jerrys, Zillion, Proton, VClub, Pepe, and unspecified invite-only forums) surfaced a shift in carder tradecraft: rather than standing up phishing pages that imitate a store, technically capable actors are compromising the legitimate e-commerce site itself and skimming real transactions.
The documented attack chain begins with generic web-application initial access — a vulnerable or outdated plugin/theme, a known CMS vulnerability, or exposed administrator credentials (no specific CVE or product/version was identified by the source). Once inside, the actor plants a web shell, then uses it to place a checkout backdoor: code positioned to execute on the payment page, whether injected into a theme file, a plugin, the database, or loaded from an attacker-controlled host.
That backdoor loads 'sender.js', a heavily obfuscated payload combining obfuscator.io-style string-array rotation with a custom encoding layer (base64, URL escape/unescape, and a per-character string-reversal helper) across two large encoded string-table blobs. On the checkout page, the script waits for the WooCommerce Payments (Stripe) element to render, then injects a DOM overlay that impersonates it — specifically targeting the 'wcpay-payment-element' / 'StripeElement' node — rather than attempting to read the real, cross-origin-protected Stripe iframe. The counterfeit form uses rogue input fields suffixed '_sb' (card-number_sb, expiry_sb, security-code_sb) to capture card number, expiry, CVV, and the customer's email in parallel with the legitimate checkout flow; because the real order still completes normally, the compromise produces no visible failure for the customer or the merchant, and CloudSEK notes dwell time is often measured in months.
Before exfiltration, the skimmer performs the same client-side checks a real checkout would run — Luhn checksum, card-brand/BIN detection, and expiry validation — so that only cards likely to be usable are captured and sent onward, reducing noise for the operator. Captured data is encoded and sent to an attacker-controlled collection endpoint, deduplicated per victim. To blend in, the skimmer stores tracking state under localStorage keys crafted to resemble marketing/analytics artifacts and sets a client-side Google Analytics opt-out flag ('ga-disable-*') to suppress anomalous behavioral-tracking signals around the injected form. CloudSEK's own defensive guidance for merchants centers on checkout-page change detection: CSP with reporting, Subresource Integrity on third-party scripts, file-integrity monitoring of theme/plugin/core files, review of WordPress options/widgets/post content for injected blobs, auditing unexplained 'ga-disable-*' flags, and synthetic checkout testing against a known-good baseline.
According to CloudSEK, freshly validated cards captured this way, along with billing context, are sold on carding marketplaces and forums (Savastan0, Cvvhub, Jerrys, Zillion, Proton, VClub, Pepe), reflecting active, ongoing monetization rather than a one-off proof of concept. No CVE, CVSS score, or specific vulnerable product/version was published by the source; the compromise vector is generic web-application initial access, not a single named vulnerability.
Target sectors: retail, ecommerce
Timeline
- CloudSEK's HUMINT engagements with operators on carding marketplaces (Savastan0, Cvvhub, Jerrys, Zillion, Proton, VClub, Pepe) surface a shift from standalone phishing pages to direct compromise of legitimate e-commerce checkouts.
- Per CloudSEK's analysis, the actor gains initial web-shell access to a WooCommerce store running WooCommerce Payments (Stripe) via a vulnerable/outdated plugin or theme, a known CMS vulnerability, or exposed admin credentials.
- Using the web shell, the actor plants a checkout backdoor, positioning code to execute on the payment page (injected into a theme file, a plugin, the database, or loaded from an attacker-controlled host).
- The obfuscated 'sender.js' skimmer loads on the checkout page and injects a DOM overlay impersonating the WooCommerce Payments Stripe element ('wcpay-payment-element' / 'StripeElement'), presenting a look-alike payment form with '_sb'-suffixed rogue input fields.
- The skimmer captures card number, expiry, CVV, and customer email in parallel with the genuine transaction, validates the card client-side (Luhn checksum, BIN detection, expiry check), and exfiltrates the encoded, deduplicated record to an attacker-controlled endpoint while the real order still completes.
- CloudSEK publishes 'Inside a WooCommerce Payment Skimmer: How Carders Moved From Phishing Pages to Checkout Backdoors,' documenting the sender.js sample and defensive guidance for merchants.
- The Hacker News' ThreatsDay Bulletin, securityonline.info, and Daily Cybersecurity Briefing amplify CloudSEK's findings on the checkout-backdoor skimmer technique.
Detections & IOCs
As of 2026-09-06, this threat has 9 detection rule(s) across Splunk SPL, Microsoft KQL and Sigma, and 14 indicator(s) of compromise. Detection query text and full IOC values are available to authenticated users and programmatically via the Threadlinqs MCP server (Purple tier). View plans.
MALWARE, HIGH, threat intelligence, cybersecurity, T1190, T1078, T1505.003, T1059.007, T1027, T1132.001, T1036, T1056.003
