Kaltura позволяет выполнить код без пароля — исправления пока нет
Уведомление CERT/CC от 25 августа 2026 года относит к уязвимым выпуски библиотеки проигрывателя Kaltura 2.45, 2.103 и более ранние версии ветки 2.x, если извне доступен файл mwEmbedLoader.php. Готового исправления производитель пока не предоставил.
Две связанные ошибки позволяют удалённому злоумышленнику без учётной записи читать локальные файлы и при определённой конфигурации выполнять команды с правами веб-сервера. Для выполнения кода требуется файловый кеш и возможность разместить исполняемый сценарий в каталоге, обслуживаемом сервером; чтение файлов от типа кеша не зависит.
Как две уязвимости образуют цепочку атаки
Общей точкой входа служит управляемый клиентом параметр ServiceUrl. Загрузчик обращается по указанному в нём адресу, а затем передаёт полученный ответ функции десериализации без надёжной проверки происхождения и структуры данных.
При эксплуатации CVE-2026-19913 злоумышленник может заставить сервер обратиться к локальному файлу вместо обычного сетевого ресурса. Когда разбор ответа завершается ошибкой, содержимое файла способно попасть в сообщение, возвращаемое клиенту. Так атакующий получает данные, доступные системной учётной записи веб-сервера, включая конфигурационные файлы, если права системы разрешают их чтение.
CVE-2026-19912 использует ту же небезопасную обработку ответа вместе с недостаточной проверкой идентификатора конфигурации. Технический разбор цепочки атаки связывает этот идентификатор с построением пути кеша: управляемые данные можно записать за пределами предназначенного каталога. Если итоговый файл оказывается в опубликованном каталоге, где разрешено исполнение сценариев PHP, отдельный запрос к нему запускает внедрённый код.
Почему тип кеша меняет риск, но не устраняет ошибку
Известная цепочка удалённого выполнения кода требует записи на диск. При файловом кеше атакующий воздействует и на сохраняемое содержимое, и на путь назначения. Для успешного завершения атаки сервер также должен разрешать исполнение созданного файла в доступном через интернет каталоге.
Конфигурация только с Memcached не создаёт такой файл на диске, поэтому описанный способ довести атаку до выполнения команд становится неприменим. Это не делает компонент безопасным: управляемый адрес всё ещё принимается, а полученный ответ по-прежнему проходит небезопасную десериализацию.
На чтение локальных файлов выбор кеша не влияет. Оно происходит до этапа записи, необходимого второй цепочке. Поэтому наличие сетевого кеша снижает риск одного известного варианта атаки, но не заменяет блокирование уязвимого загрузчика и последующее обновление.
Как определить, затронута ли конкретная установка
Проверку следует начинать с доступности серверного файла, а не с одного лишь присутствия платформы. Если загрузчик отсутствует либо сетевой запрос из недоверенной зоны до него не доходит, описанная удалённая точка входа закрыта. Уязвимый код при этом может оставаться в файловой системе и потребовать обновления после появления исправленной версии.
- Найдите загрузчик. Проверьте каталоги библиотеки проигрывателя, настройки веб-сервера и правила обратного прокси. Нужно учитывать не только основной домен, но и старые виртуальные узлы, на которых мог сохраниться прежний проигрыватель.
- Установите версию. Для ветки 2.x нельзя считать отсутствие конкретного номера в кратком перечне доказательством безопасности. Решающее условие — наличие уязвимого файла и доступного маршрута к нему.
- Проверьте границу доступа. По таблицам маршрутизации, журналам и правилам фильтрации определите, может ли неавторизованный клиент обратиться к загрузчику и передать его параметры. Для инвентаризации не требуется подставлять локальный файл или исполняемое содержимое.
- Определите тип кеша. Запись на диск поддерживает известную цепочку выполнения команд. Использование только сетевого кеша разрывает этот этап, однако не закрывает возможность чтения файлов.
- Проверьте исполнение в каталогах. В опубликованных каталогах кеша и соседних путях не должно разрешаться выполнение серверных сценариев. Такое ограничение уменьшает последствия записи файла, но само по себе не исправляет обработку входных данных.
Что временно закрыть до выпуска исправления
Основная защитная мера — полностью запретить доступ к mwEmbedLoader.php из недоверенных сетей. Если старый проигрыватель больше не используется, компонент следует отключить. В остальных случаях ограничение можно установить на веб-сервере, обратном прокси или межсетевом экране веб-приложений так, чтобы внешний запрос не достигал файла.
Если загрузчик необходим для действующей системы, параметру серверного адреса нужен строгий разрешённый список. Проверка должна сопоставлять полную схему, имя узла и порт, разрешая обращения только к заранее определённым адресам прикладного интерфейса. Локальные файловые схемы, неизвестные узлы и иные протоколы следует отклонять.
Для идентификатора конфигурации необходимо запрещать абсолютные пути, разделители каталогов и переходы к родительскому каталогу. Дополнительные барьеры — запрет исполнения сценариев в каталогах кеша и ограничение исходящих соединений сервера. Каждый из них разрывает отдельное звено известной атаки, поэтому не должен рассматриваться как самостоятельное исправление.
На момент раскрытия безопасная версия не была объявлена. До выпуска обновления определённым защитным состоянием остаётся недоступность уязвимого загрузчика для внешнего клиента. Разрешённый список адресов, сетевой кеш и запрет исполнения файлов снижают риск, но не удаляют небезопасную десериализацию из компонента.
Читайте также:
Подпишитесь на рассылку
Получайте свежие новости Web3, AI и криптовалют прямо на вашу почту.