Якщо ви отримали від мене лист із посиланням на цю сторінку, це тому, що ваш сайт, вочевидь, використовує версію iCagenda (com_icagenda компанії JoomliC, розширення календаря подій для системи керування вмістом Joomla), уражену відомою проблемою безпеки. Ця сторінка пояснює, у чому полягає проблема, як перевірити, чи стосується вона вас, і як її виправити.

Це повідомлення стосується вразливості CVE-2026-48939: критичної, активно експлуатованої вади, яка дозволяє довільне завантаження файлу без автентифікації, що веде до віддаленого виконання коду, через фронтенд-форму розширення “Submit an Event” (форма подання події). Її додано до каталогу Known Exploited Vulnerabilities Агентства кібербезпеки та захисту інфраструктури США (CISA) 10 липня 2026 року.

Дві умови, і обидві мають виконуватися

Ваш сайт уражений проблемою віддаленого виконання коду, коли обидві ці умови є істинними:

  1. iCagenda належить до лінійки 4.0.x і має версію нижчу за 4.0.8 (тобто від 4.0.0 до 4.0.7), і
  2. ядро Joomla має версію нижчу за 6.1.2.

Якщо у вас встановлено iCagenda 4.0.8 або новішу версію, вас це не стосується. А якщо ваше ядро Joomla має версію 6.1.2 або новішу, вас це також не стосується, навіть зі старою версією iCagenda, тому що саме ядро блокує завантаження. Якщо це стосується вашого сайту, тут можна припинити читання, хіба що зауважте: оновити iCagenda все одно варто.

Друга умова є тим пунктом, у якому ця сторінка не погоджується з власним бюлетенем розробника, який стверджує, що проблема стосується лише сайтів на Joomla 6. Насправді вона стосується також повністю оновлених сайтів на Joomla 4 і Joomla 5, і нижче я наводжу докази цього, тому що за посиланням ви побачите, що розробник стверджує інше.

Якщо у вас уражена версія, оновіть iCagenda, а оскільки цю ваду експлуатували ще до появи виправлення, також перевірте свій сайт на ознаки того, що хтось устиг побувати там раніше (див. Якщо ви використовували уражену версію нижче).

Примітка для тих, хто використовує старішу лінійку 3.9.x. Опублікований діапазон CVE включає й 3.9.x, і розробник виправив цю лінійку теж, у версії 3.9.15. За результатами власного читання коду та тестування, лінійка 3.9.x використовує інший, захищений шлях коду для завантаження, тож результат у вигляді віддаленого виконання коду там недосяжний: на Joomla 4 і 5 завантаження блокує ядро, а на Joomla 6 цього шляху коду взагалі більше не існує, тож функція просто видає помилку. Це не привід ігнорувати оновлення. Ті самі випуски виправляють відсутню перевірку авторизації, яка дозволяє анонімному відвідувачу додати на ваш сайт незатверджену подію (а на Joomla 4 і 5 ще й файл дозволеного типу). Менш серйозна проблема, але її все одно варто виправити: оновіться до 3.9.15 або новішої версії. Також зауважте, що розробник надає патчі безпеки для лінійки 3.9.x лише до 13 жовтня 2026 року.

Чи справжнє це повідомлення?

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

Я прочитав лише два публічні файли, які ваш сайт віддає будь-кому, хто їх запитує: маніфест компонента iCagenda за адресою /administrator/components/com_icagenda/icagenda.xml і маніфест ядра Joomla за адресою /administrator/manifests/files/joomla.xml. Обидва є простими XML-файлами з номером версії, і це ті самі два файли, що описані нижче в розділі Як перевірити свої версії, тож ви можете побачити те саме, що бачив я. Це все, що я зробив. Я свідомо не надсилав вашу форму події, не завантажував нічого і не запитував теку вкладень на вашому сайті. Цей шлях згадується далі на цій сторінці лише як місце, де ви можете перевірити власний сайт. Ця перевірка жодним чином не торкається ваших даних, вашої панелі адміністрування чи будь-якої закритої частини сайту.

Якщо ви хочете перевірити, хто я, контактні дані наведено внизу цієї сторінки та на сторінці Про мене.

Чому це важливо

