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

Коли говорять про «вразливість Joomla» або «злам Joomla», часто змішують дві різні речі: саму CMS і весь сайт, побудований на ній.

Joomla Core — це код, який розробляється та підтримується Joomla Project. Але реальна production-інсталяція зазвичай містить значно більше:

• сторонні компоненти;
• плагіни;
• модулі;
• шаблон;
• template framework;
• page builder;
• додаткові PHP-бібліотеки;
• PHP та веб-сервер;
• облікові записи адміністраторів і користувачів.

Кожен із цих елементів додає власний код і потенційно обробляє HTTP-запити, файли, дані користувачів, сесії або запити до бази даних. Тому поверхня атаки Joomla-сайту значно ширша за код Joomla Core.

Під час аналізу безпеки Joomla-сайту потрібно розділяти щонайменше шість різних категорій ризику.

Тому версія Joomla — важливий, але не єдиний параметр безпеки. Актуальний Core не компенсує старий уразливий компонент, так само як остання версія компонента не компенсує непідтримуваний Core.

Уразливості знаходять у будь-якому складному програмному забезпеченні. Сам факт наявності CVE в історії продукту не означає, що продукт «поганий».

З точки зору супроводу набагато важливіше інше: чи підтримується продукт і чи випускає розробник виправлення після виявлення проблеми.

Нормальний security lifecycle виглядає приблизно так:

Vulnerability discovered
        ↓
Developer investigates the issue
        ↓
Security fix is released
        ↓
Administrator installs the update
        ↓
Known attack vector is closed

Якщо останній крок не виконати, виправлення може існувати місяцями або роками, але конкретний сайт продовжуватиме працювати з уразливим кодом.

Саме тому аргумент «сайт працює — навіщо його оновлювати?» не має відношення до security status. Код може виконувати свої бізнес-функції без помилок і водночас бути застарілим або більше не отримувати виправлень безпеки.

Для старих поколінь Joomla питання оновлення вже не зводиться до отримання нових функцій.

Офіційна підтримка Joomla 3 завершилася 17 серпня 2023 року. Extended LTS для цієї гілки завершився 17 лютого 2025 року.

Joomla 4 також завершила життєвий цикл 14 жовтня 2025 року. Тому у 2026 році сайт, який продовжує працювати на Joomla 3 або Joomla 4, уже знаходиться поза звичайним циклом підтримки своєї major-гілки.

Joomla 5.x продовжує отримувати security fixes, а Joomla 6.x є актуальною major-гілкою Joomla. Офіційний roadmap передбачає security support для Joomla 5.x до жовтня 2027 року, а для Joomla 6.x — до жовтня 2029 року.

Оновлення тільки Joomla Core не робить автоматично актуальним весь сайт.

Компоненти, плагіни, шаблони та frameworks мають власні версії та власний життєвий цикл. Для них окремо випускаються bug fixes і security fixes.

Тому потрібно контролювати актуальність усього стеку:

• Joomla Core;
• компонентів;
• плагінів;
• модулів;
• шаблону;
• template framework;
• page builder;
• PHP;
• серверного ПЗ.

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

JCE та Helix Ultimate тут важливі не як приклади «поганих розширень». Це популярні Joomla-продукти, на яких добре видно, як працює security lifecycle: проблема стосується конкретного діапазону версій, після чого розробник випускає виправлення.

3 червня 2026 року було випущено JCE 2.9.99.5 із виправленням критичної вразливості, яка пізніше отримала ідентифікатор CVE-2026-48907.

Проблема була пов'язана з недостатнім контролем доступу під час імпорту editor profiles. За певного сценарію це дозволяло неавтентифікованому користувачу перейти до завантаження та виконання PHP-коду.

Після основного виправлення JCE також отримав додатковий hardening. 12 червня розробник повідомив, що вразливість уже активно експлуатувалася, exploit-код був публічним, а атаки — автоматизованими.

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

