Quando especialistas em redes começaram a desenhar a internet moderna, no início dos anos 1990, um problema ficou claro: o IPv4 não teria endereços suficientes para sustentar o crescimento da rede mundial. Com apenas 4,3 bilhões de endereços disponíveis, o risco de esgotamento poderia comprometer a adoção da internet e até impactar a economia global. A resposta veio em dezembro de 1995, com a publicação do RFC 1883 , que definiu oficialmente o IPv6. A principal mudança foi drástica: sair de endereços de 32 bits para 128 bits, elevando o total disponível para mais de 340 undecilhões de endereços um número tão grande que parecia garantir o futuro da internet por séculos. Na teoria, a migração seria natural. Bilhões de PCs, smartphones e dispositivos conectados passaram a fazer parte do cotidiano, e a expectativa era que os provedores abandonassem gradualmente o IPv4. Três décadas depois, porém, os números mostram outra realidade: menos da metade dos usuários globais de internet utilizam IPv6, segundo dados do Google , APNIC e Cloudflare . Por que o IPv6 não “decolou”? Um dos motivos centrais foi o próprio desenho do protocolo. Para o cientista-chefe do APNIC, Geoff Huston, o IPv6 foi “conservador demais”, mudando o mínimo possível além do espaço de endereçamento. O resultado foi um protocolo tecnicamente sólido, mas com poucos diferenciais práticos em relação ao IPv4. Além disso, o IPv6 não é retrocompatível com IPv4. Isso forçou empresas a escolherem entre um ou outro ou manterem os dois em paralelo, aumentando custos e complexidade. Para muitos operadores, o esforço não se justificava, especialmente porque recursos de segurança, qualidade de serviço e automação que ficaram de fora do IPv6 acabaram sendo implementados também no IPv4. Outro fator decisivo foi a popularização do NAT. A técnica permitiu que milhares de dispositivos compartilhassem um único endereço IPv4 público, prolongando artificialmente a vida útil do protocolo antigo e reduzindo a urgência da migração. Segundo analistas do Gartner, os custos de transição, a necessidade de treinamento e a falta de retorno imediato sobre o investimento também afastaram muitas organizações. Em alguns cenários, empresas chegaram a desabilitar o IPv6 por questões de desempenho ou compatibilidade. Um protocolo mal compreendido, não um fracasso Apesar da adoção lenta, especialistas defendem que chamar o IPv6 de fracasso é um erro. Para John Curran, presidente da ARIN, o objetivo nunca foi “desligar” o IPv4, mas permitir que a internet continuasse crescendo sem colapsar. Na prática, o IPv6 absorveu grande parte desse crescimento em ambientes móveis, banda larga e nuvem, mantendo o IPv4 funcional por mais tempo. Para o RIPE NCC, o grande mérito do IPv6 está em seu design de longo prazo, que facilita o planejamento de redes , impulsiona a Internet das Coisas (IoT) e viabiliza técnicas modernas como Segment Routing sobre IPv6. Ao mesmo tempo, novas arquiteturas de rede e protocolos como o QUIC reduziram ainda mais a dependência de endereços IP públicos permanentes. Hoje, serviços são identificados muito mais por nomes no DNS do que por IPs, o que muda o papel histórico do endereçamento na segurança e na autenticação. O futuro ainda passa pelo IPv6 Mesmo sem “dominar” a internet, o IPv6 segue relevante. Grandes organizações continuam adotando o protocolo em escala massiva, como a Huawei, que solicitou 2,56 decilhões de endereços IPv6, e a Starlink, que adquiriu cerca de 150 sextilhões. Esses movimentos já ajudam a elevar a adoção acima de 50% em diversos países. Para analistas, o caminho agora é pragmático: planejar a migração, garantir compatibilidade de aplicações e preparar a infraestrutura. O IPv6 pode não ter substituído o IPv4 como se imaginava nos anos 1990, mas cumpriu sua missão principal manter a internet crescendo. TR

As autoridades da Finlândia anunciaram nesta quarta-feira (1º) a apreensão de um navio suspeito de danificar um cabo submarino de telecomunicações no Mar Báltico, em mais um episódio que reacende preocupações sobre a segurança de infraestruturas críticas na região. O caso ocorre em meio a uma série de falhas recentes em cabos submarinos, detectadas nos últimos dias. Segundo o Ministério da Justiça da Estônia, parte desses incidentes pode estar relacionada às condições climáticas adversas, embora ao menos dois casos sigam sob investigação. As operadoras envolvidas afirmaram que não houve impacto nos serviços, graças a conexões redundantes que mantêm as comunicações ativas mesmo quando uma rota é comprometida. A Guarda de Fronteira finlandesa localizou o navio suspeito após receber, na madrugada da véspera de Ano-Novo, um alerta da operadora de telecomunicações Elisa. A falha foi identificada em um trecho de cabo da empresa que atravessa a zona econômica exclusiva da Estônia, ainda nas primeiras horas do dia 31 de dezembro. Também foram relatados danos em outro cabo submarino pertencente à operadora sueca Arelion. No momento em que o dano ocorreu, o navio sob suspeita foi identificado em trânsito da zona econômica exclusiva da Estônia para a da Finlândia. Até o momento, nenhum detalhe oficial sobre a embarcação foi divulgado. Ao localizar o navio, as autoridades constataram que a corrente da âncora estava baixada, arrastando-se pelo fundo do mar. A embarcação foi então instruída a se deslocar para uma área de ancoragem segura dentro das águas territoriais finlandesas. Em comunicado conjunto, as autoridades informaram que o controle da embarcação foi assumido pelo Estado finlandês e que a liderança da investigação passou da Guarda Costeira do Golfo da Finlândia para o Departamento de Polícia de Helsinque. Promotores locais já emitiram ordens de acusação, e o caso está sendo apurado como dano criminoso agravado, tentativa de dano criminoso agravado e interferência agravada em sistemas de telecomunicações. A apreensão do navio ocorre pouco mais de um ano após um caso semelhante, quando a polícia armada da Finlândia deteve o Eagle S, um petroleiro ligado à Rússia , suspeito de danificar múltiplos cabos submarinos no Natal de 2024. Na ocasião, a tentativa de responsabilizar criminalmente oficiais da embarcação acabou fracassando devido a disputas jurídicas sobre a jurisdição do país. O Eagle S havia partido do porto russo de Ust-Luga transportando gasolina e diesel e era apontado por países ocidentais como parte da chamada “frota fantasma” russa um conjunto estimado em até mil navios antigos, com estruturas de propriedade opacas, utilizados para exportar produtos sancionados, especialmente petróleo. Os danos causados por essa embarcação estiveram entre os mais investigados em uma sequência de incidentes no Mar Báltico, que levantaram suspeitas sobre possíveis atos de sabotagem direcionados a infraestruturas críticas. Em resposta, a NATO anunciou o reforço das patrulhas no Mar Báltico, incluindo o emprego de fragatas, aeronaves de patrulha marítima e um pequeno contingente de drones navais. Apesar disso, autoridades de diversos países europeus da região do Mar do Norte e do Mar Báltico afirmaram que cresce a convicção de que muitos desses incidentes foram acidentais, e não resultado de ações coordenadas pelo Kremlin. Segundo um funcionário europeu ouvido sob condição de anonimato, tripulações pouco profissionais e comandantes inexperientes frequentemente evitam manobras mais complexas em condições climáticas severas, permitindo que âncoras sejam arrastadas pelo leito marinho exatamente onde passam a maioria dos cabos submarinos. RFN

