Dois hackers associados ao coletivo de cibercrime Scattered Spider foram condenados a cinco anos e seis meses de prisão cada um pelo ataque cibernético que comprometeu a Transport for London (TfL) em 2024. A invasão afetou serviços internos, expôs dados de passageiros e gerou £29 milhões em prejuízos e despesas de recuperação para a autoridade responsável pelo transporte público de Londres. Thalha Jubair, de 20 anos, morador do leste de Londres, e Owen Flowers, de 18 anos, de Walsall, foram sentenciados no Tribunal da Coroa de Woolwich em 16 de julho de 2026. Os dois haviam se declarado culpados no primeiro dia do julgamento, realizado em junho, por uma infração prevista na Seção 3ZA do Computer Misuse Act de 1990. A acusação se refere a atividades computacionais não autorizadas realizadas entre 31 de agosto e 3 de setembro de 2024, com risco significativo de causar danos graves ao bem-estar da população. Segundo o Crown Prosecution Service (CPS), Jubair e Flowers estão entre os primeiros hackers processados com sucesso sob essa seção da principal legislação britânica contra crimes informáticos. O ataque não chegou a interromper os serviços de metrô, ônibus e trens de Londres, mas obrigou a TfL a desconectar partes de sua própria infraestrutura para impedir que os invasores ampliassem o comprometimento. A recuperação dos sistemas levou aproximadamente seis meses, enquanto mais de 140 plataformas internas ficaram indisponíveis. Os impactos se espalharam por diferentes áreas da organização. Cerca de 28 mil funcionários precisaram comparecer presencialmente a escritórios da TfL para redefinir suas senhas, uma medida adotada para invalidar credenciais potencialmente comprometidas e recuperar o controle das contas corporativas. A indisponibilidade dos sistemas também exigiu a adoção de processos manuais e afetou serviços voltados aos passageiros. Dados armazenados no sistema de reembolso do Oyster, cartão utilizado no transporte londrino, foram acessados pelos invasores. Alguns clientes tiveram de esperar mais tempo para receber valores devidos, enquanto as solicitações de Oyster photocards para crianças e jovens foram temporariamente suspensas. O CPS informou que os hackers conseguiram extrair informações relacionadas a milhões de usuários do Oyster. Conversas recuperadas durante a investigação indicaram que os envolvidos chegaram a discutir a possibilidade de eliminar o acesso aos sistemas, o que poderia ter ampliado significativamente os danos operacionais e econômicos. A TfL administra uma das maiores redes de transporte urbano do mundo e supervisiona, em média, cerca de 9 milhões de viagens por dia. Promotores afirmaram que uma interrupção completa da infraestrutura poderia ter provocado impactos de bilhões de libras na economia britânica, especialmente pela dependência de Londres dos sistemas públicos de mobilidade. A investigação conduzida pela National Crime Agency (NCA) e pela City of London Police encontrou evidências digitais que vinculavam os dois jovens ao ataque. Na residência de Flowers, agentes apreenderam notebooks, computadores, discos rígidos externos e dispositivos USB. Em um dos notebooks, os investigadores localizaram uma captura de tela que mostrava conectividade com a infraestrutura da TfL. O mesmo equipamento armazenava vídeos gravados por Flowers nos quais Jubair aparecia acessando sistemas da organização durante a invasão. De acordo com a acusação, Jubair chegou a transmitir a operação ao vivo enquanto Flowers acompanhava o ataque. Os dois trabalhavam remotamente a partir de suas residências e chegaram a permanecer até 16 horas por dia envolvidos na intrusão. A coordenação ocorria por meio do Telegram e de uma plataforma colaborativa online que permitia que diferentes participantes trabalhassem simultaneamente no mesmo ambiente. Mensagens recuperadas pelas autoridades ajudaram a comprovar a participação dos acusados e a reconstruir as ações realizadas durante o comprometimento. Flowers também admitiu envolvimento em tentativas de ataque contra as organizações de saúde norte-americanas SSM Health Care Corporation e Sutter Health. Segundo os promotores, essas operações foram interrompidas porque ele foi preso enquanto ainda conduzia as invasões. Os responsáveis foram associados ao Scattered Spider, nome utilizado para acompanhar uma comunidade descentralizada de hackers de língua inglesa ligada a ataques contra empresas de tecnologia, telecomunicações, varejo, aviação, seguros e outros setores. Autoridades britânicas, no entanto, observaram que o termo pode representar mais um padrão de comportamento e uma rede informal do que uma organização com estrutura fixa. Os operadores associados ao coletivo são conhecidos por combinar engenharia social, roubo de credenciais, SIM swapping e manipulação de centrais de atendimento para contornar mecanismos de autenticação. Depois do acesso inicial, diferentes integrantes podem avançar para roubo de dados, extorsão ou implantação de ransomware. No caso da TfL, o episódio demonstra como o comprometimento de identidades e sistemas administrativos pode provocar uma crise operacional mesmo quando as plataformas responsáveis diretamente pelo transporte permanecem funcionando. Processos de redefinição de credenciais, investigação forense, reconstrução de servidores e validação de ambientes podem gerar custos elevados e manter serviços indisponíveis durante meses. A NCA afirmou que a colaboração inicial da TfL com as autoridades foi fundamental para reunir evidências e identificar os envolvidos. Paul Foster, chefe da National Cyber Crime Unit, destacou que ataques digitais produzem consequências concretas para empresas, serviços públicos e cidadãos, apesar de muitas vezes serem executados remotamente. A investigação contou com a participação da NCA, da City of London Police, da West Midlands Regional Organised Crime Unit e da British Transport Police, além da cooperação de autoridades internacionais. Na sentença, o juiz Mark Turner afirmou que os dois foram motivados principalmente por uma atitude de exibição e busca de reconhecimento. Apesar da idade dos acusados durante o ataque — Flowers tinha 17 anos e Jubair, 18 —, a Justiça considerou que ambos já possuíam experiência técnica suficiente para compreender o potencial de danos de suas ações. A condenação encerra uma das mais relevantes ações judiciais recentes do Reino Unido contra integrantes de comunidades de cibercrime formadas por jovens hackers. O caso também amplia o debate sobre medidas de prevenção, monitoramento de reincidentes e restrições ao uso de dispositivos e serviços digitais após o cumprimento da pena.

Nova York tornou-se o primeiro estado dos Estados Unidos a estabelecer uma moratória estadual para novos data centers de grande porte, em uma tentativa de avaliar os impactos da rápida expansão da infraestrutura de inteligência artificial sobre a rede elétrica, as tarifas de energia, os recursos hídricos e as comunidades locais. A governadora Kathy Hochul assinou em 14 de julho de 2026 a Ordem Executiva nº 62, que suspende temporariamente a análise de determinadas licenças ambientais estaduais para a construção ou ampliação de data centers capazes de consumir 50 megawatts ou mais. A medida não interrompe automaticamente todos os projetos em andamento. A suspensão se aplica aos pedidos de autorizações, licenças e aprovações discricionárias que ainda não haviam sido considerados completos pelo Departamento de Conservação Ambiental de Nova York, o DEC, antes da publicação da ordem. Autorizações concedidas por governos municipais também não são diretamente abrangidas. Além disso, instalações utilizadas principalmente para manufatura, pesquisa, computação quântica, pesquisa biomédica, educação ou prestação de serviços médicos estão fora da definição adotada pelo governo estadual. O objetivo da pausa é dar tempo para que as autoridades desenvolvam padrões ambientais, energéticos e econômicos específicos para esse tipo de empreendimento. Embora a ordem não estabeleça uma data fixa para o término da suspensão, o processo deverá incluir estudos e relatórios previstos para os próximos 12 meses. “Nova York sempre esteve na vanguarda da inovação e da mudança, mas também sempre garantimos que os nova-iorquinos fossem beneficiados”, declarou Hochul. Segundo a governadora, o avanço dos data centers ameaça elevar as contas de energia, consumir recursos naturais e gerar incertezas para a população. A ordem executiva relaciona diretamente a crescente procura por data centers à expansão de inteligência artificial, computação em nuvem, serviços de streaming e outras operações digitais intensivas em processamento. Segundo o documento, em maio de 2026 havia quase 12 gigawatts, ou 12 mil megawatts, em pedidos de conexão de cargas de data centers na fila do New York Independent System Operator, responsável pela operação da rede elétrica estadual. Mais de 8 gigawatts entraram nessa fila apenas durante 2025. Esses números representam solicitações de conexão e não necessariamente projetos que serão concluídos, mas demonstram a escala da demanda potencial enfrentada pelo sistema elétrico. O governo argumenta que data centers podem exigir investimentos significativos em linhas de transmissão, subestações, sistemas de distribuição e novas fontes de geração. Quando um projeto é reduzido, adiado ou cancelado depois que essas obras são realizadas, os custos podem se transformar em ativos ociosos e acabar repassados aos consumidores. A política declarada pelo estado é que as despesas necessárias para conectar grandes consumidores não devem ser pagas pelos demais usuários da rede elétrica. A moratória abrange instalações ou conjuntos de instalações localizados no mesmo terreno ou em áreas contíguas que possam consumir pelo menos 50 MW. Antes da expansão da IA generativa, uma instalação desse porte já seria considerada um grande campus de computação em nuvem. Atualmente, porém, empresas de tecnologia planejam complexos capazes de consumir centenas de megawatts ou até vários gigawatts. Mesmo assim, 50 MW ainda representam uma capacidade computacional relevante. Dependendo do tipo de acelerador, do consumo dos servidores e da eficiência energética da instalação, esse volume pode alimentar dezenas de milhares de GPUs modernas utilizadas no treinamento ou na execução de modelos de IA. A ordem não distingue formalmente data centers destinados à inteligência artificial de instalações usadas para computação em nuvem, armazenamento, distribuição de conteúdo ou processamento empresarial. O critério principal é a finalidade da estrutura e sua capacidade energética. O Departamento de Serviço Público de Nova York, conhecido como DPS, deverá conduzir um processo formal para produzir uma Declaração Genérica de Impacto Ambiental, ou GEIS. O estudo deverá avaliar os efeitos da construção e da operação dos data centers sobre a demanda energética, o uso e a qualidade da água, a poluição atmosférica, os níveis de ruído e as comunidades consideradas social ou economicamente desfavorecidas. O processo será desenvolvido de acordo com a legislação ambiental estadual e deverá incluir consulta pública e audiência. O DPS trabalhará com o DEC e outras agências para preparar a versão final do documento. Até que o relatório e suas conclusões sejam entregues, o DEC deverá manter suspensas as solicitações estaduais ainda incompletas que se enquadrem nos critérios definidos pela ordem. A preocupação com água ocorre porque grandes instalações utilizam sistemas especializados para remover o calor produzido por servidores e aceleradores. A quantidade consumida varia conforme a tecnologia de refrigeração, o clima, a eficiência do projeto e o uso de água potável, reciclada ou industrial. O governo de Nova York reconheceu que as normas existentes ainda não estão totalmente preparadas para lidar com o volume de captação e tratamento associado a grandes data centers. O estado teme que projetos mal dimensionados pressionem aquíferos, rios, sistemas públicos e regiões sujeitas a períodos de seca. O DEC terá até 12 meses para avaliar se serão necessárias novas regras, políticas, exigências de comunicação ou orientações para controlar o consumo de água por grandes usuários. Outro ponto de atenção é o uso de sistemas locais de geração de energia enquanto os operadores aguardam conexão definitiva ou ampliação da rede elétrica. Data centers dependem de fornecimento contínuo e costumam manter geradores de emergência para enfrentar interrupções. Em alguns projetos, unidades móveis ou temporárias também podem ser utilizadas durante a construção e a fase inicial de operação. Quando esses equipamentos funcionam por longos períodos e utilizam combustíveis fósseis, podem elevar as emissões locais de óxidos de nitrogênio, partículas e outros poluentes. O tema ganhou maior visibilidade nos Estados Unidos com questionamentos sobre a utilização de turbinas e geradores na infraestrutura Colossus, da xAI, empresa de Elon Musk. As controvérsias aumentaram a pressão para que governos avaliem não apenas a energia consumida da rede, mas também a geração instalada dentro dos próprios campi. A ordem também determina que o DPS considere a criação do New York Grid Acceleration Fund, mecanismo destinado a financiar a modernização da rede e impedir que os custos dos projetos sejam transferidos aos consumidores. As operadoras de data centers poderão ser obrigadas a realizar aportes antecipados para financiar melhorias na infraestrutura elétrica. O fundo também poderá apoiar programas de resposta à demanda, contratação de novas fontes de energia limpa, recursos energéticos distribuídos e sistemas de armazenamento em baterias. Outra possibilidade é a criação de um fundo de seguros financiado pelos desenvolvedores. O dinheiro seria usado para proteger os consumidores caso uma obra de infraestrutura seja realizada para atender um projeto que posteriormente seja adiado, reduzido ou cancelado. O DPS deverá estudar níveis de contribuição, critérios de distribuição dos recursos e formas de identificar as melhorias necessárias na rede. O órgão também poderá avaliar exigências para que os data centers financiem novas fontes de geração limpa ou armazenamento dedicados às suas próprias operações, sempre que isso for tecnicamente possível. Em até 60 dias, o DPS deverá formar um grupo de trabalho dedicado à conexão de data centers e outras grandes cargas. A iniciativa deverá reunir concessionárias e demais participantes do setor para revisar os métodos utilizados na análise de novos projetos. O objetivo é estimar de maneira mais precisa os impactos sobre transmissão, distribuição, geração e confiabilidade. A ordem adota o princípio de que o beneficiário deve pagar pelas melhorias necessárias para atendê-lo. Na prática, isso pode levar a contratos, tarifas e garantias financeiras específicas para grandes instalações. O DPS terá ainda 90 dias para apresentar à Comissão de Serviço Público um relatório sobre as práticas das transmissoras e sua capacidade de gerenciar os custos criados pelos novos empreendimentos. A Empire State Development, agência de desenvolvimento econômico do estado, deverá criar em até 60 dias uma estrutura de investimentos comunitários. O documento servirá como orientação para municípios que negociam a instalação de data centers. As contrapartidas poderão incluir investimentos em redes locais de energia, banda larga, sistemas de irrigação, tratamento de águas residuais e outros serviços públicos. Os operadores também poderão contribuir para fundos destinados à redução dos custos de energia, programas educacionais, creches e infraestrutura comunitária. O governo quer ainda incentivar contratação local, programas de aprendizagem, qualificação profissional, acordos trabalhistas e transparência sobre os resultados econômicos dos projetos. A estrutura não estabelece automaticamente uma compensação obrigatória. Ela deverá oferecer referências para que governos locais, agências de desenvolvimento industrial e outras entidades negociem compromissos diretamente com as empresas. A moratória gerou reação de empresas do setor, que argumentam que a suspensão poderá transferir investimentos, empregos e arrecadação para outros estados. A Digital Realty afirmou à Reuters que pretende colaborar com formuladores de políticas para encontrar soluções de crescimento responsável, mas considera que uma pausa de um ano não é a abordagem adequada. A NTT Global Data Centers reconheceu que o setor precisa explicar melhor os efeitos locais dos projetos, incluindo criação de empregos, investimentos econômicos e utilização de recursos naturais. A Assembleia Legislativa de Nova York já havia aprovado uma proposta separada para suspender determinados data centers acima de 20 MW. O projeto possui alcance maior que a ordem executiva, mas ainda precisa passar pelo restante do processo legislativo e pela avaliação da governadora. Hochul também anunciou que pretende propor o encerramento das isenções de imposto sobre vendas concedidas a grandes data centers. A mudança poderá afetar a competitividade de Nova York em relação a estados que utilizam incentivos fiscais para atrair operadores. Outros estados e municípios norte-americanos já discutiram ou adotaram restrições locais para data centers, mas Nova York foi o primeiro a colocar em vigor uma moratória em todo o território estadual. O Maine esteve próximo de adotar uma medida semelhante, porém a governadora Janet Mills vetou, em abril de 2026, o projeto que havia sido aprovado pelo Legislativo estadual. A decisão de Nova York poderá servir de referência para outras regiões que enfrentam aumento da demanda elétrica, atrasos na conexão de novos projetos e pressão popular sobre tarifas, água, ruído e poluição. A suspensão, entretanto, não elimina todas as possibilidades de expansão. Desenvolvedores poderão dividir uma instalação planejada em vários projetos com capacidade inferior a 50 MW, desde que esses empreendimentos não sejam considerados um único conjunto localizado no mesmo terreno ou em áreas contíguas. Além disso, embora o treinamento dos maiores modelos de IA dependa de clusters concentrados com grande capacidade de processamento, a inferência — etapa em que modelos já treinados respondem às solicitações dos usuários — pode ser distribuída entre instalações menores. Tecnologias de rede de alta velocidade e baixa latência também permitem conectar data centers fisicamente separados. Soluções como a plataforma Spectrum-XGS, da Nvidia, foram desenvolvidas para integrar diferentes instalações e fazê-las operar como uma infraestrutura computacional distribuída. Isso significa que o limite energético poderá reduzir a implantação de grandes campi, mas não necessariamente interromper a expansão da capacidade de IA no estado. O resultado dependerá das regras que serão criadas durante a moratória, dos critérios usados para avaliar instalações relacionadas e das condições financeiras impostas aos operadores para conexão à rede, consumo de água e compensação das comunidades.

