wp2shell: критичната уязвимост в WordPress, която позволява превземане на сайт без парола

Актуализирано на 23 юли 2026 г.

На 17 юли 2026 г. WordPress публикува извънредни версии за сигурност, които отстраняват една от най-сериозните уязвимости, откривани през последните години в ядрото на платформата.

Уязвимостта получи името wp2shell и позволява на външен нападател да достигне до изпълнение на PHP код върху сървъра, без да има потребителски профил, без да знае парола и без сайтът да използва уязвим плъгин или тема.

Проблемът е особено опасен, защото се намира в самия WordPress Core и засяга стандартни инсталации с активен REST API. Засегнат може да бъде както обикновен корпоративен сайт, така и голям WooCommerce магазин с хиляди клиенти и поръчки.

На 21 юли 2026 г. CISA добави свързаните уязвимости в своя каталог на активно експлоатираните уязвимости. Следователно вече не говорим само за теоретичен риск или лабораторен експеримент. Засегнатите сайтове трябва да бъдат обновени незабавно, а тези, които са били публично достъпни с уязвима версия, трябва да бъдат проверени за евентуално компрометиране.

Най-важното накратко

Показател	Информация
Име на експлоатационната верига	wp2shell
Основна уязвимост	CVE-2026-63030
Свързана SQL injection уязвимост	CVE-2026-60137
Необходим потребителски профил	Не
Необходима парола	Не
Необходим уязвим плъгин	Не
Необходимо действие от администратор	Не
Възможен резултат	Създаване на администратор и изпълнение на PHP код
Засегнати от пълната RCE верига	WordPress 6.9.0–6.9.4 и 7.0.0–7.0.1
Поправени версии	WordPress 6.9.5 и 7.0.2
Статус към 23 юли 2026 г.	Активно експлоатирана
Препоръчително действие	Незабавно обновяване и проверка за компрометиране

Официалното съобщение на WordPress потвърждава, че заради сериозността на проблема са активирани принудителни автоматични актуализации за засегнатите сайтове. Това обаче не е гаранция, че актуализацията е достигнала до всяка инсталация. Реално инсталираната версия трябва да бъде проверена ръчно.

Какво представлява wp2shell?

wp2shell не е една-единствена програмна грешка, която директно изпълнява PHP код. Това е сложна експлоатационна верига, която комбинира две отделни уязвимости и няколко легитимни вътрешни механизма на WordPress.

Двете основни уязвимости са:

CVE-2026-63030 – объркване между валидацията и изпълнението на маршрути в REST API Batch endpoint-а;
CVE-2026-60137 – неправилна обработка на параметъра author__not_in в WP_Query, позволяваща SQL injection.

Първата уязвимост позволява на нападателя да заобиколи правилната проверка на подадените данни. Втората му позволява да достигне до SQL заявка с неподходящо обработена стойност.

След това атаката използва вътрешния кеш на WordPress, oEmbed функционалността, специалния тип публикации customize_changeset и динамичните WordPress hooks, за да превърне първоначално read-only SQL injection в административен достъп.

В стандартна конфигурация създаденият администратор може да инсталира злонамерен плъгин. Така нападателят достига до изпълнение на произволен PHP код върху сървъра – т.нар. Remote Code Execution, или RCE.

Защо Remote Code Execution е толкова опасно?

Remote Code Execution е една от най-тежките категории уязвимости.

Тя означава, че външен човек може да изпълнява собствен програмен код в средата на засегнатия сайт. На практика това може да му позволи да:

създава и изтрива WordPress потребители;
променя роли и права;
инсталира злонамерени плъгини;
чете и променя файлове, достъпни за PHP процеса;
извлича информация от базата данни;
променя съдържанието на сайта;
инжектира JavaScript в checkout страницата;
пренасочва клиенти към фалшиви платежни страници;
създава скрит постоянен достъп;
изпраща спам или фишинг съобщения;
използва сайта за разпространение на зловреден код;
атакува други системи, до които сървърът има достъп;
изтрие или криптира файлове и данни.

RCE в WordPress не означава автоматично, че нападателят получава root достъп до целия сървър. Той обаче получава правата на системния потребител, под който работи PHP. В зависимост от конфигурацията това може да постави под риск и други сайтове, файлове, резервни копия или ключове, съхранявани под същия хостинг акаунт.

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

Пълната техническа верига е необичайно сложна. За да разберем риска, е важно да разграничим отделните ѝ етапи.

1. Атаката започва от публичния WordPress REST API

REST API е стандартна част от WordPress. Той се използва от редактора, различни административни функции, WooCommerce, мобилни приложения и множество външни интеграции.

