Команда WordPress оголосила про запуск автоматизованої перевірки безпеки для кожного оновлення плагінів перед їх розповсюдженням через API WordPress.org. Система використовує моделі на основі ШІ та Jetpack Scan для аналізу змін у коді, присвоює релізу оцінку ризику й автоматично блокує розповсюдження оновлень із високим показником — без участі команди модераторів. Нововведення стосується всіх розробників плагінів і тем WordPress, а також адміністраторів сайтів, які використовують автоматичні оновлення через панель керування WordPress.
Проблема: оновлення без контролю
Досі нові плагіни проходили ручну перевірку перед додаванням до каталогу WordPress.org, однак подальші оновлення публікувалися без жодного систематичного аудиту. Як пояснив Давід Перес, один з керівників команди офіційного репозиторію плагінів: «Плагін може бути безпечним сьогодні, але в наступному релізі з’явиться вразливість або шкідливий код». Відсутність проміжного етапу перевірки між комітом оновлення та його доставкою на мільйони сайтів створювало вікно для атак через ланцюжок постачання.
Проблема не є суто теоретичною. За даними WordPress, 28 липня 2026 року автоматична система виявила бекдор в оновленні неназваного плагіна з приблизно 20 000 активних інсталяцій. Скомпрометована версія не була розповсюджена через API WordPress.org, оскільки перебувала в межах періоду очікування (cooldown). Плагін був закритий для завантаження через 26 хвилин після того, як команду WordPress повідомила компанія Wordfence. Варто зазначити, що WordPress не розкрив назву плагіна, а незалежного підтвердження цього інциденту у відкритих джерелах не виявлено.
Як працює нова система
З 5 червня 2026 року всі плагіни й теми WordPress проходять обов’язковий період очікування перед розповсюдженням через API оновлень — це частина ініціативи Protect The Shire. Спочатку затримка становила до 24 годин, але згодом була скорочена до поточних шести годин. Нова автоматична перевірка вбудовується саме в цей часовий проміжок і працює за такою схемою:
- Під час періоду очікування зміни в кожному релізі аналізуються кількома моделями на основі ШІ спільно з Jetpack Scan.
- Результати перехресно верифікуються та об’єднуються в підсумкову оцінку безпеки: що вищий бал, то вищий потенційний ризик.
- Релізи з високою оцінкою ризику блокуються автоматично після завершення перевірки. Оновлення нижче порогового значення проходять стандартний процес публікації.
- Розробники отримують лист з результатами перевірки лише в разі блокування релізу.
Важлива обмовка: висока оцінка ризику не означає наявність шкідливого коду. WordPress прямо зазначає, що випадково внесена вразливість може отримати такий самий високий бал, як і навмисно впроваджений бекдор. Система вимірює ризик, а не намір.
Патерни коду, що підвищують оцінку ризику
WordPress оприлюднив конкретний перелік патернів, на які реагує система:
- REST-, AJAX- та admin-post-ендпоінти без перевірки прав доступу (nonce сам по собі не є авторизацією);
- SQL-запити, побудовані без
$wpdb->prepare(); - Робота з файлами (шляхи, завантаження, видалення, підключення) на основі даних із запиту;
- Виклики
unserialize()для даних із запитів або віддалених відповідей; - Запис в опції, метадані користувачів чи налаштування з ендпоінтів, доступних підписникам або неавтентифікованим користувачам;
- Завантаження та виконання коду під час роботи, обфускований або упакований код.
Розробникам рекомендується перевіряти код за допомогою WordPress Coding Standards і PHP_CodeSniffer. Авторам розширень для WooCommerce пропонується використовувати платформу Quality Insights Toolkit.
Що робити у разі блокування релізу
Єдиний спосіб зняти блокування — виправити виявлені проблеми й опублікувати нову версію. Якщо оновлений реліз отримає оцінку нижче порога блокування, він пройде стандартний процес із шестигодинним періодом очікування. Розробники можуть оскаржити результат через звернення до команди Plugins Team, однак, як зазначає Перес, випуск виправленої версії майже завжди швидший за очікування ручної перевірки апеляції.
Оцінка впливу
Нововведення стосується всієї екосистеми WordPress.org — кожного плагіна й кожної теми, що розповсюджуються через офіційний API оновлень, включно з оновленнями в один клік із панелі керування. Для розробників це означає необхідність більш ретельного дотримання стандартів кодування: навіть ненавмисні помилки безпеки можуть призвести до блокування релізу та затримки доставки оновлень користувачам.
Водночас система охоплює лише канал розповсюдження WordPress.org. Плагіни, установлені зі сторонніх джерел або оновлювані через власні механізми розробників, під дію цієї перевірки не підпадають. Раніше ми вже писали про вразливості в плагінах WordPress, і нова система спрямована саме на запобігання подібним ситуаціям на етапі розповсюдження.
Автоматична перевірка безпеки — логічний розвиток ініціативи Protect The Shire, яка послідовно вибудовує багаторівневий захист ланцюжка постачання WordPress. Адміністраторам сайтів на WordPress не потрібно вживати додаткових дій: система працює на боці WordPress.org. Розробникам плагінів варто вже зараз прогнати свій код через WordPress Coding Standards і PHP_CodeSniffer, щоб наступний реліз не виявився заблокованим через патерни, які система розцінить як ризиковані.
