O Google vai encerrar o acesso da maioria dos usuários ao Gemini CLI, seu agente de desenvolvimento em linha de comando de código aberto, a partir de 18 de junho de 2026. A ferramenta será substituída pelo novo Antigravity CLI, apresentado pela empresa como uma forma de unificar seus esforços no desenvolvimento de interfaces de linha de comando para agentes de inteligência artificial. A mudança, no entanto, provocou forte reação entre desenvolvedores. O principal ponto de insatisfação é que o Gemini CLI era disponibilizado como projeto open source, enquanto o Antigravity CLI, pelo menos até o momento, não recebeu o mesmo tratamento. Na prática, usuários gratuitos, assinantes dos planos Google AI Pro e Ultra e aqueles que utilizam o Gemini Code Assist para indivíduos perderão acesso ao Gemini CLI e às extensões de IDE associadas à ferramenta. Em comunicado sobre a transição, a equipe do Gemini CLI informou que, em 18 de junho de 2026, o Gemini CLI e as extensões Gemini Code Assist para IDEs deixarão de atender solicitações desses grupos de usuários. A mudança também afeta o Gemini Code Assist para GitHub, que deixará de aceitar novas instalações na mesma data e encerrará o atendimento a solicitações nas semanas seguintes. Clientes corporativos, porém, não serão afetados da mesma forma. Segundo o Google, usuários que acessam o Gemini CLI ou suas extensões de IDE por meio de licenças Gemini Code Assist Standard ou Enterprise continuarão com acesso normal. O mesmo vale para usuários do Gemini Code Assist para GitHub que utilizam as ferramentas por contas corporativas do Google Cloud. O Google também afirmou que o Gemini CLI continuará acessível por meio de chaves pagas das APIs Gemini e Gemini Enterprise Agent Platform. Para a maioria dos usuários, contudo, a alternativa será migrar para o Antigravity CLI, mesmo sem garantia de paridade total de recursos no lançamento. A empresa reconheceu que não haverá equivalência “1:1” entre Gemini CLI e Antigravity CLI logo no início da transição. Segundo o Google, o novo CLI terá suporte, desde o lançamento, a recursos como agent skills, hooks, subagents e extensões. Outros recursos, no entanto, poderão levar mais tempo para chegar ou não serem incorporados. O argumento central do Google para a mudança é que o Antigravity CLI oferece melhor suporte a ambientes multiagente. Esse tipo de arquitetura permite que diferentes agentes de IA executem tarefas especializadas, cooperem entre si e atuem em fluxos de desenvolvimento mais complexos. Ainda assim, a forma como a migração está sendo conduzida gerou críticas, principalmente porque muitos usuários não terão opção prática de permanecer no Gemini CLI sem pagar por acesso corporativo ou por chaves de API. A diferença de abertura entre as duas ferramentas ficou evidente nas páginas dos projetos no GitHub. O repositório do Gemini CLI disponibiliza o código que sustentava a ferramenta, em linha com sua natureza de projeto open source. Já a página do Antigravity CLI exibe apenas um changelog, um arquivo README e um GIF demonstrando a aparência da ferramenta. Até o momento descrito no texto original, o código-fonte do Antigravity CLI não havia sido publicado. Essa ausência alimentou acusações de que o Google estaria encerrando, para a maioria dos usuários, uma ferramenta aberta que recebeu contribuições da comunidade, ao mesmo tempo em que direciona os desenvolvedores para uma alternativa fechada. Em discussões no GitHub, usuários também criticaram aparentes limites de uso do Antigravity CLI, com relatos de pessoas que teriam atingido sua cota semanal após poucas solicitações. A página de issues do Antigravity CLI também recebeu várias publicações pedindo que o Google investigasse os limites de uso. Outras mensagens expressam frustração com a percepção de que contribuições open source teriam ajudado a melhorar um produto que agora estaria sendo substituído por uma solução menos transparente. Também houve críticas mais amplas ao histórico do Google de encerrar produtos e serviços utilizados por comunidades de desenvolvedores. Dmitry Lyalin, gerente de produto líder do Gemini CLI, publicou informações adicionais no GitHub sobre a migração forçada para a nova ferramenta. Em sua mensagem, ele destacou que o projeto Gemini CLI continuará disponível para a comunidade como um repositório licenciado sob Apache 2.0, sem mudanças no código aberto já publicado. Lyalin também afirmou que a equipe continuará trabalhando no GitHub para manter o Gemini CLI atualizado com novos lançamentos de modelos, correções de bugs e atualizações de segurança voltadas a clientes corporativos. A declaração, no entanto, reforça a divisão entre usuários comuns, que serão empurrados para o Antigravity CLI, e clientes empresariais ou usuários pagantes de API, que poderão continuar usando o Gemini CLI. A decisão ocorre em um momento em que ferramentas de IA para desenvolvimento de software estão se tornando parte central do fluxo de trabalho de programadores. CLIs com agentes de IA ganharam relevância porque permitem interações rápidas diretamente no terminal, automatizando tarefas como geração de código, análise de arquivos, execução de comandos, revisão de alterações e integração com repositórios. Por isso, mudanças de acesso, licenciamento e transparência tendem a gerar impacto direto na confiança da comunidade técnica. No caso do Gemini CLI, a insatisfação não se limita à troca de nome ou interface. O debate envolve governança de projetos open source, dependência de fornecedores, continuidade de ferramentas de desenvolvimento e os limites entre produtos comunitários e ofertas comerciais. Para desenvolvedores que integraram o Gemini CLI aos seus fluxos de trabalho, a migração obrigatória pode significar ajustes técnicos, perda temporária de recursos e maior dependência de um produto sobre o qual há menor visibilidade. O Antigravity CLI poderá evoluir e entregar benefícios reais em ambientes multiagente, mas sua chegada começa cercada de resistência. A falta de paridade imediata com o Gemini CLI, os relatos sobre cotas de uso e a ausência de código-fonte aberto ampliam a percepção de que a transição favorece o controle comercial do Google em detrimento da abertura que havia caracterizado a ferramenta anterior.