WordPress разполага и с Batch API endpoint. Неговата задача е да позволи изпращането на няколко вътрешни REST заявки в рамките на една основна HTTP заявка.

Самото наличие на публичен REST API не е уязвимост. При нормална работа всяка вътрешна заявка трябва да премине през:

проверка на задължителните параметри;
проверка на типа и формата на стойностите;
санитизация на входните данни;
проверка на правата;
изпълнение от правилния route handler.

Проблемът е в начина, по който засегнатите версии обработват група от Batch заявки.

2. WordPress валидира една заявка, но може да изпълни друга

При Batch обработката WordPress поддържа два паралелни списъка.

В единия се записват резултатите от валидацията, а в другия – маршрутите и програмните функции, които трябва да изпълнят съответните заявки.

При специално подготвена невалидна подзаявка WordPress добавя грешката в списъка с резултатите от валидацията, но не добавя съответстващ елемент в списъка с маршрутите. От този момент позициите в двата списъка вече не съвпадат.

Резултатът е, че една подзаявка може да бъде проверена според правилата на маршрут А, но след това да бъде предадена за изпълнение на маршрут Б.

Представете си два паралелни регистъра в куриерска фирма. В единия се записва кой пакет е проверен, а в другия – на кой получател трябва да бъде доставен. Ако повреден пакет бъде записан само в първия регистър, всички следващи редове се разместват. Така пакетът минава проверката за получател А, но после се доставя на получател Б.

Точно това разминаване стои в основата на т.нар. batch-route confusion.

Важно е да се отбележи, че уязвимостта не изключва автоматично всички проверки за права в WordPress. Тя разминава валидацията и реалния route handler. В конкретната експлоатационна верига крайният използван маршрут е публично достъпен.

3. Непроверена стойност достига до `WP_Query`

Публичният REST API позволява списъкът с публикации да бъде филтриран, включително чрез изключване на определени автори.

Подаденият параметър нормално трябва да бъде масив, съдържащ само цели числа. След правилна валидация той достига до вътрешния параметър author__not_in в WP_Query.

Проблемът е в следната разлика:

когато стойността е масив, елементите се преобразуват до цели числа;
когато стойността е единичен текстов низ, тази защита не се прилага по същия начин;
впоследствие стойността може да достигне до SQL конструкцията без необходимата обработка.

При нормална директна REST заявка неправилният тип би бил отхвърлен още на входа. Уязвимостта в Batch API обаче позволява тази проверка да бъде заобиколена.

Така се достига до SQL injection.

4. SQL injection първоначално позволява „само четене“

SQL injection се намира в SELECT заявка. Първоначално това позволява на нападателя да чете стойности от базата и да манипулира формата на върнатите резултати.

Не е технически коректно да се твърди, че нападателят директно използва SQL injection, за да създаде администратор или да запише PHP файл.

WordPress съхранява паролите като hash стойности, така че прочитането на администраторската парола в чист текст не е част от публично описаната атака. Не е необходимо и разбиване на паролата.

Изследователите използват значително по-сложен подход.

5. Подменят се временни WordPress обекти

WordPress съхранява заредените WP_Post обекти във временен кеш в рамките на текущата заявка.

Чрез SQL injection нападателят може да накара резултатите от базата да изглеждат като несъществуващи или модифицирани WordPress публикации. Системата приема тези резултати и ги поставя във вътрешния си кеш.

Това е важно разграничение: става дума за вътрешен request-local object cache, а не за кеша на страниците.

Следователно използването на WP Rocket не защитава от wp2shell. WP Rocket е решение за производителност и кеширане на съдържание, а не защитна стена и не коригира уязвимия код в WordPress Core.

6. Легитимна WordPress функционалност записва подменените данни

Следващият етап използва oEmbed механизма на WordPress.

WordPress записва част от oEmbed резултатите като специални редове от тип oembed_cache. Комбинацията от подменения временен кеш и нормалната логика за синхронизация позволява определени контролирани данни да бъдат превърнати в реални записи.

Атаката използва и механизма на WordPress за откриване и поправяне на цикли в йерархията на публикациите.

Нападателят не записва директно в базата чрез SQL injection. Вместо това той подменя временната справка, а легитимна вътрешна процедура на WordPress приема тази справка за вярна и сама записва част от данните.

7. Създава се временен административен контекст

WordPress използва специален тип публикации, наречен customize_changeset, за съхраняване на подготвени промени по настройките и дизайна на сайта.

При прилагане на такава промяна WordPress временно може да изпълни операцията от името на потребителя, посочен в changeset записа.

Чрез вече изградената верига нападателят успява да подготви фалшифициран changeset, който посочва реален администратор. За кратък период заявката започва да се обработва в административен контекст.

