Woocommerce with Wordpress - a Woe in its Own Right

This time, I decided to return to one of my favorite cyber security topics, namely trying to understand what kind of issues complex software dependencies cause IT service operations or application lifecycle management. In practice I wanted to examine how an ecommerce platform, Woocommerce, with its complex software stack would stand up to a critical examination. After all, setting up a Woocommerce site seems to be relatively easy, but how easy will it be to keep it secure and up-to-date?

From the customer perspective, the problem is twofold:

1. How do I know if the site is legitimate?
2. How do I know if I can trust my payment information with the vendor?

The answer to question number one is relatively easy: use a service such as Trust Pilot to find out what others have thought about a given site. The answer to the second question, however, is a bit more complex. In short, latent cyber security issues, such as vulnerabilities or exposures can come back and bite you in the ankle over time – especially if the vendor stores your payment or contact information for future purchases.

LAMP: Complexity at the Core that Leads into Security Exposure

For this research, I examined the releases of a popular ecommerce platform, Woocommerce, which is a Wordpress plugin. Why I wanted to do this is the fact that this piece of software represents a complex dependency hierarchy, since any given version is dependent on specific versions of:

• WordPress with its own dependencies.
  • PHP
  • MySQL / MariaDB.

So in essence, even if Woocommerce itself has had only relatively few serious vulnerabilities since 2014 (for example CVE-2023-0080), the operator of this stack must:

• keep the Operating System up-to-date
• follow supported WordPress versions
• update the backend database and perform the necessary SQL magic to keep the data models in check
• ensure that PHP vulnerabilities will not bite them in the ankle
• make sure that the Woocommerce plugins, such as Stripe Payment Gateway are updated.

At times, this must feel like walking a tightrope with your eyes closed and your hands tied behind your back.

The other option of course is not to care and hope for the best and fear for the worst. As a cyber security threat model that is not ideal and is one of the root causes for the failure of the LAMP (Linux, Apache, MySQL, PHP) paradigm.

Woocommerce Life Cycle Assessment

As stated above, for my research I looked at Woocommerce from the lifecycle management perspective. I paid special attention to building a timeline of the releases , whereafter I wanted to examine how those released versions are distributed in the wild.

Woocommerce Release Timeline

Above, we see a monthly cadence of Woocommerce releases dating back to 2014. Up until 2020, the project churned out roughly 25 releases per year. The releases are grouped by major/minor versions and include all the different versions such as release candidates. From 2020 onwards, the Woocommerce release cadence has doubled to approximately 50 releases per year. The spike in 2022 was due to the fact that a developer fixed some release packaging for a large number of past releases. The odd 2.2 release in 2023 seemed to relate to some type of beta tester functionality.

In terms of official software support, the project has an identical stance to Wordpress proper:

Generally, only the latest version of Woocommerce has continued support. If a critical vulnerability is found in the current version of WooCommerce, we may opt to backport any patches to previous versions.

Woocommerce Versions in the Wild

The column chart above depicts the distribution of a sample of 10k Woocommerce hosts by major/minor version number. I consider the sample to be representative, even if the whole population is ~180k and I was only able to fingerprint roughly 80% of the 10k hosts.

Based on my analysis, I’ve divided the 8k hosts into three distinct groups, the:

1. Good (version 7.8.x)
2. Bad (version < 7.8 and >= 6.0)
3. Ugly (version < 6.0)

The basis for this grouping is the fact that officially the Woocommerce project supports only the latest version, which at the time of writing was 7.8.X.

Woocommerce Life Cycle Management

My rationale for this rather rigid grouping is that Woocommerce is an ecommerce platform, which means that the operator must be security conscious as well. It is great that the project is part of the HackerOne bug bounty program, which means that they really care about security and want to ensure that their users have a secure platform.

Looking at the CVE history for Woocommerce, it becomes evident that most of the security issues are in the actual plugins of this plugin instead of Woocommerce itself, which makes life for the sysadmin in the lack of a better word interesting.

Not only does one have to keep the upstream stack in order, but also be mindful of the vulnerabilities in the downstream plugins. So, in order to run a secure ecommerce platform, one has to make sure that the:

• host OS is up-to-date and keeps up with the OS support cycle
• Wordpress platform is the latest supported one
• database backend MySQL/MariaDB is supported and works with the latest supported Wordpress
• PHP is supported and works with all of the PHP code above
• Woocommerce plugins such as the Stripe Payment Gateway plugin are up-to-date.

That is quite a puzzle and deciding on what is the relationship between:

• OS supplied components and Woocommerce components
• Woocommerce components and its dependencies

… is not easy to make either.

I mean, will one use a Linux distribution / OS supplied version of a package such as PHP and hope that it keeps in sync or build their own and keep it in sync manually?

For these types of scenarios there are no easy answers and finding a hosting provider who is on top of their game in relation to all this will probably not be easy either.

---

---

A Couple of Extreme Examples from the Ugly Bunch

In the spirit of validating my research, I picked a couple examples from the ugly bunch depicted above and to my surprise I found out that these still seem to be functioning ecommerce solutions.

Example: Woocommerce 2.2.6

This example is extreme yet educational. I mean this instance ticks almost all the boxes on the cluelessness scale:

1. The Linux distro (Debian Stretch) was way past its prime (EOL in 2022).
2. The Apache HTTP server was way out of date (as a consequence).
3. PHP was way out of date (as a consequence).
4. The MySQL backend was obsolete (as a consequence).
5. The Wordpress instance was obsolete (as an upstream dependency).
6. The Woocommerce plugin was obsolete (based on the release timeline).
7. The jquery component was obsolete (an added bonus).

The only bonus points I can give is that not all the backend components, such as the database backend were directly exposed to the Internet and that the X.509 certificate had been recently renewed!

The good news was that the host seemed to be running some kind of a book library, so at least no money needed to change hands.

Example: Woocommerce 2.2.8

The second example from the ugly bunch was even worse:

1. The linux distro (Ubuntu 14.04 LTS) was EOL in 2019.
2. The Apache web server was obsolete (as a consequence)
3. The PHP version was obsolete (as a consequence)
4. The MySQL backend was obsolete (as a consequence)
5. The Wordpress instance itseld was obsolete (as an upstream dependency)
6. The Woocommerce plugin was obsolete (based on the release timeline)

The added deficiency was the lack of transport layer security, as well as hosting a form on the site where you can submit some type of incident reports containing quite sensitive personally identifiable information (PII).

An Example from the Basket of Bad Apples

Even if looking at the freak show was entertaining, what does the situation look like for the bunch of bad apples?

Example: Woocommerce 6.0.0

Using Woocommerce 6.0.0 as a marker, I picked the following example to demonstrate the complex nature of running a secure platform from the lifecycle management perspective.

1. The linux distro (Bionic Beaver 18.04) was EOL in April, 2023.
2. Consequently, the Apache web server 2.4.29 was not receiving even backported security patches.
3. Also the MySQL backend 8.0.20 is not updated any longer.
4. The same holds true for the PHP version 7.2, which is no longer officially supported.
5. The Wordpress version 5.6.3 is not officially supported any more either.
6. And the same holds true for the Woocommerce plugin 6.0.0.

With this instance, the MySQL backend was also directly exposed to the Internet with password authentication enabled. The sad part of this equation was that it was an active market place, which was asking for your credit card information as an accepted form of payment.

An Example of the Good Bunch

What does the situation look like for the up-to-date versions, then?

Example: Woocommerce 7.8.0

The final example represents a platform, where the sysadmin had decided to solve some of the maintenance problems through cPanel. Compared to the previous examples this has its merits, as we can see below:

1. The linux distribution was unclear based on the available markers.
2. The Apache version number had also been masked, so no definite answer on its state.
3. The PHP version 7.4.33 on the other hand reached EOL in November 2022, even if it is still recommended by the Wordpress project.
4. The Wordpress version 6.2.2 is a supported version.
5. The Woocommerce version 7.8.0 is supported.

Having chosen to use cPanel to manage the service specific components, had resulted in a much more up-to-date deployment. This approach, however, leaves a lot to hope for from the attack surface perspective, since the cPanel management interface was exposed to the whole Internet. So in essence, somewhat succeeding in one aspect of cyber security had opened up another can of worms entirely. This was further exacerbated by the fact that the MySQL/MariaDb backend was also open to the Internet.

Secure Ecommerce Operations is not Easy

Let’s face it, running a secure ecommerce site with Woocommerce is not easy. The problem is not solved with simple patch management, since the varying components of a LAMP platform follow their own release schedules and support statements. The main competitor, Shopify, has a bit more modern tech stack, but does not lack complexity either.

Having a plan on which components to source from which provider and sticking to that will make the operator’s life easier. Segregating dependencies to a container model may be an option, but that alone is not a silver bullet, since managing those is not exactly a walk in the park either.

Even if the main focus of this write-up was life cycle management, the potential operator of an ecommerce platform will also have to think about their exposure in terms of attack surface management.

All in all, this research and the one I did earlier on jQuery has proven that looking at obsolescence is a viable tool for uncovering latent security problems, which ultimately stem from complexity.

---

Give Us Feedback or Subscribe to Our Newsletter

---