A Embarcadero lançou o Kai, um assistente de inteligência artificial agêntica para o RAD Studio, ambiente de desenvolvimento integrado usado por programadores Delphi e C++ Builder. A novidade chega como uma extensão separada, o que significa que o RAD Studio, por padrão, continua sem recursos nativos de IA incorporados diretamente à IDE. O Kai adiciona funcionalidades como chat, preenchimento de código e um servidor MCP, sigla para Model Context Protocol, permitindo que outros agentes de IA se comuniquem com o ambiente de desenvolvimento. A ferramenta depende de grandes modelos de linguagem externos, que podem rodar na nuvem ou localmente, e exige que os usuários forneçam suas próprias chaves de API para utilizar os provedores de IA. Apesar dessa dependência de terceiros, o Kai é oferecido como produto por assinatura, com custo de US$ 249 por desenvolvedor ao ano. A Embarcadero também disponibiliza testes gratuitos para interessados em avaliar a extensão antes da contratação. O lançamento marca a entrada formal do ecossistema RAD Studio na corrida por recursos de IA dentro das ferramentas de desenvolvimento. Nos últimos anos, IDEs e editores de código passaram a incorporar assistentes capazes de sugerir trechos de programação, explicar erros, automatizar tarefas e interagir com projetos de software em linguagem natural. No caso do Kai, a proposta é levar essa dinâmica para uma base de desenvolvedores que ainda mantém aplicações Delphi e C++ Builder em ambientes corporativos, sistemas legados e soluções de alto desempenho. O Delphi, cuja linguagem também é conhecida como Object Pascal, tem uma trajetória longa no desenvolvimento de software. A versão 1.0 foi lançada em 1995 para Windows de 16 bits e, na época, foi considerada uma das ferramentas mais avançadas para desenvolvimento rápido de aplicações. O ambiente combinava um designer visual de formulários por arrastar e soltar, semelhante ao Microsoft Visual Basic, com um compilador de código nativo. Diferentemente do VB, os executáveis gerados pelo Delphi não dependiam de um mecanismo de runtime separado. O C++ Builder chegou posteriormente com o mesmo conceito de designer visual, mas utilizando C++ em vez de Object Pascal. A combinação de interface visual, compilação nativa e produtividade tornou as duas ferramentas populares em aplicações desktop Windows, especialmente em cenários em que desempenho e facilidade de distribuição eram pontos relevantes. Segundo Stephen Ball, diretor de pré-vendas da Embarcadero, a permanência do Delphi após mais de 30 anos está ligada justamente à sua capacidade de gerar código nativo totalmente compilado. Ele afirmou que há softwares escritos na plataforma executando partes centrais de sistemas de bolsas de valores e ambientes de negociação de alta frequência, onde velocidade, desempenho e uso eficiente de threads são requisitos essenciais. Ball também destacou que alguns clientes estariam cansados de aplicações híbridas que consomem muita memória e energia. Essas características continuam sendo os principais argumentos em favor do Delphi, sobretudo para aplicações desktop Windows. Ainda assim, a linguagem ocupa atualmente um nicho pequeno do mercado. De acordo com a pesquisa mais recente do Stack Overflow citada no texto original, ela é utilizada por 2,5% dos desenvolvedores, número suficiente para manter uma base viável, mas distante do uso massivo de linguagens mais populares. A versão atual do RAD Studio é a 13.1 e inclui suporte a binários nativos para Windows em Arm. Desenvolvedores que não utilizam Delphi há muitos anos ainda encontrarão um ambiente familiar, mas a plataforma evoluiu significativamente desde seus primeiros lançamentos. Entre as mudanças estão o FireMonkey, framework multiplataforma para Windows, macOS, iOS, Android e Linux, uma IDE real de 64 bits, suporte a telas de alta densidade de pixels, além de novos recursos de linguagem, como inferência de tipos, variáveis locais inline e operadores ternários. No C++ Builder, o compilador passou a ser baseado no Clang 20. Apesar da evolução, a compatibilidade retroativa continua sendo um ponto forte. Segundo o relato, códigos Delphi legados tendem a rodar com poucos ajustes, o que ajuda a explicar a permanência da tecnologia em organizações com aplicações críticas ou sistemas desenvolvidos ao longo de muitos anos. O Kai surge como uma resposta ainda relativamente minimalista à pressão do mercado por recursos de IA dentro das IDEs. Após a instalação da extensão e a ativação de uma assinatura, o desenvolvedor passa a contar com opções para configurar modelos voltados ao chat agêntico e ao preenchimento de código. As sugestões podem aparecer como “ghost text” diretamente no editor, aceitas pela tecla Tab, como itens em uma lista de autocompletar ou em um painel separado. O chat do Kai é aberto e pode gerar código, resolver erros de compilação, gerenciar controle de versão, executar operações em arquivos e interagir com outros servidores MCP. Na prática, a extensão tenta transformar a IDE em um ambiente mais conectado a fluxos modernos de desenvolvimento assistido por IA, nos quais o programador delega tarefas específicas ao assistente, mas mantém a revisão e a decisão final sobre o código produzido. Uma avaliação inicial da ferramenta apontou resultados mistos. A possibilidade de configurar o Kai para trabalhar com provedores locais de LLM foi considerada um ponto positivo, com suporte a Ollama e LM Studio. Essa opção pode ser relevante para desenvolvedores e empresas que preferem manter parte do processamento em ambiente local, seja por controle, privacidade ou restrições internas. No entanto, o uso de modelos locais exige computadores potentes e bastante memória RAM, especialmente quando o objetivo é executar modelos maiores com desempenho aceitável. Também foram observadas limitações. Uma consulta que funcionou diretamente no chat do LM Studio apresentou erro ao ser executada pelo chat do Kai. Em outro teste, ao solicitar código para uma função de conversão sem especificar a linguagem, o Kai, usando um modelo local, retornou uma implementação em Python, em vez de Delphi ou C++. A questão da disponibilidade de dados de treinamento para Delphi também foi levantada. Marco Cantu, gerente de produto do Delphi, reconheceu que o status de nicho da linguagem já gerou problemas, incluindo casos em que modelos de IA produziam código no estilo antigo do Delphi 7, lançado em 2002, sem aproveitar recursos mais recentes da linguagem. Segundo ele, porém, a situação melhorou. Cantu afirmou que atualmente a maioria dos grandes modelos de linguagem consegue gerar código Delphi com bom nível de qualidade. Ele também lembrou que o Kai atende tanto Delphi quanto C++ Builder, e que, no caso de C++, os modelos tendem a apresentar desempenho ainda melhor, devido à maior disponibilidade de dados e exemplos públicos da linguagem. Sobre mecanismos de proteção contra riscos como prompt injection ou uso indevido do assistente, Cantu afirmou que a Embarcadero parte do pressuposto de que os clientes usarão o Kai em um contexto no qual humanos revisam o código e verificam o que está sendo feito. A declaração indica que a ferramenta foi desenhada para atuar como apoio ao desenvolvimento, não como substituta do processo de revisão técnica, validação de segurança e controle de qualidade. Esse ponto é relevante porque assistentes de IA integrados a IDEs ampliam a superfície de risco no ciclo de desenvolvimento. Quando uma ferramenta consegue interagir com arquivos, gerar código, manipular projetos, acessar sistemas de controle de versão ou se conectar a outros agentes, falhas de contexto, comandos mal interpretados ou entradas maliciosas podem causar impactos no fluxo de trabalho. No caso do Kai, o texto original não aponta incidentes específicos, mas mostra que a responsabilidade pela revisão humana permanece central. A recepção da comunidade também foi mista. Durante um webinar de apresentação, alguns participantes defenderam que o Kai deveria estar incluído gratuitamente nas assinaturas do RAD Studio ou do Delphi, já que depende de LLMs externos e exige chaves de API próprias dos usuários. Outros consideraram o valor anual de US$ 249 razoável, especialmente se a ferramenta economizar tempo de desenvolvimento. Também houve quem argumentasse que a Embarcadero deveria concentrar esforços em melhorias no núcleo do RAD Studio, em vez de adicionar recursos de IA. Outra visão apresentada é que o próprio RAD Studio talvez não precise do Kai para todos os perfis de desenvolvedores. Um programador afirmou que, em seu fluxo atual, costuma abrir a IDE Delphi apenas quando precisa ajustar arquivos DFM, os Delphi Form Modules, enquanto cerca de 90% do trabalho de desenvolvimento acontece em interfaces de linha de comando como Claude Code e Codex CLI. Essa percepção reflete uma mudança mais ampla no desenvolvimento de software, em que agentes de IA e ferramentas por linha de comando começam a reduzir a dependência de IDEs tradicionais em algumas etapas do processo. Mesmo com limitações, o Kai representa um movimento importante da Embarcadero para aproximar o RAD Studio das práticas contemporâneas de desenvolvimento assistido por IA. A ferramenta ainda parece estar em evolução, mas indica que Delphi e C++ Builder também passam a fazer parte do debate sobre codificação agêntica, automação de tarefas e integração entre IDEs e modelos de linguagem. A avaliação inicial sugere que o Kai ainda precisa amadurecer, especialmente em estabilidade, precisão contextual e alinhamento com as linguagens usadas no RAD Studio. Ao mesmo tempo, o lançamento serve como lembrete de que o Delphi continua sendo uma opção relevante para aplicações gráficas de alto desempenho, com implantação simples e código nativo, mesmo ocupando uma fatia pequena do mercado moderno de desenvolvimento.

A e-Core, em parceria com a Rapid7, Atlassian e SUCESU-SP, reuniu executivos de tecnologia, cibersegurança, governança, riscos e operações em um jantar exclusivo realizado no NB Steak JK, em São Paulo. O encontro teve lotação máxima e foi direcionado a um tema que vem ganhando prioridade nas organizações: como conectar a visibilidade real da superfície de ataque à correção de vulnerabilidades, com integração ao CMDB e aos fluxos automatizados de ITSM. A discussão central partiu de uma dor comum em grandes ambientes corporativos. Muitas empresas já possuem ferramentas de descoberta de ativos, scanners de vulnerabilidades, plataformas de ITSM, soluções de endpoint, inventários, CMDBs e processos de governança. O problema, no entanto, está na fragmentação dessas camadas. Ativos aparecem duplicados, vulnerabilidades são tratadas sem contexto de negócio, chamados são abertos sem priorização adequada e equipes de segurança e TI acabam atuando em meio a ruídos operacionais. Durante a apresentação, Clayton Oliveira, da e-Core, destacou que o mercado está passando por uma mudança importante na forma de tratar cibersegurança. A segurança deixou de ser uma disciplina isolada entre times de cloud, infraestrutura on-premises, DevOps e operações para se tornar uma camada integrada à governança, risco, compliance e continuidade do negócio. Segundo ele, organizações que não acompanharem esse movimento tendem a enfrentar dificuldades para responder à expansão da superfície de ataque e ao aumento da complexidade operacional. Um dos pontos abordados foi o crescimento da exposição digital das empresas. A superfície de ataque não necessariamente passou a existir apenas agora, mas se tornou mais visível com a maturidade das ferramentas de descoberta, a expansão de ambientes híbridos e o uso crescente de inteligência artificial por empresas e também por agentes maliciosos. Nesse contexto, a apresentação reforçou uma premissa direta: não é possível proteger aquilo que não se conhece. Shadow IT, ativos desconhecidos, sistemas sem dono claro e ambientes distribuídos continuam sendo obstáculos relevantes para equipes de segurança. A proposta apresentada pela e-Core e Rapid7 busca justamente enfrentar esse desafio por meio de um ecossistema integrado. A abordagem combina CTEM, sigla para Continuous Threat Exposure Management, com recursos de Attack Surface Management, gestão de vulnerabilidades, varredura contínua, DAST e integração com plataformas de governança e ITSM. A ideia é consolidar dados de diferentes fontes, remover duplicidades, enriquecer o contexto dos ativos e alimentar o CMDB com informações mais confiáveis e atualizadas. Na prática, o modelo propõe transformar o CMDB em uma base viva, capaz de refletir continuamente o ambiente real da organização. Em muitas empresas, um mesmo notebook, servidor ou aplicação pode aparecer com identificadores diferentes em sistemas como EDR, Active Directory, ferramentas de inventário, sistemas operacionais e plataformas de gestão. Essa duplicidade dificulta a priorização e compromete a visibilidade. A integração apresentada busca correlacionar essas telemetrias para identificar quando diferentes registros representam o mesmo ativo, reduzindo inconsistências e melhorando a tomada de decisão. Outro ponto relevante da apresentação foi a integração entre segurança e fluxo operacional de correção. A partir da identificação de uma vulnerabilidade, a plataforma pode associar o achado ao ativo correto no CMDB, avaliar contexto, criticidade e impacto, abrir tickets em ferramentas como Jira Service Management e direcionar a demanda ao responsável adequado. Com isso, a área de segurança passa a acompanhar o ciclo de correção com rastreabilidade, enquanto TI recebe demandas mais qualificadas e conectadas ao risco real. A automação foi tratada como uma das principais alavancas para reduzir ruídos e acelerar respostas. Em determinados cenários, correções podem ser executadas por playbooks automatizados, com validação posterior para confirmar se a vulnerabilidade foi de fato corrigida. Caso a correção não seja efetiva, o fluxo pode reabrir ou escalar o chamado, evitando que vulnerabilidades críticas permaneçam sem tratamento adequado. Para casos mais sensíveis, a abordagem também prevê abertura de mudanças ou problemas, respeitando processos formais de governança e controle operacional. A apresentação também mencionou o uso de inteligência artificial para tornar a operação mais acessível a diferentes perfis de usuários. Profissionais de governança, risco ou áreas menos técnicas poderiam fazer perguntas em linguagem natural, como quais ativos possuem determinada vulnerabilidade, qual o impacto no ambiente ou quais sistemas estão conectados a um ativo específico. A partir da integração entre CMDB, telemetria e dados de segurança, a plataforma retornaria informações consolidadas, reduzindo a dependência de consultas técnicas complexas. Esse tipo de capacidade é especialmente importante em organizações nas quais a segurança precisa dialogar com múltiplas áreas. A visibilidade isolada de uma vulnerabilidade já não é suficiente. É necessário saber onde ela está, qual ativo é afetado, quem é o responsável, se existe exploração possível, quais sistemas dependem daquele ativo e qual o impacto para o negócio. Essa rastreabilidade permite que as equipes priorizem o que realmente importa, em vez de tratar listas extensas de vulnerabilidades apenas pela pontuação de severidade. A validação ofensiva também apareceu como um diferencial relevante. Segundo a abordagem apresentada, a identificação de uma vulnerabilidade pode ser combinada com testes conduzidos por equipes especializadas para verificar se a falha é explorável no ambiente do cliente. Quando a exploração é possível, a organização passa a receber uma evidência mais concreta do risco, incluindo o potencial caminho de ataque e o impacto que aquela vulnerabilidade pode gerar. Isso ajuda a transformar uma recomendação técnica em uma decisão de negócio mais clara. O evento também reforçou o papel da e-Core como integradora de tecnologia, processos e operação. A proposta não se limita à adoção de uma ferramenta específica, mas à construção de uma esteira capaz de conectar descoberta, inventário, priorização, abertura de chamados, automação, validação e governança. Ao lado da Rapid7, Atlassian e SUCESU-SP, a empresa posicionou a discussão em um ponto sensível para o mercado: a necessidade de reduzir o distanciamento entre o que a segurança identifica e o que a operação consegue corrigir. Para líderes de tecnologia e segurança, o tema tem impacto direto na gestão de risco. Quanto maior o volume de ativos, aplicações, integrações, ambientes cloud, sistemas legados e fornecedores, mais difícil se torna manter uma visão precisa da exposição. Sem integração, a empresa corre o risco de investir em ferramentas que geram alertas, mas não necessariamente reduzem o risco de forma mensurável. A conexão entre CTEM, CMDB e ITSM busca justamente transformar visibilidade em ação coordenada. O encontro realizado em São Paulo mostrou que a discussão sobre vulnerabilidades está deixando de ser apenas técnica. Ela envolve governança, eficiência operacional, automação, rastreabilidade, gestão de mudanças e priorização baseada em risco. Em um cenário no qual empresas precisam responder mais rápido, com equipes pressionadas e ambientes cada vez mais distribuídos, a integração entre e-Core, Rapid7 e Atlassian aponta para uma abordagem mais madura: corrigir melhor, com contexto, inteligência e menor ruído operacional.

