Radar Tech: a cadeia de exploração que foi de uma imagem HEIC ao repositório interno em menos de 72 horas

O resumo do dia

A notícia de segurança mais discutida das últimas 24 horas não é uma CVE isolada: é uma cadeia de exploração que atravessou quatro camadas de arquitetura diferentes até chegar a repositórios internos de uma grande empresa de IA. O relatório técnico descreve algo que todo arquiteto deveria estudar, porque nenhum dos elos individuais é exótico — todos são falhas que existem em milhares de sistemas hoje.

O ataque começou, literalmente, com o upload de uma imagem.

Os quatro elos

1. O vetor de entrada. A aplicação aceitava uploads de imagens em formato HEIC/HEIF. Esse formato não era suportado pela biblioteca de verificação rápida usada pela aplicação, então os arquivos eram repassados para um binário externo de conversão (ImageMagick). Isso expôs o parser nativo de decodificação diretamente a arquivos controlados pelo atacante. Um único formato exótico aceito na borda abriu toda a cadeia.

2. O decodificador desatualizado. A biblioteca de decodificação instalada (libheif 1.19.7, em uma imagem baseada em Debian 12) continha um heap buffer overflow que permitia leitura e escrita fora dos limites durante a decodificação de HEIC. O detalhe mais importante: a correção já existia no upstream. O commit foi feito no ano anterior, mas não foi documentado como correção de segurança e por isso nunca recebeu um CVE. Resultado: a correção nunca foi retroportada para o pacote da distribuição, e nenhum scanner de vulnerabilidade acusou — a versão simplesmente parecia estar em dia.

Esse é o elo mais perigoso da história inteira, porque é invisível. "Atualize suas dependências" não resolve um problema que o próprio ecossistema não marcou como problema.

3. O parser sem isolamento. O decodificador rodava dentro do mesmo processo da aplicação web, sem sandbox e sem namespace dedicado. Isso significa que uma corrupção de memória no parser não era um problema do parser — era um problema do serviço inteiro. Os pesquisadores obtiveram execução remota de código no host do fórum a partir desse elo.

4. A confusão de identidade. Com o serviço comprometido, o próximo passo foi o SSO. A troca de código no fluxo OIDC tinha validação insuficiente (redirect/audience), e a aplicação federava identidade com o provedor corporativo. O resultado foi a tomada de conta de um usuário real da plataforma. E aqui está o detalhe que amplifica tudo: a conta comprometida já carregava conectores pré-autorizados. Não foi o login que causou o dano — foram as permissões que vinham penduradas nele. Com a sessão da vítima, os atacantes puderam usar o agente de código da própria conta para abrir um pull request em um monorepo interno.

Do primeiro achado ao acesso ao repositório interno: menos de 72 horas. A correção do lado do provedor levou cerca de 14 horas depois do relatório.

Por que isso é uma lição de arquitetura, não de patch

O instinto comum diante de um caso desses é "atualize a biblioteca". Isso resolve 1 dos 4 elos — e apenas temporariamente, porque os outros três são estruturais:

• Aceitar formatos de arquivo que o sistema não precisa aceitar aumenta superfície de ataque sem contrapartida de valor.
• Executar parser de dado não confiável no mesmo processo da aplicação é transformar qualquer bug de decodificação em comprometimento total do serviço.
• Federar identidade entre serviços de confiança desigual, com validação frouxa de redirect e sessões longas, é criar uma ponte entre um fórum e um repositório de código.
• Autorizar escopo amplo em conectores "por conveniência" transforma um roubo de sessão em comprometimento da cadeia produtiva.

Arquitetura de segurança não é sobre ter as bibliotecas certas. É sobre assumir que cada camada vai falhar em algum momento e projetar para que a falha de uma camada não valide a próxima.

O que fazer nesta semana

• Reduza a superfície de entrada. Faça uma whitelist de formatos que a aplicação realmente precisa processar e rejeite o resto na borda. Se ninguém pediu HEIF/AVIF, eles não deveriam ser aceitos.
• Isole o processamento de mídia. Conversão e decodificação devem rodar em serviço dedicado, com usuário não privilegiado, sistema de arquivos somente leitura e sem acesso à rede interna. Um teste de egress que falha é o critério de aceite.
• Endureça o fluxo OIDC. PKCE, validação de redirect_uri por correspondência exata, TTL de sessão curto e reautenticação obrigatória para ações sensíveis (acesso a código-fonte, por exemplo).
• Trate agentes de IA como novos pontos de enforcement. Se um agente de código tem permissão de escrita em repositório, ele precisa de branch protection, revisão humana obrigatória e um token com escopo mínimo auditável. O caso mostra que o agente da conta comprometida virou o caminho de acesso ao código.
• Verifique backports, não só versões. Um inventário de dependências que compara número de versão não detecta uma correção que nunca foi retroportada. Se você roda imagem de container baseada em distro, o rebuild periódico não é opcional.

O ponto central

Nenhuma dessas quatro falhas é, isoladamente, um desastre. A combinação delas é. E é exatamente por isso que modelagem de ameaças em formato de cadeia — elo por elo, com o controle ausente nomeado em cada um — é mais útil do que uma lista de CVEs. Você não consegue corrigir "o ataque"; consegue quebrar cada elo, e quebrar os primeiros é sempre mais barato.

Publicamos hoje no catálogo um pacote para arquitetos de segurança que faz exatamente isso: transforma um relatório de incidente em um threat model de cadeia de exploração e um ADR de mitigação com plano de implementação verificável. O tema do pacote é esta cadeia — mas o ferramental serve para o próximo incidente.

Bônus do radar: o que mais foi discutido hoje

• Harness de agentes de código fechado enviando código para a nuvem. Outro relatório da janela mostrou um aplicativo de codificação com IA empacotando o workspace inteiro — incluindo histórico .git completo, cache LFS e reflogs — e enviando cifrado para armazenamento em nuvem, com a chave privada retida apenas no servidor. Os toggles da interface não impediam o comportamento. O histórico do git carrega segredos apagados em commits posteriores e nomes de branches não publicadas: é uma superfície de vazamento que quase ninguém audita.
• O debate sobre confiar em harnesses fechados de IA. A reação ao caso acima consolidou uma posição que aparece cada vez mais: os pesos podem ser abertos, mas o harness é onde seus dados vivem. Vale a auditoria.
• Falhas em bibliotecas de parsing de mídia como classe de vulnerabilidade. A mesma equipe expandiu a pesquisa para outros serviços populares e confirmou que uma quantidade surpreendente de software depende do mesmo decodificador. Se a sua aplicação aceita .heic, .heif ou .avif de usuários, vale revisar a rota.

Fechamento

Segurança virou um problema de arquitetura de dados e identidade, não de perímetro. A notícia de hoje é um lembrete caro disso.