Hackers começaram a explorar uma vulnerabilidade crítica no MLflow, plataforma open source utilizada em projetos de inteligência artificial e machine learning, para acessar serviços internos de ambientes em nuvem e tentar roubar credenciais e outros segredos. Uma segunda falha crítica, no software industrial FUXA, também está sendo alvo de varreduras maliciosas. Relatórios independentes da watchTowr e da VulnCheck apontam atividade envolvendo as vulnerabilidades CVE-2026-64849, no MLflow, e CVE-2026-25895, no FUXA. Ambas podem ser exploradas remotamente e sem autenticação. A CVE-2026-64849 possui pontuação CVSS 9,3 e consiste em uma vulnerabilidade Server-Side Request Forgery (SSRF) que afeta versões do MLflow anteriores à 3.15.0. Por meio da falha, um invasor capaz de alcançar o MLflow Tracking Server pode fazer com que o próprio servidor envie requisições HTTP para destinos arbitrários. Isso permite alcançar serviços internos que normalmente não estariam diretamente acessíveis pela internet, incluindo endpoints de metadados utilizados por provedores de nuvem. Segundo a watchTowr, invasores já estão explorando essa capacidade para acessar serviços de metadados e retirar credenciais e segredos de ambientes cloud. A empresa afirma ter detectado varreduras indiscriminadas em busca de instâncias MLflow expostas na internet poucas horas depois de a CVE ser atribuída, em 17 de agosto de 2026. O problema está relacionado aos webhooks do model registry do MLflow. De acordo com Yordan Ganchev, especialista principal de inteligência de ameaças da watchTowr, a vulnerabilidade permite utilizar o sistema afetado como intermediário para enviar requisições e interagir com serviços internos. A falha também consegue contornar correções anteriores devido à maneira como o MLflow processa redirecionamentos web. Dados dos honeypots globais da watchTowr indicam que os invasores estão tentando atingir sistemas MLflow hospedados na nuvem e acessar endereços IP e serviços internos conhecidos em busca de informações sensíveis. Organizações que utilizam MLflow devem priorizar a atualização de sistemas vulneráveis, principalmente quando o Tracking Server estiver acessível pela internet. Também é recomendado revisar logs em busca de indícios de comprometimento e verificar se credenciais ou outros segredos podem ter sido expostos. FUXA também é alvo de varreduras maliciosas A segunda vulnerabilidade, CVE-2026-25895, afeta o FUXA, uma plataforma SCADA/HMI open source baseada na web e utilizada em ambientes de tecnologia operacional (OT) e automação industrial. A falha recebeu pontuação CVSS 9,5 e combina ausência de autenticação em uma função crítica com uma vulnerabilidade de path traversal. O problema afeta as versões do FUXA até a 1.2.9. Um invasor remoto e sem autenticação pode explorar a vulnerabilidade para gravar arquivos arbitrários no sistema de arquivos do servidor, condição que pode levar à execução remota de código (RCE). A VulnCheck começou a observar varreduras maliciosas direcionadas à CVE-2026-25895 em 18 de agosto. Segundo a empresa, um único endereço IP foi detectado realizando buscas em larga escala na internet por instalações vulneráveis do FUXA. Aproximadamente 60 instalações da plataforma estariam diretamente expostas à internet. Caitlin Condon, vice-presidente de pesquisa da VulnCheck, informou que as requisições observadas tentavam explorar o path traversal para sobrescrever o arquivo "main.js" com dados sem utilidade. Até o momento da análise, a empresa não havia observado a implantação de payloads para execução remota de código. O FUXA já foi alvo de exploração de outras vulnerabilidades. No último ano, atividades maliciosas também foram associadas às CVE-2026-25939 e CVE-2023-33831. No caso da CVE-2023-33831, a VulnCheck afirma ter observado exploração desde novembro de 2025, incluindo atividade recente.

Por - Hilmar Becker Nenhuma tecnologia tradicional tornou-se tão crítica para o sucesso dos modelos de IA como os controladores de entrega de aplicação (ADCs). Soluções que garantem a melhor UX por meio da distribuição segura e com alta performance de carga entre diferentes sites e ambientes, os ADCs passam a ocupar um lugar privilegiado nos orçamentos dos CISOs de 2026. Cada transação, cada login, cada experiência digital que importa passa por esse componente. A IA eleva ainda mais a responsabilidade do ADC. Segundo o IDC, os gastos das empresas com a IA terão, até 2030, um impacto econômico acumulado de US$ 19,9 trilhões. Como resultado, o PIB global em 2030 deverá ser 3,5% maior. A complexidade da IA – a mais moderna das aplicações modernas, totalmente baseada em APIs – exige o ADC para gerar um crescimento econômico como este. É por isso que, em uma pesquisa publicada em junho de 2026, o Gartner prevê que, até 2029, mais de 30% das grandes empresas e provedores de serviços em todo o mundo atualizarão sua infraestrutura de ADC para atender aos requisitos de soberania de dados e IA. Preço da estrutura computacional de IA não é o único fator estratégico Por trás da previsão do Gartner há vários indícios. Organizações que estão desenvolvendo sólidos recursos de IA estão descobrindo que seus dados mais valiosos não podem simplesmente fluir para onde a estrutura computacional for mais barata. Regulamentações de soberania, obrigações de privacidade de dados e o custo elevado de transferir dados para dentro e fora de nuvens públicas estão levando muitas empresas a construir ambientes on-premises de IA em seus próprios data centers. Um estudo do Barclays do final de 2025 revela que mais de 80% das organizações estão planejando repatriar cargas de trabalho. Quando a IA volta para casa, tudo de que ela depende vem junto: os pipelines de dados que a alimentam, os pontos finais de inferência que a expõem e os controles de segurança que a protegem. Todo esse tráfego passa pela camada de entrega de aplicação. A camada que sempre determinou o desempenho dos aplicação agora determina o desempenho da aplicação de IA. Gartner lista pontos a ponderar a respeito da entrega e defesa da IA Os analistas do Gartner listaram pontos que podem ajudar os CISOs a mapearem os desafios de segurança e performance de seus modelos próprios de IA. E onde, conforme o caso, o ADC pode fazer diferença. Os dados precisam chegar ao modelo de IA com a rapidez necessária. A qualidade dos modelos depende da qualidade dos dados que lhes são fornecidos. O Gartner observa que o ADC pode agregar valor ao otimizar a entrega e a ingestão de dados de IA na borda da rede (edge computing), indo além dos limites do data center principal. Ao se concentrarem no gerenciamento avançado de tráfego, os ADCs conseguem enfrentar os principais desafios do movimento de dados de IA. A integração com a infraestrutura de IA e tecnologias de suporte, como DPUs, permite que o ADC mostre seu poder de fogo em aplicações de IA rodando em multicloud e WAN. A infraestrutura computacional da IA está nas mãos de times menos técnicos. O Gartner observa que está acontecendo uma mudança radical nos processos de compras de infraestrutura de IA. Cada vez mais, a responsabilidade pelos investimentos em infraestrutura de IA está se afastando das equipes tradicionais de TI. Em vez disso, equipes dedicadas à IA, muitas vezes subordinadas diretamente ao CEO e ao Board, lideram essas decisões, especialmente em organizações de alta maturidade. Neste contexto, o ADC passa a ser valorizado inclusive por equipes com menor background técnico. A organização busca proteger seu modelo de IA contra ameaças avançadas. As aplicações de IA enfrentam ameaças para as quais os controles tradicionais nunca foram projetados: injeção de prompts, envenenamento de dados e falsificação de identidade de agentes, entre outras. De acordo com o Gartner, os ADCs podem aprimorar a segurança para a IA agêntica atuando como gateways de IA que impõem barreiras de proteção no perímetro da rede ou na camada de APIs, algo crítico para os modelos de IA. O fim dos pontos cegos: o papel do ADC Um fio condutor conecta esses três pontos. O tráfego de IA e as ameaças à IA chegam pela mesma porta de entrada, e os dados que alimentam seus modelos e os ataques direcionados a eles percorrem os mesmos caminhos. Quando a entrega da IA e a segurança da IA residem em plataformas separadas, cada ponto de junção entre elas é um ponto cego, onde falta uma política clara e a latência não é a desejada. O estudo do Gartner investiga o que acontece quando se adota uma abordagem baseada na convergência entre a entrega da aplicação de IA e sua segurança. Uma única plataforma, abrangendo hardware, software, SaaS, implementações nativas da nuvem e DPUs, oferece suporte às empresas onde quer que as cargas de trabalho de IA sejam executadas. A entrega segura de dados, em escala, em ambientes híbridos é essencial para o sucesso da IA. Os CISOs brasileiros que lutam para elevar a performance e a segurança de seus modelos de IA podem encontrar no novo formato do ADC uma resposta a esses desafios.