Това не е нормален login и не е открадната администраторска сесия.

8. Първоначалната заявка се изпълнява повторно като администратор

Чрез динамичен WordPress hook се предизвиква повторно обработване на първоначалната заявка, преди временният административен контекст да бъде прекратен.

В Batch заявката предварително е включена операция за създаване на нов WordPress администратор.

При първото изпълнение тя е отказана, защото заявката идва от анонимен посетител. При повторното изпълнение обаче WordPress все още работи с временно активните административни права и операцията успява.

Резултатът е постоянен администраторски профил, контролиран от нападателя.

9. От администраторски достъп до изпълнение на PHP код

В стандартна WordPress конфигурация администраторът може да инсталира и активира плъгини.

След създаването на злонамерения администратор нападателят може да качи плъгин, съдържащ PHP код. Това завършва веригата до Remote Code Execution.

Конфигурации като DISALLOW_FILE_MODS, ограничени файлови права или други ограничения на ниво хостинг могат да затруднят конкретната последна стъпка. Те обаче не премахват уязвимостта, не предотвратяват изтичането на данни и не правят административното компрометиране приемливо.

Конкретен пример с WooCommerce магазин

Представете си онлайн магазин, който работи с WordPress 6.9.4 и WooCommerce.

Собственикът използва силни пароли, двуфакторна автентикация и няма съмнителни плъгини. Административният адрес не е публично известен, а опитите за вход са ограничени.

Въпреки това сайтът е уязвим, защото атаката не започва от login страницата.

Нападателят или автоматизиран бот изпраща специално подготвени анонимни заявки към REST API Batch endpoint-а. WordPress обработва неправилно връзката между проверените подзаявки и route handler-ите.

Неподходяща стойност достига до SQL заявка. Нападателят използва получената възможност, за да изгради останалата част от експлоатационната верига и да създаде нов администраторски профил.

След това може да инсталира злонамерен плъгин или да добави постоянен достъп по друг начин.

От този момент нападателят потенциално може да:

промени страницата за плащане;
добави JavaScript, който прихваща въведените от клиента данни;
замени банковата сметка при плащане с банков превод;
промени ключовете или настройките на платежен оператор;
добави фалшив payment gateway;
пренасочи checkout процеса към външна страница;
получи достъп до поръчки, имена, адреси, телефони и имейли;
създаде WooCommerce REST API ключове;
добави външни webhooks за изнасяне на информация;
промени цени, наличности, данъци и доставки;
издава неоторизирани възстановявания;
промени получателите на служебните имейли;
инжектира SEO спам или скрити връзки;
използва магазина за фишинг;
постави постоянна задна врата;
изтрие или криптира файлове и база данни.

Не всеки WooCommerce магазин съхранява пълни картови данни. Това зависи от използвания платежен оператор и начина на интеграция. Дори когато картовите данни не се съхраняват в WordPress, нападател с контрол върху checkout страницата може да промени бъдещите плащания или да прихваща информация в момента на въвеждането ѝ.

Кои версии са засегнати?

Трябва да се прави разлика между пълната wp2shell RCE верига и отделната SQL injection уязвимост.

WordPress версия	Риск	Поправена версия
6.8.0–6.8.5	Засегната от CVE-2026-60137, но не и от пълната wp2shell RCE верига	6.8.6
6.9.0–6.9.4	Засегната от SQL injection и пълната pre-auth RCE верига	6.9.5
7.0.0–7.0.1	Засегната от SQL injection и пълната pre-auth RCE верига	7.0.2
7.1 beta1	Засегната	7.1 beta2
Версии преди 6.8	Не са засегнати от тези две конкретни уязвимости	Препоръчва се преминаване към актуална поддържана версия

WordPress 6.8 няма пълната batch-route confusion RCE верига. Той обаче съдържа отделния проблем в author__not_in. При тази версия експлоатацията по принцип изисква плъгин или тема да подаде недоверени данни към засегнатия параметър.

Фактът, че версия преди 6.8 не е засегната от тези конкретни CVE, не означава, че е безопасна. Старите WordPress версии могат да съдържат други известни уязвимости и не трябва да бъдат използвани като стратегия за защита.

Уязвимостта активно ли се използва?

Да.

Първоначалните публикации посочваха, че няма данни за активна експлоатация и че пълните технически подробности временно няма да бъдат публикувани.

Тази информация вече е остаряла.

На 20 юли 2026 г. Searchlight Cyber публикува подробен технически анализ. Изследователите посочват, че веригата вече е била независимо възпроизведена и че публични proof-of-concept реализации са започнали да се появяват.