iCagenda публікує календар подій на сайтах Joomla. Одна з його функцій дозволяє відвідувачу подати подію через фронтенд-форму, за бажанням доклавши файл, який потрапляє до теки images/icagenda/frontend/attachments/.

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

Для того, щоб це стосувалося вас, нічого не потрібно вмикати. Форма не обов’язково має бути опублікована чи видима для відвідувачів: в уражених версіях контролер, що стоїть за нею, приймав надсилання незалежно від цього.

Це не теоретичний ризик. NVD оцінює її на 9,8 з 10 (за новою системою оцінювання органу, що призначив ідентифікатор, її оцінка становить 10,0), і вона активно експлуатується в реальних умовах. Розробник повідомляє, що експлуатація почалася 15 червня 2026 року о 08:00 UTC, ще до появи виправлення, і описує атаки як автоматизовані. CISA додала її до каталогу Known Exploited Vulnerabilities 10 липня 2026 року.

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

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

У чому ця сторінка розходиться з бюлетенем розробника

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

Небезпечні завантаження файлів і так блокувалися за замовчуванням у всіх версіях Joomla до Joomla 6. Критичну вразливість завантаження мали лише встановлення iCagenda на Joomla 6 (6.0.0-6.1.1).

Ось що я виміряв на власних ізольованих інсталяціях. У цьому жодного разу не був задіяний сторонній сайт.

  • iCagenda 4.0.x виконує завантаження через клас фреймворку Joomla\Filesystem\File, який походить із пакета joomla/filesystem, що постачається разом із ядром Joomla. Він не використовує старіший клас Joomla CMS з такою самою назвою, який завжди мав перевірку безпечного файлу і, ймовірно, саме його і мав на увазі бюлетень.
  • Цей метод фреймворку отримав власну перевірку безпечного файлу (параметр $allowUnsafe і тест isSafeFile) лише у joomla/filesystem 4.2.0, тобто у версії, яка постачається з Joomla 6.1.2.
  • Версії, які фактично постачаються з перевіреними мною випусками Joomla: Joomla 4.4.14 постачається з filesystem 2.0.2 (без перевірки), Joomla 5.4.7 постачається з 3.2.0 (без перевірки), а Joomla 6.1.2 постачається з 4.2.0 (перевірка присутня).

Тож повністю оновлений сайт на Joomla 4 чи Joomla 5, на якому працює iCagenda від 4.0.0 до 4.0.7, справді вразливий, і саме тому ця сторінка формулює умову щодо Joomla як “нижче за 6.1.2”, а не “лише Joomla 6”. Ані в опублікованому записі CVE, ані в записі NVD, ані в каталозі CISA це питання взагалі не обмежується версією Joomla; таке обмеження зустрічається лише в реченні з бюлетеня розробника.

Як перевірити свої версії

Вам не обов’язково вірити мені на слово щодо жодного з цих чисел, а перевірити потрібно два.

Версія вашого iCagenda, з файлу маніфесту (вхід у систему не потрібен): відкрийте

yourdomain.com/administrator/components/com_icagenda/icagenda.xml

і прочитайте елемент <version>. Це один із двох файлів, які я читав.

Версія вашого iCagenda, з адміністративної панелі:

  1. Увійдіть до адміністрування Joomla (зазвичай за адресою yourdomain.com/administrator).
  2. Перейдіть до System потім Manage потім Extensions.
  3. Знайдіть iCagenda і запишіть встановлену версію.

Зверніть увагу, який саме файл icagenda.xml ви читаєте. Пакет iCagenda також постачає вбудований плагін пошуку з маніфестом такої самої назви, який має власний, не пов’язаний із ним номер версії. Лише шлях компонента, наведений вище, показує, яку версію розширення насправді запущено.

Версія ядра Joomla: в адмініструванні перейдіть до System потім System Information. Або прочитайте /administrator/manifests/files/joomla.xml і візьміть значення елемента <version>. Це другий файл, який я читав.

Версію iCagenda неможливо визначити з публічного вихідного коду сторінки, і не варто навіть пробувати. Фронтенд-ресурси розширення несуть загальносайтовий медіахеш Joomla, а не номер версії, а те єдине число, схоже на версію, яке справді з’являється у вихідному коді сторінки, належить пакету ресурсів модуля календаря (невелике число на кшталт 1.0.4) і не має жодного стосунку до компонента. Єдиною чесною перевіркою є файл маніфесту або екран адміністрування.

