WordPress, the most popular CMS in the world, is vulnerable to a logical vulnerability that could allow a remote attacker to reset targeted users’ password under certain circumstances.

The vulnerability (CVE-2017-8295) becomes even more dangerous after knowing that it affects all versions of WordPress — including the latest 4.7.4 version.

The WordPress flaw was discovered by Polish security researcher Dawid Golunski of Legal Hackers last year in July and reported it to the WordPress security team, who decided to ignore this issue, leaving millions of websites vulnerable.

"This issue has been reported to WordPress security team multiple times with the first report sent back in July 2016. It was reported both directly via security contact email, as well as via HackerOne website," Golunski wrote in an advisory published today. "As there has been no progress, in this case, this advisory is finally released to the public without an official patch."

Golunski is the same researcher who discovered a critical vulnerability in the popular open source PHPMailer libraries that allowed malicious actors to remotely execute arbitrary code in the context of the web server and compromise the target web application.

The vulnerability lies in the way WordPress processes the password reset request, for the user it has been initiated.

In general, when a user requests to reset his/her password through forgot password option, WordPress immediately generates a unique secret code and sends it to user’s email ID already stored in the database.

What's the Vulnerability?

While sending this email, WordPress uses a variable called SERVER_NAME to obtain the hostname of a server to set values of the From/Return-Path fields.
Here, "From" refers to the email address of the sender and "Return-Path" refers to the email address where 'bounce-back' emails should be delivered in the case of failure in the delivery for some reason.

According to Golunski, an attacker can send a spoofed HTTP request with a predefined custom hostname value (for example attacker-mxserver.com), while initiating password reset process for a targeted admin user.

Since the hostname in the malicious HTTP request is an attacker-controlled domain, the From and Return-Path fields in the password reset email will be modified to include an email ID associated with the attacker's domain, i.e. wordpress@attacker-mxserver.com, instead of wordpress@victim-domain.com.

"Because of the modified HOST header, the SERVER_NAME will be set to the hostname of attacker's choice. As a result, Wordpress will pass the following headers and email body to the /usr/bin/sendmail wrapper," Golunski says.

Don't get confused here: You should note that the password reset email will be delivered to victim's email address only, but since the From and Return-Path fields now point to attacker's email ID, the attacker can also receive reset code under following scenarios:

1. If, in case, the victim replies to that email, it will be delivered to attacker email ID (mentioned in 'From' field), containing a password reset link in the message history.
2. If, for some reason, victim's email server is down, the password reset email will automatically bounce-back to the email address mentioned in "Return-Path" field, which points to the attacker's inbox.
3. In another possible scenario, to forcefully retrieve bounce-back email, the attacker can perform a DDoS attack against the victim's email server or send a large number of emails, so that the victim's email account can no longer receive any email.

"The CVE-2017-8295 attack could potentially be carried out both with user interaction (the user hitting the 'reply' button scenario), or without user interaction (spam victim's mailbox to exceed their storage quota)," Golunski told The Hacker News in an email.

For obvious reason, this is not a sure shot method, but in the case of targeted attacks, sophisticated hackers can manage to exploit this flaw successfully.

Another notable fact on which successful exploitation of this flaw depends is that, even if WordPress website is flawed, not all web servers allow an attacker to modify hostname via SERVER_NAME header, including WordPress hosted on any shared servers.

"SERVER_NAME server header can be manipulated on default configurations of Apache Web server (most common WordPress deployment) via HOST header of an HTTP request," Golunski says.

Since the vulnerability has now been publically disclosed with no patch available from the popular CMS company, WordPress admins are advised to update their server configuration to enable UseCanonicalName to enforce static/predefined SERVER_NAME value.