Por Priscila Meyer — CEO da Eskive, especialista em segurança da informação com foco no risco humano A inteligência artificial virou parte do cotidiano profissional antes mesmo que muitas empresas tivessem tempo para processar como ela faria essa entrada. Agora, com poucos cliques, um colaborador resume um relatório, realiza pesquisas aprofundadas, revisa uma apresentação ou organiza ideias com a ajuda de uma ferramenta pública. A promessa é sedutora: menos tempo gasto com tarefas repetitivas e mais velocidade para entregar resultado. O problema é que essa eficiência, quando acontece fora de regras claras, também abre uma nova frente de exposição para o negócio. É aí que a Shadow AI deixa de ser curiosidade tecnológica e passa a ser um tema de risco corporativo. A conveniência que chega antes da governança Toda tecnologia de fácil adoção costuma seguir um roteiro parecido: primeiro aparece a utilidade, depois a dependência e, só então, a discussão sobre controle. Com a IA, esse ciclo ficou ainda mais curto. A barreira de entrada é baixa, a recompensa é imediata e a curva de aprendizado quase desaparece. Para quem está sob pressão de prazo, meta e volume, o atalho parece racional. O colaborador não se vê como alguém que está “furando” a política; ele se enxerga como alguém tentando trabalhar melhor. E é justamente por isso que o fenômeno se espalha com tanta rapidez. Shadow AI é isso: o uso de ferramentas, modelos ou recursos de IA sem aprovação formal da organização, fora das diretrizes internas ou sem supervisão adequada das áreas responsáveis por segurança, privacidade, tecnologia e compliance. Em outras palavras, não é apenas “usar IA”. É usar IA sem que a empresa saiba, aceite e consiga responder pelo uso. Esse movimento nasce como herdeiro direto do Shadow IT, mas carrega uma diferença importante: a IA não se limita a armazenar dados; ela interpreta contexto, recebe conteúdo sensível, pode registrar interações e, em alguns cenários, ampliar o alcance da exposição de forma impossível de se prever. O risco começa no prompt O ponto mais sensível não é a ferramenta em si. É o que vai para dentro dela. Quando alguém coloca um contrato, uma base de clientes, um documento interno, um trecho de código proprietário, uma estratégia comercial ou qualquer dado protegido em uma interface não homologada, a organização perde o controle sobre aquele conteúdo. Mesmo quando o fornecedor diz que protege os dados ou que não os usa para treinar modelos, continuam em aberto as perguntas: onde a informação é processada, quem pode acessá-la, por quanto tempo ela fica retida, se há registro de logs, quais terceiros participam do ecossistema e se tudo isso está alinhado às regras internas e às exigências regulatórias. Por que esse risco está aumentando? A Shadow AI cresce porque ela combina três ingredientes perigosos: facilidade, utilidade e invisibilidade. É fácil de acessar, útil no cotidiano e, muitas vezes, invisível para a segurança corporativa. Quando uma ferramenta entrega valor na primeira tentativa, ela se espalha por recomendação informal, por hábito e até por pressão social interna. Em pouco tempo, vira “o jeito normal” de fazer a tarefa. O problema é que, nesse estágio, a empresa pode já estar lidando com múltiplas soluções não-autorizadas, usadas por áreas diferentes, para finalidades diferentes e sem qualquer mapa claro do que está acontecendo. Esse cenário piora quando a cultura da organização valoriza velocidade acima de critérios. Se as lideranças perguntam apenas “quanto tempo você economizou?”, a resposta tende a ser “usei uma IA qualquer”. Se não houver um ambiente que valorize prudência, a improvisação vira padrão. E quando o improviso vira padrão, a exposição deixa de ser pontual e passa a ser estrutural. A importância da homologação Muita empresa reage ao tema com um reflexo defensivo: bloqueia ferramentas, proíbe usos ou publica uma norma genérica esperando que o problema desapareça. Não desaparece. Bloqueio isolado costuma empurrar o usuário para o caminho informal, sem resolver a causa. O que funciona é governança combinada com clareza. A organização precisa homologar as plataformas que considera aceitáveis, avaliar fornecedores, revisar contratos, testar controles, definir escopos de uso e separar o que é permitido do que é proibido. Sem isso, a empresa perde visibilidade e não consegue medir o tamanho real da exposição. Homologar também evita a fragmentação. Quando cada equipe escolhe sua própria ferramenta, o ambiente fica mais caótico, o suporte fica mais difícil e a resposta a incidentes fica muito mais lenta. Em um cenário assim, a pergunta deixa de ser “qual IA usamos?” e passa a ser “quantas IAs estão em uso sem que ninguém consiga responder com precisão?”. O que não se enxerga não se governa. E o que não se governa acaba governando a empresa por baixo, silenciosamente. Política interna não pode ser peça decorativa Uma política de uso seguro de IA precisa ser prática, inteligível e aplicável ao trabalho real. O colaborador precisa saber exatamente o que pode inserir em uma ferramenta, o que jamais deve ser compartilhado, quando o conteúdo precisa de revisão humana e em quais casos é obrigatório pedir autorização. Precisa ficar claro que dados confidenciais, credenciais, informações pessoais, segredos de negócio, documentos internos e material protegido por contrato não devem ser enviados a soluções não aprovadas. Essa política também precisa tratar dos usos mais comuns da IA no dia a dia: redação de e-mails, apoio a atendimento, geração de conteúdo, análise de dados, desenvolvimento de código e elaboração de apresentações. Cada um desses contextos tem suas próprias fragilidades. O mesmo vale para a revisão humana obrigatória. Uma resposta gerada por IA pode ser útil como rascunho, mas não pode substituir validação, critério e responsabilidade profissional. A diretriz precisa ser simples o suficiente para ser lembrada e específica o suficiente para ser seguida. Conscientização: a peça que evita o atalho perigoso Aqui está o ponto mais importante: nenhuma política funciona se as pessoas não entenderem o motivo por trás dela. Conscientização não é repetir proibições em uma apresentação anual. É conectar risco com rotina. É mostrar, com exemplos concretos, por que colar uma proposta comercial em um chatbot público pode expor a empresa, por que resumir uma reunião sigilosa em uma ferramenta não autorizada pode criar problema e por que “todo mundo usa” não é argumento de segurança. Esse trabalho precisa ser contínuo. Não basta uma campanha de lançamento e um e-mail de boas práticas. A equipe precisa de orientação recorrente, linguagem simples e cenários próximos da realidade. O funcionário deve entender não apenas o que é proibido, mas por que a decisão errada é arriscada, como identificar sinais de uso inadequado e onde buscar apoio. Quando a política conversa com a prática, a consciência deixa de ser abstrata e passa a orientar o comportamento. E a liderança tem papel decisivo nisso. Se a gestão só cobrar produtividade, a equipe vai procurar atalhos. Se gestores reforçam que rapidez sem controle também custa caro, a cultura muda. A conscientização precisa alcançar quem toma decisão, quem aprova processos e quem modela o comportamento esperado. Segurança não se sustenta apenas na base; ela depende do exemplo de cima. Inovação sem disciplina vira exposição No fim, a Shadow AI não é um modismo passageiro. É o sintoma de uma transformação real na forma de trabalhar. A IA vai continuar avançando, e tentar expulsá-la do ambiente corporativo como se fosse um corpo estranho seria um erro. O caminho mais inteligente é outro: reconhecer o valor da tecnologia, mas enquadrá-la em regras, controles e hábitos seguros. A questão não é escolher entre inovação e proteção. É entender que inovação sem disciplina vira exposição, e exposição sem conscientização vira incidente. A Shadow AI cresce justamente onde a organização ainda acredita que uso fácil significa uso inofensivo. Não significa. O desafio, portanto, é menos tecnológico do que cultural: fazer com que a pressa não vença a política e que a conveniência não passe por cima da responsabilidade.