Créditos das imagens: Joaz Oliver O avanço da digitalização no Brasil, a maturidade do setor financeiro, a adoção de inteligência artificial e a necessidade de transformar dados técnicos em decisões de negócio colocam o país em uma posição estratégica para o mercado global de cibersegurança. Essa é a avaliação de Sumedh Thakar, presidente e CEO da Qualys, que conversou com exclusividade com a Cyber Security Brazil durante o ROCon LATAM 2026, realizado em São Paulo. A própria Qualys apresenta o encontro como sua conferência voltada a Risk Operations e à redução proativa do risco cibernético. A Cyber Security Brazil foi convidada especial da Qualys para acompanhar e cobrir o evento, que reuniu executivos, especialistas, clientes e parceiros da companhia na América Latina. Durante a cobertura, Thakar reservou espaço em sua agenda para uma entrevista extensa com o portal e recebeu a equipe de forma atenciosa, assim como os profissionais da Qualys envolvidos na organização. Registramos também nosso agradecimento especial a Leandro Roosevelt, Country Manager da Qualys no Brasil, e Eduardo Bergonse Pereira, Regional Vice President para a América Latina, pelo suporte à Cyber Security Brazil durante o evento e pela receptividade ao longo da cobertura. Na entrevista, Thakar falou sobre a transformação da Qualys de uma companhia fortemente associada ao gerenciamento de vulnerabilidades para uma plataforma mais ampla de gestão de risco cibernético, explicou a estratégia por trás do Risk Operations Center (ROC) e do Enterprise TruRisk Management (ETM), analisou a posição do Brasil no cenário internacional e discutiu como a IA deve alterar tanto o ataque quanto a defesa nos próximos anos. Da descoberta de vulnerabilidades à redução efetiva do risco A história da Qualys está diretamente relacionada ao gerenciamento de vulnerabilidades. Segundo Thakar, a empresa esteve entre as pioneiras no uso do modelo SaaS para esse tipo de atividade, em uma época em que a identificação de falhas era uma das principais preocupações das organizações. O mercado, porém, mudou. À medida que o número de vulnerabilidades e descobertas aumentou, as empresas passaram a enfrentar outro problema: encontrar uma vulnerabilidade não significa necessariamente conseguir corrigi-la. Para Thakar, essa diferença entre descoberta e ação levou a Qualys a ampliar seu foco. O executivo explicou que, inicialmente, grande parte da proposta estava relacionada ao scanning e à identificação das vulnerabilidades. Com o passar dos anos, ficou evidente que as organizações acumulavam cada vez mais descobertas que suas equipes não conseguiam corrigir. A consequência foi uma mudança de direção para adicionar mais recursos de priorização, validação e remediação. A lógica é relativamente simples: se uma empresa identifica milhares de vulnerabilidades, mas não consegue determinar quais representam risco real e nem agir rapidamente sobre elas, o volume de informações por si só não representa uma melhoria proporcional da segurança. Essa estratégia aparece em tecnologias recentes da companhia. Uma delas é o InstaScan, alimentado pelo Agent Insta, criado para correlacionar continuamente novos avisos de segurança com inventário, telemetria e informações sobre ameaças já disponíveis, buscando identificar sistemas afetados sem depender exclusivamente do próximo ciclo tradicional de scanning. Outro componente citado pelo CEO é o Agent Val, agente de IA integrado ao Enterprise TruRisk Management que utiliza o TruConfirm para ajudar a verificar se exposições priorizadas são realmente exploráveis. O fluxo inclui validação, definição da ação de mitigação ou correção e uma nova validação para verificar se o caminho de exploração foi efetivamente eliminado. Na visão apresentada por Thakar, a pergunta que as empresas precisam responder deixa de ser simplesmente “quantas vulnerabilidades temos?” e passa a incluir questões como: quais delas podem realmente ser exploradas, quais ativos são relevantes para o negócio e com que velocidade a organização consegue reduzir aquela exposição. Por que a Qualys aposta em um Risk Operations Center Essa mudança também explica a aposta da companhia no conceito de Risk Operations Center, ou ROC. Tradicionalmente, o SOC — Security Operations Center — concentra esforços na identificação e resposta a eventos, alertas, ameaças e incidentes. Para Thakar, existe espaço para uma camada complementar destinada a entender, priorizar e reduzir o risco antes que ele resulte necessariamente em um incidente. Um dos problemas atuais, segundo o executivo, é aquilo que ele descreveu durante a entrevista como uma espécie de “turismo de dashboards”. Uma organização pode ter um painel para identidade, outro para cloud, um terceiro para vulnerabilidades, outros para aplicações, endpoints ou diferentes componentes da infraestrutura. A quantidade de informações aumenta, mas o risco permanece fragmentado. O desafio é estabelecer uma visão capaz de comparar esses riscos. “Qual é o valor do risco?” é a questão que, na visão de Thakar, precisa ganhar espaço no processo de decisão. É nesse ponto que a Qualys posiciona o ROC e o Enterprise TruRisk Management. Em vez de restringir a análise a apenas uma categoria de vulnerabilidade ou tecnologia, a proposta é reunir diferentes fatores de risco e fornecer uma visão consolidada que permita priorizar ações. A companhia também vem incorporando agentes de IA ao modelo. A arquitetura anunciada pela Qualys inclui agentes voltados à priorização de ameaças, estratégias de remediação e execução de tarefas dentro das operações de risco. Para Thakar, a velocidade passa a ser particularmente importante com a adoção de IA. Quanto mais rapidamente novas vulnerabilidades e técnicas podem ser encontradas ou exploradas, menor é a margem para processos defensivos lentos e excessivamente manuais. O objetivo, segundo ele, é permitir que a organização analise rapidamente, decida rapidamente e aja rapidamente. Consolidação não significa depender de um único fabricante Questionado sobre a forte fragmentação do mercado de cibersegurança e sobre uma possível consolidação das ferramentas, Thakar fez uma distinção importante. Ele não acredita que o futuro seja necessariamente um ambiente no qual uma empresa utilizará apenas um fornecedor para todas as necessidades de segurança. A consolidação, segundo o CEO, deve ocorrer principalmente dentro de determinados domínios. No gerenciamento de vulnerabilidades, por exemplo, capacidades que anteriormente poderiam estar separadas — inventário, descoberta, priorização, validação e remediação — começam a funcionar de maneira mais integrada. Quando a discussão passa para gestão de risco, porém, é necessário considerar informações provenientes de diferentes tecnologias e fabricantes. A consolidação que Thakar considera essencial nesse contexto é a da visão do risco, e não obrigatoriamente a eliminação de todas as ferramentas de terceiros. Uma organização pode continuar utilizando diferentes tecnologias para identidade, cloud, endpoint, aplicações e outras áreas, mas precisa ser capaz de reunir esses sinais para entender quais problemas representam maior impacto para o negócio. É justamente nesse ponto que a companhia pretende posicionar o ETM e o ROC: como uma camada capaz de correlacionar diferentes fatores e transformar dados dispersos em decisões de risco. Brasil ganha importância com digitalização da economia Ao falar especificamente sobre o Brasil, Thakar foi enfático ao destacar a crescente importância do país. Na avaliação do executivo, o peso brasileiro no ambiente econômico e financeiro global aumentou, ao mesmo tempo em que o país demonstrou capacidade de utilizar tecnologia de maneira concreta para transformar atividades econômicas. Um dos exemplos citados por ele foi o Pix. Para o CEO da Qualys, sistemas desse tipo mostram como a infraestrutura digital pode facilitar transferências de dinheiro, ampliar o acesso a serviços e alterar a forma como a população interage com a economia. Mas existe uma consequência direta: quanto mais a economia depende de tecnologia, maior é a necessidade de estabelecer confiança nos sistemas que sustentam essas operações. Se usuários deixarem de confiar em uma plataforma de pagamento por receio de fraude ou comprometimento, a própria adoção da tecnologia pode ser afetada. “Como garantir que esses sistemas que estão impulsionando a economia sejam realmente confiáveis?” foi uma das questões levantadas por Thakar durante a conversa. Na avaliação do executivo, a digitalização brasileira também aumenta sua atratividade para hackers. Economias maiores, mais conectadas e dependentes de infraestrutura digital passam naturalmente a oferecer mais oportunidades para ataques com motivação financeira e outras formas de atividade maliciosa. Por esse motivo, ele considera o Brasil um mercado importante não apenas para a Qualys, mas para o setor de segurança de maneira geral. Thakar também destacou os bancos brasileiros, que considera avançados tecnologicamente e fortemente influenciados por exigências regulatórias. “Não acho que o Brasil esteja atrás de nenhuma outra região” Apesar das diferenças existentes entre organizações e setores, o CEO rejeitou a ideia de que o Brasil esteja necessariamente atrás dos Estados Unidos, Europa ou de outros mercados quando o assunto é maturidade em cibersegurança. Segundo ele, as conversas mantidas com organizações brasileiras demonstram um nível elevado de compreensão dos desafios. “Não acho que o Brasil esteja atrás de nenhuma outra região em termos de cibersegurança”, afirmou Thakar durante a entrevista. A diferença de maturidade entre empresas brasileiras também não é, segundo ele, uma característica exclusiva do país. Instituições financeiras e organizações submetidas a uma pressão regulatória maior tendem a apresentar programas mais maduros. Em outras áreas da economia, a segurança disputa orçamento e atenção com as atividades centrais de cada empresa. Essa realidade, na visão do CEO, reforça a necessidade de tratar a segurança como uma disciplina de gerenciamento de risco. Empresas não possuem recursos infinitos e dificilmente conseguem eliminar todas as possibilidades de incidente. A questão passa a ser quanto investir, quais riscos reduzir primeiro e qual nível de exposição a organização considera aceitável. Por isso, Thakar acredita que organizações brasileiras que estão expandindo seus programas de segurança têm uma oportunidade de concentrar menos a discussão exclusivamente em ferramentas e mais nos resultados obtidos. IA deve acelerar os dois lados da disputa Outro ponto central da entrevista foi a inteligência artificial. Perguntado sobre quem deve obter maior vantagem com a tecnologia — atacantes ou defensores — Thakar evitou apontar um vencedor. Para ele, cibersegurança continuará funcionando como um jogo de gato e rato. Hackers possuem incentivos para empregar IA porque precisam encontrar alvos, vulnerabilidades e oportunidades antes de outros atacantes. Na defesa, o raciocínio é semelhante: se os adversários estão automatizando processos com IA, equipes de segurança não podem responder apenas com mecanismos tradicionais e lentos. “Nenhum dos dois lados tem escolha a não ser usar IA”, resumiu o executivo. Thakar também chamou atenção para a velocidade com que o próprio ecossistema de inteligência artificial está mudando. Modelos generativos, sistemas agentivos e diferentes arquiteturas estão avançando rapidamente, e novas aplicações devem continuar surgindo. Para as empresas, o desafio será aproveitar esses recursos sem ignorar questões como disponibilidade e risco operacional. O executivo destacou ainda uma característica histórica da cibersegurança: a falta de profissionais qualificados em quantidade suficiente. Por isso, ele vê um espaço particularmente interessante para automação. A discussão, em sua visão, não deve ficar limitada à substituição de pessoas. A IA pode atuar principalmente em atividades nas quais as equipes já não tinham profissionais suficientes para acompanhar a velocidade e o volume de trabalho necessário. O resultado esperado é uma disputa contínua: atacantes adotam novas capacidades, defensores respondem com tecnologias melhores e o ciclo se repete. IA não significa necessariamente o fim dos empregos Durante a conversa, a discussão sobre IA também avançou para o impacto sobre os empregos. Thakar demonstrou uma visão otimista sobre o tema. Para ele, transformações tecnológicas anteriores eliminaram determinadas tarefas, mas também criaram novas formas de produzir valor. O executivo comparou essa evolução com diferentes saltos tecnológicos ao longo da história: atividades que antes exigiam esforço manual passaram a ser realizadas com novas ferramentas, mas isso não eliminou a capacidade humana de encontrar novas ocupações. Na avaliação dele, a IA deve aumentar o que as pessoas conseguem realizar durante o dia e modificar a natureza de determinadas funções, em vez de simplesmente tornar o trabalho humano desnecessário. Para o mercado de cibersegurança, a própria evolução constante das tecnologias e das ameaças deve continuar demandando pessoas capazes de entender problemas, tomar decisões e administrar risco. O conselho não quer saber apenas quantas CVEs existem Um dos pontos mais relevantes da entrevista surgiu quando a conversa se voltou para a comunicação entre CISOs e os conselhos de administração. Hoje, líderes de segurança possuem uma quantidade enorme de informações: vulnerabilidades, CVEs, alertas, inteligência de ameaças, dashboards, incidentes e indicadores produzidos por dezenas de ferramentas. Para Thakar, porém, quantidade de dados não significa necessariamente capacidade de comunicação com o negócio. O papel do CISO, segundo ele, é funcionar como uma ponte entre segurança e negócio. E existe uma linguagem que a administração entende com facilidade: impacto financeiro. Um servidor crítico pode ter determinada vulnerabilidade, por exemplo, mas a relevância daquele problema para a direção depende das consequências de um eventual comprometimento. Se uma indisponibilidade ou destruição daquele sistema puder gerar uma perda de milhões de dólares, a discussão muda completamente. A pergunta para o conselho deixa de ser apenas “quantas vulnerabilidades críticas ainda estão abertas?” e passa a ser “qual é a perda potencial associada ao risco que estamos assumindo?”. Depois disso surge uma segunda pergunta: a organização está gastando uma quantidade adequada de recursos para manter essa perda potencial dentro de seu apetite de risco? Nenhum CISO, segundo Thakar, pode garantir risco zero. O objetivo é demonstrar que a companhia compreende sua exposição, conhece as possíveis consequências e consegue mostrar se o risco residual está ou não dentro de um nível considerado aceitável. “O conselho não se importa com a CVE ou com a vulnerabilidade”, disse o executivo ao explicar que a preocupação da administração está no impacto que aquele problema pode causar ao negócio. Essa visão também está no centro da estratégia da Qualys para o ROC e o ETM. A intenção é transformar resultados técnicos — descobertas, ativos, vulnerabilidades e correções — em uma representação que permita aos executivos acompanhar a redução de risco de forma mais próxima à linguagem de negócio. O que a cibersegurança poderá ser daqui a cinco anos Quando questionado sobre o que espera encontrar se uma nova entrevista acontecer daqui a cinco anos, Thakar evitou fazer previsões sobre tecnologias específicas. Para ele, é praticamente impossível saber qual inovação dominará o mercado nesse período. Há, entretanto, algo que considera previsível: as organizações continuarão utilizando tecnologia digital. Enquanto isso acontecer, existirão pessoas tentando atacar esses sistemas. Novas tecnologias também introduzirão novos riscos, enquanto as empresas continuarão convivendo com sistemas antigos e riscos acumulados. Por isso, Thakar acredita que uma das perguntas fundamentais da cibersegurança permanecerá a mesma: quanto risco determinada tecnologia adiciona ao negócio e quanto a organização deve investir para reduzi-lo? O executivo exemplificou a lógica de forma financeira: se uma nova tecnologia acrescenta US$ 10 milhões de exposição potencial, a companhia precisa avaliar quanto faz sentido investir para diminuir aquele risco. É justamente por essa razão que ele defende uma abordagem de Risk Operations não limitada a uma tecnologia específica. Se, daqui a cinco anos, grande parte das operações empresariais estiver baseada em inteligência artificial, uma parcela maior do risco poderá estar ligada à IA. Isso não significa, entretanto, que vulnerabilidades de infraestrutura, aplicações, identidades, endpoints e tecnologias legadas desaparecerão. O objetivo de uma camada centralizada de gerenciamento seria incorporar esses novos fatores à mesma equação de risco e permitir que a empresa determine continuamente quais deles merecem prioridade. De engenheiro a CEO: “você continua tendo as mesmas 24 horas” A parte final da entrevista deixou a tecnologia em segundo plano e abordou a trajetória pessoal do executivo. Thakar entrou na Qualys em 2003, inicialmente na área de engenharia, e passou por diferentes posições de liderança antes de chegar à presidência e ao cargo de CEO. A informação oficial da companhia confirma sua entrada em 2003; esse ponto aparece incorretamente como “2023” em um trecho da transcrição automática da entrevista. Segundo o executivo, no início da carreira seu foco era semelhante ao de muitos engenheiros: escrever código, cumprir suas responsabilidades e voltar para casa. Cibersegurança ainda não possuía para ele o significado que adquiriria posteriormente. A mudança veio a partir de uma experiência familiar. Seus pais vivem na Índia, outro país com população numerosa e forte processo de transformação digital. Em determinado momento, seu pai resistia a utilizar serviços bancários online por receio de ter a senha roubada. Para Thakar, aquela preocupação tornou evidente a importância que a segurança teria em um futuro no qual cada vez mais atividades dependeriam de sistemas digitais. A percepção o levou a se aprofundar no setor. Já sobre a evolução de engenheiro para CEO, Thakar destacou uma limitação que permanece exatamente igual independentemente do cargo ocupado: ninguém recebe mais horas no dia. Um engenheiro possui 24 horas. Um CEO também. Portanto, chega um momento em que trabalhar mais horas deixa de ser uma estratégia de crescimento sustentável. Segundo Thakar, a diferença passa a estar na capacidade de construir uma equipe. Um profissional pode aumentar suas responsabilidades em dez, cem ou até mais vezes, mas não pode multiplicar seu próprio tempo na mesma proporção. A capacidade de produzir resultados em escala passa, portanto, a ser diretamente proporcional à qualidade das pessoas ao redor do líder. A principal lição de liderança que ele destacou foi justamente essa: formar uma equipe forte e trazer pessoas capazes de ser melhores do que o próprio líder em suas respectivas áreas. O que ainda surpreende Thakar depois de duas décadas no setor Mesmo após mais de duas décadas de experiência na Qualys, uma característica da indústria ainda chama a atenção do executivo: a dificuldade de muitos líderes em relacionar cibersegurança diretamente ao negócio. Na avaliação de Thakar, parte dos profissionais continua excessivamente concentrada nos aspectos técnicos. Tecnologia é indispensável, mas, para ele, cibersegurança existe dentro de uma empresa principalmente para reduzir a possibilidade de perdas provocadas por riscos digitais. Essa visão também ajuda a explicar por que o ROC ganhou uma posição central na estratégia que ele pretende desenvolver. Independentemente de qual seja a próxima tecnologia ou a próxima categoria de risco, o executivo defende uma equação que permita relacionar investimento e redução de exposição. Em outras palavras: se a empresa investir determinado valor, precisa entender quanto risco efetivamente conseguiu retirar do negócio. É essa mudança de uma segurança baseada predominantemente em achados técnicos para uma disciplina orientada a resultados mensuráveis de risco que Thakar considera uma das transformações mais importantes ainda em andamento no setor. Comunicação também é uma ferramenta de liderança A última pergunta trouxe uma recomendação fora da área técnica. Questionado sobre um livro que indicaria para profissionais, Thakar escolheu “Comunicação Não Violenta”, obra de Marshall Rosenberg. A justificativa está relacionada a liderança. Para o executivo, clareza mental e capacidade de comunicação são importantes independentemente da tecnologia ou função profissional. Uma das ideias que ele destacou do livro é aprender a interpretar a intenção e o significado por trás do que uma pessoa diz, em vez de reagir apenas às palavras utilizadas. Essa habilidade se torna ainda mais importante em situações difíceis. Na visão do CEO, liderança depende de pessoas e, consequentemente, depende da capacidade de comunicar objetivos, problemas e decisões com clareza. A recomendação encerrou uma conversa que começou falando sobre vulnerabilidades, inteligência artificial e plataformas de segurança, mas terminou justamente no componente humano. Entre a tecnologia atual e aquela que ainda será criada, a visão apresentada por Thakar permanece centrada em uma questão: cibersegurança precisa ser capaz de demonstrar qual risco existe para o negócio, decidir qual risco realmente merece prioridade e provar que as ações realizadas conseguiram reduzi-lo.