Pesquisadores de cibersegurança revelaram uma campanha maliciosa persistente, com duração de cerca de nove meses, que tem como alvo dispositivos de Internet das Coisas (IoT) e aplicações web, recrutando esses sistemas para uma botnet conhecida como RondoDox. A operação ganhou novo fôlego a partir de dezembro de 2025, quando passou a explorar uma falha crítica recém-divulgada chamada React2Shell. De acordo com análise da CloudSEK , o grupo hacker vem utilizando a vulnerabilidade CVE-2025-55182, que possui pontuação máxima de 10.0 no CVSS, como vetor inicial de acesso. Essa falha afeta componentes do React Server Components (RSC) e do Next.js, permitindo execução remota de código sem autenticação, um dos cenários mais graves em termos de segurança. Dados da Shadowserver Foundation indicam que, até 31 de dezembro de 2025, cerca de 90.300 instâncias ainda permaneciam vulneráveis ao React2Shell. A maior concentração está nos Estados Unidos, com aproximadamente 68.400 sistemas , seguidos por Alemanha (4.300), França (2.800) e Índia (1.500). Esse grande volume de sistemas expostos cria um terreno fértil para hackers, especialmente para botnets que buscam escala, como é o caso da RondoDox. Identificada pela primeira vez no início de 2025, a RondoDox expandiu rapidamente suas capacidades ao incorporar falhas N-day já conhecidas, como CVE-2023-1389 e CVE-2025-24893. O uso do React2Shell para disseminar a botnet já havia sido apontado anteriormente por pesquisadores da Darktrace , Kaspersky e VulnCheck, reforçando a gravidade do cenário. Segundo a CloudSEK, a campanha passou por três fases distintas antes de adotar o React2Shell: Março–abril de 2025: reconhecimento inicial e varreduras manuais de vulnerabilidades Abril–junho de 2025: exploração massiva diária de aplicações web como WordPress, Drupal e Struts2, além de dispositivos IoT como roteadores Wavlink Julho–início de dezembro de 2025: automação completa, com implantações em larga escala e frequência horária Nos ataques observados em dezembro de 2025, os invasores passaram a escanear servidores Next.js vulneráveis e, em seguida, instalar múltiplas cargas maliciosas. Entre elas estão miners de criptomoedas, um loader e verificador de integridade da botnet (/nuts/bolts) e até uma variante da botnet Mirai (/nuts/x86). O módulo /nuts/bolts chama atenção por sua agressividade: ele remove outros malwares concorrentes, encerra coin miners rivais, apaga rastros de campanhas anteriores e cria persistência via /etc/crontab. Segundo os pesquisadores, o componente monitora continuamente os processos em execução e elimina qualquer atividade não autorizada a cada 45 segundos, dificultando a reinfecção por outros grupos hackers. Para reduzir o risco, especialistas recomendam: Atualizar imediatamente o Next.js para versões corrigidas; Segmentar dispositivos IoT em VLANs dedicadas; Implantar Web Application Firewalls (WAFs); Monitorar execuções suspeitas de processos; Bloquear infraestrutura conhecida de C2 (Command and Control). Via - THN