На 21 юли 2026 г. CISA добавя и двете уязвимости в каталога Known Exploited Vulnerabilities:

Това е официален сигнал, че е наблюдавана реална злонамерена експлоатация.

Какво трябва да направят собствениците на WordPress сайтове?

1. Проверете реално инсталираната версия

Не приемайте, че сайтът е обновен само защото автоматичните актуализации са разрешени.

Автоматичната актуализация може да бъде блокирана от:

настройка в wp-config.php;
version control или deployment система;
ограничени файлови права;
хостинг конфигурация;
проблем с WordPress Cron;
липса на свободно дисково пространство;
частично или неуспешно обновяване;
временен проблем при връзката с WordPress.org.

Версията може да бъде проверена от:

WordPress Dashboard → Updates

При наличен WP-CLI могат да се използват:

wp core version
wp core check-update

Проверете всички инсталации, включително:

основния сайт;
staging и development копия;
стари поддомейни;
временни миграционни копия;
забравени тестови сайтове;
отделни WordPress инсталации в подпапки.

Тестов сайт, който не се използва активно, но е достъпен от интернет, може да бъде също толкова опасна входна точка.

2. Обновете WordPress Core незабавно

Минималните поправени версии са:

WordPress 7.0.2;
WordPress 6.9.5;
WordPress 6.8.6 за сайтовете, които временно остават на клона 6.8.

Препоръчителният вариант е използването на актуалната стабилна и поддържана версия на WordPress, освен ако няма конкретна и проверена техническа причина за оставане на по-стар клон.

Актуализацията може да бъде извършена от администрацията или чрез:

wp core update

При критична pre-auth RCE уязвимост обновяването не трябва да бъде отлагано с дни заради продължителен процес на тестване. Ако е наличен staging процес, направете ускорена проверка, но приоритизирайте затварянето на уязвимостта.

Преди обновяването е разумно да бъде създаден актуален backup или snapshot, стига това да не забавя съществено инсталирането на поправката.

3. Потвърдете, че обновяването е завършило успешно

След актуализацията проверете:

реално зарежданата WordPress версия;
WordPress администрацията;
началната страница и основните вътрешни страници;
REST API;
потребителската регистрация и вход;
формите за контакт;
Elementor страниците, ако сайтът го използва;
WooCommerce количката;
checkout процеса;
тестово плащане;
данъците и доставките;
имейл известията;
webhooks и външните интеграции;
WooCommerce Scheduled Actions;
PHP и сървърните error logs.

След проверката могат да бъдат изчистени WP Rocket, CDN и останалите приложни кешове, за да се гарантира последователно поведение на сайта.

4. Проверете WordPress Core файловете

Официалната WP-CLI команда сравнява Core файловете с публикуваните от WordPress.org checksums:

wp core verify-checksums --include-root

Успешната проверка означава, че познатите Core файлове съвпадат с официалната версия.

Тя обаче не доказва, че целият сайт е чист.

Командата не удостоверява автоматично:

персонализираните плъгини;
премиум плъгините;
custom темите;
файловете в wp-content;
съдържанието на базата данни;
WordPress потребителите;
cron задачите;
външните webhooks;
server-level persistence.

Затова проверката на Core checksums е важна, но е само една част от цялостния одит.

Какво да направим, ако не можем да обновим веднага?

Обновяването е единственото действие, което реално коригира уязвимия код.

Ако има обективна техническа причина сайтът да не бъде обновен незабавно, може временно да бъде блокиран анонимният достъп до REST API Batch endpoint-а.

Трябва да бъдат обхванати и двата начина за достигане до маршрута:

/wp-json/batch/v1
?rest_route=/batch/v1

Правилото може да бъде приложено чрез:

edge WAF;
CDN защитна стена;
reverse proxy;
конфигурация на уеб сървъра;
временно WordPress ограничение за неавтентикирани Batch заявки.

Важно е и origin сървърът да не остава директно достъпен по публичен IP. В противен случай WAF правилото може да бъде заобиколено чрез изпращане на заявката директно към сървъра.

Друга временна мярка е забрана на целия REST API за анонимни потребители. Този подход е по-груб и може да засегне:

Elementor;
WooCommerce приложения;
мобилни приложения;
ERP и складови интеграции;
системи за доставка;
външни каталози;
автоматизации;
custom REST функционалности.

Затова ограничаването само на Batch маршрута обикновено е по-подходяща аварийна мярка.

Searchlight Cyber предлага и временен mitigation плъгин на wp2shell.com, който изисква автентикация за Batch API заявките.

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

Какво не е достатъчна защита?

Следните мерки са полезни в други ситуации, но сами по себе си не спират wp2shell:

