НОВИНА
Checkout Files Upload за WooCommerce приема файлове от всеки. Вижте дали Вашият е засегнат
Сигурност

GTM Server Side показва чужди поръчки, обновете до 2.1.48

# ЕтикетиСигурностWooCommerceWordPress
Екипът на WPhost9 мин четене

На 23 октомври 2026 г. в американската национална база данни за уязвимости (NVD) беше публикувана CVE-2026-55826, уязвимост в плъгина GTM Server Side на Stape, който в по-новите си версии се казва Stape Conversion Tracking. Посетител без акаунт може да накара магазина да покаже в кода на страницата чужда поръчка, а при една включена настройка и името, адреса, имейла и телефона на клиента. Засегнати са версиите от 2.0.0 до 2.1.47 включително, поправката е във версия 2.1.48. Според wordpress.org плъгинът има над 10 000 активни инсталации.

Поправката не е от вчера. Stape я пусна през юни 2026 г., а към 27 октомври най-новата версия е 2.3.10. Ако плъгинът се обновява редовно, магазинът Ви вероятно вече е защитен. Ако е стоял на стара версия, проверете дали уязвимостта не е изложила данни на Ваши клиенти, защото по GDPR за тях отговаряте Вие.

Какво изтича от поръчката

Плъгинът подава данните за покупките към Google Tag Manager през dataLayer, списък с данни в JavaScript кода на страницата, от който Google Analytics и рекламните пиксели разбират какво е купено. Според бележката за сигурност в хранилището на плъгина в GitHub нападателят може да накара магазина да впише в този списък поръчка по свой избор.

Винаги излизат номерът на поръчката, сумата, данъкът, доставката, валутата, кодовете за отстъпка и купените продукти. Ако в настройките на плъгина е включено Add user data to Data Layer events, излизат и имената, адресът за фактуриране и адресът за доставка, имейлът и телефонът. Това се вижда в кода на версия 2.1.46 в хранилището на wordpress.org.

За магазин, който праща с Еконт или Спиди срещу наложен платеж, това са точно данните, с които измамник може да прати на клиента убедителен SMS за „доплащане по пратката“. Клиентът няма причина да се усъмни, щом в съобщението са поръчката и адресът му.

Уязвимостта е с оценка 8.7 по CVSS 4.0, „висока“. Оценката е от GitHub, а NVD не е изчислила своя. Какво значи такава оценка, е обяснено в ръководството за CVSS.

Как работи атаката

Плъгинът помни последната поръчка в бисквитка с име gtm_server_side_order_id, в която стои номерът на поръчката. Бисквитката се пази в браузъра на посетителя и той може да я промени. На всяка страница на сайта, а не само на страницата след поръчка, плъгинът чете номера от бисквитката, взима поръчката от базата данни и я вписва в кода. Проверката, която трябваше да ограничи това до страницата с потвърждението, е изключена в кода (превърната в коментар).

Според бележката в GitHub номерата на поръчките в WooCommerce вървят подред и нападателят трябва само да сложи в бисквитката чужд номер, да отвори която и да е страница и да прочете поръчката. Не му трябва акаунт, а клиентът не забелязва нищо.

Версия 2.1.47 премести номера в сесията на WooCommerce, която се пази на сървъра, и спря подмяната. Данните обаче продължиха да се показват на всяка страница, а според бележката сайт с кеширане на цели страници (например WP Rocket или LiteSpeed Cache) може да запише в кеша страница с покупката на истински клиент и да я показва на всеки следващ посетител. Затова 2.1.47 се води частична поправка. Във версия 2.1.48 плъгинът изпраща данните на всяка поръчка само веднъж.

Нито бележката в GitHub, нито записите в NVD и CVE.org съобщават за атаки с тази уязвимост.

Засегнат ли е Вашият магазин?

Уязвимостта засяга само магазини с WooCommerce, в които плъгинът е на версия от 2.0.0 до 2.1.47 и в раздела Data Layer на настройките му е включено Add ecommerce Data Layer events. Личните данни на клиентите излизат, ако там е включено и Add user data to Data Layer events.

Плъгинът се вижда в Plugins > Installed Plugins. В старите версии се казва GTM Server Side, а в по-новите Stape Conversion Tracking, затова търсете и двете имена. В Terminal на cPanel командите по-долу показват версията и двете настройки. Как се работи с WP-CLI, е описано в ръководството за WP-CLI.

Bash
# cPanel > Terminal, в папката на сайта
# Само чете. Версията на плъгина и двете настройки.
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

Стойност yes значи, че настройката е включена. Празен ред или грешка, че опцията не съществува, значи, че е изключена.

Какво да направите

  1. Обновете плъгина до 2.1.48 или по-нова версия, най-добре до последната. Ако имате копие на магазина в staging, пробвайте първо там и направете тестова поръчка с наложен платеж, за да видите, че покупката стига до Google Analytics. Как да обновявате без риск за поръчките, е описано в ръководството за обновяване на плъгини.
  2. Изчистете кеша на страниците веднага след обновлението, както препоръчва бележката, и този на CDN, ако той кешира цели страници. Обновлението не трие страниците, които вече са в кеша.
  3. Ако не ползвате данните за клиента в маркетинга си, изключете Add user data to Data Layer events. Каквото не стои в кода на страницата, не може да изтече при следваща грешка.