A Agência de Segurança Cibernética e de Infraestrutura dos Estados Unidos (CISA) adicionou quatro vulnerabilidades críticas que afetam Apple macOS, Microsoft SharePoint, VMware vCenter e Microsoft Internet Key Exchange (IKE) ao catálogo Known Exploited Vulnerabilities (KEV), indicando que as falhas já estão sendo exploradas em ataques reais. Todas as vulnerabilidades receberam correções de seus respectivos fabricantes, mas relatos públicos apontam diferentes campanhas de exploração. Três das quatro falhas possuem pontuação CVSS 9,8. No macOS, a CVE-2026-65400 é uma vulnerabilidade de autenticação inadequada que pode permitir que um invasor conectado à rede se autentique no recurso Screen Sharing sem possuir credenciais válidas. A falha recebeu CVSS 9,8 e já foi utilizada em ataques para instalar um minerador da criptomoeda Monero. A CVE-2026-55040, com CVSS 9,1, afeta o Microsoft SharePoint. O problema está relacionado a um mecanismo de autenticação fraco e pode permitir que um invasor não autorizado contorne um recurso de segurança remotamente. Segundo relatos públicos, a exploração da vulnerabilidade no SharePoint começou após a divulgação de um código proof-of-concept (PoC). Até o momento, os responsáveis pelos ataques não foram identificados. Ataques ao VMware vCenter atingem 47 países Entre as vulnerabilidades adicionadas ao catálogo está a CVE-2026-59310, falha crítica de path traversal no VMware vCenter, da Broadcom, com pontuação CVSS 9,8. Um invasor com acesso de rede ao vCenter pode explorar o problema para executar código arbitrário. A exploração foi associada a um possível grupo de ameaça persistente avançada (APT) ligado à China. Os ataques utilizaram um backdoor e binários "reverse_ssh" para manter acesso persistente aos servidores comprometidos. Em pelo menos um caso, a invasão também resultou na implantação de um ransomware derivado do Babuk. A campanha comprometeu 361 endereços IP únicos de vítimas em 47 países. A maior concentração foi registrada na Alemanha, com 55 sistemas afetados, seguida pelos Estados Unidos, com 41; Turquia, com 38; Irã, com 26; e França, com 25. Falha no Microsoft IKE também é explorada A quarta vulnerabilidade, CVE-2026-33824, possui CVSS 9,8 e afeta as extensões do serviço Microsoft Internet Key Exchange (IKE). Trata-se de uma falha do tipo "double free" que pode permitir a execução remota de código por um invasor não autenticado através da rede. De acordo com a Unit 42, da Palo Alto Networks, a vulnerabilidade vem sendo explorada por outro grupo de hackers de língua chinesa. A atividade foi observada em paralelo a uma campanha autônoma de hacking baseada em inteligência artificial, na qual os responsáveis utilizaram o DeepSeek, além de conduzirem operações manuais explorando vulnerabilidades conhecidas, incluindo a falha no Microsoft IKE. A inclusão das quatro vulnerabilidades no catálogo KEV representa uma confirmação da CISA de que existem evidências de exploração ativa. Órgãos civis federais dos Estados Unidos têm até 21 de agosto de 2026 para atualizar os sistemas vulneráveis e seguir as diretrizes de correção estabelecidas pela BOD 26-04. Para outras organizações, a presença das vulnerabilidades no KEV aumenta a prioridade das atualizações, principalmente em sistemas acessíveis pela rede ou expostos à internet.

