WordPress is the most popular content management or blogging system in world.A zero-day vulnerability exists in WordPress that in some conditions could allow an attacker to reset a user’s password and gain access to their WordPress account.
The WordPress vulnerability was discovered by security researcher Dawid Golunski of Legal Hackers who disclosed the vulnerability on Wednesday via his new ExploitBox service. All versions of WordPress are vulnerable including the latest 4.7.4.
According to Golunski the vulnerability (CVE-2017-8295) occurs because WordPress uses untrusted data by default when it creates a password reset email.
What is the Vulnerability?
Golunski points out that WordPress uses a variable, SERVER_NAME, to get the hostname to create a From/Return-Path header for the password reset email. Since that variable, by its nature, can be customized, an attacker could insert a domain of his choosing and make it so an outgoing email could be sent to a malicious address.
which would result in WordPress setting the $from_email to email@example.com and thus result in an outgoing email with From/Return-Path set to this malicious address.
Depending on the configuration of the mail server, it may result in an email that gets sent to the victim WordPress user with such malicious From/Return-Path address set in the email headers.
Golunski writes that there are three scenarios in which a user could be tricked, and only one of them relies on user interaction.
In one, an attacker could perform a denial of service attack on the victim’s email account in order to prevent the password reset email from reaching the victim’s account. Instead, it could bounce back to the malicious sender address, pointed at the attacker.
Second, Golunski says some auto-responders may attach a copy of the email sent in the body of the auto-replied message.
Third, by sending multiple password reset emails, he says the attacker could trigger the victim to ask for an explanation, below, which could contain the malicious password link.
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 said.
No official solution available. As a temporary solution users can enable UseCanonicalName to enforce static SERVER_NAME value.