Уязвимост в PHP при WordPress – PHP2Shell: какво трябва да направят операторите

Накратко: Уязвимостта в PHP при WordPress, за която се съобщава в момента, не е в WordPress, а в PHP на сървъра под него. Затова актуализацията на WordPress не затваря PHP2Shell. Решаващи са състоянието на пача на PHP, рестартирането на всички PHP процеси и проверка на типичните скривалища като wp-content/uploads и mu-plugins.

Защо актуализацията на WordPress не отстранява PHP2Shell

WordPress е приложение, написано на PHP. Уязвимостите CVE-2026-109618 и CVE-2026-109619 са едно ниво по-надолу, в самия интерпретатор на PHP. Според екипа на PHP те позволяват изпълнение на злонамерен код от разстояние без вход в системата. При Apache с mod_php е показан експлойт още преди да е стартирал какъвто и да е код на WordPress.

Уебсайт с актуално ядро, актуални плъгини и силни пароли може следователно пак да е уязвим, ако PHP отдолу е остарял. Обратно, пачнат PHP не доказва, че преди това нищо не се е случило. Контекста обясняваме на страницата Какво е PHP2Shell?.

Уязвимост в PHP при WordPress: проверка на версията на PHP

В таблото ще намерите под Инструменти > Здраве на сайта > Информация в раздел „Сървър“ версията на PHP, с която уебсайтът Ви реално работи. Това е по-показателно от php -v в командния ред, защото командният ред често ползва друга PHP инсталация от уеб сървъра.

Показаният номер сам по себе си обаче не стига. Поправените версии на оригиналния проект са 8.5.12, 8.4.27, 8.3.36 и 8.2.35. Много хостинг доставчици внасят корекциите като backport; тогава остава по-стар номер, макар да е пачнато. Как да установите истинското състояние, е описано в Как да проверите правилно PHP версията и състоянието на пача. Кои версии на PHP поддържа Вашата версия на WordPress, проверете според системните изисквания на wordpress.org.

Къде злонамереният код обича да се крие в WordPress

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

• wp-content/uploads/: предназначена за изображения и PDF файлове, не за PHP файлове.
• wp-content/mu-plugins/: „Must-use“ плъгините се зареждат автоматично и не могат да се деактивират от таблото.
• wp-config.php: съдържа достъпа до базата данни и ключовете за сигурност; вмъкнат ред тук трудно се забелязва.
• .htaccess в главната директория и в поддиректориите: пренасочвания само за търсачки или изпълнение на необичайни файлови разширения.
• Теми, най-вече functions.php, както и деактивирани, забравени плъгини.
• База данни: нови администратори в wp_users, чужд JavaScript в wp_options или в публикациите.

Безопасни първи проверки с WP-CLI и вградени средства:

# Сравняване на файловете на ядрото с официалните контролни суми
wp core verify-checksums
# Проверка на плъгините от директорията на wordpress.org
wp plugin verify-checksums --all
# Списък на PHP файловете в папката за качване
find wp-content/uploads -type f -name "*.php"
# Показване на всички администратори
wp user list --role=administrator

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

Плъгини, теми и административни достъпи като допълнителен риск

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

За wp-login.php и wp-admin важи: малко администратори, лични акаунти вместо споделени достъпи и двуфакторно удостоверяване. Ако не Ви трябва XML-RPC, може да се блокира. При подозрение трябва да се сменят всички пароли и ключовете за сигурност във wp-config.php. Редактора на файлове в таблото също изключвате там:

define( 'DISALLOW_FILE_EDIT', true );

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

1. Поискайте от хостинг доставчика писмено потвърждение за състоянието на пача на PHP и за рестартирането на всички PHP процеси.
2. Помолете да се запазят сървърните логове от 20.10.2026 г. нататък.
3. Извършете горните проверки или ги възложете на специалист.
4. Актуализирайте WordPress, плъгините и темите. Това е правилно, но не заменя стъпка 1.
5. При нередности не продължавайте просто да експлоатирате уебсайта, а го почистете.

Актуализацията на платформата може да затвори известни уязвимости в WordPress и в плъгините. Тя не може нито да поправи PHP, нито да премахне внедрени файлове, които не принадлежат към ядрото.

Как помага PHP SOS конкретно?

• С Вас или с Вашия хостинг доставчик изясняваме действителното състояние на PHP на Вашия WordPress уебсайт, включително backport-ове и рестартиране.
• Запазваме логове, файлове и база данни, преди да се промени каквото и да било.
• Проверяваме ядрото, плъгините, качените файлове, mu-plugins, .htaccess и потребителските акаунти за задни вратички.
• При находки нашата услуга за премахване на зловреден софтуер поема почистването, докато инцидентът бъде приключен и документиран; без находки заздравяваме инсталацията в рамките на спешната помощ срещу PHP2Shell.

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

Източници

• php.net: Съобщения за сигурност
• PHP 8 ChangeLog
• WordPress.org
• BSI (Федерална служба за информационна сигурност на Германия)