CVE-2026-33626 afeta o módulo de visão-linguagem do LMDeploy e permite que o carregador de imagens faça requisições para metadados de nuvem, serviços internos e endpoints externos controlados pelo atacante.
| Componente | LMDeploy com suporte a visão-linguagem, especificamente a função load_image() em lmdeploy/vl/utils.py. |
| Vetor | SSRF acionado por URLs arbitrárias processadas pelo carregador de imagens, sem validação adequada contra endereços internos, privados ou serviços de metadados. |
| Impacto | A falha pode permitir acesso a serviços internos, metadados de nuvem, varredura de portas internas e recursos sensíveis acessíveis a partir do servidor de modelo. |
| Prioridade | Atualizar ambientes afetados, restringir egress HTTP/DNS do servidor de inferência e auditar requisições de VLM para destinos internos ou incomuns. |
| Versões | Todas as versões 0.12.0 e anteriores do toolkit com suporte a visão-linguagem são indicadas como afetadas. |
| Artefatos | Exploração observada contra AWS Instance Metadata Service, Redis, MySQL, uma interface administrativa HTTP secundária e um endpoint OOB DNS em requestrepo[.]com. |
| IoCs | Uma tentativa observada teve origem em 103.116.72[.]119 e ocorreu em 22 de abril de 2026 às 03:35 UTC. |
A vulnerabilidade CVE-2026-33626 no LMDeploy expõe uma primitiva de Server-Side Request Forgery no fluxo de carregamento de imagens usado por módulos de visão-linguagem. O LMDeploy é um toolkit aberto voltado à compressão, implantação e serviço de modelos de linguagem de grande porte, e o defeito fica no caminho em que a função load_image() busca uma URL fornecida ao processamento de conteúdo visual. A falha recebeu pontuação CVSS 7.5 e foi descrita como de alta severidade porque o servidor vulnerável passa a atuar como origem de requisições para destinos escolhidos pelo atacante, incluindo endereços que normalmente não são expostos diretamente à internet.
A exploração pública apareceu em menos de 13 horas após a divulgação no GitHub, com uma primeira tentativa observada 12 horas e 31 minutos depois da publicação. A atividade detectada não ficou limitada a confirmar a existência da falha. Em uma sessão de oito minutos, o operador usou o carregador de imagens de visão-linguagem como um cliente HTTP genérico para consultar alvos internos atrás do servidor de modelo. Esse comportamento muda a leitura operacional do incidente: a falha não é apenas um bug de validação de URL, mas uma abertura para reconhecimento interno a partir de uma aplicação de IA que pode ter acesso privilegiado a redes de serviço, metadados de instância e planos administrativos locais.
O impacto confirmado no material disponível é a capacidade de alcançar recursos a partir do ponto de vista do servidor LMDeploy. Isso inclui tentativa de contato com AWS Instance Metadata Service, Redis, MySQL, uma interface administrativa HTTP secundária e um endpoint de DNS fora de banda. O acesso a credenciais de nuvem é um risco técnico condicionado quando o serviço consegue consultar metadados expostos e quando as proteções de metadados, identidade e egress não bloqueiam esse caminho. Não há base para afirmar que credenciais foram efetivamente roubadas nessa atividade específica; o que há é evidência de uso da SSRF para enumeração, varredura e teste de saída.
A causa técnica está na ausência de validação suficiente na função load_image() em lmdeploy/vl/utils.py. Em um fluxo legítimo, esse componente recupera imagens por URL para alimentar um modelo de visão-linguagem. Quando a entrada aceita uma URL arbitrária e o código realiza a busca sem bloquear endereços privados, loopback, redes internas ou serviços de metadados, o atacante consegue deslocar a requisição para dentro da zona de confiança do servidor. A requisição não parte do navegador do usuário nem do host do atacante; ela parte do processo que executa o LMDeploy, carregando consigo a posição de rede, as permissões de rota e eventuais credenciais de ambiente daquele servidor.
A sessão observada em 22 de abril de 2026 às 03:35 UTC teve 10 requisições distintas distribuídas em três fases. As requisições alternaram entre modelos de visão-linguagem como internlm-xcomposer2 e OpenGVLab/InternVL2-8B, uma escolha que pode reduzir padrões óbvios de repetição em logs de aplicação quando a telemetria é agregada por modelo usado. O comportamento procurou transformar o endpoint de inferência em uma ferramenta de reconhecimento: primeiro alcançando serviços de metadados e endpoints internos, depois verificando serviços comuns como Redis e MySQL, e por fim usando DNS fora de banda para confirmar que o servidor conseguia estabelecer comunicação com infraestrutura externa controlada pelo operador.
O uso de um endpoint OOB em requestrepo[.]com é relevante porque comprova uma propriedade diferente da simples leitura de HTTP interno. Ele mostra que o servidor vulnerável pode emitir tráfego de saída para um domínio externo e que o operador consegue observar callbacks associados ao teste. Em uma exploração real, essa confirmação ajuda a medir se o ambiente permite egress, se há resolução DNS funcional e se respostas ou metadados podem ser correlacionados fora do ambiente alvo. A atividade descrita também procurou enumerar a superfície de API após testar a saída, o que indica uma sequência técnica de reconhecimento, validação de canal e mapeamento de funcionalidade exposta pelo serviço.
A superfície afetada abrange implantações do LMDeploy 0.12.0 e anteriores que tenham suporte a visão-linguagem habilitado e aceitem URLs de imagem em fluxos acessíveis a usuários, clientes, integrações ou sistemas automatizados. O risco cresce quando o servidor de inferência roda em nuvem, dentro de uma VPC, sub-rede corporativa ou ambiente que consiga alcançar serviços internos não publicados na internet. Nesses cenários, a aplicação de IA vira ponte para ativos que dependiam da segmentação de rede como controle principal.
Ambientes de inferência costumam ficar próximos de credenciais, buckets, filas, bancos, caches e endpoints administrativos porque precisam carregar modelos, receber requisições e interagir com infraestrutura de apoio. A SSRF explora exatamente essa proximidade. Se o servidor consegue resolver nomes internos, alcançar 169.254.169.254 ou conectar a portas de serviços locais, o atacante pode obter sinais sobre o desenho da rede mesmo sem executar código no host. O resultado prático pode ser uma lista de portas abertas, serviços alcançáveis e respostas de endpoints que revelam configuração, versão, permissões ou caminhos de administração.
- Implantações do LMDeploy
0.12.0e anteriores com módulo de visão-linguagem ativo. - Endpoints que aceitam URLs de imagens remotas e repassam essas URLs para
load_image(). - Servidores de modelo em nuvem com acesso ao
AWS Instance Metadata Serviceou a serviços internos. - Redes onde
Redis,MySQLou interfaces administrativas HTTP são acessíveis a partir do host de inferência. - Ambientes sem controle estrito de egress HTTP e DNS para processos de IA.
A investigação deve começar pelos logs de aplicação do LMDeploy, logs do proxy reverso e registros de API que armazenem parâmetros de entrada enviados a modelos de visão-linguagem. O sinal principal é a presença de URLs que não representam imagens legítimas de negócio ou que apontam para endereços internos, metadados de nuvem, portas incomuns, hosts administrativos ou domínios de callback. Como a atividade observada alternou modelos VLM em uma sequência curta, a correlação por janela temporal é mais importante do que a análise isolada de um único modelo ou rota.
No endpoint, a caça deve observar conexões de saída originadas pelo processo do LMDeploy ou pelo contêiner que hospeda o servidor de inferência. Requisições para AWS Instance Metadata Service, conexões para Redis e MySQL internos, tentativas contra interfaces administrativas HTTP e consultas DNS para domínios que não fazem parte da operação normal são sinais fortes. Em nuvem, fluxos de VPC, registros de firewall, DNS resolver logs e telemetria de egress podem revelar o padrão de varredura mesmo quando a aplicação não registra o corpo completo da requisição.
Também é útil procurar sessões curtas com múltiplas URLs distintas, respostas de erro geradas por timeouts internos, códigos HTTP variados retornados pelo carregador de imagens e aumento súbito de chamadas a modelos de visão-linguagem que normalmente processam imagens hospedadas em origens conhecidas. A presença do IP 103.116.72[.]119 em logs de borda deve ser tratada como indicador de investigação, não como critério único de detecção, porque a exploração de SSRF pode ser reproduzida por outras origens rapidamente após a divulgação pública.
- Parâmetros de imagem contendo
http://169.254.169.254, endereços privados, loopback ou nomes internos. - Sequências curtas de requisições alternando entre
internlm-xcomposer2eOpenGVLab/InternVL2-8B. - Conexões de saída do servidor LMDeploy para portas associadas a
Redis,MySQLou interfaces HTTP administrativas. - Consultas DNS ou callbacks para
requestrepo[.]comou domínios OOB equivalentes usados para teste de egress. - Eventos de 22 de abril de 2026 próximos de 03:35 UTC envolvendo origem
103.116.72[.]119.
A resposta deve combinar atualização do componente, redução da superfície de entrada e controles de rede. O primeiro passo é retirar de produção versões afetadas quando houver correção disponível para o LMDeploy e validar se os serviços com suporte a visão-linguagem realmente precisam aceitar imagens por URL remota. Onde a funcionalidade for necessária, a aplicação deve permitir apenas origens aprovadas, validar resolução DNS após redirecionamentos, bloquear redes privadas e impedir acesso a metadados de instância, loopback e faixas internas.
A contenção de rede é essencial porque uma correção de código não substitui segmentação. O processo ou contêiner do LMDeploy deve ter egress limitado a destinos esperados, com bloqueio explícito para serviços de metadados, RFC1918 quando não houver necessidade operacional, portas administrativas internas e DNS arbitrário. Em nuvem, controles de identidade e metadados devem exigir mecanismos resistentes a SSRF quando disponíveis, além de reduzir privilégios associados ao servidor de inferência. Se uma instância exposta processou requisições suspeitas, a revisão deve incluir tokens temporários, papéis de nuvem associados ao host e registros de acesso a serviços internos.
Depois da correção, a validação precisa reproduzir apenas testes controlados e autorizados para confirmar que URLs internas não são buscadas pelo servidor. A equipe deve registrar bloqueios esperados, verificar que callbacks externos não são acionados e confirmar que os logs mantêm informação suficiente para reconstruir futuras tentativas. A mitigação efetiva não depende de um único controle: ela exige atualização, validação de entrada, isolamento de rede, política de egress e monitoramento contínuo do comportamento do serviço de inferência.
- Atualizar o LMDeploy afetado e remover de produção versões
0.12.0e anteriores quando a correção aplicável estiver disponível. - Bloquear em aplicação URLs para endereços privados, loopback, metadados de nuvem e hosts internos não autorizados.
- Restringir egress HTTP, HTTPS e DNS do servidor de inferência aos destinos necessários para a operação.
- Revisar credenciais e papéis de nuvem associados a hosts que possam ter recebido requisições SSRF.
- Adicionar alertas para chamadas de VLM contendo URLs internas, portas de serviço e domínios de callback OOB.
0 Comentários