Безопасность 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.