Vulnerabilidades críticas e exploração ativa, Julho 2026

Incidentes relevantes

Redis e o pacote de vulnerabilidades com PoC pública

Redis foi o caso técnico mais persistente de julho. O conjunto reúne várias peças que, juntas, desenham um cenário de risco transversal para Redis OSS, Redis Software, Redis Cloud e módulos como RedisTimeSeries e RedisBloom. O alerta do CGII da Bolívia foi especialmente relevante para a região porque elevou o problema a uma advertência local, classificou a gravidade como alta e indicou que a exploração pode permitir corrupção de memória e execução remota de código em cenários em que o atacante tenha uma conta autenticada e permissões específicas, sobretudo para usar RESTORE ou para operar em contextos de replicação mestre-réplica.

O grupo de CVEs citado no material, CVE-2026-25243, CVE-2026-25588, CVE-2026-25589, CVE-2026-23479 e CVE-2026-23631, não é homogêneo. Algumas falhas se associam a desserialização insegura, outras a use after free e outras a corrupção de memória em módulos específicos. Isso torna a remediação mais difícil, porque não basta identificar uma única versão vulnerável. É preciso revisar a branch principal, os módulos, as políticas de replicação e a exposição de comandos administrativos. O alerta boliviano inclusive destaca versões específicas de RedisTimeSeries e RedisBloom, ampliando o alcance além do core do produto.

A outra leitura importante é a da exploração prática. SecurityLab informou que cadeias de exploits de demonstração conseguiram execução remota mesmo em versões já corrigidas como 6.2.22, 7.4.9 e 8.6.4. The Hacker News e Engenharia Telemática também apontaram a circulação de PoC autenticadas, enquanto a Redis respondeu com sete lançamentos adicionais de segurança em um único dia, 23 de julho. Essa sequência sugere que o processo inicial de correção não fechou toda a superfície de ataque. Para um CISO, isso significa que aplicar um patch de emergência não é o fim do trabalho, mas o início de uma verificação mais ampla de cobertura e exposição.

Do ponto de vista operacional, Redis merece uma leitura em duas camadas. Primeiro, pelo uso frequente em caches, filas, sessões e dados temporários, o que o transforma em um componente com alta exposição horizontal. Segundo, porque o material mostra que o abuso exige autenticação em vários cenários, o que muda o perfil do controle. Não estamos diante de uma falha de simples varredura indiscriminada na internet em todos os casos, mas de uma vulnerabilidade que pode passar despercebida se houver qualquer vetor prévio de acesso ou credenciais reutilizadas. Isso eleva a importância de revisar contas de serviço, segmentação e permissões de comandos.

SharePoint e a pressão sobre a colaboração interna

SharePoint voltou ao centro da conversa regional a partir do alerta 65/2026 do CTIR Gov do Brasil. O aviso identifica versões vulneráveis no SharePoint Server 2016, 2019 e Subscription Edition, e acrescenta que a falha pode afetar confidencialidade, integridade e disponibilidade. Também inclui um EPSS de 5,06% e um percentil 91,41%, além da referência ao catálogo KEV da CISA. Essa combinação de atributos é relevante porque mostra que o problema não foi apresentado como uma simples vulnerabilidade de laboratório, mas como um caso com probabilidade de abuso suficiente para justificar remediação imediata.

Outras fontes do mesmo período acrescentam profundidade técnica. Foi mencionada a possibilidade de roubo de machine keys, persistência e execução remota sem autenticação. Também se citou o surgimento de um proof-of-concept público como fator que acelera a exploração. Tudo isso coloca o SharePoint em uma zona delicada: não é apenas uma aplicação de produtividade, mas um componente que costuma armazenar conteúdo sensível, integrar autenticação e funcionar como interface entre usuários, processos e repositórios internos. Quando surge uma vulnerabilidade crítica nesse ponto, o dano potencial vai além do alcance de um único servidor.

