Terceira edição do Inside Pentesting da Vantico analisou centenas de testes conduzidos pela Vantico em 2025 e o cenário de ameaças que se constrói em 2026. A discussão sobre segurança ofensiva costuma girar em torno de um único problema: identificar vulnerabilidades. Mas os dados da terceira edição do Inside Pentesting, um estudo anual produzido pela Vantico com base em centenas de pentest realizados, revelam que o verdadeiro gap pode estar em outro lugar. Das vulnerabilidades classificadas como altas, 27% permanecem abertas por mais de 70 dias após a entrega do relatório. Ou seja, mesmo com o relatório em mãos, as falhas já identificadas, classificadas e documentadas, muitas vezes até com recomendações de correção, as empresas não estão conseguindo corrigir no ritmo que as ameaças exigem. O dado é preocupante por si só. Mas, no contexto atual, em que campanhas de phishing geradas com IA cresceram 1.265% e atacantes começam a explorar falhas publicadas em questão de horas, ele se torna ainda mais crítico. O que mudou no perfil dos testes em 2025 O estudo também analisou como as empresas estão testando e revelou uma preferência na metodologia escolhida para os testes. O gray box, modalidade em que o tester recebe contexto parcial antes da execução, foi utilizado em 55,9% dos projetos, superando o black box pelo segundo ano consecutivo. Esse movimento reflete uma escolha estratégica: o gray box é especialmente indicado para empresas que querem simular o perfil de um atacante com acesso parcial ao ambiente, como acontece quando um parceiro é comprometido. Outro dado que chama atenção é o crescimento das APIs como superfície de ataque testada: de 5,6% dos projetos em 2024 para 11,2% em 2025, praticamente o dobro. Isso reflete a expansão das arquiteturas de microsserviços e integrações digitais, que ampliam significativamente a superfície de ataque das empresas sem que as equipes de segurança acompanhem no mesmo ritmo. Misconfiguration ainda domina, mas o número surpreende Security Misconfiguration (A05:2021) respondeu por 43,2% de todas as vulnerabilidades identificadas. Esse número representa mais que o dobro da segunda colocada, Identification and Authentication Failures, com 10,9%. Isso representa que quase metade de todas as falhas encontradas em 2025 derivam desta vulnerabilidade. Muitos problemas de misconfiguration já são amplamente conhecidos, com soluções publicadas e, mesmo assim, continuam extremamente recorrentes. Outro dado interessante apontado foi de que as vulnerabilidades críticas caíram de 7,8% para 5,08%, e as altas de 15,4% para 8,01%. Em um primeiro momento, essa parece ser uma boa notícia. Mas este número exige cautela, uma vez que menos vulnerabilidades críticas podem significar mais maturidade das empresas ou indicar que os ambientes mais críticos não estão sendo testados com a frequência necessária. A correção não acompanhou o diagnóstico em 2025 Enquanto os números de vulnerabilidades encontradas trazem algum otimismo, os dados de remediação vão na direção oposta. 16% das vulnerabilidades críticas permaneceram sem correção por mais de 70 dias após a entrega do relatório. Para as altas, esse percentual sobe para 27%. O estudo aponta que esse atraso pode estar ligado a duas causas: a dificuldade de integrar correções ao cotidiano operacional e a dificuldade de priorização, mesmo quando o relatório já traz classificações por impacto e probabilidade de exploração. A consequência disso é uma ampla janela entre a identificação da falha e sua correção, o que mantém o ambiente extremamente vulnerável por mais tempo. O estudo também revelou que esse dado mostra diferenças consideráveis por setor: Jurídico (11%), Turismo (14,3%) e Energia (16,7%) registraram as menores taxas de correção de vulnerabilidades críticas e altas, enquanto Telecomunicações e Varejo atingiram 100% de remediação. Os dados completos de remediação por setor, incluindo os SLAs médios por severidade, estão disponíveis no estudo. O balanço da segurança ofensiva em 2025 Os dados internos da Vantico devem ser analisados ao lado do que aconteceu no cenário de ameaças em 2025. Phishing e engenharia social foram o principal vetor de ataque externo do ano, com a IA impulsionando as campanhas maliciosas. Houve um crescimento de 1.265% em ataques de phishing gerados com inteligência artificial, com mensagens cada vez mais personalizadas e difíceis de identificar. Em 2025, 16% das violações de dados envolveram uso de IA pelos invasores, sendo 37% para geração de phishing e 35% para deepfakes. Além disso, um alerta: o fator humano esteve presente em 60% dos vazamentos de dados do ano. Todos esses dados reforçam por que a janela de 70 dias de exposição é tão perigosa. Os atacantes estão cada vez mais rápidos e eficientes, e muitas organizações não conseguem acompanhar esse ritmo. O cenário de ameaças que se constrói para 2026 Das cinco tendências de segurança mapeadas pelo estudo, duas merecem destaque nesta análise. A primeira é a IA como sistema operacional dos atacantes. Ou seja, a tendência mais relevante não é o surgimento de novos tipos de ataques, mas a potencialização dos que já existem. Grupos antes limitados por capacidade técnica agora têm acesso a ferramentas que personalizam as campanhas, automatizam o reconhecimento e geram conteúdo convincente em alto volume. Isso muda o perfil de ameaça para empresas que antes se julgavam fora do radar dos grupos mais sofisticados. A segunda é a gestão de identidades no centro. Com Identification and Authentication Failures em segundo lugar no ranking de falhas e o crescimento das APIs como superfície de ataque, o estudo aponta que a gestão de identidades exigirá atenção especial em 2026. O estudo completo, com outras análises, mais previsões e recomendações, está disponível gratuitamente neste link.

