A Cisco divulgou atualizações de segurança para corrigir uma vulnerabilidade crítica de bypass de autenticação que afeta os controladores Catalyst SD-WAN e que já está sendo explorada em ataques reais. A falha, identificada como CVE-2026-20182, recebeu pontuação máxima CVSS 10.0 e permite que invasores remotos obtenham privilégios administrativos sem necessidade de autenticação. Segundo a Cisco, o problema afeta os componentes Cisco Catalyst SD-WAN Controller, anteriormente chamados de SD-WAN vSmart, e Cisco Catalyst SD-WAN Manager, anteriormente conhecidos como SD-WAN vManage. A vulnerabilidade está relacionada a uma falha no mecanismo de autenticação de peering entre dispositivos da arquitetura SD-WAN. De acordo com a fabricante, um invasor pode explorar o problema enviando requisições especialmente manipuladas para os sistemas vulneráveis. Caso a exploração seja bem-sucedida, o atacante consegue se autenticar no controlador SD-WAN como um usuário interno altamente privilegiado, embora sem privilégios root inicialmente. A partir desse acesso, é possível utilizar serviços como o NETCONF para manipular configurações da malha SD-WAN, alterar políticas de rede e potencialmente comprometer comunicações corporativas. Os ambientes afetados incluem: Deployments on-premises Cisco SD-WAN Cloud-Pro Cisco SD-WAN Cloud (Cisco Managed) Cisco SD-WAN for Government (FedRAMP) A vulnerabilidade foi descoberta pela Rapid7, que destacou semelhanças com a CVE-2026-20127, outra falha crítica de bypass de autenticação divulgada anteriormente e explorada desde pelo menos 2023 por um grupo identificado como UAT-8616. Segundo os pesquisadores Jonah Burgess e Stephen Fewer, ambas as vulnerabilidades afetam o serviço “vdaemon” sobre DTLS na porta UDP 12346. Apesar das semelhanças, a Rapid7 ressaltou que a CVE-2026-20182 não é um bypass do patch anterior, mas uma nova falha localizada em outra parte da mesma stack de rede. Na prática, o resultado operacional continua extremamente perigoso: invasores remotos sem autenticação conseguem se registrar como peers confiáveis dentro da infraestrutura SD-WAN e executar operações privilegiadas no ambiente. A Cisco informou que tomou conhecimento de “exploração limitada” da vulnerabilidade em maio de 2026 e recomenda a aplicação imediata das atualizações de segurança disponibilizadas. A fabricante alertou ainda que controladores SD-WAN expostos diretamente à internet apresentam risco significativamente maior de comprometimento, principalmente quando portas relacionadas ao serviço vulnerável estão acessíveis externamente. Como medida de detecção, a Cisco orienta administradores a revisar o arquivo /var/log/auth.log em busca de registros suspeitos relacionados a: “Accepted publickey for vmanage-admin” Conexões originadas de IPs desconhecidos ou não autorizados Eventos de peering ocorrendo em horários incomuns Conexões envolvendo tipos de dispositivos incompatíveis com a arquitetura esperada do ambiente Especialistas alertam que controladores SD-WAN ocupam uma posição estratégica dentro das redes corporativas modernas. Como esses sistemas centralizam políticas, conectividade entre filiais, comunicação com ambientes cloud e gerenciamento de tráfego, uma invasão bem-sucedida pode permitir espionagem, movimentação lateral, persistência silenciosa e controle amplo da infraestrutura de rede. O caso também reforça uma tendência crescente de ataques direcionados a appliances de borda, controladores de rede e plataformas de gerenciamento centralizado, componentes frequentemente utilizados como ponto inicial de comprometimento em operações conduzidas por grupos avançados e atores patrocinados por Estados-nação.

Pesquisadores divulgaram detalhes sobre uma nova vulnerabilidade de escalada local de privilégios no Linux que permite a invasores obter acesso root por meio da corrupção do page cache do kernel. A falha, batizada de Fragnesia, foi registrada como CVE-2026-46300 e surge poucas semanas após a divulgação das vulnerabilidades Dirty Frag e Copy Fail, ampliando preocupações em torno da segurança do subsistema XFRM ESP-in-TCP do kernel Linux. A vulnerabilidade recebeu pontuação CVSS 7.8 e foi descoberta pelo pesquisador William Bowling, da Zellic e da equipe V12 Security. Segundo a Wiz, empresa pertencente ao Google, a falha permite que usuários locais sem privilégios modifiquem conteúdos de arquivos somente leitura presentes no page cache do kernel, criando uma primitiva determinística de corrupção de memória capaz de resultar em privilégio root. O problema está relacionado ao subsistema XFRM ESP-in-TCP, componente responsável por funcionalidades ligadas a IPsec e encapsulamento ESP sobre TCP. De acordo com os pesquisadores, a vulnerabilidade explora um erro lógico que possibilita gravações arbitrárias de bytes no page cache de arquivos somente leitura, sem necessidade de explorar condições de corrida, diferentemente de outras falhas históricas semelhantes. A equipe V12 explicou que a Fragnesia utiliza a mesma superfície explorada pela Dirty Frag, embora se trate de uma vulnerabilidade diferente com correção própria. Ainda assim, as mitigações aplicadas anteriormente para Dirty Frag permanecem válidas para reduzir o risco até que kernels corrigidos sejam distribuídos pelas distribuições Linux afetadas. Assim como Copy Fail e Dirty Frag, a nova falha permite modificar a memória associada ao binário /usr/bin/su, técnica que leva rapidamente à obtenção de privilégios administrativos em diversas distribuições Linux. Os pesquisadores também disponibilizaram um exploit proof-of-concept (PoC), demonstrando a viabilidade prática da exploração. Diversas distribuições já publicaram alertas e orientações relacionadas à vulnerabilidade, incluindo: AlmaLinux Amazon Linux CloudLinux Debian Gentoo Red Hat Enterprise Linux SUSE Ubuntu Segundo a CloudLinux, sistemas que já aplicaram as mitigações recomendadas para Dirty Frag não precisam de ações adicionais imediatas até a liberação dos patches definitivos. A Red Hat informou que ainda avalia se as mitigações existentes são suficientes para bloquear completamente a exploração da CVE-2026-46300. A Wiz observou ainda que restrições do AppArmor relacionadas a namespaces de usuários sem privilégios podem atuar como mitigação parcial. Mesmo assim, a exploração continua relevante porque não exige privilégios em nível de host para ser executada. A Microsoft também recomendou que administradores atualizem seus sistemas o mais rápido possível. Para ambientes onde a aplicação imediata de patches não seja viável, a empresa sugere as mesmas medidas temporárias adotadas para Dirty Frag, incluindo: Desabilitar módulos esp4, esp6 e funcionalidades relacionadas a xfrm/IPsec Restringir acessos shell locais desnecessários Reforçar a segurança de workloads containerizados Aumentar o monitoramento de atividades anormais de escalada de privilégios O cenário se torna ainda mais preocupante após pesquisadores identificarem um agente chamado “berz0k” anunciando em fóruns de cibercrime um suposto exploit zero-day de escalada local de privilégios para Linux pelo valor de US$ 170 mil. Segundo o ThreatMon, o vendedor afirma que o exploit utiliza uma vulnerabilidade baseada em TOCTOU (Time-of-Check Time-of-Use), funciona de forma estável em múltiplas distribuições Linux e utiliza payloads .so armazenados no diretório /tmp. Embora ainda não existam evidências públicas de exploração da Fragnesia em ataques reais, a divulgação do exploit PoC e o aumento do interesse de grupos criminosos em falhas LPE para Linux elevam significativamente o risco para ambientes corporativos, servidores e infraestruturas em nuvem que dependem do kernel Linux.

