Published on 8 October, 2026 by Lana Miro
When an attacker failed to compromise a WordPress site but exposed an overlooked entry point
All responses in this series were submitted by real people and reviewed by the Melapress team. Some details may be generalized to protect anonymity.
Even a failed attack can have an impact.
The website already had several security measures in place, including two-factor authentication (2FA), account lockouts after repeated failed login attempts, and activity logging. These measures helped prevent the attacker from gaining access and identify what happened, but the repeated attempts still caused disruption.
At first, the failed logins did not seem particularly unusual.
The investigation eventually traced the attempts to XML-RPC, which gave the attacker another way to attempt authentication outside the standard WordPress login page.
The incident showed that even an unsuccessful attack can still have an impact through user lockouts, investigation work, and uncertainty about whether anyone managed to gain access.
Multiple user accounts started getting locked
Failed login attempts were nothing unusual for this website. Like many WordPress sites, it regularly received unsuccessful login attempts.
The first indication that this was more than routine background activity came when the marketing manager was locked out of their account.
Initially, the failed login attempts did not seem unusual, as they are a common occurrence on public websites. The turning point came when our marketing manager’s account was automatically locked due to too many failed login attempts. Shortly afterward, other user accounts were also locked.
The activity logs showed repeated failed login attempts, but some of the details initially made the source difficult to identify:
WP Activity Log showed repeated failed login attempts with entries such as:
Login URL: Not found
Failed login attempt
User-Agent: Jetpack by WordPress.com
At first, the requests appeared to be associated with Jetpack. Further investigation showed that the user agent was being spoofed.
After replicating the behavior, the website administrator identified XML-RPC as the route being used for the login attempts.
What is XML-RPC? It is a protocol that lets different applications communicate with each other over the web. WordPress supports it through the xmlrpc.php endpoint. You can read more about XML-RPC here.
The attack failed, but it still caused disruption
None of the login attempts caused an account compromise. The security controls already in place, like two-factor authentication and automatic account lockouts that limited repeated failed login attempts, helped prevent the attacker from successfully gaining access.
But the incident still had an impact.
What stood out most was the reminder that even a failed attack can have an impact. There is a certain level of disruption and stress that comes from knowing someone is constantly trying to gain access to your website.
Legitimate users were being locked out of their accounts, while the administrator had to spend time investigating what was causing the attempts and confirming whether any accounts had actually been compromised.
The experience also showed the value of understanding what was happening rather than only resolving the immediate symptoms.
Without proper security logging and monitoring tools, we might have resolved the immediate symptoms without fully understanding what was happening or whether the attack had truly stopped.
In this case, the activity logs provided the information needed to investigate the failed login attempts, test the suspected cause, and identify the targeted entry point.
What changed after the incident
The main change was disabling XML-RPC. The website had recently been rebuilt from scratch, and looking back, the administrator felt that would have been the right time to review whether XML-RPC was actually needed.
We had recently rebuilt the website from scratch, and in hindsight, that would have been the ideal time to remove unnecessary entry points such as XML-RPC.
The incident also strengthened the value of using multiple security measures in combination rather than relying on a single control.
Even when the standard WordPress login page is hidden or customized, other authentication routes may still exist.
In this case, 2FA, login protection, account lockouts, and activity logging helped prevent those attempts from becoming a successful compromise while also providing visibility into what was happening.
The lesson
Reduce your attack surface and implement multiple layers of protection.
The incident did not result in a successful breach. Instead, it revealed an entry point that was still available even though it was not needed.
And of course, no single security measure covers every scenario, so layering authentication controls with login protection and monitoring can both make unauthorized access more difficult and provide the visibility needed to investigate when something unusual happens.
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.