A implicação regional é forte porque o SharePoint está presente em governos, educação, serviços financeiros e grandes corporações latino-americanas. O alerta brasileiro, além disso, veio acompanhado de recomendações concretas para inventariar versões e aplicar as correções do desenvolvedor. Não há espaço para uma defesa meramente perimetral. Se o sistema é usado como portal de colaboração, a prioridade deve incluir revisão de contas, verificação de indícios de persistência e busca de anomalias em registros, já que a exploração descrita permite um acesso que pode sobreviver ao patch se a resposta ficar limitada à atualização de binários.

OpenSSH, Ivanti e o perímetro que continua sendo ponto de entrada

O Chile trouxe várias sinais de alto valor operacional. O CSIRT publicou um alerta sobre a vulnerabilidade crítica CVE-2024-6387 em OpenSSH, conhecida como regressh, e indicou que há exploração ativa confirmada. Também divulgou um alerta sobre Ivanti com múltiplos CVEs, entre eles CVE-2023-46805 e CVE-2024-21887, que segundo a própria notificação foram usados de forma encadeada para comprometer dispositivos Ivanti Connect Secure. Essa combinação de mensagens é relevante porque marca duas realidades distintas, mas conectadas: acesso remoto exposto e dispositivos de segurança convertidos em vetores de intrusão.

O fato de a Ivanti ser tratada como alvo de exploração ativa em campanhas dirigidas contra dispositivos de segurança reforça uma tendência persistente na região, em que equipamentos instalados para proteger acabam fazendo parte da superfície de ataque. Não é um detalhe menor. Se um VPN ou um gateway de acesso for comprometido, o atacante já não precisa necessariamente buscar outra via de entrada. Em vez disso, pode ampliar o alcance, obter credenciais ou se mover lateralmente a partir de um ponto que as organizações costumam considerar confiável.

O CERT.br complementou essa leitura a partir do Brasil, ao alertar que CVE-2024-24919 em dispositivos Check Point VPN estava sendo usado para ler informações sensíveis da memória de gateways afetados. O aviso também destacou relatos de comprometimento em organizações brasileiras e a necessidade de aplicar imediatamente os patches do fabricante. Quando várias autoridades regionais coincidem em que a exploração está ocorrendo e que o vetor atinge a infraestrutura de acesso, a prioridade deixa de ser teórica. Vira questão de continuidade operacional e de gestão de exposição.

Balbooa Forms e o risco silencioso das extensões web

Balbooa Forms para Joomla concentrou uma quantidade incomum de cobertura técnica para uma extensão de terceiros. O registro oficial de CVE-2026-56291 informa que todas as versões anteriores a 2.4.1 eram vulneráveis a um upload arbitrário de arquivos sem autenticação que permitia carregar executáveis e obter RCE completa. O material técnico acrescenta detalhes mais incômodos, como a ausência de token CSRF, a falta de uma lista de extensões permitidas e a confiança no nome de arquivo informado pelo usuário. Em outras palavras, a falha não foi sutil. Foi uma combinação de controles ausentes em um ponto de entrada muito exposto.

O problema aumenta porque várias fontes coincidem em que houve exploração ativa. CTI Pilot e SentinelOne descreveram o caso como um zero-day já explorado, enquanto a Devel Group informou que a CISA o incluiu no catálogo KEV e recomendou isolamento, aplicação imediata do patch e caça a ameaças em logs HTTP POST para rotas de extensões Joomla. A TechConsulting acrescentou uma leitura técnica útil ao resumir que o handler de upload do frontend aceitava arquivos sem autenticação e permitia enviar .php para um diretório público. A contrapartida defensiva é clara: qualquer site que tenha executado a extensão vulnerável deve ser tratado como potencialmente comprometido até que se prove o contrário.

A dimensão regional do achado não depende de uma vítima específica. Depende da presença massiva do Joomla em portais, intranets e sites de atendimento ao cidadão na América Latina, onde extensões de terceiros costumam ser instaladas para resolver necessidades de negócio com rapidez. O risco não está só no CMS, mas na longa cauda de componentes adicionais que nem sempre passam pelo mesmo controle de desenvolvimento seguro que o núcleo. O mês mostrou que esse descuido pode terminar em web shells, persistência e comprometimento total do servidor em questão de segundos.