A Microsoft revelou uma nova vulnerabilidade de segurança que afeta versões on-premises do Exchange Server e que já está sendo explorada ativamente por invasores. A falha, identificada como CVE-2026-42897, recebeu pontuação CVSS 8.1 e envolve um problema de spoofing decorrente de uma vulnerabilidade de cross-site scripting (XSS). Segundo a empresa, um invasor pode explorar a falha enviando um e-mail especialmente criado para o alvo. Quando a mensagem é aberta no Outlook Web Access (OWA), e determinadas condições de interação são atendidas, códigos JavaScript arbitrários podem ser executados dentro do contexto do navegador da vítima. A vulnerabilidade foi classificada pela Microsoft com o status “Exploitation Detected”, indicando que já existem tentativas reais de exploração em andamento. Apesar disso, a companhia não divulgou detalhes técnicos sobre os ataques observados, nem informações sobre os responsáveis pela atividade maliciosa, escala das campanhas ou possíveis vítimas comprometidas. A origem do problema está na neutralização inadequada de entradas durante a geração de páginas web no Exchange Server. Esse comportamento abre espaço para ataques de cross-site scripting, técnica frequentemente utilizada para executar scripts maliciosos no navegador de usuários legítimos, roubar sessões autenticadas, manipular conteúdo exibido e realizar ações em nome da vítima. De acordo com a Microsoft, o ataque pode ser iniciado remotamente sem autenticação prévia. O vetor principal envolve o envio de um e-mail manipulado que, ao ser processado pelo Outlook Web Access, permite que o código malicioso seja executado no navegador do usuário afetado. A empresa informou que versões online do serviço, como o Exchange Online do Microsoft 365, não são impactadas pela vulnerabilidade. O problema afeta exclusivamente instalações locais das seguintes versões: Exchange Server 2016 Exchange Server 2019 Exchange Server Subscription Edition (SE) Todos os níveis de atualização dessas versões estão vulneráveis. Enquanto trabalha em uma correção definitiva, a Microsoft disponibilizou uma mitigação temporária por meio do Exchange Emergency Mitigation Service. O mecanismo aplica automaticamente uma configuração de reescrita de URL destinada a bloquear a exploração da falha. O recurso vem habilitado por padrão, mas administradores devem verificar se o serviço do Windows responsável pela funcionalidade está ativo. Para ambientes isolados ou com restrições de acesso externo, como infraestruturas air-gapped, a companhia orienta o uso da ferramenta Exchange On-Premises Mitigation Tool (EOMT). O script pode ser executado individualmente em cada servidor ou aplicado em massa via Exchange Management Shell com privilégios elevados. A Microsoft também reconheceu um problema conhecido relacionado à exibição da mitigação. Em alguns casos, o sistema pode mostrar a mensagem “Mitigation invalid for this exchange version.” no campo de descrição. Segundo a empresa, trata-se apenas de um erro visual e a mitigação continua sendo aplicada corretamente quando o status aparece como “Applied”. Embora os detalhes da exploração permaneçam limitados, o caso reacende preocupações envolvendo servidores Exchange on-premises, historicamente visados por grupos hackers em campanhas de espionagem, acesso inicial e comprometimento de ambientes corporativos. Como o Exchange frequentemente opera integrado a autenticação corporativa, e-mail interno e serviços críticos de colaboração, falhas exploráveis remotamente tendem a representar alto risco operacional para empresas e governos. A recomendação imediata é aplicar as mitigações fornecidas pela Microsoft e acompanhar a liberação da correção definitiva para reduzir a superfície de ataque e evitar possíveis comprometimentos.