O desenvolvimento do Linux continua avançando rapidamente, e a futura versão 7.1 já começa a ganhar forma com uma mudança relevante: a introdução de um novo driver NTFS com suporte completo de leitura e escrita diretamente no kernel. A novidade promete melhorar a integração com o ecossistema Windows, embora também sinalize uma possível substituição de soluções existentes. O novo driver foi desenvolvido por Namjae Jeon, conhecido por contribuições importantes em sistemas de arquivos, incluindo melhorias no suporte ao exFAT. O projeto é, na prática, uma modernização do antigo driver NTFS do kernel — originalmente limitado a leitura — agora atualizado para suportar escrita e adaptado às arquiteturas modernas do Linux. Diferente do que pode parecer à primeira vista, essa mudança não representa uma revolução em desempenho. O suporte ao NTFS no Linux já existe há décadas. Desde 1997, o kernel já permitia leitura de partições NTFS, e posteriormente soluções como o NTFS-3G trouxeram suporte de escrita via FUSE (em modo usuário), embora com limitações de performance e funcionalidades. O cenário mudou em 2021, quando a Paragon Software contribuiu com um driver NTFS completo para o kernel, conhecido como NTFS3 . Essa implementação trouxe suporte nativo de leitura e escrita com melhor desempenho, mas exigia manutenção contínua — um desafio significativo em projetos complexos dentro do kernel Linux . Foi justamente nesse ponto que surgiu a nova abordagem. Namjae Jeon iniciou um trabalho de reestruturação do driver original, focando em código mais limpo, moderno e sustentável a longo prazo. O resultado é um driver que não apenas adiciona suporte de escrita, mas também incorpora recursos atuais do kernel, como large folios, fallocate, permissões avançadas e idmapped mounts. Do ponto de vista técnico, a principal diferença está na qualidade e manutenção do código. O novo driver foi projetado para ser mais fácil de evoluir, com melhor organização e documentação — fatores críticos em projetos open source de longo ciclo de vida. Os testes também reforçam essa evolução. O novo driver passou por 326 testes de conformidade ( xfstests ), superando os 273 testes atendidos pelo NTFS3 da Paragon. Isso indica maior robustez e compatibilidade com diferentes cenários de uso. A cadeia de impacto dessa mudança é relevante. Com um driver mais moderno e mantido ativamente dentro do kernel, a tendência é que ele se torne a implementação padrão no futuro. Inicialmente, ele será opcional, podendo ser ativado via configuração (Kconfig), mas o histórico do kernel indica que soluções mais bem mantidas tendem a prevalecer ao longo do tempo. Isso coloca a solução da Paragon em uma posição delicada. Embora o NTFS3 continue presente no kernel por enquanto, há sinais claros de que sua substituição pode ocorrer em versões futuras, caso o novo driver se consolide como padrão. Para usuários, especialmente aqueles que trabalham em ambientes híbridos entre Linux e Windows, a mudança representa uma melhoria incremental na compatibilidade e confiabilidade. Já para o ecossistema open source, o caso reforça uma lição importante: em projetos de infraestrutura crítica, a qualidade e a manutenção do código são tão importantes quanto a funcionalidade em si. No fim, mais do que uma evolução técnica, o novo driver NTFS simboliza a capacidade do Linux de evoluir continuamente, revisitando soluções antigas e adaptando-as às necessidades atuais — mesmo que isso signifique substituir contribuições relativamente recentes.

A Microsoft, por meio do GitHub, decidiu interromper temporariamente novas assinaturas do GitHub Copilot para planos individuais. A medida afeta as modalidades Pro, Pro+ e Student e foi adotada diante de um cenário crescente de pressão sobre infraestrutura e custos operacionais. Segundo a empresa, o principal fator por trás da decisão é a evolução dos chamados “agentic workflows” — fluxos de trabalho baseados em agentes de IA que executam tarefas mais complexas, paralelas e de longa duração. Esse novo padrão de uso aumentou significativamente o consumo computacional, superando a capacidade inicialmente projetada para os planos atuais. Na prática, isso significa que o modelo de negócio original do Copilot começou a se tornar insustentável. Diferente de interações simples, os novos agentes podem executar cadeias extensas de raciocínio, consumir grandes volumes de tokens e permanecer ativos por longos períodos, elevando drasticamente o custo por usuário — muitas vezes acima do valor pago na assinatura. A cadeia de impacto começa na arquitetura da IA. Cada interação com o Copilot aciona modelos de linguagem que processam requisições, geram respostas e, em cenários mais avançados, executam múltiplas etapas em paralelo. Com a popularização dessas funcionalidades, a demanda por GPU, memória e processamento em datacenters cresceu de forma exponencial, pressionando provedores de cloud e exigindo ajustes emergenciais. Para conter o problema, o GitHub já vinha adotando medidas progressivas. Inicialmente, suspendeu testes gratuitos do Copilot Pro após detectar abuso. Agora, além da pausa nas novas assinaturas, a empresa anunciou o endurecimento dos limites de uso para clientes existentes. Dois mecanismos principais passaram a ser reforçados: limites por sessão e limites semanais. Os limites de sessão controlam o uso durante períodos de alta demanda, evitando que usuários monopolizem recursos. Já os limites semanais restringem o consumo total de tokens, especialmente em tarefas longas e paralelizadas, que geram custos elevados. Outro ponto crítico envolve o modelo de cobrança. Atualmente, o Copilot utiliza um sistema baseado em requisições, mas esse modelo se mostrou inadequado diante de workloads imprevisíveis. Em muitos casos, uma única requisição pode gerar um consumo muito maior do que o esperado, especialmente quando envolve raciocínios complexos de IA. Por isso, a empresa sinaliza uma transição para um modelo baseado em consumo de tokens, mais alinhado ao custo real de processamento. Essa mudança segue uma tendência já observada em outras plataformas de IA, que buscam equilibrar sustentabilidade financeira com escalabilidade. O impacto dessa crise de capacidade não se limita ao GitHub. Outros players do mercado também vêm enfrentando desafios semelhantes. Empresas como Anthropic, Google e OpenAI já implementaram políticas para limitar uso, redistribuir carga e reduzir consumo em horários de pico — um indicativo claro de que a infraestrutura global de IA ainda não acompanha o ritmo da demanda. Além disso, provedores de cloud como Amazon Web Services e Google Cloud também enfrentam dificuldades para expandir capacidade na mesma velocidade, refletindo um gargalo estrutural no setor. Como parte das mudanças, o GitHub também anunciou ajustes nos modelos disponíveis. Versões mais antigas e custosas da Anthropic, como Opus 4.5 e 4.6, serão removidas dos planos Pro+, sendo substituídas por versões mais recentes, porém com custo potencialmente maior por requisição . A decisão também gerou insatisfação entre usuários, especialmente aqueles que adquiriram planos anuais com expectativas diferentes de uso. O GitHub informou que clientes têm até 20 de maio para solicitar reembolso, caso não concordem com as novas condições. O episódio evidencia um ponto crítico no avanço da inteligência artificial: a diferença entre inovação tecnológica e viabilidade operacional. Enquanto os agentes de IA evoluem rapidamente, a infraestrutura necessária para sustentá-los — incluindo datacenters, GPUs e energia — ainda está em fase de expansão. No fim, o caso do Copilot reforça uma tendência clara: o futuro da IA não será definido apenas por capacidade técnica, mas também por eficiência econômica e gestão de recursos em larga escala.

