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. Автоматика в лице антивирусов на такие вещи часто не реагирует, потому что формально файл лежит там, где ему положено лежать, просто попал он туда не через ту дверь.