Pesquisadores divulgaram quatro vulnerabilidades no OpenClaw que podem ser encadeadas para permitir roubo de dados, escalada de privilégios e persistência em sistemas comprometidos. O conjunto de falhas foi chamado de Claw Chain pela Cyera e afeta componentes do OpenShell, sandbox gerenciado e runtime MCP loopback. As falhas incluem a CVE-2026-44112, uma condição de corrida TOCTOU no backend sandbox do OpenShell, com pontuação CVSS 9.6/6.3. A vulnerabilidade permite contornar restrições da sandbox e redirecionar gravações para fora da raiz de montagem prevista. Na prática, um invasor poderia alterar configurações, inserir backdoors e manter controle persistente sobre o host comprometido. A CVE-2026-44113, com CVSS 7.7/6.3, também envolve uma condição de corrida TOCTOU no OpenShell. Nesse caso, a exploração permite ler arquivos fora da raiz de montagem pretendida, abrindo caminho para acesso a arquivos de sistema, credenciais, segredos e artefatos internos. Outra falha, identificada como CVE-2026-44115, recebeu pontuação CVSS 8.8 e está relacionada a uma lista incompleta de entradas bloqueadas. Segundo a análise, invasores poderiam burlar a validação por allowlist ao incorporar tokens de expansão de shell no corpo de um here document, conhecido como heredoc, possibilitando a execução de comandos não aprovados em tempo de execução. A quarta vulnerabilidade, CVE-2026-44118, com CVSS 7.8, decorre de controle de acesso inadequado. A falha poderia permitir que clientes loopback que não são proprietários se passassem por donos do ambiente, elevando privilégios e assumindo controle sobre configurações de gateway, agendamento cron e gerenciamento do ambiente de execução. A cadeia de exploração descrita pela Cyera começa com um plugin malicioso, uma injeção de prompt ou uma entrada externa comprometida obtendo execução de código dentro da sandbox do OpenShell. Em seguida, o invasor poderia explorar as CVEs 2026-44113 e 2026-44115 para expor credenciais, segredos e arquivos sensíveis. Depois, a CVE-2026-44118 permitiria obter controle em nível de proprietário sobre o runtime do agente. Por fim, a CVE-2026-44112 poderia ser usada para implantar backdoors, alterar configurações e estabelecer persistência. De acordo com a Cyera, a causa raiz da CVE-2026-44118 está no fato de o OpenClaw confiar em um sinalizador de propriedade controlado pelo cliente, chamado senderIsOwner. Esse campo indicava se o chamador estava autorizado a usar ferramentas restritas ao proprietário, mas sem validação adequada contra a sessão autenticada. Em seu comunicado de correção, o OpenClaw informou que o runtime MCP loopback passou a emitir tokens bearer separados para proprietários e não proprietários. A definição de senderIsOwner agora é derivada exclusivamente do token usado na autenticação da requisição. O cabeçalho falsificável deixou de ser emitido ou considerado confiável. As quatro vulnerabilidades foram corrigidas no OpenClaw 2026.4.22 após divulgação responsável. O pesquisador Vladimir Tokarev foi creditado pela descoberta e pelo reporte das falhas. A recomendação para usuários é atualizar para a versão mais recente para reduzir o risco de exploração. Para a Cyera, o risco central está no uso dos próprios privilégios do agente contra o ambiente. Ao transformar o agente em uma ferramenta operacional dentro da infraestrutura, um invasor pode avançar por etapas de acesso a dados, escalada de privilégios e persistência com ações que podem parecer comportamento legítimo para controles tradicionais, ampliando o impacto potencial e dificultando a detecção.

Um pesquisador de segurança conhecido pelos pseudônimos Chaotic Eclipse e Nightmare-Eclipse divulgou duas novas vulnerabilidades zero-day no Microsoft Windows que afetam diretamente mecanismos críticos de segurança do sistema operacional, incluindo o BitLocker e o componente Windows Collaborative Translation Framework (CTFMON). As falhas foram apelidadas de YellowKey e GreenPlasma e surgem poucas semanas após o mesmo pesquisador publicar outros três zero-days relacionados ao Microsoft Defender. Segundo o pesquisador, as novas vulnerabilidades podem permitir bypass de criptografia, obtenção de privilégios SYSTEM e execução arbitrária de comandos em sistemas Windows vulneráveis. A vulnerabilidade mais crítica, chamada YellowKey, afeta o Windows 11 e Windows Server 2022/2025. O problema está relacionado ao Windows Recovery Environment (WinRE), ambiente de recuperação utilizado para reparar sistemas operacionais que falharam durante a inicialização. De acordo com a análise divulgada, o ataque funciona através da utilização de arquivos “FsTx” especialmente manipulados em um dispositivo USB ou na partição EFI do sistema. Após conectar o dispositivo ao computador alvo com BitLocker habilitado e reiniciar o sistema no ambiente WinRE, o invasor consegue acionar um shell de comandos utilizando a tecla CTRL. O pesquisador afirma que o comportamento funciona praticamente como um backdoor oculto dentro do mecanismo de recuperação do Windows. Segundo ele, o bypass continua explorável mesmo em cenários protegidos por TPM+PIN, mecanismo considerado uma das configurações mais seguras do BitLocker. O pesquisador de segurança Will Dormann confirmou ter conseguido reproduzir o ataque utilizando apenas um pendrive conectado ao sistema. Segundo sua análise, estruturas Transactional NTFS presentes na pasta “System Volume Information\FsTx” conseguem modificar arquivos em outro volume montado pelo ambiente de recuperação, incluindo o arquivo “winpeshl.ini”, permitindo abrir um prompt cmd.exe com o BitLocker já desbloqueado. Além do bypass de criptografia, o segundo zero-day divulgado, chamado GreenPlasma, afeta o processo CTFMON do Windows e pode permitir escalada de privilégios para SYSTEM. A falha envolve criação arbitrária de seções de memória em diretórios acessíveis por processos privilegiados do sistema operacional. Embora a prova de conceito divulgada esteja incompleta, especialistas alertam que o problema pode ser utilizado para manipular serviços privilegiados ou drivers que confiam implicitamente nesses caminhos de memória, criando possibilidades de execução privilegiada a partir de contas sem privilégios administrativos. O caso ganha ainda mais relevância porque o pesquisador já havia divulgado anteriormente três falhas no Microsoft Defender chamadas BlueHammer, RedSun e UnDefend. Segundo Chaotic Eclipse, parte dessas vulnerabilidades teria sido explorada ativamente após divergências com a Microsoft sobre o processo de divulgação responsável. Paralelamente, a empresa francesa Intrinsec revelou uma nova cadeia de ataque contra o BitLocker baseada em downgrade do boot manager do Windows através da CVE-2025-48804. O método permite contornar a proteção de criptografia mesmo em sistemas totalmente atualizados em menos de cinco minutos. A técnica explora limitações do Secure Boot, que verifica a assinatura digital dos binários de boot, mas não valida suas versões específicas. Com isso, versões antigas e vulneráveis do arquivo “bootmgfw.efi”, ainda assinadas por certificados confiáveis da Microsoft, podem ser carregadas para burlar as proteções do BitLocker. Segundo os pesquisadores, o ataque exige acesso físico ao equipamento, mas representa um risco importante para ambientes corporativos, notebooks corporativos, estações administrativas e dispositivos utilizados em cenários de alta sensibilidade operacional. Como mitigação, especialistas recomendam habilitar autenticação pré-boot com PIN no BitLocker, atualizar o boot manager para os novos certificados CA 2023 e revogar os antigos certificados PCA 2011 que ainda permitem o carregamento de componentes vulneráveis.

