WordPress 4.8.3, A Security Release Six Weeks in the Making

WordPress 4.8.3 is available and is a security release for 4.8.2 and all previous versions. This release addresses an issue with $wpdb->prepare() that could lead to a potential SQL injection. While WordPress core is not vulnerable, hardening has been added to prevent plugins and themes from inadvertently causing a vulnerability.

If you’re experiencing a bit of déjà vu, it’s because WordPress 4.8.2 attempted to solve the same problem. According to Anthony Ferrara who reported and disclosed the vulnerability, the patch in 4.8.2 didn’t solve the underlying problem and broke many sites.

Ferrara says he reported the issue immediately after 4.8.2 was released and was ignored by the WordPress security team for several weeks.

“When I got the attention of the team, they wanted to fix a subset of the issue I reported,” he said. “It became clear to me that releasing a partial fix was worse than no fix (for many reasons). So I decided the only way to make the team realize the full extent was to Full Disclosure the issue.”

Full Disclosure is the process of publicly sharing technical details of a vulnerability so that the public knows the same amount of information about it as hackers. The threat of full disclosure is typically used to pressure businesses and software creators to act swiftly and release patches as soon as possible.

On October 26th, Ferrara used his Twitter account to notify the public that WordPress contained a serious SQLi vulnerability and that because he lacked confidence in the team, fully disclosing it was his only option. His message was retweeted 562 times and liked by 484 people.

The amount of publicity his Tweet received had an impact as on October 27th, Ferrara reported that constructive discussions resumed with the team and that he would delay the disclosure until October 31st.

On October 27th, Ferrara spoke to a member of the WordPress security team who provided a fresh set of eyes to the problem, “A security team member who hadn’t yet participated in the thread went back to the beginning of the thread and re-read every post,” he said.

“He (correctly I may add) summarized the entirety of the issues, as well as asked a few clarifying questions. He also asked for a little more time but gave me a target of Tuesday, October 31st so it wasn’t wide open. This was the response I was looking for the entire time.”

Both parties collaborated on a patch that fixed the issue and WordPress 4.8.3 was released. Although his experience started out frustrating, Ferrara is hopeful that the team will do better with future reports.

“I get that there are competing priorities,” he said. “But show attention. Show that you’ve read what’s written. And if someone tells you it seems like you don’t understand something, stop and get clarification. And ask for help. Overall, I hope the WP security team moves forward from this. I do honestly see hope.”

Aaron Campbell, WordPress Security Team Lead, says that although there were some rough patches in working with Ferrara, they were able to work together to get a fix released in the end. While the threat of full disclosure didn’t have a huge impact on getting the vulnerability patched, it may have been the catalyst to get a new person involved in the process.

“A threat of disclosure certainly adds pressure and possibly stress, but doesn’t actually change the overall equation that much.” Campbell said. “An issue isn’t more severe because it’s going to be disclosed, but it can become more rushed (meaning a higher likelihood of mistakes).

In this case, I actually think the threat of disclosure ended up coinciding with one of the people from our security team joining in to help out. The new person was much better at communicating with Anthony, and it really turned things around.”

In the official release post, the WordPress Security Team thanked Ferrara for practicing Responsible Disclosure. This generated some conversation on Twitter on whether responsible disclosure should be renamed to coordinated disclosure.

“I’m not sure I know what the terminology change would be aiming to accomplish,” Campbell said. “I do see that some places use this particular phrasing, but honestly I don’t see how it conveys anything that’s not already generally understood with responsible disclosure.”

Users are encouraged to update their sites to 4.8.3 as soon as possible. Since this release changes the behavior of esc_sql(), developers are highly encouraged to read this dev note on the Make WordPress Core site.

10 Comments


  1. Themes and plugins (like our) use $wpdb->prepare(). It would be great to get an early heads-up, so we know about upcoming API changes and we can release our updates ahead of time.

    As it is, WordPress 4.8.3 fixes a security problem and breaks a good number of sites. Of course, we’re releasing an update ASAP for that change.

    For end-users, it doesn’t help knowing who’s right and who’s wrong and what all the underlying good reasons are. Their sites broke and they’re frustrated.

    It’s our common responsibility to make sure that sites are secure AND don’t break. If we could get advanced warnings about upcoming changes, we will stay up all night to adapt our plugins ahead of these changes, to prevent sites from breaking.

    Report

    Reply

    1. @Amir can you give any examples of code that has broken? The information in the release notes is a bit sparse, and itself gives no examples.

      Report

      Reply

      1. @david here’s the explanation of the issue.

        In `sitepress-multilingual-cms/classes/query-filtering/class-wpml-get-page-by-path.php` (`\WPML_Get_Page_By_Path::get_page_by_path_filter`), we had the following where clause:

        “`
        $this->wpdb->prepare( “ID IN ( SELECT element_id FROM {$this->wpdb->prefix}icl_translations WHERE language_code = %s AND element_type LIKE ‘post_%%’ ) AND “, $this->language )
        “`

        In case this is not clear, here we want to add a WHERE clause which filters by language and looks for all element types starting with “post_”. To escape the “%”, we must prefix it with another “%”.

        With WP 4.8.3, this string is converted into something like that:

        “`
        “ID IN ( SELECT element_id FROM wptests_icl_translations WHERE language_code = ‘en’ AND element_type LIKE ‘post_{e72a1103990676cd16df62a59657d29057b9f79ef08138075ceae85fee130fb6}’ )”
        “`

        `post_%%` was turned into `post_{e72a1103990676cd16df62a59657d29057b9f79ef08138075ceae85fee130fb6}`.

        We hook this method which adds the WHERE clause to the `query` filter.

        We’ve fixed the issue by using a higher priority (-1).

        This way the placeholder gets fixed by WP after we adjust the where clause.

        In our case, it was only one affected place (at least, after looking at all similar issue and running our tests which, thankfully, spotted the problem before our fix).

        As Amir wrote, like we had this problem, many other plugins and themes could have been affected.

        Report


    2. I think the challenge with security issues is trying to balance end user security-related safety versus breaking their site. It’s almost a catch 22 issue since from a security perspective a secure broken site is better than a functioning site with security issues. Unfortunately it’s hard, as a plugin, to have that sort of conversation with a user, and as you stated, user’s don’t actually care why their site broke even if it is a good thing. Security is hard and I don’t see there being an all encompassing answer.

      Also, how can WordPress release the pending changes to developers only, without risking nefarious people getting that information also and using it to attack sites before the security fixes are publicly available?

      Report

      Reply

      1. Where there’s a will, there’s a way. I’m sure that if WP folks want to send updates to theme and plugin authors, they will find a way.

        Report


  2. I’m sure all the work being done on Gutenberg took precedence over an important security issue… /endsarcasm

    Report

    Reply

  3. So WPML and newest WP obviously don’t play nice together, because the site I’m maintaining is broken after the update…

    Report

    Reply

    1. Yes Denis. That’s exactly what I was referring to. WPML already got an update which fixed the newly-introduced compatibility problem. It was a very simple fix and we released it quickly after we saw WordPress 4.8.3.
      Had we been able to see this version of WordPress before it was released, we would have updated our code ahead of time. It’s impossible to come up with updates for WP versions that come without betas, over night, during a major holiday.

      Report

      Reply

Leave a Reply

Your email address will not be published. Required fields are marked *