How Attackers Stole Credit Cards from MyPillow's Website

In October and November 2018, a hacking group called MageCart broke into MyPillow.com's payment system and stole customer credit card information. They did this by injecting malicious code into the website's checkout pages — a technique that remains a significant threat to online retailers today.

How the Attack Worked

The attackers started by registering a fake domain name: mypiltow.com. Notice the typo — it's close enough to the real MyPillow.com that it could fool automated security tools. This fraudulent domain hosted malicious JavaScript code (a programming language that runs in web browsers).

The attackers then found a way to inject this malicious code directly into MyPillow's legitimate checkout pages. When customers typed their credit card numbers and billing addresses into the payment form, the hidden code captured that information before it could reach MyPillow's legitimate payment processor. The attackers essentially placed a digital wiretap on the checkout process.

This is called "client-side" skimming because it happens on the customer's browser, not on MyPillow's servers. That distinction matters: the attackers never had to break into MyPillow's main computer systems. They just needed to slip their code into the right place.

Why This Attack Pattern Matters

The approach used here — typosquatting combined with script injection — is the calling card of the MageCart group. Over the past few years, they've targeted hundreds of e-commerce platforms using similar methods. The attackers exploit the fact that modern websites rely on dozens of JavaScript libraries and third-party services, creating many potential entry points.

The typosquatted domain mypiltow.com was deliberately designed to evade detection. Automated security tools that rely on comparing domain names often miss small variations. A human might spot the typo, but security systems watching millions of domains in real time can easily miss it.

The Bigger Picture

The MyPillow incident ran for about two months — a lengthy window for data theft. This suggests either that MyPillow's security monitoring didn't catch the intrusion quickly, or that the attackers had enough skill to stay hidden despite efforts to remove them.

Looking at what this attack reveals about how e-commerce security works, there is a real architectural vulnerability at play. Most online retailers implement strong protections on their servers, but the front-end code that runs in browsers is much harder to monitor continuously. The code customers interact with directly — the checkout forms, the shopping cart — is built from many pieces, and keeping track of all of them is genuinely difficult.

Many retailers in 2018 lacked real-time visibility into what code was actually running in their checkout pages at any given moment. That's changed somewhat in recent years, but the underlying challenge remains: as websites become more complex and more dependent on external code libraries, the attack surface grows.

How to Stop It

To defend against this attack, organizations need a few layers of protection. The first is a content security policy — essentially a rulebook that tells the browser which domains are allowed to run code on a given page. If MyPillow's policy had blocked scripts from mypiltow.com, the attack would have failed at the browser level.

The second is real-time monitoring of payment pages. Security teams can watch for unauthorized changes to the code that runs during checkout, catching injected code before it steals data.

The third is domain monitoring — services that flag newly registered domains that closely resemble your organization's actual domain. If MyPillow had such a service in place, the mypiltow.com domain might have been flagged and investigated before it caused damage.

The MageCart group has adapted its tactics over time, finding new ways to bypass emerging defenses. But the fundamental vector — injecting malicious code into legitimate websites — remains effective at scale because many retailers still do not have comprehensive script monitoring in place. The good news is that the defenses are well understood. The challenge is implementing them consistently across thousands of websites, each with their own technical complexity and constraints.