O Departamento do Tesouro dos Estados Unidos, por meio do Office of Foreign Assets Control (OFAC), retirou as sanções impostas a três indivíduos associados ao Intellexa Consortium, grupo responsável pelo desenvolvimento e comercialização do spyware Predator. Os nomes removidos da lista de Nacionais Especialmente Designados (SDN) são Merom Harpaz, Andrea Nicola Constantino Hermes Gambazzi e Sara Aleksandra Fayssal Hamou. As sanções haviam sido aplicadas ao longo de 2024, após investigações apontarem o envolvimento direto dos três na criação, operação e distribuição do Predator, uma ferramenta de espionagem comercial altamente intrusiva. No entanto, em comunicado oficial, o Tesouro norte-americano informou que a retirada ocorreu como parte de um processo administrativo padrão, após pedidos formais de reconsideração apresentados pelos sancionados. Distanciamento formal da Intellexa Segundo informações repassadas à agência Reuters , o OFAC afirmou que os indivíduos “demonstraram medidas para se separar do Intellexa Consortium”. Apesar disso, o comunicado não detalha quais ações concretas foram tomadas nem esclarece se os envolvidos ainda mantêm cargos ou vínculos indiretos com as empresas do grupo. Registros anteriores indicavam que Merom Harpaz atuava como gestor da Intellexa S.A., enquanto Gambazzi era apontado como proprietário da Thalestris Limited e da Intellexa Limited empresas que, segundo o próprio Tesouro, detinham direitos de distribuição do spyware e intermediavam transações financeiras do consórcio. Já Sara Hamou foi descrita como uma das principais facilitadoras da estrutura corporativa, responsável por serviços administrativos e de offshoring, incluindo a locação de escritórios na Grécia. Risco contínuo do spyware comercial Na época das sanções, o governo dos EUA alertou que a proliferação de spyware comercial representa um risco crescente à segurança nacional e aos direitos civis, defendendo a criação de regras mais rígidas (guardrails) para equilibrar segurança, direitos humanos e liberdades individuais. A decisão de remover as sanções, no entanto, gerou críticas de organizações da sociedade civil. Para Natalia Krapiva , conselheira jurídica sênior da ONG Access Now, a medida pode passar uma mensagem perigosa: de que ataques contra cidadãos e interesses norte-americanos podem ter poucas consequências, desde que haja recursos financeiros suficientes para pressionar politicamente. Predator segue ativo apesar de denúncias A decisão ocorre poucas semanas após um relatório da Anistia Internacional revelar que um advogado de direitos humanos do Paquistão foi alvo de uma tentativa de infecção pelo Predator por meio de uma mensagem no WhatsApp. Ativo desde pelo menos 2019, o spyware é conhecido por operar de forma furtiva, deixando poucos ou nenhum vestígio no dispositivo comprometido e sendo capaz de coletar dados sensíveis por meio de ataques 1-click ou zero-click. Embora seja oficialmente comercializado para fins de contraterrorismo e aplicação da lei, investigações independentes apontam o uso recorrente do Predator contra jornalistas, ativistas, defensores de direitos humanos e políticos, em um padrão semelhante ao observado com o Pegasus, da NSO Group. Análises recentes da Recorded Future indicam que o Predator continua em uso, mesmo após sanções internacionais e ampla exposição pública. O relatório destaca ainda tendências preocupantes no ecossistema de spyware, como a fragmentação geopolítica, a busca por legitimidade via aquisições e o deslocamento dessas empresas para regiões com menor fiscalização regulatória, aumentando riscos de corrupção, vazamentos internos e até ataques contra os próprios fornecedores de spyware. Via - THN

Imagine um cenário simples: uma empresa usa um gateway de APIs para controlar quem acessa serviços internos como consulta de saldo, dados de clientes ou integrações com parceiros. Se alguém consegue “pular” a etapa de login nesse sistema, o que era para ser um portão com catraca vira uma entrada liberada. É exatamente esse o tipo de risco que a IBM descreveu ao divulgar uma vulnerabilidade crítica no IBM API Connect, plataforma usada para criar, gerenciar e proteger APIs em ambientes cloud e on-premises. A falha, identificada como CVE-2025-13915 , recebeu nota 9,8/10 (crítica) e foi classificada como bypass de autenticação ou seja, pode permitir que hackers contornem mecanismos de autenticação e obtenham acesso não autorizado ao sistema remotamente. Segundo o boletim de segurança da IBM , o problema afeta as versões 10.0.8.0 a 10.0.8.5 e também a 10.0.11.0. Quando um software tem um bypass de autenticação, existe a possibilidade de um invasor acessar recursos protegidos sem apresentar credenciais válidas. Em uma solução de gestão de APIs, isso pode ter impacto alto porque o API Connect costuma ficar no caminho de integrações críticas além de concentrar configurações, políticas, chaves e controles de acesso que sustentam aplicações e serviços. Até o momento, não há confirmação pública de exploração ativa dessa vulnerabilidade “na prática” (o famoso in the wild). Mesmo assim, a recomendação é agir rápido: falhas críticas com bypass de autenticação costumam ganhar atenção do ecossistema assim que são divulgadas. Versões afetadas De acordo com a IBM e bases de referência do ecossistema, o alcance é o seguinte: IBM API Connect 10.0.8.0 até 10.0.8.5 IBM API Connect 10.0.11.0 O que a IBM recomenda fazer agora A IBM orienta clientes a aplicar um “interim fix” (correção temporária) disponibilizado via Fix Central, seguindo as instruções do pacote (incluindo arquivo de readme) e aplicando o fix conforme a versão instalada. Como mitigação, para organizações que não conseguem instalar o fix imediatamente, a IBM recomenda desativar o “self-service sign-up” (auto-cadastro) no Developer Portal, quando essa função estiver habilitada medida que reduz a exposição ao vetor descrito pela empresa. Via - THN