силна администраторска парола;
двуфакторна автентикация;
скрит или променен адрес на login страницата;
ограничаване на опитите за вход;
промяна на стандартния database prefix;
WP Rocket;
стандартен malware scanner;
забрана на XML-RPC;
скриване на WordPress версията;
SSL сертификат;
CAPTCHA;
премахване на потребителя с име admin;
backup без проверен процес за възстановяване.

Причината е проста: първоначалната атака се извършва преди автентикация и не използва login формата.

WAF може да осигури допълнителен защитен слой, но само ако разполага с правилно правило, което покрива конкретната атака. Той не трябва да се приема за заместител на поправения WordPress Core.

Достатъчно ли е само да обновим WordPress?

Не винаги.

Обновяването затваря входната точка, но не премахва вече настъпило компрометиране.

Ако нападателят е успял да създаде администратор, да инсталира backdoor, да добави cron задача или да промени базата, тези промени ще останат и след обновяването.

Трябва да разграничаваме:

уязвим сайт – използва версия, съдържаща проблема;
поправен сайт – използва версия, в която проблемът е отстранен;
проверен чист сайт – освен че е поправен, е преминал през проверка за компрометиране.

Скенерът на wp2shell.com може да помогне да установите дали текущата версия е уязвима. Той не може самостоятелно да докаже, че сайтът никога не е бил атакуван.

Как да проверим дали сайтът е бил компрометиран?

Няма един универсален файл, IP адрес или потребителско име, които присъстват при всяка атака.

Публичните proof-of-concept реализации могат да оставят определени разпознаваеми следи, но реалните нападатели могат лесно да променят имената, пътищата и последващите си действия.

Затова проверката трябва да бъде поведенческа и да сравнява няколко независими източника.

Проверка на сървърните и WAF логове

Прегледайте наличните:

CDN и WAF логове;
Nginx или Apache access logs;
Nginx или Apache error logs;
PHP-FPM и PHP error logs;
WordPress debug logs;
хостинг и control-panel audit logs;
SSH и SFTP логове;
database audit logs, ако са били активни;
DNS и изходящия мрежов трафик;
логовете на инсталираната security система.

Особено внимание заслужават POST заявки към:

/wp-json/batch/v1;
адреси, съдържащи rest_route=/batch/v1.

Трябва да се търсят:

необичайно големи или сложни Batch заявки;
вложени Batch заявки;
повтарящи се грешки около маршрута;
заявки от непознати източници;
последваща административна активност;
инсталиране или активиране на плъгин;
създаване на WordPress потребител;
промяна на файлове непосредствено след REST заявките.

Самото използване на Batch endpoint-а не доказва атака. Маршрутът може да бъде използван и легитимно. Събитията трябва да се съпоставят по време с останалата активност.

Стандартните access logs обикновено не пазят пълното съдържание на POST заявките. Следователно липсата на видим злонамерен payload не доказва, че експлоатация не е имало.

Проверка на WordPress потребителите

Прегледайте всички потребителски профили и права:

непознати администратори;
потребители с необяснимо променена роля;
административни capabilities, добавени директно в usermeta;
променени имейл адреси;
активни application passwords;
необичайни сесии;
промени в users_can_register;
промяна на default role;
нови WooCommerce API ключове.

WordPress таблицата с потребители не предоставя надеждна дата на създаване за всеки профил. При съмнение сравнете с по-стари backups, audit logs, административни имейли и сървърни логове.

Проверка на файловата система

Проверете:

wp-content/plugins/;
wp-content/themes/;
wp-content/mu-plugins/;
wp-content/uploads/;
cache директориите;
wp-config.php;
.htaccess;
.user.ini;
index.php;
PHP конфигурацията;
WordPress drop-in файловете.

Особено важни са:

advanced-cache.php;
object-cache.php;
db.php;
sunrise.php;
нови PHP файлове в uploads;
наскоро променени файлове;
скрити файлове;
необясними symbolic links;
промени във файловите права и собствеността.

Must-use плъгините трябва да бъдат проверени директно във файловата система. Те се зареждат автоматично и могат да бъдат пропуснати при повърхностен преглед на стандартния Plugins екран.

Датата на последна промяна е само насока. Тя може да бъде променена от нападател, deployment система, backup restore или нормално обновяване.

Проверка на WordPress Cron и системните задачи

Постоянният достъп често се възстановява чрез планирани задачи.

Проверете:

WordPress cron hooks;
системния crontab;
cron задачите в хостинг панела;
WooCommerce Scheduled Actions;
неизвестни hook имена;
задачи с необичайни аргументи;
задачи, които свалят външни файлове;
задачи, които създават потребители или променят настройки.