Um novo levantamento do Gartner revela uma mudança silenciosa, porém consistente, no mercado global de sistemas de gerenciamento de banco de dados (DBMS). Embora as transformações ocorram de forma gradual, o recado é claro: os grandes fornecedores tradicionais estão, aos poucos, perdendo espaço para plataformas cloud e novos players impulsionados por dados, analytics e inteligência artificial. De acordo com a análise, entre os líderes de 2011 — Oracle, IBM, Microsoft e SAP — apenas a Microsoft conseguiu aumentar sua participação de mercado ao longo dos últimos 15 anos. Os demais perderam espaço para gigantes da nuvem como Amazon Web Services, Google Cloud Platform, além de empresas emergentes como Snowflake, Databricks e MongoDB. A metodologia do estudo considera exclusivamente receita, o que significa que bancos de dados open source como PostgreSQL, MySQL e Cassandra aparecem apenas quando integrados a serviços comerciais. Ainda assim, o impacto dessas tecnologias é evidente quando analisado sob outras métricas, como adoção por desenvolvedores e tendências de mercado. No topo do ranking, o cenário permanece relativamente estável desde 2022, com AWS, Microsoft, Oracle, Google Cloud e IBM ocupando as primeiras posições. No entanto, a estabilidade esconde uma mudança estrutural importante: a crescente dependência de soluções baseadas em nuvem e o avanço acelerado de plataformas orientadas a dados e IA. Um dos destaques recentes é a ascensão da Cockroach Labs, responsável pelo CockroachDB — um banco relacional distribuído com compatibilidade com PostgreSQL. A empresa vem ganhando espaço rapidamente, refletindo uma tendência mais ampla de adoção de arquiteturas distribuídas e resilientes, especialmente em ambientes cloud-native. A transformação do mercado está diretamente ligada a três fatores principais: computação em nuvem, analytics avançado e inteligência artificial. Esses elementos estão redefinindo a forma como aplicações são desenvolvidas e operadas, exigindo bancos de dados mais flexíveis, escaláveis e integrados a pipelines de dados modernos. Nesse contexto, a posição da Oracle merece atenção especial. Líder histórica do mercado até 2019, a empresa ainda mantém forte presença em ambientes corporativos tradicionais. No entanto, sua relevância tende a diminuir à medida que sistemas legados são substituídos por novas aplicações construídas diretamente na nuvem. O desafio da Oracle não está apenas na tecnologia, mas também no modelo de adoção. Em ambientes já baseados em suas soluções, a continuidade faz sentido. Porém, em projetos novos — especialmente aqueles nativos de cloud — a empresa frequentemente não aparece como primeira escolha, principalmente diante da ampla oferta de alternativas open source e serviços gerenciados mais flexíveis. A Oracle Cloud Infrastructure surge como tentativa de reposicionamento, mas ainda enfrenta dificuldades para competir com os líderes do mercado em termos de participação. Sua estratégia depende fortemente da base instalada de clientes corporativos para impulsionar a adoção da nuvem. Outro ponto relevante é a diferença entre participação de mercado e popularidade entre desenvolvedores. Em rankings como o DB-Engines e pesquisas da comunidade, bancos como PostgreSQL e MySQL apresentam forte crescimento. Em 2023, por exemplo, PostgreSQL se tornou o banco de dados mais popular entre desenvolvedores, enquanto a Oracle caiu para a nona posição em levantamentos da Stack Overflow . Esse contraste evidencia uma mudança geracional no ecossistema de dados. Enquanto grandes empresas ainda mantêm investimentos estratégicos em plataformas tradicionais, novas aplicações estão sendo construídas sobre tecnologias mais abertas, distribuídas e alinhadas ao modelo cloud-first. Apesar disso, a mudança não será abrupta. O mercado de bancos de dados é conhecido por sua inércia, devido à criticidade dos sistemas envolvidos e ao alto custo de migração. A tendência, portanto, é de uma transição gradual, com coexistência entre soluções legadas e modernas por muitos anos. No longo prazo, porém, a direção parece definida: a influência da Oracle tende a diminuir à medida que o mercado evolui para arquiteturas mais flexíveis e orientadas a dados. Ainda assim, a empresa deve manter relevância por um longo período, especialmente em grandes ambientes corporativos e aplicações críticas.