Pesquisadores divulgaram uma vulnerabilidade crítica no NGINX que permaneceu oculta por aproximadamente 18 anos e pode permitir execução remota de código (RCE) sem autenticação em servidores vulneráveis. A falha, identificada como CVE-2026-42945 e apelidada de “NGINX Rift”, afeta o módulo ngx_http_rewrite_module presente tanto no NGINX Open Source quanto no NGINX Plus. Segundo os pesquisadores da depthfirst, responsáveis pela descoberta, o problema possui pontuação CVSS v4 de 9.2 e pode ser explorado remotamente através de uma única requisição HTTP especialmente manipulada. O bug é classificado como um heap buffer overflow, condição em que dados gravados além do limite previsto na memória podem corromper estruturas internas do processo afetado. Em cenários específicos, isso pode resultar em execução arbitrária de código no processo worker do NGINX ou provocar falhas contínuas de disponibilidade. De acordo com a F5, a vulnerabilidade ocorre quando a diretiva rewrite é utilizada em combinação com outras diretivas como rewrite, if ou set, além do uso de capturas PCRE não nomeadas — como $1 e $2 — em strings de substituição contendo o caractere “?”. A exploração acontece através do envio de URIs maliciosas para o servidor vulnerável. Como o ataque não exige autenticação, sessão ativa ou acesso prévio ao ambiente, a superfície de risco é considerada extremamente elevada, especialmente em infraestruturas expostas diretamente à internet. Segundo os pesquisadores, os dados escritos além da região válida da memória são parcialmente controlados pelo invasor, permitindo manipular a corrupção da heap de forma previsível. Além do potencial de RCE, ataques repetidos também podem manter processos workers do NGINX em ciclos contínuos de crash, causando indisponibilidade para todos os sites hospedados na instância afetada. A possibilidade de execução remota de código depende de alguns fatores adicionais, como a desativação do ASLR (Address Space Layout Randomization), mecanismo de proteção utilizado pelos sistemas operacionais modernos para dificultar exploração de memória. Mesmo assim, especialistas alertam que o risco continua crítico devido à facilidade de exploração e ao impacto operacional potencial. O problema afeta diversas versões do ecossistema NGINX, incluindo NGINX Open Source, NGINX Plus, NGINX Ingress Controller, NGINX Gateway Fabric, App Protect WAF e soluções DoS da F5. As correções foram disponibilizadas nas versões: NGINX Open Source 1.30.1 e 1.31.0 NGINX Plus R32 P6 e R36 P4 Versões mais antigas entre 0.6.27 e 0.9.7 não receberão correções oficiais. Além da CVE-2026-42945, a F5 também corrigiu outras três vulnerabilidades relevantes no NGINX: CVE-2026-42946: falha de alocação excessiva de memória nos módulos SCGI e UWSGI que pode permitir leitura de memória ou reinicialização do worker process. CVE-2026-40701: vulnerabilidade use-after-free no módulo SSL que pode causar corrupção limitada de dados ou reinicialização do processo. CVE-2026-42934: falha out-of-bounds read que pode expor conteúdos da memória do servidor. A recomendação oficial é que administradores atualizem imediatamente para as versões corrigidas. Nos casos em que a aplicação do patch não seja possível no curto prazo, a orientação é modificar regras rewrite vulneráveis substituindo capturas não nomeadas por capturas nomeadas dentro das expressões regulares utilizadas na configuração. O caso chama atenção não apenas pela gravidade técnica, mas também pelo tempo que a vulnerabilidade permaneceu invisível em um dos servidores web mais utilizados do mundo. O NGINX está presente em data centers, aplicações cloud, APIs, plataformas SaaS, Kubernetes Ingress Controllers e infraestruturas críticas amplamente expostas à internet.

Muito antes da explosão da computação em nuvem, dos containers e das grandes plataformas de cloud, alguns brasileiros já participavam diretamente do desenvolvimento das tecnologias que sustentariam parte significativa da internet moderna. Entre eles está Marcelo Tosatti, que entrou para a história do software livre ao assumir, aos 18 anos, a manutenção da árvore estável do kernel Linux 2.4 — uma das versões mais importantes do sistema operacional no início dos anos 2000. Na época, o Linux 2.4 era utilizado em servidores corporativos, provedores de internet, universidades, supercomputadores e infraestruturas críticas ao redor do mundo. A versão representava um dos pilares técnicos da expansão da internet comercial e da consolidação do Linux no ambiente corporativo. A chegada de Marcelo à função ocorreu após Alan Cox, um dos mais respeitados mantenedores do projeto Linux, informar a Linus Torvalds que não desejava mais continuar responsável pela manutenção da série 2.4. Questionado sobre quem poderia assumir a função, Alan indicou o jovem brasileiro que trabalhava na Conectiva, companhia que se tornou referência em software livre na América Latina durante os anos 1990 e início dos anos 2000. Linus então enviou um e-mail perguntando se Marcelo tinha interesse em assumir a responsabilidade. A resposta foi simples: “sure”. Sem processos formais, entrevistas ou estruturas corporativas, o ecossistema do kernel Linux sempre operou com uma lógica baseada em mérito técnico e contribuições práticas para o projeto. Marcelo começou a programar ainda na infância e já trabalhava profissionalmente com Linux aos 13 anos. Poucos anos depois, passou a integrar um dos níveis mais críticos da manutenção do kernel utilizado em grande parte da infraestrutura digital da época. Mas ele não foi o único brasileiro a ganhar destaque no núcleo de desenvolvimento do Linux. Outro nome relevante é Glauber Costa, engenheiro que atuou diretamente em áreas fundamentais do subsistema x86 do kernel — responsável pela compatibilidade com arquiteturas Intel e AMD presentes em praticamente todos os servidores e desktops modernos. Em 2008, Glauber apareceu entre os principais contribuidores do subsistema x86 em uma lista publicada por Linus Torvalds, ao lado de nomes históricos como Ingo Molnár e Thomas Gleixner. Suas contribuições envolveram tecnologias relacionadas a virtualização, gerenciamento de memória e KVM, componentes essenciais para a evolução da infraestrutura cloud moderna. Parte desse trabalho esteve ligada à evolução dos memory cgroups, mecanismo utilizado pelo Linux para controle e isolamento de recursos computacionais. A tecnologia se tornaria uma das bases utilizadas posteriormente em containers modernos e plataformas como Docker e Kubernetes. O Brasil também possui outros nomes historicamente relevantes no desenvolvimento do Linux, como Arnaldo Carvalho de Melo, mantenedor da ferramenta perf, amplamente utilizada para análise de performance do kernel, e Mauro Carvalho Chehab, conhecido pelo trabalho em subsistemas de mídia e drivers do Linux. Embora pouco conhecidas fora dos círculos técnicos, essas contribuições ajudaram a construir tecnologias que hoje sustentam data centers, provedores cloud, plataformas de streaming, ambientes corporativos e serviços utilizados diariamente por bilhões de pessoas. A história desses desenvolvedores também ajuda a quebrar uma percepção comum no setor de tecnologia de que inovação em infraestrutura crítica acontece exclusivamente nos Estados Unidos ou em grandes polos tecnológicos globais. No universo do software livre e do kernel Linux, o reconhecimento sempre esteve ligado à capacidade técnica e à qualidade das contribuições entregues à comunidade internacional. E foi exatamente nesse ambiente que diversos brasileiros conquistaram espaço entre alguns dos engenheiros mais respeitados da computação moderna.