Pesquisadores da Varonis Threat Labs divulgaram três vulnerabilidades no Microsoft Copilot Personal que poderiam permitir que um invasor roubasse silenciosamente dados de aplicativos conectados após a vítima clicar em um link especialmente preparado. As falhas foram agrupadas sob o nome CoSnitch e são rastreadas como CVE-2026-24301. Segundo a Varonis, o problema foi reportado à Microsoft em dezembro de 2025 e recebeu correções em 18 de agosto de 2026. A pesquisa trata especificamente do Copilot Personal, versão para consumidores disponível em copilot.microsoft.com. O relatório não afirma que o mesmo comportamento afetava o Microsoft 365 Copilot. Não foram encontradas evidências de exploração da CoSnitch em ataques reais. Um dos pontos centrais da descoberta foi um parâmetro de URL não documentado chamado "autorun=1". Curiosamente, segundo os pesquisadores, o próprio Copilot revelou sua existência durante os testes. A Varonis utilizou uma abordagem que chama de "meta-hacking": os pesquisadores perguntaram repetidamente ao Copilot por que determinado prompt não poderia ser executado automaticamente, sem interação do usuário. Nas respostas, o assistente forneceu justificativas técnicas até mencionar o parâmetro "autorun=1", as condições necessárias para seu funcionamento e mecanismos de proteção que supostamente deveriam tê-lo desabilitado. Quando os pesquisadores construíram uma URL seguindo as informações fornecidas pelo próprio Copilot, descobriram que o parâmetro ainda funcionava. O ataque combinava "autorun=1" com o parâmetro existente "q". Isoladamente, "q" apenas preenche o campo de entrada do Copilot. Quando os dois eram utilizados juntos, porém, um prompt controlado pelo atacante podia ser executado automaticamente assim que a vítima abrisse o link. Segundo a Varonis, depois de iniciada, a execução continuava até o fim mesmo que a vítima fechasse imediatamente a aba do Copilot. Dados de e-mail, calendário e Google Drive podiam ser acessados A primeira vulnerabilidade identificada permitia a execução automática do prompt dentro da sessão autenticada da vítima. Na prática, a instrução fornecida pelo invasor recebia as mesmas capacidades que um comando digitado diretamente pelo usuário. A segunda possibilitava utilizar esse prompt para consultar serviços que a vítima já havia autorizado no Copilot. Os dados obtidos podiam ser codificados e enviados para um webhook controlado pelo invasor por meio do próprio recurso de acesso a URLs do assistente. A técnica não concedia novas permissões ao Copilot nem ampliava os privilégios da vítima. O ataque explorava os acessos que o usuário já havia autorizado. Durante os testes, os pesquisadores afirmam ter conseguido recuperar conteúdo de mensagens de e-mail, assuntos, remetentes e destinatários. Também foram acessados títulos de eventos do calendário, participantes, horários e locais. No Google Drive, o Copilot retornou nomes de arquivos e resumos de metadados. Os pesquisadores também conseguiram obter conversas anteriores mantidas com o assistente, além de instruções e regras armazenadas na memória do Copilot. A documentação da Microsoft estabelece que serviços externos precisam ser previamente autorizados pelo usuário e que os conectores operam utilizando as permissões existentes da conta. Portanto, a exploração não dava ao invasor acesso a informações que o próprio usuário não pudesse acessar por meio do Copilot. Segundo a Varonis, as solicitações utilizadas para retirar os dados também poderiam parecer, no nível de rede, semelhantes aos acessos realizados normalmente pelo Copilot ao resumir páginas da web. A codificação em Base64 poderia ainda dificultar filtros que procuram determinados padrões de informações sensíveis em requisições de saída. Ataque também podia manipular a memória do Copilot A terceira vulnerabilidade identificada pela Varonis utiliza um caminho diferente. Uma página web maliciosa poderia inserir instruções na memória do Copilot quando seu conteúdo fosse resumido pelo assistente. Essas instruções poderiam permanecer armazenadas e influenciar conversas futuras, caracterizando um ataque de envenenamento de memória por meio de prompt injection indireto. De acordo com os pesquisadores, a instrução persistente sobrevivia a mudanças de senha, revogação de sessão e novo registro do dispositivo. Ela permanecia ativa até ser explicitamente excluída nas configurações de memória do Copilot. A Varonis afirma ainda que essa alteração não gerava processo, arquivo ou conexão de rede específica que pudesse ser facilmente identificada por ferramentas tradicionais de segurança. A instrução armazenada podia ser visualizada na própria interface de memória do Copilot. Problemas relacionados à manipulação da memória de assistentes da Microsoft já haviam sido reportados anteriormente. Pesquisadores como Håkon Måløy e Johann Rehberger documentaram técnicas envolvendo prompt injection e memória tanto no Microsoft 365 Copilot quanto no assistente voltado ao consumidor. A Microsoft também abordou essa classe de ataques em junho, explicando que, no Microsoft 365 Copilot, as memórias passam por mecanismos de sanitização e detecção de prompt injection. A empresa também afirmou que atualizações de memória no ambiente corporativo podem ser registradas em logs de auditoria e consultadas por ferramentas como Defender Advanced Hunting e Sentinel. Essas informações, porém, dizem respeito ao Microsoft 365 Copilot, e não necessariamente ao Copilot Personal analisado pela Varonis. Microsoft corrigiu as vulnerabilidades A Varonis recomenda que usuários revisem quais aplicativos estão conectados ao Copilot e desconectem aqueles que não são necessários, além de terem cautela com links que abrem diretamente assistentes de inteligência artificial. Não foi indicada nenhuma atualização de cliente que precise ser instalada pelos usuários. Segundo a Varonis, a Microsoft implementou as correções em 18 de agosto. O relatório também não esclarece se a correção remove automaticamente eventuais instruções maliciosas gravadas na memória antes da atualização. A Varonis afirma que memórias injetadas permanecem armazenadas até serem explicitamente excluídas. A descoberta ocorre menos de duas semanas depois de a mesma equipe divulgar o RovoBlast, ataque de um clique contra o assistente Rovo, da Atlassian. Nesse caso, um parâmetro de URL também podia ser utilizado para inserir instruções controladas pelo invasor na sessão autenticada de um usuário.