Какво значи това по GDPR

Като търговец Вие сте администратор на личните данни на клиентите си. Уязвимост, през която чужд човек може да прочете поръчката на клиент, не доказва сама по себе си, че някой го е направил. Задължава Ви обаче да прецените дали е имало нарушение на сигурността на личните данни.

Според Европейския комитет по защита на данните администраторът документира всяко такова нарушение, дори когато не го съобщава. Ако е вероятно то да породи риск за хората, администраторът уведомява надзорния орган в рамките на 72 часа, откакто е разбрал за него. В България това е Комисията за защита на личните данни. Когато рискът е висок, без ненужно забавяне се уведомяват и самите клиенти. Така го уреждат членове 33 и 34 от GDPR.

Запишете коя версия на плъгина е била инсталирана и докога, дали двете настройки са били включени и дали сайтът кешира цели страници, дори да решите, че нарушение няма. Стандартните логове на сървъра не пазят бисквитките на посетителите, затова по тях атака трудно се доказва или изключва. Решението дали и кого да уведомите е правно. При съмнение се посъветвайте с юрист или с длъжностното лице по защита на данните, ако имате такова.

Какво правим ние

При наблюдението на уязвимостите всеки ден сверяваме плъгините, темата и WordPress на Вашия сайт с базите данни с уязвимости (CVE). Щом се появи уязвимост в нещо, което използвате, изпращаме Ви сигнал и обновяваме, като първо пробваме обновлението на копие в staging. Сайтът може да е хостнат където и да е. Ако искате да включим и Вашия магазин, пишете ни през формата за запитване.

Често задавани въпроси

Какво е CVE-2026-55826 в плъгина GTM Server Side?

Уязвимост в плъгина GTM Server Side на Stape, който в по-новите версии се казва Stape Conversion Tracking, публикувана в NVD на 23 октомври 2026 г. Посетител без акаунт може да накара магазина да изпише в кода на страницата чужда поръчка, а при една включена настройка и името, адреса, имейла и телефона на клиента. Засегнати са версиите от 2.0.0 до 2.1.47 включително.

Коя версия на GTM Server Side поправя уязвимостта?

GTM Server Side 2.1.48. Stape пусна поправката още през юни 2026 г., а към 27 октомври последната версия е 2.3.10. Версия 2.1.47 е само частична поправка, затова обновете поне до 2.1.48, а най-добре до последната версия.

Кои данни на клиентите изтичат през GTM Server Side?

Номерът на поръчката, сумата, данъкът, доставката, валутата, кодовете за отстъпка и купените продукти излизат винаги. Ако в настройките на плъгина е включено „Add user data to Data Layer events“, излизат и имената, адресите за фактуриране и доставка, имейлът и телефонът. За магазин, който праща с Еконт или Спиди с наложен платеж, това е точно наборът, с който измамник праща убедително съобщение за „доплащане по пратката“.

Как нападателят чете чужда поръчка през GTM Server Side?

Плъгинът помни последната поръчка в бисквитката gtm_server_side_order_id, която е в браузъра на посетителя и той може да я промени. На всяка страница плъгинът чете номера от бисквитката, зарежда тази поръчка от базата и я изписва в страницата. Номерата на поръчките в WooCommerce са поредни, така че нападателят слага чужд номер, отваря произволна страница и чете поръчката, без клиентът да забележи.

Засегнат ли е магазинът ми от уязвимостта в GTM Server Side?

Засегнати са магазините с WooCommerce, в които плъгинът е на версия от 2.0.0 до 2.1.47 и в раздела Data Layer на настройките му е включено „Add ecommerce Data Layer events“. Личните данни на клиентите излизат, ако там е включено и „Add user data to Data Layer events“. Търсете плъгина в Plugins > Installed Plugins и под двете имена, GTM Server Side и Stape Conversion Tracking.

Защо трябва да изчистя кеша след обновяване на GTM Server Side?

Според бюлетина в GitHub сайт с кеш на цели страници, например с WP Rocket или LiteSpeed Cache, може да е запазил страница с покупката на истински клиент и да я показва на всеки следващ посетител. Обновяването не маха вече кешираните страници. Затова изчистете кеша на страниците веднага след обновяването, а също и кеша на CDN, ако той пази цели страници.

Трябва ли да уведомя КЗЛД за уязвимостта в GTM Server Side?

Самата уязвимост не доказва, че някой е прочел поръчка, но Ви задължава да прецените дали е имало нарушение на сигурността на личните данни. Ако нарушението вероятно създава риск за хората, администраторът уведомява надзорния орган, в България Комисията за защита на личните данни, до 72 часа, а при висок риск и самите клиенти. Дали и кого да уведомите е правно решение, така че при съмнение попитайте юрист или длъжностното лице по защита на данните.

Какво да запиша, ако реша, че нарушение на данните не е имало?

Запишете коя версия на GTM Server Side е била инсталирана и до кога, дали двете настройки са били включени и дали сайтът кешира цели страници. Според Европейския комитет по защита на данните администраторът документира всяко нарушение, дори такова, за което не уведомява. Стандартните логове на сървъра не пазят бисквитките на посетителите, така че трудно доказват или изключват атака.

Източници

# ЕтикетиСигурностWooCommerceWordPress
СподелетеFacebookXLinkedIn