O sistema público de saúde da Inglaterra confirmou uma mudança de política que permitirá que funcionários da Palantir Technologies tenham acesso direto a dados identificáveis de pacientes do NHS, ampliando as permissões anteriormente concedidas dentro do controverso projeto Federated Data Platform (FDP). A plataforma é operada pela NHS England e utiliza tecnologia fornecida pela Palantir por meio de um contrato avaliado em £330 milhões, equivalente a aproximadamente US$ 446 milhões. O objetivo do FDP é centralizar e compartilhar dados entre diferentes unidades do sistema público de saúde britânico para otimizar operações, reduzir filas acumuladas após a pandemia e monitorar o desempenho do NHS. Até então, funcionários da Palantir envolvidos no projeto só podiam acessar conjuntos específicos de dados mediante autorização pontual e limitada dentro do National Data Integration Tenant (NDIT), repositório que armazena informações de pacientes antes da transferência para ambientes analíticos pseudonimizados. Com a mudança, alguns profissionais da empresa poderão receber um novo perfil administrativo com acesso ampliado ao NDIT, incluindo informações identificáveis de pacientes. Outros consultores externos que trabalham no FDP também terão permissões semelhantes. Documentos internos confirmados pelo NHS e obtidos inicialmente pelo Financial Times apontam que a própria organização reconheceu o risco de perda de confiança pública relacionado à decisão. O material afirma que ampliar o acesso de funcionários da Palantir aos dados poderia comprometer as garantias anteriormente apresentadas sobre proteção, governança e uso apropriado das informações médicas. Segundo o NHS England, o acesso será restrito a um pequeno grupo de profissionais envolvidos na implementação da plataforma central de coleta e monitoramento de desempenho do sistema de saúde. A organização afirmou ainda que qualquer pessoa externa que necessite acessar os dados deverá possuir autorização de segurança do governo britânico e aprovação formal de diretores do NHS. O caso reacende críticas históricas envolvendo a participação da Palantir em projetos governamentais e de vigilância. A empresa, fundada com apoio de investimentos ligados à comunidade de inteligência dos Estados Unidos, mantém contratos com órgãos militares, agências de segurança e governos ao redor do mundo, o que frequentemente gera debates sobre privacidade e uso ético de dados sensíveis. Sam Smith, coordenador do grupo de privacidade medConfidential, afirmou que funcionários da Palantir já possuíam algum nível de acesso a dados pseudonimizados em outras áreas do FDP. Para ele, o principal problema foi a falta de transparência do NHS sobre o real alcance dessas permissões. De acordo com Smith, a divulgação do tema ocorreu por meio de vazamentos internos, e não de uma comunicação pública clara sobre o funcionamento do acesso aos dados médicos. A crítica reforça preocupações recorrentes sobre governança, consentimento e prestação de contas em projetos de centralização de informações de saúde. O debate ocorre em um momento delicado para o NHS. Em março, a publicação Health Service Journal informou que quase um terço das unidades do sistema conectadas ao FDP em 2025 não atendiam integralmente aos padrões de segurança de dados exigidos. Mesmo diante das críticas, autoridades britânicas insistem que o NHS continua sendo o controlador exclusivo das informações. O ministro responsável pelo projeto, Zubir Ahmed, declarou recentemente ao Parlamento que a Palantir não possui propriedade sobre os dados, produtos ou propriedade intelectual da plataforma, e que todas as permissões são rigidamente controladas pelo governo britânico. Segundo Ahmed, a empresa opera sob um contrato regulado no Reino Unido e só pode utilizar informações para finalidades previamente aprovadas que tragam benefícios aos pacientes. A controvérsia envolvendo o FDP também chama atenção para uma tendência crescente em governos e sistemas de saúde: a adoção de plataformas centralizadas de análise de dados em larga escala. Embora essas iniciativas prometam ganhos operacionais, eficiência e inteligência analítica, elas também ampliam a superfície de risco relacionada à privacidade, vazamento de dados sensíveis e abuso de acesso privilegiado.

Uma instituição financeira dos Estados Unidos reportou a si própria à SEC, órgão regulador do mercado financeiro norte-americano, após identificar que dados confidenciais de clientes foram inseridos em uma aplicação de inteligência artificial não autorizada pela organização. O caso envolve o Community Bank, banco regional com operações nos estados da Pensilvânia, Ohio e Virgínia Ocidental. A empresa informou que iniciou uma investigação interna sobre o incidente e decidiu formalizar a ocorrência por meio de um documento 8-K enviado à Securities and Exchange Commission (SEC), devido ao “volume e à natureza sensível das informações não públicas” envolvidas. Segundo o comunicado, os dados expostos incluem nomes de clientes, datas de nascimento e números de Social Security Number (SSN), equivalente ao CPF nos Estados Unidos. O banco não revelou quantas pessoas foram afetadas nem forneceu detalhes técnicos adicionais sobre o vazamento. A instituição também não especificou qual era a “aplicação de software baseada em IA não autorizada” utilizada internamente. Ainda assim, a descrição do incidente levanta a possibilidade de que funcionários tenham inserido informações sigilosas em ferramentas de IA generativa fora do ambiente corporativo aprovado pela instituição. Caso esse cenário seja confirmado, especialistas apontam que os dados podem ter sido transmitidos para plataformas terceirizadas de inteligência artificial, o que abre discussões sobre retenção, processamento e possível reutilização dessas informações pelos provedores dos serviços. Nos Estados Unidos, números de Social Security são considerados dados extremamente sensíveis e estão protegidos por diversas legislações estaduais e federais. Vazamentos desse tipo podem aumentar significativamente o risco de fraude financeira, roubo de identidade e golpes direcionados contra clientes. O episódio também reforça uma preocupação crescente no setor financeiro: o uso não controlado de ferramentas de IA generativa dentro de ambientes corporativos. Nos últimos meses, empresas de diversos segmentos passaram a restringir ou monitorar o uso de plataformas de IA por colaboradores após casos envolvendo exposição involuntária de código-fonte, documentos internos, dados financeiros e informações pessoais. Apesar do incidente, o Community Bank afirmou que não houve impacto operacional. Segundo a instituição, os clientes continuaram tendo acesso normal às contas e aos serviços de pagamento durante toda a investigação. O banco informou ainda que está avaliando quais dados foram efetivamente afetados e conduzindo as notificações obrigatórias conforme exigências regulatórias e leis federais e estaduais aplicáveis. A organização também confirmou que segue em contato com reguladores bancários e financeiros dos Estados Unidos enquanto implementa medidas corretivas para evitar novos incidentes. O caso evidencia um desafio crescente para instituições financeiras e empresas altamente reguladas: equilibrar o uso de inteligência artificial com políticas rígidas de governança, classificação da informação e prevenção contra vazamento de dados sensíveis. Sem controles claros, ferramentas de IA podem acabar se tornando um novo vetor de exposição involuntária de informações críticas.

