На нашому тестовому стенді атака починається без логіна й пароля. Через ланцюжок вразливостей у ядрі WordPress зʼявляється новий адміністратор, а далі виконується код на сервері. Ще одна помилка, вже в налаштуваннях самого сервера, дозволяє підвищити права до root.

Це демонстрація на власному ізольованому середовищі, а не перевірка чужого сайту. Вона показує головне: захищати треба не тільки сторінку входу. В одному інциденті поєднуються помилки ядра, плагінів і серверних прав.

У відео VAPAN про безпеку WordPress ми розбираємо ланцюжок WP2Shell і стару вразливість File Manager. Нижче пояснюємо механіку, додаємо свіжі вразливості вересня 2026 року й даємо перелік дій для власника сайту. Перевіряти можна лише власні системи або чужі в межах явно погодженого тестування.

Що відбулося на стенді

Демонстрація починається з визначення WordPress і його версії. Сама версія в HTML ще не доводить можливість злому: метадані бувають застарілими, прихованими або зміненими. Потрібна перевірка фактичної конфігурації та встановлених виправлень.

У показаному сценарії інструмент проходить кілька етапів: використовує вразливий шлях обробки запиту, отримує адміністративний доступ до WordPress і завантажує код через можливості адміністратора. Виконання коду спочатку відбувається з правами користувача вебсервера.

Це важливе розмежування. Адміністратор WordPress, користувач вебсервера й root операційної системи мають різні повноваження. Отримати одні права не означає автоматично отримати всі інші.

Як пов'язані дві помилки WP2Shell

Ланцюжок WP2Shell поєднує плутанину маршрутів у REST batch API, CVE-2026-63030, та SQL-ін'єкцію в параметрі author__not_in, CVE-2026-60137. Обидва номери підтверджені в базі NVD. Назва стосується конкретного ланцюжка, а не будь-якого злому WordPress.

REST batch API дозволяє передати кілька підзапитів в одному HTTP-запиті. У вразливій реалізації обробка помилкового шляху порушувала відповідність між результатами перевірки й обробниками. Через це дані могли потрапити до обробника без належної перевірки саме для його маршруту.

Друга проблема стосувалася параметра author__not_in у WP_Query. Некоректно нормалізоване значення могло впливати на SQL-запит, коли плагін або тема передавали в цей параметр дані без перевірки. Поєднання двох помилок і дає перехід від анонімного запиту до підробленого адміністратора й вебшелу.

Уразливими були WordPress 6.9.0 до 6.9.4 та 7.0.0 до 7.0.1. Виправлення вийшли у версіях 6.9.5 і 7.0.2. За даними NVD, для повного ланцюжка не потрібні ні логін, ні окремий плагін: досить самого ядра у вразливій версії.

Root це вже не про WordPress

У відео після вебшелу ми підвищуємо права до root. Це окрема помилка, і вона не є частиною WP2Shell. Причина в конфігурації самого стенда, де користувач вебсервера мав зайві права на рівні операційної системи.

Ми навмисно показуємо це окремо, бо тут часта плутанина. Свіже ядро WordPress не рятує від слабких серверних прав, і навпаки, ідеально налаштований сервер не закриє діру в застарілому ядрі. Це два різні рівні захисту.

Свіжі вразливості вересня 2026

WP2Shell не поодинокий випадок. За останні тижні вийшло ще кілька критичних виправлень, і одне з них уже активно експлуатують.

Elementor Pro, CVE-2026-32475. Помилка в перевірці завантаження файлів у формах плагіна дозволяє анонімному відвідувачу залити PHP-файл і виконати код на сервері. Уразливі всі версії до 4.2.1 включно, виправлено у 4.2.2 від 19 серпня 2026 року. Атаки почалися майже одразу після виходу патча: за даними Wordfence, вони заблокували понад 190 тисяч спроб. Умова для атаки це опублікована сторінка з формою Elementor, у якій є поле завантаження файлу. Якщо ви користуєтесь Elementor Pro, оновіть його насамперед і перевірте каталог wp-content/uploads/elementor/forms/ на наявність сторонніх PHP-файлів.

