As falhas CVE-2026-1281 e CVE-2026-1340 permitem execução remota de código sem autenticação em appliances Ivanti EPMM e já foram exploradas contra um número limitado de clientes.
| Componente | Ivanti Endpoint Manager Mobile, especificamente os recursos In-House Application Distribution e Android File Transfer Configuration. |
| Vetor | Requisições HTTP especialmente construídas contra endpoints expostos do appliance, explorando injeção de código sem autenticação. |
| Impacto | Execução remota arbitrária de código no appliance EPMM, com risco de persistência por web shells ou reverse shells e acesso a dados sensíveis de dispositivos gerenciados. |
| Prioridade | Aplicar o pacote RPM correto, investigar logs e configurações antes de considerar o appliance íntegro, e reconstruir ou restaurar a partir de backup confiável quando houver sinais de comprometimento. |
| Versões | EPMM 12[.]5[.]0[.]0 e anteriores, 12[.]6[.]0[.]0 e anteriores, 12[.]7[.]0[.]0 e anteriores, além de EPMM 12[.]5[.]1[.]0 e anteriores e 12[.]6[.]1[.]0 e anteriores, conforme os ramos de correção RPM informados. |
| Mitigação | As correções RPM estão disponíveis, mas devem ser reaplicadas após upgrade de versão; a correção permanente foi indicada para o EPMM 12[.]8[.]0[.]0. |
A Ivanti liberou atualizações de segurança para duas vulnerabilidades críticas no Ivanti Endpoint Manager Mobile, rastreadas como CVE-2026-1281 e CVE-2026-1340. Ambas receberam pontuação CVSS 9.8 e foram descritas como falhas de injeção de código capazes de levar à execução remota de código sem autenticação. O ponto operacional mais importante é que a exploração não é apenas teórica: a empresa reconheceu exploração em um número muito limitado de clientes no momento da divulgação, e as duas falhas foram posteriormente incluídas no catálogo de vulnerabilidades exploradas conhecidas da CISA.
As falhas afetam funcionalidades específicas do EPMM: In-House Application Distribution e Android File Transfer Configuration. A delimitação é relevante para inventário e resposta, porque o próprio aviso separa esses problemas de outros produtos da Ivanti. Ivanti Neurons for MDM, Ivanti Endpoint Manager e Ivanti Sentry não aparecem como afetados por essas duas vulnerabilidades no material recebido. Para equipes responsáveis por mobilidade corporativa, a prioridade deve ser tratar appliances EPMM expostos como ativos de alto risco, especialmente quando acessíveis pela internet ou integrados a serviços internos de identidade, VPN, distribuição de aplicativos e gestão de dispositivos móveis.
A correção tem uma particularidade operacional: o pacote RPM disponibilizado não persiste após uma atualização de versão do appliance. Se o EPMM for atualizado para uma nova versão e o pacote não for reaplicado, o ambiente pode voltar a ficar vulnerável dentro do ramo afetado. A correção definitiva foi indicada para o EPMM 12[.]8[.]0[.]0. Portanto, a resposta não deve ser reduzida a instalar um pacote uma única vez; ela precisa incluir controle de mudança, validação pós-upgrade e comprovação de que o ramo instalado recebeu a correção adequada.
A análise dos patches indicou que a correção RPM alterou a configuração do Apache HTTPd para substituir scripts Bash usados no fluxo vulnerável por classes Java introduzidas no ajuste. Dois artefatos citados na análise são /mi/bin/map-appstore-url e /mi/bin/map-aft-store-url. A presença desses scripts no caminho de processamento é relevante porque a vulnerabilidade foi associada à forma como parâmetros de uma requisição HTTP eram tratados até alcançar execução no appliance. Em vez de depender de credenciais válidas, o problema foi descrito como explorável por requisições HTTP especialmente manipuladas.
O primeiro fluxo envolve a recuperação de aplicativos móveis a partir de uma loja de aplicações aprovada pelo EPMM. O script map-appstore-url era acionado com parâmetros relacionados ao arquivo de aplicativo solicitado. Quando a entrada enviada pela requisição era processada de maneira insegura, o caminho permitia injeção de código e, em caso de exploração bem-sucedida, execução arbitrária no appliance. O material recebido inclui um exemplo de endpoint e de entrada, mas a sequência operacional não é necessária para defesa e não deve ser reproduzida em ambientes fora de testes autorizados.
O impacto técnico confirmado é execução de código no servidor EPMM. A partir desse ponto, o risco passa a depender da exposição do appliance, das integrações configuradas e do tempo de permanência do atacante. Com base em ataques anteriores contra vulnerabilidades antigas no mesmo produto, a Ivanti citou dois padrões de persistência que já foram observados em appliances comprometidos: implantação de web shells e uso de reverse shells. Esse histórico não prova automaticamente o mesmo comportamento em todos os casos atuais, mas define uma linha objetiva para investigação de resposta a incidente.
Os ramos afetados cobrem versões EPMM 12[.]5[.]0[.]0 e anteriores, 12[.]6[.]0[.]0 e anteriores e 12[.]7[.]0[.]0 e anteriores, com correção no pacote RPM correspondente ao ramo 12.x.0.x. O material também lista EPMM 12[.]5[.]1[.]0 e anteriores e 12[.]6[.]1[.]0 e anteriores, com correção no RPM do ramo 12.x.1.x. Essa distinção importa porque aplicar um RPM incorreto ou perder a correção durante upgrade cria uma falsa sensação de remediação.
O appliance EPMM ocupa uma posição sensível porque centraliza gestão de dispositivos móveis e pode armazenar informações sobre usuários e dispositivos administrados. O material recebido menciona nomes, endereços de e-mail, números de telefone, informações de GPS e outros identificadores sensíveis como dados potencialmente acessíveis a partir de um servidor comprometido. Também há risco condicionado de movimentação lateral para ambientes conectados, especialmente quando o EPMM possui integrações com diretórios, serviços Kerberos, redes internas, configurações de VPN ou distribuição de aplicativos corporativos.
- Instâncias EPMM expostas à internet ou acessíveis por redes não confiáveis devem ser priorizadas na resposta.
- Ambientes com distribuição de aplicativos internos pelo EPMM exigem revisão de configurações enviadas aos dispositivos.
- Configurações de rede e VPN distribuídas para dispositivos móveis devem ser inspecionadas para alterações não autorizadas.
- Contas LDAP, KDC e outras contas de serviço configuradas no EPMM devem entrar no escopo de rotação quando houver suspeita de comprometimento.
A investigação deve começar pelo appliance e pelos sistemas que recebem ou processam suas integrações. Um ponto específico citado é o log de acesso do Apache em /var/log/httpd/https-access_log. A orientação técnica diferencia o uso legítimo das funcionalidades, que tende a produzir respostas HTTP 200, de tentativas ou exploração bem-sucedida associadas a respostas HTTP 404 no fluxo vulnerável. Isso não deve ser usado como único critério de decisão, mas é um sinal inicial útil para buscar padrões anômalos em horários próximos à exposição pública das falhas.
A telemetria de rede também merece atenção. Um ambiente de honeypot registrou centenas de conexões de entrada em 24 horas vindas de mais de 130 endereços IP únicos, com parte relevante tentando explorar as vulnerabilidades. Os payloads observados foram descritos como voltados a controle rápido, incluindo reverse shells pela porta 443, tentativas de implantação de web shell e droppers automatizados. Para defesa, o foco deve ser identificar conexões de saída incomuns do appliance, criação ou modificação inesperada de arquivos em caminhos web, alterações de configuração e atividades de processo incompatíveis com a operação normal do EPMM.
Como a própria Ivanti indicou não possuir indicadores atômicos confiáveis suficientes para atribuir táticas específicas de ator, a caça deve privilegiar comportamento e integridade do sistema. Isso inclui comparar arquivos e configurações do appliance com uma base confiável, revisar mudanças recentes em aplicativos internos distribuídos, validar alterações em perfis de rede ou VPN e correlacionar autenticações de contas de serviço após a possível janela de exploração.
- Respostas HTTP 404 associadas aos fluxos vulneráveis no log
/var/log/httpd/https-access_log. - Conexões de saída incomuns do appliance, especialmente tráfego interativo ou persistente pela porta 443.
- Arquivos web novos, alterados ou com timestamps incompatíveis com manutenção autorizada.
- Mudanças não planejadas em aplicativos internos, configurações de rede e perfis VPN enviados a dispositivos.
- Uso anômalo de contas LDAP, KDC ou outras contas de serviço vinculadas à solução EPMM.
A primeira ação é aplicar o pacote RPM apropriado ao ramo instalado e registrar evidência de que a correção permanece presente após qualquer upgrade. Como o pacote não sobrevive automaticamente a atualização de versão, operações de manutenção precisam incluir uma etapa explícita de reaplicação e validação. Em paralelo, a exposição externa do appliance deve ser revisada para reduzir superfície de ataque enquanto a investigação confirma se houve tentativa ou exploração bem-sucedida.
Quando houver sinais de comprometimento, a recomendação técnica é não confiar apenas em limpeza pontual. O caminho indicado é restaurar o EPMM a partir de um backup reconhecidamente íntegro ou construir um appliance substituto e migrar os dados para ele. Essa abordagem reduz o risco de persistência residual por web shell, reverse shell ou alteração de configuração que sobreviva a uma correção aplicada sobre um sistema já controlado. Após reconstrução ou restauração, as equipes devem rotacionar credenciais de contas de serviço LDAP e KDC usadas para consultas, além de outras contas internas ou externas configuradas na solução.
A contenção também precisa alcançar os efeitos administrativos do EPMM. Configurações de aplicativos enviados aos dispositivos, aplicativos internos, perfis de rede e configurações de VPN devem ser revisados contra mudanças não autorizadas. A validação final deve combinar versão corrigida, ausência de artefatos suspeitos, revisão de logs, rotação de segredos operacionais e confirmação de que os dispositivos gerenciados não receberam configurações indevidas durante a janela de risco.
- Aplicar o RPM correto para o ramo EPMM em uso e validar novamente após qualquer upgrade.
- Tratar instâncias expostas e vulneráveis como potencialmente comprometidas até conclusão da investigação.
- Restaurar de backup íntegro ou reconstruir o appliance quando houver evidência de comprometimento.
- Rotacionar senhas de contas LDAP, KDC e demais contas de serviço configuradas no EPMM.
- Revisar aplicativos internos, perfis de rede e configurações VPN distribuídos pelo appliance.
0 Comentários