Hackers estão explorando ativamente uma vulnerabilidade crítica no Everest Forms Pro, plugin para WordPress usado em cerca de 4 mil instalações ativas, para executar código arbitrário e assumir o controle completo de sites vulneráveis. A falha, rastreada como CVE-2026-3300, recebeu pontuação CVSS 9.8, indicando severidade crítica. A vulnerabilidade afeta todas as versões do Everest Forms Pro até a 1.9.12, inclusive. A correção foi disponibilizada em 18 de março de 2026, com o lançamento da versão 1.9.13. Segundo a Wordfence, o problema está no recurso Calculation Addon, mais especificamente na função process_filter(), que concatena valores enviados por usuários em campos de formulário dentro de uma string de código PHP sem o tratamento adequado antes de repassá-la à função eval(). Na prática, isso significa que entradas fornecidas por visitantes do site podem ser interpretadas como código PHP pelo servidor. A Wordfence explicou que a função sanitize_text_field(), aplicada aos dados de entrada, não escapa aspas simples nem outros caracteres relevantes no contexto de código PHP. Com isso, atacantes não autenticados conseguem injetar e executar código arbitrário ao enviar valores especialmente criados em campos de texto, e-mail, URL, seleção ou radio button, desde que o formulário utilize o recurso “Complex Calculation”. A exploração bem-sucedida da CVE-2026-3300 pode permitir que invasores executem comandos PHP diretamente no servidor, criem contas administrativas falsas, implantem web shells e estabeleçam mecanismos de persistência para manter acesso ao ambiente comprometido. Em um site WordPress, esse tipo de falha pode resultar em controle total da aplicação, alteração de conteúdo, roubo de dados, redirecionamentos maliciosos e uso da infraestrutura para novas campanhas. De acordo com a Wordfence, os ataques começaram a ser observados em 13 de abril de 2026. Até o momento do relatório, mais de 29.300 tentativas de exploração contra a falha haviam sido bloqueadas. Desse total, 16 tentativas ocorreram nas últimas 24 horas analisadas pela empresa. O payload mais comum identificado nas tentativas de ataque buscava criar uma conta de administrador chamada “diksimarina”, associada ao endereço de e-mail “diksimarina@gmail.com”, nos sites comprometidos. Essa técnica é recorrente em ataques contra WordPress, pois permite que o invasor obtenha acesso persistente ao painel administrativo mesmo após a exploração inicial. As tentativas de exploração partiram dos endereços IP 202.56.2.126, 209.146.60.26, 15.235.166.18, 2402:1f00:8000:800::40db e 185.78.165.153, segundo os dados divulgados. Administradores de sites que utilizam o Everest Forms Pro devem verificar logs de acesso, revisar contas administrativas recém-criadas e garantir que o plugin esteja atualizado para a versão corrigida. A divulgação ocorre em meio a novos alertas sobre campanhas de skimmers digitais contra lojas online. A Sansec identificou múltiplas operações voltadas ao roubo de dados de cartão, incluindo uma campanha que abusa da infraestrutura da Stripe como servidor de comando e controle e também como canal para exfiltração de informações roubadas. Segundo a Sansec, os invasores tratam a Stripe como uma infraestrutura gratuita para armazenar dados roubados e hospedar partes do código do skimmer, aproveitando a boa reputação do domínio para escapar de regras de Content Security Policy e filtros de rede. Em muitos ambientes de e-commerce, domínios como api.stripe.com e googletagmanager.com são implicitamente confiáveis, o que facilita a passagem do tráfego malicioso. A campanha usa Google Tag Manager e domínios da Stripe. O código malicioso é carregado a partir de um contêiner do GTM e executado em todas as páginas que o incluem. Em páginas de checkout do Magento e do Adobe Commerce, o loader extrai um skimmer ofuscado armazenado no campo de metadados de uma conta de cliente da Stripe, identificada no relatório como “cus_TfFjAAZQNOYENR”. Depois de carregado, o skimmer coleta informações financeiras, endereços de cobrança, e-mails e números de telefone inseridos por usuários durante o processo de compra. Esses dados são armazenados temporariamente no localStorage do navegador e, em seguida, exfiltrados para a conta Stripe controlada pelo atacante. A Sansec afirmou que cada cartão roubado passa a ser registrado como um “cliente” na conta do invasor. Após o envio bem-sucedido, o loader remove a entrada do localStorage para evitar que o mesmo registro seja transmitido duas vezes. Posteriormente, o atacante pode listar os cartões roubados utilizando a mesma API e a mesma chave, transformando a base de clientes da Stripe em um repositório durável para dados exfiltrados. O registro da Stripe que continha o skimmer teria sido criado em 24 de dezembro de 2025, o que indica que a operação pode estar ativa desde então. A Sansec também identificou uma segunda variante do loader que utiliza o Google Firestore em vez da Stripe, mas com o mesmo objetivo: abusar de serviços confiáveis como canais encobertos de comunicação e armazenamento, reduzindo a chance de bloqueio por lojas virtuais. As descobertas coincidem com uma operação em larga escala chamada GorgonAgora, que usou um cluster de 5.714 lojas falsas com domínio “.shop” para se passar por marcas conhecidas como Starbucks, Ford, Sony, Mattel, Hasbro, Lego, Disney e Toyota. As páginas de checkout desses sites direcionavam dados de cartão roubados para um único servidor de skimmer localizado na Moldávia. A campanha está em andamento desde agosto de 2025. Segundo a Sansec, todas as lojas falsas utilizam a mesma stack de comércio Medusa.js e carregam o mesmo SDK de checkout personalizado, que renderiza um iframe falso da Stripe. A partir dele, os dados de cartão são exfiltrados por meio de um WebSocket criptografado para o servidor controlado pelos invasores. A operação também mantém um relay ativo de 3D Secure. Quando o banco da vítima retorna um desafio 3DS, o operador repassa esse desafio ao comprador por meio do iframe falso, permitindo que a transação seja concluída enquanto o roubo permanece menos perceptível para a vítima. Os casos mostram dois movimentos relevantes no cenário de ameaças contra aplicações web e e-commerce. De um lado, plugins vulneráveis do WordPress continuam sendo explorados como porta de entrada para controle de sites. De outro, grupos especializados em skimming estão abusando de serviços legítimos e amplamente confiáveis para hospedar código, comandar operações e armazenar dados roubados, dificultando a atuação de defesas baseadas apenas em reputação de domínio. Para administradores de WordPress, a prioridade é atualizar imediatamente o Everest Forms Pro para a versão 1.9.13 ou superior, revisar usuários administrativos, procurar web shells e verificar alterações recentes em arquivos do site. Para equipes responsáveis por e-commerce, é importante revisar integrações com GTM, Stripe e outros serviços externos, validar scripts carregados em páginas de checkout e monitorar comportamentos anômalos no localStorage, chamadas para APIs de terceiros e conexões WebSocket inesperadas.

O agente de ameaça conhecido como PCPJack sequestrou servidores em ambientes associados à Amazon Web Services, Google Cloud e Microsoft Azure para montar uma rede oculta de relay SMTP, usada para encaminhamento de e-mails por meio de infraestrutura comprometida. A descoberta foi divulgada pela Hunt.io, que identificou servidores empresariais comprometidos nos Estados Unidos, Europa e Ásia convertidos silenciosamente em proxies SMTP. Segundo a empresa de inteligência de ameaças, os servidores invadidos eram verificados quanto à capacidade de retransmitir e-mails e sincronizados com um consumidor downstream a cada cinco minutos. A infraestrutura ainda estava em operação quando foi encontrada pelos pesquisadores. A investigação ganhou força após o operador por trás da campanha deixar dois diretórios abertos, sem autenticação, em um servidor de comando e controle localizado em “213.136.80[.]73”. Nesses diretórios, a Hunt.io encontrou código-fonte, binários compilados, logs de estado de implantação, scanners de internet, ferramentas de exploração e uma configuração ativa do Sliver, framework de comando e controle usado em operações ofensivas. O PCPJack foi identificado pela primeira vez pela SentinelOne em abril de 2026, quando pesquisadores descobriram um framework de roubo de credenciais voltado especificamente para serviços em cloud. Na ocasião, a atividade também chamou atenção por tentar encerrar e remover processos ou artefatos associados ao TeamPCP, outro grupo hacker que ganhou visibilidade nos últimos meses por ataques à cadeia de suprimentos de software. Em um dos diretórios expostos, os pesquisadores encontraram um toolkit de implantação de proxies SMTP integrado ao Sliver, além de binários do Chisel, ferramenta usada para tunelamento e proxy, compilados para várias arquiteturas Linux, incluindo AMD64, ARM64 e x86. Nos sistemas das vítimas, o binário era instalado como um arquivo oculto com prefixo de ponto e persistia no caminho “/var/tmp/.xs”. Também foram encontrados scripts de implantação criados para carregar a configuração do cliente Sliver C2 e filtrar beacons Linux que haviam se comunicado com o servidor nos dez minutos anteriores. Em operações desse tipo, beacons são implantes que se conectam periodicamente ao servidor de comando e controle para informar que estão ativos e buscar novas instruções. De acordo com a Hunt.io, cada beacon recebia uma porta de proxy SOCKS5 derivada de forma determinística a partir de um hash MD5 do UUID do Sliver. Esse valor era mapeado dentro da faixa de portas 10000 a 14999. Com isso, o mesmo beacon sempre era associado à mesma porta em diferentes execuções, eliminando a necessidade de manter um registro compartilhado de portas. O script também executava uma etapa de validação de qualidade SMTP. Essa checagem testava se o host comprometido conseguia estabelecer comunicação de saída com “smtp.gmail[.]com:587”. Máquinas que falhavam nesse teste eram ignoradas com código de saída zero, indicando que não serviam ao objetivo da operação. Para a Hunt.io, esse mecanismo deixa clara a finalidade da campanha: servidores incapazes de retransmitir e-mails não tinham valor para a infraestrutura montada pelo PCPJack. Os beacons eram processados em lotes de 50, com espera de 25 minutos após uploads e 15 minutos após comandos de execução, para acomodar implantes configurados com intervalos lentos de comunicação com o C2. Versões posteriores dos scripts de implantação removeram tanto a validação SMTP quanto a lógica de processamento em lotes. Os pesquisadores também identificaram um script de diagnóstico que selecionava cinco beacons ativos e enviava comandos shell para verificar a presença de binários Chisel em caminhos conhecidos, confirmar se um processo Chisel estava em execução, avaliar espaço em disco, testar a conectividade com a porta 9000 no C2 e verificar artefatos de persistência, como entradas de cron ou serviços systemd. O servidor de comando e controle também executava um script Python chamado “chisel_verifier.py” como daemon persistente em segundo plano. Esse script enumerava portas de túneis Chisel ativas por meio do comando “ss -tlnp” a cada 60 segundos, testava cada nova porta quanto à capacidade de relay SMTP e removia túneis com falha ou indisponíveis do pool ativo. Os proxies verificados eram enriquecidos com informações como endereço IP de saída, país e ASN, usando serviços como “api.ipify[.]org” e “ip-api[.]com”. Em seguida, as listas de proxies eram sincronizadas a cada cinco minutos, por meio do protocolo SCP, com um servidor downstream separado em “38.242.204[.]245”. Esse servidor não estava acessível no momento da análise. O objetivo final da operação ainda não foi determinado. No entanto, a infraestrutura construída pelo PCPJack tinha capacidade clara de envio em escala, o que poderia ser usado para spam, phishing ou outras campanhas que dependem de retransmissão de e-mails por servidores com melhor reputação do que infraestruturas maliciosas tradicionais. A Hunt.io descreveu a campanha como oportunista e afirmou que o resultado observável foi uma rede com 230 nós. Ainda não é possível determinar, com base nos arquivos recuperados, se essa evolução representa a ação de um único operador ajustando a infraestrutura ao longo do tempo ou de múltiplos atores compartilhando o mesmo ambiente. A relevância do caso está no abuso de servidores cloud empresariais para criar uma camada de infraestrutura difícil de atribuir e bloquear. Ao transformar máquinas legítimas hospedadas em AWS, Google Cloud e Azure em proxies SMTP, os operadores podem se beneficiar da reputação de provedores amplamente confiáveis e distribuir o tráfego por diferentes regiões, dificultando ações de resposta baseadas apenas em bloqueio de IPs ou domínios. A campanha também mostra como frameworks de C2, ferramentas de tunelamento e scripts de automação podem ser combinados para transformar servidores comprometidos em recursos operacionais reutilizáveis. Nesse caso, a infraestrutura não parecia voltada apenas ao acesso inicial ou à movimentação lateral, mas à criação de uma rede funcional de retransmissão, validada continuamente e sincronizada com outro servidor para consumo externo. Para equipes de segurança, a atividade reforça a importância de monitorar servidores Linux em ambientes cloud em busca de arquivos ocultos incomuns em diretórios temporários, serviços systemd ou cron suspeitos, processos Chisel inesperados, beacons Sliver, conexões de saída para servidores SMTP e túneis SOCKS5 em portas altas. Também é recomendável revisar tráfego periódico para servidores desconhecidos, principalmente quando há sincronização constante ou comunicação com infraestrutura externa não documentada.