A F5 corrigiu uma vulnerabilidade crítica no NGINX que permite a invasores remotos e não autenticados provocar um estouro de buffer na memória por meio de requisições HTTP especialmente manipuladas. Dependendo da configuração do servidor e das proteções existentes no sistema operacional, a falha pode causar indisponibilidade do serviço e, potencialmente, permitir a execução remota de código. Identificada como CVE-2026-42533, a vulnerabilidade foi corrigida em 15 de julho nas versões NGINX 1.30.4, do ramo estável, e 1.31.3, do ramo mainline. Para clientes comerciais, a atualização está disponível no NGINX Plus R37 P3, também identificado como 37.0.3.1. O boletim oficial classifica o problema como um buffer overflow relacionado ao uso da diretiva map com expressões regulares. Todas as versões do NGINX entre 0.9.6 e 1.31.2 são consideradas vulneráveis, enquanto as versões 1.30.4 e 1.31.3 ou posteriores não são afetadas. A F5 atribuiu à falha pontuação 9,2 no CVSS v4 e 8,1 no CVSS v3.1. Embora o impacto potencial seja elevado, a complexidade do ataque foi classificada como alta porque a exploração depende de uma combinação específica de diretivas e referências a capturas de expressões regulares na configuração do servidor. A CVE-2026-42533 não afeta automaticamente todos os servidores que executam uma versão vulnerável do NGINX. A exposição depende de como o software foi configurado. O problema ocorre quando uma variável criada por uma diretiva map baseada em expressão regular é usada em uma expressão de texto depois de uma captura numerada, como $1 ou $2, produzida anteriormente por outra expressão regular. A diretiva map permite definir o valor de uma variável a partir de outras informações processadas pelo NGINX, como partes da URL, cabeçalhos HTTP ou endereços enviados pelo cliente. Expressões regulares podem ser utilizadas nesse mecanismo para identificar padrões e capturar trechos específicos da requisição. Em uma configuração vulnerável, o mecanismo interno responsável por montar as strings calcula o tamanho necessário para o resultado em uma primeira etapa e grava os dados no buffer durante uma segunda etapa. As duas operações deveriam utilizar os mesmos valores de captura. Entretanto, a avaliação da expressão regular presente na diretiva map modifica o estado compartilhado dessas capturas entre as duas etapas. Como resultado, a primeira passagem pode reservar memória com base em uma captura menor, enquanto a segunda escreve uma captura diferente e controlada pelo invasor. Quando o conteúdo gravado supera o tamanho calculado, ocorre um heap buffer overflow. Tanto o tamanho quanto o conteúdo excedente podem ser influenciados por dados enviados na requisição HTTP. Isso permite que um atacante remoto acione a falha sem precisar se autenticar no servidor. O resultado mais direto da exploração é o encerramento inesperado do worker process, processo do NGINX responsável por receber conexões e processar requisições. Dependendo da configuração do serviço, o processo principal pode reiniciar automaticamente o worker afetado. Mesmo assim, o envio repetido de requisições maliciosas pode provocar reinicializações contínuas, aumento no consumo de recursos e indisponibilidade de sites, APIs e aplicações publicadas pelo servidor. Em ambientes com alto volume de tráfego, balanceamento de carga ou poucas instâncias disponíveis, a interrupção dos workers pode afetar a continuidade operacional de serviços digitais. A F5 também alerta que a vulnerabilidade pode permitir execução remota de código quando o ASLR estiver desativado ou puder ser contornado. O Address Space Layout Randomization é uma proteção que distribui componentes do processo em endereços de memória imprevisíveis, dificultando a criação de exploits confiáveis. Caso um invasor consiga determinar os endereços necessários e controlar adequadamente a corrupção de memória, o impacto pode deixar de ser apenas uma negação de serviço e avançar para a execução de comandos no servidor com os privilégios do processo NGINX. Stan Shaw, pesquisador que publica sob o nome cyberstan e foi um dos responsáveis pela descoberta independente da vulnerabilidade, apresentou uma análise mais grave do que a descrita no boletim da F5. Segundo Shaw, a mesma inconsistência entre as capturas utilizadas nas duas etapas do processamento também pode fazer o NGINX retornar conteúdo não inicializado da memória heap quando a nova captura é menor do que a usada para calcular o buffer. Esse comportamento poderia resultar em vazamento de endereços de memória e fornecer informações suficientes para contornar o ASLR. O pesquisador afirma que conseguiu reproduzir o cenário em uma instalação padrão do Ubuntu 24.04 usando apenas uma requisição GET não autenticada. Na avaliação de Shaw, a vulnerabilidade não deveria ser interpretada apenas como uma falha de negação de serviço em sistemas que utilizam ASLR. O próprio problema poderia oferecer um caminho para obter os endereços necessários à etapa seguinte de exploração. Essa conclusão, entretanto, ainda não foi validada de forma independente. O pesquisador decidiu não publicar detalhes completos nem um código de prova de conceito imediatamente, o que impede que terceiros confirmem a confiabilidade do método neste momento. A afirmação sobre um possível bypass do ASLR deve, portanto, ser tratada como uma conclusão técnica do pesquisador, e não como uma capacidade confirmada oficialmente pela F5. Para ambientes que não podem aplicar a atualização imediatamente, a F5 recomenda substituir capturas numeradas por capturas nomeadas nas expressões regulares relacionadas à diretiva map. Em vez de utilizar referências como $1 e $2, o administrador pode atribuir nomes explícitos aos grupos capturados e fazer referência a essas variáveis na configuração. Segundo o boletim da F5, essa modificação impede o principal cenário conhecido de exploração. A medida, porém, deve ser considerada apenas uma mitigação temporária. Shaw afirma ter identificado um segundo caminho capaz de provocar o mesmo estouro quando uma diretiva map define um grupo nomeado com o mesmo nome utilizado anteriormente por outra expressão regular, como uma expressão configurada em um bloco location. O pesquisador disse ter confirmado essa variação com o AddressSanitizer, ferramenta utilizada para detectar erros de memória durante a execução de programas. Esse cenário não aparece no boletim oficial publicado pela F5. Diante dessa possibilidade, a atualização para NGINX 1.30.4, 1.31.3 ou NGINX Plus R37 P3 permanece como a única correção completa conhecida. Alterações emergenciais na configuração podem reduzir a exposição, mas não devem substituir a instalação das versões corrigidas. O comunicado da F5 relaciona a CVE-2026-42533 não apenas ao servidor NGINX de código aberto e ao NGINX Plus, mas também a produtos construídos sobre seus componentes. A lista inclui NGINX Ingress Controller, NGINX Gateway Fabric, NGINX App Protect WAF e NGINX Instance Manager. No momento da divulgação inicial, a F5 ainda não havia informado versões corrigidas específicas para todos esses produtos. O NGINX Ingress Controller é amplamente utilizado para gerenciar o tráfego de entrada em clusters Kubernetes. O Gateway Fabric implementa recursos relacionados à Kubernetes Gateway API, enquanto o App Protect WAF adiciona funções de firewall de aplicações web. Essa presença em ambientes de nuvem, contêineres, APIs e arquiteturas de microsserviços amplia o impacto potencial da vulnerabilidade. Uma instância afetada pode estar posicionada diretamente na borda da infraestrutura e receber requisições enviadas por usuários externos. Administradores devem verificar não apenas a versão do executável NGINX instalado diretamente no sistema, mas também imagens de contêiner, controladores Kubernetes, appliances e soluções comerciais que incorporem versões vulneráveis. A análise deve procurar diretivas map que utilizem expressões regulares e gerem variáveis posteriormente combinadas com capturas numeradas de uma expressão anterior. O padrão vulnerável exige que a referência numerada, como $1 ou $2, apareça na expressão antes da variável produzida pela diretiva map. A ordem é relevante porque determina quando o estado das capturas é calculado e sobrescrito. Arquivos incluídos por meio da diretiva include também precisam ser analisados, já que partes relacionadas da configuração podem estar distribuídas por diferentes diretórios e arquivos. A simples presença de uma diretiva map ou de uma expressão regular não confirma que o servidor possa ser explorado. É necessário avaliar o encadeamento das variáveis e a ordem em que elas são processadas. Mesmo quando a configuração não parece corresponder ao padrão descrito, organizações devem atualizar o NGINX. Configurações podem mudar, arquivos antigos podem ser reativados e aplicações instaladas posteriormente podem introduzir uma combinação vulnerável. A CVE-2026-42533 é a terceira vulnerabilidade de estouro de memória divulgada em aproximadamente dois meses envolvendo o mecanismo de avaliação de expressões do NGINX. Em maio, o projeto corrigiu a CVE-2026-42945, conhecida como Rift, relacionada a um estado incorreto durante o processamento de scripts. Poucos dias depois, a CVE-2026-9256 revelou outro estouro de buffer provocado por capturas sobrepostas no módulo rewrite. O histórico oficial de lançamentos do NGINX confirma que as duas falhas receberam correções nas versões publicadas em maio. Embora os gatilhos sejam diferentes, os três problemas compartilham uma característica estrutural: o mecanismo calcula o tamanho do buffer em uma passagem e escreve o resultado em outra, assumindo que o estado utilizado nas duas operações permanecerá consistente. Na CVE-2026-42533, essa premissa é quebrada porque uma nova expressão regular altera as capturas entre o cálculo e a gravação. A análise dos pesquisadores sugere que componentes semelhantes que utilizam processamento em duas etapas precisam ser revisados para identificar outras inconsistências desse tipo. Até 20 de julho de 2026, a CVE-2026-42533 não havia sido adicionada ao catálogo Known Exploited Vulnerabilities da CISA, e não havia relatos públicos confirmados de exploração ativa. Também não havia um exploit público disponível. Shaw informou que pretende divulgar sua prova de conceito 21 dias após o lançamento da correção, o que pode facilitar a validação da falha, mas também reduzir o tempo disponível para que organizações vulneráveis realizem a atualização. A publicação de detalhes técnicos costuma acelerar a criação de scanners e tentativas de exploração. Servidores expostos à internet, proxies reversos, gateways de API e controladores de entrada Kubernetes devem receber prioridade no processo de correção. A recomendação é atualizar para NGINX 1.30.4 ou 1.31.3, conforme o ramo utilizado, ou para NGINX Plus R37 P3. Após a instalação, as equipes devem validar a configuração, reiniciar os processos necessários e confirmar que todas as instâncias e imagens de contêiner passaram a utilizar a versão corrigida.

