Falha crítica no Ivanti Sentry com CVSS 10 expõe infraestrutura corporativa a ataque remoto
Uma vulnerabilidade crítica no Ivanti Sentry está permitindo que atacantes remotos, sem qualquer autenticação, executem comandos arbitrários com privilégios de root em servidores expostos. Catalogada como CVE-2026-10520 e classificada com pontuação CVSS 10.0, a falha atinge versões anteriores às releases R10.5.2, R10.6.2 e R10.7.1 da solução – antes conhecida como MobileIron Sentry.
O Ivanti Sentry atua como um gateway entre dispositivos móveis e sistemas internos da organização, realizando criptografia, controle de acesso e inspeção de tráfego. Por estar posicionado na borda da rede e controlar o acesso a aplicações sensíveis, sua exploração oferece um ponto de entrada privilegiado para movimentação lateral e ataques mais profundos contra o ambiente corporativo.
Duas falhas graves: execução de código e criação de contas admin
Pesquisadores da watchTowr Labs descreveram duas vulnerabilidades distintas:
– CVE-2026-10520 – injeção de comandos que possibilita execução remota de código (RCE) como root, sem autenticação.
– CVE-2026-10523 – falha lógica que permite a criação de contas administrativas arbitrárias, concedendo controle administrativo total sobre o sistema a um invasor remoto não autenticado.
A segunda falha, portanto, não apenas complementa a primeira, como também abre espaço para um takeover completo do dispositivo, facilitando persistência, alteração de configurações de segurança e uso do Sentry como plataforma de ataque contra outros ativos. A descoberta é creditada ao pesquisador Bryan Lam.
Onde está o problema: endpoint vulnerável no Sentry
O ponto central da falha CVE-2026-10520 é o endpoint:
`/mics/api/v2/sentry/mics-config/handleMessage`
Esse endpoint aceita um parâmetro `message` fornecido pelo usuário. Em vez de validar e sanitizar adequadamente essa entrada, o sistema repassa o valor diretamente a um método responsável por processar comandos de configuração internos.
Durante esse processamento, o conteúdo de `message` é analisado e dividido em tokens que são mapeados para variáveis internas como `xpath`, `module` e `command`. Quando o token `command` recebe o valor `”execute”`, o fluxo de execução alcança o método `executeNativeCommand()`.
É justamente nesse ponto que ocorre o problema: o método `executeNativeCommand()` usa reflexão para invocar comandos do sistema operacional, permitindo que o atacante injete e execute comandos arbitrários no servidor, com privilégios elevados.
Demonstração prática do exploit
Os pesquisadores demonstraram que basta uma requisição HTTP POST bem estruturada para explorar a falha. No exemplo apresentado, o payload incluía o comando:
`uname -a`
A resposta do servidor retornou a saída completa desse comando, evidenciando que o sistema estava executando instruções fornecidas pelo atacante. A partir desse ponto, qualquer comando de sistema poderia ser testado: desde coleta de informações até instalação de backdoors, download de ferramentas maliciosas ou pivotamento para outros ativos internos.
Por se tratar de execução como root, as limitações são mínimas: o invasor pode manipular arquivos críticos, ajustar configurações de rede, desabilitar logs ou implantar malwares sofisticados, como ransomware e ferramentas de comando e controle.
Correções aplicadas pela Ivanti
A Ivanti, que adquiriu a MobileIron e a Pulse Secure em 2020 como parte de sua estratégia de fortalecer o portfólio em zero trust, nuvem e segurança de TI, liberou atualizações para mitigar os problemas. As versões corrigidas são:
– Ivanti Sentry R10.5.2 ou posterior
– Ivanti Sentry R10.6.2 ou posterior
– Ivanti Sentry R10.7.1 ou posterior
Para tratar a CVE-2026-10520, a empresa adotou uma abordagem em duas frentes:
1. Substituição do comando controlável pelo usuário
O campo antes controlado via `message` foi trocado por um comando fixo, responsável por executar `/bin/cat` em um caminho específico do sistema (relacionado ao produto DMI). Com isso, a aplicação deixa de depender de parâmetros arbitrários para acionar comandos nativos do sistema operacional.
2. Bloqueio de acesso ao endpoint via configuração do Apache
Foram introduzidas regras baseadas em expressões regulares (regex) no servidor Apache que atende o Sentry. Essas regras bloqueiam completamente o acesso ao endpoint vulnerável, redirecionando requisições não autenticadas para a página de login. Essa camada extra dificulta o uso direto do endpoint para exploração remota.
Já a falha CVE-2026-10523, que possibilita a criação de contas administrativas, foi corrigida com ajustes de lógica de autenticação e autorização, de modo a impedir que endpoints administrativos sejam acionados sem credenciais válidas e verificações adequadas de permissão.
Impacto prático para empresas
Comprometer o Ivanti Sentry significa, na prática, colocar nas mãos do invasor:
– Um ponto de controle de tráfego entre dispositivos móveis e sistemas internos;
– A capacidade de interceptar, redirecionar ou manipular comunicações;
– Um ponto de apoio para ataques de movimento lateral dentro da rede;
– A possibilidade de desabilitar ou contornar políticas de segurança aplicadas via Sentry.
Uma vez com acesso administrativo ou com RCE como root, o atacante pode:
– Criar novas contas com privilégios elevados e manter persistência;
– Alterar regras de acesso, listas de permissão e políticas de segurança;
– Usar o gateway como proxy para ataques contra servidores internos, bancos de dados e aplicações críticas;
– Apagar logs e rastros de sua atividade, dificultando a detecção e resposta a incidentes.
Em ambientes que dependem do Sentry para controlar o acesso de dispositivos móveis a dados sensíveis, a exploração dessas falhas pode significar vazamento massivo de informações, comprometimento de credenciais corporativas e interrupção de serviços essenciais.
Recomendações imediatas para equipes de segurança
Diante da gravidade da vulnerabilidade (CVSS 10.0) e do fato de não exigir autenticação, as ações devem ser prioritárias:
1. Atualizar imediatamente para as versões corrigidas: R10.5.2, R10.6.2 ou R10.7.1, conforme a linha em uso na organização.
2. Verificar exposição externa do Ivanti Sentry, identificando se o painel ou APIs estão acessíveis diretamente pela internet. Caso estejam, considerar:
– Restringir o acesso por VPN;
– Implementar filtragem por IP;
– Colocar o Sentry atrás de um WAF com regras específicas.
3. Revisar logs de acesso e eventos, especialmente requisições para o endpoint `/mics/api/v2/sentry/mics-config/handleMessage`, em busca de:
– Padrões incomuns de POST;
– Parâmetros suspeitos no campo `message`;
– Tentativas de execução de comandos, como `uname`, `id`, `cat`, `curl`, `wget`, entre outros.
4. Auditar contas administrativas no Sentry, verificando se não há usuários criados sem justificativa clara ou fora dos processos formais de gestão de identidade.
5. Implementar monitoração contínua, com alertas específicos para atividades anômalas no Sentry e na infraestrutura associada.
A watchTowr também divulgou um “Detection Artefact Generator” para auxiliar organizações a verificarem se seus ambientes permanecem vulneráveis ou já foram potencialmente explorados, reforçando a necessidade de validação ativa, e não apenas de atualização.
Como avaliar se sua organização foi comprometida
Além da simples instalação do patch, é importante adotar uma postura forense mínima para entender se houve exploração prévia:
– Analise o histórico de logs do Sentry, do servidor web (Apache) e do sistema operacional, cobrindo uma janela de tempo anterior à divulgação pública da falha.
– Busque por comandos suspeitos executados pelo usuário de serviço do Sentry ou pelo root. Sequências como `curl`, `wget`, scripts em `bash` baixados remotamente, tentativas de instalar pacotes ou abrir conexões saindo do Sentry para hosts internos são sinais de alerta.
– Verifique mudanças de configuração recentes no Sentry e nas integrações com MDM, AD/LDAP e outros diretórios. Ajustes não documentados, novos perfis de acesso ou alterações em políticas podem indicar interferência maliciosa.
– Considere uma varredura completa de integridade nos servidores adjacentes ao Sentry, caso haja qualquer indício de uso do gateway como ponto de pivotamento.
Se houver confirmação ou forte suspeita de comprometimento, deve-se acionar o plano de resposta a incidentes, que inclua isolamento do equipamento, reset de credenciais, revalidação de integrações e notificação às partes interessadas internas.
Boas práticas para reduzir o risco em gateways de acesso
O caso do Ivanti Sentry reforça algumas lições fundamentais para a proteção de gateways que ficam na borda da rede:
– Menor exposição possível: evitar que painéis administrativos e APIs sensíveis fiquem diretamente acessíveis pela internet, sempre que houver alternativa (VPN, segmentação, WAF).
– Princípio do menor privilégio: garantir que o serviço não execute com privilégios desnecessários, reduzindo o impacto de uma eventual exploração.
– Validação rigorosa de entrada: endpoints que recebem dados do usuário precisam de sanitização forte, whitelists e validação de tipos, evitando interpretações como comandos.
– Atualizações regulares e rápidas: gateways críticos não podem ficar longos períodos sem patch; é importante ter processos ágeis de teste e implantação de correções.
– Monitoramento proativo: métricas de comportamento, detecção de anomalias e correlação de eventos ajudam a identificar padrões de exploração mesmo antes de um exploit público ser massivamente utilizado.
O que CISOs e gestores de risco devem considerar
Para gestores de segurança e risco, a CVE-2026-10520 não é apenas um problema técnico, mas um ponto de atenção estratégico. Alguns pontos a serem avaliados:
– Dependência do Sentry para acesso móvel: quanto do negócio depende da disponibilidade e integridade desse gateway?
– Posição do Sentry na arquitetura: ele tem rota direta para sistemas críticos, bancos de dados sensíveis ou diretórios de identidade?
– Maturidade do plano de resposta a incidentes: há procedimentos claros para tratar falhas críticas em componentes de borda? O tempo de reação é compatível com o risco?
– Exposição regulatória: em setores regulados, um vazamento de dados decorrente da exploração dessa falha pode desencadear sanções, notificações a autoridades e danos reputacionais significativos.
Essa análise deve alimentar uma revisão mais ampla da estratégia de segurança de acesso, contemplando não só o patch imediato, mas também possíveis redesenhos de arquitetura para aumentar a resiliência contra falhas futuras em soluções similares.
Caminho adiante
A descoberta e divulgação das vulnerabilidades no Ivanti Sentry evidenciam, mais uma vez, o quão atrativos são os dispositivos de borda para atacantes: eles concentram tráfego, credenciais e acesso a sistemas de alto valor. Com uma única falha, é possível abrir a porta de entrada para toda a organização.
Organizações que utilizam o Ivanti Sentry devem tratar a CVE-2026-10520 e a CVE-2026-10523 como prioridade máxima: aplicar as atualizações, revisar exposição, auditar atividades recentes e fortalecer a postura de segurança ao redor desse tipo de solução.
Mais do que corrigir um bug específico, o episódio é um lembrete da importância de enxergar gateways e soluções de acesso como componentes centrais da estratégia de segurança, que exigem atenção contínua, monitoramento dedicado e processos ágeis de resposta a vulnerabilidades críticas.