Published on 20 October, 2026 by Lana Miro
How an attacker tried to steal card details from a WordPress checkout page
All responses in this series were submitted by real people and reviewed by the Melapress team. Some details may be generalized to protect anonymity.
We caught this by luck. We were doing planned maintenance [on the site] and saw the checkout page being edited from an IP [address] in Spain.
Last winter, a WordPress ecommerce website experienced two separate unauthorized logins roughly two weeks apart.
Different administrator accounts were used in each incident, and the logins came from different IP addresses. But they had one important thing in common:
There was no brute-force attack. They logged in successfully on the first attempt with valid credentials.
How the security incident started
In the first incident, the attacker gained access to an administrator account and added hidden text and links to the website.
Two weeks later, another administrator account was compromised. This time, the attacker targeted the checkout page.
After logging in, the attacker went directly to the checkout page, enabled Elementor, and attempted to add an obfuscated script that would display fake card fields below the legitimate payment method.
The real payment gateway redirects customers to the payment processor and then back to the store, so they were clearly trying to capture card details before the redirect.
Fortunately, the attempted modification did not work as intended, and no stolen card details were reported.
The page was not loading due to the broken script. They did not manage to get it working.
They discovered the attack during planned maintenance
There was no security alert that initially brought the agency to the website. They happened to be doing planned maintenance while the checkout page was being edited. The site’s activity log showed that the changes were coming from Spain.
The exact source of the compromised credentials was not confirmed.
However, the website owner later told the agency that the team stored its passwords in one place.
They keep all of their passwords in a Microsoft OneDrive Excel spreadsheet that everyone on the team can access, so that probably explains it…
Hopefully!
Whatever the source, both incidents involved successful logins with valid credentials rather than repeated attempts to guess a password.
What changed after the incident
After the second incident, the agency changed how access to the website was managed.
They reduced user privileges where administrator-level access was not required and enabled email-based two-factor authentication for all accounts with editorial permissions or higher.
They also added an alert for logins from IP addresses outside the website owner’s country.
The lesson
One of the clearest lessons from this story is the value of actively monitoring what is happening on a website, not just maintaining it. The agency spotted the suspicious checkout changes because they checked the site’s activity log.
The incident also reinforced the importance of limiting unnecessary permissions and adding stronger protection (like 2FA) to higher-risk accounts.
Have you dealt with a WordPress security incident?
Your story can show what security incidents really look like beyond the statistics, including the impact and lessons that are easy to miss.
Tell us what happened, what the experience was like, and what you learned from it. Stories may be published anonymously.
