Критична уразливість CVE-2026-48908 у SP Page Builder для Joomla: загроза RCE та як захиститися

Критична уразливість CVE-2026-48908 у SP Page Builder для Joomla -це загроза повного захоплення акаунта вашого хостингу (RCE)

У червні 2026 року дослідники кібербезпеки зафіксували масові атаки на вебресурси, що використовують популярний конструктор сторінок SP Page Builder для CMS Joomla. Новій критичній уразливості присвоєно ідентифікатор CVE-2026-48908.

За даними аналітичного центру Ionix Threat Center, уразливість отримала максимальну оцінку за шкалою CVSS v4.0 — 10.0 балів із 10. Це означає, що її використання є надзвичайно простим для зловмисників і не потребує жодних прав доступу чи взаємодії з користувачем. Оскільки дірки в безпеці вже активно експлуатуються в мережі (in the wild), українським власникам сайтів та системним адміністраторам необхідно вжити негайних заходів.

Суть та технічні деталі уразливості

Проблема криється в компоненті завантаження кастомних іконок (uploadCustomIcon) конструктора SP Page Builder від розробника JoomShaper.

У коді цього контролера повністю відсутня перевірка автентифікації або авторизації, а також немає належної серверної валідації типів файлів (CWE-284 / CWE-434).

Сценарій атаки:

1. Зловмисник відправляє спеціально сформований HTTP POST-запит (multipart/form-data) на вразливий ендпоінт без логіну чи паролю.
2. Замість файлу зображення іконки, в архівованому чи прямому вигляді передається шкідливий PHP-скрипт (вебшелл).
3. Компонент безперешкодно записує цей файл у публічно доступну кореневу директорію сайту.
4. Хакер звертається до завантаженого файлу через браузер, що призводить до віддаленого виконання коду (RCE) з правами вебсервера (наприклад, www-data).

Які версії під загрозою?

Уразливість присутня в дефолтному стані на будь-якому сайті Joomla, де встановлено та увімкнено розширення SP Page Builder всіх версій, включно до 6.6.1.

Наслідки та активність хакерів після експлуатації

Згідно з моніторингом Ionix та інцидентами, які зафіксували фахівці CERT, кіберзлочинці після отримання доступу виконують такі дії:

• Створення прихованих супер-адміністраторів: у базі даних Joomla реєструються нові облікові записи з максимальними правами (часто використовуються фейкові email-адреси на кшталт @secure.local).
• Закріплення в системі: у директоріях сайту (найчастіше під шляхом /media/com_sppagebuilder/assets/) розміщуються стійкі бекдори та PHP файлові менеджери для збереження контролю навіть після оновлення плагіна.
• Крадіжка даних: компрометація файлу конфігурації Joomla (configuration.php), що відкриває доступ до паролів бази даних.

Як перевірити сайт на наявність компрометації?

Якщо ви використовуєте вразливу версію, обов’язково проведіть аудит безпеки (Incident Response):

1. Перевірте список користувачів Joomla на наявність невідомих адміністраторів.
2. Проскануйте директорії upload, media, images та cache на предмет появи нових файлів з розширеннями .php, .phtml, .php5 або подвійними розширеннями (наприклад, image.jpg.php).
3. Вивчіть логи вебсервера (Apache/Nginx) на наявність підозрілих POST-запитів до функціоналу uploadCustomIcon.

Термінові заходи захисту та мітигація

Залишати сайт без захисту в поточних умовах — це прямий шлях до втрати даних чи блокування ресурсу пошуковими системами через поширення спаму чи вірусів.

1. Негайне оновлення (Рекомендовано)

Розробник JoomShaper випустив екстрений патч безпеки. Необхідно терміново оновити SP Page Builder до версії 6.6.2 або новішої. Це повністю закриває діру в контролері завантаження файлів.

2. Тимчасове рішення (якщо оновлення неможливе прямо зараз)

• Налаштування WAF / Web Application Firewall: Якщо ви використовуєте комерційні рішення захисту, переконайтеся, що правила заблокують неавторизовані POST-запити до вразливого ендпоінту. Наприклад, за даними розробників, інструмент RsFirewall (починаючи з версії 3.3.7) має вбудоване правило безпеки, що нівелює цю атаку.
• Заборона виконання PHP в медіа-директоріях: Конфігуруйте ваш вебсервер (через .htaccess для Apache або файли конфігурації для Nginx) так, щоб у папках завантажень (/media/, /images/) було фізично заборонено запуск будь-яких PHP-скриптів. Це знизить рівень загрози з RCE до звичайного несанкціонованого запису файлу. Приклад вмісту .htaccess для заборони виконання php у поточній папці:
  

<FilesMatch ".*.(php|php3|php4|php5|php6|php7|php8|phps|pl|py|pyc|pyo|jsp|asp|htm|html|shtml|phtml|sh|cgi)$">
 Order Deny,Allow
 Deny from all
</FilesMatch>

• Тимчасове вимкнення компоненту: Якщо оновитися немає змоги, тимчасово вимкніть або видаліть плагін через менеджер розширень Joomla.

Висновок:

Випадок із CVE-2026-48908 наочно демонструє, як один сторонній плагін може поставити під загрозу всю інфраструктуру компанії. Сучасний підхід до кібербезпеки вимагає постійного моніторингу зовнішнього периметра (External Exposure Management). Платформи автоматизованого захисту дозволяють виявляти подібні вразливості нульового дня (Zero-Day) та застарілі компоненти на підконтрольних активах за лічені хвилини, значно скорочуючи середній час на усунення загрози (MTTR) ще до того, як її встигнуть експлуатувати хакери.

Не зволікайте — перевірте версію вашого SP Page Builder прямо зараз!