O Departamento de Justiça dos Estados Unidos anunciou os resultados de uma ampla operação conduzida por autoridades governamentais e empresas do setor privado para combater fraudes digitais e golpes envolvendo criptomoedas que tinham cidadãos norte-americanos como alvo. A ação, chamada “Disruption Week”, começou em 18 de maio de 2026 e resultou na derrubada de milhões de contas usadas por grupos transnacionais de cibercrime no Sudeste Asiático. Segundo o DoJ, a operação afetou contas de redes sociais, e-mail e acesso à internet empregadas por redes criminosas para enganar vítimas. Como parte da iniciativa, empresas privadas congelaram voluntariamente mais de US$ 3,8 milhões em criptomoedas associadas à lavagem de dinheiro proveniente de valores roubados de cidadãos dos Estados Unidos. A procuradora Jeanine Ferris Pirro, do Distrito de Columbia, afirmou que fraudes digitais e golpes de investimento em criptoativos têm causado danos severos a cidadãos comuns, incluindo a perda de economias acumuladas ao longo da vida e a exploração de pessoas em situação de maior vulnerabilidade. A ação faz parte de uma iniciativa em andamento do governo dos EUA chamada Scam Center Strike Force, criada para desmantelar organizações criminosas transnacionais responsáveis por fraudes digitais e esquemas conhecidos como “pig butchering”, também chamados de romance baiting. Nesse tipo de golpe, os criminosos constroem uma relação de confiança com a vítima ao longo do tempo, muitas vezes com abordagem emocional ou romântica, antes de induzi-la a investir em plataformas fraudulentas. O funcionamento do golpe geralmente segue um padrão. Os criminosos mantêm contato prolongado com a vítima, criam uma falsa sensação de confiança e apresentam supostas oportunidades de investimento com promessa de altos retornos. Quando a vítima deposita dinheiro ou criptoativos na plataforma indicada, os recursos são desviados para contas controladas pelos golpistas. Quando a vítima fica sem dinheiro ou percebe a fraude, os criminosos encerram o contato. A operação contou com a participação de empresas como Apple, Coinbase, Google, Meta, Microsoft, Silent Push, SpaceX/Starlink, TRM Labs e Zenlayer. Também participaram autoridades internacionais, incluindo a Polícia Federal Australiana, o Canadian Anti-Fraud Centre, a Polícia da Nova Zelândia, a Polícia Real da Tailândia e a National Crime Agency do Reino Unido. Descrita como uma iniciativa inédita, a Disruption Week resultou em uma série de ações coordenadas. Entre elas, a interrupção de atividades criminosas em mais de 1,4 milhão de contas, páginas e grupos no Facebook e no Instagram, 20 mil contas da Microsoft e milhares de kits Starlink usados por redes fraudulentas. A operação também interrompeu tráfego malicioso associado a endereços IP e conexões de rede hospedadas por golpistas, além de desativar servidores, ambientes de colocation e infraestruturas de hospedagem ligadas a redes de golpes em operação no Sudeste Asiático. As ações também permitiram identificar múltiplos golpistas e plataformas fraudulentas, que foram encaminhados às autoridades norte-americanas para investigação e possível processo criminal. Na Tailândia, sete suspeitos foram presos, e a Polícia Real Tailandesa abriu novos casos por meio de seu Anti-Cyber Scam Center. De acordo com o Departamento de Justiça, golpes de investimento em criptomoedas estão entre as modalidades de fraude que mais crescem e causam maior impacto financeiro contra cidadãos norte-americanos. As perdas relatadas nesse tipo de crime passaram de US$ 3,96 bilhões em 2023 para US$ 5,8 bilhões em 2024 e ultrapassaram US$ 7,2 bilhões em 2025, um aumento anual de 24%. O DoJ afirmou que muitas dessas operações são conduzidas a partir de complexos industriais usados como centros de golpes em países como Camboja, Laos e Mianmar, especialmente em áreas próximas à fronteira com a Tailândia. Segundo o órgão, sindicatos criminosos frequentemente atraem trabalhadores para a Tailândia com promessas de empregos técnicos bem remunerados, confiscam seus documentos de identificação e os traficam para trabalhar nesses centros de fraude. Dentro desses complexos, trabalhadores vítimas de tráfico humano são frequentemente forçados a executar operações fraudulentas contra pessoas nos Estados Unidos e em outros países, sob ameaça de violência. Esse aspecto mostra que os golpes de investimento em criptomoedas não envolvem apenas fraude financeira e lavagem de dinheiro, mas também redes de exploração humana que sustentam parte da operação criminosa. No mês anterior, uma operação internacional conjunta envolvendo autoridades dos Estados Unidos e da China já havia resultado na prisão de pelo menos 276 suspeitos e no fechamento de nove centros de golpes usados em esquemas de fraude de investimento em criptomoedas contra cidadãos norte-americanos. Em uma declaração coordenada, a Meta informou que autoridades policiais já prenderam 63 possíveis criminosos ligados a centros de golpes. A Coinbase, por sua vez, congelou mais de US$ 3 milhões em criptoativos associados a redes criminosas. O tenente-general Jirabhop Bhuridej, da Polícia Real da Tailândia, afirmou que fraudes online transnacionais não podem ser combatidas por uma única agência ou país atuando isoladamente. Segundo ele, a colaboração internacional e o compartilhamento rápido de informações são essenciais para desmantelar essas redes e proteger a população. A operação reforça o papel crescente da cooperação entre governos, forças policiais e empresas de tecnologia no combate a fraudes digitais em escala global. Plataformas de redes sociais, provedores de nuvem, empresas de criptoativos, serviços de conectividade e companhias de inteligência de ameaças desempenham funções diferentes dentro da cadeia de resposta, desde a derrubada de contas e infraestrutura até o rastreamento e bloqueio de ativos digitais. O caso também evidencia a complexidade dos golpes envolvendo criptoativos. A infraestrutura usada pelas redes criminosas combina engenharia social, contas falsas, plataformas fraudulentas de investimento, lavagem de dinheiro em blockchain, hospedagem distribuída e, em alguns casos, conectividade via satélite. Ao atacar várias camadas ao mesmo tempo, a Disruption Week buscou reduzir a capacidade operacional dessas redes, mesmo que o objetivo de longo prazo seja desmontar suas estruturas financeiras e humanas.

