LMDeploy sob ameaça SSRF explorada em horas expõe recursos internos

Publicada 4 min de lectura 80 leituras

Menos de 13 horas depois de se tornar pública, uma vulnerabilidade de alta gravidade em LMDeploy – o conjunto de ferramentas de código aberto para comprimir, implantar e servir modelos de linguagem e visão – já estava sendo explorada em ambientes reais. A falha, registrada como CVE-2026-33626 com pontuação CVSS 7.5, é uma variante do Server-Side Request Forgery (SSRF) no módulo visão-lenguaje: uma função que descarrega imagens de URLs não valida se esses endereços pertencem a redes internas ou serviços de metadados na nuvem, abrindo a porta a acessos não autorizados a recursos sensíveis.

O vetor é simples e perigoso: o loader de imagens aceita URLs arbitrários. Um atacante que controle a entrada pode forçar o servidor a solicitar recursos internos como o serviço de metadados da instância na AWS (IMDS), bases de dados locais, interfaces administrativas em loopback ou endpoints internos que normalmente não estão acessíveis da Internet. No caso relatado, os atacantes combinaram digitalização de portos internos e exfiltração por DNS OOB para confirmar e explorar a capacidade da SSRF como "primitiva HTTP".

LMDeploy sob ameaça SSRF explorada em horas expõe recursos internos
Imagem gerada com IA.

Que a exploração tenha ocorrido em questão de horas não é por acaso. Na prática, as divulgações técnicas que incluem o fragmento de código vulnerável, o nome do parâmetro e exemplos funcionais atuam como instruções precisas para atores maliciosos – e hoje também como prompts para modelos comerciais – acelerando a tradução de um problema detectado a um exploit operacional. Isto mostra uma dinâmica preocupante no ecossistema de infra-estruturas de IA: tempo de resposta extremamente curto entre publicação e ataque.

As consequências potenciais são materiais e multifacetadas. Robo de credenciais nuvem através de IMDS, reconhecimento e movimento lateral para serviços internos, compromisso de bases de dados ou caudas, e a possibilidade de persistência se o servidor afetado tiver permissões ampliadas são cenários plausível. Para ambientes industriais ou executando controladores e PLCs expostos, a combinação de probes maciços e digitalização seletivos é uma receita para interrupções e manipulação.

Do ponto de vista operacional, a primeira prioridade imediata deve ser conter a exposição. Se a sua organização usar o LMDeploy com suporte de visão‐lenguaje, aplique a correção oficial se já estiver disponível ou desactive temporariamente as funcionalidades de carregamento remoto de imagens. Como medida de contenção adicional, bloco ou restringir o tráfego de saída dos servidores de inferência, implemente regras de egress que permitam apenas domínios e faixas explicitamente necessários e garanta que não exista acesso direto a 169.254.169.254 (IMDS) ou a interfaces loopback desde processos que aceitam URLs de clientes.

Há atenuações específicas na nuvem que reduzem o impacto deste tipo de SSRF. Para instâncias AWS, ativar IMDSv2 e fixar o hop limit ou desativar o acesso a metadados quando não for necessário limitar a capacidade de um atacante para roubar credenciais. Também é recomendável aplicar segmentação de rede estrita, aplicar listas brancas de domínios para fetches salientes e empregar proxies inversos ou validadores que verifiquem whitelist/blacklist de IPs e faixas RFC1918 antes de permitir um pedido externo. Em termos gerais, validar e normalizar entradas que contenham URLs é obrigatório; contornar esta validação foi a raiz do incidente.

Na detecção e resposta, procure indicadores claros: pedidos do servidor para 169.254.169.254, ligações ao loopback 127.0.0.1 desde processos que normalmente não as realizam, cadeias de consulta contendo URLs fornecidas por terceiros, e consultas DNS atípicas para domínios OOB (out‐of‐band). Revise logs do serviço de modelos para padrões de requests que mudem entre diferentes modelos ou que mostrem tentativas de digitalização de portos internos. Se suspeitar de compromisso, isole a instância, coleta evidências e rote credenciais expostas.

LMDeploy sob ameaça SSRF explorada em horas expõe recursos internos
Imagem gerada com IA.

Este incidente deve servir como lembrete de que a segurança em infra-estruturas de modelos não é apenas tradicional: implica considerar como funções concebidas para flexibilidade (como carregar uma imagem remota) podem tornar-se vetores de acesso à rede interna. Os responsáveis por produtos e equipamentos de segurança devem incorporar revisões de design orientadas para a exposição de rede, testes de SSRF e controlos de saída por defeito em qualquer componente que processa URLs externos.

Para aprofundar a prevenção e padrões de mitigação de SSRF, consulte o guia da OWASP sobre o tema e a documentação da AWS sobre o serviço de metadados, que descrevem controles concretos aplicáveis em produção: OWASP SSRF Prevention Cheat Sheet e AWS Instance Metadata Service (IMDS) documentation. Além disso, a própria publicação do achado e a correção podem ser encontradas na assessoria pública do projeto: GitHub Advisory GHSA-6w67-hwm5-92mq.

Em suma, as organizações que implementam modelos e gateways de inferência devem assumir que os exploits chegarão com extrema rapidez após uma divulgação e preparar tanto adesivos como medidas compensatórias e capacidades de detecção. Actualizar, segmentar, monitorar e validar entradas São os pilares para reduzir o risco imediato; a melhoria sustentada exige integrar essas práticas no ciclo de desenvolvimento e implantação de infra-estruturas de IA.

Cobertura

Relacionadas

Mas notícias do mesmo assunto.