O Google está preparando uma nova linha de laptops baseados em Android, em vez do ChromeOS, em uma tentativa de reposicionar sua presença no mercado de computadores portáteis e avançar para um segmento mais premium. Os novos dispositivos, chamados informalmente de Googlebooks no material original, devem combinar elementos do ChromeOS e do Android, mas com uma diferença central: a inteligência artificial Gemini estará profundamente integrada à experiência do sistema. A proposta marca uma mudança importante na estratégia da empresa. Por anos, os Chromebooks foram associados principalmente a dispositivos mais simples, acessíveis e populares em ambientes educacionais. Com os novos laptops Android, o Google parece buscar um espaço mais próximo dos notebooks premium com Windows e macOS, usando o ecossistema Android como diferencial competitivo. A movimentação também reforça uma tendência cada vez mais evidente entre grandes empresas de tecnologia: integrar assistentes de IA diretamente ao sistema operacional e aos fluxos de trabalho do usuário. No caso dos Googlebooks, a presença do Gemini parece ir além de um aplicativo ou painel lateral. Segundo a demonstração apresentada pela empresa, a IA será acionada de forma contextual em diferentes partes da interface, inclusive a partir do movimento do cursor sobre elementos na tela. Um dos recursos destacados é o Magic Pointer. A função é ativada quando o usuário movimenta o cursor de determinada forma e passa a exibir sugestões baseadas no conteúdo sobre o qual o ponteiro está posicionado. Em um exemplo demonstrado por Alexander Kuscher, diretor sênior de laptops e tablets do Google, ao passar o cursor sobre uma data em um e-mail, o sistema apresentou opções para consultar a agenda, criar uma resposta confirmando presença na cidade em 19 de maio e até usar o Google Maps para sugerir locais de encontro. Na prática, o recurso transforma ações comuns, como ler um e-mail ou selecionar uma informação, em pontos de entrada para tarefas automatizadas com IA. A ideia é reduzir etapas que normalmente exigiriam abrir um chatbot, copiar informações, formular um prompt e aguardar uma resposta. Ao mesmo tempo, a abordagem pode gerar incômodo para usuários que preferem sistemas menos intervencionistas ou que não desejam sugestões de IA surgindo em tarefas rotineiras. Outro exemplo apresentado envolve manipulação de imagens por arrastar e soltar. Durante a demonstração, Kuscher arrastou a foto de um quarto infantil sobre imagens de um papel de parede e de um berço. O sistema então gerou uma nova imagem combinando os elementos, criando uma visualização do ambiente com o berço e o papel de parede aplicados. Segundo o executivo, uma tarefa desse tipo normalmente exigiria acessar um chatbot, enviar os arquivos e escrever instruções; no Googlebook, o processo seria integrado diretamente à interface. O texto original observa que não foi esclarecido se o sistema poderia usar fotos dos usuários como dados de treinamento. Esse ponto é relevante porque a expansão de recursos generativos em sistemas operacionais aumenta a necessidade de transparência sobre privacidade, processamento local ou em nuvem, retenção de dados e uso de conteúdo pessoal para melhoria de modelos. Os Googlebooks também devem executar aplicativos Android, o que aproxima os notebooks do ecossistema móvel do Google. A demonstração mostrou o Duolingo rodando em uma janela vertical, semelhante à experiência em um smartphone. Os usuários também poderão iniciar aplicativos a partir do telefone, em uma abordagem comparável ao espelhamento de iPhone no ecossistema da Apple. O Google informou que os novos laptops serão produzidos com materiais e acabamento premium por parceiros como Acer, ASUS, Dell, HP e Lenovo. Os dispositivos também devem trazer uma barra luminosa com as cores do Google na tampa, um elemento visual voltado à identificação da linha. A chegada dos Googlebooks, no entanto, ocorre em um momento desafiador para o mercado de PCs. O texto menciona a escassez de memória RAM e a previsão da IDC de queda de 11,3% nas remessas de PCs em 2026. Ainda não há preços oficiais, mas a expectativa é que os novos modelos sejam significativamente mais caros que os Chromebooks, tradicionalmente vendidos nos Estados Unidos em uma faixa aproximada de US$ 200 a US$ 500. Esse posicionamento pode colocar os Googlebooks em concorrência direta com notebooks premium de consumo baseados em Windows e macOS. O desafio é que esse mercado enfrenta pressão por queda de demanda, enquanto consumidores tendem a manter dispositivos antigos por mais tempo. O texto também aponta que não há sinais claros de que o Google esteja mirando empresas, e que departamentos de TI podem não se interessar pelas funcionalidades priorizadas na apresentação. Além dos laptops Android, o Google anunciou a expansão do Gemini Intelligence para dispositivos Android de alto desempenho, incluindo modelos Samsung Galaxy e Google Pixel. A proposta é permitir que o telefone lide com tarefas consideradas repetitivas ou pouco produtivas, como preencher formulários online, resumir páginas da web e reescrever mensagens transcritas por voz para remover pausas e marcas naturais da fala. Durante a mesma apresentação, o Google também mostrou recursos previstos para o Android 17. Um deles é o Pause Point, uma função que permite marcar determinados aplicativos como distrativos. Quando o usuário tenta abrir esses apps, o sistema exibe uma solicitação para respirar fundo e reconsiderar a ação. A proposta segue uma linha semelhante a recursos de bem-estar digital já explorados por outras plataformas, mas com uma intervenção mais direta no momento de uso. Outra novidade é o Screen Reactions, recurso que permitirá capturar a tela do dispositivo junto com a imagem do próprio usuário em um canto inferior, facilitando a criação de vídeos de reação diretamente no Android. A funcionalidade aproxima o sistema operacional de formatos populares em redes sociais, especialmente vídeos em que criadores comentam conteúdos exibidos na tela. Ainda não está claro o que acontecerá com a linha Chromebook após a chegada dos Googlebooks. O texto informa que o Google foi questionado sobre o futuro dos dispositivos mais acessíveis, mas não respondeu. A expectativa apresentada é que os Chromebooks continuem atendendo o mercado educacional por algum tempo, enquanto os novos laptops Android tentam disputar uma faixa mais alta do mercado. A aposta do Google mostra como a inteligência artificial está deixando de ser apenas um recurso adicional para se tornar parte estrutural dos sistemas operacionais. Nos Googlebooks, o Gemini aparece como uma camada permanente de assistência, automação e criação. A questão é se os usuários verão isso como produtividade ampliada ou como mais uma tentativa de tornar a IA impossível de ignorar.