JCE no Brasil e o arquivo que confirma a exploração ativa

O caso do Joomla Content Editor, identificado como CVE-2026-48907, aparece no arquivo com uma particularidade editorial: uma fonte do governo brasileiro o confirmou como alerta sobre exploração ativa, mas a data associada ficou sem confirmação em um dos registros arquivados. Ainda assim, o restante do material do período situa o problema com clareza. A SonicWall o descreve como RCE remota sem autenticação, a IntelSecLab publicou PoC do vetor via profiles.import, e a dbugs, vinculada à Positive Technologies, o apresentou como uma falha de controle de acesso inadequado que permitia a usuários não autenticados criar perfis de editor e executar PHP arbitrário.

O interessante aqui é a convergência entre a técnica e a resposta institucional. Não se trata apenas de uma vulnerabilidade teórica, mas de uma falha que já havia motivado alerta público e atividade de pesquisa prática. Para as equipes de segurança, isso implica revisar não apenas a versão do componente, mas a existência de perfis criados de forma anômala, arquivos PHP estranhos e qualquer vestígio de abuso em rotas de importação. Quando o ponto vulnerável é um editor de conteúdo, o comprometimento pode passar despercebido por um tempo se o monitoramento ficar restrito ao núcleo do CMS.

Ameaças e campanhas ativas

Ransomware e extorsão

O arquivo do mês reúne quatro casos em que ransomware ou extorsão aparecem como eixo principal, mas só um permite identificar com clareza ciframento de ativos confirmado. Nos outros três, o material não esclarece se houve ciframento, exfiltração sem ciframento ou apenas reivindicação em um leak site. Essa diferença não é menor. Para uma equipe de resposta, muda a prioridade de contenção, o tipo de negociação jurídica e a urgência de recuperação a partir de backups.

Uma leitura prudente exige não forçar homogeneidade onde ela não existe. Quando a fonte não confirma ciframento, o relatório deve dizer isso. A ausência de precisão documental não reduz o risco, mas impede transformar uma menção genérica em um incidente operacional verificado. No mês analisado, o valor do material esteve menos na narrativa de extorsão e mais nos vetores de acesso inicial que, na prática, costumam alimentar depois esse tipo de campanha.

Fraude e phishing

O material do período documenta dois casos de fraude ou phishing. Não há detalhe suficiente para construir uma campanha unificada nem para atribuir uma metodologia comum, então o registro precisa se manter nesse nível. Ainda assim, o sinal é útil porque convive com o restante da superfície de risco e sugere que o abuso de credenciais, a falsificação de identidade ou a engenharia social seguiram operando como camada complementar de acesso ou monetização.

Em um mês tão carregado de vulnerabilidades críticas, o phishing não desaparece. Ele se torna, antes, o lubrificante de outros ataques, especialmente quando uma credencial roubada, uma conta comprometida ou uma interação enganosa permite burlar controles que a vulnerabilidade isolada não conseguiria vencer. Por isso, embora o material não detalhe uma campanha maior, o dado deve ser lido como um lembrete de que a exposição técnica e a exposição humana se retroalimentam.

APT e hacktivismo

Não há material suficiente neste arquivo para construir uma atribuição sólida de APT ou de hacktivismo como eixos predominantes do mês. Há, sim, padrões compatíveis com atores que buscam acesso persistente ou movimento lateral a partir de software de perímetro e plataformas de colaboração. A menção à exploração ativa em VPNs, SharePoint e OpenSSH se encaixa em táticas de acesso inicial de alto valor, mas o material não permite atribuição a grupos específicos nesta seção.

Vulnerabilidades críticas

A tabela reflete 48 CVEs críticos mencionados no material, mas nem todos aparecem detalhados aqui porque o arquivo reúne referências repetidas e agrupadas por advisory. O ponto central para a leitura regional é que vários dos CVEs com maior valor operacional se concentraram em componentes de acesso remoto, colaboração e extensões web. Isso coincide com um padrão defensivo conhecido: os atacantes preferem as peças que resolvem autenticação, visibilidade ou publicação externa, porque uma única falha nessas camadas oferece retornos muito maiores do que um vetor isolado em um endpoint interno.