WooCommerce нормално използва голям брой Scheduled Actions. Не трябва автоматично да се изтриват всички непознати задачи. Всяка трябва да бъде съпоставена с активните плъгини и нормалните бизнес процеси.

Проверка на базата данни

Проверката не трябва да се ограничава само до таблиците за потребители.

Потърсете:

промени в списъка с активни плъгини;
непознати autoloaded options;
необичайно големи стойности в options;
промени в siteurl и home;
промяна на административния имейл;
промени в регистрацията и default role;
непознати cron hooks;
инжектиран JavaScript;
скрити iframe елементи;
външни redirect адреси;
непознати code snippets;
нови външни домейни;
променени widgets;
SEO спам в публикации и страници;
непознати WooCommerce webhooks;
нови REST API ключове;
промени по SMTP и payment gateway настройки.

Не приемайте автоматично, че WordPress таблиците започват с wp_. При много сайтове се използва различен prefix.

Специална проверка за WooCommerce

При онлайн магазин трябва да се проверят и бизнес операциите:

WooCommerce REST API consumer keys;
webhooks и техните destination URL адреси;
payment gateway ключове и настройки;
банковата сметка за директен превод;
checkout страницата;
checkout JavaScript кодът;
custom checkout templates;
неочаквани refunds;
промени в поръчки;
необичайни купони;
промени в цените;
промени в данъците и доставките;
получателите на административните имейли;
WooCommerce Status Logs;
webhook delivery logs;
Scheduled Actions;
несъответствия между поръчките и отчетите на платежния оператор.

При съмнение за засегнати платежни операции трябва да се свържете и с платежния оператор.

Как да реагираме при потвърдено или вероятно компрометиране?

1. Ограничете активната атака

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

При WooCommerce това е особено важно, ако има риск за:

checkout процеса;
платежните настройки;
банковите данни;
клиентската информация;
текущите поръчки.

Batch маршрутът трябва да бъде блокиран, а достъпът до администрацията може временно да бъде ограничен до доверени IP адреси.

2. Запазете доказателствата

Преди масово изтриване и „почистване“, когато ситуацията го позволява, създайте:

snapshot на файловата система;
пълен database dump;
копие на сървърните логове;
копие на WAF и CDN логовете;
списък на WordPress потребителите;
списък на активните плъгини;
списък на cron задачите;
списък на процесите и мрежовите връзки;
времева линия на подозрителните събития.

Това е forensic копие на компрометираното състояние, а не чист backup за възстановяване.

3. Преинсталирайте от доверени източници

Най-надеждният подход е чисто преизграждане, а не редактиране на няколко подозрителни файла.

WordPress Core, плъгините и темите трябва да бъдат инсталирани от:

WordPress.org;
официалния разработчик;
проверен вътрешен repository;
доказано чист deployment пакет.

Custom плъгините и темите трябва да бъдат възстановени от version control след code review.

Ако целостта на операционната система или PHP средата не може да бъде доказана, по-сигурният вариант е използването на нов чист сървър или container.

4. Премахнете всички механизми за постоянен достъп

Проверете и премахнете:

злонамерени администратори;
application passwords;
непознати плъгини;
mu-plugins;
PHP файлове в uploads;
променени theme файлове;
drop-in файлове;
server cron задачи;
WordPress cron hooks;
WooCommerce Scheduled Actions;
непознати webhooks;
външни JavaScript ресурси;
модифицирани .htaccess и .user.ini;
backdoor код в базата данни.

5. Сменете всички засегнати пароли и ключове

Смяната трябва да се извърши от доверен компютър, след като средата е почистена или преизградена.

Сменете:

паролите на WordPress администраторите;
WordPress application passwords;
WordPress authentication keys и salts;
hosting и control-panel паролите;
CDN и WAF акаунтите;
DNS и domain registrar акаунтите;
SSH и SFTP ключовете;
паролата на базата данни;
SMTP достъпа;
служебните имейли;
WooCommerce REST API ключовете;
webhook secrets;
payment gateway ключовете;
ERP и CRM интеграциите;
API ключовете на куриерски услуги;
достъпа до backup системите;
object storage ключовете.

Смяната само на WordPress администраторската парола не е достатъчна.

Ако backdoor-ът все още е активен, той може да прихване и новите credentials. Затова окончателната ротация трябва да бъде извършена след чистото възстановяване.

6. Внимавайте при възстановяване на WooCommerce база

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

При WooCommerce това може да доведе до загуба на:

нови поръчки;
клиенти;
плащания;
refunds;
складови движения;
абонаменти;
промени в статуса на поръчките.