A Microsoft está alterando a forma como o Copilot aparece e pode ser acionado dentro dos aplicativos do Microsoft 365, em uma tentativa de tornar o assistente de inteligência artificial mais acessível para usuários de Word, Excel e PowerPoint. A mudança, descrita pela empresa como uma forma de “simplificar” o acesso ao recurso, também reacendeu críticas de usuários que consideram a presença do Copilot invasiva ou difícil de ignorar. Segundo a Microsoft, muitos usuários relataram não saber exatamente como começar a interagir com o Copilot nos aplicativos de produtividade. A empresa não detalhou de onde vieram esses comentários, mas a justificativa foi usada para explicar a decisão de reduzir e reorganizar os pontos de entrada do assistente dentro da interface do Office. A medida chega em um momento em que parte da base de usuários pede justamente mais controle sobre a presença da ferramenta. No fórum de feedback do Microsoft 365 Copilot, uma das solicitações mais votadas era por controles mais granulares de disponibilidade dos agentes. Entre os pedidos populares também estava a opção de desativar o botão flutuante do Copilot nos aplicativos do Office, descrito por alguns usuários como um recurso altamente disruptivo. Um dos comentários citados no pedido afirmava que impedir a remoção da “bolha” flutuante era uma decisão “além de desagradável”. A reação ilustra um ponto sensível na estratégia da Microsoft: ao mesmo tempo em que a empresa tenta acelerar a adoção da inteligência artificial nos aplicativos corporativos, parte dos usuários vê a integração como excessivamente presente na rotina de trabalho. Apesar das críticas, a Microsoft seguirá com a reformulação da interface. A principal mudança será a redução do número de formas de acesso ao Copilot. A partir da atualização, os usuários terão um ícone do Copilot no canto inferior direito da tela. Ao passar o cursor sobre o botão, o sistema poderá exibir sugestões de uso. Também haverá um ponto de entrada contextual quando o usuário interagir com algum conteúdo, como no caso de selecionar um trecho de texto. Na prática, a empresa tenta tornar o Copilot mais previsível dentro da experiência do Office. Em vez de múltiplos caminhos espalhados pela interface, a proposta é concentrar o acesso em locais específicos e vinculados ao contexto de uso. Isso pode facilitar a descoberta de recursos por quem ainda não incorporou o assistente à rotina, mas também mantém a ferramenta visível para usuários que prefeririam uma interface menos orientada por IA. A Microsoft também atualizou os atalhos de teclado relacionados ao Copilot. No Windows, pressionar F6 passará a mover o foco para o botão do Copilot dentro da área de trabalho do aplicativo. A tecla de seta para cima permitirá navegar entre prompts, enquanto o atalho Alt+C poderá mover o foco para o painel do Copilot Chat quando ele já estiver aberto. No Mac, os usuários deverão pressionar Cmd + Control + I para direcionar o foco ao botão do Copilot. Essas alterações indicam que a Microsoft está tentando transformar o Copilot em um elemento mais integrado ao fluxo natural de edição, análise e criação de documentos. A própria empresa afirmou que, em breve, o Copilot poderá editar conteúdo diretamente a partir da conversa, reforçando a visão de que o assistente deve atuar não apenas como uma ferramenta auxiliar, mas como parte ativa da experiência de produtividade. A recepção, no entanto, permanece dividida. O primeiro comentário na publicação da Microsoft sobre a novidade questionava como impedir totalmente a exibição do ícone, afirmando que até mesmo a versão fixada do botão era incômoda. A crítica resume o desconforto de usuários que não rejeitam necessariamente recursos de IA, mas querem maior capacidade de decidir quando e como eles aparecem na interface. As mudanças devem chegar à disponibilidade geral no Word, Excel e PowerPoint para Windows e Mac até o início de junho. Para empresas, a atualização pode exigir atenção adicional das equipes de TI e governança digital, especialmente em ambientes que adotam políticas mais rígidas sobre experiência do usuário, uso de IA generativa, produtividade assistida e controle de recursos habilitados nos aplicativos corporativos.

