Някои сайтове, базирани на WordPress, все още могат да бъдат атакувани, докато инсталират корекцията за сигурност за активно експлоатирана уязвимост, твърди Умут Байрам, изследователят от Picus Security, който я е открил.

Обновяването, което инсталира корекцията за сигурност, все още разархивира файловете си, използвайки стария, некоригиран код на сайта, така че атакуващ, който удари в точния момент, може да изпълни код на сървъра. Изследователят съветва преди обновяване да се блокира уеб достъпът до папката wp-content/upgrade на сайта.

Уязвимостта, проследявана като CVE-2026-119977, засяга версиите на WordPress от 4.7 до 7.1.3. По време на основно обновяване, което използва пълен пакет, WordPress разархивира копие на новата версия във временна папка вътре в wp-content/upgrade. Това копие включва инсталатора на WordPress и уеб сървърът обикновено има достъп до него.

Атакуващ без акаунт, който успее да определи името на папката и да получи достъп до инсталатора, преди WordPress да изтрие копието, може да изпълни код на сървъра. По-рано тази седмица Агенцията за киберсигурност и сигурност на инфраструктурата на САЩ (CISA) добави уязвимостта в своя каталог с известни експлоатирани уязвимости.

WordPress пусна корекцията за сигурност миналата седмица във версия 7.1.4, както и в съответните обновявания за по-старите разклонения назад до 4.7, като всички те са изброени в бюлетина за сигурност на платформата.

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

Преди корекцията за сигурност атакуващият можеше да използва инсталатора, за да запише нов конфигурационен файл, wp-config.php, във временното копие. След това обновяването би презаписало реалния файл на сайта с този файл. Частта от корекцията за сигурност, която спира това, вече работи по време на обновяването, което я инсталира, тъй като WordPress копира файловете на място чрез новия код.

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

Кой е изложен на риск по време на обновяването

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

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

The Hacker News провери услугата за обновяване на WordPress.org днес за няколко версии. За обновявания в рамките на едно разклонение, като например от 7.1.3 до 7.1.4, тя предлагаше частичен пакет, включително за автоматични обновявания. За преминаване от по-старо разклонение, като например от 7.0.7 към 7.1.4, тя предлагаше само пълни пакети.

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

Веднъж щом бъде инсталирана версия 7.1.4 или корекция за сигурност за съответното разклонение, следващите обновявания използват произволно име на папката и файл wp-config.php във временното копие никога не се копира върху реалния.

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

Първата препоръка на изследователя е изобщо да се спре обслужването на wp-content/upgrade от уеб сървъра. WordPress работи с тази папка директно на диска, така че блокирането на уеб достъпа не нарушава обновяванията, казва той.

  1. Блокирайте папката в конфигурацията на уеб сървъра. При Nginx добавете location ^~ /wp-content/upgrade/ { deny all; }. При Apache добавете Require all denied вътре в блок <Directory> за тази папка в конфигурацията на виртуалния хост.
  2. Ако можете да редактирате само .htaccess, добавете RedirectMatch 403 ^/wp-content/upgrade/ във файла .htaccess в основната директория на WordPress, над правилата за пренаписване на WordPress.
  3. Не поставяйте файл .htaccess в самата папка wp-content/upgrade. Старият механизъм за обновяване изтрива всичко в тази папка, преди да разархивира обновяването, така че файлът ще изчезне точно когато е необходим.
  4. Потвърдете, че заявка към /wp-content/upgrade/ връща грешка 403.
  5. Обновете до 7.1.4 или до коригираната версия за вашето разклонение.

Другият безопасен начин, казва той, е ръчно обновяване, извършено извън основната уеб директория (web root) — папката, която уеб сървърът обслужва. Направете резервно копие на файловете на сайта и базата данни, разархивирайте новата версия в папка, която уеб сървърът не обслужва, копирайте основните файлове на място, без да пипате wp-config.php или wp-content, и след това стартирайте обновяването на базата данни на WordPress. По този начин никога не се създава временен инсталатор в папка, достъпна през уеб.

Командата wp core update на WP-CLI не е заместител, тъй като тя стартира същия механизъм за обновяване и разархивира пакета в същата папка.

WordPress 4.6 и по-ранните версии вече не получават обновявания за сигурност, така че за тях няма корекция за сигурност. Изследователят казва, че уязвимостта датира от WordPress 2.7, пусната през 2008 г., и че тези сайтове трябва да преминат към поддържана версия.

Атаки и какво да проверите

Добавянето в каталога на CISA по-рано тази седмица се основаваше на доказателства за активна експлоатация, но агенцията не описа атаките.

Wordfence, компанията за сигурност на WordPress, която присвои CVE идентификатора, забеляза опити за атаки да започват девет минути след като внедри правило за защитна стена за уязвимостта в деня на пускането на корекцията за сигурност. Два от най-активните източници са продължили да проверяват малки групи от сайтове в продължение на около 14.5 часа, което според компанията, в нейния анализ на атаките, съвпада с опитите да се улови моментът, в който даден сайт се обновява.

Нейната оценка за уязвимостта в CVE записа е 8.1 от 10 по скалата CVSS. В нейните лабораторни тестове времевият прозорец е продължил само секунди. Собственият бюлетин на WordPress оценява уязвимостта като нискорискова.

Код, който авторите му описват като експлойт за уязвимостта, се появи в публични хранилища в GitHub от началото на тази седмица. В едно от тях се твърди, че кодът му работи и върху сайтове, които все още използват предвидима папка по време на обновявания с пълен пакет. Дали кодът работи, не е установено.

За сайтове, които са останали на засегната версия след пускането на корекцията за сигурност, Wordfence предлага да се провери за:

  • неочаквани заявки към PHP файлове в wp-content/upgrade
  • администраторски акаунти, които никой не разпознава
  • плъгини, които никой не е инсталирал
  • PHP файлове в wp-content/upgrade, които никой не е поставял там

Обновление

Байрам заяви пред The Hacker News на 6 ноември, че дали едно частично обновяване е изложено на риск зависи от това какво съдържа конкретният пакет. Частичният пакет съдържа само файловете, които са се променили между две версии. Ако те не включват файловете на инсталатора, временното копие не може да се стартира като инсталация на WordPress и инсталаторът никога не става достъпен.

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

Решаващият фактор, каза изследователят, „не е дали обновяването е частично или пълно. А дали механизмът за обновяване, който вече е инсталиран на сайта, е бил коригиран.“