Imagine um vídeo “para crianças” que não é marcado como tal. Para quem assiste, nada muda na tela mas, nos bastidores, a classificação errada pode abrir espaço para que dados sejam coletados e usados em publicidade direcionada. É exatamente esse o ponto central de um acordo anunciado pelas autoridades dos EUA: a Disney concordou em pagar uma multa civil de US$ 10 milhões para encerrar acusações de que violou a Children’s Online Privacy Protection Act (COPPA) ao rotular incorretamente conteúdos no YouTube. Segundo o Departamento de Justiça (DOJ), a investigação encaminhada pela Federal Trade Commission (FTC) aponta que a Disney teria deixado de marcar vídeos direcionados ao público infantil como “Made for Kids” (MFK). Esse rótulo é essencial porque sinaliza ao YouTube que o conteúdo deve ter restrições de coleta de dados pessoais e bloqueio de anúncios personalizados, justamente para atender às exigências da COPPA . A acusação sustenta que, com a marcação incorreta, a Disney teria permitido que, “por meio do YouTube”, ocorresse coleta de dados de crianças menores de 13 anos para fins de publicidade direcionada e que a empresa também se beneficiava financeiramente, já que recebe parte da receita de anúncios exibidos em seus vídeos e pode vender publicidade diretamente. O caso se conecta a um marco importante: desde 2019, criadores e empresas passaram a ser obrigados a marcar vídeos e canais como MFK (ou “não MFK”), após o acordo em que Google/YouTube pagaram US$ 170 milhões por alegadas violações da regra da COPPA. No processo envolvendo a Disney, o DOJ e a FTC afirmam que a empresa teria mantido falhas de classificação mesmo depois de alertas do YouTube incluindo uma mudança feita pela própria plataforma em 2020, quando mais de 300 vídeos teriam sido reclassificados de “não MFK” para MFK. Além do pagamento da multa, o acordo estabelece obrigações de conformidade. Na prática, a Disney terá que notificar responsáveis antes de coletar informações pessoais de crianças e garantir que os vídeos voltados ao público infantil no YouTube sejam classificados corretamente para impedir coleta indevida e anúncios personalizados em conteúdo infantil. O tema também aparece em um contexto mais amplo de escrutínio regulatório. Em 2024, um relatório de equipe da FTC apontou que grandes empresas de redes sociais e vídeo sob demanda mantêm práticas de coleta e monetização de dados em larga escala, com impactos relevantes para crianças e adolescentes. Via - BC

O Rainbow Six Siege (R6), da Ubisoft, foi atingido por um incidente de segurança que permitiu que hackers abusassem de sistemas internos para banir e desbanir jogadores, forjar mensagens no “ban ticker” (o feed de punições exibido no jogo) e conceder grandes quantidades de moeda e itens para contas em escala global. Relatos de jogadores e capturas de tela compartilhadas nas redes indicam que os invasores conseguiram, entre outras ações, desbloquear todos os cosméticos do jogo incluindo skins restritas a desenvolvedores e distribuir aproximadamente 2 bilhões de R6 Credits e Renown. O impacto chama atenção principalmente pelo valor econômico associado aos R6 Credits, que são vendidos por dinheiro real na loja da Ubisoft. Pela precificação informada no próprio ecossistema do jogo (ex.: 15.000 R6 Credits por US$ 99,99), a distribuição de 2 bilhões de créditos equivaleria, em termos de “valor de tabela”, a cerca de US$ 13,33 milhões em moeda virtual concedida indevidamente. Na manhã de sábado, por volta de 9h10, a conta oficial de Rainbow Six Siege no X (antigo Twitter) reconheceu o problema e informou que equipes estavam trabalhando para resolver a falha. Pouco depois, a Ubisoft derrubou intencionalmente o Siege e o Marketplace para conter o incidente e acelerar a correção. Em uma atualização posterior, a empresa afirmou que jogadores não seriam punidos por terem gasto os créditos recebidos, mas avisou que faria um rollback (reversão) de todas as transações realizadas desde 11:00 (UTC). A Ubisoft também disse que não gerou as mensagens exibidas no ban ticker e que o recurso já havia sido desativado anteriormente. Até o momento descrito no texto, o jogo ainda enfrentava instabilidade com servidores fora do ar, e a empresa não havia publicado um comunicado técnico detalhando como a brecha aconteceu, nem respondeu aos pedidos de esclarecimento citados. Além do abuso visível dentro do jogo, circularam rumores não confirmados de que o caso poderia ser parte de uma invasão mais ampla na infraestrutura da Ubisoft. Segundo relatos atribuídos ao grupo de pesquisadores VX-Underground , hackers teriam alegado acesso a servidores da empresa usando uma suposta vulnerabilidade recente do MongoDB apelidada de “MongoBleed” (CVE-2025-14847). A falha, de acordo com as alegações, permitiria que invasores sem autenticação vazassem conteúdo de memória de instâncias expostas do banco de dados, abrindo caminho para a exposição de credenciais e chaves de autenticação. Também foi citado que já existiria um PoC público capaz de procurar segredos em servidores MongoDB expostos. O texto ainda menciona a possibilidade de múltiplos grupos hackers, não necessariamente relacionados, terem mirado a Ubisoft ao mesmo tempo: um grupo teria manipulado punições e inventário do Siege sem acesso a dados de usuários; outro teria usado a falha para pivotar até repositórios internos e alegar roubo de código-fonte histórico; um terceiro teria supostamente capturado dados de usuários e tentaria extorquir a empresa; e um quarto contestaria partes dessas alegações. No entanto, o ponto central é que essas afirmações não foram verificadas de forma independente e, até aqui, o único fato confirmado publicamente (com base no texto fornecido) é o abuso dentro do Rainbow Six Siege, sem evidências públicas de um comprometimento maior envolvendo código-fonte ou dados de clientes. Via - BC

