WooCommerce плъгини за плащане приемат фалшиви потвърждения

Между 14 и 19 октомври 2026 г. в NVD, американската национална база данни за уязвимости, излязоха записи за над десет плъгина за плащане в WordPress, повечето от тях за WooCommerce. Грешката е една и съща. Плъгинът приема подправено известие, че плащането е минало, и маркира поръчката като платена, макар клиентът да не е платил нищо. Нападателят няма нужда от акаунт в магазина. Всички записи са на WPScan, а оценките им по CVSS са предимно между 5.3 и 6.5 („средна“). В записите, които CISA е прегледала досега, няма данни за реални атаки.

Сред засегнатите няма модул на български доставчик. В записите не фигурират нито BORICA, ePay.bg и myPOS, нито плъгините на Еконт и Спиди. Същата грешка обаче може да има всеки модул за плащане, включително писан специално за един магазин, затова проверката по-долу важи за всички, които приемат плащане онлайн.

Как магазинът разбира, че поръчката е платена

Клиентът въвежда данните на картата си на страницата на банката или на платежния доставчик, не в магазина. След плащането доставчикът изпраща на магазина известие (webhook), че сумата е получена, или връща клиента обратно с резултата в адреса. Платежният плъгин чете известието и сменя статуса на поръчката на Processing, което в WooCommerce значи „платена“. Клиентът получава потвърждение, наличността намалява и поръчката влиза в списъка за изпращане.

Истинското известие е подписано с таен ключ, който знаят само доставчикът и магазинът, и плъгинът трябва да провери подписа, преди да приеме известието. Според записите в CVE при Walletdoc, Asaas и Cardinity ключът е празен по подразбиране, а при Visma Pay остава празен, докато търговецът не въведе данните си. Щом ключът е празен, плъгинът приема известие от когото и да е. При Sifalo Pay е достатъчен номерът на една истинска транзакция. Нападателят плаща една своя поръчка и с номера на това плащане маркира като платени други поръчки, които чакат плащане.

Какво рискува магазинът

Нападателят поръчва, „плаща“ с подправеното известие и чака стоката. Ако пратките тръгват с Еконт или Спиди веднага щом поръчката стане платена, никой не забелязва нищо, докато счетоводството не потърси плащането по сметката. При цифрови продукти, като курсове или електронни книги, достъпът до файла се дава веднага и загубата настъпва още в момента на поръчката.

Подобна грешка има и в WPForms Lite, плъгин за формуляри с над 5 милиона активни инсталации според wordpress.org. Във версиите преди 2.0.2.2 формуляр с плащане през PayPal Commerce приема попълване без плащане. Посетителят вижда потвърждението и на Вас идва обичайният имейл, а при PayPal няма нито поръчка, нито плащане.

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

Ето част от засегнатите плъгини. Ако при Вас някой от тях е с версия, по-стара от посочената, сайтът е засегнат.

Плъгините за плащане и версиите им се виждат в Plugins > Installed Plugins, а в Terminal на cPanel командата по-долу ги показва наведнъж. Как се работи с WP-CLI, е описано в ръководството за WP-CLI.

# cPanel > Terminal, в папката на сайта
# Само чете. Показва плъгините, свързани с плащания.
wp plugin list --fields=name,title,status,version \
  | grep -iE "pay|gateway|forms"

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

1. Обновете плъгина за плащане до последната версия. Ако за Вашия няма поправка, както е при Gateway for Vantiv on WC, изключете го и оставете на клиентите друг начин на плащане, докато излезе нова версия.
2. Отворете настройките на модула в WooCommerce > Settings > Payments и проверете дали тайният ключ за известията е попълнен. Всеки доставчик го нарича по свой начин, а стойността се взема от профила на магазина при доставчика. В няколко от уязвимите плъгини атаката минаваше именно през празното поле.
3. Преди да изпратите поръчка, платена онлайн, проверете дали сумата се вижда в профила при доставчика или по банковата сметка. Правете го задължително при необичайни поръчки (голяма сума, много бройки, нов клиент).

По същия начин сверете и платените поръчки от последните седмици. Филтрирайте WooCommerce > Orders по статус Processing или изпълнете командата по-долу, която показва и номера на транзакцията, записан от платежния плъгин.

# cPanel > Terminal, в папката на сайта
# Само чете. Поръчките в статус Processing от 1 октомври.
wp wc shop_order list --user=ADMIN_LOGIN \
  --status=processing --after=2026-10-01T00:00:00 \
  --fields=id,total,payment_method_title,transaction_id,date_paid

Сменете ADMIN_LOGIN с потребителското име на администратор, а датата с началото на периода, който искате да прегледате. Потърсете всеки номер от колоната transaction_id в профила при доставчика. Ако плащането липсва, задръжте поръчката, докато не изясните какво се е случило.

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

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

Източници

• NVD, CVE-2026-103307 (Walletdoc)
• NVD, CVE-2026-87974 (Asaas)
• NVD, CVE-2026-103308 (Visma Pay)
• NVD, CVE-2026-103324 (Cardinity)
• NVD, CVE-2026-94261 (Sifalo Pay)
• NVD, CVE-2026-92428 (Rede Itaú)
• NVD, CVE-2026-92429 (Rede Itaú)
• NVD, CVE-2026-94273 (Snap Finance)
• NVD, CVE-2026-106014 (Gateway for Vantiv on WC)
• NVD, CVE-2026-82844 (WPForms Lite)
• WPScan, Walletdoc Payment Gateway for WooCommerce
• WPScan, Visma Pay for WooCommerce
• WPScan, Snap Finance
• WPScan, Gateway for Vantiv on WC
• WPScan, WPForms Lite
• WordPress.org, WPForms Lite
• WooCommerce, wc shop_order
• WooCommerce, WC CLI examples
• WP-CLI, wp plugin list