WooCommerce Payment Skimmer 'sender.js' Uses Checkout Backdoor to Steal Card Data

WooCommerce Payment Skimmer 'sender.js' Uses Checkout (TL-2026-2169) is a high-severity malware campaign, first published 2026-06-10. It has no confirmed attribution, affects Automattic / WooCommerce WooCommerce Payments (WooPayments) — Stripe, maps to 8 MITRE ATT&CK techniques (T1027, T1036, T1056.003), and is covered by 9 detection rules and 14 indicators of compromise.

Key facts for TL-2026-2169

Threat ID
TL-2026-2169
Severity
HIGH
Status
ACTIVE
Category
MALWARE
First published
2026-06-10
Last reviewed
2026-06-10
Attribution confidence
LOW
Motivation
FINANCIAL
Target sectors
retail, ecommerce
Detection rules
9
Indicators of compromise
14

Malware and tooling in WooCommerce Payment Skimmer 'sender.js' Uses Checkout

Malware and tooling: sender.js (WooCommerce/Stripe checkout skimmer), obfuscator.io (or a compatible JavaScript obfuscation toolchain)

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 vulnerable plugin/theme, exposed admin credentials, or a known CMS flaw, the actor plants a checkout backdoor that loads the skimmer, which overlays a fake Stripe-lookalike payment form to harvest card number, expiry, CVV, and customer email in real time while letting the genuine transaction complete undetected.

How WooCommerce Payment Skimmer 'sender.js' Uses Checkout works

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.

MITRE ATT&CK techniques used in TL-2026-2169

Defense Evasion

T1027 Obfuscated Files or Information; T1036 Masquerading

Collection

T1056.003 Web Portal Capture

Execution

T1059.007 JavaScript

Initial Access

T1078 Valid Accounts; T1190 Exploit Public-Facing Application

Command and Control

T1132.001 Standard Encoding

Persistence

T1505.003 Web Shell

Affected products and versions in WooCommerce Payment Skimmer 'sender.js' Uses Checkout

  • Automattic / WooCommerce — WooCommerce Payments (WooPayments) — Stripe checkout integration for WooCommerce on WordPress
    Vulnerable versions: Not version-specific: CloudSEK identified no flaw in WooCommerce Payments itself. Compromise is via generic web-application initial access (vulnerable/outdated plugin or theme, exposed admin credentials, or a known CMS vulnerability) on the surrounding WordPress/WooCommerce store.

Remediation for WooCommerce Payment Skimmer 'sender.js' Uses Checkout

Immediate actions

  • Deploy a Content Security Policy (with reporting) that alerts on any new or changed script loading on the checkout page
  • Audit WordPress options, widgets, and post content for injected scripts or encoded blobs
  • Investigate any unexplained 'ga-disable-*' flags and reconcile Google Analytics property IDs against known-good baselines
  • Run synthetic/automated checkout transactions and diff behavior against a known-good baseline to catch a live overlay

Workarounds

  • Prefer wallet/tokenized payment methods (Apple Pay, Google Pay, PayPal) where offered, which are not exposed to a DOM-overlay card-form skimmer
  • Use virtual or single-use card numbers and enable transaction alerts to limit fraud exposure from any single compromised checkout

Longer-term hardening

  • Deploy File Integrity Monitoring (FIM) on theme files, plugins, and WordPress core to catch unauthorized modification
  • Enforce Subresource Integrity (SRI) hashes on third-party checkout scripts to prevent silent tampering
  • Restrict script and outbound-connection sources on the checkout page via CSP to an approved allowlist
  • Harden WordPress admin authentication (MFA, unique strong credentials) to close the exposed-credentials initial-access path
  • Keep all WooCommerce/WordPress plugins and themes patched and remove unused ones to close the vulnerable-plugin/theme initial-access path

Timeline of WooCommerce Payment Skimmer 'sender.js' Uses Checkout

  • 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 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.
  • 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.
  • 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).
  • 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.
  • 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.
  • The Hacker News' ThreatsDay Bulletin, securityonline.info, and Daily Cybersecurity Briefing amplify CloudSEK's findings on the checkout-backdoor skimmer technique.

Sources cited for WooCommerce Payment Skimmer 'sender.js' Uses Checkout

More in malware

Detection coverage for TL-2026-2169

As of 2026-06-10, Threadlinqs Intelligence publishes 9 detection rule(s) for TL-2026-2169 across Splunk SPL, Microsoft KQL and Sigma, covering 14 indicator(s) of compromise. The whole corpus is readable without an account; a free account unlocks full detection query text in Splunk SPL, Microsoft KQL and Sigma; paid tiers add raw indicator values, correlation and the MCP server. Threadlinqs MCP server · View plans.

Threadlinqs Intelligence — Real-Time Threat Detection Platform

[ 0 threats ] [ 0 det ] [ CRIT: 0 ] [ HIGH: 0 ]
// threat_feed
$ sort --newest
Showing all threats

Latest Threats