PUBLICIDADE | Post patrocinado em parceria com a BLACKBOX.AI A BLACKBOX.AI  se posiciona como um ecossistema de IA para construção de software  indo além do “chat que escreve código” e oferecendo agentes autônomos  capazes de executar tarefas localmente (no seu desktop/IDE)  ou remotamente (na nuvem) , com fluxos que incluem geração de código, testes, refatoração e até criação de Pull Requests . BLACKBOX.AI: a IA que quer transformar intenção em entrega Na prática, a Blackbox quer reduzir o atrito entre “ideia” e “entrega”: você descreve o que precisa em linguagem natural e a plataforma ajuda a planejar, implementar e iterar  — desde dúvidas simples até desenvolvimento de funcionalidades mais complexas, apoiando milhões de desenvolvedores  (segundo a própria empresa). Do prompt ao PR: como a Blackbox coloca agentes para trabalhar O ecossistema é distribuído em frentes que se conectam: Web App : um hub no navegador com chat, geração de código e recursos como Image → Website  (converter mockups/imagens em um site/app), além de histórico e acesso a outras partes da plataforma. VS Code Agent : extensão com ferramentas (ex.: browser tool) e recursos de orquestração  para dividir uma tarefa grande em subtarefas e rodar subagentes em paralelo , acelerando entregas. Blackbox Cloud (Remote Agents) : agentes remotos via browser para trabalhar em repositórios, com execução simultânea , monitoramento, e fluxo automatizado de Pull Request  (e até code review, conforme a documentação). CLI + MCP : controle e gestão de agentes remotos via terminal usando Model Context Protocol , para quem prefere operação “terminal-first”. Builder : camada “texto/voz → app” para criar aplicações full-stack e iterar visualmente, com opção de integração com Stripe  para pagamentos. Por que não é “só mais uma IA para código” Pelos próprios guias e comparativos da Blackbox, os diferenciais mais fortes ficam em quatro pontos: Agentes locais + remotos no mesmo ecossistema  (IDE/desktop/VS Code + Cloud), permitindo escalar tarefas sem ficar preso a uma máquina. Execução paralela de verdade  com orquestração (vários subagentes rodando ao mesmo tempo), útil para features grandes e correções complexas. Privacidade forte no Desktop Agent , com criptografia ponta a ponta  e modelo “zero-knowledge” (chaves não saem do dispositivo; a própria Blackbox afirma não conseguir ver seus dados). Ferramentas integradas ao fluxo  (ex.: browser tool no VS Code Agent) e foco em automação prática — mais do que só sugerir código. Por que testar agora: menos prompt, mais entrega Se você já usa assistentes de código, a Blackbox chama atenção por ir além do autocomplete: ela tenta cobrir o ciclo completo “pedir → executar → validar → entregar”, com agentes , paralelismo , cloud  e camadas para construir apps  rapidamente (inclusive a partir de imagem), além de um discurso forte de privacidade no desktop . Se você quiser, eu adapto essa notícia para o estilo do Cyber Security Brazil  (mais “jornalístico + análise”, com bloco “impacto para devs/empresas” e “pontos de atenção de segurança”). Para quem quiser testar na prática use o cupom CYBER  e garanta 1 mês de teste grátis . É uma boa chance de colocar a BLACKBOX.AI em um cenário real e ver se o modelo de agentes + automação  faz diferença no seu fluxo de trabalho.