Uma vulnerabilidade crítica foi descoberta no Forminator Forms, plugin para WordPress com mais de 600 mil instalações ativas. A falha pode permitir que invasores sem autenticação enviem arquivos PHP maliciosos e, sob determinadas condições, executem código remotamente no servidor. Identificada como CVE-2026-15748, a vulnerabilidade recebeu pontuação 9,8 de 10 no sistema CVSS. O problema foi descoberto e reportado por um pesquisador que utiliza o pseudônimo "daroo". Segundo a Wordfence, a falha permite o upload arbitrário de arquivos, incluindo código PHP executável. Caso a exploração seja bem-sucedida, um invasor pode alcançar execução remota de código (RCE) e potencialmente assumir o controle completo do site. A vulnerabilidade afeta todas as versões do Forminator até a 1.56.1. A correção foi disponibilizada na versão 1.56.2, lançada em 31 de julho de 2026. A exploração, porém, depende de uma configuração específica. O site vulnerável precisa possuir um formulário contendo simultaneamente um campo de upload de arquivos e um campo do tipo Select. Tecnicamente, o problema está na função "handle_file_upload()", que não realiza validação suficiente do tipo de arquivo fornecido pelo usuário. A lista utilizada pelo plugin para bloquear extensões perigosas faz uma correspondência exata que pode ser contornada por chaves de tipos MIME com alternativas separadas por pipe. Esse comportamento é combinado com um manipulador público de submissões que aceita configurações do campo de upload controladas pelo invasor e inseridas por meio de um valor Select forjado. Dessa forma, um atacante sem autenticação pode enviar um formulário especialmente preparado e fazer upload de um arquivo PHP malicioso. Se o arquivo puder ser executado pelo servidor web, o atacante passa a executar seu próprio código no ambiente WordPress, abrindo caminho para o comprometimento completo do site. Por padrão, os arquivos enviados pelo Forminator são armazenados em um diretório protegido por um arquivo ".htaccess" que impede a execução de PHP, o que reduz a possibilidade de exploração em instalações com a configuração padrão. O risco aumenta quando o administrador configura um diretório personalizado para armazenamento dos uploads. Segundo a Wordfence, esse local pode não receber a mesma proteção porque o diretório é criado somente quando necessário, durante uma requisição no frontend em que o componente do WordPress responsável por gerar o arquivo ".htaccess" não está carregado. Nessa situação, acessar diretamente o arquivo PHP enviado pode ser suficiente para que o servidor execute o código controlado pelo invasor. Outra falha crítica permite assumir conta de administrador A divulgação ocorre poucos dias depois de a Wordfence detalhar outra vulnerabilidade crítica, desta vez no plugin User Profile Builder, presente em mais de 40 mil instalações ativas do WordPress. Registrada como CVE-2026-15826 e também classificada com CVSS 9,8, a falha pode permitir que um invasor sem autenticação faça login como o usuário de ID 1, normalmente correspondente ao administrador do WordPress, e assuma o controle do site. O problema afeta todas as versões anteriores à 3.16.5, lançada em 16 de julho de 2026. Entretanto, a vulnerabilidade só pode ser explorada em sites que tenham a configuração "Automatically Log In" habilitada. A falha ocorre na função "wppb_log_in_user()". Quando um registro é realizado com um nome de usuário entre 61 e 70 caracteres, o núcleo do WordPress rejeita a solicitação e retorna um objeto WP_Error. O plugin, porém, chama a função "absint()" antes de verificar esse erro. O objeto acaba sendo convertido para o número inteiro 1, fazendo com que o mecanismo de login automático associe a operação ao usuário de ID 1. Com isso, um invasor não autenticado pode obter acesso à conta de administrador e assumir o controle do site. Administradores que utilizam o Forminator Forms devem atualizar o plugin para a versão 1.56.2 ou posterior. Já usuários do User Profile Builder devem instalar a versão 3.16.5 ou mais recente, especialmente em ambientes onde o login automático está habilitado.