Възстановяването трябва да се подготви в отделна чиста staging среда. Данните, възникнали след последния сигурен backup, трябва да бъдат внимателно сравнени с платежните, куриерските и счетоводните системи.

Не трябва автоматично да се импортира цялата компрометирана база в новата среда. Така могат да бъдат върнати злонамерени options, потребители, webhooks или инжектиран код.

7. Направете оценка за изтичане на данни

Ако има вероятност нападателят да е получил достъп до лични, служебни или платежни данни, трябва да бъде извършена отделна оценка на инцидента.

В зависимост от конкретния случай може да е необходимо включването на:

хостинг доставчика;
платежния оператор;
специалист по информационна сигурност;
длъжностното лице по защита на данните;
юридически консултант;
застрахователя по киберрискове;
засегнати партньори и доставчици;
компетентните институции.

Дългосрочни мерки за превенция

wp2shell показва защо сигурността на WordPress не може да бъде сведена до инсталирането на един security плъгин.

Необходими са няколко независими защитни слоя.

Централен регистър на всички сайтове

Поддържайте актуален списък на:

всички production сайтове;
staging инсталации;
development копия;
WordPress и PHP версиите;
активните теми и плъгини;
хостинг средата;
отговорното лице;
backup политиката;
последната проверка за сигурност.

Не може да бъде обновен сайт, за чието съществуване никой вече не помни.

Процес за критични актуализации

Критичните WordPress Core актуализации трябва да се прилагат в рамките на същия ден.

Staging тестовете са важни, но не трябва да забавят аварийна security актуализация с дни или седмици.

Процесът трябва да включва:

автоматично известяване;
оценка на засегнатите версии;
бърз backup или snapshot;
ускорен staging тест;
production deployment;
проверка на реалната версия;
функционален тест;
наблюдение на логовете.

Автоматични актуализации с контрол за успех

Автоматичните актуализации са полезни, но не трябва да се използват без наблюдение.

Необходимо е да има известяване при:

успешно обновяване;
неуспешно обновяване;
частично завършен update;
недостъпност на сайта;
промяна във файловете;
несъвместимост след update.

WAF и защита на origin сървъра

Добре конфигурираният WAF може да осигури virtual patching и да блокира известни злонамерени заявки, преди да достигнат до WordPress.

Защитата трябва да включва:

филтриране на подозрителни REST заявки;
ограничаване на автоматизираните сканирания;
rate limiting;
logging;
защита на административните адреси;
блокиране на директния достъп до origin сървъра;
достатъчно дълъг retention на логовете.

WAF е допълнителен слой, а не заместител на актуализациите.

Минимални потребителски права

Всеки служител трябва да има само правата, необходими за конкретната му работа.

Не използвайте един общ администраторски профил за всички.

Препоръчително е:

отделни персонални акаунти;
минимален брой администратори;
двуфакторна автентикация;
периодичен преглед на ролите;
незабавно премахване на достъпа на бивши служители;
отделни акаунти за външни изпълнители;
забрана на споделени пароли.

Тези мерки не спират първоначалната wp2shell атака, но ограничават риска при други сценарии и улесняват одита.

Ограничаване на файловите промени

Когато built-in редакторът за теми и плъгини не е необходим, той може да бъде забранен чрез:

define( 'DISALLOW_FILE_EDIT', true );

В среди с контролиран deployment може да се използва и DISALLOW_FILE_MODS, но само ако обновяванията се извършват по външен, наблюдаван процес. В противен случай тази настройка може да попречи и на критичните WordPress актуализации.

Файловите права трябва да бъдат възможно най-ограничени, без да се нарушава нормалната работа на сайта.

Изолиране на различните сайтове

Когато на един сървър се хостват няколко сайта, те трябва по възможност да използват:

отделни системни потребители;
отделни database потребители;
отделни PHP pools;
отделни credentials;
ограничен достъп между директориите.

Това намалява вероятността компрометирането на един сайт да засегне всички останали.

File integrity monitoring

Изградете baseline на нормалните файлове и наблюдавайте за:

нови PHP файлове;
промени по Core;
промени по custom код;
промени по premium плъгини;
файлове в необичайни директории;
промени по конфигурацията;
промени във файловите права.

Известията трябва да бъдат изпращани извън самия сървър, за да не могат лесно да бъдат изтрити заедно с локалните логове.

Централизирани логове

Сървърните и защитните логове трябва да се съхраняват достатъчно дълго и, когато е възможно, извън WordPress сървъра.

Полезно е централизираното събиране на:

web access logs;
error logs;
WAF събития;
административни входове;
файлови промени;
plugin инсталации;
промени в потребителите;
WooCommerce операции;
cron и Scheduled Actions;
изходящи мрежови връзки.

