CISA 7 липня 2026 року додала дві вразливості Joomla page builder до каталогу Known Exploited Vulnerabilities після підтвердження експлуатації у реальних атаках. Обидві проблеми небезпечні з однієї причини: неавтентифікований запит може привести до завантаження PHP-файлу та віддаленого виконання коду на Joomla-сайті.
Йдеться про JoomShaper SP Page Builder, CVE-2026-48908, і Joomlack PageBuilder CK, CVE-2026-56290. Оновлення потрібно зробити першим, але на цьому перевірка не закінчується. Якщо вразливий сайт був доступний до встановлення патча, перевірте web shell, приховані облікові записи адміністратора, змінені шаблони та підозрілі PHP-файли у публічних каталогах.
Кого це стосується
Це проблема для власників сайтів, вебстудій і адміністраторів Joomla, а не звичайне попередження для домашнього ПК. Перевірте кожен Joomla-сайт, де встановлено один із цих page builder, включно зі staging-копіями та старими клієнтськими сайтами, які все ще доступні з інтернету.
| Розширення | Ризик і перевірка патча |
|---|---|
| JoomShaper SP Page Builder | CVE-2026-48908 дозволяє неавтентифіковане завантаження файлу, який може виконати PHP-код. Дослідницькі дані вказують на вразливість версій до 6.6.1 включно; виправлення є у 6.6.2. |
| Joomlack PageBuilder CK | CVE-2026-56290 є неавтентифікованою arbitrary-file-upload вразливістю, що веде до повного RCE. Дослідницькі дані вказують на PageBuilder CK до 3.5.10 включно; виправлені релізи: 3.6.0, 3.4.10 і 3.1.1 для відповідних гілок Joomla. |
Чому запис у KEV змінює реакцію
Якщо вразливість потрапила до CISA KEV, її варто сприймати як уже експлуатовану, а не як теоретичну примітку до патча. Практичний ризик для сайту: серверний foothold, завантажений PHP, файловий менеджер-бекдор, прихований Super User або невеликий loader, який зберігає доступ після оновлення розширення.
Для SP Page Builder дослідники описують експлуатацію через task asset.uploadCustomIcon і попереджають, що просте вимкнення компонента не є повним захистом. Для PageBuilder CK ключова проблема полягає у помилці контролю доступу під час завантаження файлів, що може перейти у remote code execution. В обох випадках патч закриває відомий вхід, а перевірка компрометації показує, чи хтось уже ним скористався.
Що перевірити спочатку
- Оновіть розширення. Переведіть SP Page Builder на 6.6.2 або новішу версію, а PageBuilder CK на виправлену гілку, що відповідає вашій Joomla. Поки сайт у maintenance mode, оновіть Joomla core та інші розширення.
- Знайдіть усі публічні копії. Перевірте production, staging, старі піддомени, preview-хости вебстудії та тимчасово відновлені резервні копії. Саме забуті Joomla-інсталяції часто сканують першими.
- Перегляньте облікові записи адміністраторів. Шукайте нових Super User, дивні email-домени, входи не у звичний час і акаунти, які не належать клієнту або команді підтримки.
- Пошукайте нові PHP у публічних каталогах. Особливо перевірте
/images/,/media/,/tmp/,/cache/, каталоги assets розширень і директорії шаблонів. Файл із назвою іконки, cache-об’єкта або update helper все одно може містити PHP. - Збережіть access logs перед ротацією. Вам потрібні підозрілі POST-запити до page-builder endpoint, нові файлові шляхи з HTTP 200 і входи адміністратора одразу після спроб завантаження.
- Після cleanup змініть облікові дані. Оновіть паролі Super User, hosting panel, SFTP/SSH keys, database credentials і API tokens, які були на сайті або могли бути доступні з скомпрометованого акаунта.
Якщо сайт уже зачепили, не вважайте видалення одного файлу повним cleanup. Перевстановіть розширення з чистого пакета, порівняйте шаблони з known-good копією, перевірте cron jobs і подивіться, чи домен не почали позначати reputation-системи. Web Application Firewall може зменшити повторні спроби, але він має доповнювати патчинг і cleanup, а не замінювати їх. Для суміжного контексту про CMS-ботнети дивіться наш матеріал про GoTrim і злам WordPress-сайтів.
FAQ
Це стосується кожного Joomla-сайту?
Ні. Термінова перевірка потрібна сайтам із JoomShaper SP Page Builder або Joomlack PageBuilder CK. Але вебстудіям варто інвентаризувати старі Joomla-копії, бо забуті staging-сайти часто залишаються відкритими.
Оновлення достатньо?
Оновлення закриває відому вразливість, але не видаляє web shell або rogue administrator account, якщо їх уже створили. Спочатку встановіть патч, потім перевірте users, files, logs і credentials.
Чи потрібно домашнім користувачам сканувати Windows-ПК через цю новину?
Зазвичай ні. Це проблема Joomla-сервера. Сканування Windows має сенс лише якщо ви завантажували з потенційно зламаного сервера підозрілі backup, PHP-файли або архіви й відкривали їх локально.
Джерела
- CISA. “Known Exploited Vulnerabilities Catalog,” оновлено 7 липня 2026 року, переглянуто 7 липня 2026 року. https://www.cisa.gov/known-exploited-vulnerabilities-catalog
- NIST National Vulnerability Database. “CVE-2026-48908 Detail,” опубліковано 20 червня 2026 року, переглянуто 7 липня 2026 року. https://nvd.nist.gov/vuln/detail/CVE-2026-48908
- NIST National Vulnerability Database. “CVE-2026-56290 Detail,” опубліковано 29 червня 2026 року, переглянуто 7 липня 2026 року. https://nvd.nist.gov/vuln/detail/CVE-2026-56290
- Phil Taylor, mySites.guru. “SP Page Builder Zero Day RCE Fixed in 6.6.2,” mySites.guru, переглянуто 7 липня 2026 року. https://mysites.guru/blog/sp-page-builder-zero-day-uploadcustomicon-rce/
- Phil Taylor, mySites.guru. “PageBuilder CK RCE – CVE-2026-56290,” mySites.guru, переглянуто 7 липня 2026 року. https://mysites.guru/blog/pagebuilderck-unauthenticated-file-upload-rce/