Pesquisadores da Wiz identificaram uma vulnerabilidade de injeção de comandos em um workflow do GitHub Actions no repositório público snowflakedb/snowflake-connector-net, da Snowflake. Durante testes autorizados, a falha permitiu executar comandos a partir de uma issue especialmente preparada e obter um token de API interno do Jira. O problema estava no arquivo ".github/workflows/jira_issue.yml", executado automaticamente quando uma issue pública era aberta no repositório. O mesmo workflow tinha acesso às variáveis JIRA_BASE_URL, JIRA_USER_EMAIL e JIRA_API_TOKEN. Segundo a análise, o título e o conteúdo das issues, controlados por usuários externos, eram inseridos diretamente em um bloco shell "run:". Isso criava uma condição de workflow injection, na qual dados não confiáveis podiam ser interpretados como comandos pelo runner do GitHub Actions. O workflow também verificava a propriedade "github.event.pull_request.user.login", embora o evento processado fosse uma issue. Como essa propriedade de pull request não existia naquele contexto, o GitHub Actions a avaliava como uma string vazia. Com isso, a comparação utilizada para bloquear determinados eventos não impedia que uma issue comum chegasse à etapa vulnerável. Durante testes de segurança autorizados, o sistema Red Agent, da Wiz, tentou explorar a injeção. Depois que um primeiro payload provocou um erro de sintaxe no shell, o sistema alterou a abordagem e conseguiu receber uma conexão externa originada do runner do GitHub Actions. Os pesquisadores afirmam que, a partir da exploração, conseguiram obter o token da API do Jira utilizado pelo workflow. De acordo com a Wiz, a credencial pertencia à conta qa@snowflake.net e fornecia acesso de leitura a projetos internos relacionados a engenharia, conformidade de segurança e acompanhamento de programas de bug bounty no ambiente Jira da Snowflake. As permissões completas da conta, os registros de execução do workflow e os logs de auditoria do Jira não foram divulgados publicamente. A Wiz informou a vulnerabilidade à Snowflake por meio do HackerOne em 23 de junho de 2026, no relatório #3819931. A empresa implementou uma correção no mesmo dia por meio do pull request #1402. A mudança eliminou a expansão direta das expressões provenientes do GitHub dentro do shell. Os dados passaram a ser armazenados em variáveis de ambiente e fornecidos ao "jq" como argumentos, reduzindo o risco de que conteúdo controlado por usuários seja interpretado como comandos. O workflow vulnerável havia chegado à branch padrão cinco dias antes, em 18 de junho, após a integração do pull request #1218. O tratamento corrigido permanece na branch master do repositório. Segundo declaração da Snowflake reproduzida pela Wiz, a investigação da empresa não encontrou evidências de acesso não autorizado. O token do Jira foi rotacionado em 24 de junho, e a análise também não teria identificado uso externo não relacionado da credencial durante os cinco dias em que ela ficou exposta. Os logs de auditoria utilizados nessa investigação, porém, não foram publicados. Papel do GitHub Copilot não está confirmado A Wiz descreveu a vulnerabilidade como resultado de uma alteração do GitHub Copilot Autofix, mas o histórico disponível no GitHub não confirma que o Copilot tenha sido responsável especificamente pelas linhas vulneráveis do arquivo "jira_issue.yml". O commit explicitamente identificado como coautorado pelo Copilot, 6d0e2fa, modificou o arquivo "jira_close.yml". Já a alteração insegura em "jira_issue.yml" aparece em outro commit, 094038e, de 25 de agosto de 2025, atribuído pelo GitHub a sfc-gh-hpathak. Posteriormente, as duas mudanças foram incorporadas ao squash merge 4a1b8ce, de 18 de junho, que lista o Copilot Autofix entre seus coautores. O histórico confirma, portanto, a participação do Copilot no pull request #1218, mas não permite atribuir a ele a autoria do código vulnerável. O GitHub já havia documentado esse tipo de workflow injection em julho de 2025, recomendando que dados não confiáveis provenientes de issues não fossem expandidos diretamente em blocos "run:" e que variáveis de ambiente intermediárias fossem utilizadas. Até 17 de agosto de 2026, não havia CVE, pontuação CVSS ou registro no catálogo Known Exploited Vulnerabilities (KEV) da CISA associado ao problema. Também não foi identificada nenhuma versão do Snowflake Connector for .NET afetada, já que a vulnerabilidade estava restrita à automação de CI/CD do repositório. A interpolação vulnerável já foi removida da branch master. As informações disponíveis também não indicam exploração maliciosa da falha em ambiente real nem comprometimento de clientes da Snowflake.

O GitLab lançou atualizações de segurança emergenciais para corrigir uma vulnerabilidade crítica nas edições Community Edition (CE) e Enterprise Edition (EE) que, sob determinadas condições, pode permitir que invasores sem autenticação modifiquem ou excluam remotamente projetos públicos e dados de usuários. Identificada como CVE-2026-19478, a falha recebeu classificação Critical pelo GitLab e pontuação 9,4 no sistema CVSS. O problema está relacionado ao GraphQL e pode ser explorado pela rede sem que o atacante possua credenciais ou dependa de qualquer interação da vítima. A atualização foi disponibilizada em 17 de agosto de 2026, fora do calendário habitual do GitLab, que normalmente publica correções duas vezes por mês, na segunda e na quarta quarta-feira. O patch emergencial chegou apenas cinco dias depois de uma atualização regular que não continha vulnerabilidades classificadas como críticas. O problema afeta somente instalações autogerenciadas do GitLab. GitLab.com e GitLab Dedicated já executam versões corrigidas e, segundo a empresa, seus clientes não precisam tomar nenhuma medida. As correções estão disponíveis nas versões GitLab 19.2.4, 19.1.6, 19.0.8 e 18.11.11. São vulneráveis todas as versões da 18.2 anteriores à 18.11.11, a linha 19.0 antes da 19.0.8, a 19.1 antes da 19.1.6 e a 19.2 antes da 19.2.4. As ramificações 18.2 a 18.10 permanecem dentro da faixa afetada e não receberam a correção. Administradores que utilizam essas versões precisam migrar para uma versão suportada que contenha o patch. De acordo com o GitLab, a CVE-2026-19478 pode permitir que um usuário não autenticado modifique ou exclua projetos públicos e dados de usuários por meio de uma diretiva GraphQL. A empresa, porém, não informou qual diretiva está envolvida nem detalhou as condições específicas necessárias para explorar a vulnerabilidade. Até 18 de agosto, o alerta de segurança não indicava exploração ativa da falha, e nenhum código público de exploração havia sido identificado no GitHub. A mesma atualização também corrige a CVE-2026-19650, vulnerabilidade de alta severidade com pontuação CVSS 7,1. O problema consiste em uma falha de Cross-Site Request Forgery (CSRF) no mecanismo responsável pelo processamento de consultas GraphQL multiplex. Nesse segundo caso, a exploração exige interação do usuário. Segundo o GitLab, a vulnerabilidade poderia permitir, sob determinadas condições, que um usuário não autenticado executasse mutações por meio de requisições GET devido à validação inadequada das solicitações no processamento de consultas GraphQL multiplex. A empresa informou que a atualização não introduz novas migrações e não deve exigir indisponibilidade em implantações com múltiplos nós. A divulgação ocorre após pesquisadores publicarem, em julho de 2026, código de exploração funcional para outra vulnerabilidade que afetava servidores GitLab autogerenciados. O GitLab também informou que os registros detalhando cada vulnerabilidade serão publicados em seu rastreador de issues 90 dias após o lançamento das respectivas correções. Com isso, informações técnicas adicionais sobre as CVE-2026-19478 e CVE-2026-19650 devem se tornar públicas por volta de meados de novembro de 2026.