Em 2025, a cibersegurança deixou de ser “um jogo de exploits” e passou a ser, cada vez mais, "um jogo de escala" . A inteligência artificial entrou de vez no campo não só como tecnologia de defesa, mas como um acelerador para ataques mais rápidos, mais baratos e mais convincentes. Ao mesmo tempo, o ransomware seguiu amadurecendo como indústria, com extorsão, vazamento de dados e exploração de terceiros se tornando parte do modelo operacional de muitos grupos criminosos. O resultado foi um cenário mais barulhento, mais imprevisível e mais desgastante para as equipes de segurança, que precisaram extrair sinal em meio a um volume crescente de alertas, riscos e decisões. Para 2026, a tendência é clara: "A automação vai deixar de ser suporte e virar protagonista" . Agentes de IA devem começar a operar dentro de SOCs, pipelines de TI e fluxos de negócio trazendo ganhos reais de velocidade, mas também novos riscos: prompt injection mais “industrializado”, modelos conectados a fontes externas (RAG) com possibilidade de vazamento e envenenamento, e o desafio de tratar agentes como identidades digitais com privilégios e rastreabilidade. Em paralelo, a pressão por redução de superfície de ataque, segurança de cadeia de suprimentos e resiliência operacional aumenta e, em alguns setores, o Zero Trust tende a migrar de boa prática para exigência de compliance. Neste relatório, a CyberSecBrazil organiza o que 2025 ensinou e o que 2026 deve cobrar, traduzindo tendências em ações práticas. A proposta é simples: transformar previsões em um plano de execução com foco em governança de IA, fundamentos operacionais (least privilege, patching contínuo, exposição), inteligência acionável, e preparo real para incidentes que não chegam mais “devagar”. Visão executiva O ano de 2025  consolidou três movimentos que mudaram o “ritmo” da segurança: crescimento do uso de IA por atacantes e defensores , amadurecimento do modelo de extorsão (ransomware + vazamento + pressão)  em escala industrial, e elevação do papel de Threat Intelligence (CTI)  para decisões estratégicas (investimentos, riscos e priorização). Para 2026 , a tendência dominante é que agentes de IA  deixem de ser “feature” e virem atores digitais operacionais : exigindo governança, identidade, telemetria e controles “secure-by-design”, enquanto o crime mantém foco em extorsão , engenharia social aumentada por IA  e exploração de pontos de falha sistêmicos  (terceiros, supply chain, infraestrutura). Como foi 2025 IA deixou de ser “futuro” e virou multiplicador de ataques: Em 2025, relatórios de mercado reforçam que a IA baixou a barreira de entrada  e ajudou atacantes a escalar volume e sofisticação, criando pressão por “encontrar sinal no ruído” e evitar burnout das equipes. Extorsão em escala: ransomware + vazamento como ecossistema maduro A extorsão permaneceu como uma das categorias mais disruptivas, com sinais claros de maturidade do ecossistema: 2.302 vítimas em sites de vazamento (DLS) no Q1 2025 , o maior trimestre desde o início do tracking (2020), com grupos explorando terceiros  e zero-days  para atingir volume. CTI ganhou status “core” e mais estratégico O CTI se fortaleceu: 76%  das organizações pesquisadas investem US$ 250 mil+ por ano  em threat intelligence; e 65%  dizem que CTI influencia decisões de compra de tecnologia; 58%  usam em avaliação de risco do negócio. A consolidação também apareceu forte: 81%  planejam consolidar fornecedores de CTI e 91%  pretendem aumentar investimento em 2026 (não como corte, mas como priorização). Previsões e prioridades para 2026 (o que mais deve importar) “Agentic SOC” e identidade para agentes de IA": A previsão para 2026 é a adoção acelerada de agentes de IA  executando workflows e decisões e isso muda o desenho de segurança porque muitos controles não foram pensados para “operadores não-humanos”. A expectativa é tratar agentes como identidades digitais distintas , com least privilege , just-in-time , e cadeia de delegação  (“agentic identity management”). Em paralelo, o SOC tende a evoluir para um modelo em que analistas direcionam agentes , recebendo alertas já com sumário, decodificação e contexto para decidir e automatizar contenção mais rápido. Prompt injection e ataques diretos a sistemas de IA: O Google Cloud Cybersecurity Forecast 2026 aponta aumento relevante de prompt injection  e ataques direcionados a sistemas de IA corporativos, migrando de PoCs para campanhas de exfiltração  e sabotagem . Extorsão continua (e pior): mais criatividade, mais coerção, mais zero-day: A tendência para 2026 é mais ransomware e extorsão , com aumento de estratégias de acesso inicial via vishing  e engenharia social para contornar MFA, além de uso crescente de zero-days  em campanhas amplas. Planejamento 2026: resiliência, exposição e supply chain como “pilares” O guia de planejamento do Gartner para 2026 coloca foco em: Redução de attack surface  como parte central de defense-in-depth (incluindo CTEM ) Maturidade de software supply chain security  e secure-by-design (incluindo apps de IA) Controles para consumo de IA  (treinamento + controles técnicos para evitar vazamento de dados) SecOps augmentation  (incluindo agentes no SOC) Adoção de padrões: security-by-design, zero trust e CSMA   Previsões de mercado (Forrester): IA “cobrança por resultado” e corrida quântica: Algumas apostas públicas do ecossistema de previsões 2026 da Forrester: 25% dos CIOs  serão chamados a “salvar” iniciativas de IA lideradas pelo negócio que falharem (governança e execução). Quantum security : gasto deve exceder 5%  do orçamento total de segurança de TI, acelerando migração/consultoria/inventário criptográfico. O que eu recomendaria como “linha de ação” (bem pragmático) Controles mínimos para IA e agentes (90 dias): Catálogo de uso de IA  (quem usa, onde, com quais dados) + política de dados (o que pode/ não pode). (Alinha com controle de consumo de IA). Identidade para agentes : contas dedicadas, JIT, escopos mínimos, trilhas de auditoria e delegação. Guardrails para LLM : sanitização de entrada/saída, confirmação humana para ações de alto risco, e detecção de prompt injection. Redução de exposição e resiliência (até 6 meses) Rodar um programa de CTEM  e attack surface reduction com backlog priorizado. Reforçar supply chain  (SBOM onde possível, validações, gestão de dependências e terceiros críticos). Preparar-se para mudanças do mercado de fornecedores (consolidação) sem criar pontos únicos de falha. CTI como motor de decisão (contínuo) Priorizar integrações e redução de overload (as dores mais citadas). Fazer CTI “sair do SOC” e ir para GRC/IAM/fraude , como tendência de integração de workflows. Matriz “2025 aprendizados → 2026 ações” Aprendizado de 2025 Ação prioritária em 2026 Primeiros passos (30–60 dias) KPI de acompanhamento IA virou multiplicador de ataque  (mais volume/sophisticação e mais “ruído”) Governança + controles de IA  (uso corporativo, dados, auditoria) Inventariar “AI use cases” e onde dados sensíveis entram/saem; criar política de uso e classificação para IA % de use cases mapeados; incidentes de “shadow AI”/mês SOC tende a virar “Agentic SOC”  (analista orquestra agentes) SOC com automação orientada por agentes + SOAR Definir 5 playbooks para automação (phishing, credenciais, malware, exfil, ransomware) e colocar “human-in-the-loop” MTTR; % casos com playbook; tempo de triagem Shadow Agent  (uso não aprovado cria pipeline invisível de dados) Canal seguro para agentes  (permitir com guardrails, não banir) Criar “rota segura” (proxy/SSE + logging) para tráfego de ferramentas/agents; aprovar catálogo de agentes % tráfego de IA “visível”; violações de policy Prompt injection sai do PoC e vai para exfiltração/sabotagem em 2026 Proteção de aplicações LLM  (guardrails input/output e validações) Testes de segurança em prompts; sanitização de saída; confirmação humana para ações de alto risco nº de tentativas bloqueadas; taxa de falsos positivos Ransomware + vazamento atingiu escala recorde  (DLS 2.302 vítimas no Q1/2025) Resiliência anti-extorsão  (backup, contenção, exfil controls) Revisar backups (imutável + teste de restauração); DLP/egress controls; tabletop de crise RTO/RPO real; % restaurações testadas; tempo até contenção Acesso inicial via engenharia social evoluiu  (vishing e técnicas para contornar MFA) Defesa contra vishing + fraude de identidade Treinar helpdesk/IT e líderes (procedimentos de verificação); bloquear resets por voz sem prova forte; alertas para “MFA fatigue” nº de tentativas; % resets com verificação forte Terceiros viraram alavanca de escala  (provedores e MFT/zero-days para muitos alvos) Programa de risco de terceiros + “single point of failure” Classificar terceiros críticos; exigir logs/telemetria; validar plano de resposta e comunicação % terceiros críticos avaliados; tempo de resposta do fornecedor Superfície de ataque precisa ser reduzida continuamente (CTEM) CTEM + hardening baseline  (contínuo, não pontual) Rodar ciclo CTEM trimestral; baseline de hardening para endpoints/servidores/cloud redução de exposições críticas; tempo para corrigir Supply chain e secure-by-design viraram “core”  (inclui produtos de IA) SSDLC + segurança de dependências (SBOM/controles) Definir gates no CI/CD (SAST/dep scanning/secrets); política de dependências; revisão de pipelines % builds com gates; falhas críticas por release Consolidação de fornecedores é tendência (e risco de concentração) Estratégia anti lock-in + plano de continuidade Mapear dependências de plataforma; requisitos mínimos de portabilidade; plano de migração emergencial nº SPOFs de fornecedor; tempo estimado de migração CTI virou peça estratégica  (investimento, compra, risco e integração) CTI integrado ao ciclo de decisão  (SOC + GRC + vulnerabilidades) Integrar TI com SIEM/SOAR e VM; definir “intelligence requirements” por negócio % alertas enriquecidos; redução de ruído; decisões suportadas por TI Dores de CTI em 2025: credibilidade + integrações + overload Curadoria + scoring de fonte + automação de integração Criar score de fontes/feeds; matar feeds redundantes; playbook de “enrichment” padronizado % fontes com score; queda em “info overload”; SLA de integração Em 2025, ficou evidente que não vence quem tem “mais ferramentas”, e sim quem tem mais clareza operacional : visibilidade real do ambiente, prioridade bem definida e capacidade de agir rápido quando o incidente acontece. O ano consolidou a IA como multiplicador tanto para atacantes quanto para defensores e mostrou que extorsão e cadeia de terceiros continuam sendo caminhos eficientes para impacto em escala. Também ficou claro que Threat Intelligence só gera valor quando vira decisão: reduz ruído, orienta prioridade e melhora resposta, em vez de virar mais uma fonte de informação difícil de consumir. Para 2026, o recado é direto: a superfície de ataque não é mais só “o que você expõe”, é o que você automatiza . Agentes, integrações e fluxos conectados (MCP, RAG, automações no SOC e no ITSM) aumentam produtividade, mas também ampliam riscos se não houver governança, identidade, telemetria e limites de autonomia. Por isso, a preparação que realmente importa combina três frentes: fundamentos bem executados  (least privilege, patching contínuo e redução de exposição), resiliência anti-extorsão  (conter rápido, recuperar mais rápido ainda e controlar exfiltração), e segurança de IA “by design”  (guardrails, controles de dados e trilhas de auditoria). O que separa as organizações que vão “apagar incêndios” das que vão atravessar 2026 com maturidade é a capacidade de transformar aprendizados em rotina: medir, automatizar com responsabilidade e corrigir continuamente. A tecnologia vai acelerar e o ataque também. A diferença estará em quem trata segurança como processo vivo , não como checklist.

