В All in One SEO виправили дві вразливості для атак без авторизації
В All in One SEO виправили дві вразливості, зокрема виконання шорткодів і DOM-based XSS. Щоб захистити сайт, оновіть плагін до версії 5.0.2.1 або новішої.
13 жовтня 2026 року Search Engine Journal повідомив про дві вразливості середнього рівня серйозності в плагіні All in One SEO (AIOSEO) для WordPress. Обидві дають змогу провести атаку без облікового запису, але за різних умов: одна дозволяє виконати довільний шорткод, інша — впровадити скрипт через спеціально підготовлений URL. Проблеми вже виправлено; версія 5.0.2.1 усуває обидві.
AIOSEO встановлено більш ніж на двох мільйонах сайтів. Плагін допомагає керувати SEO-налаштуваннями, XML-картами сайту, структурованими даними, редиректами та внутрішніми посиланнями. Тому встановлена версія важлива не лише для фахівця з пошукової оптимізації: вона впливає і на безпеку сайту.
Виконання шорткодів залежить від хлібних крихт
Вразливість CVE-2026-100152 отримала оцінку 6,5 і стосується версій AIOSEO до 5.0.2 включно. Перед викликом функції WordPress do_shortcode плагін не перевіряв належним чином передане значення. Через це зловмисник без авторизації міг домогтися виконання довільного шорткоду.
Шорткод — це інструкція, за допомогою якої WordPress виводить контент або запускає певну функцію. Сам по собі цей механізм не є вразливістю. Проблема в тому, що AIOSEO допускав виконання інструкції без необхідної перевірки значення. Ця відмінність важлива: йдеться про конкретний спосіб обробки шорткодів, а не про всі шорткоди на сайті.
Для атаки є обов’язкова умова: хлібні крихти AIOSEO — навігаційні посилання, що показують розташування сторінки на сайті, — мають відображатися на сторінці результатів пошуку WordPress. Їх можна вивести блоком, віджетом, шорткодом або через шаблон. Якщо такий вивід не налаштовано, описаний сценарій не спрацює. Водночас відсутність вимоги авторизації залишається суттєвою для сайтів, де ця умова виконується.
Виправлення увійшло до версії 5.0.2.1. Згідно з описом оновлення, розробники посилили захист шорткодів на сторінках пошуку.
Для XSS потрібен користувач із правом керування SEO
Друга вразливість, CVE-2026-85492, отримала оцінку 6,1. Це DOM-based XSS: шкідливий скрипт може виконатися в браузері користувача. Вона стосується версій AIOSEO до 5.0.1.1 включно; виправлення вийшло у версії 5.0.2.
Причина пов’язана з обробкою шляху URL: вхідні дані очищувалися недостатньо, а вивід недостатньо екранувався. Зловмисник без облікового запису міг підготувати адресу зі шкідливим кодом. Але самого переходу за цією адресою недостатньо, щоб скрипт виконався за описаним сценарієм.
Користувач WordPress повинен мати право aioseo_manage_seo і, перебуваючи на сторінці зі шкідливим шляхом в URL, відкрити панель SEO Preview з адміністративної панелі WordPress. Іншими словами, атака залежить від дій людини, яка має доступ до керування SEO-функціями. Це не сценарій, за якого скрипт виконується в браузері будь-якого відвідувача, який просто відкрив посилання.
Що перевірити на сайті
Власнику сайту або розробнику потрібно перевірити встановлену версію AIOSEO й оновити плагін до 5.0.2.1 або новішої версії з виправленнями. Випуск 5.0.2 усуває XSS, але ще не закриває можливість виконання шорткодів. Те, що виправлення вийшли у двох різних релізах, легко пропустити, якщо орієнтуватися лише на повідомлення про перше оновлення.
Після цього корисно подивитися, чи виводяться хлібні крихти AIOSEO на сторінці результатів пошуку. Це допомагає оцінити, чи можливий перший сценарій на конкретному сайті, але не замінює оновлення. Для другого сценарію має значення, хто має право aioseo_manage_seo: самого підготовленого URL для атаки недостатньо.
Маркетологу, який працює із SEO Preview, не потрібно розбиратися в реалізації do_shortcode або DOM-based XSS. Якщо оновленнями займається окремий фахівець, достатньо передати йому завдання перевірити плагін і номери обох CVE. Схоже питання розподілу відповідальності виникає і під час оновлень безпеки самого WordPress.
Моя думка: умови атаки — не привід відкладати оновлення
На мій погляд, обмеження тут легко сприйняти як привід нічого не робити. Так, для однієї атаки потрібні хлібні крихти на сторінці пошуку, а для іншої — дія користувача з правами на керування SEO. Але я б не покладався на те, що відповідний сценарій ніколи не виникне.
Я б також уточнив, хто відповідає за оновлення плагінів на конкретному сайті. Це не нова функція і не ще один екран, зате менше невизначеності в ручній роботі: зрозуміло, хто перевіряє встановлену версію і коли завдання виконано.
Джерела
Звідки новина. Текст — переказ своїми словами, факти — з джерела, думка — автора.
- All In One SEO WordPress Plugin Vulnerable To Two Exploits via @sejournal, @martinibuster www.searchenginejournal.com
досвідчений e-commerce-розробник
Розробляю магазини та інтеграції з обліковими системами. Люблю завдання, у яких можна прибрати ручну роботу власника, а не просто додати ще один екран.
Усі публікації автораСхожі статті
WordPress 7.1.4 усуває 22 вразливості, зокрема ризик під час оновлення ядра
WordPress 7.1.4 усуває 22 вразливості, зокрема ризик віддаленого виконання коду під час оновлення ядра. Власникам сайтів варто перевірити, чи встановлено оновлення.
WordPress 7.1.3 закриває сім вразливостей і виправляє збій завантаження зображень
WordPress 7.1.3 закриває сім вразливостей і виправляє критичну помилку, через яку на деяких хостингах не завантажувалися зображення. Власникам сайтів рекомендують встановити оновлення.
У ядрі PHP виправили вразливості, що дають змогу віддалено виконувати код
У ядрі PHP виправили вразливості, які могли призвести до віддаленого виконання коду та читання пам’яті процесу. Власникам сайтів варто перевірити версію PHP і встановити оновлення безпеки.
Обговорення 1
Бекзод Рахімов
У нас на магазине после обновления SEO-плагина однажды поехали хлебные крошки на карточках запчастей — покупатели и так иногда теряются между маркой и моделью, ещё и навигацию ломать не надо. Поэтому такие обновления ставлю сначала на копию сайта, проверяю карточку товара и только потом выкатываю на рабочий. Но 5.0.2.1 откладывать надолго точно не стал бы: «потом обновим» обычно вспоминают в самый неудобный момент.