КИБЕРБЕЗОПАСНОСТЬ

Две уязвимости Kaltura без патча открыли путь к RCE

Две уязвимости Kaltura без патча позволяют без авторизации читать файлы сервера и выполнять код; риск затрагивает и клиентские инсталляции, и shared-хосты.

✍️ Редакция iTech News | 27.08.2026 | ⏱ 5 мин | Источник: The Hacker News
👁

В библиотеке HTML5-плеера Kaltura нашли две опасные дыры без готового исправления: одна позволяет удаленно читать файлы с сервера, вторая — выполнять на нем код без авторизации. Для тех, кто использует уязвимости Kaltura в продакшене, история неприятна не только CVE с высокими баллами, но и тем, что под ударом оказались и собственные установки клиентов, и общая инфраструктура вендора.

О проблеме сообщает The Hacker News со ссылкой на CERT Coordination Center. Речь идет о CVE-2026-19913 и CVE-2026-19912 в библиотеке mwEmbed, которую Kaltura также распространяет как html5lib. Обе уязвимости завязаны на небезопасную десериализацию в endpoint'е mwEmbedLoader.php. По данным CERT/CC, злоумышленнику не нужен ни логин, ни сессионный токен Kaltura: достаточно сетевого доступа к этому endpoint'у.

Первая уязвимость, CVE-2026-19913, ведет к чтению произвольных файлов. Параметр ServiceUrl в mwEmbedLoader.php используется как адрес для backend-запросов API. Дальше PHP-клиент Kaltura берет то, что вернулось по этому адресу, и передает в unserialize(), не проверяя источник, схему или содержимое. Если вместо нормального API-адреса подсунуть путь вида file://, сервер попытается открыть локальный файл. Десериализация, как и следовало ожидать, ломается, но сырые байты файла попадают в текст ошибки и возвращаются атакующему. Исследователь Gerjan Wemekamp из AndDone показал, что так можно добраться, например, до /opt/kaltura/app/configurations/local.ini, где хранятся строки подключения к БД, пароли администратора и консоли, а также внутренние адреса хостов.

Вторая уязвимость, CVE-2026-19912, развивает тот же баг уже до удаленного выполнения кода. Здесь в игру вступает параметр uiconf_id, который при записи файлов в кэш приклеивается к пути без нормальной санации. Сценарий выглядит так: атакующий указывает в ServiceUrl адрес с вредоносным сериализованным объектом, сервер его подтягивает и десериализует, а затем через uiconf_id с последовательностями вроде ../ запись уводится из каталога кэша в веб-доступную директорию. После этого достаточно открыть записанный файл по HTTP, и PHP-код выполнится от имени веб-сервера. Исследователь отдельно оговорил, что полный сценарий с web shell он демонстрировал на docker-образе Kaltura Server 2019 года, а на актуальном релизе подтвердил наличие обеих частей цепочки и работоспособность самой десериализации.

Технически здесь нет ничего нового: небезопасная десериализация в PHP давно считается классикой плохих решений. Нюанс в другом — насколько долго этот код жил в продакшене. The Hacker News проверил публичный серверный репозиторий Kaltura и обнаружил, что файл deployment/uiconf/KalturaClientBase.php с вызовом unserialize() совпадает побайтно в 21 релизе, от Jupiter-10.9.0, закоммиченного 27 апреля 2015 года, до West-23.5.0 от 13 августа 2026 года. Следы той же логики видны и в более ранней ветке, коммит которой датирован 10 марта 2014 года. Ирония в том, что Kaltura уже вычищала unsafe deserialization в 2017 году после другого пакета проблем, но конкретно этот участок кода тогда не тронули.

Для рынка это означает неприятную комбинацию из трех факторов. Во-первых, патча нет. CERT/CC прямо пишет, что не смог связаться с Kaltura для координации исправления, а статус вендора по обоим CVE остается неизвестным. Во-вторых, уязвимый endpoint выставлен наружу не только у отдельных клиентов, но и на shared, multi-tenant CDN-инфраструктуре Kaltura, поэтому ошибка потенциально масштабируется сразу на множество арендаторов. В-третьих, даже если конкретный путь до RCE не сработает в среде с memcache-only вместо файлового кэша, это не делает систему безопасной: чтение файлов никуда не исчезает, а с ним уходят конфиги, секреты и база для следующего этапа атаки.

Практический вывод для разработчиков и администраторов довольно приземленный. Если legacy-плеер mwEmbed уже не нужен, endpoint лучше просто убрать или закрыть на уровне WAF, reverse proxy или CDN. Если нужен, то ServiceUrl должен жить по строгому allow-list: только собственный API-хост, только HTTP(S), без экзотики вроде file://. Параметр uiconf_id нужно резать на входе, отбрасывая обходы каталогов, абсолютные пути и любые разделители директорий. Отдельно CERT/CC советует запрещать выполнение PHP в кэш-каталогах, ограничивать исходящий сетевой доступ с приложения и, если endpoint был доступен извне, ротировать все секреты из local.ini: пароли БД, админские учетные данные, partner secrets и API-ключи. Список затронутых версий включает html5lib v2.45, v2.103 и более ранние релизы, а также другие ветки v2.x, где доступен уязвимый mwEmbedLoader.php.

Отдельный штрих к этой истории — состояние экосистемы вокруг CVE. Исследователь оценил CVE-2026-19912 в 10.0, а CVE-2026-19913 в 9.1, но это именно reporter-assigned оценки. В NVD записей на 25 августа 2026 года еще не было, а в каталог CISA KEV обе уязвимости не попали. Для корпоративной безопасности это еще один повод не ждать, пока «официальные базы дозреют». Если endpoint торчит наружу, риск уже вполне прикладной: сначала утекут конфиги и ключи, потом кто-нибудь проверит, можно ли дотянуться до записи PHP-файла в доступную директорию.

История с уязвимости Kaltura хорошо показывает старую проблему современной веб-инфраструктуры: опаснее всего не нулевой день с громким брендом, а код, который годами лежит на видном месте, переживает релизы и работает в общей среде сразу на многих арендаторов. Пока у вендора нет публичного исправления и внятной коммуникации, ответственность снова ложится на тех, кто держит сервисы в бою: инвентаризировать endpoint'ы, ограничивать доверие к внутренним параметрам и считать любой старый PHP-код с unserialize() не «техническим долгом», а живым инцидентом. Подробности исходного разбора собраны в материале The Hacker News.

Поделиться: Telegram X LinkedIn