Подібну ситуацію можна побачити на Helix Ultimate. У липні 2026 року Joomla Project як CNA опублікував CVE для двох різних проблем у версіях Helix Ultimate до 2.2.7.

CVE-2026-57829 описує unauthenticated stored XSS. Це означає, що збережений уразливістю JavaScript міг виконуватися у браузері іншого користувача, який переглядав відповідний контент.

CVE-2026-57830 стосується missing authorization і дозволяла неавтентифіковане arbitrary file deletion.

І JCE, і Helix Ultimate демонструють один принцип: наявність історичної CVE не означає, що актуальна версія продукту містить цю саму проблему. Уразливим є конкретний діапазон версій, а адміністратор повинен встановити реліз із виправленням.

Joomla-розширення не виконуються в повністю ізольованому середовищі. Їх PHP-код працює всередині Joomla та під тим самим системним користувачем PHP, що й інші частини сайту.

Залежно від свого призначення розширення може легітимно мати доступ до:

• Joomla API;
• бази даних;
• файлової системи;
• завантаження файлів;
• сесій користувачів;
• ACL;
• параметрів компонента;
• інших можливостей CMS.

Тому критична помилка в розширенні іноді дозволяє перейти від однієї функції компонента до значно ширшої компрометації сайту.

Vulnerable extension
        ↓
Unauthorized operation
        ↓
File modification / data access / code execution
        ↓
Persistence
        ↓
Compromised Joomla site

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

З попередніх прикладів не потрібно робити протилежний висновок, ніби Joomla Core не має власних security issues.

Joomla Project регулярно публікує security releases і виправляє знайдені проблеми в самому Core. Саме для цього існує Joomla Security Centre.

Різниця полягає у правильній атрибуції проблеми.

Якщо уразливість знаходиться в Joomla Core — це проблема Joomla Core. Якщо початковим вектором був JCE, Helix Ultimate або інше розширення — це проблема конкретної версії цього розширення. Якщо атакувальник увійшов через викрадений пароль адміністратора — CVE може взагалі не мати відношення до інциденту.

Сам факт роботи сайту на Joomla не дозволяє визначити джерело компрометації.

У старих сайтів часто накопичується не одна застаріла версія, а цілий ланцюжок залежностей.

Наприклад, стара Joomla залежить від старого PHP. Шаблон використовує framework, який більше не розвивається. Один із компонентів уже не випускає версію для цієї Joomla-гілки. У власному шаблоні накопичилися overrides застарілих layouts.

У результаті просте «оновити Joomla» поступово перетворюється на повноцінний проєкт модернізації.

Old Joomla
    ↓
Old extensions
    ↓
Old template / framework
    ↓
Old PHP requirements
    ↓
Updates become harder
    ↓
Migration is postponed again

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

Визначте точну версію CMS і перевірте, чи знаходиться її major-гілка в офіційному циклі підтримки.

Перевіряти потрібно компоненти, модулі, плагіни, шаблони та frameworks разом із точними версіями.

Не обмежуйтеся тільки розширеннями, які видно на frontend. Встановлений код також потрібно супроводжувати.

Joomla Vulnerable Extensions List містить інформацію про відомі проблеми сторонніх Joomla-розширень і про випадки, для яких уже існують виправлення.

VEL не варто використовувати як єдине джерело. Додатково потрібно перевіряти changelog та security advisory самого розробника.

Якщо розробка завершена і нові релізи більше не виходять, варто планувати заміну такого розширення.

Відсутність CVE не є доказом відсутності вразливості.

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

• версію PHP і її support status;
• права файлів та каталогів;
• власника файлів;
• налаштування веб-сервера;
• можливість виконання PHP у каталогах завантажень;
• ізоляцію сайтів на сервері;
• оновлення операційної системи та серверного ПЗ.

Оновити Joomla та розширення після інциденту необхідно, але самого оновлення недостатньо.