A agência de cibersegurança dos Estados Unidos, CISA, emitiu um alerta urgente sobre a exploração ativa de vulnerabilidades críticas na plataforma Cisco Catalyst SD-WAN Manager. Três falhas foram adicionadas ao catálogo de vulnerabilidades exploradas ativamente (Known Exploited Vulnerabilities – KEV), com um prazo extremamente curto: apenas quatro dias para que órgãos federais realizem a correção. A plataforma afetada ocupa um papel central em ambientes corporativos, sendo responsável pela orquestração de redes SD-WAN e capaz de gerenciar até 6.000 dispositivos de borda em um único cluster. Isso significa que uma exploração bem-sucedida não compromete apenas um equipamento isolado, mas potencialmente toda a infraestrutura distribuída da organização. As vulnerabilidades identificadas são as seguintes: A CVE-2026-20128 envolve uma falha de exposição de informações no recurso Data Collection Agent (DCA). Essa brecha permite que um invasor remoto, sem autenticação, obtenha privilégios de usuário dentro do sistema — um cenário crítico, já que elimina a necessidade de credenciais iniciais. A CVE-2026-20133 também trata de exposição de informações sensíveis, possibilitando que um invasor remoto não autenticado visualize dados internos do sistema, o que pode servir como base para ataques mais sofisticados. Já a CVE-2026-20122 representa um risco ainda mais grave. Trata-se de uma falha de sobrescrita arbitrária de arquivos que pode ser explorada por um invasor autenticado, mesmo com permissões limitadas de leitura via API. A partir disso, é possível enviar arquivos maliciosos, sobrescrever componentes locais e escalar privilégios até o nível de usuário do vManage. A cadeia de ataque, nesse contexto, pode seguir um fluxo relativamente direto. Inicialmente, o invasor explora falhas de exposição de informações para mapear o ambiente e obter dados sensíveis. Em seguida, utiliza credenciais válidas — possivelmente obtidas ou já existentes — para explorar a vulnerabilidade de sobrescrita de arquivos, implantando código malicioso no sistema. A partir daí, ganha persistência, eleva privilégios e pode assumir controle da plataforma de gerenciamento, impactando toda a rede SD-WAN. Embora as correções tenham sido disponibilizadas pela Cisco ainda no final de fevereiro, a exploração ativa começou a ser observada em março de 2026. Até o momento, há confirmação de ataques utilizando as falhas CVE-2026-20128 e CVE-2026-20122, enquanto a CVE-2026-20133 ainda não foi oficialmente listada como explorada — embora esteja no radar das autoridades. O impacto potencial dessas vulnerabilidades é significativo. Em ambientes corporativos, o SD-WAN Manager é o ponto de controle central da rede. Comprometê-lo pode permitir que invasores manipulem políticas de roteamento, interceptem tráfego, criem túneis maliciosos, movimentem-se lateralmente e até interrompam serviços críticos. Em setores como financeiro, saúde e infraestrutura, isso pode resultar em indisponibilidade operacional, vazamento de dados e prejuízos financeiros relevantes. Esse tipo de incidente reforça uma tendência preocupante no cenário atual: a crescente exploração de sistemas de gerenciamento centralizado. Em vez de atacar endpoints individuais, invasores estão focando em plataformas que oferecem controle amplo sobre múltiplos ativos — uma abordagem mais eficiente e com maior potencial de impacto. A inclusão dessas falhas no catálogo KEV da CISA indica que a exploração já é considerada confiável e recorrente no mundo real. Para organizações que utilizam a solução da Cisco , o recado é direto: a janela de resposta é curta, e o risco de comprometimento é elevado.

Uma falha grave de segurança na plataforma de desenvolvimento assistido por IA Lovable expôs dados sensíveis de usuários, incluindo credenciais, histórico de chats e códigos-fonte. O caso ganhou repercussão não apenas pelo impacto técnico, mas principalmente pela forma como a empresa respondeu inicialmente às descobertas — negando a existência de um vazamento e atribuindo o problema a um suposto “comportamento intencional” da plataforma. O problema foi identificado por um pesquisador independente que demonstrou que qualquer usuário com uma conta gratuita conseguia acessar informações de outros clientes sem necessidade de técnicas avançadas de exploração. Bastaram algumas chamadas de API para obter acesso a perfis, projetos públicos e até credenciais de banco de dados expostas dentro do código. Esse tipo de falha é classificado como BOLA (Broken Object Level Authorization) , uma das vulnerabilidades mais críticas no contexto de APIs modernas, pois indica ausência de validação adequada de autorização entre usuários. Na prática, a cadeia de ataque era simples, mas extremamente eficaz. Primeiro, o invasor criava uma conta comum na plataforma. Em seguida, realizava requisições diretas à API explorando endpoints que não validavam corretamente a propriedade dos dados. A partir daí, era possível navegar entre projetos de outros usuários, acessar históricos de interação com a IA e extrair informações sensíveis embutidas no código, como credenciais e dados de clientes. O fato de não exigir exploração sofisticada aumenta significativamente o risco, já que reduz a barreira de entrada para abusos em larga escala. Inicialmente, a Lovable tentou minimizar o impacto, afirmando que não houve violação de dados e que o comportamento observado fazia parte do design da plataforma. A empresa alegou que projetos configurados como “públicos” permitiam visualização ampla por padrão e que o problema estaria na falta de clareza da documentação. No entanto, essa justificativa não foi bem recebida pela comunidade, especialmente porque usuários não tinham plena consciência de que seus dados — incluindo chats e código — poderiam estar expostos dessa forma. Com a pressão crescente, a empresa revisou sua posição e admitiu falhas no processo. Um dos pontos mais críticos revelados foi uma alteração interna feita em fevereiro de 2026, durante a unificação de permissões no backend, que acabou reativando inadvertidamente o acesso aos chats de projetos públicos. Esse erro reintroduziu uma vulnerabilidade que já havia sido mitigada anteriormente, evidenciando fragilidades no controle de mudanças e testes de segurança. Outro elemento relevante do caso envolve o processo de reporte da falha. O pesquisador afirmou ter comunicado o problema com antecedência por meio do programa de bug bounty, operado pela plataforma HackerOne. No entanto, o reporte foi tratado como duplicado e não escalado corretamente, sob a interpretação de que o comportamento observado era esperado. A própria Lovable confirmou posteriormente que a falha não chegou à equipe interna devido a essa avaliação equivocada, o que atrasou a correção e ampliou a janela de exposição. Do ponto de vista de segurança, o incidente reforça um padrão recorrente em plataformas baseadas em IA e APIs: a combinação de crescimento acelerado, complexidade de permissões e decisões de design centradas em experiência do usuário frequentemente abre espaço para falhas críticas de autorização. Em ambientes onde código, dados e interações com IA coexistem, a exposição indevida pode ter impacto direto sobre propriedade intelectual, dados corporativos e informações pessoais. Além disso, o caso evidencia riscos associados à dependência de terceiros na gestão de vulnerabilidades. Embora programas de bug bounty sejam uma prática consolidada, a triagem inadequada de relatórios pode comprometer todo o ciclo de resposta a incidentes. Nesse cenário, a governança sobre o processo de disclosure se torna tão importante quanto a própria correção técnica da falha. Empresas como Uber, Zendesk e Deutsche Telekom, que utilizam a plataforma, entram automaticamente no radar de risco indireto, já que a exposição de código e credenciais pode abrir caminho para ataques em cadeia, comprometendo ambientes mais amplos. Isso amplia o impacto do incidente, que deixa de ser apenas um problema pontual de aplicação para se tornar uma questão de segurança de ecossistema. No fim, o episódio serve como um alerta claro: em plataformas modernas, especialmente aquelas baseadas em IA e APIs, falhas de autorização continuam sendo uma das ameaças mais subestimadas — e potencialmente mais devastadoras — para a segurança de dados.

