PAYPAL FELT SAFE UNTIL IT WASN’T
Attackers turned one of the most trusted moments in online checkout, selecting PayPal, into a false sense of security. In this campaign, a compromised OpenCart store quietly loaded a fake PayPal payment experience that looked legitimate enough to lower suspicion, captured full card and billing details, and then let the shopper’s real order complete as normal. That made the attack especially deceptive: the customer saw familiar PayPal branding, the merchant still processed the sale, and nothing obviously broke.
The broader investigation made it even more serious, revealing at least 13 victim stores across multiple countries, payloads dating back to September 2025, and clear overlap with a much louder December 2025 campaign from the same operator, showing a shift from obvious activity to much quieter tradecraft.
Traditional defenses often miss this because the theft happens inside the browser, on the live checkout page, outside the normal visibility of server-side monitoring and beyond what WAFs or payment provider controls are designed to inspect.
Attack details
The attack begins with malicious code hidden in the page source in a way that appears commented out to a human reviewer, even though the browser still executes it.
That initial injection quietly activates a previously inert page element and then loads a victim-specific JavaScript payload from the attacker’s infrastructure, with each targeted store receiving its own tailored file.
The payload itself is heavily obfuscated, using layered string lookups and remapping logic to conceal its true purpose, a notable evolution from the same operator’s much louder December 2025 campaign, which relied on unobfuscated code.
Once active, it monitors the checkout page for two conditions at the same time: PayPal must be selected as the payment option, and the checkout flow must be initiated. It then intercepts the shopper’s click before the legitimate payment flow can continue, suppressing the normal event chain so the real checkout logic never gets a chance to run.
A short PayPal-branded loading animation appears first to make the transition feel legitimate, followed by a full-screen fake PayPal checkout overlay that uses genuine PayPal assets and familiar branding cues to reinforce trust.

The overlay collects card number, expiry date, CVV, cardholder name, billing address, phone number, and email, then packages that data into multiple encoded layers and sends it to the attacker through a hidden image request designed to blend into normal browser activity and slip past simpler controls.
After exfiltration, the skimmer cleans up after itself by briefly showing an error-style message, removing the fake overlay, triggering the real checkout flow, and setting a cookie to avoid stealing the same data again from the same browser.
The wider investigation made the campaign even more significant: an exposed directory on the attacker’s server revealed at least 13 victim stores across multiple countries, payloads dating back to September 2025, evidence of multiple payload generations, and overlap with the December 2025 operation, confirming the same actor had shifted from obvious activity to quieter, more disciplined tradecraft.

How Source Defense protects you
Source Defense extends security to the client side, where this attack actually happens, and can stop unauthorized third-party code before data exfiltration. In this case, the malicious payload was served from an attacker-controlled external domain that Source Defense had already identified and classified as malicious following research published in December 2025. That means Source Defense would have detected and blocked the script from loading on customer websites before it could present a fake payment experience to the shopper. This is a strong example of how ongoing threat research continuously strengthens Source Defense’s ability to protect against emerging client-side attacks.
How Source Defense alerts you
Source Defense, as described above, would completely block the script from loading in case the protect product is used. In cases where the detect product is in place, the script would load and Source Defense would alert on the following high severity behaviors:
As noted above, Source Defense would block this script from loading when the Protect product is in place. When Detect is in place, the script would load and Source Defense would alert on the following high-severity behaviors:
- Loaded from a blacklisted domain
- Sending to blacklisted domain
- Accessing PCI and PII data
- Transferring data
- Executing risky actions
- Accessing browser storage
- Using 1st party cookies
These alerts appear in the bell notification center and dashboard summaries, with blacklist-related findings visible in the “Found in blacklists” widget and behavioral findings surfaced through the “Script behaviors” widget. Based on configuration, they can also be delivered through email and webhook integrations so security teams can route them into existing workflows and response systems.
Key takeaways
This campaign is a strong reminder that familiar payment brands do not guarantee a safe browser session. When attackers can hijack the client-side experience, they can place convincing, trusted-looking screens in front of users, steal payment data before submission, and still allow the transaction to finish, leaving both merchant and customer with little reason to suspect compromise. That is why client-side security is essential for payment pages: the real attack surface is often the browser itself, not just the server or payment processor. Traditional controls such as WAFs, CSP, SRI, and server-side logging each have value, but they can be blind or too static when the attack is obfuscated, behavior-driven, and designed to look like normal page activity. Effective defense requires visibility into script behavior at runtime, where these silent payment skimming attacks actually unfold.