Якщо атакувальник уже отримав можливість записувати або виконувати PHP-код, він міг створити додатковий механізм persistence. Після закриття початкової вразливості такий код може залишатися на сервері.

Потрібно перевірити:

• невідомі PHP-файли;
• PHP у каталогах images, media, tmp та інших upload-каталогах;
• зміни .htaccess;
• зміни .user.ini;
• невідомі або неочікувані system/authentication plugins;
• нових Super Users;
• зміни шаблону;
• зміни Joomla Core;
• дату модифікації підозрілих файлів;
• access та error logs веб-сервера.

Особливо корисно зіставити час появи перших підозрілих файлів із HTTP-запитами в access log. Це може допомогти визначити endpoint або компонент, через який почалася компрометація.

• Використовуйте підтримувану версію Joomla. Якщо сайт ще працює на Joomla 3 або Joomla 4, upgrade вже повинен бути реальною технічною задачею.
• Регулярно оновлюйте Joomla Core. Особливо не відкладайте security releases без технічної причини.
• Оновлюйте сторонні розширення. Оновлення Joomla не встановлює автоматично security fixes сторонніх розробників.
• Перевіряйте changelog та advisory. Особливо для розширень, які працюють із файлами, користувачами, оплатами, формами та API.
• Видаляйте невикористовувані розширення. Не залишайте зайвий код лише тому, що він вимкнений.
• Не використовуйте nulled або модифіковані пакети. Їх код неможливо прирівнювати до офіційного релізу.
• Оновлюйте PHP та серверне ПЗ. CMS не може компенсувати непідтримуване серверне оточення.
• Використовуйте MFA для адміністративних облікових записів.
• Зберігайте резервні копії окремо від робочого сайту.
• Контролюйте зміни файлів і зберігайте серверні логи.

З точки зору безпеки Joomla-сайт і Joomla Core — не одне й те саме.

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

Приклади JCE та Helix Ultimate показують нормальну реальність розробки програмного забезпечення: у конкретній версії знаходять вразливість, проблему виправляють, після чого користувачам потрібно встановити новий реліз. Наявність історичної CVE не робить весь продукт «небезпечним».

Принципова різниця полягає в іншому. Для підтримуваного програмного стеку продовжує працювати цикл «знайшли проблему → випустили виправлення → встановили оновлення». Для EOL-версії покладатися на цей цикл уже не можна.

Тому сайт на Joomla 3 або Joomla 4 не стає безпечним лише тому, що він кілька років стабільно працює і власник не помічав атак. Відсутність видимого інциденту не замінює підтримку безпеки.

Перехід на підтримувану Joomla — це не просто отримання нового інтерфейсу або додаткових функцій. Це повернення сайту до актуального програмного стеку, для якого Joomla Project і розробники розширень можуть випускати сумісні bug fixes та security fixes.

При цьому після фактичного злому не потрібно автоматично звинувачувати Joomla Core. Спочатку слід встановити початковий вектор: ядро CMS, розширення, викрадений обліковий запис, серверне оточення або інший компонент системи.

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

Використані джерела:
Joomla! Project Roadmap — офіційний roadmap Joomla та строки bugfix/security support для Joomla 5.x і Joomla 6.x.
Joomla! Technical Requirements — офіційна інформація про завершення підтримки Joomla 3 та Extended LTS.
Joomla! Versions which are End of Life — розділ офіційного Joomla Forum із статусом Joomla 4.x End of Life.
Joomla Security Centre — офіційні security announcements Joomla Project.
Joomla Vulnerable Extensions List — інформація про відомі проблеми безпеки сторонніх Joomla-розширень.
JCE security update, and a free patch for older sites — офіційне повідомлення JCE про виправлення критичної вразливості, активну експлуатацію та рекомендації для старих сайтів.
CVE-2026-57829 — NVD — unauthenticated stored XSS у Helix Ultimate до 2.2.7.
CVE-2026-57830 — NVD — unauthenticated arbitrary file deletion у Helix Ultimate до 2.2.7.