Regulação e conformidade

Não foram registrados movimentos regulatórios documentados no material do mês. Isso não significa ausência de atividade de conformidade em andamento, mas que não houve fatos verificáveis no arquivo que permitam descrever novos marcos normativos, sanções ou obrigações regulatórias específicas para julho de 2026.

Mesmo sem mudanças regulatórias formais, há implicações operacionais de conformidade. Os alertas do CTIR Gov no Brasil, do CERT.br e do CSIRT Chile funcionam como sinais de urgência para órgãos públicos e empresas privadas que administram infraestrutura crítica ou serviços essenciais. Na prática, esses comunicados costumam se traduzir em exigências internas de revisão, inventário, comprovação de aplicação de patches e, em alguns casos, notificação a terceiros ou contratados. O foco não é normativo em sentido estrito, e sim de governança de risco.

Países mais afetados na América Latina

Brasil

O Brasil foi o país com maior densidade de fatos verificáveis no período. O CTIR Gov publicou o alerta 65/2026 sobre Microsoft SharePoint, incluindo versões afetadas, EPSS e referência a KEV. O CERT.br emitiu um alerta sobre exploração ativa em VPNs empresariais, com foco em CVE-2024-24919 e comprometimento real em organizações brasileiras. Além disso, a imprensa local reportou incidentes associados à Check Point e foi registrada a alerta de Ivanti pelo CSIRT do Chile, que também tem relevância para ambientes com operação regional compartilhada a partir do Brasil.

O caso brasileiro mostra uma combinação muito típica do risco latino-americano, muita dependência de suítes corporativas e dispositivos de borda, somada a uma camada de urgência institucional que chega justamente quando o patch já circula no ecossistema global. A qualidade do material oficial é alta e permite inferir uma pressão defensiva importante sobre empresas de serviços, infraestrutura crítica e órgãos públicos. A leitura prática é que o Brasil concentrou tanto a produção de alertas quanto a amplificação midiática regional.

Chile

O Chile aparece como segundo polo documental do mês pela atuação do seu CSIRT. O órgão publicou um alerta sobre OpenSSH com exploração ativa confirmada, outro sobre vulnerabilidades em Ivanti e uma referência a dispositivos de borda explorados ativamente. A presença do Chile no arquivo é valiosa porque mostra uma autoridade nacional tratando vulnerabilidades de acesso remoto e perímetro com uma visão operacional, não apenas informativa.

O sinal chileno é claro, priorização da exposição externa, revisão de dispositivos de acesso e correções imediatas. Isso sugere um ambiente em que falhas de perímetro seguem sendo uma preocupação real para organizações com operação distribuída, fornecedores conectados e usuários remotos. A ausência de outras menções não deve ser interpretada como risco menor, e sim como menor densidade de fatos verificáveis no material arquivado.

Bolívia

A Bolívia traz um dos avisos técnicos mais detalhados do mês por meio do CGII. O órgão emitiu um alerta sobre um lote de vulnerabilidades em Redis, com classificação de gravidade alta, versões afetadas e explicação técnica dos mecanismos de exploração. Além de ser um aviso local, o documento tem valor regional porque traduz um problema global em uma recomendação concreta para administradores da região.

A contribuição boliviana mostra que os alertas nacionais podem ser tão úteis quanto os advisories do vendor, sobretudo quando especificam módulos, versões e medidas de mitigação. Em ambientes onde Redis é usado como serviço interno de alto desempenho, o risco não está só na exposição pública, mas também na persistência de configurações de replicação ou permissões excessivamente amplas. A Bolívia foi, nesse sentido, um bom exemplo de tradução operacional do risco.

Colômbia

A Colômbia não registrou incidentes com impacto confirmado no eixo deste relatório, mas contribuiu com telemetria agregada por meio do ColCERT. O alerta sobre a rede CHARLIE/ORB3/SPACEHOP reportou pelo menos 16 nós confirmados realizando varreduras e força bruta massiva contra SSH, PostgreSQL e Apache Tomcat. Esse dado não entra na contagem de incidentes, mas ajuda a lembrar que as organizações colombianas operam em um ambiente com pressão automatizada constante.

