WooCommerce Vulnerability Reintroduced from 7.0.1

Background

Last year we were alerted to a security issue (thanks to David Anderson) that would potentially allow users with specific capabilities (and, by default, this would include the Shop Manager role) to view user data for all users. This has the possibility of exposing sensitive information. Generally, and within WooCommerce, the information stored as user metadata is not sensitive, however it is possible for other plugins to store sensitive data should they elect to. We are not aware of any cases in which this would pose a risk in WooCommerce on its own.

We identified the issue and released a fix in version 7.0.1. However, this patch did not make its way into 7.2 so the vulnerability was re-introduced with that version and has been present up until now.

We have deployed a fix for the vulnerability in version 8.1.1 that is now available.

These vulnerabilities were identified as part of our ongoing HackerOne responsible disclosure program. At this time, we have no evidence of the vulnerability being exploited in the wild.

What do I need to do?

Update your WooCommerce version to the latest version (8.1.1) as soon as possible.

Is WooCommerce still safe to use?

Yes. While identifying new vulnerabilities is difficult, we work hard to do so proactively by partnering with HackerOne researchers to continually improve the safety of WooCommerce. Of course, finding vulnerabilities is just the first step.  

Afterward, we work to track and patch any vulnerabilities as quickly as possible. And we strive to keep our merchants and customers updated on a proactive basis about the continual steps we are taking to improve the platform.

I have other questions. If anyone has further concerns or questions regarding the patches, our team of Happiness Engineers is on hand to help โ€” please open a support ticket.


Keep yourself in the loop!

This field is hidden when viewing the form
This field is hidden when viewing the form
This field is hidden when viewing the form


6 responses to “WooCommerce Vulnerability Reintroduced from 7.0.1”

  1. “Last year we uncovered a security issue”

    This statement doesn’t reflect the correct attribution. The issue was discovered and reported by a third-party developer (me).

    1. Hey David, apologies for missing the attribution. In our haste to publish the report it was overlooked. I have corrected the post to link to the original Patch Release and have also added your name and link to the post. Please let me know if anything there is incorrect.

      1. The post is still missing some attribution, as we were the ones who noticed that the vulnerability had returned to the plugin and reported it to Automattic’s security team.

        Also, the changelog doesn’t identify the change to address this as a security fix or warn that it was a vulnerability.

        1. The reason we did not apply that attribution is because this vulnerability was disclosed publicly by Plugin Vulnerabilities prior to WooCommerce being able to provide a fix. That’s not a practice we would like to condone in the future. While we appreciate folks taking the time to alert our security team to these types of vulnerabilities, it’s important that they don’t get into the public’s hands before we are able to address them. That public disclosure, even though the vulnerability existed in core for quite some time, made this incident all the more critical.

          1. We obviously were not the discloser of the vulnerability. This post links to your own disclosure of it from November of last year. And this post also credits someone other than us for discovering it. We only knew about it because another arm of Automattic, WPScan, had done their own disclosure of it, but incorrectly claimed it had been fixed. So the vulnerability was already in the public’s hands.

            It doesn’t seem like a great way to get cooperation from security providers by making misleading claims to not credit them. Especially when your company owns a competitor.

            Even if you were not going to attribute this to us, you didn’t even admit that a third-party had found it had returned to the plugin. Considering that the post had at first apparently claimed you had uncovered the security issue, not David Anderson, it comes across as you trying to be less than honest about what has transpired.

            Also, if the issue is so critical, then it should be clearly labeled that way in the changelog, which it still isn’t.

Leave a Reply

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