Os desenvolvedores do 7-Zip lançaram a versão 26.02 do popular compactador de arquivos para corrigir uma vulnerabilidade de execução remota de código (RCE) que pode ser explorada por meio de arquivos compactados especialmente manipulados. A falha pode permitir que invasores executem código arbitrário na máquina da vítima caso ela seja induzida a abrir um arquivo malicioso. A vulnerabilidade foi identificada pelo pesquisador Landon Peng, da Lunbun, e afeta o processamento de dados compactados no formato XZ. Segundo um comunicado da Zero Day Initiative (ZDI), dados XZ cuidadosamente elaborados podem provocar um heap-based buffer overflow, um tipo de corrupção de memória que pode resultar na execução de código com os mesmos privilégios do usuário que abriu o arquivo. Embora o desenvolvedor do 7-Zip não tenha divulgado detalhes técnicos completos sobre a vulnerabilidade, alterações no código-fonte da versão 26.02 indicam que o problema estava relacionado ao controle do espaço disponível durante o processo de descompressão de arquivos XZ. A atualização implementa verificações adicionais para impedir que o mecanismo de descompressão grave dados além do espaço restante disponível no buffer de saída, mitigando assim a possibilidade de exploração por meio de um estouro de buffer na heap. De acordo com a ZDI, a exploração da vulnerabilidade exige interação do usuário. Na prática, isso significa que a vítima precisa ser convencida a abrir um arquivo compactado malicioso ou acessar uma página capaz de fornecer esse conteúdo. Embora não seja uma exploração automática, esse tipo de cenário é frequentemente utilizado em campanhas de phishing e engenharia social. Diferentemente de muitos aplicativos modernos, o 7-Zip não possui um mecanismo de atualização automática. Por esse motivo, os usuários não receberão a correção de segurança automaticamente e precisarão instalar manualmente a versão 26.02, disponível no site oficial do projeto. A ausência de atualização automática amplia a janela de exposição, principalmente porque o 7-Zip está entre os compactadores de arquivos mais utilizados em sistemas Windows, tornando-se um alvo frequente para grupos de cibercrime interessados em explorar vulnerabilidades capazes de instalar malware nas máquinas das vítimas. Um cenário plausível de exploração envolve o envio de arquivos compactados maliciosos por e-mail, aplicativos de mensagens ou downloads falsos. Após convencer a vítima a abrir o arquivo, um invasor poderia executar código arbitrário e iniciar a instalação de trojans, backdoors, ransomware ou outros tipos de malware. O uso de vulnerabilidades em softwares de compactação não é novidade. Em 2025, uma falha no próprio 7-Zip permitia contornar o mecanismo de segurança Mark of the Web (MotW) do Windows e foi explorada como um zero-day por hackers ligados à Rússia para distribuir malware. Ainda naquele ano, outro grupo russo explorou uma vulnerabilidade no WinRAR, identificada como CVE-2025-8088, em campanhas de phishing destinadas à instalação do malware RomCom. Esses episódios demonstram que falhas em ferramentas amplamente utilizadas para manipulação de arquivos continuam sendo extremamente valiosas para agentes maliciosos, especialmente porque exploram uma ação comum do usuário: abrir um arquivo recebido por e-mail ou baixado da internet. Até o momento, não existem evidências de exploração ativa da nova vulnerabilidade corrigida no 7-Zip 26.02. Ainda assim, pesquisadores recomendam que usuários e organizações realizem a atualização o quanto antes para reduzir a superfície de ataque e evitar que futuras campanhas de malware utilizem a falha como vetor de comprometimento.

A cadeia de abastecimento de alimentos do Japão foi impactada por um ataque cibernético contra a Nichirei Logistics Group, maior empresa de logística refrigerada do país. O incidente interrompeu operações de distribuição de alimentos congelados e refrigerados, provocando atrasos nas entregas para milhares de clientes e afetando redes de restaurantes, supermercados e fabricantes de alimentos. A empresa informou que identificou uma indisponibilidade em seus sistemas na última segunda-feira e confirmou, na quinta-feira, que hackers conseguiram invadir seus servidores. Como medida de contenção e para proteger os dados de clientes, a Nichirei desconectou sistemas críticos de sua infraestrutura, interrompendo parte significativa de sua operação logística. Segundo a companhia, a retomada dos serviços deve ocorrer de forma gradual a partir desta sexta-feira. No entanto, ainda não há previsão para que toda a operação volte ao funcionamento normal. A Nichirei Logistics opera aproximadamente 140 centros de distribuição refrigerados em todo o Japão e presta serviços para cerca de 5 mil clientes, desempenhando um papel estratégico na cadeia de suprimentos de alimentos do país. A interrupção das operações afetou tanto atividades de armazenagem quanto o transporte de produtos congelados. Durante a investigação do incidente, a empresa também constatou que alguns dos servidores comprometidos armazenavam informações pessoais. A organização notificou as autoridades japonesas responsáveis pela proteção de dados e informou que continua apurando o caso. Segundo a empresa, ainda não há confirmação de vazamento de informações. Caso isso seja comprovado, a companhia afirmou que realizará a comunicação oficial às autoridades e às partes afetadas conforme exigido pela legislação. A Nichirei não divulgou detalhes técnicos sobre o ataque, alegando que a divulgação dessas informações poderia representar riscos adicionais à segurança. Também não informou como os invasores obtiveram acesso ao ambiente corporativo nem confirmou se o incidente envolve ransomware, prática comum em ataques direcionados a empresas de infraestrutura crítica e cadeias de suprimentos. Os impactos operacionais foram sentidos rapidamente em diversos setores da indústria alimentícia japonesa. A KFC Japan informou que o acesso não autorizado aos sistemas da Nichirei interrompeu o fornecimento de ingredientes para suas mais de 1.300 unidades no país, incluindo o tradicional frango preparado com a receita Original Recipe. Como consequência, algumas lojas podem enfrentar falta de produtos, redução temporária do cardápio, horários de funcionamento limitados e até fechamento provisório, dependendo do estoque disponível. A rede também suspendeu temporariamente os pedidos online realizados pelo site oficial e pelo aplicativo móvel, afirmando que não consegue prever quando o fluxo normal de abastecimento será restabelecido. Outras grandes empresas também relataram impactos decorrentes da interrupção logística. Entre elas estão a rede de bentôs Hotto Motto, a operadora de restaurantes Yayoi Ken, a rede de sushi Kura Sushi, além da varejista Aeon, que informou à imprensa japonesa a ocorrência de falta de produtos em parte de seus supermercados. A fabricante de alimentos congelados TableMark também declarou que não conseguiu realizar o envio de produtos para redes varejistas e clientes comerciais devido à paralisação da logística refrigerada. O caso evidencia como ataques contra fornecedores de serviços essenciais podem produzir efeitos em cascata muito além da organização inicialmente comprometida. Empresas responsáveis por transporte, armazenamento e distribuição fazem parte da cadeia de suprimentos crítica, e uma interrupção em seus sistemas pode afetar simultaneamente milhares de clientes, comprometendo operações, disponibilidade de produtos e receitas de diversos segmentos. Nas últimas semanas, outras grandes empresas japonesas também divulgaram incidentes de segurança cibernética, incluindo a operadora de telecomunicações KDDI, a subsidiária japonesa da seguradora Aflac, a fabricante de equipamentos eletrônicos Nidec e a cervejaria Sapporo Holdings. Até o momento, não há indícios de que esses ataques estejam relacionados entre si.