Um turboélice executivo pousou “sozinho” em Colorado (EUA) após um problema em voo e o episódio virou um marco para a aviação geral: pela primeira vez fora de testes, a autoridade de aviação civil dos EUA confirmou que uma aeronave realizou um pouso de emergência totalmente guiado por automação, do início ao fim, usando o sistema Garmin Emergency Autoland. O caso ocorreu no sábado, 20 de dezembro de 2025, quando um Beechcraft Super King Air pousou com segurança no Rocky Mountain Metropolitan Airport ( KBJC ), por volta das 14h20 (horário local). Segundo a Federal Aviation Administration (FAA), o pouso aconteceu depois que o piloto perdeu comunicação com o controle de tráfego aéreo, momento em que um sistema de autolanding de emergência foi ativado. A agência informou ainda que duas pessoas estavam a bordo e que o episódio está sob investigação. A repercussão inicial levantou suspeitas de incapacitação dos pilotos , em parte porque o Autoland transmite mensagens automáticas com esse tipo de alerta inclusive para o ATC . Porém, o operador do voo indicou que a ativação do sistema foi uma decisão deliberada da tripulação, tomada como medida conservadora diante de um evento de cabine: a aeronave teria sofrido uma perda rápida e não comandada de pressurização. De acordo com o relato, os pilotos colocaram máscaras de oxigênio e optaram por manter o sistema conduzindo o procedimento até o pouso. O avião envolvido era um King Air B200, versão bastante comum em táxi-aéreo e operações corporativas por sua capacidade de operar em pistas relativamente curtas. Em configurações típicas, o modelo comporta 7 a 9 passageiros, além de dois tripulantes, e costuma voar com dois pilotos em operações comerciais por margem adicional de segurança, ainda que algumas variantes sejam certificadas para operação com um piloto. Como funciona o Emergency Autoland Diferente de um piloto automático tradicional (que mantém rota/altitude e segue comandos do piloto), o Emergency Autoland foi projetado para assumir o controle completo em uma emergência: ele seleciona automaticamente o melhor aeroporto disponível e executa aproximação, pouso, frenagem e procedimentos finais. A decisão de onde pousar leva em conta variáveis como comprimento de pista, condições, distância e combustível, além de enviar comunicações automatizadas ao controle de tráfego aéreo para coordenar a chegada. A Garmin lançou o Autoland em 2019 , com foco em cenários como incapacidade do piloto e, na prática, o caso no Colorado sugere que a automação também pode ser usada como “plano B” quando a tripulação avalia que reduzir carga de trabalho e risco operacional é a melhor escolha naquele momento. Via - TR