Um veterano arquiteto de redes chamado James Thain apresentou uma proposta para o “Internet Protocol Version 8”, ou IPv8, com a promessa de ampliar a capacidade do IPv4, preservar compatibilidade com a infraestrutura existente e evitar uma migração forçada para o IPv6. A ideia foi publicada como um Internet-Draft da Internet Engineering Task Force (IETF) em 16 de abril, mas, como todo documento desse tipo, ainda não possui status oficial nem representa uma decisão formal da entidade. A proposta tem chamado atenção no setor de redes porque não tenta simplesmente substituir o IPv6 ou criar uma nova arquitetura completamente incompatível. O objetivo declarado de Thain é evoluir o IPv4, adicionando uma espécie de “código de área” baseado em Autonomous System Numbers, conhecidos como ASNs. Esses números são identificadores únicos atribuídos por registros regionais da internet a operadores de rede e são usados para orientar decisões de roteamento entre redes autônomas. No site dedicado ao IPv8, Thain descreve o protocolo como uma suíte de rede gerenciada capaz de resolver o esgotamento do IPv4, unificar a administração de redes e manter 100% de compatibilidade retroativa. Segundo ele, não haveria necessidade de uma “flag day”, expressão usada para indicar uma migração coordenada e obrigatória em larga escala, nem de substituição imediata de dispositivos, aplicações ou redes existentes. O rascunho técnico afirma que o IPv4 seria um subconjunto adequado do IPv8. Na prática, isso significa que um endereço IPv8 com o campo de prefixo de roteamento definido como zero corresponderia a um endereço IPv4 tradicional. A proposta tenta preservar a lógica já conhecida da pilha IPv4, adicionando uma camada de identificação que permitiria ampliar drasticamente o espaço de endereçamento disponível. Em entrevista ao The Register, Thain afirmou que criou o rascunho porque os protocolos atuais foram desenvolvidos para resolver problemas de rede de outra época. Para ele, a realidade operacional da internet mudou, mas a evolução dos protocolos não acompanhou plenamente essa transformação. O arquiteto também argumenta que, fora grandes provedores de nuvem, hyperscalers e operadores de rede, muitas organizações não enxergam retorno claro sobre o investimento em uma migração para IPv6. Thain reconhece que o esgotamento dos endereços IPv4 pressiona empresas e operadoras a considerar o IPv6. Ainda assim, ele defende que a melhor abordagem seria melhorar o IPv4 para entregar um protocolo mais eficiente sem exigir uma atualização ampla da infraestrutura. Essa visão é justamente um dos pontos mais polêmicos da proposta, já que o IPv6 foi desenvolvido para resolver, entre outros desafios, a limitação estrutural do IPv4. O principal mecanismo sugerido pelo IPv8 é um novo formato de endereço no modelo r.r.r.r.n.n.n.n. Nesse esquema, o bloco “r” representa o ASN codificado como um inteiro de 32 bits, enquanto o bloco “n” corresponde a um endereço IPv4 convencional. A lógica é semelhante ao uso de um código de área em sistemas telefônicos: o identificador da rede amplia o contexto no qual o endereço IPv4 é interpretado. Com esse modelo, cada detentor de ASN receberia 2³² endereços de host, o equivalente a 4.294.967.296 endereços por organização ou operador de rede. Thain considera esse volume suficiente para quase todas as entidades conectadas à internet. Organizações que precisassem de mais capacidade provavelmente já operariam múltiplos ASNs, o que, segundo a proposta, permitiria expandir ainda mais o uso do modelo. A estimativa apresentada é que o IPv8 ampliaria o espaço de endereçamento IPv4 para cerca de 30 trilhões de endereços únicos. Esse número é muito inferior aos aproximadamente 340 undecilhões de endereços disponíveis no IPv6, mas, na avaliação de Thain, ainda seria suficiente para atender às necessidades práticas de grande parte do mercado, com a vantagem de manter uma continuidade operacional maior com o IPv4. Thain também argumenta que a adoção do IPv8 não exigiria mudanças profundas em protocolos de roteamento consolidados. Segundo ele, o Border Gateway Protocol, ou BGP, já sabe lidar com múltiplos protocolos, e o mesmo vale para MPLS. Na visão do arquiteto, o IPv8 seria uma evolução incremental do IPv4, exigindo servidores capazes de traduzir os chamados “códigos de área”, enquanto o restante da pilha permaneceria amplamente conhecido pelos profissionais de rede. Além do novo modelo de endereçamento, a proposta inclui um componente chamado “Zone server”. De acordo com o rascunho, esse servidor concentraria serviços necessários a um segmento de rede, incluindo atribuição de endereços por DHCP8, resolução de nomes por DNS8, sincronização de tempo por NTP8, coleta de telemetria por NetLog8, cache de autenticação por OAuth8, validação de rotas por um resolvedor WHOIS8, aplicação de controle de acesso por ACL8 e tradução entre IPv4 e IPv8 por XLATE8. Essa abordagem mostra que o IPv8, na visão de Thain, não seria apenas uma expansão de endereçamento. A proposta tenta combinar roteamento, gerenciamento, autenticação, telemetria e controle operacional em uma suíte de rede integrada. Esse ponto recebeu alguma recepção positiva de especialistas, mesmo entre aqueles que não estão convencidos da viabilidade do protocolo. Silvan Gephart, do provedor Openfactory, comentou que aprecia o fato de a proposta tratar tabela de roteamento, endereçamento, gestão, autenticação e complexidade operacional como partes de um problema maior. A observação sugere que, embora o IPv8 enfrente resistência, parte da comunidade reconhece que a administração da internet moderna envolve desafios que vão além da simples quantidade de endereços disponíveis. As críticas, porém, têm sido duras. Um leitor do The Register classificou o IPv8 como “uma distração e perda de tempo”. Outros questionamentos miram a própria maturidade técnica da proposta, sua viabilidade de adoção e a possibilidade de ela fragmentar ainda mais o debate sobre o futuro do endereçamento IP. Parte das críticas também aponta suspeitas de uso de inteligência artificial na elaboração do documento. Thain não negou ter usado chatbots para trabalhar no rascunho e afirmou considerar esse tipo de apoio uma prática contemporânea. Para ele, a validade da proposta deve ser medida por sua capacidade técnica de funcionar em um ambiente de testes, não apenas pela forma como o documento foi produzido. Para responder aos críticos, o arquiteto iniciou uma campanha de financiamento coletivo com meta de US$ 100 mil. O objetivo é criar um ambiente de testes para o IPv8, desenvolver software de código aberto, financiar pesquisa, montar infraestrutura de validação, produzir demonstrações e publicar documentação técnica. A expectativa de Thain é que um testbed funcional ajude a demonstrar se o protocolo pode cumprir o que promete. Por enquanto, o IPv8 permanece como uma proposta experimental, sem adoção formal pela IETF e sem garantia de aceitação pela comunidade técnica. Ainda assim, o debate em torno do projeto revela uma tensão persistente na internet: enquanto o IPv6 oferece um espaço de endereçamento praticamente inesgotável, a base instalada do IPv4 segue enorme, familiar e economicamente difícil de abandonar para muitas organizações.