A União Europeia e o Reino Unido atribuíram formalmente ao Centro 16 do Serviço Federal de Segurança da Rússia, o FSB, uma operação de sabotagem cibernética contra o setor energético da Polônia. O ataque, ocorrido em dezembro de 2025, chegou perto de provocar interrupções de energia que poderiam afetar cerca de 500 mil pessoas durante o inverno europeu. A atribuição foi anunciada em 13 de julho de 2026, juntamente com o primeiro pacote de sanções cibernéticas adotado de forma coordenada pela UE e pelo governo britânico. As medidas procuram atingir integrantes de serviços de inteligência, operadores de malware, empresas privadas, hackers e organizações acusadas de apoiar os objetivos estratégicos de Moscou. Segundo a União Europeia, o Centro 16 é o braço de inteligência de sinais do FSB e controla diferentes grupos de ameaça, incluindo o Turla, também conhecido por nomes como Snake e Venomous Bear. A unidade foi responsabilizada por operações de espionagem, infiltração em redes governamentais e tentativas de sabotagem contra infraestruturas críticas. As atividades atribuídas ao ecossistema cibernético russo teriam atingido, nos últimos anos, França, Alemanha, Polônia, Chipre, Países Baixos, Áustria, Eslováquia, Romênia e Finlândia, além da Ucrânia e de outros parceiros europeus. “Condenamos firmemente o comportamento da Rússia e o uso indevido desse ecossistema cibernético, que tem como alvos serviços públicos e infraestruturas críticas, provocando interrupções e perdas financeiras”, afirmou a chefe da diplomacia da União Europeia, Kaja Kallas. Ataque tentou comprometer infraestrutura energética O incidente polonês ocorreu em 29 de dezembro de 2025 e envolveu ataques coordenados contra instalações do setor de energia. A análise técnica do CERT Polska identificou ações destrutivas contra sistemas de geração distribuída e uma usina de cogeração, infraestrutura responsável pela produção combinada de eletricidade e calor. Em parte dos ambientes atacados, os invasores encontraram equipamentos industriais da Moxa com interfaces administrativas expostas e credenciais padrão. Os responsáveis utilizaram esse acesso para restaurar dispositivos às configurações de fábrica, alterar senhas e definir endereços IP inválidos, dificultando a recuperação operacional. Em uma das instalações, o objetivo teria sido destruir de forma irreversível dados armazenados na rede interna por meio de um malware do tipo wiper. Diferentemente de um ransomware, que normalmente criptografa arquivos para exigir pagamento, um wiper busca apagar ou inutilizar dados e sistemas. A invasão foi precedida por um período prolongado de acesso à infraestrutura e roubo de informações sensíveis. Os hackers conseguiram comprometer contas privilegiadas no Active Directory, o que permitiu movimentação lateral pelos sistemas da organização. O código destrutivo foi distribuído por meio de Group Policy Objects, ou GPOs, recurso legítimo utilizado por administradores para aplicar configurações e executar tarefas em máquinas de um domínio Windows. A solução de EDR implantada pela organização detectou e bloqueou a atividade maliciosa antes que o wiper concluísse o ataque. Disputa inicial sobre a autoria As primeiras análises publicadas por empresas de cibersegurança associaram o ataque ao Sandworm, grupo historicamente vinculado ao serviço de inteligência militar russo, o GRU. O Sandworm é conhecido por operações destrutivas contra infraestrutura crítica, incluindo ataques anteriores ao sistema elétrico da Ucrânia. O CERT Polska, entretanto, contestou essa atribuição inicial depois de analisar a infraestrutura utilizada na invasão. Os investigadores encontraram conexões com um conjunto de servidores e atividades anteriormente relacionado ao FSB, conclusão posteriormente adotada na atribuição pública da União Europeia e do Reino Unido. A atribuição de ataques cibernéticos costuma combinar indicadores técnicos, infraestrutura de comando e controle, métodos operacionais, histórico dos grupos, informações de inteligência e interesses estratégicos. Como diferentes unidades russas podem utilizar ferramentas semelhantes ou compartilhar recursos, divergências entre análises iniciais são possíveis. Além do setor energético, o serviço de inteligência doméstica da Polônia informou que invasões contra instalações de tratamento de água criaram risco direto à continuidade do abastecimento no país. Operações atingiram governos e organizações europeias A França também anunciou medidas adicionais e informou que convocaria o embaixador russo para prestar esclarecimentos sobre atividades persistentes de espionagem cibernética. Um relatório técnico do Centro de Coordenação de Crises Cibernéticas da França, conhecido como C4, detalhou operações atribuídas ao Centro 16 e identificou 11 centros de interceptação ligados ao braço de inteligência de sinais do FSB em território russo. Entre eles está a Unidade 61240, descrita pelas autoridades francesas como uma estrutura dedicada a operações contra alvos na França. Duas empresas russas, AO AST e NPP Gamma, foram acusadas de fornecer suporte às atividades ofensivas da unidade. As autoridades francesas relacionaram o FSB a ataques contra sistemas de ministérios em 2014, à rede da Embaixada da França em Moscou em 2018 e a um instituto de pesquisa ligado à indústria de defesa francesa em fevereiro de 2025. Nesse último incidente, um volume significativo de informações teria sido roubado. Um dos grupos incluídos nas sanções também teria reivindicado ações de desestabilização relacionadas aos Jogos Olímpicos e Paralímpicos de Paris de 2024. O governo francês declarou que pretende utilizar os instrumentos disponíveis para responder a operações cibernéticas maliciosas antes das eleições nacionais de 2027. Alerta conjunto destaca roteadores mal configurados Estados Unidos e agências de segurança de aproximadamente uma dúzia de países aliados também publicaram um alerta técnico conjunto sobre as operações do Centro 16. Segundo o documento, os hackers continuam explorando dispositivos de rede vulneráveis ou configurados de forma inadequada. A atividade inclui varreduras em larga escala da internet em busca de roteadores protegidos por senhas padrão, credenciais fracas, softwares desatualizados e serviços de administração expostos. Depois de comprometer esses equipamentos, os operadores podem utilizá-los como infraestrutura intermediária para ocultar a origem das conexões, acessar redes de interesse ou apoiar operações de espionagem. O uso de roteadores legítimos comprometidos dificulta a detecção porque o tráfego malicioso parece vir de dispositivos comuns localizados em outros países. O alerta recomenda eliminar credenciais padrão, utilizar senhas fortes e exclusivas, instalar atualizações de segurança, desativar interfaces administrativas desnecessárias e restringir o gerenciamento remoto. Organizações também devem revisar equipamentos que não recebem mais suporte do fabricante e monitorar alterações incomuns nas configurações. Lumma Stealer também entra nas sanções O Reino Unido incluiu no pacote pessoas associadas ao Lumma Stealer, uma das famílias de malware de roubo de informações mais utilizadas por grupos de cibercrime. O malware é projetado para extrair credenciais armazenadas em navegadores, cookies de sessão, carteiras de criptomoedas e outras informações presentes em computadores infectados. Esses dados podem ser comercializados ou utilizados para invadir contas corporativas e pessoais. Segundo autoridades britânicas, credenciais roubadas pelo Lumma foram utilizadas para apoiar operações russas de espionagem em diferentes países. A National Crime Agency informou que mais de 2.100 vítimas no Reino Unido foram infectadas pelo malware nos seis meses anteriores ao anúncio. As sanções britânicas contra os operadores do Lumma incluem congelamento de ativos, proibição de entrada no país e impedimento para exercer cargos de direção em empresas. O governo britânico acusa os serviços russos de recorrer a criminosos digitais para coletar informações relacionadas aos objetivos militares e de política externa de Moscou. Esse modelo permite que o Estado utilize grupos intermediários e mantenha algum nível de distanciamento formal das operações. Sanções alcançam mais de 30 alvos Consideradas em conjunto, as medidas da União Europeia e do Reino Unido atingem mais de 30 pessoas e organizações associadas ao ecossistema cibernético russo. A UE aplicou restrições a nove indivíduos e quatro entidades, incluindo agentes de inteligência, criminosos digitais, hacktivistas e empresas acusadas de viabilizar operações maliciosas. O bloco descreveu o pacote como o maior conjunto de sanções cibernéticas já adotado por suas instituições. O Reino Unido sancionou 24 indivíduos e entidades. Entre os alvos estão dirigentes e integrantes da Unidade 29155 do GRU, operadores do Lumma Stealer, empresas acusadas de recrutar especialistas em universidades russas e pessoas associadas ao blog militar pró-Kremlin Rybar. Dez pessoas relacionadas ao Rybar foram incluídas nas medidas britânicas. O Reino Unido acusa o veículo de disseminar desinformação sobre a Ucrânia e interferir em processos eleitorais na Moldávia e na Armênia. A ministra das Relações Exteriores do Reino Unido, Yvette Cooper, afirmou que as sanções pretendem atingir as redes criminosas que sustentam as atividades agressivas do Estado russo e demonstrar que Moscou não pode se esconder atrás de grupos intermediários. A Rússia nega repetidamente conduzir operações cibernéticas ofensivas contra países ocidentais. O presidente Vladimir Putin classificou acusações europeias de sabotagem e ataques digitais como infundadas e afirmou que elas seriam utilizadas para justificar políticas hostis contra Moscou.

A União Europeia estuda estabelecer 13 anos como idade mínima comum para o acesso de crianças às redes sociais sem a supervisão de pais ou responsáveis. A proposta foi defendida pela presidente da Comissão Europeia, Ursula von der Leyen, após a entrega de um relatório elaborado por um painel especial de especialistas em segurança infantil no ambiente digital. A medida ainda não representa uma proibição aprovada. A Comissão Europeia analisa as recomendações do grupo e deverá definir os próximos passos para transformar as conclusões em uma proposta formal, que precisaria passar pelo processo legislativo do bloco. O painel entregou seu relatório final em 13 de julho de 2026. Von der Leyen afirmou que existe um consenso crescente sobre a necessidade de definir uma “data de início” para o ingresso de crianças nas redes sociais. Embora reconheça que cabe às famílias decidir quando os filhos receberão o primeiro smartphone, a presidente da Comissão considera necessário estabelecer limites comuns para o uso das plataformas. O modelo em análise prevê que crianças com menos de 13 anos tenham acesso limitado e acompanhado por adultos. A partir dessa idade, a utilização poderia ser liberada gradualmente, conforme a faixa etária e mediante demonstração, pelas próprias plataformas, de que seus serviços são adequados e seguros para adolescentes. A recomendação não se limita às redes sociais tradicionais. O conceito discutido pelo painel inclui serviços digitais com recursos sociais, jogos e ferramentas baseadas em inteligência artificial capazes de manter interações prolongadas com crianças e adolescentes. Responsabilidade maior para as plataformas Um dos principais pontos da proposta é transferir às empresas de tecnologia a responsabilidade de demonstrar que seus produtos não provocam danos aos usuários mais jovens. Von der Leyen comparou essa obrigação aos requisitos de segurança aplicados à indústria automobilística, como a instalação de cintos de segurança e airbags. Na prática, empresas como Meta, TikTok, Google e outras operadoras de plataformas digitais poderiam ter de comprovar que seus sistemas de recomendação, mecanismos de interação e recursos de engajamento foram projetados de maneira apropriada para cada faixa etária. A discussão envolve funcionalidades como rolagem infinita, reprodução automática de vídeos, notificações constantes e algoritmos de recomendação personalizados. Esses mecanismos são desenvolvidos para ampliar o tempo de permanência nas plataformas, mas vêm sendo questionados por reguladores devido ao risco de estimular uso compulsivo, especialmente entre crianças. Em julho de 2026, a Comissão Europeia acusou preliminarmente a Meta de não enfrentar adequadamente os riscos associados ao chamado “design viciante” no Facebook e no Instagram. A investigação, conduzida com base na Lei de Serviços Digitais, também analisa se a empresa adota medidas suficientes para impedir que menores de 13 anos acessem seus serviços. Tempo diante das telas preocupa autoridades Ao defender novas restrições, Von der Leyen afirmou que crianças europeias passam, em média, entre quatro e seis horas por dia diante de telas. Segundo ela, seis horas diárias acumuladas poderiam representar aproximadamente 20 anos de vida dedicados ao uso desses dispositivos. A Comissão relaciona a discussão a preocupações sobre saúde mental, qualidade do sono, concentração, desenvolvimento social e exposição a conteúdos inadequados. O objetivo declarado é construir uma política que não dependa apenas da vigilância familiar, mas que imponha requisitos técnicos e jurídicos às empresas responsáveis pelos serviços digitais. A aplicação de uma idade mínima, entretanto, dependerá de mecanismos confiáveis de verificação etária. Atualmente, diversas plataformas determinam em seus termos de uso que os usuários devem ter pelo menos 13 anos, mas a declaração de uma data de nascimento falsa costuma ser suficiente para contornar a restrição. Para enfrentar o problema, a União Europeia desenvolve soluções de verificação de idade que buscam confirmar se uma pessoa pertence a determinada faixa etária sem necessariamente revelar sua identidade completa. A implementação deverá equilibrar proteção infantil, privacidade, segurança dos dados e facilidade de acesso. Países defendem limites mais rígidos A iniciativa surge em meio à pressão de governos europeus por uma resposta coordenada. França, Espanha e Grécia estão entre os países que aprovaram, anunciaram ou discutem restrições nacionais, algumas delas voltadas a menores de 15 ou 16 anos. Essa diferença pode gerar divergências durante a negociação de uma regra comum. Enquanto a Comissão considera 13 anos como o ponto inicial de uma política progressiva, alguns governos defendem uma proibição mais ampla para adolescentes mais velhos. Uma eventual legislação europeia também terá de definir quais serviços serão abrangidos, como a verificação etária será realizada, quais formas de supervisão adulta serão aceitas e quais penalidades poderão ser aplicadas às plataformas que não cumprirem as exigências. A proposta formal é esperada após o verão europeu de 2026. Para entrar em vigor em todos os 27 Estados-membros, o texto ainda deverá ser negociado e aprovado pelo Parlamento Europeu e pelos governos nacionais no Conselho da União Europeia.

