Cinco meses de silêncio: o player de vídeo que ninguém lembra que instalou

A pesquisa é de Gerjan Wemekamp, que assina como AndDone. Ela começou de um jeito comum: enumeração de subdomínios em um programa de bug bounty, um player de vídeo antigo rodando em um deles, bibliotecas JavaScript desatualizadas o bastante para chamar atenção.

O que ele encontrou ali foi um parâmetro não documentado, ServiceUrl, e uma mensagem de erro generosa demais: failed to unserialize server result. Duas informações em uma linha. O valor que ele controlava virava uma URL que o servidor buscava, e os bytes de volta iam direto para o unserialize() do PHP.

Um file:///etc/passwd? confirmou a primeira parte. Depois veio /opt/kaltura/app/configurations/local.ini, que guarda string de conexão de banco em texto claro, senha de administrador, senha de console e referências de host interno.

Onde deixa de ser problema de um cliente

A versão no caminho da URL era v2.103, a mais nova que a Kaltura publica. Isso descartou a explicação confortável de que se tratava de um servidor esquecido rodando algo antigo.

Ele então foi ao código-fonte do Kaltura Server, na tag West-23.5.0, e achou a origem em deployment/uiconf/KalturaClientBase.php. A função doQueue() monta a URL concatenando o serviceUrl sem qualquer validação, e quando a resposta não desserializa, coloca os bytes crus dentro da mensagem de exceção. Três coisas erradas no mesmo trecho: origem controlada pelo atacante, desserialização sem verificação de origem, assinatura ou lista de classes permitidas, e um caminho de erro que devolve o que foi buscado.

Uma consulta de buscador por inurl:/html5/html5lib/ devolveu mais de 630 resultados. O próprio pesquisador registra que o número indica exposição do componente, não hosts confirmadamente vulneráveis. A ordem de grandeza é que importa.

E há um agravante que muda a natureza do caso: o loader vulnerável também está exposto na infraestrutura de CDN compartilhada e multi-inquilino da própria Kaltura, que serve conteúdo de player para um grande número de clientes. Não é só quem instalou o produto no próprio servidor. É todo mundo servido por aqueles hosts.

Do vazamento de arquivo à execução de código

A segunda falha usa o mesmo parâmetro por outro caminho. Se o atacante controla o que o servidor busca e desserializa, ele consegue fazer a aplicação instanciar um objeto PHP de sua escolha. A pergunta seguinte é o que a aplicação faz com esse objeto.

A resposta está em kInfraFileSystemCacheWrapper::getFilePath(), que monta o destino em disco concatenando o diretório base de cache com um caminho derivado do parâmetro uiconf_id, sem sanitização. Sequências de travessia como ../ passam direto.

Controle do conteúdo pelo objeto desserializado, controle do destino pelo uiconf_id. Em um servidor PHP com webroot que executa PHP, isso é um web shell. O arquivo escapa do diretório de cache, cai em uma pasta acessível pela web e executa como o usuário do servidor.

O pesquisador é explícito sobre os limites do que validou. A cadeia completa até o web shell foi demonstrada no contêiner kaltura/server:latest, que é de janeiro de 2019 e traz o Kaltura Server 14.12.0 sobre CentOS 6, porque a fornecedora não publica imagem atual. Na release corrente ele verificou que as duas metades continuam presentes e que a desserialização ainda executa: o KalturaClientBase.php é byte a byte idêntico ao de 2019, e o getFilePath() segue sem realpath() nem rejeição de travessia.

A linha do tempo do silêncio

Data	Ação
23/03/2026	Primeiro contato com o canal de segurança da Kaltura, por e-mail pessoal.
13/04/2026	Reenvio de e-mail corporativo, na hipótese de filtro de spam.
23/05/2026	Contato com o CISO da fornecedora pelo LinkedIn.
02/07/2026	Escalonamento por CERT nacional, que levou o caso até a CISA.
08/07/2026	Notificação formal da Kaltura pelo CERT/CC.
25/08/2026	Publicação da VU#308749. Status do fornecedor: desconhecido. Sem declaração.

Leitura LATAMSEC

A Kaltura é uma daquelas plataformas que entram na organização pela porta de outro departamento. Universidade que precisa gravar aula. Emissora que precisa de biblioteca de vídeo. Área de comunicação interna que precisa de portal de treinamento. Na América Latina, o setor educacional é especialmente exposto, e o inventário de segurança raramente registra "player de vídeo" como ativo crítico.

Mas o local.ini não sabe disso. Ele guarda credencial de banco em texto claro, e credencial de banco costuma ser reaproveitada. Uma leitura de arquivo em um portal de vídeo esquecido pode terminar em um banco que ninguém associava àquele sistema.

Há ainda o problema de responsabilidade. Quando a exposição está na CDN compartilhada da fornecedora, o cliente não tem o que corrigir. Ele pode bloquear o próprio endpoint, e deve. O que serve os embeds pelo domínio da Kaltura está fora do alcance dele.

Sem patch, o roteiro do pesquisador é o que existe. Bloquear ou remover o mwEmbedLoader.php no WAF, no proxy reverso ou na CDN, porque quem não serve player mwEmbed legado não tem motivo para deixar esse caminho acessível. Rejeitar qualquer ServiceUrl que não seja o próprio host de API, e recusar esquemas que não sejam http ou https. Rejeitar uiconf_id com travessia, caminho absoluto ou separador de diretório. Negar execução de PHP nos diretórios de cache. Restringir a saída de rede do servidor de aplicação, já que a execução remota depende de ele buscar algo no host do atacante.

E o item que costuma ser esquecido: se houve exposição, rotacionar tudo que está no local.ini. Banco, senha de admin, senha de console, segredo de partner, chave de API. Depois procurar nos logs por requisições ao mwEmbedLoader.php carregando o parâmetro ServiceUrl, e por arquivos .php inesperados sob os diretórios de cache da html5lib. O parâmetro está sob desserialização insegura desde bem antes de março, e o horizonte de busca não deveria começar na data da publicação.

Uma nota final, sobre um assunto que voltará a aparecer. O pesquisador conta que usou um assistente de IA no trecho de revisão de código: para mapear onde o objeto injetado desemboca e para encontrar a forma de abusar do cache. Ele mantinha o Kaltura rodando em contêiner, então cada hipótese era checada contra uma instância viva. Vale ler isso pelo que é. A parte difícil continuou sendo humana, da enumeração ao Param Miner até a leitura do doQueue(). O que mudou foi a velocidade entre suspeitar de um sink e confirmá-lo. Do lado de quem defende, essa é exatamente a mesma aceleração disponível para quem procura o próximo mwEmbedLoader.php sem intenção de avisar ninguém.