Pesquisadores de segurança identificaram uma campanha de typosquatting que distribuiu pacotes maliciosos nos ecossistemas RubyGems e npm para infectar computadores Windows e roubar credenciais de navegadores, carteiras de criptomoedas, seed phrases, dados do Telegram e outras informações sensíveis. A atividade foi descoberta pela OpenSourceMalware em 15 de agosto de 2026 e recebeu o nome de StubMaker. Inicialmente, a investigação encontrou 16 pacotes maliciosos publicados no RubyGems. Uma atualização posterior revelou que o mesmo responsável também distribuiu 37 pacotes no npm, totalizando 53 pacotes associados à campanha. No RubyGems, foram identificados os pacotes ubnuler, ubnlder, ri18nr, reaker, rakier, orakw, joxn, ise18n, ioe18n, ie18u, iai8n, i1l8n, i18om, activesupmport, brumdler e brundlef. Segundo os pesquisadores, os nomes tentavam imitar dependências Ruby populares por meio de pequenos erros de digitação, técnica conhecida como typosquatting. Os 16 gems foram publicados por contas identificadas como "mod8rz41mje", associada ao nome Riley Miller, e "rbq95bwt6q", vinculada a Alex Davis. Os pacotes já foram removidos do RubyGems. Em pelo menos dois casos, brumdler e brundlef, os invasores também exploraram um comportamento do RubyGems que permite que um namespace seja reivindicado novamente depois que todas as versões anteriores de um gem são removidas. Os pacotes haviam sido originalmente publicados por outra conta antes de serem recuperados pelos responsáveis pela campanha. Jenn Gile, cofundadora da OpenSourceMalware, afirmou que essa característica, combinada com a possibilidade de preencher o campo de autor sem validação, facilitou a operação. Segundo ela, depois que um gem malicioso era removido, os invasores podiam criar outra conta e publicar uma nova versão usando o mesmo nome. O campo "Author" também podia receber qualquer texto, sem precisar corresponder ao proprietário da conta. Com isso, os responsáveis atribuíram autores diferentes aos pacotes para tentar fazer com que parecessem não relacionados, embora vários deles fossem controlados pelas mesmas contas. A cadeia de ataque do StubMaker explora o arquivo "extconf.rb", normalmente usado durante a instalação de gems que possuem extensões nativas escritas em linguagens como C, C++ ou Rust. O arquivo é executado automaticamente durante a instalação do pacote, de forma semelhante aos lifecycle hooks utilizados pelo npm. No ataque, o "extconf.rb" funciona como mecanismo para baixar um loader de aproximadamente 22 MB desenvolvido em Rust e hospedado em uma release do GitHub. Esse loader executa um infostealer escrito em Go e identificado como "wincfg". A conta do GitHub utilizada na operação já não está acessível. O malware incorpora ainda a DLL "abe_payload.dll", usada para extrair credenciais de navegadores baseados em Chromium contornando as proteções App-Bound Encryption (ABE) introduzidas pelo Google. Entre os navegadores visados estão Google Chrome, Microsoft Edge, Brave, Opera, Opera GX, Vivaldi, Yandex, Avast, AVG e CCleaner Browser. Além das credenciais, o infostealer coleta dados de extensões, histórico de navegação e números de cartões de pagamento. O malware também procura carteiras de criptomoedas e seed phrases, extrai informações do Telegram Desktop, reúne dados do sistema e consulta o serviço api.ipify.org para identificar o endereço IP público da vítima. As informações roubadas são compactadas em um arquivo ZIP protegido por senha e enviadas ao serviço Gofile. O link resultante para download é então transmitido aos responsáveis pelo ataque por meio de uma conexão HTTP sem criptografia para a infraestrutura associada ao domínio "dresslee.com". O nome StubMaker está relacionado à forma como o malware mascara sua execução. Em vez de realmente compilar uma extensão, o pacote cria um Makefile com operações vazias e scripts para Unix e Windows que apenas retornam sucesso. Dessa forma, a instalação aparenta ter concluído normalmente enquanto o download e a execução do malware ocorrem no próprio hook do instalador. Campanha também atingiu o npm A investigação foi posteriormente ampliada após pesquisadores identificarem 37 pacotes npm relacionados à mesma operação. Eles utilizavam um hook "postinstall" para baixar o mesmo loader hospedado no GitHub e instalar o infostealer em sistemas Windows. Os pacotes imitavam bibliotecas populares como axios, chalk, commander, lodash, typescript e react. Entre os nomes utilizados estavam axois-http, axious-core, chalk-core, chalk-lib, comand, comander-cli, commander-lib, loadashjs, lodash-lib, typescirpt-cli, typscript-cli, typescriptt-cli e raectjs, além de diversas outras variações com erros de digitação. Segundo a OpenSourceMalware, trata-se do mesmo responsável operando duas frentes de typosquatting contra ecossistemas diferentes, compartilhando o mesmo payload e a mesma infraestrutura de comando e controle. Apesar da finalidade semelhante, a execução apresentou diferenças. Os gems utilizavam "extconf.rb", enquanto os pacotes npm recorriam ao hook "postinstall". No RubyGems, a URL do loader era codificada em Base64; no npm, o instalador empregava XOR com chave fixa para ocultá-la. O padrão de publicação também mudou. Os gems foram distribuídos durante dois dias, enquanto os pacotes npm foram enviados em apenas oito minutos por cinco contas diferentes. De acordo com Gile, a estratégia no npm reduzia a dependência de uma única conta, dificultando a interrupção de todo o lote caso apenas um perfil fosse detectado. Os pacotes npm foram publicados em 16 de agosto e também já foram removidos. A OpenHack recomenda que usuários que tenham instalado qualquer um deles em uma máquina Windows enquanto estavam disponíveis isolem o equipamento, troquem as credenciais potencialmente expostas e removam as bibliotecas maliciosas.

Uma análise dos 5 mil domínios mais utilizados da internet identificou violações dos padrões HTML em 87,2% dos sites avaliados. Os problemas vão de erros de estruturação do código a falhas de acessibilidade que podem dificultar a navegação de pessoas que dependem de leitores de tela. O levantamento foi realizado pelo ValidateHTML, projeto mantido pelo desenvolvedor francês independente Théo Ducreux. A seleção dos domínios foi baseada no ranking do projeto de pesquisa Tranco e inclui grandes serviços como Google, YouTube e Akamai, além de domínios utilizados principalmente para redirecionamento ou comunicação entre produtos e servidores. Dos 5 mil domínios examinados, 2.656 apresentavam uma página inicial destinada à leitura por usuários. Ainda assim, considerando todos os endereços analisados, Ducreux contabilizou 100.305 violações de HTML, incluindo especificações do HTML5, além de 18.863 erros de CSS. Segundo o levantamento, apenas 12,8% dos sites apresentavam HTML completamente válido. Quando também são considerados erros e alertas relacionados às boas práticas, somente 2,6% dos domínios passaram pela análise sem qualquer ocorrência. Os padrões definidos pelo World Wide Web Consortium (W3C) e pelo WHATWG ajudam navegadores, leitores de tela e outras ferramentas a interpretar páginas de maneira consistente. Embora navegadores modernos consigam corrigir ou ignorar muitos erros automaticamente, outras tecnologias podem ter menor tolerância a códigos fora das especificações. Esse problema aparece principalmente na acessibilidade. Mais de um terço dos sites falhou nas verificações dessa categoria. Cerca de 20,4% não apresentavam textos alternativos em imagens, recurso importante para descrever conteúdo visual a usuários de leitores de tela. Além disso, 41,6% das páginas apresentavam ausência de rótulos ARIA usados para identificar regiões e elementos da interface. A falta dessas informações pode dificultar a compreensão da estrutura de uma página por tecnologias assistivas. “Leitores de tela não têm nem de longe a tolerância a erros do Chrome, então uma marcação que parece perfeitamente normal para você pode estar quebrada para alguém usando tecnologia assistiva”, afirmou Ducreux. As falhas de acessibilidade também podem representar um problema de conformidade. Na Europa, o European Accessibility Act, em vigor desde 2025, ampliou as exigências relacionadas à acessibilidade de determinados produtos e serviços digitais. Nos Estados Unidos, empresas também podem enfrentar disputas relacionadas à falta de acessibilidade de serviços online. Para realizar o estudo, Ducreux desenvolveu seu próprio web crawler e utilizou ferramentas open source como HTML-validate, CSS Validator, Lightning CSS e fast-xml-parser. O código do site, o sistema de pontuação e a lógica utilizada no rastreamento foram desenvolvidos por ele, sem equipe, financiamento ou empresa por trás do projeto. Um dos fatores que contribuem para o problema é justamente a capacidade dos navegadores modernos de interpretar códigos incorretos. Em muitos casos, erros de HTML não provocam consequências visíveis porque o navegador tenta reconstruir automaticamente a estrutura pretendida pelo desenvolvedor. Frameworks de front-end também podem introduzir problemas durante o processo de construção das páginas. A falha mais frequente encontrada pelo ValidateHTML, presente em mais de 59% dos sites, foi o posicionamento incorreto de elementos, incluindo aninhamento inadequado de tags. Segundo Ducreux, muitos desses erros são criados automaticamente durante o processo de build e não necessariamente escritos manualmente pelos desenvolvedores. O próprio pesquisador não considera o HTML inválido uma ameaça à existência da web, principalmente porque navegadores são capazes de contornar grande parte dessas inconsistências. O impacto, porém, torna-se mais relevante quando as páginas são processadas por outras tecnologias. Agentes de inteligência artificial, assistentes de voz, ferramentas de tradução e leitores de tela também precisam interpretar a estrutura das páginas. Para Ducreux, seguir as especificações ajuda a garantir que o conteúdo tenha o mesmo significado para diferentes sistemas, em vez de depender exclusivamente da capacidade dos navegadores de corrigir erros.