Hackers ligados ao governo da Rússia estão comprometendo câmeras de segurança conectadas à internet em países europeus e na Ucrânia para monitorar rotas militares, acompanhar o transporte de armas e identificar soldados ucranianos, segundo um alerta divulgado pelos serviços de inteligência dos Países Baixos. O comunicado conjunto do Serviço Geral de Inteligência e Segurança dos Países Baixos (AIVD) e do Serviço de Inteligência e Segurança Militar (MIVD) afirma que ao menos uma agência de inteligência russa conduz operações de ciberespionagem contra câmeras acessíveis pela internet instaladas em território holandês, em outros países da OTAN e da União Europeia e na Ucrânia. O objetivo da campanha é coletar informações com valor militar, incluindo movimentações em corredores logísticos, passagem de veículos, transporte de equipamentos e remessas de armamentos destinadas às forças ucranianas. Na Ucrânia, algumas das câmeras comprometidas teriam sido utilizadas para localizar militares. De acordo com as agências holandesas, as informações obtidas pelos invasores posteriormente apoiaram tentativas de atingir soldados e destruir equipamentos no campo de batalha. A investigação também identificou um pequeno número de câmeras comprometidas ao longo de rotas de logística militar nos Países Baixos. O país ocupa uma posição estratégica na Europa e funciona como importante corredor para o transporte de equipamentos e suprimentos destinados à Ucrânia. “Como um país-chave de trânsito, os Países Baixos são um importante alvo de espionagem devido à sua localização geográfica e ao seu apoio à Ucrânia”, afirmaram AIVD e MIVD no alerta publicado em 10 de julho. Moscou tem negado repetidamente envolvimento em operações cibernéticas maliciosas contra países ocidentais. Câmeras expostas são localizadas pela internet Segundo o alerta, os hackers realizam varreduras automatizadas da internet em busca de câmeras e outros dispositivos de videomonitoramento expostos. Os equipamentos são identificados a partir de endereços IP, informações de fabricantes, interfaces de administração e características específicas dos dispositivos. Depois de localizar os alvos, os invasores exploram práticas inseguras comuns em equipamentos de Internet das Coisas, como senhas padrão, credenciais fracas, firmware desatualizado e configurações originais mantidas após a instalação. Essas falhas podem permitir que os operadores da campanha acessem transmissões ao vivo, alterem configurações ou mantenham controle persistente sobre os dispositivos sem que os responsáveis pelo sistema percebam a invasão. As imagens capturadas são analisadas automaticamente por softwares de reconhecimento visual. A tecnologia permite identificar veículos militares, tipos de carga e outros elementos logísticos relevantes em grandes volumes de vídeo, reduzindo a necessidade de análise manual. A combinação entre câmeras comprometidas e reconhecimento de imagens transforma sistemas comerciais de vigilância em ferramentas de inteligência militar. Um equipamento instalado para proteger um estacionamento, depósito, rodovia ou centro logístico pode acabar revelando movimentações estratégicas. Espionagem ultrapassa o conflito na Ucrânia Os serviços de inteligência holandeses avaliam que a operação não se limita ao monitoramento de remessas destinadas à Ucrânia. A Rússia também estaria utilizando câmeras comprometidas para coletar informações militares dentro de países da OTAN e da União Europeia, mesmo quando a atividade observada não possui relação direta com a guerra. Até o momento, AIVD e MIVD afirmam não ter identificado o uso dessas informações para apoiar ataques militares fora do território ucraniano. Ainda assim, a campanha demonstra a capacidade russa de reunir inteligência operacional que poderia ser empregada em um eventual conflito futuro. “O número de operações de ciberespionagem conduzidas por agentes estatais russos em apoio a operações militares aumentou continuamente desde o início da guerra contra a Ucrânia”, disseram as agências. O uso de dispositivos conectados para espionagem oferece vantagens aos invasores porque permite acompanhar alvos de forma remota, discreta e contínua. Além disso, muitas câmeras ficam anos sem receber atualizações de segurança e são administradas por organizações que não mantêm inventários completos dos equipamentos. Dispositivos de diferentes fabricantes também podem ser acessados diretamente pela internet, sem segmentação de rede, autenticação multifator ou monitoramento centralizado. Essa exposição amplia a superfície de ataque e facilita operações em escala. Alerta recomenda atualização e troca de credenciais As autoridades orientaram organizações públicas e privadas a revisar a segurança de câmeras conectadas à internet, especialmente aquelas instaladas próximas a portos, aeroportos, ferrovias, rodovias, instalações militares, centros logísticos e depósitos. Entre as principais recomendações estão a substituição imediata de credenciais padrão, o uso de senhas fortes e exclusivas, a atualização constante de firmware e a revisão das configurações de acesso remoto. As organizações também devem limitar a exposição direta dos equipamentos à internet, restringir conexões por endereço IP, segmentar câmeras em redes separadas e monitorar tentativas de autenticação ou conexões incomuns. O alerta recomenda ainda considerar o país de origem dos equipamentos e dos fornecedores. Segundo as agências, China, Rússia e Irã mantêm programas cibernéticos ofensivos que têm interesses holandeses entre seus alvos. A origem de um dispositivo, porém, não substitui controles técnicos. Mesmo equipamentos de fabricantes considerados confiáveis podem se tornar vulneráveis quando utilizam credenciais padrão, sistemas desatualizados ou interfaces administrativas expostas. A campanha destaca como dispositivos comuns de videomonitoramento passaram a integrar operações modernas de inteligência e guerra. Além de proteger as próprias redes, organizações envolvidas em cadeias logísticas militares precisam avaliar quais informações visuais suas câmeras podem revelar sobre rotas, cargas, horários e padrões operacionais.