Потім застосуйте правило з початку цієї сторінки: лінійка 4.0.x нижче за 4.0.8 і ядро нижче за 6.1.2 означає, що сайт уражений.

Як оновитися

Найбезпечніший шлях: оновитися через саму Joomla, попередньо створивши резервну копію:

  1. Створіть резервну копію сайту (файли й базу даних), перш ніж щось змінювати. Більшість хостинг-провайдерів пропонують резервне копіювання в один клік, або скористайтеся розширенням резервного копіювання для Joomla.
  2. В адмініструванні Joomla відкрийте Extensions потім Manage потім Update і натисніть Find Updates. Якщо оновлення iCagenda вказано у списку, встановіть його звідси.
  3. Якщо там не з’являється оновлення, завантажте поточний випуск безпосередньо від розробника, JoomliC, і встановіть його через Extensions потім Install.
  4. Яку версію встановлювати: 4.0.8 є випуском, який виправляє цю проблему, але на момент написання цього тексту поточним є випуск 4.0.11, і випуски після 4.0.8 додають подальший захист для тієї самої функції, зокрема блокують виконання коду з медіатеки iCagenda. Встановлюйте 4.0.11, а не зупиняйтеся на 4.0.8. У старішій лінійці встановлюйте 3.9.15 або новішу версію.
  5. Альтернативно, оновлення ядра Joomla до версії 6.1.2 або новішої також закриває саме цю проблему, але це не замінює оновлення розширення: відсутня перевірка авторизації міститься в самому iCagenda, і виправити це може лише оновлення iCagenda.
  6. Після оновлення підтвердьте новий номер версії за наведеними вище кроками і перевірте, що ваш календар усе ще відображається, а подання подій усе ще працює так, як ви очікуєте.

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

Якщо ви використовували уражену версію

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

Оновлення закриває точку входу і захищає функцію файлових вкладень, але не усуває наслідки на вже скомпрометованому сайті. […] Зберігайте копію будь-яких підозрілих файлів як докази, видаліть їх, змініть паролі та облікові дані Joomla і перевірте весь свій сайт, а не лише теку iCagenda.

Ось що ви (або ваш вебмайстер) можете шукати на власному сайті:

  • PHP-файли в теці images/icagenda/frontend/attachments/. Ця тека повинна містити лише вкладення подій. На хостингу з Linux перевірка виглядає так:

    find images/icagenda/frontend/attachments -name '*.php' -type f
  • Незатверджені анонімні події у вашій черзі модерації, чого ви б не очікували, якщо ніколи не відкривали подання подій для публіки.
  • Записи у ваших логах доступу від сканера, який ідентифікує себе як icagenda-batch/1.0.

Починаючи з версії 4.0.8, iCagenda також самостійно перевіряє ознаки компрометації і показує попередження після оновлення, якщо їх знаходить. Розробник відверто зазначає, що відсутність такого попередження не є гарантією, тож це радше корисний сигнал, аніж підтвердження повної чистоти.

Якщо ви знайдете щось із перерахованого, вважайте сайт скомпрометованим: збережіть копії підозрілих файлів як докази, а потім видаліть їх, змініть усі облікові дані (адміністратора Joomla, бази даних, FTP/SSH, панелі хостингу), перегляньте облікові записи користувачів Joomla та групи, до яких вони належать, і перевірте весь сайт, а не лише теку iCagenda. Відновлення з резервної копії, зробленої до 15 червня 2026 року, часто безпечніше за очищення на місці, тому що залишений бекдор може звести очищення нанівець. Якщо у вашій організації є команда безпеки чи національний CERT, залучіть їх.

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

У мене немає вебмайстра / я не даю ради

Якщо сайтом опікуєтеся не ви, перешліть, будь ласка, цю сторінку тому, хто ним опікується (вашому веброзробнику, агенції або хостинг-провайдеру). Він швидко впізнає наведені вище кроки.

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

Контакти

Evan Harris, дослідник безпеки

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

Джерела

Офіційні бюлетені та відстеження

Розробник (JoomliC)