15 июня 2026 года в логах одного из клиентов — сервиса, через который администрируют сайты на WordPress и Joomla — появилась запись, которая не должна была там появиться. Автоматический сканер, представившийся как «icagenda-batch/1.0», забрал токен, отправил вредоносный файл через форму отправки события, а затем обратился за только что загруженной веб-оболочкой ровно по тому пути, куда компонент сохраняет вложения. Так был обнаружен CVE-2026-48939 — уязвимость в расширении iCagenda для Joomla, получившая максимальную оценку по шкале CVSS: 10.0 из 10.
Проблема сидела в функции «Submit an Event» — форме, через которую посетители сайта предлагают организаторам добавить событие в календарь. Загрузка вложений там не проверялась должным образом, и вместо картинки или документа можно было залить PHP-файл, а потом просто открыть его в браузере и получить выполнение произвольного кода на сервере. Под удар попали все версии 4.x вплоть до 4.0.7 включительно, а также давно устаревшая линейка 3.x — от 3.2.1 до 3.9.14. Разработчик, компания JoomliC, закрыла дыру в версиях 4.0.8 и 3.9.15. Владельцам сайтов на iCagenda стоит проверить папку images/icagenda/frontend/attachments/ — если там завалялся посторонний PHP-файл, его нужно удалить и не откладывать это на потом.
Параллельно та же команда нашла вторую уязвимость с идентичной оценкой 10.0 — на этот раз в расширении Balbooa Forms, тоже для Joomla. Присвоенный номер — CVE-2026-56291. Суть проще некуда: до версии 2.4.0 включительно форма загрузки вложений на фронтенде принимала файл от абсолютно любого анонимного посетителя. Ни авторизации, ни CSRF-токена, ни проверки типа файла. В отчёте это описано без прикрас: «Злоумышленник мог загрузить PHP-файл в публичную папку, а затем запустить его — это неаутентифицированное удалённое выполнение кода, худший из возможных исходов для веб-уязвимости». Патч вышел в версии 2.4.1.
Обе истории — не изолированный случай, а часть куда более масштабной картины. Австралийский центр кибербезопасности (ACSC) выпустил предупреждение о глобальной кампании эксплуатации, которая затрагивает сразу несколько CMS-платформ и плагинов по всему миру. Атакующие методично сканируют сайты в поисках знакомых дыр — неаутентифицированной загрузки файлов, удалённого выполнения кода, SSRF, небезопасной десериализации — и там, где получается, устанавливают веб-шеллы. Такая оболочка становится постоянным каналом доступа: через неё можно возвращаться на сервер снова и снова, уже не заботясь о повторной эксплуатации первоначальной уязвимости.
Список программ, упомянутых ACSC в связи с этой кампанией, довольно пёстрый. Тут и фреймворк Sneeit с CVE-2025-6389, и плагин для WordPress WPBookit с CVE-2025-7852, и популярный Gravity Forms с CVE-2025-12352. Отдельно фигурирует Craft CMS с уязвимостью CVE-2025-32432, ещё один WordPress-плагин Ninja Forms с CVE-2026-0740, китайская MaxSite CMS с CVE-2026-3395, кеширующий плагин Breeze Cache с CVE-2026-3844, аудиоплеер WavePlayer с CVE-2025-12057, движок MetInfo CMS с CVE-2026-29014 и, наконец, ещё одно расширение для Joomla — JCE, с уязвимостью CVE-2026-48907.
Формулировка ACSC звучит без обиняков: «Эта масштабная глобальная кампания эксплуатации демонстрирует стремительно меняющийся киберриск, с которым сталкиваются организации». И дальше — ключевая фраза, ради которой, собственно, всё предупреждение и писалось: развитие искусственного интеллекта ускоряет скорость и масштаб кибератак, сокращая время между публикацией сведений об уязвимости и её практической эксплуатацией.
Именно этот временной разрыв — между раскрытием бага и первой реальной атакой — раньше был единственной подушкой безопасности для админов, которые не успели поставить патч день в день. Судя по хронологии с iCagenda, где эксплуатация началась ещё до официального объявления об уязвимости, подушка сдувается быстрее, чем раньше. Автоматизированные сканеры теперь массово прощупывают тысячи сайтов сразу после появления первых технических деталей, а иногда и раньше — если утечка происходит через закрытые каналы или обратный инжиниринг патча.
Для владельцев сайтов на Joomla практический вывод простой и скучный: обновить iCagenda до 4.0.8 или 3.9.15, Balbooa Forms — до 2.4.1, и после этого вручную пройтись по папкам с вложениями в поисках чужих PHP-файлов. Если сайт использует ещё и JCE — стоит проверить и его на предмет CVE-2026-48907. Автоматика в лице антивирусов на такие вещи часто не реагирует, потому что формально файл лежит там, где ему положено лежать, просто попал он туда не через ту дверь.
Изображение носит иллюстративный характер
Проблема сидела в функции «Submit an Event» — форме, через которую посетители сайта предлагают организаторам добавить событие в календарь. Загрузка вложений там не проверялась должным образом, и вместо картинки или документа можно было залить PHP-файл, а потом просто открыть его в браузере и получить выполнение произвольного кода на сервере. Под удар попали все версии 4.x вплоть до 4.0.7 включительно, а также давно устаревшая линейка 3.x — от 3.2.1 до 3.9.14. Разработчик, компания JoomliC, закрыла дыру в версиях 4.0.8 и 3.9.15. Владельцам сайтов на iCagenda стоит проверить папку images/icagenda/frontend/attachments/ — если там завалялся посторонний PHP-файл, его нужно удалить и не откладывать это на потом.
Параллельно та же команда нашла вторую уязвимость с идентичной оценкой 10.0 — на этот раз в расширении Balbooa Forms, тоже для Joomla. Присвоенный номер — CVE-2026-56291. Суть проще некуда: до версии 2.4.0 включительно форма загрузки вложений на фронтенде принимала файл от абсолютно любого анонимного посетителя. Ни авторизации, ни CSRF-токена, ни проверки типа файла. В отчёте это описано без прикрас: «Злоумышленник мог загрузить PHP-файл в публичную папку, а затем запустить его — это неаутентифицированное удалённое выполнение кода, худший из возможных исходов для веб-уязвимости». Патч вышел в версии 2.4.1.
Обе истории — не изолированный случай, а часть куда более масштабной картины. Австралийский центр кибербезопасности (ACSC) выпустил предупреждение о глобальной кампании эксплуатации, которая затрагивает сразу несколько CMS-платформ и плагинов по всему миру. Атакующие методично сканируют сайты в поисках знакомых дыр — неаутентифицированной загрузки файлов, удалённого выполнения кода, SSRF, небезопасной десериализации — и там, где получается, устанавливают веб-шеллы. Такая оболочка становится постоянным каналом доступа: через неё можно возвращаться на сервер снова и снова, уже не заботясь о повторной эксплуатации первоначальной уязвимости.
Список программ, упомянутых ACSC в связи с этой кампанией, довольно пёстрый. Тут и фреймворк Sneeit с CVE-2025-6389, и плагин для WordPress WPBookit с CVE-2025-7852, и популярный Gravity Forms с CVE-2025-12352. Отдельно фигурирует Craft CMS с уязвимостью CVE-2025-32432, ещё один WordPress-плагин Ninja Forms с CVE-2026-0740, китайская MaxSite CMS с CVE-2026-3395, кеширующий плагин Breeze Cache с CVE-2026-3844, аудиоплеер WavePlayer с CVE-2025-12057, движок MetInfo CMS с CVE-2026-29014 и, наконец, ещё одно расширение для Joomla — JCE, с уязвимостью CVE-2026-48907.
Формулировка ACSC звучит без обиняков: «Эта масштабная глобальная кампания эксплуатации демонстрирует стремительно меняющийся киберриск, с которым сталкиваются организации». И дальше — ключевая фраза, ради которой, собственно, всё предупреждение и писалось: развитие искусственного интеллекта ускоряет скорость и масштаб кибератак, сокращая время между публикацией сведений об уязвимости и её практической эксплуатацией.
Именно этот временной разрыв — между раскрытием бага и первой реальной атакой — раньше был единственной подушкой безопасности для админов, которые не успели поставить патч день в день. Судя по хронологии с iCagenda, где эксплуатация началась ещё до официального объявления об уязвимости, подушка сдувается быстрее, чем раньше. Автоматизированные сканеры теперь массово прощупывают тысячи сайтов сразу после появления первых технических деталей, а иногда и раньше — если утечка происходит через закрытые каналы или обратный инжиниринг патча.
Для владельцев сайтов на Joomla практический вывод простой и скучный: обновить iCagenda до 4.0.8 или 3.9.15, Balbooa Forms — до 2.4.1, и после этого вручную пройтись по папкам с вложениями в поисках чужих PHP-файлов. Если сайт использует ещё и JCE — стоит проверить и его на предмет CVE-2026-48907. Автоматика в лице антивирусов на такие вещи часто не реагирует, потому что формально файл лежит там, где ему положено лежать, просто попал он туда не через ту дверь.