Mozilla, Google, Adobe e Broadcom lançaram uma série de atualizações para corrigir vulnerabilidades críticas em navegadores, plataformas de comércio eletrônico, servidores de aplicações, ferramentas de criação e componentes de infraestrutura corporativa. Entre os problemas mais graves estão duas falhas no Firefox com códigos de exploração já disponíveis publicamente, vulnerabilidades de corrupção de memória no Chrome, oito brechas críticas no Adobe ColdFusion e uma falha de autenticação no VMware Avi Load Balancer com pontuação CVSS 9,8. Embora nenhum dos fabricantes tenha confirmado exploração ativa das vulnerabilidades em ataques reais, a publicação de códigos de prova de conceito e detalhes técnicos aumenta o risco de que invasores adaptem rapidamente essas falhas para campanhas maliciosas. A Mozilla corrigiu duas vulnerabilidades críticas no Firefox 152.0.6. A empresa informou que códigos capazes de explorar os problemas já estão disponíveis publicamente, mas afirmou não ter conhecimento de ataques que estejam utilizando as falhas. A CVE-2026-15718 envolve um ponteiro inválido no componente JavaScript: WebAssembly do navegador. Erros dessa natureza podem fazer com que o software tente acessar uma região incorreta da memória, provocando falhas, corrupção de dados ou, em determinadas circunstâncias, execução de código controlado pelo invasor. O WebAssembly permite executar código de alto desempenho dentro do navegador e é utilizado por aplicações web, jogos, ferramentas de edição e outros serviços. Por operar próximo às camadas de memória e execução, vulnerabilidades nesse componente podem representar risco elevado. A segunda falha, identificada como CVE-2026-15719, está relacionada ao isolamento de sites no componente DOM: Navigation. O isolamento de sites é uma proteção criada para manter conteúdos de diferentes domínios separados em processos ou contextos de segurança distintos. Uma falha nesse mecanismo pode permitir que uma página maliciosa ultrapasse limites de segurança definidos pelo navegador e interfira em dados ou recursos pertencentes a outro site. A Mozilla classificou as duas vulnerabilidades como críticas e recomenda a atualização para o Firefox 152.0.6. O boletim foi publicado em 14 de julho de 2026. A disponibilidade pública de código de exploração torna a correção especialmente urgente. Mesmo que não existam ataques conhecidos, a publicação de uma prova de conceito reduz o trabalho necessário para que grupos criminosos transformem a falha em uma ferramenta operacional. O Google lançou atualizações para corrigir 15 vulnerabilidades no Chrome, incluindo dois problemas críticos de uso de memória após liberação, conhecidos como use-after-free. As falhas CVE-2026-15764 e CVE-2026-15765 afetam o Ozone, uma camada de abstração utilizada pelo navegador para interagir com servidores gráficos, sistemas de janelas e outros componentes nativos de diferentes plataformas. O Ozone oferece suporte a ambientes como Linux, ChromeOS e Fuchsia. Ele permite que o Chrome funcione sobre diferentes arquiteturas gráficas sem que toda a lógica do navegador precise ser adaptada individualmente para cada sistema. Uma vulnerabilidade use-after-free ocorre quando um programa continua utilizando uma área de memória depois que ela já foi liberada. Um invasor pode tentar controlar o conteúdo que passa a ocupar esse espaço e manipular o comportamento do aplicativo. De acordo com a descrição da CVE-2026-15764, um atacante remoto poderia criar uma página HTML maliciosa e convencer a vítima a executar gestos específicos na interface. A interação poderia provocar corrupção da memória heap no Chrome para Linux. A necessidade de interação não elimina o risco, pois os gestos podem ser induzidos por botões, caixas de diálogo, jogos, verificações falsas ou outros elementos visuais preparados para enganar o usuário. As correções foram disponibilizadas nas versões 150.0.7871.124 e 150.0.7871.125 para Windows e macOS, além da versão 150.0.7871.124 para Linux. O Google confirmou que a atualização contém 15 correções de segurança, incluindo as duas falhas críticas no Ozone e problemas de alta gravidade no Skia, libyuv, GPU, Media, Core e no mecanismo JavaScript V8. Como ocorre normalmente durante a distribuição de atualizações do Chrome, o fabricante pode restringir detalhes técnicos até que a maior parte dos usuários esteja protegida. Essa prática busca reduzir a possibilidade de exploração durante o período em que os patches ainda estão sendo instalados. A Adobe publicou atualizações para 88 vulnerabilidades distribuídas por diferentes produtos. Os boletins incluem falhas críticas no ColdFusion, Adobe Commerce, Magento Open Source, Adobe Experience Manager e Illustrator. O ColdFusion concentra alguns dos problemas de maior gravidade. A plataforma é utilizada para desenvolver e executar aplicações web, inclusive em ambientes empresariais e governamentais, o que torna servidores expostos um alvo relevante para invasores. A Adobe corrigiu oito vulnerabilidades críticas no ColdFusion: CVE-2026-48318, com CVSS 9,9, é uma falha de travessia de diretórios que pode levar à execução arbitrária de código. CVE-2026-48322, com CVSS 9,6, permite injeção de código e possível execução de comandos controlados pelo atacante. CVE-2026-48284, com CVSS 9,6, decorre de validação inadequada de entrada e pode resultar em execução arbitrária de código. CVE-2026-48321, com CVSS 9,3, envolve autorização incorreta e pode permitir elevação de privilégios. CVE-2026-48325, com CVSS 9,3, está relacionada à ausência de autenticação em uma função crítica e pode permitir execução arbitrária de código. CVE-2026-48319, com CVSS 9,1, é outra vulnerabilidade de travessia de diretórios capaz de levar à execução de código. CVE-2026-48324, com CVSS 9,1, consiste em uma injeção de SQL que pode resultar em execução arbitrária de código. CVE-2026-48327, com CVSS 9,0, decorre de autorização incorreta e também pode permitir execução de código. As vulnerabilidades foram corrigidas no ColdFusion 2025 Update 11 e no ColdFusion 2023 Update 22. O boletim oficial informa que as atualizações resolvem problemas críticos, importantes e moderados nas versões 2025 e 2023 da plataforma. Uma falha de travessia de diretórios permite manipular caminhos de arquivos para acessar locais fora da pasta originalmente autorizada. Dependendo da implementação, o atacante pode ler configurações, obter credenciais, sobrescrever arquivos ou posicionar conteúdo malicioso em diretórios executáveis. A injeção de SQL ocorre quando dados fornecidos pelo usuário são incorporados de forma insegura a comandos enviados a um banco de dados. O problema pode permitir leitura, alteração ou exclusão de informações e, em determinados ambientes, evoluir para execução de comandos no servidor. As vulnerabilidades do ColdFusion são particularmente relevantes porque servidores de aplicações costumam manter acesso a bancos de dados, sistemas internos, arquivos de configuração e credenciais de serviços. O comprometimento de uma dessas plataformas pode servir como ponto inicial para roubo de dados, instalação de web shells, movimentação lateral e persistência na infraestrutura. A Adobe também corrigiu duas falhas críticas no Adobe Commerce e no Magento Open Source, plataformas utilizadas para operar lojas virtuais e processar transações online. A CVE-2026-48356, com pontuação CVSS 9,6, é uma vulnerabilidade de upload de arquivos que pode permitir elevação de privilégios. Falhas de upload podem permitir que um invasor envie conteúdo não autorizado ao servidor. Quando os controles de extensão, tipo, localização e execução são insuficientes, o arquivo pode ser utilizado para instalar código malicioso ou assumir funções administrativas. A CVE-2026-48358, com CVSS 9,1, decorre de codificação ou escape inadequado de saída e pode permitir execução arbitrária de código. Em plataformas de comércio eletrônico, o impacto de um comprometimento pode incluir alteração de páginas, captura de dados de pagamento, roubo de credenciais, criação de contas administrativas e interrupção das operações de venda. Ataques contra lojas virtuais também podem ser utilizados para implantar skimmers digitais, códigos maliciosos inseridos nas páginas de pagamento para capturar informações fornecidas pelos clientes. Duas vulnerabilidades críticas foram corrigidas no Adobe Experience Manager, plataforma utilizada por empresas para administrar sites, conteúdos digitais e experiências de clientes. A CVE-2026-48259, com pontuação CVSS 9,6, é uma falha de falsificação de requisições do lado do servidor, conhecida como SSRF. Em um ataque SSRF, o invasor induz o servidor vulnerável a realizar conexões em seu nome. Isso pode permitir acesso a serviços internos, interfaces administrativas, APIs que não estão expostas diretamente à internet ou metadados de ambientes em nuvem. Em infraestruturas cloud, uma SSRF mal explorada pode atingir endpoints de metadados associados a máquinas virtuais e, dependendo das proteções adotadas, expor tokens temporários ou credenciais de identidade. A CVE-2026-48359, também com CVSS 9,6, envolve restrição inadequada de referências a entidades externas em documentos XML, uma condição conhecida como XXE. Uma vulnerabilidade XXE pode ser explorada para ler arquivos locais, provocar requisições internas, causar indisponibilidade ou acessar outros recursos processados pelo servidor. Segundo a página do Adobe Product Security Incident Response Team, o fabricante publicou em 14 de julho de 2026 uma atualização específica para o Adobe Experience Manager. A Broadcom corrigiu uma vulnerabilidade crítica de bypass de autenticação no VMware Avi Load Balancer, também conhecido anteriormente como VMware NSX Advanced Load Balancer. Identificada como CVE-2026-47865, a falha recebeu pontuação CVSS 9,8. Um invasor com acesso de rede pode contornar o mecanismo de autenticação e acessar o plano de controle do Avi. O plano de controle administra configurações, políticas, aplicações, serviços virtuais, certificados e componentes relacionados ao balanceamento de carga. O acesso indevido a essa camada pode permitir manipular a distribuição de tráfego e afetar aplicações críticas. A vulnerabilidade foi descoberta e reportada por Filip Waeytens, do NATO Cyber Security Centre. O boletim VMSA-2026-0005 não apresenta nenhuma solução alternativa. A Broadcom orienta os clientes a instalar as versões corrigidas do Avi Controller. Para ambientes da linha 31.1.1 até 31.2.2, a correção está disponível na versão 31.2.2-2p3. Sistemas das versões 30.1.1 até 30.2.6 devem ser atualizados para a 30.2.7. Instalações da linha 22.1 devem migrar para pelo menos a versão 30.2.7. A Broadcom recomenda a versão 32.1.2, que era a versão mais recente disponível no momento da publicação do boletim. A atualização do VMware Avi Load Balancer também resolve outras seis vulnerabilidades, com pontuações entre 7,1 e 8,8. A CVE-2026-47866 permite contornar controles de autorização e acessar uma parte limitada do plano de controle. As CVEs 2026-47867 e 2026-47869 podem permitir execução remota de código em diferentes condições de acesso e autenticação. A CVE-2026-47868 possibilita que um usuário com acesso local eleve seus privilégios e execute código como root. A CVE-2026-47870 permite que um usuário autenticado execute código remotamente por meio de uma falha de elevação de privilégios. Por fim, a CVE-2026-47871 é uma vulnerabilidade de travessia de diretórios que pode ser explorada por um usuário autenticado com acesso de rede. A Broadcom informou que todas as falhas foram reportadas de forma privada e que não existem soluções alternativas para os problemas. A instalação das versões corrigidas é, portanto, a principal medida de mitigação. A urgência de aplicação dos patches depende da exposição e da função de cada produto. Firefox e Chrome estão presentes em grande quantidade de estações corporativas e podem ser explorados por meio de páginas maliciosas, anúncios comprometidos, links de phishing ou sites legítimos invadidos. O ColdFusion, o Adobe Commerce, o Magento e o Experience Manager costumam operar como serviços acessíveis pela internet. Servidores desatualizados podem ser localizados por varreduras automatizadas assim que detalhes técnicos ou códigos de exploração se tornam disponíveis. Já o VMware Avi Load Balancer ocupa uma posição crítica na infraestrutura de aplicações. O equipamento pode controlar tráfego destinado a sistemas internos, APIs e serviços publicados, tornando uma falha no plano de controle especialmente sensível. Organizações devem inventariar as versões instaladas, identificar sistemas expostos à internet, testar as atualizações quando necessário e aplicar primeiro as correções relacionadas a execução remota de código, bypass de autenticação e vulnerabilidades com exploits públicos. Equipes de segurança também devem procurar atividades anormais em logs de navegadores, servidores web, plataformas Adobe e controladores Avi. A atualização elimina a vulnerabilidade, mas não remove automaticamente acessos persistentes caso um sistema já tenha sido comprometido. Até a publicação dos boletins, nenhuma das vulnerabilidades havia sido oficialmente classificada como explorada em ataques reais. Ainda assim, o histórico de exploração de navegadores, ColdFusion, Magento e produtos VMware torna recomendável não adiar a instalação dos patches.