A leitura da Colômbia em julho é, portanto, a de uma superfície exposta a ruído massivo mais do que a um caso singular. O valor editorial do dado é contextual e não deve ser confundido com impacto confirmado. Ainda assim, a presença de varreduras dessa escala indica que os controles de acesso e a exposição de serviços seguem sendo uma prioridade básica de higiene.

México

Não houve fatos verificáveis no material do mês que permitam atribuir ao México um incidente ou alerta concreto dentro deste eixo. Isso não reduz o risco do país, mas limita a afirmação documental. O arquivo não inclui um alerta mexicano equivalente aos do Brasil, Chile ou Bolívia para julho de 2026.

Argentina

Não foram registrados fatos verificáveis do período para a Argentina neste eixo. A ausência de material não deve ser interpretada como ausência de exposição, e sim como falta de casos documentados dentro do arquivo disponível.

Peru

Não foram registrados fatos verificáveis do período para o Peru neste eixo. O material analisado não traz um alerta ou incidente concreto com data de julho de 2026.

Paraguai

Não foram registrados fatos verificáveis do período para o Paraguai neste eixo. Também não há no arquivo um aviso comparável que permita construir uma leitura específica do país.

Estados Unidos

Embora este relatório priorize a América Latina, vários fatos do período enquadram a exposição regional porque envolvem vendors globais e catálogos de exploração conhecidos. Em particular, a CISA adicionou SharePoint ao KEV e também aparece a referência ao caso de Balbooa Forms. Não são incidentes latino-americanos por si só, mas determinam a velocidade com que as equipes da região precisam responder.

Tendências e sinais a monitorar

Não há baseline comparativo do mês anterior neste formato arquivado para a América Latina, então não cabe inventar variações percentuais nem uma tendência mês a mês quantificada. Ainda assim, julho consolidou uma linha clara de pressão em três frentes: exposição de perímetro, colaboração interna e extensões web. Redis, SharePoint, VPNs, OpenSSH, Ivanti, JCE e Balbooa Forms formam uma cadeia de software que mistura acesso, autenticação, publicação e administração. Esse conjunto tem alto valor para intrusos porque permite saltar de uma falha externa para persistência ou movimento lateral com custo relativamente baixo.

Um segundo sinal a monitorar é a aceleração entre PoC e mitigação efetiva. O material mostra casos em que já havia exploração pública, catálogos KEV, avisos de CERTs regionais e múltiplas rodadas de patches do fabricante. Quando isso acontece, a pergunta não é se a vulnerabilidade é grave, mas se a organização conseguiu fechar a brecha antes de ela ser explorada no seu ambiente. Essa mudança de pergunta, de criticidade abstrata para velocidade de remediação, é provavelmente a tendência mais importante do mês.

O terceiro sinal é a persistência de vulnerabilidades em produtos que costumam ser administrados por equipes diferentes. Redis pode ficar com plataformas de dados; SharePoint com times de workplace ou colaboração; VPNs e gateways com infra ou segurança; Joomla com web ou marketing; Ivanti com operações ou segurança. O risco aparece quando ninguém tem a foto completa. Julho deixou a impressão de que a fragmentação de responsabilidades segue sendo uma fraqueza regional mais séria do que a falta de patches em si.

Recomendações para equipes de segurança

Primeiro, montar ou atualizar um inventário de exposição que não se limite ao software central. Neste mês ficou claro que módulos do Redis, extensões do Joomla e complementos como o Balbooa Forms podem ter impacto tão alto quanto uma vulnerabilidade no produto principal. O inventário deve incluir branches, plugins, módulos, versões menores e pontos de administração expostos.

Segundo, priorizar a validação de patches com verificação real, não apenas com tickets encerrados. Vários casos do mês mostram que uma correção inicial não necessariamente fechou toda a superfície de ataque. Vale revisar versões, comportamento do endpoint e evidências de exploração, especialmente em Redis, SharePoint, VPNs e Joomla. Se o fabricante publicou várias rodadas de segurança em poucos dias, é preciso assumir que a primeira remediação pode ter sido incompleta ou insuficiente para a instalação local.

