Прегледах целия ZIP. Плъгинът е малък — 2 файла, няма обфускация, eval, shell команди, скрити файлове или очевиден malware. PHP синтаксисът е валиден.
За публичен WooCommerce сайт обаче не бих го инсталирал в този вид.
Най-сериозните проблеми:
- Критичен: еднакъв hardcoded API token
define('PBX_SHARED_TOKEN', 'pbx-bgtel-2026-a7f3c9e2b4d16580');
Той е директно в кода. Ако този ZIP се дава на повече клиенти, практически трябва да приемеш, че token-ът е публичен.
С него endpoint-ът позволява:
- да се получи order_id + телефон на клиент;
- да се променя статусът на произволна съществуваща поръчка чрез return_request;
- да се влияе кои поръчки се прозвъняват чрез nocall.
IP проверката не решава това, защото условието е:
if (!wc_pbx_validate_source('voip.bgtel.tel') && !wc_pbx_token_ok())
Тоест валиден token сам по себе си е достатъчен.
- Критичен privacy проблем: записва token-и и телефони в базата
Логва цялото:
'request_data' => json_encode($_GET),
'response_data' => json_encode($response),
Следователно при dial_request в таблицата остават:
- token;
- order ID;
- телефонният номер на клиента;
- IP;
- timestamp.
Няма и cleanup/retention. Таблицата може да расте безкрайно.
Освен това token в GET URL може да попадне и в:
- nginx/Apache access log;
- reverse proxy логове;
- WAF/CDN логове;
- monitoring системи.
API credentials не трябва да се пращат по този начин.
- Много лошо operational поведение: създава PHP файл извън плъгина
При активация:
file_put_contents(ABSPATH . 'pbx_api.php', ...)
Тоест създава:
/public_html/pbx_api.php
И дори документацията изрично казва, че endpoint-ът остава да работи след деактивиране.
Още по-лошо: admin_init проверява файла и може автоматично да го презапише. Ако вече съществува друг /pbx_api.php, който няма очаквания version marker, плъгинът може да го унищожи.
За WordPress плъгин това е неприемливо поведение според мен.
- Умишлено затруднява премахването си
Прави:
unset($links['deactivate'], $links['delete']);
Технически администраторът пак може да го премахне по други начини, но плъгин не трябва да крие стандартните WordPress контроли.
И най-важното: дори да изтриеш директорията му, /pbx_api.php остава.
Тоест може да си мислиш, че плъгинът е махнат, а API endpoint-ът да продължава да приема заявки.
- HPOS съвместимостта е съмнителна
Работи с WooCommerce поръчки чрез:
get_post_meta()
update_post_meta()
вместо WooCommerce CRUD:
$order->get_meta()
$order->update_meta_data()
$order->save()
При съвременен WooCommerce с HPOS това е лош подход и може да има проблеми при конфигурации без синхронизация към wp_posts/wp_postmeta.
За нов плъгин през 2026 г. това бих го счел за реален дефект.
- Няма locking при взимане на поръчка
dial_request намира pending order и го връща, но не го „claim“-ва атомарно.
Две почти едновременни заявки от PBX могат да получат една и съща поръчка и да стартират две обаждания.
_pbx_seen се записва, но не участва в избора и не предотвратява race condition.
- Повторните обаждания не се контролират от плъгина
За status 95:
wc_pbx_find_retry()
може многократно да върне същата поръчка. Няма:
- брояч на опитите;
- минимален интервал;
- максимален брой опити.
Коментарът казва „до лимита“, но такъв лимит в кода няма. Очевидно се разчита изцяло на външната централа.
- orderby => rand върху поръчки
За retry:
'orderby' => 'rand'
При голям магазин това може да бъде неоптимално. Не е security проблем, но е ненужно.
- Несъответствие README ↔ реален код
README е за версия 2.0.1, плъгинът е 2.1.4.
README твърди, че COD се звъни винаги, а другите методи се включват от WooCommerce настройки. Реалният код вече няма такива настройки и централата управлява nocall.
Това подсказва, че документацията не се поддържа надеждно.
Положителното е, че не виждам класически backdoor или malware. Няма:
- eval/base64_decode;
- изпълнение на shell;
- remote code download;
- създаване на WordPress потребители;
- директен подозрителен SQL;
- произволно четене на файлове;
- очевиден XSS в админ страницата.
Затова оценката ми е:
Malware: не изглежда да е malware.
Качество на кода: средно/ниско.
Security design: слаб.
Подходящ за публичен production WooCommerce: не в сегашния вид.
Най-опасният сценарий е прост: ако някой получи този ZIP или token-а, може да направи заявка към известен магазин с /pbx_api.php, да получава телефоните на клиентите му и да променя статуси на поръчки.
Преди да го сложа бих изискал минимум: уникален secret за всеки магазин, authentication в HTTP header вместо GET, никакво логване на secret/телефон, endpoint през WordPress REST API вместо root PHP файл, HPOS CRUD, atomic locking и нормална деинсталация.
Не изпуска нито един клиент. Обажданията се повтарят до установяване на контакт. Не отговори ли клиентът — може да върне обаждането и да потвърди по-късно.
Блокирай некоректните — веднъж завинаги. Върнал ти е пратка? Блокираш номера и той повече не може да поръчва от нито един магазин, който ползва системата.
Обаждане, а не SMS. SMS-ите често не стигат до пренесени номера и остават непрочетени. Гласовото обаждане е пряк контакт и мигновена реакция.
Обади се сега: 0888913737