Pesquisadores da Unit 42, divisão de inteligência de ameaças da Palo Alto Networks, identificaram uma estrutura de botnet para dispositivos de Internet das Coisas chamada TuxBot v3 Evolution. O projeto apresenta sinais claros de que seu desenvolvedor utilizou um grande modelo de linguagem para gerar, adaptar e integrar partes do código malicioso. O uso de inteligência artificial, no entanto, produziu resultados inconsistentes. Embora o modelo tenha ajudado a construir uma plataforma modular com diversos mecanismos de ataque, vários componentes analisados não funcionavam corretamente. O desenvolvedor também deixou nos arquivos comentários gerados pela IA, incluindo explicações sobre decisões de programação e até um aviso de segurança que dizia que o código deveria ser usado apenas para pesquisas autorizadas. Segundo a Unit 42, uma revisão manual relativamente simples poderia ter identificado e corrigido os principais erros. Os pesquisadores avaliam, portanto, que versões mais completas e funcionais podem já existir ou ser produzidas com pouco esforço. A estrutura recuperada estava aproximadamente 70% operacional. Funções centrais, como varredura de dispositivos, ataques de força bruta, persistência, comunicação com o servidor de comando e controle e execução de ataques distribuídos de negação de serviço, funcionavam na amostra examinada. Botnet foi compilada para 17 arquiteturas O TuxBot v3 Evolution foi desenvolvido para infectar uma ampla variedade de equipamentos conectados à internet, incluindo roteadores, câmeras IP, servidores compactos, dispositivos Android e outros sistemas embarcados baseados em Linux. O agente malicioso é escrito principalmente em C e pode ser compilado para 17 arquiteturas de processadores. Entre elas estão ARM, ARM64, MIPS, MIPSEL, MIPS64, x86_64, PowerPC e RISC-V, além de outras plataformas utilizadas em equipamentos IoT. Essa compatibilidade amplia o número potencial de dispositivos que podem ser incorporados à botnet. Depois de identificar a arquitetura do equipamento comprometido, a infraestrutura pode disponibilizar pela internet o binário apropriado para aquele processador. Além do agente instalado nos dispositivos, a plataforma reúne um servidor de comando e controle escrito em Go, um painel para comercialização de ataques DDoS, uma máquina virtual personalizada para execução de exploits, ambientes de teste baseados em Docker e um sistema automatizado de compilação e implantação. O material recuperado pelos pesquisadores incluía o código-fonte completo, binários compilados, configurações de Docker Compose, ambientes de emulação QEMU e 254 relatórios automatizados de testes de desempenho de ataques DDoS. Força bruta testa 1.496 combinações de credenciais Uma das principais formas de propagação do TuxBot é o ataque de força bruta contra serviços Telnet expostos à internet. O malware possui uma lista com 1.496 combinações de nomes de usuário e senhas, incluindo credenciais padrão ou fracas frequentemente encontradas em dispositivos IoT. Quando encontra um equipamento acessível, o scanner tenta autenticar-se automaticamente utilizando essas combinações. Caso obtenha acesso, a botnet pode transferir e executar a versão do malware compatível com a arquitetura do dispositivo. O framework também inclui scanners para SSH, interfaces HTTP e Android Debug Bridge, conhecido como ADB. De acordo com a análise, esses quatro mecanismos estavam funcionais na versão examinada. O scanner HTTP consegue administrar até 128 conexões simultâneas para localizar painéis web vulneráveis. O TuxBot também contém códigos destinados a explorar vulnerabilidades conhecidas em mais de 30 famílias de dispositivos IoT. Essa parte da estrutura, porém, apresentava limitações. A máquina virtual personalizada para exploits não funcionava corretamente, o mecanismo principal de exploração não era chamado durante a execução e determinadas cargas maliciosas utilizavam configurações incompatíveis ou endereços de servidores desativados. C2 utiliza criptografia e cinco canais alternativos Depois da infecção, os dispositivos comprometidos tentam estabelecer comunicação com o servidor de comando e controle, chamado de C2. O canal principal utiliza TCP com criptografia baseada em X25519 e ChaCha20-Poly1305, dificultando a inspeção direta das instruções transmitidas entre o servidor e os bots. O TuxBot também possui uma arquitetura redundante de comunicação. Caso o canal principal deixe de funcionar, o malware pode recorrer a cinco mecanismos alternativos: um algoritmo de geração de domínios baseado em SHA-512, comunicação ponto a ponto, IRC, consultas DNS TXT e requisições HTTP periódicas. O algoritmo de geração de domínios, ou DGA, pode produzir 20 endereços por dia. Esse mecanismo permite que os operadores registrem novos domínios para recuperar o controle da botnet caso os servidores originais sejam bloqueados. Na comunicação P2P, comandos são distribuídos entre os dispositivos por um protocolo de propagação e assinados com Ed25519. A assinatura serve para que os bots verifiquem se as ordens foram emitidas pelo operador esperado. Nem todos os canais alternativos estavam operacionais. A Unit 42 constatou que os mecanismos baseados em IRC e HTTP apresentavam erros, enquanto o canal principal, o DGA, o P2P e parte dos demais métodos estavam funcionais. Painel oferece ataques DDoS como serviço O servidor C2 do TuxBot foi escrito em Go e utiliza três portas TCP para diferentes funções. A porta TCP 1999, ou 31337 dependendo da compilação, é usada para enviar comandos criptografados aos dispositivos infectados. A porta 2222 oferece uma interface SSH interativa para os operadores. Já a porta 9999 disponibiliza uma API baseada em JSON para acesso automatizado. O painel SSH permite visualizar a quantidade de dispositivos conectados e emitir comandos de ataque. O sistema também impõe limites por usuário, incluindo número de ataques simultâneos, duração máxima e quantidade de bots disponíveis. As contas, permissões e registros das operações são armazenados em um banco de dados MariaDB. Essa estrutura indica que o projeto foi planejado para funcionar como uma plataforma multiusuário de DDoS-as-a-Service, modelo no qual criminosos vendem ou alugam capacidade para derrubar sites, APIs, jogos e outros serviços online. Entre os recursos funcionais estavam ataques de inundação por UDP, TCP e DNS. O código também continha componentes parcialmente adaptados do MHDDoS, uma ferramenta aberta em Python para geração de tráfego DDoS. Ambiente de testes simulava jogos e serviços reais O TuxBot inclui uma infraestrutura de testes baseada em Docker, criada para avaliar os ataques antes de sua utilização em ambientes externos. Uma das configurações, chamada pelos desenvolvedores de “battle arena”, inicia um servidor C2, cinco réplicas de bots e um alvo executando nginx e listeners associados a serviços como Minecraft, TeamSpeak, FiveM e Xbox Live. Os 254 relatórios encontrados mostram testes de 12 métodos de ataque contra três hosts controlados. O sistema media indicadores como quantidade de pacotes por segundo, volume de tráfego e taxas de erro. Essas avaliações foram realizadas no início de janeiro de 2026, poucas semanas antes de uma amostra do TuxBot ser enviada ao VirusTotal em 20 de janeiro. O histórico do projeto indica que o desenvolvimento começou pelo menos em 3 de janeiro de 2025, quando o responsável clonou o repositório do MHDDoS no GitHub. Ao ser executado, o TuxBot segue uma sequência de inicialização destinada a garantir sua permanência no equipamento e reduzir a possibilidade de análise. O malware procura ferramentas de depuração e ambientes virtualizados, altera ou oculta o nome de seu processo e instala diferentes mecanismos de persistência. Entre eles estão serviços systemd, tarefas cron, scripts de inicialização e um processo watchdog que reinicia o bot caso ele seja interrompido. O malware também tenta encerrar processos pertencentes a outras famílias de botnets. Essa prática, comum entre ameaças voltadas para dispositivos IoT, impede que concorrentes consumam os recursos de processamento, memória e largura de banda do mesmo equipamento. Depois disso, o TuxBot inicializa scanners, módulos DDoS, canais alternativos de C2, um proxy SOCKS5 e um componente reservado para mineração de criptomoedas. Na amostra analisada, contudo, a função de mineração era apenas um placeholder e não estava operacional. Um dos elementos mais incomuns encontrados pela Unit 42 foi a presença de extensos comentários produzidos pelo modelo de linguagem durante o desenvolvimento. Os arquivos continham explicações sobre decisões de programação, interrupções no raciocínio e referências ao “usuário”, termo utilizado pela IA para descrever a pessoa que enviava os comandos. Esses registros apareceram principalmente durante tarefas de adaptação de módulos e conversão de código entre linguagens. Todos os aproximadamente 60 arquivos em C do diretório principal também continham um aviso informando que o código era destinado a pesquisas educacionais e autorizadas e que seu uso indevido poderia ser ilegal. O texto provavelmente foi acrescentado automaticamente pelo modelo e não foi removido pelo desenvolvedor. Em outro caso, o código afirmava implementar o algoritmo Argon2id para proteção de senhas. A função, entretanto, utilizava operações baseadas em SHA-256 e PBKDF2, mas formatava o resultado para que parecesse uma saída Argon2id. Os pesquisadores também encontraram chaves XOR incompatíveis, erros na máquina virtual de exploits, componentes que nunca eram chamados e problemas nos canais de comunicação. A aparência organizada do código pode ter contribuído para que o responsável confiasse no conteúdo gerado sem realizar uma auditoria adequada. Apesar das falhas, a Unit 42 conseguiu corrigir alguns dos problemas com poucos comandos direcionados a outro modelo de linguagem. Isso indica que os operadores também poderiam aprimorar rapidamente a plataforma. A investigação relacionou a infraestrutura do TuxBot a ferramentas associadas ao ecossistema Keksec, conhecido por operar diferentes variantes de botnets IoT simultaneamente. Um dos servidores de comando e controle foi identificado no endereço 209.182.237[.]133, hospedado em Singapura. A porta 2222 apresentava uma identificação compatível com o servidor SSH personalizado do painel de controle e foi observada pela primeira vez em 5 de março de 2026. Outro endereço, 185.10.68[.]127, hospedava os binários utilizados para infectar diferentes arquiteturas. O mesmo servidor também distribuía amostras do Kaitori v3.9, variante associada às famílias Tsunami, Mirai e Gafgyt. A Unit 42 também encontrou conexões com ferramentas AISURU. Embora TuxBot, Kaitori e AISURU sejam bases de código distintas, elas convergiam para a mesma infraestrutura de distribuição, o que sugere a atuação de um mesmo operador ou de agentes pertencentes ao mesmo ecossistema. O TuxBot incorpora características de diferentes botnets, incluindo Mirai, AISURU e uma linhagem chamada Wuhan, além de adaptar funcionalidades do MHDDoS. A proposta vai além de uma simples modificação do código do Mirai. O projeto adiciona comunicação C2 criptografada, geração automática de domínios, propagação P2P, múltiplos scanners, uma máquina virtual para exploits e um painel comercial de ataques DDoS. Apesar das falhas, os componentes essenciais já permitem localizar dispositivos vulneráveis, testar credenciais fracas, manter persistência e utilizar os equipamentos comprometidos em ataques de negação de serviço. A Unit 42 identificou seis novas amostras em sua telemetria interna em abril de 2026, compiladas para múltiplas arquiteturas e aparentemente mais próximas de versões de produção. A atividade indica que o projeto não ficou restrito a um ambiente experimental. Para empresas e provedores, a descoberta destaca o risco representado por roteadores, câmeras, dispositivos Android e equipamentos embarcados expostos diretamente à internet. Credenciais padrão, serviços administrativos acessíveis externamente e firmware desatualizado continuam oferecendo meios eficientes para a formação de botnets. A adoção de IA também pode reduzir o esforço necessário para que um único desenvolvedor combine recursos anteriormente encontrados apenas em projetos mantidos por equipes maiores. Ao mesmo tempo, o TuxBot demonstra que código gerado por modelos de linguagem pode conter falhas graves quando utilizado sem revisão técnica.

A Zoom lançou atualizações de segurança para corrigir uma vulnerabilidade crítica em seus aplicativos para Windows que poderia permitir o sequestro de contas sem exigir autenticação prévia do invasor. Identificada como CVE-2026-53412, a falha recebeu pontuação 9,8 de 10 no sistema CVSS, classificação que indica risco crítico. O problema afeta o Zoom Desktop Client para Windows, o Zoom VDI Client para Windows e o Zoom Meeting SDK para Windows. Segundo o boletim de segurança ZSB-26014, publicado pela Zoom em 14 de julho de 2026 e atualizado no dia seguinte, a vulnerabilidade está relacionada à validação inadequada de dados de entrada. Um atacante não autenticado poderia explorar o problema por meio de acesso à rede e assumir o controle da conta de uma vítima. A empresa não detalhou publicamente a cadeia completa de exploração, os pacotes de rede envolvidos ou as ações que poderiam ser realizadas após o comprometimento. Ainda assim, o fato de a falha poder ser explorada remotamente, sem credenciais válidas, contribui para a pontuação elevada e aumenta a necessidade de atualização imediata dos ambientes afetados. Em um cenário corporativo, o comprometimento de uma conta do Zoom pode expor reuniões, contatos, mensagens, gravações, arquivos compartilhados e informações internas, dependendo das permissões atribuídas ao usuário e dos recursos habilitados pela organização. Contas privilegiadas ou vinculadas a integrações empresariais podem representar um risco ainda maior. Além da CVE-2026-53412, o pacote de segurança corrige outras três vulnerabilidades classificadas como de alta gravidade e relacionadas principalmente à elevação local de privilégios em sistemas Windows. A CVE-2026-53411, com pontuação CVSS 7,8, afeta o Zoom Workplace VDI Plugin para Windows em versões anteriores à 6.6.14. A falha também decorre de validação inadequada de entrada e pode permitir que um usuário autenticado aumente seus privilégios por meio de acesso local ao computador. A exploração de vulnerabilidades desse tipo normalmente depende de algum nível inicial de acesso à máquina, mas pode permitir que uma conta com permissões limitadas execute operações reservadas a usuários mais privilegiados. Em ataques reais, esse tipo de falha pode ser utilizado como uma etapa posterior ao comprometimento inicial. Já a CVE-2026-53410, avaliada com CVSS 7,0, consiste em uma condição de corrida do tipo time-of-check to time-of-use, conhecida pela sigla TOCTOU. O problema ocorre quando um sistema verifica determinada condição, como permissões ou integridade de um arquivo, mas o recurso é alterado antes de ser efetivamente utilizado. Nesse caso, a vulnerabilidade está presente nos processos de instalação e desinstalação de determinados clientes Zoom para Windows. Um usuário local autenticado poderia explorar o intervalo entre a verificação e o uso do recurso para elevar seus privilégios no sistema. A CVE-2026-53410 afeta os seguintes produtos e versões: Zoom Workplace para Windows anterior à versão 7.0.5; Zoom Workplace VDI Client para Windows anterior às versões 6.5.17 e 6.6.14, dentro de suas respectivas ramificações; Zoom Workplace VDI Plugin para Windows anterior às versões 6.5.17 e 6.6.14, dentro de suas respectivas ramificações; Zoom Rooms para Windows anterior à versão 7.0.5; Remote Control for Zoom Contact Center para Windows anterior à versão 7.0.0. A terceira falha de alta gravidade, CVE-2026-53409, recebeu pontuação CVSS 7,8 e afeta o Zoom Rooms para Windows em versões anteriores à 7.1.0. O problema está relacionado ao gerenciamento inadequado de privilégios e pode permitir que um usuário autenticado eleve suas permissões por meio de acesso local. Os boletins referentes às CVEs 2026-53409, 2026-53410 e 2026-53411 também foram publicados pela Zoom em 14 de julho de 2026, sob os identificadores ZSB-26011, ZSB-26012 e ZSB-26013. A presença das vulnerabilidades em clientes VDI e no Zoom Rooms amplia a relevância das correções para empresas que utilizam ambientes virtuais, salas de reunião compartilhadas e terminais administrados centralmente. Em infraestruturas VDI, aplicações e desktops podem ser disponibilizados remotamente para diversos usuários. Uma falha de elevação de privilégios nesse contexto pode facilitar movimentação dentro do ambiente virtual, comprometimento de sessões ou acesso indevido a recursos corporativos, dependendo da arquitetura e das demais medidas de proteção implementadas. Equipamentos com Zoom Rooms também costumam permanecer conectados à rede empresarial e podem ser utilizados por vários funcionários. Por isso, a atualização desses dispositivos deve fazer parte do processo corporativo de gestão de vulnerabilidades, mesmo quando eles não são tratados como estações de trabalho convencionais. Até a divulgação dos boletins, não havia indicações públicas de que as quatro vulnerabilidades estivessem sendo exploradas em ataques reais. A ausência de exploração conhecida, no entanto, não elimina o risco, especialmente após a publicação dos identificadores CVE e das versões vulneráveis. Administradores devem atualizar os aplicativos afetados para as versões mais recentes disponibilizadas pela Zoom, verificar a cobertura dos sistemas de distribuição de software e confirmar se clientes VDI, plugins, salas de reunião e componentes do Zoom Contact Center foram incluídos no processo. Organizações também podem acompanhar logs de autenticação e atividades anormais em contas do Zoom, revisar sessões ativas e avaliar as permissões atribuídas a usuários e integrações. Como a CVE-2026-53412 permite, segundo a empresa, a tomada de contas por acesso à rede, a instalação da correção é a principal medida para eliminar a vulnerabilidade.

