Remote Code Execution
Corrija agora. Ela está sob exploração confirmada pelo CISA e tem exploit funcional público.
Apply mitigations per vendor instructions, follow applicable BOD 22-01 guidance for cloud services, or discontinue use of the product if mitigations are unavailable.
Resumo
Falha de code injection (CWE-94) no componente de API do Ivanti Endpoint Manager Mobile (EPMM), decorrente de uma implementação insegura da biblioteca Hibernate Validator, que permite a um atacante já autenticado executar código arbitrário no servidor via requisições de API manipuladas. O risco real é maior do que o CVSS 7.2 sugere porque essa CVE foi explorada em conjunto com CVE-2025-4427 (bypass de autenticação no mesmo componente API), formando uma cadeia que dá RCE completo sem qualquer credencial — e essa cadeia está confirmada em exploração ativa, com registro no catálogo KEV da CISA.
Detalhamento técnico
A vulnerabilidade está no componente de API do EPMM (nome anterior: MobileIron Core), especificamente na forma como parâmetros de requisições são processados e validados antes de alimentar a biblioteca Hibernate Validator. A Ivanti e a CISA atribuem a causa raiz a uma implementação insegura dessa biblioteca open-source, referenciada como CVE-2025-35036 — ou seja, o defeito de fundo não é exclusivo do código da Ivanti, mas de como o produto integra o Hibernate Validator sem sanitizar adequadamente entrada controlada pelo cliente da API.
O CWE associado (CWE-94, Code Injection) indica que o atacante consegue injetar expressões ou payloads que são interpretados e executados pelo mecanismo de validação em tempo de execução, em vez de serem tratados apenas como dados. Isso normalmente ocorre quando validadores customizados ou expressões de validação (como SpEL ou constraints do Bean Validation) processam valores de entrada sem restrição de escopo, permitindo que o valor injetado escape do contexto de validação e alcance execução de código no processo da aplicação.
O vetor CVSS (AV:N/AC:L/PR:H/UI:N/C:H/I:H/A:H) descreve o cenário isolado: rede, sem interação do usuário, mas exigindo privilégios altos (PR:H) — ou seja, autenticação válida no componente de API antes de disparar o payload. Isolada, a falha já é grave por comprometer confidencialidade, integridade e disponibilidade do host que roda o EPMM, dado que a exploração ocorre no contexto do processo de aplicação, tipicamente com privilégios elevados no servidor.
Como é explorada
Isoladamente, a exploração de CVE-2025-4428 exige uma conta autenticada no componente de API do EPMM com privilégios suficientes para acionar os endpoints afetados, e então enviar uma requisição de API com valores manipulados que acionem a rota insegura de validação do Hibernate Validator, resultando em execução de código no servidor. Esse é o cenário descrito na CVE em si (PR:H — privilege required: high).
Na prática, a exploração observada e reportada publicamente não depende de credenciais: pesquisadores e a própria CISA documentam a combinação com CVE-2025-4427, um bypass de autenticação no mesmo componente de API, que permite a um atacante não autenticado obter acesso equivalente ao necessário para então acionar a injeção de código desta CVE. Encadeadas, as duas falhas produzem RCE remoto e não autenticado contra instâncias EPMM expostas à internet — o cenário mais crítico e o que motivou a entrada no catálogo KEV com prazo de remediação. Não há PoC pública detalhada aqui que reproduzamos, mas a existência de módulo Metasploit e de PoC pública, somada à confirmação de exploração ativa, indica que o exploit da cadeia já circula e é usado por múltiplos atores.
O impacto final reportado é execução arbitrária de código no servidor EPMM, o que em ambientes de gestão de dispositivos móveis (MDM) significa potencial controle sobre a infraestrutura de gerenciamento de toda a frota de dispositivos móveis da organização — de onde um atacante pode pivotear para políticas de dispositivo, certificados e, dependendo da integração, para a rede interna.
Versões
Como se proteger
A Ivanti publicou correção para os branches suportados do EPMM. O advisory oficial (link nas referências) deve ser consultado para o número exato de build corrigido no branch específico em uso, já que a numeração de patch da Ivanti varia por linha de versão (11.12.x, 12.3.x, 12.4.x, 12.5.x); a orientação de maior confiança é aplicar a versão de correção referenciada no próprio advisory da Ivanti para o EPMM, sem assumir que apenas a versão 12.5.0.0 ou anterior é a barreira — trate qualquer versão anterior à corrigida no seu branch como vulnerável.
Como essa CVE só atinge sua gravidade máxima quando combinada com o bypass de autenticação (CVE-2025-4427), a mitigação eficaz exige corrigir ambas simultaneamente — corrigir apenas uma das duas deixa a outra ainda explorável em cenários específicos (uma com atacante autenticado, outra com bypass de auth). Não expor a interface de administração/API do EPMM diretamente à internet é um controle compensatório real enquanto o patch não é aplicado, assim como restringir acesso via firewall/VPN a IPs confiáveis e monitorar contas administrativas por atividade anômala.
O que não funciona como mitigação: rotacionar senhas de administradores não resolve o problema quando a cadeia de exploração inclui bypass de autenticação — o atacante nunca precisa da senha legítima. Da mesma forma, WAF genérico tem eficácia limitada contra injeção que ocorre dentro da camada de validação de bean, a menos que a regra seja específica para os endpoints de API do EPMM identificados no advisory.
Como detectar
Procure por requisições ao componente de API do EPMM com payloads incomuns em parâmetros normalmente validados (campos que deveriam conter apenas texto simples, números ou formatos rígidos recebendo expressões, sequências de escape ou strings anormalmente longas/estruturadas). Logs de acesso mostrando chamadas de API bem-sucedidas (200/201) para endpoints administrativos originadas de IPs não corporativos, especialmente combinadas com tentativas anteriores de acesso não autenticado a esses mesmos endpoints (indício de encadeamento com CVE-2025-4427), são o sinal mais forte de tentativa de exploração da cadeia completa.
Como a exploração final ocorre na camada de validação da aplicação e pode não deixar rastro distinto em logs de acesso HTTP padrão (a requisição em si pode parecer uma chamada de API legítima), a ausência de sinal óbvio não é garantia de que o sistema não foi comprometido — processos filhos inesperados gerados pelo processo Java do EPMM, conexões de saída não usuais a partir do host, ou arquivos novos em diretórios de execução do serviço são indicadores mais confiáveis de exploração bem-sucedida do que qualquer assinatura de rede isolada.