Resultados experimentais do XI SAPCT 2026 — SENAI CIMATEC A criptografia que protege praticamente toda a comunicação segura na internet tem um prazo de validade. Não é catastrofismo — é uma conclusão técnica bem documentada, que motivou o NIST a publicar, em agosto de 2024, os primeiros padrões de criptografia pós-quântica da história. E é o problema que decidimos investigar de forma experimental no SENAI CIMATEC. Este artigo descreve o que fizemos, o que encontramos e o que isso significa para quem trabalha com infraestrutura, segurança ou arquitetura de sistemas. O problema: por que a criptografia clássica não é suficiente RSA e ECC (criptografia de curvas elípticas) são seguros porque resolver os problemas matemáticos por trás deles — fatoração de inteiros e logaritmo discreto — é inviável para qualquer computador clássico disponível. Essa premissa muda com computadores quânticos. O algoritmo de Shor, executado em um computador quântico de capacidade suficiente, quebra RSA e ECC em tempo polinomial. Não se sabe ao certo quando esse computador existirá — estimativas variam entre 10 e 20 anos —, mas o risco já é real hoje por outro motivo. O ataque "harvest now, decrypt later" (HNDL) consiste em capturar e armazenar tráfego cifrado agora para decifrar no futuro, quando o computador quântico existir. Segredos industriais, registros médicos, comunicações estratégicas — qualquer dado com longevidade que trafegue hoje pela internet sob criptografia clássica está potencialmente exposto a esse vetor. A ameaça não começa quando o computador quântico chegar. Ela já está em andamento. A resposta: criptografia pós-quântica e a inevitabilidade dos ambientes híbridos O NIST padronizou três algoritmos resistentes à computação quântica: ML-KEM (FIPS 203, para troca de chaves), ML-DSA (FIPS 204, para assinatura digital) e SLH-DSA (FIPS 205, assinatura alternativa). A migração, porém, não acontece de uma vez. A infraestrutura atual — servidores, clientes, certificadoras, dispositivos legados — não pode ser substituída da noite para o dia. O cenário inevitável é o ambiente híbrido: sistemas em que algoritmos clássicos e pós-quânticos coexistem, às vezes dentro do mesmo handshake TLS. Essa coexistência levanta perguntas práticas que nenhuma especificação responde sozinha: como configurar isso? O que muda no TLS? A PKI existente precisa ser refeita? Qual o custo de performance? É exatamente aí que entra o nosso trabalho. O que fizemos: metodologia experimental em seis etapas Toda a pesquisa foi conduzida em laboratório, sobre Rocky Linux 9.5, usando exclusivamente ferramentas open source. A escolha não foi apenas pragmática — foi deliberada: qualquer instituição com acesso à internet consegue reproduzir cada etapa. Etapa 1 — Análise do handshake TLS 1.3 Começamos pelo começo: capturar e dissecar o que realmente acontece quando um cliente e um servidor estabelecem uma sessão TLS. Com Wireshark e tcpdump, inspecionamos ao nível de pacote o Client Hello, o Server Hello, a troca de certificados e o estabelecimento da sessão criptografada. Essa linha de base é essencial — sem entender o handshake clássico em detalhe, não há como avaliar o que muda quando inserimos algoritmos pós-quânticos. Etapa 2 — Implementação de PKI local Criamos uma Autoridade Certificadora raiz com OpenSSL, emitimos e assinamos certificados digitais, e configuramos a validação da cadeia de confiança com OpenSSL e curl. O objetivo foi ter controle total sobre a PKI para os experimentos seguintes. Etapa 3 — Servidor TLS 1.3 com NGINX Subimos um servidor NGINX com TLS 1.3 usando os certificados emitidos pela nossa CA local. Isso estabeleceu o ambiente base sobre o qual adicionaríamos os algoritmos pós-quânticos. Etapa 4 — Integração OpenSSL 3.x + OQS Provider O OQS Provider é um módulo desenvolvido pela iniciativa Open Quantum Safe que adiciona algoritmos pós-quânticos ao OpenSSL 3.x. Compilar, instalar e validar essa integração foi tecnicamente o passo mais delicado — o provider é explicitamente experimental, a documentação é escassa, e erros de configuração resultam em falhas silenciosas ou mensagens pouco descritivas. Etapa 5 — Validação do handshake TLS híbrido Com o OQS Provider operacional, configuramos cliente e servidor para negociar a suíte híbrida x25519_mlkem512: uma combinação de X25519 (clássico) com ML-KEM-512 (pós-quântico, NIST FIPS 203). O resultado: O handshake híbrido funcionou. A PKI clássica (certificado ECDSA P-256) continuou válida — o que muda é apenas a camada de troca de chaves, não a estrutura de confiança. Etapa 6 — Análise do KMS e crypto-agility Por fim, mapeamos o ciclo de vida das chaves em um Key Management System orientado à transição PQC: geração, armazenamento, rotação e revogação de chaves em um ambiente que precisa suportar algoritmos clássicos e pós-quânticos simultaneamente. O que aprendemos: quatro desafios reais da migração A validação técnica foi bem-sucedida, mas o processo revelou quatro frentes de desafio que vão muito além de “trocar o algoritmo": 1. Interoperabilidade: Sistemas clássicos e pós-quânticos precisam se comunicar durante toda a transição. A suíte híbrida resolve isso para a troca de chaves — mas certificados, protocolos de revogação (CRL/OCSP) e outros componentes da PKI também precisarão evoluir. 2. Performance: As chaves do ML-KEM são significativamente maiores do que as do X25519 clássico (chave pública ~800 bytes vs. ~32 bytes). O handshake fica mais pesado. Em ambientes de alta escala, isso se traduz em latência e custo computacional que precisam ser quantificados e gerenciados. 3. Gerenciamento do ciclo de vida das chaves: Um KMS que suporte PQC precisa ser capaz de gerar, armazenar, rotar e revogar chaves de algoritmos distintos, com políticas diferentes, sem comprometer a operação dos sistemas legados que ainda dependem do clássico. Isso é muito mais complexo do que um KMS tradicional. 4. Crypto-agility: A capacidade de trocar de algoritmo sem reengenharia profunda da aplicação — o que chamamos de agilidade criptográfica — deixa de ser um "nice to have" e se torna uma capacidade crítica de segurança. Sistemas que hoje têm o algoritmo "hard-coded" terão custos de migração exponencialmente maiores. O que vem a seguir: Quantum OWASP Top 10 Uma das conclusões mais importantes do trabalho foi perceber que a migração para PQC cria novas superfícies de ataque que ainda não têm framework de análise consolidado. Configurações híbridas mal feitas podem, paradoxalmente, ser menos seguras do que configurações clássicas — por exemplo, se permitirem fallback silencioso para o componente clássico quando o pós-quântico falha. Como trabalho futuro, estamos desenvolvendo o Quantum OWASP Top 10: um framework para mapear sistematicamente os riscos específicos da transição pós-quântica — falhas de configuração, vetores de downgrade, gestão inadequada de chaves em ambientes bimodais e ausência de crypto-agility em sistemas críticos. Reflexão final A segurança pós-quântica não é um problema do futuro. É um problema de hoje, que exige planejamento hoje — especialmente para sistemas com longos ciclos de atualização e dados com longevidade. O que validamos em laboratório é encorajador: a integração é tecnicamente viável, com ferramentas acessíveis, sem reescrever toda a infraestrutura existente. Mas a viabilidade técnica é apenas o começo. A migração real exige maturidade operacional, crypto-agility e uma nova forma de pensar o ciclo de vida das chaves. "A segurança pós-quântica também é um desafio de adaptação operacional." Agradecimentos Ao Prof. João Marcelo Silva Souza, pela orientação e visão do projeto. Ao SENAI CIMATEC e ao projeto Integração Clássico e Quântico pelo ambiente de pesquisa. O resumo completo foi apresentado no XI SAPCT 2026. Está disponível para quem tiver interesse. Ney Ricardo Lopez Junior — Pesquisador em Comunicação e Tecnologia Quântica | SENAI CIMATEC #PostQuantum #TLS #PKI #CryptoAgility #PQC #CyberSecurity #MLKEM #OpenQuantumSafe #SENAIcimatec #SAPCT2026 #SegurançaDaInformação #Criptografia #QuantumComputing

Pesquisadores identificaram um novo cluster de ameaça, ainda não documentado publicamente, que vem mirando servidores Microsoft Internet Information Services, conhecidos como IIS, para implantar um framework personalizado de web shells. O grupo foi batizado de OP-512, em que “OP” representa “opponent”, ou adversário. De acordo com a ReliaQuest, a atividade tem foco em espionagem e foi associada, com confiança moderada a alta, a interesses ligados à China. A empresa avaliou que o grupo provavelmente conduzia operações de coleta de inteligência a partir de um servidor IIS comprometido em uma organização cujo setor e localização geográfica estariam alinhados a prioridades de inteligência chinesas. Embora os pesquisadores não tenham encontrado sobreposição direta entre o OP-512 e outros grupos já conhecidos alinhados à China, a campanha chama atenção por reforçar uma tendência observada nos últimos 12 meses: o uso de servidores IIS como alvo recorrente por diferentes clusters de ameaça. Antes do OP-512, grupos como CL-STA-0048, DragonRank e GhostRedirector também foram associados a ataques contra essa tecnologia. No mês passado, a Cisco Talos revelou que múltiplos grupos de cibercrime de língua chinesa estavam compartilhando uma variante de malware chamada BadIIS para infectar servidores IIS. Além disso, servidores Microsoft IIS também foram alvo do SHADOW-EARTH-053 em uma campanha de espionagem alinhada à China contra setores governamentais e de defesa no Sul, Leste e Sudeste Asiático. O principal diferencial do OP-512 está no uso de um framework próprio de web shells, composto por três componentes que fornecem acesso remoto ao host comprometido. Web shells são scripts maliciosos implantados em servidores web para permitir que invasores executem comandos, manipulem arquivos e mantenham acesso ao ambiente comprometido por meio da própria aplicação exposta. Segundo a ReliaQuest, o framework foi projetado para dificultar a detecção baseada em assinaturas e complicar a análise forense. Uma das técnicas empregadas é o timestomping, que consiste em manipular intencionalmente os registros de data e hora de criação ou modificação dos artefatos maliciosos. Nesse caso, os web shells verificam arquivos e subpastas ao redor do diretório onde foram implantados, calculam a mediana dos timestamps de última modificação e sobrescrevem suas próprias datas de criação e alteração para combinar com esse valor. Com isso, os arquivos maliciosos passam a aparentar que já estavam presentes no servidor havia mais tempo, reduzindo a chance de chamar atenção durante uma investigação baseada em linha do tempo. A ReliaQuest destacou que o framework combina recursos pouco comuns em uma única operação. Cada implantação é gerada de forma única, o acesso é restrito ao invasor por meio de controles criptográficos e os servidores comprometidos reportam automaticamente sua localização para uma infraestrutura centralizada de gerenciamento. Essa combinação permite operar em escala, com maior controle sobre os acessos e menor exposição a mecanismos tradicionais de detecção. O OP-512 apresenta proximidade tática com o CL-STA-0048, o que levanta a possibilidade de se tratar de um cluster já existente que reformulou completamente seu conjunto de ferramentas ou, alternativamente, de um grupo que desenvolveu capacidades semelhantes de forma independente. Ainda assim, a ReliaQuest avalia o OP-512 como um cluster distinto, operando de maneira autônoma. No ataque analisado pela empresa, os invasores miraram um servidor IIS legado executando Windows Server 2016 e .NET Framework 4.0, uma versão já sem suporte. Os pesquisadores também encontraram indícios de atividade anterior no mesmo host cerca de 75 dias antes do incidente principal, incluindo consultas DNS para um domínio diferente controlado pelo atacante, “ashx.lhlsjcb[.]com”. Semanas depois, a sequência de ações foi descrita pelos pesquisadores como um “sprint”, ou seja, uma execução rápida e concentrada. O invasor utilizou o processo de trabalho do servidor web, “w3wp.exe”, para gravar um dos web shells no diretório de upload da aplicação. Esse processo é legítimo no ambiente IIS e normalmente é responsável por executar aplicações web hospedadas no servidor, o que pode ajudar a mascarar a atividade maliciosa. Após a implantação, o web shell acionou um mecanismo de autorrelato, usando uma consulta DNS ou, como alternativa, uma requisição HTTP para transmitir sua localização a uma infraestrutura controlada pelo invasor. Dessa forma, os operadores da campanha conseguiam registrar automaticamente quais servidores haviam sido comprometidos e onde os artefatos estavam posicionados. Com os três web shells instalados, o OP-512 obteve capacidades de gerenciamento de arquivos, execução autenticada de comandos por dois caminhos independentes e comunicação automatizada sobre o comprometimento. Segundo os pesquisadores, tudo isso ocorreu antes que houvesse tempo hábil para uma resposta defensiva. Depois da implantação dos web shells, o grupo tentou elevar privilégios para o nível SYSTEM usando a Potato Suite, um conjunto de técnicas e ferramentas exploradas para abuso de privilégios em ambientes Windows. Em seguida, os invasores executaram comandos como “whoami /priv” para confirmar os direitos disponíveis no sistema comprometido. A ReliaQuest afirmou que quatro clusters ligados à China mirando a mesma tecnologia em menos de um ano dificilmente representam uma coincidência. Para a empresa, servidores IIS expostos à internet e executando softwares legados ou sem suporte continuam sendo um ponto de entrada preferencial dentro desse ecossistema de ameaças. O aspecto mais preocupante do OP-512, segundo os pesquisadores, é que o grupo não depende de ferramentas comuns reutilizadas em várias campanhas. Em vez disso, utiliza um framework desenvolvido sob medida para contornar métodos de detecção que poderiam funcionar contra outros clusters conhecidos. Isso significa que organizações que ajustaram suas defesas apenas com base em atores já mapeados podem não estar adequadamente protegidas contra essa nova atividade. Para equipes de segurança, a campanha reforça a necessidade de revisar servidores IIS expostos, especialmente aqueles que executam versões antigas do Windows Server, .NET Framework sem suporte ou aplicações com diretórios de upload acessíveis. Também é importante monitorar alterações incomuns em arquivos web, discrepâncias em timestamps, execuções suspeitas originadas pelo processo “w3wp.exe”, consultas DNS para domínios desconhecidos e tentativas de elevação de privilégio em servidores de aplicação.