Uma vulnerabilidade ainda sem correção em aspiradores robôs da Shark pode permitir que invasores controlem dispositivos de outros usuários na mesma região da AWS, acessem a câmera embarcada, movimentem o robô, leiam o mapa da residência e obtenham a senha da rede Wi-Fi em texto claro. A falha foi divulgada pelo pesquisador que publica sob o nome tokay0, que afirma ter testado o método apenas contra aspiradores comprados por ele. Segundo o pesquisador, a SharkNinja, empresa responsável pelas marcas Shark e Ninja, recebeu o relatório técnico em março, mas a vulnerabilidade continuava sem correção quando os detalhes foram publicados. O problema está relacionado à forma como certificados de dispositivos eram autorizados no ambiente de nuvem usado pela Shark. Em vez de limitar o certificado ao próprio aspirador que o possuía, a política associada permitia publicar e assinar mensagens destinadas a outros dispositivos atendidos pelo mesmo broker de nuvem. Na prática, isso transforma certos certificados em uma espécie de chave de acesso regional. Ao extrair o certificado de um Shark RV2320EDUS e apresentá-lo ao broker da Shark na AWS, o pesquisador conseguiu interagir com tópicos de outros aspiradores na mesma região, sem explorar corrupção de memória, sem escalar privilégios no sistema remoto e sem adivinhar senhas. O ataque explora um erro de autorização em infraestrutura IoT. Em arquiteturas baseadas em AWS IoT, cada dispositivo se comunica com a nuvem por meio de tópicos MQTT e documentos de estado conhecidos como device shadows. Esses documentos armazenam informações de estado e comandos que podem ser sincronizados entre o dispositivo físico e a nuvem. No caso analisado, o comando executado no aspirador é enviado como um campo comum dentro do shadow do dispositivo. O campo, chamado Exec_Command, é lido pelo daemon de gerenciamento appd e repassado para uma função chamada execute_command. Essa função executa comandos de até 1.000 bytes por meio de popen, uma chamada que permite iniciar processos no sistema operacional. Com isso, basta publicar uma atualização de shadow contendo o campo Exec_Command no tópico de um dispositivo vulnerável. Se aquele modelo implementar o manipulador do comando, o aspirador executa a instrução recebida. Segundo tokay0, o certificado pode ser extraído com acesso físico simples ao dispositivo. No modelo Shark RV2320EDUS, a placa principal expõe pinos UART, o console U-Boot não exige senha e a modificação dos argumentos de inicialização com init=/bin/sh permite obter um shell root. A partir desse acesso local, o pesquisador encontrou a chave e o certificado do dispositivo armazenados como arquivos comuns no diretório /mnt/res/vapp/certs/. Depois de obter o certificado, ele se inscreveu no tópico $aws/things/# e passou a observar o tráfego que circulava pelo broker, coletando números de série dos aspiradores conectados. O mesmo mecanismo permitia publicar mensagens para outros dispositivos. A limitação mais relevante identificada foi regional. Os certificados são vinculados à região AWS em que foram provisionados. Assim, uma chave extraída em uma região permite alcançar dispositivos daquela mesma região, mas não aspiradores conectados a outras regiões. Para atingir outra região, seria necessário obter um certificado provisionado ali e associado à mesma política excessivamente permissiva. O tipo de falha descrito pelo pesquisador corresponde a um problema conhecido em ambientes AWS IoT. O AWS IoT Device Defender, serviço de auditoria de frotas IoT da Amazon, possui uma verificação específica para políticas que concedem permissões amplas demais para publicar ou assinar tópicos como $aws/things/*. A checagem aparece como IOT_POLICY_OVERLY_PERMISSIVE_CHECK e é classificada como crítica pela AWS. A documentação da Amazon alerta que um certificado comprometido com esse tipo de política pode permitir que um invasor leia ou modifique shadows, jobs ou execuções de jobs de todos os dispositivos cobertos pela permissão. A mitigação recomendada pela AWS é restringir a política ao próprio dispositivo conectado, usando variáveis como ${iot.Thing.ThingName}. Dessa forma, um aspirador só poderia publicar e assinar tópicos relacionados à sua própria identidade, e não interagir com toda a frota. No caso da Shark, o problema não está necessariamente em todos os certificados. A análise indica uma diferença importante entre dispositivos que funcionam como “chave” e dispositivos que funcionam como “alvo”. Um aspirador cujo certificado possui a política incorreta pode ser usado por um invasor para acessar outros dispositivos na mesma região. Já qualquer aspirador que implemente o campo Exec_Command pode ser alvo da execução remota de comandos, mesmo que seu próprio certificado esteja configurado corretamente. Tokay0 comprovou essa condição ao usar o certificado extraído de um RV2320EDUS para comprometer um AV1102ARUS adquirido por ele como alvo. O certificado do AV1102ARUS estava restrito corretamente e não permitia assinatura curinga de tópicos, mas o firmware do modelo ainda executava comandos recebidos via Exec_Command. Com essa cadeia, o pesquisador obteve uma reverse shell no aspirador alvo e acessou um feed ao vivo da câmera embarcada enquanto o robô se movimentava pelo ambiente. O título da publicação original menciona milhões de dispositivos, mas os dados verificados pelo pesquisador são mais específicos. Durante 24 horas de observação em uma única região AWS, tokay0 contou 1.517.605 números de série únicos de aspiradores Shark. Desse total, 673.816 dispositivos, cerca de 44%, emitiram uma resposta Exec_Response, interpretada por ele como confirmação de que o dispositivo executa o manipulador de comandos. Esses números não significam que todos os aparelhos tenham sido testados ou comprometidos. Eles representam dispositivos observados respondendo no ambiente monitorado. O pesquisador afirma que o número real de aparelhos afetados pode ser maior, já que a medição ficou limitada a uma região e a uma janela de 24 horas. A combinação de câmera, mapeamento residencial, controle remoto e exposição de senha Wi-Fi torna a falha particularmente sensível do ponto de vista de privacidade. Aspiradores robôs modernos podem armazenar mapas internos das casas, rotas de limpeza, nomes de redes sem fio e dados operacionais usados pelo aplicativo do fabricante. Em um cenário de abuso, essas informações poderiam revelar detalhes sobre a residência, hábitos dos moradores e características da rede doméstica. A possibilidade de controlar o movimento do equipamento e acessar imagens ao vivo amplia o risco além de uma falha comum de dispositivo conectado. De acordo com a linha do tempo publicada por tokay0, o contato inicial com a SharkNinja ocorreu em 1º de março. Os detalhes técnicos foram enviados em 11 de março, e a empresa acusou recebimento no dia seguinte. Em 27 de abril, a SharkNinja informou que o relatório estava em análise. Em 3 de julho, segundo o pesquisador, a companhia disse que enviaria uma data confirmada de conclusão até sexta-feira, 10 de julho. Nenhum e-mail teria chegado. Tokay0 publicou os detalhes em 13 de julho. Ele afirma que a fabricante minimizou a gravidade do problema e questionou se a atribuição de um CVE seria apropriada. A política pública de divulgação de vulnerabilidades da SharkNinja afirma que a empresa fornecerá atualizações regulares até que uma falha reportada seja resolvida. A mesma política pede que pesquisadores mantenham sigilo até que a companhia confirme uma correção ou autorize a divulgação por escrito. Até a publicação do relato original, a SharkNinja não havia divulgado comunicado público sobre a falha. O The Hacker News informou que entrou em contato com a empresa para obter comentários sobre o status da correção e a linha do tempo de divulgação. Também não havia CVE atribuído à vulnerabilidade. Tokay0 disse ter solicitado um identificador à CNA of Last Resort da MITRE em 11 de junho, mas não recebeu retorno antes da publicação. Sem CVE, pontuação CVSS ou advisory oficial, equipes de gestão de vulnerabilidades ficam sem um identificador padronizado para rastrear o problema. Um ponto central da falha é que a correção principal não depende do usuário final nem exige, inicialmente, atualização de firmware no aspirador. A medida imediata está no ambiente AWS da SharkNinja. Segundo a orientação da AWS para esse tipo de problema, uma política não conforme pode ser substituída por uma versão mais restrita usando CreatePolicyVersion com o parâmetro setAsDefault, tornando a nova política padrão para todos os certificados que a utilizam. Essa mudança reduziria o alcance dos certificados excessivamente permissivos sem exigir uma atualização local nos robôs. A reemissão correta dos certificados, recomendada por tokay0 em março, seria uma etapa mais longa e estrutural. Enquanto a SharkNinja não aplicar uma dessas medidas, a única mitigação disponível para donos dos aspiradores é desconectar o equipamento da rede Wi-Fi. Isso impede controle pelo aplicativo, agendamentos e uso de mapas, fazendo o produto operar apenas como um aspirador comum. Tokay0 afirmou que não publicou seus scripts enquanto a falha permanece ativa. Ele também disse que outros achados eram menores e não justificavam uma publicação separada. O pesquisador não analisou o restante da linha conectada da SharkNinja, como grills inteligentes e termômetros sem fio para carne, mas afirmou que esses produtos também podem estar vulneráveis. Essa possibilidade não foi confirmada no material divulgado, mas indica que a exposição pode não se limitar aos aspiradores robôs se a mesma arquitetura de provisionamento e autorização tiver sido reutilizada em outros dispositivos IoT da empresa.