Terceiro, revisar com urgência serviços de acesso remoto e dispositivos perimetrais. OpenSSH, Ivanti e Check Point ficaram sob exploração ativa confirmada. Isso obriga a buscar anomalias em autenticações, sessões persistentes, novas contas, regras alteradas e qualquer indício de movimento lateral após a entrada inicial. Em dispositivos de segurança, além disso, a auditoria deve incluir configuração, logs e possibilidade de comprometimento anterior ao patch.

Quarto, tratar SharePoint e outras plataformas de colaboração como ativos de alta sensibilidade. A exposição de machine keys, a possibilidade de persistência e o impacto sobre confidencialidade e integridade exigem mais do que um patch. É necessário revisar credenciais, chaves, serviços associados e vestígios de abuso. Se a plataforma funciona como portal de negócios ou intranet, o dano potencial se amplia para processos inteiros.

Quinto, aplicar hardening específico em aplicações web e extensões de CMS. O caso Balbooa Forms é um exemplo direto de por que formulários, handlers de upload e endpoints de importação precisam estar blindados. Desativar temporariamente componentes críticos, restringir por IP onde for possível, bloquear a execução de PHP em diretórios de upload e revisar logs de HTTP POST são medidas razoáveis quando o intervalo entre divulgação e abuso é curto.

Sexto, assumir comprometimento quando o cenário justificar. Se um site Joomla executou o Balbooa Forms vulnerável, ou se um SharePoint ficou exposto com a CVE de julho, não basta atualizar. É preciso revisar contas, procurar web shells, rotacionar credenciais, validar backups e analisar eventos anteriores à remediação. A lógica de julho não foi a do patch isolado, e sim a da caça à persistência.

Sétimo, coordenar segurança, infraestrutura e donos de aplicação. Este mês deixou evidente que a fragmentação organizacional piora o risco. Redis, SharePoint, VPNs e CMS costumam ter responsáveis distintos, mas o atacante não respeita essas fronteiras. A priorização precisa ser transversal e com prazos curtos.

Limitações do material

Este relatório foi elaborado exclusivamente com o material fornecido para julho de 2026, sem acesso à internet e sem incorporar fontes fora da lista habilitada. O escopo é a América Latina, embora vários fatos de vendors globais ou organismos externos tenham sido usados apenas quando ajudavam a contextualizar riscos que tiveram impacto ou alerta regional.

A janela temporal dos indicadores é a declarada no início: 189 fatos com data em julho de 2026, 14 de meses anteriores como marco comparativo e 1 fato sem data confirmada, excluído dos indicadores. Os fatos de meses anteriores não contam como volume do período e só podem ser citados se o mês for explicitado. O registro sem data confirmada também fica fora das contagens; quando usado como contexto, deve-se dizer que a data não está confirmada.

O indicador de CVEs críticos mencionados não deve ser confundido com ausência de vulnerabilidades na região se alguma seção aparecer em zero em outro período. Neste mês, o material registrou CVEs críticos, mas o princípio metodológico segue o mesmo: um valor em zero significaria apenas que não apareceu no material analisado, não que não tenha existido atividade real na região.

Também não foi somada telemetria agregada aos incidentes. Os registros de ColCERT e Semana são citados apenas como tentativas, bloqueios ou medições de volume, não como intrusões com impacto confirmado. Da mesma forma, os casos de ransomware ou extorsão foram mantidos diferenciados conforme a evidência disponível e, quando a fonte não permitiu determinar se houve criptografia de ativos, isso foi indicado expressamente. Não foram usadas redes sociais nem conteúdo excluído, nem apoiadas tendências em material promocional.

Por fim, algumas peças do arquivo apresentam datas inconsistentes ou registros sem confirmação temporal completa. Nesses casos, priorizou-se não forçar uma cronologia artificial. O objetivo foi preservar a rastreabilidade e evitar que um dado tecnicamente interessante se transformasse, por excesso de interpretação, em uma afirmação que o material não sustentava.