Dois eventos divulgados na mesma semana colocaram em evidência uma mudança importante no ritmo da descoberta e correção de vulnerabilidades. De um lado, uma startup de segurança identificou 21 falhas zero-day até então desconhecidas no FFmpeg, biblioteca amplamente usada em aplicações que processam vídeo e áudio. Do outro, o Google lançou o Chrome 149 com correções para 429 vulnerabilidades de segurança, o maior volume já registrado em uma única versão do navegador. A relação entre os dois casos não está na autoria direta das descobertas. Apenas as falhas do FFmpeg foram encontradas por inteligência artificial. No caso do Chrome, o número recorde ocorre após o Google revisar seu programa de recompensas para lidar com um aumento expressivo de relatórios gerados com apoio de IA. Mesmo assim, os dois episódios apontam para a mesma tendência: ferramentas baseadas em inteligência artificial estão colocando mais vulnerabilidades diante de equipes de segurança, mantenedores de software e fornecedores, em um ritmo mais acelerado do que o processo tradicional de triagem e correção consegue acompanhar. As falhas no FFmpeg foram reportadas pela depthfirst, que utilizou um agente autônomo de segurança para analisar aproximadamente 1,5 milhão de linhas de código em C do projeto. O resultado foi a descoberta de 21 zero-days confirmados, cada um acompanhado de uma entrada de prova de conceito reproduzível. Segundo a empresa, o custo da execução ficou em torno de US$ 1 mil. O FFmpeg é uma das bibliotecas de mídia mais importantes do ecossistema de software. Ele é usado em players de vídeo, ferramentas de transcodificação, pipelines de mídia, aplicações web, pacotes Python, imagens de contêiner, dispositivos embarcados e appliances. Por isso, vulnerabilidades nesse tipo de componente podem ter alcance muito maior do que aparentam, especialmente quando cópias embutidas da biblioteca permanecem desatualizadas em produtos de terceiros. Entre as falhas encontradas, várias estavam presentes no código havia 15 ou 20 anos. Um dos casos citados envolve um stack overflow no código de service-description-table, introduzido em 2003 e que permaneceu sem correção por 23 anos. A maioria das vulnerabilidades envolve overflows de heap ou stack em parsers e demuxers, incluindo componentes como o TS demuxer e o decodificador VP9. A depthfirst informou que parte das falhas já recebeu identificadores CVE. A publicação lista nove vulnerabilidades, de CVE-2026-39210 a CVE-2026-39218, enquanto as demais já foram corrigidas no código upstream, mas ainda não haviam recebido numeração no momento da divulgação. A empresa também publicou uma prova de conceito, reforçando a necessidade de atualização rápida por parte de mantenedores e distribuidores. A cadeia de risco no caso do FFmpeg está associada ao processamento de conteúdo não confiável. Um arquivo de mídia, fluxo RTSP ou tráfego AV1-over-RTP especialmente criado pode acionar falhas em parsers, demuxers ou decodificadores vulneráveis. Dependendo da natureza do bug e do contexto de execução, o impacto pode variar de crash da aplicação a exploração mais grave de memória. Mesmo quando uma falha não resulta imediatamente em execução de código, ela pode comprometer disponibilidade, estabilidade e segurança de serviços que processam mídia em escala. Para organizações, o desafio não se limita a atualizar o pacote instalado no sistema operacional. O FFmpeg costuma estar embutido em aplicações, containers, bibliotecas de terceiros, ferramentas internas e produtos de fornecedores. Isso significa que equipes de segurança precisam mapear onde a biblioteca está sendo usada, identificar versões empacotadas e garantir que atualizações cheguem também às cópias incorporadas em pipelines e aplicações. Em paralelo, o Google lançou o Chrome 149 com correções para 429 vulnerabilidades de segurança. A atualização está disponível nas versões 149.0.7827.53 para Linux e 149.0.7827.53/54 para Windows e macOS. Entre as falhas corrigidas, mais de 100 foram classificadas como críticas ou de alta severidade, com predominância de erros como use-after-free e validação insuficiente de entrada. A vulnerabilidade mais grave destacada na atualização é a CVE-2026-10881, com pontuação CVSS 9.6. Trata-se de uma falha de leitura e escrita fora dos limites no ANGLE, mecanismo gráfico usado pelo Chrome. Segundo as informações divulgadas, uma página especialmente criada poderia explorar a vulnerabilidade para escapar do sandbox do navegador e executar código no sistema host. O Google pagou uma recompensa de US$ 97 mil pelo relatório dessa falha. O volume de correções no Chrome 149 chama atenção não apenas pelo número absoluto, mas pela concentração de falhas graves identificadas internamente. Entre cerca de 90 vulnerabilidades de alta severidade, apenas 10 vieram de pesquisadores externos. Das 22 classificadas como críticas, 19 foram descobertas pelo próprio Google. Isso indica que o recorde do Chrome não deve ser interpretado como resultado direto de uma ferramenta de IA específica, mas como parte de um cenário em que o volume de descobertas, relatórios e triagens está aumentando. O próprio Google já havia ajustado seu programa de bug bounty em abril para lidar com uma enxurrada de submissões geradas por IA. A empresa passou a valorizar reprodutores concisos e funcionais em vez de relatórios longos produzidos automaticamente. A mudança sinaliza uma preocupação crescente no setor: a inteligência artificial pode acelerar a descoberta de falhas, mas também pode gerar ruído, relatórios redundantes ou materiais difíceis de validar. Esse movimento não se restringe ao FFmpeg ou ao Chrome. O agente Big Sleep, do Google, já havia reportado falhas no FFmpeg anteriormente, agora visíveis na página de segurança do projeto com a marcação BIGSLEEP. A Anthropic também relatou que seu modelo Mythos encontrou uma falha de 16 anos no H.264 e outras vulnerabilidades no FFmpeg, algumas delas incorporadas ao FFmpeg 8.1. Outros casos recentes seguem a mesma direção. Uma ferramenta autônoma identificou uma falha de execução remota de código autenticada no Redis que estava presente desde a versão 7.2.0 e havia passado despercebida por mais de dois anos. Estudos acadêmicos também apontam que agentes de IA já conseguem reproduzir provas de conceito funcionais para uma parcela significativa de vulnerabilidades reais do kernel Linux, superando abordagens tradicionais de fuzzing em determinados cenários. A tendência muda a dinâmica operacional da segurança de software. Antes, encontrar vulnerabilidades profundas em grandes bases de código exigia tempo, especialização e esforço manual significativo. Agora, agentes autônomos começam a reduzir o custo da descoberta e a ampliar a quantidade de bugs reportados. O gargalo passa a estar cada vez mais na triagem, validação, priorização, correção, distribuição de patches e instalação efetiva das atualizações. Para projetos open source, esse cenário pode ser especialmente pesado. Muitas bibliotecas críticas são mantidas por voluntários ou por equipes pequenas, mas estão presentes em milhares de produtos comerciais e ambientes corporativos. Quando agentes de IA passam a encontrar dezenas de falhas em pouco tempo, os mantenedores precisam lidar com uma carga adicional de análise, comunicação e correção, enquanto organizações consumidoras precisam acelerar seus processos de atualização. No caso do FFmpeg, a recomendação é obter a versão upstream corrigida ou aplicar a atualização de segurança da distribuição assim que disponível. Ambientes que processam RTSP não confiável ou AV1-over-RTP devem ser priorizados. Também é importante revisar pipelines de mídia, imagens de contêiner, pacotes embutidos, appliances e aplicações que possam carregar cópias próprias da biblioteca. Para usuários e empresas que utilizam Chrome, a orientação é atualizar para a versão 149.0.7827.53 no Linux ou 149.0.7827.53/54 no Windows e macOS, ou confirmar que a atualização automática já foi aplicada. Navegadores são componentes altamente expostos, e falhas em mecanismos gráficos, renderização, mídia, WebRTC e V8 costumam ter impacto relevante por poderem ser acionadas a partir de conteúdo web. Os dois casos reforçam a necessidade de ciclos de patch mais curtos, atualização automática sempre que possível e tratamento de dependências vulneráveis como trabalho de segurança, não apenas manutenção de rotina. Em um cenário no qual a IA torna a descoberta de bugs mais barata e rápida, a capacidade de corrigir, distribuir e instalar patches se torna um fator decisivo de resiliência. A principal mudança, portanto, não está apenas na quantidade de vulnerabilidades encontradas, mas na pressão sobre quem precisa responder a elas. A indústria pode estar entrando em uma fase na qual máquinas encontram falhas em escala, enquanto a triagem, a correção e a coordenação de segurança continuam dependendo de equipes humanas, muitas vezes pequenas, sobrecarregadas e responsáveis por componentes usados por grande parte da internet.