Проверени резервни копия

Добрата backup стратегия трябва да включва:

автоматични резервни копия;
файлове и база данни;
няколко времеви версии;
независимо off-site копие;
поне едно immutable или read-only копие;
криптиране;
контрол на достъпа;
редовно тестване на възстановяването.

Backup, който никога не е бил възстановяван тестово, е само предположение, че разполагате с резервно копие.

Поддръжка на плъгини и теми

Въпреки че wp2shell се намира в WordPress Core, повечето ежедневни атаки продължават да използват стари плъгини и теми.

Добрата практика включва:

използване само на доверени източници;
премахване на неизползваните компоненти;
редовни актуализации;
наблюдение на security advisory съобщенията;
замяна на изоставени плъгини;
преглед на custom кода;
премахване на стари тестови теми;
отделна проверка на премиум компоненти без публични checksums.

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

WooCommerce има ли отделна wp2shell уязвимост?

Не. Проблемът се намира в WordPress Core.

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

Необходим ли е уязвим плъгин?

Не и за пълната wp2shell верига при WordPress 6.9 и 7.0.

Изследователите потвърждават, че стандартна WordPress инсталация без активни плъгини може да бъде експлоатирана.

При самостоятелната CVE-2026-60137 в WordPress 6.8 обикновено е необходим плъгин или тема, които подават недоверени данни към засегнатия параметър.

Необходима ли е администраторска парола?

Не.

Атаката започва преди автентикация. Публично описаната верига не разчита на открадната или разбита администраторска парола.

Ще помогне ли двуфакторната автентикация?

Не срещу първоначалната wp2shell експлоатация.

2FA е важен защитен слой срещу откраднати пароли и неоторизиран login, но в този случай нападателят заобикаля нормалния процес за вход.

WP Rocket предпазва ли сайта?

Не.

WP Rocket е решение за кеширане и производителност. Уязвимостта използва WordPress REST API и вътрешния временен кеш на WP_Post обекти, а не page cache-а на WP Rocket.

След актуализацията WP Rocket кешът може да бъде изчистен като част от контролираната проверка, но самият плъгин не е защита срещу wp2shell.

Достатъчно ли е да блокирам REST API?

Това може да бъде временна мярка, но не е окончателно решение.

Пълното блокиране на REST API може да наруши легитимна функционалност. Официалната препоръка е WordPress Core да бъде обновен незабавно.

Сайтът се е обновил автоматично. Трябва ли да правя нещо друго?

Проверете реалната версия.

Ако сайтът е използвал уязвима версия, докато е бил публично достъпен, извършете поне базова проверка за:

непознати администратори;
нови или променени файлове;
непознати плъгини;
cron задачи;
WooCommerce ключове и webhooks;
подозрителна REST API активност.

Скенерът показва, че сайтът не е уязвим. Това означава ли, че е чист?

Не непременно.

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

Версията ми е по-стара от 6.8. Това безопасно ли е?

Тези две конкретни уязвимости не засягат версиите преди WordPress 6.8.

Това обаче не означава, че старата версия е безопасна. Тя може да съдържа други известни и отдавна публични уязвимости. Използването на остарял WordPress не е препоръчителна защитна стратегия.

Заключение

wp2shell е особено сериозна уязвимост, защото атаката:

започва без автентикация;
не изисква парола;
не изисква уязвим плъгин;
засяга самия WordPress Core;
работи срещу стандартна инсталация;
може да доведе до постоянен администраторски достъп;
може да завърши с изпълнение на PHP код;
вече е отбелязана като активно експлоатирана.

Ако сайтът използва WordPress 6.9.0–6.9.4 или 7.0.0–7.0.1, обновяването трябва да бъде извършено незабавно.

Ако използва WordPress 6.8.0–6.8.5, трябва да бъде обновен до 6.8.6 или до актуалната стабилна версия заради отделната SQL injection уязвимост.

Най-важното е да не се спира само до update-а. Ако сайтът е бил публично достъпен с уязвима версия, трябва да се провери дали преди обновяването не е бил създаден непознат администратор, инсталиран злонамерен плъгин или добавен друг механизъм за постоянен достъп.

Екипът на Webselo може да извърши:

проверка на използваната WordPress версия;
безопасно обновяване;
проверка на WordPress Core;
одит на потребители, файлове и база данни;
проверка на WooCommerce настройки и интеграции;
анализ на сървърните логове;
премахване на зловреден код;
възстановяване от чист backup;
допълнително укрепване на сигурността;
дългосрочна техническа поддръжка и наблюдение.

При критични уязвимости времето е съществен фактор. Обновяването трябва да се измерва в часове, а не в дни.