Em meio ao conflito em curso no Oriente Médio, veículos ligados ao regime iraniano passaram a afirmar que os Estados Unidos teriam usado supostas backdoors ou até uma botnet para derrubar equipamentos de rede de fabricantes como Cisco, Juniper, Fortinet e MikroTik dentro do país. Segundo esses relatos, parte da infraestrutura teria reiniciado ou simplesmente perdido conectividade durante ataques recentes, algo que Teerã tenta apresentar como prova de sabotagem embutida em hardware e firmware estrangeiros. Até o momento, porém, essas alegações não foram verificadas de forma independente. O ponto mais sensível dessa narrativa é que ela sugere não apenas uma operação cibernética pontual, mas uma capacidade de interferência pré-posicionada em equipamentos de borda e backbone. A hipótese ventilada por fontes iranianas é a de que haveria uma porta de acesso oculta em firmware ou bootloader, capaz de ser acionada remotamente em horário predeterminado ou até por algum sinal externo. Outra versão menciona a possibilidade de os dispositivos já estarem comprometidos por uma botnet, o que permitiria ao invasor acionar falhas coordenadas mesmo com o país operando sob forte isolamento da internet global. Até aqui, contudo, não há evidência pública que comprove nenhuma dessas teses. Do ponto de vista técnico, a acusação é grave porque atinge o coração da confiança em cadeias de suprimentos de tecnologia. Se fosse verdadeira, significaria que o ataque não dependeria apenas de exploração tradicional de vulnerabilidades expostas na internet. A cadeia poderia envolver comprometimento anterior do equipamento, abuso de mecanismos de gerenciamento, manipulação de firmware, persistência em baixo nível e ativação sincronizada em um momento crítico do conflito. Em ambientes de telecomunicações e infraestrutura estatal, um evento assim poderia gerar reinicializações em massa, perda de rotas, interrupção de enlaces, falhas em VPNs, indisponibilidade de firewalls e degradação generalizada de serviços. Ainda assim, sem telemetria, amostras ou análises forenses públicas, essas possibilidades permanecem no campo da especulação. A dificuldade de confirmar os relatos aumenta porque o próprio Irã segue sob um apagão digital prolongado. A organização NetBlocks informou que o bloqueio da internet no país chegou a 52 dias, com a população em geral ainda desconectada das redes internacionais e com sinais de acesso seletivo para grupos favorecidos. Esse cenário reduz drasticamente a transparência e dificulta tanto a coleta independente de evidências quanto a validação dos impactos reais sobre a infraestrutura de rede mencionada pelos meios iranianos. É nesse vácuo informacional que a China entrou com força na disputa de narrativa. A mídia estatal chinesa passou a dar destaque às alegações iranianas para reforçar uma linha já conhecida de Pequim: a de que os EUA seriam o verdadeiro grande vilão do ciberespaço e que acusações contra a China serviriam apenas para desviar atenção. Esse discurso aparece com frequência em publicações do CVERC, órgão chinês que já sustentou, em relatórios e comunicados anteriores, que operações atribuídas a grupos chineses seriam, na verdade, campanhas de desinformação ou até ações de falsa bandeira conduzidas por Washington. O caso também ganha relevância porque ocorre num momento em que autoridades e analistas vêm discutindo de forma mais aberta o uso de capacidades cibernéticas como complemento a operações militares. Em março de 2026, o general Dan Caine afirmou que o US Cyber Command e o US Space Command atuaram como “first movers” para gerar efeitos não cinéticos, degradando e cegando a capacidade iraniana de enxergar, comunicar e reagir. Em outra referência oficial, o próprio Pentágono voltou a citar a Operação Midnight Hammer, conduzida em junho de 2025 contra alvos iranianos, como parte do repertório recente de pressão militar dos EUA sobre o país. Isso não comprova as acusações atuais sobre backdoors em equipamentos comerciais, mas mostra que operações cibernéticas e de guerra eletrônica estão claramente no tabuleiro. Para o mercado de cibersegurança, o episódio reacende um debate antigo e delicado: até que ponto países confiam em equipamentos de rede produzidos por fornecedores estrangeiros em contextos de alta tensão geopolítica. Essa discussão envolve segurança da cadeia de suprimentos, validação de firmware, revisão de código, controle sobre atualizações, segmentação de gerenciamento, hardening de plano de controle e dependência de tecnologias importadas em infraestruturas críticas. Em cenários de guerra ou de escalada diplomática, a simples suspeita de que um fabricante possa ser instrumentalizado por um Estado já é suficiente para provocar revisões estratégicas, substituição de fornecedores e fortalecimento de iniciativas de soberania digital. Outro aspecto importante é que alegações desse tipo tendem a embaralhar a fronteira entre incidente técnico real e operação psicológica. Mesmo que os desligamentos tenham ocorrido, as causas podem ser múltiplas: falhas operacionais, efeitos colaterais de isolamento de rede, sabotagem interna, malware já implantado anteriormente ou até interrupções deliberadas promovidas pelo próprio Estado. Sem dados técnicos verificáveis, o risco é transformar hipóteses em narrativa geopolítica pronta para consumo doméstico e internacional. No fim, o caso mostra como a guerra cibernética moderna não se resume a derrubar sistemas, mas também a controlar a interpretação pública sobre quem atacou, como atacou e com qual legitimidade.