A Agência de Segurança Cibernética e de Infraestrutura dos Estados Unidos, a CISA, adicionou uma vulnerabilidade de alta severidade que afeta o SolarWinds Serv-U ao catálogo Known Exploited Vulnerabilities, conhecido como KEV, após identificar evidências de exploração ativa. A falha, rastreada como CVE-2026-28318, recebeu pontuação CVSS 7.5 e pode causar uma condição de negação de serviço no software de servidor de arquivos multiprotocolo da SolarWinds. O SolarWinds Serv-U é utilizado por organizações para transferência e gerenciamento de arquivos por diferentes protocolos. Por esse motivo, uma indisponibilidade provocada por exploração da falha pode afetar operações que dependem da troca contínua de arquivos entre sistemas, usuários, parceiros ou ambientes corporativos. Embora a vulnerabilidade não tenha sido descrita como uma falha de execução remota de código, seu impacto está diretamente relacionado à disponibilidade do serviço. De acordo com a CISA, a CVE-2026-28318 é uma vulnerabilidade de consumo descontrolado de recursos que resulta em uma condição de DoS. Na prática, isso significa que um invasor pode explorar um comportamento inadequado no processamento de determinadas requisições para fazer o serviço Serv-U travar, interrompendo sua operação normal. A SolarWinds informou que o Serv-U é suscetível a requisições POST especialmente criadas, capazes de derrubar o serviço sem necessidade de autenticação quando utilizam o cabeçalho Content-Encoding: deflate. Esse detalhe técnico é relevante porque indica que a exploração não exige credenciais válidas. Um atacante capaz de alcançar a interface vulnerável pode enviar a requisição maliciosa e provocar o crash do serviço. A cadeia de ataque descrita até o momento é relativamente direta. Primeiro, o invasor identifica uma instância vulnerável do SolarWinds Serv-U exposta ou acessível em rede. Em seguida, envia uma requisição POST criada especificamente para acionar o consumo indevido de recursos. Quando a requisição é processada pelo serviço vulnerável, o Serv-U falha e deixa de responder, gerando indisponibilidade para usuários e sistemas que dependem dele. A falha foi corrigida na versão SolarWinds Serv-U 15.5.4 HF1. Para organizações que não conseguem aplicar a atualização imediatamente, a SolarWinds recomenda restringir o acesso ao serviço apenas a endereços conhecidos e bloquear qualquer requisição contendo “content-encoding”, já que a funcionalidade vulnerável não é necessária para o funcionamento do serviço afetado. Essas medidas de mitigação podem reduzir a exposição enquanto a correção definitiva não é aplicada. No entanto, como a vulnerabilidade já foi incluída no catálogo KEV da CISA, a recomendação prioritária é atualizar o produto o quanto antes. A presença de uma CVE no KEV indica que há evidências de exploração em ambiente real, o que aumenta a urgência para equipes de segurança, infraestrutura e resposta a incidentes. Até o momento, não há detalhes públicos sobre como a CVE-2026-28318 está sendo explorada em ataques reais, quais setores foram afetados ou quem está por trás da atividade. Também não está claro quantas instâncias do Serv-U expostas à internet podem ter sido comprometidas ou impactadas. A ausência desses detalhes, porém, não reduz a gravidade operacional da falha, especialmente para ambientes que dependem do Serv-U em processos críticos de transferência de arquivos. A CISA determinou que as agências federais civis do Poder Executivo dos Estados Unidos corrijam a vulnerabilidade até 19 de junho de 2026. Embora essa exigência seja obrigatória apenas para órgãos federais norte-americanos, o catálogo KEV é amplamente utilizado por empresas privadas, equipes de segurança e gestores de vulnerabilidades como referência para priorização de patches. O caso também chama atenção pelo histórico do SolarWinds Serv-U como alvo de exploração por invasores. Em anos anteriores, outras falhas no produto foram exploradas por agentes maliciosos, incluindo grupos associados ao ransomware Cl0p. Esse histórico torna ainda mais importante a revisão de exposição, a aplicação de correções e o monitoramento de tentativas de exploração contra servidores Serv-U. Do ponto de vista de risco corporativo, uma falha de negação de serviço em um servidor de transferência de arquivos pode gerar efeitos significativos. Organizações que usam o Serv-U para troca de documentos, integração com parceiros, movimentação de arquivos sensíveis ou automações internas podem sofrer interrupções em processos de negócio. Em ambientes nos quais o serviço está integrado a fluxos operacionais, a indisponibilidade pode afetar prazos, entregas, atendimento a clientes e continuidade operacional. Para equipes técnicas, a prioridade deve ser identificar instâncias do SolarWinds Serv-U em uso, verificar a versão instalada, aplicar a atualização 15.5.4 HF1 e revisar a exposição do serviço à internet. Também é recomendável limitar o acesso por listas de endereços confiáveis, avaliar regras de firewall e WAF, bloquear requisições com o cabeçalho vulnerável quando possível e monitorar logs em busca de padrões anômalos de requisições POST. Além disso, organizações devem tratar a inclusão no KEV como um gatilho de priorização no processo de gestão de vulnerabilidades. Mesmo que a falha tenha impacto de disponibilidade, e não de execução de código ou roubo direto de dados, a exploração ativa indica que invasores já estão tentando abusar da vulnerabilidade. Em ambientes críticos, indisponibilidade também é um risco de segurança, especialmente quando afeta serviços usados para operações essenciais. A correção rápida da CVE-2026-28318 reforça a importância de inventário de ativos, exposição controlada de serviços de borda e processos bem definidos de aplicação de patches. Servidores de transferência de arquivos costumam lidar com dados sensíveis e se conectam a múltiplos fluxos corporativos, o que torna qualquer instância exposta um ponto relevante na superfície de ataque.

A Cisco alertou que uma vulnerabilidade de alta severidade no Catalyst SD-WAN Manager está sendo explorada ativamente por invasores. A falha, rastreada como CVE-2026-20245, recebeu pontuação CVSS 7.8, em uma escala que vai até 10, e afeta diferentes modelos de implantação da solução, incluindo ambientes on-premises, Cisco SD-WAN Cloud-Pro, Cisco SD-WAN Cloud gerenciado pela própria Cisco e Cisco SD-WAN for Government, voltado a ambientes FedRAMP. Segundo o comunicado da empresa, a vulnerabilidade está localizada na interface de linha de comando do Cisco Catalyst SD-WAN Manager, anteriormente conhecido como SD-WAN vManage. Em determinadas condições, um atacante local e autenticado pode executar comandos arbitrários com privilégios de root ao fornecer um arquivo especialmente criado ao sistema afetado. A falha decorre de validação insuficiente de entradas fornecidas pelo usuário. Na prática, um invasor com acesso adequado poderia enviar um arquivo malicioso ao sistema, explorar a falha para realizar injeção de comandos e, a partir disso, elevar seus privilégios até o nível de root, o usuário com controle administrativo máximo em sistemas Linux e Unix. A Cisco destacou, no entanto, que a exploração da CVE-2026-20245 exige privilégios de netadmin no sistema afetado. Para obter esse nível de acesso, o atacante precisaria possuir credenciais válidas ou explorar vulnerabilidades anteriores, como a CVE-2026-20182 ou a CVE-2026-20127. A empresa informou que, até o momento, não tem conhecimento de explorações bem-sucedidas por outros métodos. A CVE-2026-20182, com pontuação CVSS 10.0, foi divulgada no mês passado pela Rapid7 e descrita como uma falha de bypass de autenticação capaz de permitir que invasores remotos e não autenticados obtenham privilégios administrativos em sistemas vulneráveis. A vulnerabilidade é considerada semelhante à CVE-2026-20127, outro caso de bypass de autenticação que afeta o mesmo componente. As duas falhas anteriores já foram exploradas em ataques reais como zero-days. A atividade relacionada à CVE-2026-20127 foi associada a um cluster de ameaça identificado como UAT-8616, que teria abusado da vulnerabilidade desde 2023. Esse histórico amplia a preocupação em torno da nova falha, já que ela pode ser combinada com vulnerabilidades de autenticação para compor uma cadeia de ataque mais severa. No alerta publicado na quinta-feira, a Cisco afirmou ter observado casos limitados nos quais a exploração da CVE-2026-20245 resultou em alterações de configuração enviadas para dispositivos de borda. Esse tipo de impacto é relevante porque o SD-WAN Manager atua como componente central de gerenciamento da infraestrutura SD-WAN, podendo influenciar políticas, conectividade e configurações aplicadas em equipamentos distribuídos pela rede. A nova vulnerabilidade foi descoberta e reportada por pesquisadores do Google Mandiant: Chester Sng, Pete Boonyakarn e Logeswaran Nadarajan. Até o momento, não se sabe quem está por trás das tentativas de exploração mais recentes. Um dos pontos mais críticos do comunicado é que ainda não há correções ou mitigações disponíveis para a CVE-2026-20245. Como medida de redução de risco, a Cisco recomenda que os clientes atualizem o software SD-WAN para garantir que tenham aplicado as correções lançadas em 14 de maio de 2026 para a CVE-2026-20182. A empresa também alertou que sistemas expostos diretamente à internet estão sob risco elevado de comprometimento. Para buscar possíveis indicadores de comprometimento, administradores devem revisar o arquivo “/var/log/scripts.log” em busca de entradas suspeitas relacionadas à execução de scripts e ao envio de arquivos pela interface CLI. Entre os exemplos citados pela Cisco estão registros associados ao upload de listas de tenants por número de série vSmart, envio de números de série vSmart e upload de números de chassi para ZTP. Um dos exemplos mostra o uso de um arquivo chamado “malicious.csv”, localizado no diretório “/home/admin/”, como parte de uma chamada ao script “vconfd_script_upload_tenant_list.sh”. A CVE-2026-20245 é a sétima vulnerabilidade envolvendo Cisco SD-WAN marcada como explorada ativamente apenas neste ano. Antes dela, já haviam sido sinalizadas as falhas CVE-2026-20182, CVE-2026-20127, CVE-2026-20122, CVE-2026-20128, CVE-2026-20133 e CVE-2022-20775. A divulgação ocorre poucos dias depois de a Cisco corrigir outra falha de alta severidade, desta vez no Unified Communications Manager. A vulnerabilidade, rastreada como CVE-2026-20230 e com pontuação CVSS 8.6, já possui código de prova de conceito público, embora a empresa tenha informado não haver evidências de exploração ativa até o momento. O caso envolvendo o Catalyst SD-WAN Manager chama atenção pela combinação de três fatores: exploração ativa, ausência de patch específico e possibilidade de uso em conjunto com falhas anteriores de bypass de autenticação. Em ambientes corporativos, especialmente aqueles que dependem de SD-WAN para conectar filiais, data centers, cloud e usuários distribuídos, a exposição desse tipo de componente pode representar risco direto para a operação e para a continuidade dos negócios.