Gtm Server Side Wordpress Plugin
Monthly
Unauthenticated visitors to WordPress sites running the GTM Server Side plugin (stape.io, also published as Stape Conversion Tracking) versions 2.0.0 through 2.1.46 can cause another customer's complete WooCommerce order record - transaction ID, items, value, shipping and, when the plugin's 'User Data' option is enabled, name, email and billing address - to be rendered into the page's JavaScript dataLayer simply by setting the gtm_server_side_order_id cookie to an enumerable, sequential order ID and loading any page of the site. The root cause is that the guard restricting purchase-event output to the WooCommerce order-received endpoint was commented out, so the wp_footer hook trusts an integrity-free client-side value; version 2.1.47 moved the order ID into WC()->session and closed the direct cookie manipulation path, but full remediation only arrived in 2.1.48, which adds a once-per-order sent flag to stop full-page caching plugins replaying a legitimate purchase event to later anonymous visitors. CVSS 4.0 scores this 8.7 (AV:N/AC:L/PR:N/UI:N/VC:H) and the practical prerequisite is WooCommerce plus the 'Ecommerce' dataLayer feature being enabled; a public proof-of-concept reproduction procedure is documented in the GitHub advisory, though it is not verified as working exploit code, and no confirmed active exploitation (CISA KEV) is indicated. Priority is set to this_week rather than emergency because exploitation depends on that configuration prerequisite and yields read-only disclosure.
Unauthenticated visitors to WordPress sites running the GTM Server Side plugin (stape.io, also published as Stape Conversion Tracking) versions 2.0.0 through 2.1.46 can cause another customer's complete WooCommerce order record - transaction ID, items, value, shipping and, when the plugin's 'User Data' option is enabled, name, email and billing address - to be rendered into the page's JavaScript dataLayer simply by setting the gtm_server_side_order_id cookie to an enumerable, sequential order ID and loading any page of the site. The root cause is that the guard restricting purchase-event output to the WooCommerce order-received endpoint was commented out, so the wp_footer hook trusts an integrity-free client-side value; version 2.1.47 moved the order ID into WC()->session and closed the direct cookie manipulation path, but full remediation only arrived in 2.1.48, which adds a once-per-order sent flag to stop full-page caching plugins replaying a legitimate purchase event to later anonymous visitors. CVSS 4.0 scores this 8.7 (AV:N/AC:L/PR:N/UI:N/VC:H) and the practical prerequisite is WooCommerce plus the 'Ecommerce' dataLayer feature being enabled; a public proof-of-concept reproduction procedure is documented in the GitHub advisory, though it is not verified as working exploit code, and no confirmed active exploitation (CISA KEV) is indicated. Priority is set to this_week rather than emergency because exploitation depends on that configuration prerequisite and yields read-only disclosure.