Na semana que antecedeu o Natal, milhões de franceses sentiram na prática como uma interrupção digital pode virar um problema do “mundo real”: rastreio de encomendas fora do ar, lentidão na distribuição de correspondências e instabilidade no acesso ao banco pelo celular. Foi esse o cenário enfrentado por clientes da La Poste o serviço postal nacional da França e da La Banque Postale, braço bancário do grupo, após um ataque de negação de serviço distribuída (DDoS) que tirou sistemas do ar em um dos períodos mais movimentados do ano. Autoridades francesas afirmam que o grupo hacker pró-Rússia NoName057(16) reivindicou a autoria do ataque. A La Poste informou na sexta-feira que as operações foram restabelecidas depois da ofensiva, que começou no início da semana. Mesmo com a interrupção, a empresa disse ter entregue 5,5 milhões de encomendas até a tarde de quarta-feira, em meio ao pico de demanda típico das compras de fim de ano. Com a reivindicação pública, o caso ganhou prioridade na esfera criminal. O Ministério Público de Paris abriu uma investigação e a apuração passou a ser conduzida pela DGSI, a agência de inteligência interna da França. Segundo promotores ouvidos pela imprensa local, a investigação neste momento concentra-se no crime de interrupção deliberada de um serviço de processamento de dados, tipificação comum quando ataques DDoS derrubam sistemas e plataformas essenciais. A La Poste, que emprega mais de 200 mil pessoas, já havia relatado que o ataque derrubou temporariamente sistemas digitais considerados críticos, afetando serviços como rastreamento online de pacotes e contribuindo para atrasos na distribuição de correspondências. A empresa também declarou que, até então, não havia evidências de comprometimento de dados de clientes, indicando que o foco da ofensiva foi a indisponibilidade e não o roubo de informações. O impacto se estendeu ao ecossistema financeiro do grupo. A La Banque Postale alertou clientes sobre a indisponibilidade temporária do internet banking e do aplicativo móvel, com a maior parte dos serviços normalizada na quarta-feira. Em incidentes desse tipo, é comum que instituições priorizem a continuidade de operações internas e canais alternativos enquanto reforçam camadas de proteção contra tráfego malicioso. O NoName057(16) surgiu no início da invasão russa à Ucrânia, em 2022, e ficou conhecido por campanhas de DDoS contra a Ucrânia e países aliados. De acordo com as informações divulgadas no relato do caso, o grupo costuma coordenar ataques relativamente simples do ponto de vista técnico, mas altamente disruptivos, usando apoio de centenas de voluntários e uma estrutura baseada em botnet com centenas de servidores. Alvos recorrentes incluem países europeus como Polônia, República Tcheca, Lituânia e Itália. O episódio também ocorre em um contexto de atenção elevada do governo francês a ameaças digitais. No início de dezembro, a França já havia divulgado uma intrusão no Ministério do Interior, em que invasores acessaram contas de e-mail e documentos confidenciais. Na ocasião, as autoridades prenderam um suspeito de 22 anos ligado ao caso, reforçando o clima de alerta para ataques contra serviços públicos e estruturas governamentais.

Uma vulnerabilidade crítica  foi divulgada no LangChain Core , um dos principais frameworks utilizados para orquestração de aplicações baseadas em Large Language Models (LLMs) . A falha, identificada como CVE-2025-68664  e com pontuação CVSS de 9,3 , pode ser explorada por hackers para extrair segredos sensíveis , manipular respostas de modelos de IA e, em cenários mais graves, executar código arbitrário . O LangChain Core ( langchain-core ) é um pacote central em Python dentro do ecossistema LangChain, responsável por fornecer interfaces e abstrações independentes de modelo para a construção de aplicações baseadas em LLMs. Justamente por estar no núcleo do framework, a vulnerabilidade possui alto impacto potencial , afetando uma ampla gama de aplicações que utilizam serialização e desserialização de dados. Como a vulnerabilidade funciona A falha, batizada de LangGrinch , foi reportada em 4 de dezembro de 2025  pelo pesquisador Yarden Porat  e está relacionada a um problema de serialization injection  nas funções dumps() e dumpd()  do LangChain. Segundo o advisory oficial, essas funções não escapam corretamente dicionários controlados pelo usuário que contenham a chave especial "lc" . Essa chave é utilizada internamente pelo LangChain para identificar objetos serializados legítimos do framework. Na prática, quando um invasor consegue inserir dados contendo a estrutura "lc" em campos controláveis pelo usuário, esses dados passam a ser tratados como objetos legítimos do LangChain durante a desserialização , e não como simples entrada de usuário. Isso abre caminho para a criação de objetos inseguros e execução de fluxos inesperados dentro da aplicação. Impactos possíveis do ataque De acordo com o pesquisador, a exploração bem-sucedida da falha pode resultar em diversos cenários críticos, incluindo: Extração de segredos armazenados em variáveis de ambiente , especialmente quando a desserialização ocorre com secrets_from_env=True (configuração que anteriormente vinha habilitada por padrão) Instanciação de classes dentro de namespaces confiáveis , como langchain_core, langchain e langchain_community Manipulação de respostas de LLMs via prompt injection , explorando campos como metadata, additional_kwargs e response_metadata Possível execução de código arbitrário , especialmente em ambientes que utilizam templates Jinja2 Segundo Porat , esse é um exemplo clássico da interseção entre IA e falhas tradicionais de segurança , onde saídas de modelos de linguagem que deveriam ser tratadas como entrada não confiável  acabam sendo reutilizadas em fluxos críticos de serialização. Correções aplicadas pelo LangChain Para mitigar o problema, o LangChain lançou atualizações que introduzem mudanças restritivas de segurança , incluindo: Novo parâmetro allowed_objects nas funções load() e loads(), permitindo definir explicitamente quais classes podem ser serializadas/desserializadas Bloqueio de templates Jinja2 por padrão Alteração do secrets_from_env para False, impedindo o carregamento automático de segredos do ambiente Versões afetadas (Python) langchain-core >= 1.0.0, < 1.2.5 → corrigido na 1.2.5 langchain-core < 0.3.81 → corrigido na 0.3.81 Falha similar no LangChain.js Além da versão em Python, foi identificada uma falha semelhante no LangChain.js , também causada pela falta de escape adequado da chave "lc" , permitindo extração de segredos e prompt injection. Essa vulnerabilidade recebeu o identificador CVE-2025-68665  (CVSS 8,6). Pacotes afetados incluem: @langchain/core >= 1.0.0, < 1.1.8 → corrigido na 1.1.8 @langchain/core < 0.3.80 → corrigido na 0.3.80 langchain >= 1.0.0, < 1.2.3 → corrigido na 1.2.3 langchain < 0.3.37 → corrigido na 0.3.37 Via - THN