A empresa aeroespacial Blue Origin, fundada por Jeff Bezos, enfrentou um cenário agridoce em seu mais recente lançamento. Embora tenha conseguido pousar com sucesso o primeiro estágio reutilizável do foguete New Glenn — um marco técnico importante — a missão falhou em seu objetivo principal: posicionar corretamente o satélite em órbita. O lançamento ocorreu no último domingo (19), a partir da base de Cabo Canaveral, nos Estados Unidos, marcando o terceiro voo do foguete New Glenn e a primeira tentativa de reutilização de seu primeiro estágio. A etapa inicial foi considerada um sucesso, com o pouso controlado na plataforma marítima Jacklyn, demonstrando avanços relevantes na estratégia da empresa de reduzir custos com reutilização. No entanto, o problema surgiu na fase mais crítica da missão: a inserção orbital da carga útil. O satélite Bluebird 7, da AST SpaceMobile , até conseguiu se separar corretamente do segundo estágio e foi ativado, mas acabou sendo colocado em uma órbita inferior ao planejado. Esse desvio comprometeu completamente a missão. Segundo a AST SpaceMobile, o satélite não possui capacidade suficiente para corrigir sua trajetória utilizando seus próprios propulsores, tornando impossível sua operação funcional. Como consequência, a empresa confirmou que o Bluebird 7 será desorbitado, encerrando prematuramente sua vida útil — embora o prejuízo financeiro deva ser coberto por seguro. A falha levanta questionamentos sobre o desempenho do segundo estágio do foguete, que até o momento não teve sua falha explicada pela Blue Origin. Esse ponto é particularmente sensível, já que a precisão na inserção orbital é um dos requisitos mais críticos em missões espaciais. Apesar do avanço com a reutilização do foguete — um feito dominado por empresas como a SpaceX — o fracasso na entrega da carga útil ofusca o sucesso parcial da missão. No setor espacial, o êxito é medido principalmente pela capacidade de colocar cargas em órbita funcional, e não apenas pelo desempenho do veículo lançador. O impacto pode ir além de uma única missão. A Blue Origin possui um cronograma ambicioso, incluindo projetos como o Blue Moon, um módulo robótico de pouso lunar, e contratos relacionados ao programa NASA Artemis, que prevê o retorno de humanos à Lua nos próximos anos. Além disso, a AST SpaceMobile contava com o Bluebird 7 como parte de sua constelação de satélites voltada para fornecer conectividade celular diretamente do espaço. A perda do equipamento pode atrasar planos de expansão da rede, embora a empresa já tenha outros satélites em preparação. O episódio reforça um ponto recorrente na indústria espacial: avanços tecnológicos podem coexistir com falhas críticas, especialmente em sistemas complexos como lançadores orbitais. Cada lançamento representa um teste real, onde pequenos desvios podem resultar em perdas milionárias.

A provedora de infraestrutura web Vercel confirmou um incidente de segurança que resultou no acesso não autorizado a sistemas internos da empresa. O ataque teve origem na comprometimento da ferramenta de inteligência artificial Context.ai, utilizada por um funcionário, evidenciando mais um caso crítico de ataque à cadeia de suprimentos digital. De acordo com a investigação, hackers exploraram o acesso à ferramenta externa para assumir o controle da conta corporativa do Google Workspace do colaborador. A partir desse ponto, conseguiram acessar ambientes internos da Vercel e variáveis de ambiente que não estavam classificadas como sensíveis . Embora dados críticos protegidos por criptografia não tenham sido comprometidos, um subconjunto limitado de clientes teve credenciais expostas. A cadeia de ataque demonstra um nível elevado de sofisticação. O vetor inicial pode estar ligado à infecção de um funcionário da Context.ai com o malware Lumma Stealer, conhecido por roubar credenciais e tokens de autenticação. Com isso, os invasores teriam obtido acesso a tokens OAuth, permitindo escalar privilégios e se movimentar lateralmente até atingir a infraestrutura da Vercel. Um dos pontos mais críticos do incidente foi o uso excessivo de permissões OAuth. Um funcionário da Vercel teria autorizado permissões amplas (“Allow All”) ao integrar sua conta corporativa com a plataforma da Context.ai, abrindo caminho para que o invasor explorasse essa confiança implícita entre sistemas. Esse tipo de falha reforça um problema recorrente em ambientes modernos: a dificuldade em controlar integrações entre aplicações SaaS. Além disso, o grupo hacker conhecido como ShinyHunters reivindicou a autoria do ataque e afirmou estar vendendo os dados obtidos por cerca de US$ 2 milhões, indicando possível monetização do incidente. Mesmo sem divulgação completa do escopo, a Vercel afirmou que está trabalhando com empresas especializadas como a Mandiant para investigar o caso e reforçar suas defesas. Entre as medidas recomendadas estão a rotação imediata de credenciais, auditoria de logs, revisão de variáveis de ambiente e análise de atividades suspeitas em deployments recentes. O incidente também levanta preocupações mais amplas sobre segurança em ambientes de desenvolvimento modernos, especialmente aqueles que dependem fortemente de integrações com ferramentas de IA e serviços de terceiros. A crescente adoção dessas tecnologias amplia a superfície de ataque e cria novos vetores para invasores explorarem. Do ponto de vista estratégico, o caso reforça a importância de práticas como o princípio do menor privilégio, controle rigoroso de acessos OAuth, monitoramento contínuo e segmentação de ambientes — especialmente em organizações que operam com pipelines de desenvolvimento altamente automatizados.