Ядро WordPress, CVE-2026-87902. 22 вересня 2026 року вийшли патчі ядра проти помилки в підборі шаблону сторінки. За певних умов анонімний запит може підключити сторонній PHP-файл із сервера, а це відкриває шлях до виконання коду. Рейтинг критичності 9.2 за CVSS 4.0. Виправлення отримали всі гілки: 7.1.2, 7.0.6, 6.9.9, 6.8.10 і нижче, аж до 4.7.37. Для виконання коду потрібні дві умови на боці сервера, тому вразливі не всі сайти, але оновити ядро варто всім. Станом на день виходу патча публічних повідомлень про атаки не було, проте після розкриття деталей ситуація змінюється швидко.

All-in-One WP Migration, CVE-2026-19949. SQL-ін'єкція під час відновлення архіву. Плагін встановлено на мільйони сайтів, уразливі версії до 7.109 включно, виправлено у 7.110. Ризик реалізується під час операції відновлення бекапу, тому важливо не тільки оновити плагін, а й не запускати відновлення з непевних архівів.

Спільне в усіх цих випадках одне. Дірки живуть не в екзотиці, а у звичайних популярних плагінах і в самому ядрі. Тому базова гігієна закриває більшість реальних атак.

Що перевірити на своєму сайті

Порядок дій від найважливішого до бажаного.

  • Оновіть ядро WordPress. Переконайтесь, що стоїть остання версія вашої гілки: щонайменше 6.9.5, 7.0.2 і вище проти WP2Shell, а також 6.9.9, 7.0.6, 7.1.2 і відповідні патчі старіших гілок проти CVE-2026-87902. Увімкніть автоматичне встановлення хоча б безпекових оновлень.
  • Оновіть або видаліть плагіни й теми. Кожен неактивний плагін це зайва поверхня атаки. Якщо не користуєтесь, видаляйте, а не просто вимикайте. Особливо перевірте Elementor Pro та All-in-One WP Migration, якщо вони у вас є.
  • Заберіть зайві права в користувача вебсервера. Процес PHP не повинен мати запис у системні каталоги чи право виконувати команди від root. Це не зупинить злом WordPress, але не дасть перетворити вебшел на повний контроль над сервером.
  • Обмежте доступ до службових точок. Якщо REST batch API /wp-json/batch/v1 вам не потрібен, закрийте його на рівні вебсервера або WAF. Тримайте перед сайтом фаєрвол рівня застосунку, який фільтрує типові шаблони атак.
  • Слідкуйте за файлами завантажень. Поява PHP-файлів у каталогах для завантажень це сигнал компрометації. Налаштуйте заборону виконання PHP в uploads і періодично перевіряйте вміст.
  • Робіть резервні копії й перевіряйте відновлення. Копія потрібна не лише щоб пережити збій, а й щоб відкотитись після інциденту. Зберігайте її окремо від самого сайту.

Жоден пункт не є чарівною кнопкою. Разом вони закривають ті сценарії, які ми показуємо у відео, і ті, що трапляються в реальних атаках цього місяця.

Коли потрібна перевірка людиною

Автоматичне сканування знаходить відомі вразливості, але не бачить логічних помилок, ланцюжків із кількох слабких місць і небезпечних серверних налаштувань. Саме поєднання таких дрібниць і дало повний контроль над стендом у відео.

Якщо на сайті є оплата, персональні дані клієнтів або кастомний код, разовий технічний аудит показує реальну картину ризику. Ми у VAPAN робимо такі перевірки на погоджених системах і пояснюємо результат зрозумілою мовою, без залякування.

Повний розбір WP2Shell дивіться у відео на каналі VAPAN. Якщо хочете перевірку свого проєкту, напишіть нам.