Накратко: Задна вратичка в WordPress откривате най-бързо, като сверите ядрото и добавките чрез WP-CLI с официалните контролни суми и след това прегледате целенасочено mu-plugins, папката за качване, wp-config.php, администраторските акаунти и базата данни. Важно след PHP2Shell: актуализация на WordPress не затваря уязвимостта в PHP и не премахва съществуваща задна вратичка.
Защо операторите на WordPress трябва да погледнат по-внимателно сега
С PHP2Shell през октомври 2026 г. станаха известни две критични уязвимости в самия PHP, CVE-2026-109618 и CVE-2026-109619. Те позволяват изпълнение на злонамерен код без вход в системата, независимо колко добре е поддържана Вашата инсталация на WordPress. Пачове има от 21.10.2026, но според медийни съобщения първи опит за атака е наблюдаван още на 17.10.
Който е бил уязвим през този период, трябва да търси следи. WordPress е типична цел, защото много инсталации са изградени сходно и атакуващите познават скривалищата. Какво трябва да направят операторите по темата PHP2Shell изобщо, е описано на страницата WordPress и PHP2Shell.
Извършвайте следните проверки по възможност върху копие или след архивиране. Командите само четат и не променят нищо.
По какво забелязвате задна вратичка в ежедневието
Задната вратичка е проектирана да остава незабележима. Въпреки това има признаци, които се забелязват и без технически познания. Към тях спадат пренасочвания към чужди сайтове, които се появяват само при посетители от търсачката на Google или само на мобилни устройства. Също толкова подозрителни са нови страници с реклама на лекарства, хазарт или копия на марково стоки, които се появяват в индекса на търсачките, но не и в административната част на WordPress.
Други указания са предупреждения от Google или от браузъра, оплаквания от клиенти за спам имейли от Вашия домейн, рязко нараснало потребление на изчислително време при хостинг доставчика или администратори, които никой в екипа не познава. Нито един от тези признаци сам по себе си не доказва задна вратичка. Ако се появят няколко заедно, не отлагайте следните проверки.
Обратното също важи: ако нищо от това не се забелязва, това не значи, че инсталацията е чиста. Именно вратички, създадени само за по-късен достъп, често изобщо не проявяват ефект навън.
Откриване на задна вратичка в WordPress: проверка на ядрото и добавките
WP-CLI може да сравни файловете на ядрото на WordPress и на добавките от официалната директория с публикуваните контролни суми. Всяко отклонение е конкретна задача за проверка.
cd /var/www/meine-seite
# Файловете на ядрото срещу официалните контролни суми
wp core verify-checksums
# Добавки от официалната директория
wp plugin verify-checksums --all
# Инсталирани версии и състояние
wp plugin list
wp theme list
Комерсиални добавки и теми така не могат да се проверят. За тях помага само сравнение с току-що изтеглен оригинален пакет на доставчика. Непознати добавки, които никой в екипа не е инсталирал, винаги са подозрителни, дори да изглеждат деактивирани.
Типични скривалища във файловата система
Някои места се срещат отново и отново при компрометирани инсталации на WordPress:
wp-content/mu-plugins/: зарежда се автоматично и не се появява в обикновения списък с добавки.wp-content/uploads/: там са мястото на изображенията и документите, не на PHP файловете.wp-config.php: допълнителни редовеincludeилиrequireв началото или в края..htaccessи.user.iniв уеб директорията и в поддиректориите: неочаквани пренасочвания или автоматично предварително зареждани файлове.- Файлове в главната директория, чиито имена напомнят основни файлове на WordPress, но не принадлежат към него.
# PHP файлове в папката за качване
find wp-content/uploads -type f -name "*.php*"
# Съдържание на Must-Use добавките
ls -la wp-content/mu-plugins/
# Всички .htaccess и .user.ini файлове с дата на промяна
find . \( -name ".htaccess" -o -name ".user.ini" \) -exec ls -la {} +
# Наскоро променени PHP файлове
find . -type f -name "*.php" -newermt "2026-10-17" -ls
Общи модели за търсене на замъглен код описва наръчникът Разпознаване и премахване на уеб шелове.
Проверка на потребители, база данни и планирани задачи
Много задни вратички изобщо не са във файловата система. Допълнителен администраторски акаунт често е достатъчен на атакуващите, за да се върнат по-късно.
# Всички администратори с дата на регистрация
wp user list --role=administrator --fields=ID,user_login,user_email,user_registered
# Планирани задачи в WordPress
wp cron event list
# Адрес на сайта (манипулации водят до пренасочвания)
wp option get siteurl
wp option get home
# Публикации с вградени скриптове
wp db query "SELECT ID, post_title FROM $(wp db prefix)posts WHERE post_content LIKE '%<script%'"
Проверете и опции с необичайно голямо съдържание и уиджети с чужд код. Намерените резултати не означават автоматично атака, защото кодове за проследяване или вградени карти също използват скриптове. Решаващо е дали някой в екипа познава съдържанието.
След находка сменете всички пароли и ключовете за сигурност в wp-config.php. Иначе съществуващите входове на атакуващите остават валидни.
Затваряне на задните вратички и предотвратяване на повторение
Ако сте намерили задна вратичка, преинсталирането обикновено е по-сигурно от поправянето на отделни файлове. Този ред се е доказал:
- Запазете следите: логове, подозрителни файлове и експорт на базата данни с дата.
- Приведете PHP до поправена версия и рестартирайте всички PHP процеси.
- Инсталирайте ядрото на WordPress, добавките и темите наново от оригинални източници.
- Прехвърлете проверени качени файлове и база данни, изтрийте чуждите акаунти, сменете всички достъпи.
- Забранете изпълнението на PHP в папката за качване на ниво сървър.
За Nginx е достатъчен един блок в конфигурацията на сървъра:
location ~* ^/wp-content/uploads/.*\.php$ {
deny all;
}
При Apache постигате същото с правило в конфигурацията на сървъра за папката за качване. .htaccess в самата папка за качване е по-слаб вариант, защото атакуващ с права за запис може отново да го промени.
След почистването планирайте няколко седмици по-внимателно наблюдение. Нови администратори, нови PHP файлове и промени в wp-config.php през това време трябва да се забелязват веднага, например чрез редовна проверка с WP-CLI или наблюдение на файловете на сървъра.
Как после да зададете правата за файловете така, че WordPress да може да записва само там, където е необходимо, показва наръчникът Права за файлове на уеб сървъра.
Как конкретно помага PHP SOS?
- Запазваме състоянието на инсталацията, преди нещо да бъде променено.
- Проверяваме ядрото, добавките, темите, базата данни, акаунтите и конфигурацията на сървъра за задни вратички.
- Инсталираме WordPress наново от чисти източници и прехвърляме само проверено съдържание.
- Заздравяваме сървъра и инсталацията и документираме какво е намерено и поправено.
Хода на едно почистване описва услугата Премахване на злонамерен софтуер и уеб шелове.
Често задавани въпроси
Затваря ли актуализация на WordPress уязвимостта PHP2Shell?
Не. PHP2Shell е в интерпретатора на PHP, а не в WordPress. Актуализация на WordPress, теми или добавки не променя нищо; решаващи са състоянието на PHP на сървъра и рестартът на всички PHP процеси.
Открива ли добавка за сигурност всички задни вратички?
Не надеждно. Добавката работи във вече компрометираната инсталация и самата тя може да е манипулирана. Допълнете я с проверки отвън, например с контролни суми чрез WP-CLI и сравнение с чисти оригинални файлове.
Какво са mu-plugins и защо са подозрителни?
Must-Use добавките в папката wp-content/mu-plugins се зареждат автоматично и не се появяват в обикновения списък с добавки. Атакуващите често ги използват, защото операторите рядко поглеждат тази папка.
Може ли задна вратичка да се крие и в базата данни?
Да. Злонамерен код или пренасочвания често се записват в опции, публикации или уиджети. Освен това атакуващите често създават собствени администраторски акаунти, които ще намерите в таблицата с потребители.