Uma nova ameaça digital voltada para ambientes industriais críticos está chamando a atenção de especialistas em cibersegurança. O malware ZionSiphon foi identificado como uma ferramenta projetada especificamente para atacar sistemas de tratamento de água e dessalinização em Israel, marcando mais um avanço preocupante na evolução de ataques contra infraestruturas críticas. A descoberta foi feita por pesquisadores da Darktrace , que analisaram o comportamento do código e identificaram capacidades avançadas, como escalonamento de privilégios, persistência no sistema, propagação via dispositivos USB e varredura de redes industriais (OT). A amostra foi detectada pouco tempo após um período de tensão geopolítica entre Irã e Israel, sugerindo possível motivação política por trás da ameaça. Do ponto de vista técnico, o ZionSiphon demonstra um encadeamento de ataque bem definido. Após a infecção inicial, o malware realiza reconhecimento do ambiente, identificando dispositivos na rede local e buscando serviços industriais específicos. Ele utiliza protocolos amplamente empregados em sistemas de controle industrial, como Modbus, DNP3 e S7comm, para interagir com equipamentos críticos. O objetivo final parece ser sabotagem operacional. O código contém rotinas capazes de alterar parâmetros sensíveis, como níveis de cloro e pressão em sistemas de água, o que poderia impactar diretamente o abastecimento e a segurança da população. Ainda que a versão analisada esteja incompleta, o direcionamento é claro: interferir fisicamente em processos industriais por meio de manipulação digital. Outro aspecto relevante é o uso de critérios específicos para ativação do malware. O ZionSiphon verifica tanto a localização geográfica — por meio de faixas de IP associadas a Israel — quanto características do ambiente, garantindo que a carga maliciosa seja executada apenas em alvos de interesse. Em sistemas fora desse escopo, o malware pode até se autodestruir, dificultando sua detecção. A capacidade de propagação via dispositivos removíveis reforça paralelos com campanhas históricas, como o Stuxnet, que também utilizava vetores físicos para alcançar ambientes isolados (air-gapped). Esse comportamento indica uma preocupação dos hackers em atingir redes industriais que não estão diretamente expostas à internet. Além do ZionSiphon, outras ameaças foram identificadas no mesmo contexto. Um implante baseado em Node.js chamado RoadK1ll foi projetado para criar túneis reversos e permitir movimentação lateral dentro de redes comprometidas, funcionando como um ponto de acesso persistente e discreto. Já o backdoor AngrySpark utiliza técnicas avançadas de ofuscação com máquina virtual para dificultar análises forenses e manter comunicação furtiva com servidores de comando e controle. O cenário reforça uma tendência crescente: ataques direcionados a sistemas OT estão se tornando mais sofisticados e estratégicos, muitas vezes ligados a conflitos geopolíticos. Diferente de ataques tradicionais focados em roubo de dados, essas campanhas têm potencial de causar impactos físicos reais, afetando serviços essenciais como água, energia e transporte.

Uma vulnerabilidade crítica identificada na arquitetura do Model Context Protocol (MCP), desenvolvido pela Anthropic, está acendendo um alerta significativo na indústria de inteligência artificial. A falha, considerada “by design”, abre caminho para execução remota de código (RCE) e pode impactar diretamente toda a cadeia de suprimentos de aplicações baseadas em IA. A análise conduzida pela OX Security aponta que o problema está enraizado na forma como o MCP gerencia configurações por meio da interface STDIO (entrada/saída padrão). Na prática, essa implementação permite que comandos arbitrários do sistema operacional sejam executados remotamente, comprometendo ambientes que utilizam o protocolo. Segundo os especialistas envolvidos na análise, a falha permite que hackers obtenham acesso direto a dados sensíveis, incluindo bancos de dados internos, chaves de API e históricos de conversas. O impacto é potencialmente massivo: mais de 7 mil servidores e pacotes de software expostos, somando mais de 150 milhões de downloads, podem estar vulneráveis. O problema não se limita a uma única aplicação. Ele afeta uma ampla gama de projetos populares no ecossistema de IA, como LangChain, LangFlow, Flowise e LiteLLM. Ao todo, foram identificadas pelo menos 10 vulnerabilidades associadas, incluindo falhas catalogadas como CVEs que envolvem injeção de comandos e execução remota. A cadeia de ataque é particularmente preocupante. Em muitos cenários, o invasor pode explorar configurações inseguras do MCP para injetar comandos diretamente via STDIO. Em outros casos, ataques mais sofisticados utilizam técnicas de prompt injection — inclusive em cenários “zero-click” — para modificar configurações e disparar execuções maliciosas sem interação do usuário. Há ainda vetores envolvendo marketplaces de MCP, onde requisições de rede podem acionar configurações ocultas e comprometer sistemas. Do ponto de vista técnico, o comportamento decorre de uma decisão arquitetural: o MCP foi projetado para iniciar servidores locais via STDIO e retornar um “handle” para o modelo de linguagem. No entanto, essa mesma lógica permite que qualquer comando válido seja executado antes mesmo de retornar um erro, criando uma brecha crítica para exploração. Embora falhas semelhantes tenham sido reportadas anteriormente em projetos como LibreChat, MCP Inspector e Cursor, o problema central persiste. A Anthropic, por sua vez, classificou o comportamento como “esperado” e optou por não alterar a arquitetura do protocolo, transferindo a responsabilidade de mitigação para os desenvolvedores. Esse posicionamento amplia o risco sistêmico. Como o MCP é utilizado como base para diversas integrações, a vulnerabilidade se propaga silenciosamente por múltiplas linguagens, bibliotecas e aplicações. Na prática, trata-se de um problema de supply chain: uma única decisão de design afetando todo um ecossistema. Para mitigar os riscos, especialistas recomendam uma série de medidas defensivas. Entre elas estão o bloqueio de acesso público a serviços sensíveis, monitoramento rigoroso de chamadas MCP, execução de serviços em ambientes isolados (sandbox), validação de qualquer entrada externa como não confiável e restrição à instalação de servidores MCP apenas de fontes verificadas. O caso evidencia uma tendência crescente no cenário de ameaças: à medida que sistemas baseados em IA se tornam mais integrados e automatizados, também ampliam significativamente sua superfície de ataque. A exploração de protocolos, SDKs e frameworks passa a ser um vetor estratégico para hackers, especialmente em ambientes onde automação e confiança implícita são predominantes.

