I see that many of my WordPress installs are being hit with 1000+ failed login attempts using non-existing 'admin' account name. The requests come from different IP's every time, and I see IP's such as (google's public dns) as the origin of some of the login attempts.

I use WordFence to detect and block these attempts, but the block is based on IP, so it's not so efficient.

My question is:

  • Is it 'normal' for low profile WordPress sites to get these 'attacks'? I've notices an increase in the logs during the first days of 2013.

  • Is it something to worry about, and is it possible to detect/verify if a login request is coming from a spoofed IP?

  • 7
    Spoofing IPs shouldn't be possible with TCP. How are you detecting the IP? Do you trust the forwarded-for header? Jan 13, 2013 at 17:05
  • Clarification: Spoofing source IP addresses is possible but few routers forward the packets and if they do, TCP communication is not possible. Jan 14, 2013 at 8:35
  • thanks for the comments, I'll ask the developer of WordFence, how the IP's are determined. Jan 14, 2013 at 10:39

1 Answer 1


Its impossible to spoof your ip address of a TCP connection due to the 3 way handshake.... Unless of course the application is vulnerable to CWE-291: Trusting a Self Reported IP address

Sure enough in ./wordfence/lib/wfUtils.php on line 77:

public static function getIP(){
    $IP = 0;

So yes, the reason why you are seeing brute force attempts from is because WordFence is vulnerable to CWE-291. I am reporting this vulnerability to WordFence, but to be honest this vulnerability is so painfully obvious. If the developer doesn't understand even the most basic flaws of trusting attacker input, then they have probably made other serious mistakes that impact security, I smell blood.

Its possible that a security system can make your system as a whole less secure. This is nothing new, remote code execution vulnerabilities have been found in anti-virus software. Complexity is the worst enemy of security.

  • 1
    @Null this flaw completely bypasses the security system they are trying to implement... but in the grand scale i agree its not critical. However, this is an inexcusable mistake for a security professional to make, I would expect that they have made even more egregious mistakes.
    – rook
    Jan 14, 2013 at 19:39
  • 1
    Hi, I'm the author. The initial design was a conscious decision to provide support for the widely used Nginx and other reverse proxy configs and to make the plugin work out of the box. However, point taken and we've released a fix. Here's how it's now implemented: Users install the plugin and it defaults to the old detection routine so that it functions. However it displays an urgent warning telling the admin their site is insecure until they tell us how to get IP addresses. The warning is visible at the top of all WordPress admin pages and won't go away until they configure this.... Jan 19, 2013 at 15:49
  • 1
    ...They need to go to our options page and select to use PHP's REMOTE_ADDR, X-Real-IP, X-Forwarded-For or Cloudflare's CF-Connecting-IP. Once they do this we detect if we're getting an internal (RFC1918) address and issue a warning if we do, or show a success message if we're getting external IP's. Jan 19, 2013 at 15:49
  • 1
    @Mark Maunder Putting the burden on the users in the form of a configuration option is still a vulnerability. The REMOTE_ADDR is the only value taken from the socket and there for cannot be spoofed. The other values may contain valid information, but this is highly unlikely. You could have an option to take all of these sources of IP address and BLOCK THEM ALL, but this can create a problem where the attacker can intentionally block the administrator if the attacker knew this ip address. Ignoring the REMOTE_ADDR is always the wrong option.
    – rook
    Jan 19, 2013 at 17:46
  • 1
    @Rook Reverse proxy configs don't provide client IP on the socket data. Jan 19, 2013 at 22:51

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .