GTM Server Side leaks customer orders, update to 2.1.48

Q: How does an attacker read someone else's order through GTM Server Side?

The plugin remembers the latest order in a cookie named gtm_server_side_order_id, which sits in the visitor's browser and can be changed by the visitor. On every page the plugin reads the number from the cookie, loads that order from the database and writes it into the page. WooCommerce order numbers run in sequence, so the attacker puts in someone else's number, opens any page and reads the order without the customer noticing.

# TagsSecurityWooCommerceWordPress

The WPhost team27 Oct 202610 min read

On 23 October 2026 the US National Vulnerability Database (NVD) published CVE-2026-55826, a vulnerability in Stape's GTM Server Side plugin, which newer versions call Stape Conversion Tracking. A visitor without an account can make the store print another customer's order into the page's code and, with one setting switched on, that customer's name, address, email and phone number as well. Versions 2.0.0 to 2.1.47 inclusive are affected, and the fix is in 2.1.48. According to wordpress.org the plugin has more than 10,000 active installations.

The fix is not new. Stape shipped it in June 2026, and as of 27 October the latest version is 2.3.10. If the plugin gets updated regularly, your store is probably already safe. If it has been sitting on an old version, check whether the flaw exposed your customers' data, because under the GDPR that data is your responsibility.

What leaks from an order

The plugin passes purchase data to Google Tag Manager through the dataLayer, a list of values in the page's JavaScript that Google Analytics and ad pixels read to learn what was bought. According to the security advisory in the plugin's GitHub repository, an attacker can make the store write an order of their choosing into that list.

The order number, total, tax, shipping, currency, coupon codes and purchased products always come out. If "Add user data to Data Layer events" is switched on in the plugin's settings, so do the first and last names, the billing and shipping addresses, the email address and the phone number. The code of version 2.1.46 in the wordpress.org repository shows this.

For a Bulgarian store that ships with Econt or Speedy on cash on delivery, that is exactly the set a scammer needs to send a customer a convincing text about an "extra charge on your parcel". With the order and the address in the message, the customer has no reason to doubt it.

The vulnerability scores 8.7 on CVSS 4.0, "high". The score comes from GitHub, and NVD has not calculated its own. The CVSS score guide explains what such a score means.

How the attack works

The plugin remembers the latest order in a cookie named gtm_server_side_order_id, which holds the order number. The cookie lives in the visitor's browser, and the visitor can change it. On every page of the site, not only the page shown after checkout, the plugin reads the number from the cookie, loads that order from the database and writes it into the page. The check that should have limited this to the order confirmation page is disabled in the code (turned into a comment).

According to the GitHub advisory, WooCommerce order numbers run in sequence, so all an attacker has to do is put someone else's order number in the cookie, open any page and read the order. No account is needed, and the customer notices nothing.

Version 2.1.47 moved the order number into the WooCommerce session, which lives on the server, and that stopped the cookie trick. The order data still appeared on every page, though, and the advisory warns that a site with full-page caching (WP Rocket or LiteSpeed Cache, for example) could store a page carrying a real customer's purchase and serve it to every visitor after them. That is why 2.1.47 counts as a partial fix. From 2.1.48 the plugin sends each order's data only once.

Neither the GitHub advisory nor the NVD and CVE.org records report attacks using this vulnerability.

Is your store affected?

The flaw only affects WooCommerce stores where the plugin is on a version from 2.0.0 to 2.1.47 and "Add ecommerce Data Layer events" is switched on in the Data Layer tab of its settings. Customers' personal data comes out if "Add user data to Data Layer events" is switched on there too.

You can find the plugin under Plugins > Installed Plugins. Older versions are called GTM Server Side and newer ones Stape Conversion Tracking, so look for both names. In cPanel's Terminal, the commands below show the version and both settings. The WP-CLI guide explains how to work with WP-CLI.

Bash

# cPanel > Terminal, in the site's folder
# Read-only. The plugin version and both settings.
wp plugin list --fields=name,title,status,version \
  --skip-plugins --skip-themes | grep -i gtm-server-side
wp option get gtm_server_side_data_layer_ecommerce \
  --skip-plugins --skip-themes
wp option get gtm_server_side_data_layer_user_data \
  --skip-plugins --skip-themes

A value of yes means the setting is on. An empty line, or an error saying the option does not exist, means it is off.

What to do

Update the plugin to 2.1.48 or later, ideally to the latest version. If you have a staging copy of the store, try it there first and place a test cash on delivery order to see that the purchase still reaches Google Analytics. The guide to updating plugins shows how to update without putting orders at risk.
Clear the page cache straight after the update, as the advisory recommends, and the CDN's cache too if it stores whole pages. The update does not remove pages that are already cached.
If you do not use customer data in your marketing, switch off "Add user data to Data Layer events". What is not in the page's code cannot leak through the next bug.

As the store owner you are the controller of your customers' personal data. A flaw that lets a stranger read a customer's order does not, on its own, prove that anyone did. It does oblige you to assess whether a personal data breach took place.

According to the European Data Protection Board, a controller documents every such breach, even one it does not report. If the breach is likely to put people at risk, the controller notifies the supervisory authority within 72 hours of becoming aware of it. In Bulgaria that is the Commission for Personal Data Protection. Where the risk is high, the customers themselves are also told without undue delay. That is what Articles 33 and 34 of the GDPR require.

Write down which version was installed and until when, whether the two settings were on and whether the site caches whole pages, even if you decide there was no breach. Standard server logs do not keep visitors' cookies, so they can hardly prove or rule out an attack. Whether to notify anyone, and whom, is a legal decision. If in doubt, ask a lawyer or your data protection officer if you have one.

What we do

With vulnerability (CVE) monitoring we match the plugins, theme and WordPress on your site against the vulnerability (CVE) databases every day. As soon as a vulnerability appears in something you use, we send you an alert and update, trying the update on a copy in staging first. Your site can be hosted anywhere. If you would like us to add your store, write to us through the inquiry form.

Frequently asked questions

What is CVE-2026-55826 in the GTM Server Side plugin?

A vulnerability in Stape's GTM Server Side plugin, called Stape Conversion Tracking in newer versions, published in the NVD on 23 October 2026. A visitor without an account can make the store print another customer's order into the page's code and, with one setting switched on, that customer's name, address, email and phone number too. Versions 2.0.0 to 2.1.47 inclusive are affected.

Which version of GTM Server Side fixes the vulnerability?

GTM Server Side 2.1.48. Stape shipped the fix back in June 2026, and as of 27 October the latest version is 2.3.10. Version 2.1.47 is only a partial fix, so update to 2.1.48 at least, and ideally to the latest version.

Which customer data leaks through GTM Server Side?

The order number, total, tax, shipping, currency, coupon codes and purchased products always come out. If "Add user data to Data Layer events" is on in the plugin's settings, so do the names, the billing and shipping addresses, the email and the phone number. For a store shipping with Econt or Speedy on cash on delivery, that is exactly what a scammer needs for a convincing text about an "extra charge on your parcel".

How does an attacker read someone else's order through GTM Server Side?

The plugin remembers the latest order in a cookie named gtm_server_side_order_id, which sits in the visitor's browser and can be changed by the visitor. On every page the plugin reads the number from the cookie, loads that order from the database and writes it into the page. WooCommerce order numbers run in sequence, so the attacker puts in someone else's number, opens any page and reads the order without the customer noticing.

Is my store affected by the GTM Server Side vulnerability?

WooCommerce stores are affected when the plugin is on a version from 2.0.0 to 2.1.47 and "Add ecommerce Data Layer events" is on in the Data Layer tab of its settings. Customers' personal data comes out if "Add user data to Data Layer events" is on there too. Look for the plugin under Plugins > Installed Plugins under both names, GTM Server Side and Stape Conversion Tracking.

Why should I clear the cache after updating GTM Server Side?

According to the GitHub advisory, a site with full-page caching, such as WP Rocket or LiteSpeed Cache, may have stored a page carrying a real customer's purchase and serve it to every visitor after them. The update does not remove pages that are already cached. So clear the page cache straight after the update, and the CDN cache too if it stores whole pages.

Do I have to notify the data protection authority about the GTM Server Side flaw?

The flaw on its own does not prove anyone read an order, but it obliges you to assess whether a personal data breach took place. If a breach is likely to put people at risk, the controller notifies the supervisory authority, in Bulgaria the Commission for Personal Data Protection, within 72 hours, and where the risk is high the customers too. Whether and whom to notify is a legal decision, so if in doubt ask a lawyer or your data protection officer.

What should I record if I decide there was no data breach?

Write down which GTM Server Side version was installed and until when, whether the two settings were on and whether the site caches whole pages. According to the European Data Protection Board, a controller documents every breach, even one it does not report. Standard server logs do not keep visitors' cookies, so they can hardly prove or rule out an attack.

Sources