Attacker user agent is my own website

I’ ve got this ip from cyprus trying to mess with my wordpress site for weeks now, trying to get at wp-login, xmlrpc.php, wp-cron.php…
i blocked it of course but i wonder about its user-agent that started as
“The Incutio XML-RPC PHP Library – WordPress/5.6.2” and is now :
“WordPress/5.7; [my site url]”
Anybody has an explanation?

Maybe you have Pingback and Trackbacks enabled, also XML-RPC requests, that could be the reason why you see it.

Someone linked to your site in a blog post, and it’s WordPress instance wanted to notify your about that.

If your Website is on Cloudflare, you can setup Firewall Rule to block anyone accessing xmlrpc.php and few other files like wp-config, etc. with this kind of rule:

You can also protect your wp-login.php by limiting to Country only, like allow only from Croatia and block the rest with the rule like:

Other way is activate Bot Fight Mode at Cloudflare Dashboard Firewall → Tools → Bot Fight Mode to enabled.

Have the security settings at least Medium under Firewall → Settings → Security Level.

thanks for your answer
Already protected wp-login, xml-rpc wp-admin and all…
i was surprised to find my website url as user-agent, i had the idea user-agents were browsers…

1 Like

Well, User-agent does not always mean “a person behind” is using Web browser :slight_smile:

For example, a script from a server via cronjob can be sent and contain custom User-agent with either custom HTTP headers (“act like a real person behind”, using custom user-agent like Mozilla/Chrome, from Windows NT, etc.).

Or bots also, like Googlebot that crawls your Website using sitemap, etc.

got that
thanks for info!
what does that tell me then about this ip behavior, the fact that it is setting the user-agent as my site url?
thats the last firewall report for this ip activity:

method: POST
Path: /wp-cron.php
Query string: ?doing_wp_cron=1615531696.3506369590759277343750

hostinger is my shared hosting provider, btw

wp-cron.php is fine, I do not recommend blocking the requests to it, rather allow them.

  • yes, someone may hit them also, but … it’s like the Ajax :slight_smile: (use rate limit if that case so)

You can disable WordPress cron jobs, but in that case, you would manually need to set them up and running.

Mostly, maintenance, security stuff, SEO maybe from Yoast, some database optimizations if running WP optimize or some similar plugin, scheduled posts, check for WordPress updates (if enabled and allowed to auto-update theme, core, plugin), etc.


This topic was automatically closed after 30 days. New replies are no longer allowed.