CISA потвърди атаки срещу пролука в обновяването на WordPress

На 3 ноември 2026 г. американската агенция за киберсигурност CISA добави CVE-2026-119977 в каталога си с уязвимости, които вече се използват в атаки (Known Exploited Vulnerabilities). Това е пролука в самото ядро на WordPress, в процеса на обновяване, и засяга всички версии от 4.7 до 7.1.3. Поправката е във WordPress 7.1.4 от 28 октомври и в обновленията за сигурност на по-старите клонове чак до 4.7. Американските държавни институции трябва да я приложат до 6 ноември.

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

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

Когато обновява ядрото, WordPress първо разопакова новите файлове във временна папка в wp-content/upgrade/ и чак след това ги копира върху сайта. Тази папка се отваря и през браузъра. До версия 7.1.3 името на временната подпапка се образуваше от името на пакета и лесно се познаваше, а на сървър с включен списък на файловете можеше и да се види.

За тези няколко секунди в папката стои пълно копие на WordPress, включително инсталаторът setup-config.php, който работи и без настройките на сайта. Според Wordfence човек без акаунт, който отвори инсталатора в точния момент, може да стигне до изпълнение на собствен код на сървъра. Това значи пълен контрол над сайта.

Сравнихме кода на 7.1.3 и 7.1.4. Новата версия прави три неща. Дава на временната папка име с 16 случайни знака, слага празен index.php в wp-content/upgrade/, за да не се вижда съдържанието ѝ, и никога не копира wp-config.php от временната папка върху сайта. Последната промяна подсказва как завършва атаката. Инсталаторът пише файл с настройки, а обновлението го пренася върху истинския сайт.

Wordfence оценява уязвимостта с 8.1 по CVSS, „висока“, като отбелязва висока сложност на атаката. Самият WordPress я оценява като ниска. Какво значат тези оценки, е обяснено в ръководството за CVSS. Wordfence засече първите опити девет минути след като пусна защитно правило на 28 октомври, а броят им за първите дни е в хиляди. Към края на октомври Wordfence не съобщаваше за потвърден пробив, но CISA вписва в каталога само уязвимости, за които има доказателства за атаки.

Кои сайтове са засегнати

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

Има една неприятна подробност. Обновяването до 7.1.4 минава през кода на старата версия, защото той разопакова пакета. Ако това обновление ползва пълния пакет, самото то отваря прозореца за атака. Затова първо блокирайте папката, после обновявайте.

Версиите 4.6 и по-стари нямат поправка. WordPress вече не издава обновления за сигурност за тях.

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

Версията се вижда в Dashboard > Updates. В Terminal на cPanel може да я проверите с командата по-долу. Как се работи с WP-CLI, е описано в ръководството за WP-CLI.

# cPanel > Terminal, в папката на сайта
# Само чете. Показва версията на WordPress.
wp core version

Поправката е в 7.1.4, 7.0.8, 6.9.11, 6.8.12, 6.7.11 и в съответните обновления на по-старите клонове чак до 4.7.39. Ако версията Ви е някоя от тях или по-нова в същия клон, пролуката е затворена.

Следващата команда търси в логовете на cPanel заявки към wp-content/upgrade/. Нормален посетител няма работа там.

# cPanel > Terminal
# Само чете. Заявки към временната папка на обновленията.
zgrep -h "/wp-content/upgrade/" ~/access-logs/* ~/logs/*.gz 2>/dev/null \
  | tail -n 20

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

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

1. Блокирайте достъпа през браузъра до wp-content/upgrade/. Сложете правилото по-долу в началото на файла .htaccess в папката на сайта, преди блока на WordPress. Не го слагайте в самата wp-content/upgrade/, защото старите версии изтриват всичко в нея при всяко обновяване.
2. Направете бекъп на файловете и базата данни, както е описано в ръководството за бекъп.
3. Обновете от Dashboard > Updates и проверете версията отново с wp core version.
4. Прегледайте Users за непознати администратори и Plugins за плъгини, които не сте слагали. Ако откриете нещо такова, сменете паролите и следвайте ръководството за хакнат сайт.

# В началото на .htaccess в папката на сайта, преди # BEGIN WordPress
# Забранява достъпа през браузъра до временната папка на обновленията.
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteRule ^wp-content/upgrade/ - [F,L]
</IfModule>

След като запишете файла, отворете https://Вашият-сайт/wp-content/upgrade/ в браузъра. Трябва да видите грешка 403. Обновленията работят и с правилото, защото WordPress пише в папката директно на диска, а не през браузъра.

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

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

Източници

• CISA, Known Exploited Vulnerabilities Catalog
• NVD, CVE-2026-119977
• WordPress.org, WordPress 7.1.4 Security Release
• Wordfence, WordPress Core 4.7.0 - 7.1.3, Unauthenticated Upgrade Window Staged Installer Remote Code Execution
• GitHub, сравнение на WordPress 7.1.3 и 7.1.4
• WP-CLI, wp core version