O NIST anunciou uma mudança significativa na forma como gerencia e enriquece os registros de vulnerabilidades no banco de dados global CVE, após enfrentar um crescimento acelerado no número de falhas reportadas. A decisão marca uma ruptura com o modelo tradicional, no qual todas as vulnerabilidades recebiam análise detalhada e classificação de risco. A medida impacta diretamente o funcionamento da NVD, uma das principais bases de dados utilizadas globalmente por empresas, governos e ferramentas de segurança para priorização de correções e resposta a incidentes. Crescimento exponencial pressiona capacidade operacional Segundo o próprio NIST , o volume de vulnerabilidades submetidas ao sistema cresceu de forma insustentável. Apenas nos três primeiros meses de 2026, houve um aumento de quase um terço em comparação com o mesmo período do ano anterior. Em 2025, foram cerca de 42 mil CVEs analisados — um aumento de 45% em relação a anos anteriores —, mas ainda insuficiente para acompanhar o ritmo atual. O problema estrutural é agravado por limitações de recursos: a equipe responsável pela NVD permanece com apenas 21 profissionais, mesmo diante da escalada contínua de novas vulnerabilidades sendo descobertas e reportadas. Nova abordagem: priorização baseada em risco real Diante desse cenário, o NIST adotará uma estratégia de priorização. A partir de agora, apenas vulnerabilidades consideradas críticas ou com alto impacto terão seus registros “enriquecidos” — ou seja, receberão detalhes técnicos adicionais, como descrição completa e pontuação de severidade. Entre os critérios definidos, terão prioridade: Vulnerabilidades incluídas no catálogo de falhas exploradas ativamente da CISA Falhas presentes em softwares utilizados pelo governo dos Estados Unidos Vulnerabilidades classificadas como críticas em sistemas amplamente utilizados As demais vulnerabilidades continuarão sendo registradas, mas sem informações adicionais detalhadas — o que pode impactar diretamente processos de análise e priorização em empresas que dependem desses dados. Impacto direto na cadeia de defesa cibernética A mudança levanta preocupações na comunidade de segurança. O enriquecimento de CVEs é um componente essencial para diversas soluções de segurança, incluindo: Ferramentas de gestão de vulnerabilidades Sistemas de priorização de patches Plataformas de threat intelligence Soluções de detecção e resposta (SIEM, XDR, etc.) Sem essas informações, organizações podem enfrentar dificuldades para avaliar corretamente o risco de determinadas falhas e priorizar ações de mitigação. Além disso, o NIST informou que deixará de atribuir pontuações de severidade para todos os CVEs, passando a depender das avaliações fornecidas pelos próprios responsáveis pela submissão — o que pode gerar inconsistência e falta de padronização. Backlog e limitações estruturais continuam sendo desafio Outro ponto crítico é o backlog acumulado desde 2024, quando cortes de orçamento impactaram a operação do NIST. Na época, cerca de 90% das vulnerabilidades submetidas deixaram de ser analisadas. Agora, o órgão admite que não conseguirá processar esse volume acumulado. Como consequência, todos os CVEs pendentes com data anterior a março de 2026 serão movidos para a categoria “Not Scheduled”, indicando que não há previsão de análise. Embora o NIST afirme que continuará revisando esse backlog e priorizando casos críticos, especialistas alertam que vulnerabilidades potencialmente relevantes podem ficar sem análise detalhada. Papel da inteligência humana e novas tendências A decisão também reflete uma mudança mais ampla no cenário de cibersegurança. Com o aumento do uso de inteligência artificial para análise de código, há uma explosão no número de vulnerabilidades identificadas — muitas delas de baixo impacto, mas que ainda assim consomem recursos operacionais. Especialistas apontam que o modelo centralizado de triagem de vulnerabilidades pode não ser mais viável. Em vez disso, o futuro tende a priorizar sinais baseados em exploração real e inteligência ativa, conduzida por Pesquisadores e equipes de segurança atuando diretamente em ambientes reais. Infraestrutura crítica sob pressão A própria comunidade de segurança já classificou a NVD como uma “infraestrutura crítica” para o ecossistema global de cibersegurança, dado seu papel central na defesa contra exploração de vulnerabilidades. A redução na capacidade de análise pode ter efeitos em cadeia, impactando desde pequenas empresas até grandes organizações governamentais que dependem dessas informações para proteger seus sistemas.