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

„Новите разширения се преглеждат, преди да влязат в директорията, но след това актуализациите се доставят непрекъснато“, заяви Давид Перес, съръководител на официалния екип за хранилището на разширения на WordPress. „Дадено разширение може да е сигурно днес и да въведе уязвимост или злонамерен код в бъдеща версия.“

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

Платформата за управление на съдържание (CMS) отбеляза, че нейният автоматизиран преглед е открил задна врата (backdoor), въведена във версия на разширение с около 20 000 активни инсталации на 28 юли 2026 г. Тъй като пускането е било в прозорец за изчакване (cooldown window), компрометираната версия на разширението така и не е била разпространена чрез API за актуализации на WordPress.org.

Разширението е било затворено за изтегляне 26 минути след като екипът по разширенията е бил уведомен за актуализацията от компанията за киберсигурност на WordPress Wordfence. От WordPress не разкриват името на разширението.

От 5 юни 2026 г. всяко разширение и тема за WordPress преминава през период на изчакване (cooldown period), преди да бъде разпространено чрез автоматични актуализации като част от нова инициатива за сигурност, наречена Protect The Shire. Идеята е да се въведе известно забавяне в процеса, така че злонамерените актуализации да не стигат незабавно до крайните потребители. В момента периодът на изчакване е шест часа, спрямо 24 часа при първоначалното му въвеждане.

Последните усилия имат за цел да затворят друг критичен пропуск в сигурността: високата оценка за риск на дадена версия на разширение или тема трябва автоматично да спира разпространението без намесата на екипа по разширенията. Целият процес преминава през следните стъпки –

  • По време на периода на изчакване промените във всяка версия се анализират в WordPress.org от модели с изкуствен интелект (AI) заедно с Jetpack Scan.
  • Резултатите се потвърждават взаимно и се комбинират в оценка за сигурност: по-високата оценка означава потенциално по-висок риск.
  • Версиите с висока оценка за риск се блокират автоматично след приключване на прегледа, докато тези под този праг продължават по нормалния процес.
  • Разработчиците, качващи кода (committers), получават имейл с констатациите. Имейли се изпращат само в сценарии, при които разширението е блокирано.

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

В последващ коментар Перес разясни, че прегледът на сигурността „търси същите класове уязвимости, които търси всеки одит на сигурността“, като призова разработчиците да следват стандартите за кодиране на WordPress и правилата на PHP_CodeSniffer (PHPCS), за да валидират кода си и да гарантират неговото качество. На разработчиците, публикуващи разширения за WooCommerce, се препоръчва да използват платформата за тестване Quality Insights Toolkit (QIT).

Други модели, които също биха могли да увеличат оценката за риск, са посочени по-долу –

  • Крайни точки (endpoints) на REST, AJAX или admin-post без проверка на правата (capability check) – нонсът (nonce) сам по себе си не представлява авторизация
  • Заявки, изградени без $wpdb->prepare()
  • Файлови пътища, качвания, изтривания или включвания на файлове, изградени от данни в заявката (request data)
  • unserialize() върху данни от заявката или върху отдалечен отговор
  • Код, извлечен или изпълняван по време на работа (runtime), както и обфускиран или компресиран код

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

„Ако дадена констатация изглежда неправилна, авторите могат да се свържат с екипа по разширенията“, каза Перес. „Моля, имайте предвид, че екипът обработва голям обем прегледи, така че публикуването на коригирана версия почти винаги е по-бързо от чакането за ръчен преглед на обжалване.“