A Stripe teria fechado um acordo para adquirir a OpenRouter por pelo menos US$ 7 bilhões, em uma operação que colocaria uma das maiores empresas de pagamentos digitais em uma posição estratégica na infraestrutura usada para acessar e comercializar modelos de inteligência artificial. A OpenRouter funciona como um gateway de IA, permitindo que desenvolvedores e empresas utilizem diferentes modelos por meio de uma única plataforma, sem precisar criar integrações separadas para cada fornecedor. Com a aquisição, a Stripe passaria a atuar como intermediária não apenas dos pagamentos, mas também do consumo de tokens entre empresas, aplicações e provedores de IA. A Stripe não confirmou a negociação. A empresa informou que não comenta rumores ou especulações. Antes das informações sobre a conclusão de um acordo, reportadas pela Bloomberg, o Wall Street Journal já havia noticiado que as companhias estavam negociando uma possível aquisição. Para Akhil Verghese, fundador e CEO da desenvolvedora de software de IA Krazimo, existe uma relação direta entre os negócios das duas empresas: enquanto a Stripe criou uma camada de infraestrutura para pagamentos, a OpenRouter ocupa uma posição semelhante entre aplicações e modelos de IA. O valor estimado da operação chama atenção. Segundo Verghese, a OpenRouter havia captado recursos em maio com uma avaliação pós-investimento de US$ 1,3 bilhão. Uma aquisição por pelo menos US$ 7 bilhões representaria uma valorização superior a cinco vezes em apenas três meses. A lógica estratégica estaria no crescimento do consumo de tokens. Um estudo econômico chamado “AI Premium” estima que modelos de linguagem processam globalmente entre 5 e 7 quadrilhões de tokens por mês, com aproximadamente 2% desse volume passando pela OpenRouter. A plataforma também vem crescendo rapidamente. Em dezembro de 2025, a OpenRouter informava atender mais de 5 milhões de desenvolvedores, conectando usuários a mais de 300 modelos de mais de 70 fornecedores. Atualmente, a empresa afirma possuir mais de 10 milhões de desenvolvedores e trabalhar com 80 provedores. Dados citados pela Andreessen Horowitz mostram a escala desse mercado. Em outubro de 2025, a OpenAI processava aproximadamente 8,6 trilhões de tokens diariamente, enquanto a OpenRouter já ultrapassava 1 trilhão de tokens por dia. Esse crescimento ocorre enquanto empresas buscam reduzir a dependência de um único fornecedor de IA. Embora OpenAI e Anthropic tenham desenvolvido ecossistemas em torno de seus próprios modelos, clientes corporativos podem optar por gateways para alternar entre diferentes tecnologias, controlar custos e preservar poder de negociação. Nesse cenário, serviços como a OpenRouter ocupam uma camada intermediária cada vez mais relevante. Em vez de uma aplicação depender diretamente de um único modelo, um gateway pode encaminhar solicitações para diferentes provedores conforme requisitos como preço, desempenho e disponibilidade. Modelos de pesos abertos também estão conquistando uma parcela maior desse mercado. Segundo dados da Vercel, a participação desses modelos nos gastos com tokens processados por gateways aumentou de 11% em abril para 36% em julho. No mesmo período, a parcela dos gastos destinada aos quatro maiores laboratórios de modelos de fronteira, que havia permanecido acima de 93% durante sete meses, caiu para 89%. Parte da mudança foi associada ao crescimento de laboratórios chineses como Z.ai e Moonshot, com modelos GLM 5.2 e Kimi K3. Apesar da expansão das alternativas abertas, os principais laboratórios norte-americanos continuam concentrando a maior parcela da receita. Segundo a Vercel, eles receberam 95% dos gastos realizados por meio de seu AI Gateway em junho. A Anthropic, por exemplo, recebeu 65% dos gastos processados pelo gateway da Vercel em julho, embora representasse 30% do volume de tokens. O preço médio de seus tokens foi 4,4 vezes superior à média dos demais laboratórios. Ao mesmo tempo, os modelos de pesos abertos estão capturando mais receita. Depois de quase triplicarem sua participação no volume de tokens entre abril e junho, de 11% para 29%, sua participação na receita passou de cerca de quatro para quase nove centavos de cada dólar movimentado pelos gateways. O avanço ocorreu mesmo com uma redução de 13,6% no preço médio dos tokens em julho. Caso empresas continuem distribuindo suas cargas entre diferentes modelos, especialmente alternativas abertas e mais econômicas, os gateways de IA podem assumir um papel ainda maior na infraestrutura do setor. Para a Stripe, controlar uma plataforma desse tipo significaria ter visibilidade tanto sobre os pagamentos quanto sobre o fluxo de consumo de modelos. A possível aquisição também levanta dúvidas sobre a neutralidade da OpenRouter. Verghese observa que um gateway deve encaminhar cargas de trabalho de acordo com as necessidades dos clientes, sem favorecer determinados fornecedores. Caso essa independência seja comprometida sob o controle da Stripe, a confiança na plataforma poderia ser afetada.

A empresa chinesa de inteligência artificial Zhipu apresentou o GLM-5.3, novo modelo que, segundo a companhia, alcançou desempenho superior a modelos da OpenAI e da Anthropic em um benchmark voltado à descoberta e exploração de vulnerabilidades. Nos testes divulgados pela Zhipu, o GLM-5.3 superou o Fable 5 e o GPT-5.6 Sol no CyberGym, benchmark desenvolvido para avaliar a capacidade de modelos de IA de resolver desafios de cibersegurança baseados em cenários reais. Segundo a empresa, as capacidades de segurança do modelo avançaram mais rapidamente do que o esperado durante a etapa de pós-treinamento. O principal ganho teria ocorrido não apenas na identificação de falhas isoladas, mas na capacidade de raciocinar sobre diferentes estágios de exploração. A Zhipu afirma que o GLM-5.3 passou a desenvolver planos coerentes envolvendo cadeias completas de exploração, conectando diferentes vulnerabilidades e etapas necessárias para comprometer um sistema. A companhia também testou o modelo em bases de código reais em colaboração com empresas chinesas. De acordo com os resultados divulgados, o GLM-5.3 encontrou 2.436 vulnerabilidades em 269 projetos, das quais 1.097 foram classificadas como de média a alta severidade. As falhas foram identificadas em diferentes tipos de software e infraestrutura, incluindo kernels de sistemas, sistemas operacionais, motores de navegadores, projetos de infraestrutura open source, aplicações web e protocolos de rede. Algumas dessas vulnerabilidades teriam permanecido sem identificação durante anos ou décadas. Segundo a Zhipu, a falha mais antiga encontrada pelo modelo estava presente no código havia aproximadamente 40 anos. Os resultados, porém, não indicam superioridade generalizada do GLM-5.3. O modelo chinês apresentou desempenho inferior aos concorrentes ocidentais em outros benchmarks de programação e segurança avaliados. Ainda assim, o desempenho no CyberGym e os resultados reportados em projetos reais indicam o avanço das capacidades de modelos chineses aplicados à pesquisa de vulnerabilidades. Esse tipo de tecnologia pode automatizar etapas que tradicionalmente exigem análise manual de código, investigação de falhas e desenvolvimento de cadeias de exploração. A evolução também reduz uma possível vantagem tecnológica dos Estados Unidos nessa área. Modelos avançados de IA estão sendo cada vez mais avaliados não somente pela capacidade de encontrar vulnerabilidades, mas também por compreender como diferentes falhas podem ser combinadas durante uma exploração. Os números divulgados são resultados apresentados pela própria Zhipu e devem ser interpretados dentro desse contexto. Embora o CyberGym permita comparar capacidades específicas, o desempenho de um modelo em um benchmark não necessariamente representa sua eficácia em todos os cenários de segurança ou desenvolvimento de software.