Um dos reprodutores multimídia mais conhecidos do mundo está no centro de um novo alerta de segurança depois da divulgação de duas vulnerabilidades capazes de atingir diretamente a memória do processo do VLC Media Player.
As falhas são identificadas como CVE-2026-56711 e CVE-2026-73324 e atingem versões do VLC 3.0.0 até a 3.0.23.
O problema mais grave pode permitir que dados controlados pelo atacante sejam escritos além dos limites de uma área de memória. A segunda vulnerabilidade permite que o programa leia dados além do espaço reservado, criando potencial para exposição de informações presentes na memória.
Mas a informação que circula de que “as duas falhas precisam apenas de um vídeo malicioso” merece uma correção importante.
Os dois vetores não são iguais.
A primeira vulnerabilidade pode ser acionada por uma imagem PNG especialmente criada — inclusive quando ela é carregada por determinados conteúdos ou playlists. Já a segunda está relacionada ao módulo RealRTSP e envolve comunicação com um servidor malicioso.
A falha mais grave recebeu pontuação 8,6
A CVE-2026-56711 é a vulnerabilidade de maior severidade das duas.
Ela recebeu pontuação 8,6 no CVSS v4.0 e está relacionada a um erro de cálculo durante a alocação de memória para imagens.
O problema ocorre porque determinados valores utilizados pelo VLC podem sofrer um integer overflow antes que o programa determine corretamente quanto espaço precisa reservar.
Na prática, o software pode acreditar que precisa de uma área de memória menor do que aquela realmente necessária para processar o conteúdo.
Depois:
o decoder continua escrevendo os dados.
E eles ultrapassam o limite da região que foi alocada.
O ataque pode começar com um PNG preparado
O vetor envolve uma imagem PNG construída especificamente para explorar o problema.
Arquivos PNG possuem metadados que descrevem características da imagem, incluindo suas dimensões.
Um atacante pode manipular valores relacionados à largura e à altura para provocar o cálculo incorreto.
O VLC processa essas informações e calcula o tamanho do buffer necessário.
O problema está justamente nessa matemática.
Quando determinados valores são suficientemente grandes, o cálculo pode ultrapassar a capacidade prevista pelo tipo inteiro utilizado.
O resultado é um valor incorreto.
O VLC então reserva menos memória do que realmente precisa
Imagine que o programa deveria reservar uma área muito grande.
O cálculo sofre overflow.
O resultado final passa a representar um número menor.
O sistema então reserva memória com base nesse valor incorreto.
Quando o decoder começa a colocar os dados da imagem naquele espaço, encontra um problema:
os dados são maiores que o buffer.
A escrita continua além do limite.
Esse comportamento é conhecido como:
heap out-of-bounds write.
E corrupção de heap é uma classe perigosa de vulnerabilidade
Escrever fora dos limites de uma região de memória pode simplesmente fazer o programa travar.
Mas também pode alterar informações utilizadas pelo próprio aplicativo.
Dependendo da estrutura da memória e das condições do sistema, vulnerabilidades desse tipo podem, em alguns casos, ser transformadas em primitivas mais poderosas de exploração.
Por isso, falhas de corrupção de memória recebem atenção especial dos pesquisadores.
Entretanto, existe uma diferença fundamental entre:
“a vulnerabilidade permite corromper memória”
e:
“já existe execução remota de código comprovada.”
No caso atual, não há evidência pública de que um exploit funcional esteja sendo utilizado para transformar essa falha em execução arbitrária de código contra usuários do VLC.
Portanto, não é correto dizer que hackers já podem “controlar qualquer computador com VLC”
Essa seria uma extrapolação.
O que está comprovado é uma vulnerabilidade de escrita fora dos limites da memória.
A possibilidade teórica de desenvolver exploração adicional existe justamente pela natureza da falha.
Mas isso não significa que pesquisadores tenham demonstrado uma cadeia completa capaz de assumir o controle do computador em todas as plataformas.
Mitigações modernas como ASLR e outras proteções de memória também aumentam a dificuldade de transformar corrupção de memória em execução de código confiável.
O arquivo precisa ser processado pelo VLC
Existe ainda outro elemento importante.
A falha não significa que simplesmente baixar um arquivo automaticamente comprometa o computador.
O conteúdo precisa chegar ao componente vulnerável e ser processado pelo VLC.
Isso pode acontecer quando o usuário abre diretamente um arquivo malicioso ou quando determinado conteúdo faz com que a imagem especialmente preparada seja carregada.
Essa exigência de interação reduz o risco quando comparado a uma vulnerabilidade explorável automaticamente pela internet.
Mas não elimina o problema.
Afinal, a função de um media player é justamente:
abrir arquivos recebidos de outras pessoas.
Um arquivo aparentemente comum pode esconder dados preparados para exploração
Essa é uma das dificuldades das vulnerabilidades em parsers multimídia.
Para o usuário, o arquivo parece ser apenas:
uma imagem;
um vídeo;
uma playlist;
um stream.
Mas internamente existem estruturas complexas.
Cabeçalhos.
Metadados.
Tamanhos.
Offsets.
Chunks.
Codecs.
O software precisa interpretar todas essas informações.
Se uma delas provoca um cálculo incorreto de memória, o conteúdo passa a funcionar como entrada para exploração.
A segunda vulnerabilidade é a CVE-2026-73324
O outro problema possui características diferentes.
A CVE-2026-73324 recebeu pontuação 6,9 no CVSS e está relacionada ao módulo RealRTSP do VLC.
Aqui, o problema não é uma escrita além dos limites.
É uma:
leitura fora dos limites da memória.
Ou, tecnicamente:
out-of-bounds read.
Isso significa que o programa pode acabar lendo bytes localizados depois do final de um buffer.
Um servidor malicioso pode provocar o problema
O RealRTSP é utilizado para comunicação relacionada a streams utilizando o protocolo RTSP.
Segundo a análise técnica da vulnerabilidade, um servidor controlado pelo atacante pode responder ao VLC com uma string especialmente preparada.
O código espera uma determinada estrutura.
O problema aparece quando a resposta ultrapassa aproximadamente 4.096 bytes sem possuir a terminação esperada.
O VLC pode então continuar lendo a memória além do fim do buffer.
Dessa vez, o problema não é destruir a memória — é enxergar além dela
A diferença entre as duas falhas pode ser resumida assim:
CVE-2026-56711:
escreve onde não deveria.
CVE-2026-73324:
lê onde não deveria.
Uma escrita fora dos limites pode causar corrupção.
Uma leitura fora dos limites pode revelar informações.
Em determinadas condições, isso pode expor dados que estavam próximos daquele buffer na memória do processo.
O conteúdo da memória pode incluir informações inesperadas
Memória de processo é dinâmica.
Pode conter temporariamente:
endereços;
dados de arquivos;
metadados;
informações internas;
tokens;
strings;
estruturas utilizadas pelo aplicativo.
Isso não significa que a CVE-2026-73324 automaticamente roube senhas, documentos ou credenciais.
Não existe garantia de que determinado segredo esteja exatamente na área acessada.
Mas o princípio da vulnerabilidade é preocupante porque permite que o programa ultrapasse uma fronteira que deveria existir.
Também não significa que um atacante possa “ler toda a RAM do computador”
Essa seria outra interpretação exagerada.
A vulnerabilidade está relacionada à memória acessível no contexto do processo e às condições específicas criadas durante a comunicação.
Ela não entrega automaticamente acesso arbitrário a toda a memória física da máquina.
Ainda assim, vazamentos de memória podem ser valiosos.
Inclusive porque, em determinados ataques sofisticados, uma vulnerabilidade de leitura pode ajudar a explorar outra vulnerabilidade.
Vazamento e corrupção podem ser peças complementares
Uma das principais dificuldades na exploração moderna é lidar com proteções como ASLR, que randomiza endereços de memória.
Se o atacante não sabe onde determinadas estruturas estão localizadas, explorar uma corrupção de memória fica mais difícil.
Uma vulnerabilidade de leitura pode, em determinados cenários, revelar endereços.
Uma vulnerabilidade de escrita pode permitir manipular memória.
Isso não significa que as duas falhas do VLC já tenham sido combinadas dessa maneira.
Mas explica por que pesquisadores tratam vulnerabilidades de leitura e escrita de memória com seriedade.
Há uma correção importante na informação que circula nas redes
A publicação compartilhada afirma que:
“Both need only a booby-trapped video.”
Essa simplificação não descreve precisamente os vetores divulgados.
A CVE-2026-56711 está ligada ao processamento de PNG especialmente preparado, que pode ser aberto diretamente ou referenciado por conteúdo como uma playlist.
Já a CVE-2026-73324 está ligada ao RealRTSP e pode ser provocada por uma resposta malformada fornecida por um servidor controlado pelo atacante.
Portanto, não é correto resumir os dois problemas como:
“basta abrir um vídeo infectado.”
O módulo RealRTSP também não está necessariamente presente em todas as distribuições
Existe outra particularidade.
O RealRTSP está habilitado nas builds oficiais do VLC distribuídas pelo VideoLAN.
Algumas distribuições Linux, entretanto, podem compilar seus próprios pacotes sem esse componente.
Nesses sistemas específicos, a segunda vulnerabilidade pode não estar acessível pelo mesmo vetor.
Isso significa que o impacto real depende também de:
sistema operacional;
build utilizada;
componentes compilados;
configuração.
As versões 3.0.0 até 3.0.23 aparecem como afetadas
Os registros das vulnerabilidades identificam como vulnerável toda a linha do VLC desde:
3.0.0
até:
3.0.23.
Isso representa um intervalo significativo da série 3.x.
A versão 3.0 foi lançada originalmente em 2018.
Portanto, o problema pode estar presente em código utilizado durante vários anos.
Mas isso não significa que a vulnerabilidade tenha sido explorada durante todo esse período.
Presença de código vulnerável e exploração real são coisas diferentes.
A 3.0.23 também está vulnerável
Esse detalhe é particularmente importante para os usuários.
A versão 3.0.23, disponibilizada em 2026, também aparece na faixa afetada.
Portanto, simplesmente estar usando essa versão não elimina o problema.
Até a divulgação das vulnerabilidades, a 3.0.23 permanecia como a versão estável pública mais recente da série 3.0.
E aqui existe outra correção importante: não há atualização estável pública corrigindo as duas falhas
A imagem afirma:
“VideoLAN patched two VLC media player flaws.”
Essa formulação pode dar a impressão de que uma versão estável corrigida já está disponível para todos.
Até a apuração desta publicação, porém, os registros públicos indicavam que VLC 3.0.23 continuava afetado, e a página pública de segurança do VideoLAN ainda não apresentava um novo boletim específico com uma versão estável posterior corrigindo essas duas CVEs.
Há mudanças no código do projeto relacionadas à prevenção de overflow, mas isso não deve ser confundido automaticamente com:
“todo usuário já recebeu o patch.”
Esse é um detalhe relevante para quem utiliza o VLC neste momento.
O pesquisador responsável é Fabian Wahle
As duas vulnerabilidades foram creditadas ao pesquisador Fabian Wahle, da Hap Security.
A divulgação pública ocorreu no início de setembro de 2026.
Os problemas foram registrados separadamente porque atingem componentes e comportamentos diferentes do VLC.
Uma falha está relacionada à alocação de imagens.
A outra:
ao processamento de respostas RealRTSP.
Não há evidência pública de exploração ativa
Outro ponto importante para evitar alarmismo:
até o momento, não há indicação pública confiável de que as vulnerabilidades estejam sendo exploradas em ataques reais.
Isso significa que não existe evidência conhecida de campanhas distribuindo arquivos especialmente preparados para comprometer usuários do VLC por meio dessas CVEs.
Mas a publicação dos detalhes técnicos altera o cenário.
Depois que uma vulnerabilidade se torna pública, pesquisadores e criminosos podem analisar o código e tentar desenvolver provas de conceito.
Por isso, a janela entre:
divulgação e atualização
merece atenção.
O que fazer enquanto não há uma versão estável corrigida?
A recomendação mais importante é reduzir a exposição a conteúdo não confiável.
Até que uma versão corrigida seja disponibilizada e instalada, usuários devem evitar abrir no VLC arquivos, imagens, playlists e streams recebidos de fontes desconhecidas ou suspeitas.
Também é prudente evitar conectar o VLC a servidores RealRTSP não confiáveis.
Para ambientes corporativos, equipes de TI podem monitorar o lançamento de uma nova versão e priorizar sua distribuição assim que o VideoLAN disponibilizar oficialmente a correção.
Baixar o VLC apenas do site oficial continua sendo importante — mas não resolve esta falha
Há uma diferença entre instalar uma cópia adulterada do programa e explorar uma vulnerabilidade existente na versão legítima.
Neste caso, o problema está no código do próprio software.
Portanto, mesmo uma instalação legítima do VLC pode estar vulnerável.
Baixar exclusivamente de canais oficiais continua sendo uma boa prática, mas não substitui:
instalar atualizações de segurança.
Media players possuem uma superfície de ataque enorme
O caso também ajuda a explicar por que programas multimídia aparecem frequentemente em pesquisas de segurança.
O VLC precisa interpretar uma quantidade gigantesca de formatos.
Vídeos.
Áudios.
Imagens.
Legendas.
Playlists.
Streams.
Protocolos de rede.
Cada formato possui estruturas próprias.
Cada parser representa código que recebe dados potencialmente controlados por terceiros.
Quanto mais formatos um player entende, mais entradas ele precisa interpretar
A grande vantagem do VLC sempre foi sua capacidade de abrir praticamente qualquer conteúdo multimídia.
Essa flexibilidade também significa uma base de código extremamente complexa.
Um único arquivo pode combinar:
container;
codec de vídeo;
codec de áudio;
legenda;
metadados;
imagem de capa.
Cada componente precisa ser analisado corretamente.
E basta um erro em um cálculo de tamanho para surgir uma vulnerabilidade de memória.
Arquivos multimídia não devem ser tratados como conteúdo passivo
Para muitos usuários, existe uma percepção de segurança:
“é só um vídeo.”
Mas um arquivo multimídia é uma estrutura de dados que será interpretada por milhares de linhas de código.
O mesmo vale para:
PDF;
imagem;
documento;
fonte;
arquivo compactado.
Eles não precisam conter um executável tradicional para explorar uma vulnerabilidade.
O programa que abre o arquivo é quem pode possuir a falha.
O risco agora está no intervalo entre divulgação e correção
As duas vulnerabilidades estão publicamente documentadas.
A versão 3.0.23 aparece como vulnerável.
Os mecanismos técnicos já são conhecidos.
E ainda não há evidência pública de exploração ativa.
Esse cenário cria uma fase especialmente importante:
a janela de exposição.
É justamente nesse período que usuários e administradores precisam acompanhar as atualizações do projeto.
A boa notícia é que não estamos diante de um ataque comprovadamente disseminado contra milhões de instalações.
A notícia menos confortável é que uma das falhas permite corrupção de memória e recebeu pontuação 8,6, enquanto a versão estável atual da série 3.0 permanece entre as afetadas.
Para um software cuja função principal é abrir conteúdo recebido de diferentes origens, isso é motivo suficiente para atenção.
