A discussão coloca novamente Google e União Europeia em lados opostos de um debate que vai muito além do design da página de resultados. De um lado, os reguladores querem impedir que uma plataforma dominante favoreça seus próprios serviços. Do outro, o Google afirma que as novas regras podem beneficiar grandes intermediários, prejudicar negócios locais e tornar a pesquisa menos útil.

Neste artigo, vamos explicar o que está mudando na Busca do Google na Europa, por que o DMA levou a essas alterações, quais podem ser os efeitos para usuários e pequenas empresas e o que esse conflito revela sobre o poder das Big Techs.

Por que o Google muda a busca na Europa

A origem da mudança está em uma decisão da Comissão Europeia, anunciada em julho de 2026. O órgão aplicou ao Google uma multa de €460 milhões por considerar que a empresa favorecia seus próprios serviços na Busca, incluindo resultados relacionados a compras, hotéis, transporte e esportes.

A legislação europeia determina que empresas classificadas como gatekeepers não podem dar tratamento mais favorável aos próprios serviços quando isso prejudica serviços concorrentes.

No entendimento da Comissão Europeia, o Google apresentava seus produtos com maior destaque, recursos visuais e filtros privilegiados, enquanto serviços de terceiros não recebiam tratamento equivalente.

A empresa recebeu 60 dias para cumprir as determinações. Caso contrário, poderia ficar sujeita a penalidades periódicas que chegam a 5% do faturamento mundial total.

É nesse contexto que surge a nova estrutura da Busca.

O que muda nos resultados do Google na Europa

A principal alteração envolve os chamados Vertical Search Services (VSS), serviços especializados em determinados segmentos, como viagens, hotéis, restaurantes e transporte.

Com o novo formato, um serviço especializado ganha maior destaque no topo dos resultados, seguido por outras duas alternativas com menos informações. Abaixo aparecem módulos tradicionais, mas com determinadas informações removidas.

Entre os serviços que podem ganhar maior visibilidade estão plataformas como Booking.com e Expedia.

O problema apontado pelo Google é que a medida criada para aumentar a concorrência poderia acabar favorecendo justamente empresas intermediárias de grande porte.

Um hotel independente, por exemplo, pode aparecer abaixo de plataformas que agregam centenas ou milhares de estabelecimentos. O usuário então entra primeiro no intermediário, em vez de acessar diretamente o site do hotel.

Essa diferença é importante porque tráfego direto significa relacionamento direto com o cliente. Quando a reserva acontece por meio de um agregador, o negócio pode precisar pagar comissão e perde parte do controle sobre a relação com o consumidor.

Google muda a busca na Europa e remove recursos tradicionais

Outra alteração relevante está nos módulos utilizados para apresentar informações de maneira direta.

Segundo o Google, carrosséis tradicionais relacionados a hotéis, companhias aéreas e restaurantes terão determinadas informações retiradas, incluindo elementos como preços em tempo real.

Para o usuário, isso pode transformar uma consulta simples em uma sequência maior de cliques.

Antes, uma pessoa poderia pesquisar uma hospedagem e visualizar rapidamente diferentes opções, preços e informações diretamente na página de resultados. Com a nova estrutura, parte dessas informações pode exigir uma visita a serviços especializados.

É justamente essa mudança que sustenta a crítica mais forte do Google: a empresa afirma que a experiência fica menos direta e menos eficiente.

A companhia também diz ter realizado testes com milhões de usuários europeus e observado insatisfação, incluindo casos em que usuários precisaram reformular ou repetir pesquisas para encontrar o que procuravam.

Naturalmente, existe outro lado nessa discussão.

Se o Google concentra uma parcela enorme da descoberta de informações na internet, permitir que seus próprios serviços ocupem posições privilegiadas pode dificultar a concorrência. Para os reguladores europeus, portanto, uma pequena perda de conveniência pode ser aceitável se resultar em um mercado mais competitivo.

O impacto para pequenas empresas e sites independentes

Um dos pontos mais controversos está no possível efeito sobre pequenas empresas europeias.

O Google afirma que alterações anteriores relacionadas ao DMA provocaram uma queda de aproximadamente 30% no tráfego gratuito e direto de reservas para empresas europeias. A companhia argumenta que o novo formato pode ampliar esse problema.

Isso é particularmente relevante para negócios que dependem de SEO local e tráfego orgânico.

Um pequeno hotel pode ter um excelente site, preços competitivos e boas avaliações. Mesmo assim, se o usuário encontra primeiro um grande agregador, o negócio pode perder uma oportunidade de conversão direta.

O mesmo vale para restaurantes, empresas de transporte e outros serviços.

Existe ainda uma consequência para profissionais de SEO. Durante anos, otimizar uma página para aparecer bem no Google significava disputar posições diretamente com outros sites. Agora, a arquitetura dos resultados também pode determinar qual tipo de intermediário recebe a maior exposição.

Isso mostra por que empresas digitais não deveriam depender exclusivamente de uma plataforma para gerar audiência.

Ao mesmo tempo, é importante não transformar a argumentação do Google em uma conclusão definitiva. A alegação de que as mudanças prejudicarão pequenas empresas é a posição da própria companhia. A Comissão Europeia parte de uma premissa diferente: sem intervenção, a posição dominante do Google poderia continuar dificultando a competição.

Regulamentação antitruste protege o consumidor ou prejudica a usabilidade?

O caso resume um dilema cada vez mais importante na economia digital.

A União Europeia quer limitar a concentração de poder das Big Techs, mas qualquer intervenção sobre plataformas usadas diariamente por centenas de milhões de pessoas pode produzir efeitos inesperados.

O DMA tenta resolver esse problema estabelecendo regras antecipadas para empresas consideradas gatekeepers. Em vez de esperar anos por processos antitruste, a legislação impõe obrigações específicas sobre como essas plataformas devem operar.

No caso do Google, a Comissão Europeia concluiu que havia tratamento preferencial dos próprios serviços na Busca e determinou o fim dessa prática.

O debate fica mais complexo porque o Google não é apenas um mecanismo de pesquisa. Ele funciona como uma das principais portas de entrada para sites, lojas, hotéis, restaurantes, notícias e serviços online.

Alterar seu algoritmo ou seus módulos de apresentação pode redistribuir milhões de visitas.

Há ainda um detalhe importante: a decisão europeia não afeta apenas a Pesquisa. Em julho, a Comissão também aplicou uma multa de €430 milhões ao Google por restrições relacionadas ao direcionamento de usuários do Google Play para ofertas alternativas. Somadas, as duas penalidades chegaram a €890 milhões.

Isso demonstra que o conflito entre reguladores europeus e Google é estrutural.

Não se trata apenas de uma mudança visual na Busca, mas de uma tentativa de alterar como uma das maiores plataformas digitais do mundo distribui poder e tráfego na internet.

Google muda a busca na Europa em um momento decisivo para a web

A importância dessa disputa aumenta com a chegada dos agentes de inteligência artificial.

A próxima geração de buscadores não deverá apenas entregar links. Sistemas de IA poderão comparar preços, escolher produtos, reservar hotéis, analisar avaliações e executar tarefas em nome do usuário.

Nesse cenário, controlar a distribuição dos resultados pode significar controlar uma parcela ainda maior da economia digital.

Por isso, a discussão sobre Google e DMA pode servir como precedente para outras empresas. Se a União Europeia conseguir obrigar uma plataforma dominante a oferecer condições mais equilibradas para concorrentes, outras jurisdições poderão adotar medidas semelhantes.

Para usuários do Linux e do ecossistema Open Source, o tema também merece atenção. A concentração de poder não acontece apenas nos buscadores. Ela aparece em sistemas operacionais, lojas de aplicativos, navegadores, publicidade, plataformas de vídeo, computação em nuvem e agora na própria inteligência artificial.

A pergunta central, portanto, não é simplesmente se a nova Busca europeia será melhor ou pior.

É saber quanto de conveniência o consumidor deve abrir mão para reduzir a concentração de poder das Big Techs.

O Google afirma que a nova estrutura prejudica a experiência. A União Europeia entende que regras mais rígidas são necessárias para tornar o mercado mais competitivo. O resultado prático dessa disputa será observado diretamente por milhões de usuários e empresas.

E a experiência europeia pode determinar como o restante do mundo lidará com plataformas digitais que se tornaram essenciais para acessar a internet.

A pesquisa, publicada em 8 de setembro de 2026, mostrou que um atacante poderia inserir instruções ocultas em uma conversa compartilhada ou em um GPT personalizado. Quando a vítima interagia normalmente com aquela conversa, o ChatGPT poderia processar uma segunda tarefa em paralelo, usando as permissões já concedidas pelo usuário aos aplicativos conectados.

O caso chama atenção porque combina injeção de prompt, acesso a aplicativos externos e uma falha de isolamento entre ambientes de execução. Neste artigo, vamos explicar como a vulnerabilidade funcionava, por que o Gmail era especialmente relevante, como o JFrog Artifactory acabou funcionando como um canal oculto entre contas e quais configurações podem reduzir esse tipo de risco.

Como funcionava a falha no ChatGPT

O ataque começava com uma técnica conhecida como prompt injection, na qual instruções especialmente preparadas eram inseridas no contexto que o modelo deveria processar.

Segundo a Check Point, o conteúdo malicioso poderia ser introduzido por diferentes caminhos, incluindo conversas compartilhadas, GPTs personalizados ou instruções inseridas no contexto da vítima. A ideia não era necessariamente fazer o usuário executar um comando visível, mas convencer o modelo a realizar uma tarefa adicional que permanecesse fora do fluxo principal apresentado na interface.

O resultado era uma espécie de dupla execução. Enquanto o ChatGPT produzia uma resposta aparentemente normal para a pergunta feita pelo usuário, uma tarefa adicional poderia ser processada usando os recursos disponíveis naquela sessão.

No cenário demonstrado pela pesquisa, a tarefa escondida podia acessar dados do Gmail conectado à conta da vítima e encaminhá-los para uma conta controlada pelo atacante.

Isso muda significativamente a natureza do problema. Em vez de um invasor precisar obter diretamente as credenciais do Gmail, o ataque procurava fazer o próprio ChatGPT agir usando uma autorização legítima que já existia.

O papel das permissões padrão e do Gmail

Um componente importante da exploração estava relacionado às permissões dos aplicativos conectados.

A documentação atual da OpenAI informa que o ChatGPT pode trabalhar com aplicativos conectados e que as permissões determinam quando uma confirmação é necessária. Dependendo da configuração, o sistema pode permitir automaticamente determinadas operações de leitura, enquanto solicita autorização para ações consideradas mais sensíveis.

A configuração Ações importantes, por exemplo, permite leituras automáticas e exige confirmação para ações consideradas importantes. A opção Sempre perguntar é mais restritiva e faz o ChatGPT solicitar autorização antes de ler informações ou executar ações em um aplicativo conectado.

Essa diferença é fundamental para entender o ataque.

Se uma tarefa maliciosa conseguia convencer o modelo a consultar uma caixa de entrada, uma permissão que permitisse leitura automática reduzia uma das barreiras que poderiam alertar o usuário.

A Check Point demonstrou justamente esse problema no contexto do Gmail. O atacante não precisava convencer a vítima a clicar em um botão de autorização para cada mensagem. A sessão já possuía capacidade legítima de consultar os dados disponíveis ao aplicativo conectado.

Isso não significa que qualquer conta do Gmail pudesse ser acessada indiscriminadamente pelo ChatGPT. O acesso dependia de o usuário ter conectado e autorizado o serviço. A própria OpenAI esclarece que aplicativos conectados somente podem acessar os dados permitidos durante a conexão e pelas políticas aplicáveis à conta ou ao workspace.

Injeção de prompt e execução dupla no modo Thinking

O aspecto mais sofisticado da vulnerabilidade no ChatGPT estava na possibilidade de separar o que o usuário enxergava do que o modelo fazia internamente.

A pesquisa descreve uma situação em que uma única mensagem legítima poderia desencadear dois fluxos: um encarregado de responder ao usuário e outro responsável por executar a instrução implantada pelo atacante.

Na prática, o usuário poderia fazer uma pergunta completamente inocente e receber uma resposta coerente, enquanto o contexto malicioso orientava uma segunda atividade.

Essa característica torna ataques contra sistemas baseados em agentes particularmente difíceis de identificar. Em aplicações tradicionais, uma operação suspeita costuma produzir uma solicitação de rede, um processo ou uma ação que pode ser monitorada de maneira relativamente direta.

Em sistemas de IA agentiva, entretanto, a própria linguagem funciona como mecanismo de controle. Uma instrução aparentemente inofensiva pode alterar o comportamento do agente e levá-lo a utilizar ferramentas às quais possui acesso legítimo.

O risco aumenta quando o modelo consegue consultar e-mail, armazenamento em nuvem, calendários, documentos ou outros serviços corporativos.

A falha no ChatGPT e o isolamento dos contêineres

O segundo componente da exploração estava no ambiente usado pelo ChatGPT para executar código.

Segundo a Check Point, os contêineres criados para diferentes conversas eram projetados para permanecer isolados. Eles não deveriam conseguir acessar diretamente a Internet pública nem estabelecer comunicação direta entre ambientes associados a contas diferentes.

Porém, havia uma exceção arquitetural importante.

Para permitir que os ambientes instalassem pacotes Python, npm e outras dependências necessárias para determinadas tarefas, os contêineres podiam acessar um serviço interno baseado no JFrog Artifactory.

A intenção era legítima: oferecer um intermediário controlado para disponibilizar pacotes sem conceder aos contêineres acesso direto aos repositórios públicos.

O problema surgiu porque esse serviço compartilhado possuía mecanismos de armazenamento de propriedades associados aos arquivos.

O JFrog Artifactory virou um canal oculto

A investigação descobriu que as APIs de gerenciamento do Artifactory permitiam gravar e consultar propriedades associadas a itens armazenados.

Mais importante: as credenciais disponibilizadas aos contêineres tinham permissões suficientes para realizar essas operações. Essas credenciais também estavam disponíveis em variáveis de ambiente dentro do ambiente de execução.

A Check Point realizou então um teste simples.

Em um contêiner associado a uma conta, os pesquisadores adicionaram uma propriedade chamada chatgpt_test_ts a um arquivo armazenado em cache. Depois, a partir de outra conversa pertencente a uma conta diferente, solicitaram as propriedades daquele mesmo arquivo.

O segundo ambiente conseguiu recuperar exatamente o valor gravado pelo primeiro.

Esse comportamento transformou o serviço em uma espécie de “área de transferência compartilhada” entre contêineres que deveriam estar isolados.

O mecanismo também não estava limitado a pequenos textos.

As propriedades poderiam transportar texto ou dados codificados em Base64. Informações maiores poderiam ser divididas em vários fragmentos, armazenadas em propriedades diferentes e reconstruídas posteriormente pelo ambiente receptor.

Isso criou o elemento que faltava para completar a cadeia de ataque.

Um ChatGPT sob controle de um atacante poderia colocar instruções ou receber resultados através do serviço interno, enquanto uma sessão da vítima executaria a tarefa utilizando seus próprios recursos autorizados.

Assim, o Artifactory não precisava funcionar como um servidor tradicional de comando e controle. Bastava atuar como meio de troca de informações entre ambientes aparentemente separados.

Como os dados do Gmail poderiam sair da conta

Com o canal disponível, o ataque poderia seguir uma sequência conceitual:

1. O atacante prepara uma instrução maliciosa.
2. A instrução é inserida em uma conversa, GPT personalizado ou outro contexto que chegue à vítima.
3. A vítima envia uma mensagem normal ao ChatGPT.
4. O modelo processa a solicitação legítima e a instrução escondida.
5. A sessão da vítima utiliza as permissões disponíveis para consultar o Gmail conectado.
6. Os dados obtidos são preparados para transmissão.
7. O conteúdo é gravado no mecanismo compartilhado do Artifactory.
8. A sessão controlada pelo atacante recupera as informações.

O ponto crítico é que o atacante poderia utilizar capacidades legítimas da sessão da vítima em vez de depender exclusivamente de uma invasão convencional.

A pesquisa da Check Point apresentou uma prova de conceito na qual informações do Gmail da vítima eram recuperadas e retransmitidas para outra conta do ChatGPT.

O mesmo princípio é preocupante para outros tipos de informação acessíveis por uma sessão de IA. Documentos, mensagens, arquivos e informações presentes no contexto de uma conversa podem se tornar alvos quando o agente possui autorização para consultá-los.

Por isso, a segurança do ChatGPT não pode ser analisada somente pela perspectiva da conta do usuário. É necessário considerar toda a cadeia: modelo, prompts, ferramentas, credenciais, aplicativos conectados, ambientes de execução e serviços internos.

O que a OpenAI fez e como proteger sua conta

A descoberta foi comunicada à OpenAI pela Check Point. De acordo com os pesquisadores, a empresa confirmou que o Artifactory interno que possibilitava o canal foi desativado. Ao final da investigação, o canal entre as contas já não estava disponível.

O episódio também não surgiu isoladamente. A Check Point já havia documentado anteriormente outro mecanismo de comunicação usado para retirar dados de ambientes de execução do ChatGPT. Segundo a pesquisa, o novo caso utilizava uma técnica diferente, mas apresentava o mesmo problema estrutural: um serviço interno compartilhado podia transformar-se em uma camada de comunicação inesperada entre ambientes isolados.

A recomendação mais importante para usuários que mantêm aplicativos conectados ao ChatGPT é revisar cuidadosamente as permissões.

Na configuração atual, a OpenAI oferece a opção Sempre perguntar, que exige autorização antes de o ChatGPT ler informações ou realizar ações em um aplicativo conectado.

Para revisar essa configuração, o usuário pode acessar Configurações > Aplicativos e procurar as preferências de permissão dos aplicativos conectados. A OpenAI também permite configurar permissões específicas para determinados aplicativos, quando essa opção estiver disponível.

Para quem não precisa consultar Gmail, Drive ou outros serviços diretamente pelo ChatGPT, existe uma medida ainda mais simples: desconectar o aplicativo. A mudança de permissão não remove o acesso concedido durante a conexão; para revogar efetivamente o acesso, é necessário desconectar o aplicativo ou utilizar os controles administrativos correspondentes.

Administradores de ambientes corporativos devem ir além. É importante revisar quais aplicativos estão habilitados, quais escopos OAuth foram autorizados e quais ações cada aplicativo pode executar. A OpenAI disponibiliza controles específicos para workspaces gerenciados, permitindo restringir as ações disponíveis para aplicativos conectados.

A principal lição dessa falha no ChatGPT é que o isolamento de um ambiente de execução não depende apenas de bloquear conexões diretas. Serviços internos compartilhados, metadados, caches, credenciais e APIs de gerenciamento também fazem parte da superfície de ataque.

À medida que agentes de IA passam a operar com acesso a e-mails, documentos e sistemas corporativos, uma simples instrução deixa de ser apenas texto. Ela pode se transformar em uma ordem executada por uma máquina com permissões reais.

O caso investigado pela Check Point mostra exatamente por que a segurança de sistemas de IA precisa combinar isolamento forte, princípio do menor privilégio, controle de ferramentas, aprovação explícita e segmentação rigorosa de dados entre usuários.

Para usuários comuns, a recomendação é simples: revise os aplicativos conectados ao ChatGPT e considere mudar a permissão para “Sempre perguntar”, principalmente quando a conta possui informações sensíveis no Gmail ou em outros serviços integrados. Para empresas, a revisão deve incluir também as políticas de OAuth e os controles de aplicativos no ambiente corporativo.

O caso chama atenção pela combinação de técnicas aparentemente simples, como scripts Bash e ferramentas nativas do Linux, com operações sofisticadas envolvendo gerenciamento de segredos, custódia de criptomoedas, Azure DevOps, Kubernetes e automação baseada em inteligência artificial. A campanha mostra como criminosos estão deslocando o foco para os sistemas que ficam atrás das aplicações financeiras e concentram as credenciais capazes de movimentar dinheiro.

Mais do que um ataque contra uma organização específica, a atividade do grupo hacker Slim Spider revela uma mudança importante no cenário brasileiro. O objetivo passa a ser comprometer diretamente componentes da infraestrutura que sustentam operações financeiras, aproveitando identidades legítimas, pipelines de desenvolvimento e ambientes de nuvem para chegar aos ativos de maior valor.

Como o grupo Slim Spider operou na nuvem financeira

A operação observada pela CrowdStrike começou com a exploração do ambiente de nuvem de uma instituição financeira brasileira. Segundo as informações divulgadas, o grupo utilizou scripts personalizados em Bash para consultar o serviço de metadados da instância e obter credenciais temporárias.

Um detalhe particularmente relevante foi a utilização de conexões diretas por sockets, em vez de depender exclusivamente de ferramentas convencionais do sistema. Essa escolha reduz a dependência de utilitários facilmente identificáveis e demonstra preocupação com a redução da superfície de detecção durante a intrusão.

Depois de conquistar acesso ao ambiente, os criminosos passaram a enumerar os segredos armazenados no gerenciador de credenciais da nuvem. Esse estágio é crítico porque uma única identidade comprometida pode abrir caminho para chaves de API, certificados, credenciais de serviços e informações relacionadas à custódia de ativos digitais.

O uso de sed também merece atenção. O utilitário tradicional de manipulação de texto do Linux foi empregado para copiar e modificar rotinas utilizadas na extração de segredos. Em outras palavras, o invasor não precisava necessariamente introduzir uma ferramenta desconhecida no sistema: podia adaptar scripts existentes utilizando componentes já presentes no ambiente.

Essa estratégia é representativa de uma tendência importante em ataques modernos: usar ferramentas legítimas para realizar atividades ilegítimas. Para equipes de segurança, detectar simplesmente a presença de Bash, sed, OpenSSL ou outros utilitários nativos é pouco eficaz. O contexto de execução e o comportamento precisam ser analisados.

O alvo mais valioso eram as credenciais de criptomoedas

Após encontrar informações relacionadas aos ativos digitais da instituição, o Slim Spider utilizou o cast, componente do ecossistema Foundry Ethereum, para derivar o endereço de uma carteira Ethereum a partir de uma chave privada obtida durante a intrusão.

Esse detalhe mostra que o grupo não estava interessado apenas em dados corporativos. A intenção era chegar às credenciais que efetivamente controlam ativos financeiros digitais.

A diferença é fundamental. Uma conta corporativa comprometida pode causar vazamento de informações ou interrupção operacional. Já uma chave privada associada a uma carteira de criptomoedas pode representar acesso direto a recursos financeiros, dependendo do modelo de custódia utilizado pela instituição.

Outro elemento sofisticado foi a utilização do OpenSSL diretamente a partir de scripts Bash para realizar operações criptográficas. Em vez de depender de bibliotecas externas ou componentes adicionais que poderiam produzir sinais de detecção, o grupo aproveitou uma ferramenta criptográfica nativa e amplamente disponível em sistemas Linux.

Isso representa um problema importante para soluções EDR e XDR. A presença de um binário legítimo não significa que a operação seja legítima. O que precisa ser investigado é a combinação entre processo, identidade, contexto, destino da comunicação, horário e sequência de comandos.

Slim Spider transforma DevOps em vetor de ataque

A intrusão não terminou na infraestrutura de nuvem. Depois de alcançar componentes relacionados ao ambiente de contêineres, os criminosos avançaram para Azure DevOps e Kubernetes, transformando a própria cadeia de desenvolvimento e implantação em mecanismo de persistência.

De acordo com as informações divulgadas, credenciais comprometidas foram utilizadas para executar pipelines maliciosos no Azure DevOps, permitindo implantar implantes adicionais em um cluster Kubernetes gerenciado.

Essa técnica é especialmente perigosa porque um pipeline de CI/CD possui, por definição, permissões para construir, testar e publicar software. Se essas permissões forem excessivas, o comprometimento do pipeline pode se transformar em uma espécie de chave mestra para a infraestrutura de produção.

Para ambientes modernos de DevOps, isso reforça a necessidade de separar claramente:

código-fonte, credenciais de CI/CD, identidades de implantação, clusters Kubernetes e recursos financeiros críticos.

Uma conta utilizada para automatizar uma implantação não deveria possuir, por padrão, privilégios capazes de acessar segredos de custódia ou modificar componentes diretamente ligados a sistemas de pagamentos.

Implantes que imitavam componentes legítimos

O grupo também teria utilizado binários com nomes relacionados à infraestrutura para tentar se misturar ao funcionamento normal dos ambientes comprometidos. Um dos implantes recebeu o nome “spi”, referência ao Sistema de Pagamentos Instantâneos, infraestrutura central relacionada ao processamento do Pix.

A escolha do nome demonstra uma preocupação operacional adicional: camuflar componentes maliciosos dentro de ambientes complexos, nos quais dezenas ou centenas de serviços legítimos podem estar sendo executados simultaneamente.

Para o administrador Linux, esse comportamento reforça a importância de manter inventários de processos, imagens e workloads. Não basta saber que um processo chamado spi existe. É necessário saber qual imagem o originou, qual pipeline a publicou, quem a implantou, quais permissões possui e para onde estabelece conexões.

IA e painéis C2 ampliam a escala da operação

Outro aspecto que diferencia a campanha é a presença de painéis automatizados de comando e controle (C2).

Entre as ferramentas identificadas está o NEXUS // Scanner, descrito como um painel capaz de analisar endpoints e classificá-los em categorias relacionadas a bancos, fintechs, pagamentos e criptomoedas. O sistema utiliza Ollama para auxiliar na categorização e priorização dos alvos.

A utilização de um modelo de IA nesse contexto não significa necessariamente que a inteligência artificial esteja conduzindo autonomamente toda a invasão. O ponto mais importante é outro: ela pode funcionar como um mecanismo de triagem e automação, reduzindo o trabalho humano necessário para identificar quais sistemas merecem atenção.

Isso permite que uma operação criminosa processe grandes quantidades de endpoints e concentre seus operadores humanos nos alvos considerados mais promissores.

A mesma infraestrutura incluía painéis voltados à reconhecimento de contas Entra ID e operações relacionadas ao Pix. A CrowdStrike também identificou um painel C2 exposto que apresentava hosts comprometidos pertencentes a diferentes bancos e fintechs brasileiras.

Esse modelo representa a industrialização do cibercrime. O atacante deixa de executar manualmente cada etapa e passa a operar uma plataforma que enumera, classifica, prioriza e automatiza ações contra múltiplos alvos.

Slim Spider e a nova geração de ataques ao Pix

O caso ganha ainda mais importância quando observado ao lado de outra ameaça recentemente documentada: Breeze Comet, também associada pela CrowdStrike ao nome Plump Spider.

Enquanto o Slim Spider concentrou parte significativa de sua operação em nuvem, credenciais e custódia de ativos digitais, o Breeze Comet foi descrito pelo Google Threat Intelligence Group e pela Mandiant como um grupo que busca acesso a sistemas capazes de realizar transações em Pix, STR e Boleto.

A convergência entre essas campanhas aponta para uma transformação do crime financeiro digital brasileiro.

Durante anos, boa parte das fraudes latino-americanas esteve concentrada em clientes finais, malware bancário, roubo de credenciais e engenharia social. Agora, criminosos financeiramente motivados demonstram interesse crescente pelos sistemas corporativos que efetivamente processam transações.

Isso muda radicalmente o modelo de defesa.

Se o criminoso consegue comprometer uma identidade com privilégios suficientes dentro de uma instituição financeira, ele não precisa necessariamente convencer milhares de usuários a clicar em um link. Pode tentar controlar diretamente os mecanismos que autorizam ou processam as transações.

O que a invasão do Slim Spider ensina aos profissionais de TI e nuvem

A principal lição deixada pelo Slim Spider é que segurança de nuvem não pode ser tratada apenas como proteção de máquinas virtuais.

A superfície de ataque inclui identidades, metadados de instâncias, cofres de segredos, APIs, pipelines, repositórios, registros de contêineres, Kubernetes e sistemas de autenticação. Quando esses elementos estão conectados, o comprometimento de um componente pode criar uma cadeia de movimentação até ativos financeiros.

Para administradores e equipes de DevOps, algumas medidas são particularmente importantes.

Revisar o RBAC do Kubernetes deve estar entre as prioridades. Contas de serviço precisam receber somente as permissões necessárias, evitando que um comprometimento de workload resulte em privilégios administrativos no cluster.

Também é fundamental revisar o gerenciamento de segredos. Credenciais temporárias devem ter escopo reduzido, duração limitada e mecanismos de rotação. Segredos de custódia de criptomoedas devem permanecer isolados de credenciais utilizadas por aplicações comuns.

Outro ponto é a segurança dos pipelines de CI/CD. Azure DevOps, GitHub Actions, GitLab CI e plataformas semelhantes precisam ser considerados parte da superfície de produção. Uma alteração maliciosa em um pipeline pode ser tão perigosa quanto uma vulnerabilidade no próprio servidor.

Finalmente, equipes de segurança precisam monitorar o uso anômalo de Bash, sed, OpenSSL e outras ferramentas nativas. O objetivo não é bloquear esses componentes, mas identificar combinações incomuns de comportamento, como acesso inesperado a metadados, enumeração de segredos, alteração de scripts e comunicação com infraestrutura externa.

A atividade do grupo hacker Slim Spider mostra que o próximo estágio dos ataques financeiros brasileiros não está necessariamente no computador do cliente. Ele pode estar escondido dentro da nuvem, do pipeline de DevOps ou do cluster Kubernetes que sustenta a operação financeira.

Para instituições que trabalham com Pix e ativos digitais, essa realidade exige uma mudança de mentalidade: proteger a aplicação já não é suficiente. É necessário proteger toda a cadeia de identidade, desenvolvimento, implantação e execução que permite que uma transação financeira aconteça.

Na prática, a decisão afasta um risco jurídico que vinha preocupando desenvolvedores e mantenedores de distribuições Linux há meses. A DAAA, prevista para entrar em vigor em 1º de janeiro de 2027, obrigará os provedores de sistemas operacionais a coletarem a data de nascimento do usuário durante a configuração inicial da conta. Essa informação será convertida em um sinal de faixa etária, repassado aos desenvolvedores e lojas de aplicativos no momento do uso.

Se a lei fosse aplicada cegamente a todo o ecossistema, projetos mantidos por voluntários e comunidades, como o Ubuntu, Fedora e Linux Mint, teriam que criar e embutir coletores de dados etários em seus instaladores, o que seria um ônus técnico massivo e uma exigência incompatível com a cultura de privacidade do software livre.

O que isso significa para quem usa Linux

Para o usuário final e para administradores de sistemas, o processo de instalação e configuração de um computador não sofrerá alterações. A isenção foi estruturada diretamente na base da lei: o texto atualizado redefine o conceito de “provedor de sistema operacional”.

A nova redação exclui categoricamente qualquer pessoa ou entidade que distribua software sob termos de licença que permitam copiar, redistribuir e modificar o código-fonte.O modelo resguarda aplicações fornecidas sob licenças consagradas, como GPL, MIT, BSD e Apache.

A medida abrange também gerenciadores de pacotes, repositórios (como GitHub e GitLab) e ferramentas de contêineres, como Docker e Podman. Ferramentas e dependências baixadas via linha de comando não enfrentarão sanções de faixa etária.

Android fica de fora, SteamOS é área cinzenta

Embora o Kernel Linux esteja protegido de forma geral, a isenção tem limites claros e foca no modelo de distribuição, não apenas no núcleo do sistema. Plataformas comerciais baseadas em ecossistemas fechados continuam sob as exigências legais.

• Android, Windows, macOS e iOS:O Android não escapará da lei de verificação de idade da Califórnia, dada a natureza de seu ecossistema, sua vinculação aos serviços da Google e o modelo de configuração guiado pelas fabricantes.
• SteamOS: O sistema da Valve, focado em jogos e popularizado pelo Steam Deck, encontra-se em uma lacuna jurídica. Apesar de rodar sobre o Arch Linux (aberto), o sistema é entregue junto a um cliente proprietário da Steam. Como a lei e a Valve ainda não se pronunciaram sobre a mescla de código fechado em distribuições, esse modelo híbrido segue sem um status definido.
• GrapheneOS:Projetos móveis alternativos estritamente construídos e distribuídos com base no código aberto estão amparados pela exclusão legal e não precisarão coletar os dados dos usuários.

Um precedente nacional

O modelo da Califórnia acompanha o trabalho legislativo recente no Colorado, onde o CEO da System76, Carl Richell, fez forte articulação política para proteger o ecossistema open source de regras desenhadas originalmente para frear a coleta de dados de menores por gigantes das redes sociais e lojas de aplicativos.

Como a Califórnia é o epicentro do mercado de tecnologia nos Estados Unidos, a adoção dessa isenção específica consolida um padrão legislativo. A expectativa de especialistas é que o texto sirva como um modelo confiável para outros estados e até esferas federais que venham a aprovar políticas de verificação etária, garantindo a sustentabilidade da distribuição de sistemas operacionais livres no futuro.

Diferente de soluções gráficas que atuam apenas como interfaces para comandos do terminal, o Shelly interage diretamente com o libalpm, biblioteca central do pacman. Esta nova atualização refina a estabilidade da ferramenta, corrigindo comportamentos no processamento de receitas de instalação (PKGBUILD) e expandindo a autonomia do software com a introdução do Shellystrap.

O que isso muda na prática

Para os usuários de Arch Linux e distribuições derivadas (como o CachyOS, que já adota o projeto), o Shelly-ALPM tem o objetivo de unificar a instalação de pacotes de repositórios oficiais, do AUR, além de Flatpaks e AppImages. Com a versão 3.1.3, gerenciar essas múltiplas fontes fica mais organizado.

Aqueles que instalam frequentemente programas pelo Arch User Repository (AUR) agora contam com opções para apagar rapidamente arquivos desnecessários de compilação. Simultaneamente, usuários que dependem de AppImages ganham controle total sobre variáveis de sistema para aplicações individuais, algo que evita incompatibilidades na área de trabalho.

Limpeza inteligente de cache do AUR

Ao compilar pacotes do AUR, os arquivos compactados gerados podem se acumular e consumir espaço considerável. O Shelly 3.1.3 resolve isso adicionando o parâmetro --aur-cache ao comando de limpeza.

Ao executar shelly purify standard --aur-cache, o gerenciador remove os arquivos instaladores gerados pelo AUR e suas respectivas assinaturas. O sistema de limpeza é projetado para preservar os arquivos cruciais, como os diretórios de construção originais, códigos-fonte e históricos, afetando apenas o que é considerado supérfluo. O comando pode ser testado com a bandeira --dry-run para visualizar previamente o que será apagado.

Para administradores que preferem não lidar com caixas de diálogo durante as atualizações gerais do sistema, a equipe de desenvolvimento introduziu o comando shelly config set DisableCacheClean true. A alteração instrui o utilitário (durante um shelly upgrade all, por exemplo) a pular a fase de exclusão de cache, devolvendo o controle da manutenção ao usuário.

Shellystrap: a evolução dos builds isolados

A principal alteração arquitetural desta atualização ocorre nos bastidores. Os processos isolados de compilação do Shelly passam a utilizar o Shellystrap, um recurso auxiliar desenvolvido sobre o libalpm.

A ferramenta substitui a dependência anterior do utilitário pacstrap. Segundo a documentação oficial, a troca garante que as instâncias do sistema de arquivos permaneçam contidas dentro dos namespaces privados do próprio Shelly. Outra vantagem é permitir que chaves criptográficas transitem de forma segura do chaveiro do usuário principal diretamente para o ambiente enclausurado.

Com a atualização, os mantenedores do projeto alertam que desenvolvedores fazendo uso das compilações isoladas devem se certificar de ter a ferramenta unshare (do pacote util-linux) instalada, juntamente com o systemd-nspawn.

Suporte refinado para arquivos PKGBUILD

A versão 3.1.3 também resolve problemas incômodos na interpretação dos arquivos PKGBUILD. Entre as correções documentadas no código, destacam-se:

• Aplicação uniforme da variável SOURCE_DATE_EPOCH durante todo o processo (útil para quem busca builds reproduzíveis).
• Um novo sistema independente de descompressão antes da fase prepare(), que suporta nativamente pacotes em gzip, bzip2, xz e zstd, respeitando parâmetros que exigem a não extração do código.
• Resolução de falhas críticas que interrompiam a compilação por conta de campos de atribuição declarados vazios (como install='').
• Caso um binário não possa ser enxugado pela ferramenta nativa da arquitetura hospedeira durante a fase de limpeza (strip), o sistema agora emite um alerta formal em vez de abortar abruptamente a geração do pacote.

Variáveis nativas para AppImages e integração com Flathub

Em relação aos pacotes em formato universal, cada AppImage gerido pelo aplicativo agora suporta variáveis de ambiente exclusivas e persistentes. Isso significa que é possível adicionar um parâmetro de hardware a um software (forçando aceleração gráfica, por exemplo) sem alterar o sistema inteiro.

A alteração pode ser configurada na interface ou via linha de comando usando a estrutura:

shelly config appimage "NomeDoApp" --set-env "CHAVE=valor"

No que diz respeito ao suporte Flatpak, o trabalho mais recente corrige a manipulação de URIs, garantindo que links oriundos do portal Flathub iniciem a busca e instalação do respectivo software adequadamente, mesmo se a interface do programa estiver ociosa e aguardando na bandeja do sistema.

Downloads dinâmicos e avisos transparentes

Por fim, falhas relativas à simultaneidade de tráfego foram sanadas. O carregamento de repositórios e programas agora obedece rigorosamente ao parâmetro ParallelDownloadCount do Arch Linux. O sistema aceita a delimitação entre 1 e 255 conexões (com um recuo de segurança para o padrão de 100 conexões caso detecte um valor defeituoso configurado pelo usuário).

As mensagens de erro também se tornaram mais claras. Telas relatando quebras e conflitos de dependências informarão de maneira descritiva qual aplicativo exato necessitará ser desinstalado e quem o substituirá caso a instalação seja autorizada pelo usuário.

Embora uma das vulnerabilidades atinja todas as plataformas suportadas, o grande volume de correções desta versão concentra-se na arquitetura de serviços do OpenVPN para Windows. Além da segurança, a nova versão introduz validação aprimorada para conexões via Netlink no Kernel Linux e otimizações de desempenho na gestão de pacotes e chaves criptográficas.

O que isso significa para quem administra redes

Se você gerencia instâncias de OpenVPN, esta é uma atualização altamente recomendada. Para servidores baseados em Linux e BSD, a atualização protege a camada de confiabilidade do protocolo contra instabilidades no TLS. Já no caso de clientes rodando Windows, o patch é ainda mais urgente: ele fecha brechas de transbordamento de buffer, abusos de privilégio local e caminhos de configuração que poderiam permitir que um usuário mal-intencionado interferisse no serviço de VPN.

Correção global na camada de confiabilidade

A correção de maior impacto geral aborda a infraestrutura central de transmissão, afetando instalações em Linux, macOS e Windows.Identificada como CVE-2026-84732, a falha reside na camada de confiabilidade responsável por gerenciar handshakes do protocolo TLS e pacotes de confirmação (ACKs).

Dois problemas coexistiam nesta estrutura: um limite de tempo (timeout) não restrito para o TLS e a falta de filtros adequados para ACKs correspondentes a pacotes que já não deveriam estar pendentes. Descobertos pelo pesquisador Mark Bregman, esses bugs poderiam ser explorados para manipular o fluxo da conexão, criando condições propícias para uma negação de serviço via handshake malformado.

Foco na arquitetura do Windows

As outras seis vulnerabilidades corrigidas afetam especificamente os clientes de Windows. As modificações refletem um esforço para proteger componentes críticos, como o utilitário tapctl e o serviço openvpnserv, que acumularam comportamentos problemáticos de borda e validação insuficiente de entradas:

• CVE-2026-84256: Corrigiu o tratamento de aspas e argumentos no CreateProcess(). Anteriormente, caracteres especiais processados pelo cmd.exe, aliados a um script de validação e a uma autoridade certificadora desonesta, poderiam resultar em comportamento inesperado na execução.
• CVE-2026-84226:O utilitário tapctl passou a invocar o netsh.exe informando seu caminho completo, preenchendo uma lacuna técnica que poderia ser abusada para sequestro de binários ou de rotas (binary hijacking).
• CVE-2026-82312: O OpenVPN não usa mais permissões DACL nulas em objetos do sistema (como o semáforo do netsh.exe). A abordagem antiga permitia que um usuário local bloqueasse intencionalmente o evento de saída ou as instâncias de OpenVPN de outros usuários, causando um DoS local.
• CVE-2026-78221:Evita um problema de buffer overread no openvpnserv ao processar domínios (NRPT) com codificação UTF-8, ajustando adequadamente o tamanho de leitura esperado.
• CVE-2026-78043: A validação de diretórios de configuração do Windows não barrava o uso da barra comum (/). Esse drible nas APIs de abertura de arquivos permitia carregar configurações de VPN não autorizadas pelos administradores do sistema.
• CVE-2026-81738: Soluciona um erro de limite (“off-by-one”) em opções malformadas de DHCP. Domínios de pesquisa cuidadosamente criados podiam transbordar um buffer temporário em um byte.

Otimizações de rede e Netlink no Linux

Fora do escopo direto das vulnerabilidades, a versão 2.7.7 incorpora melhorias estruturais para desempenho e estabilidade do tráfego.

Para os usuários de Linux, a principal adição é que o cliente agora valida as respostas do Netlink em relação à requisição que as gerou. Sugerida pelo pesquisador Joshua Rogers, a camada extra atua como uma salvaguarda de comunicação com o Kernel Linux.

No tratamento de pacotes, os desenvolvedores reduziram a retenção de chaves futuras no formato de canal de dados EPOCH.O limite despencou de 16 para 4 chaves. A adequação elimina excesso de registros (logs) e reduz o consumo de recursos computacionais nas implementações de kernel, pois apenas 4 chaves sobressalentes já são estatisticamente suficientes para manter links estabilizados até em altas taxas de 100 Gbit/s.

Por fim, respeitando o padrão da RFC 768, o cliente deixou de ajustar checksums UDP quando seus valores são nulos.Em paralelo, a integração com o OpenSSL evita a redefinição desnecessária da chave HMAC a cada novo pacote processado, poupando ciclos de CPU.

A proposta é reduzir a quantidade de espaço ocupada por dados que podem ser descartados ou reorganizados, deixando o processo mais automatizado para o usuário. Segundo a Huawei, a tecnologia pode recuperar até 109 GB de armazenamento em determinados aparelhos equipados com 1 TB.

O recurso está sendo introduzido durante a fase de testes do HarmonyOS 7, que também avança para uma distribuição beta mais ampla. A combinação entre um novo sistema operacional e ferramentas capazes de administrar automaticamente os recursos do aparelho mostra uma tendência importante no mercado mobile: cada vez mais tarefas de manutenção podem deixar de depender de ações manuais.

Como funciona o Hyperspace Storage no HarmonyOS 7

O Hyperspace Storage foi desenvolvido para otimizar a utilização do armazenamento interno de maneira integrada ao sistema operacional. Em vez de depender exclusivamente de uma ferramenta externa para identificar arquivos que podem ser removidos, a tecnologia trabalha dentro do próprio ambiente do HarmonyOS 7.

O princípio é relativamente simples. Ao longo do uso normal de um smartphone, aplicativos e componentes do sistema produzem uma grande quantidade de dados temporários, caches e outros arquivos que podem deixar de ser necessários.

Individualmente, esses arquivos podem ocupar pouco espaço. Entretanto, depois de meses de utilização, o acúmulo pode representar dezenas de gigabytes.

A proposta da Huawei é automatizar parte desse processo de gerenciamento. Dessa maneira, o usuário não precisa necessariamente abrir periodicamente uma ferramenta de limpeza para procurar arquivos que possam ser eliminados.

Essa abordagem também pode ajudar a manter uma quantidade maior de espaço disponível durante períodos prolongados, reduzindo a necessidade de intervenções constantes.

Huawei promete recuperar até 109 GB em aparelhos de 1 TB

O número mais chamativo associado ao Hyperspace Storage é a promessa de recuperar até 109 GB de espaço em smartphones com 1 TB de armazenamento.

Para colocar esse número em perspectiva, 109 GB representam uma parcela considerável da capacidade total de um aparelho de 1 TB. É espaço suficiente para armazenar uma grande quantidade adicional de fotografias, vídeos, jogos ou aplicativos.

O benefício pode ser ainda mais relevante para usuários que utilizam o smartphone como principal dispositivo para consumo e produção de conteúdo.

Câmeras modernas produzem arquivos cada vez maiores, especialmente quando são utilizadas resoluções elevadas, formatos avançados de imagem ou gravação de vídeo em alta definição. Jogos mobile também podem ocupar dezenas de gigabytes depois da instalação dos arquivos adicionais.

Por isso, recuperar espaço que antes estava sendo consumido por dados temporários ou desnecessários pode prolongar o período entre uma limpeza e outra.

É importante, entretanto, interpretar corretamente a afirmação da Huawei. 109 GB é o máximo divulgado para determinados cenários, e não significa que todos os smartphones com 1 TB recuperarão automaticamente essa quantidade.

O resultado real dependerá do modelo do aparelho, do histórico de utilização e principalmente da quantidade de dados que poderá ser identificada como recuperável.

Limpeza manual de cache perde espaço para a automação

Durante anos, a solução para armazenamento cheio foi relativamente simples: abrir as configurações, verificar quais aplicativos ocupavam mais espaço e apagar caches ou arquivos desnecessários.

Também surgiram inúmeros aplicativos de terceiros prometendo realizar esse processo automaticamente.

O problema é que ferramentas externas nem sempre possuem o mesmo nível de integração que uma função incorporada ao sistema operacional. Um aplicativo convencional precisa trabalhar dentro das permissões disponibilizadas pela plataforma, enquanto uma tecnologia nativa pode participar diretamente dos mecanismos de gerenciamento do sistema.

É justamente nesse ponto que o Hyperspace Storage se torna interessante.

Em vez de transformar a limpeza em uma tarefa recorrente do usuário, a Huawei pretende fazer com que o próprio HarmonyOS 7 administre parte desse processo.

Isso também reduz a necessidade de instalar aplicativos de limpeza que permanecem ativos ou enviam notificações solicitando que o usuário execute determinadas tarefas.

A automação, porém, precisa ser cuidadosa. Liberar espaço não pode significar simplesmente apagar tudo que parece desnecessário. Dados importantes precisam ser preservados, e uma limpeza agressiva poderia provocar perda de informações ou exigir que aplicativos reconstruam dados posteriormente.

Por isso, o sucesso da tecnologia dependerá não apenas da quantidade de gigabytes recuperados, mas também da precisão com que o sistema determina o que pode ser descartado.

HarmonyOS 7 amplia os testes e prepara nova fase de distribuição

O lançamento do Hyperspace Storage acontece paralelamente à evolução do programa beta do HarmonyOS 7.

A Huawei está avançando da beta fechada para a beta pública, ampliando os testes para mais de 50 dispositivos. A expansão é importante porque permite que mais usuários e desenvolvedores experimentem os novos recursos antes da versão final.

Uma base maior de testes também ajuda a identificar problemas que dificilmente aparecem em ambientes controlados.

No caso de uma tecnologia de gerenciamento automático de armazenamento, essa etapa é particularmente importante. O sistema precisa funcionar corretamente em diferentes configurações de hardware e diante de padrões de utilização muito distintos.

Um usuário pode ter milhares de fotografias e vídeos, enquanto outro pode ocupar a maior parte do armazenamento com jogos. Um terceiro pode instalar centenas de aplicativos e produzir poucos arquivos pessoais.

O Hyperspace Storage terá de lidar com esses cenários sem prejudicar o funcionamento dos aplicativos ou eliminar informações que ainda sejam necessárias.

A expectativa é que o HarmonyOS 7 ganhe destaque comercial junto à próxima geração de smartphones da Huawei, com a linha Mate 90 sendo apontada como uma das principais plataformas associadas ao novo sistema.

O gerenciamento automático de armazenamento pode virar padrão

A proposta da Huawei representa uma mudança que vai além de simplesmente adicionar mais uma ferramenta ao sistema.

À medida que smartphones recebem câmeras mais avançadas, jogos maiores, recursos de inteligência artificial e aplicativos mais complexos, o armazenamento se tornou um recurso cada vez mais disputado.

A solução tradicional sempre foi aumentar a capacidade interna. Hoje já existem smartphones com 512 GB, 1 TB e até capacidades superiores em determinadas categorias. Porém, aumentar o armazenamento também aumenta a quantidade de dados que o usuário pode acumular.

Por isso, gerenciar melhor o espaço disponível pode ser tão importante quanto oferecer mais capacidade.

Soluções automatizadas integradas ao sistema operacional podem se tornar uma tendência importante no mercado. Em vez de esperar que o usuário perceba que o armazenamento está acabando, o sistema pode trabalhar continuamente para reduzir desperdícios.

Esse modelo também combina com uma tendência maior da indústria: transferir tarefas de manutenção para mecanismos inteligentes capazes de tomar decisões automaticamente.

O Hyperspace Storage no HarmonyOS 7 ainda precisa passar por mais testes para que seja possível avaliar seu desempenho em situações reais. O número de 109 GB chama atenção, mas a experiência prática será determinada pela quantidade de espaço que cada dispositivo realmente consegue recuperar.

Ainda assim, a iniciativa mostra que a Huawei está tratando o armazenamento como uma questão de otimização contínua, e não apenas como uma característica definida pelo número de gigabytes disponíveis.

Se a tecnologia funcionar como prometido, usuários poderão ganhar mais espaço útil sem precisar recorrer constantemente a aplicativos de limpeza ou realizar operações manuais.

Embora a atualização modernize o fluxo de trabalho e traga suporte oficial a ASIO no Windows, a transição de arquitetura resultou na remoção temporária de recursos voltados a usuários avançados, como suporte a faixas MIDI, Macros e plugins LADSPA.

O que isso significa na prática

Para a maioria dos podcasters, músicos e criadores de conteúdo, o Audacity 4.0 parecerá um software mais moderno e flexível. Janelas e painéis agora podem ser movidos livremente, o comportamento de sobreposição de áudio foi corrigido (clipes sobrepostos agora substituem o áudio inferior em vez de bloquear o movimento) e não é mais necessário trocar manualmente entre ferramentas de seleção e envelope.

No entanto, para usuários que dependem de scripts, automação por Macros ou edição MIDI, a versão 4.0.0 ainda não atende a essas necessidades. A atualização de projetos antigos também exige atenção, já que o novo formato não permite salvar arquivos de volta para as versões anteriores.

Interface modular e ferramentas contextuais

A transição para o Qt permitiu a implementação de renderização nativa em alta resolução (high-DPI) e uma interface baseada em painéis acopláveis. Os usuários agora podem mover, fixar ou ocultar barras de ferramentas livremente, além de salvar configurações visuais através do recurso de “Workspaces” (Áreas de trabalho), que já inclui layouts pré-definidos para uso Moderno, Clássico e Musical.

No fluxo de trabalho, a mudança mais notável é a remoção das antigas ferramentas separadas (Seleção, Envelope, Desenho e Multi-ferramenta). O Audacity 4.0 adota uma abordagem sensível ao contexto:

• O ajuste de volume (envelope) é feito diretamente no modo de ganho do clipe.
• O desenho de forma de onda (Draw) é ativado automaticamente ao aplicar zoom em nível de amostra.
• O corte de clipes ganhou uma ferramenta dedicada, ativada ao pressionar ou segurar a tecla S.

O recurso “Sync-Lock” também foi removido, substituído por variantes explícitas de exclusão, corte e cola que permitem ao usuário escolher entre deixar um espaço vazio na trilha ou mover o material posterior para preservar o tempo.

Edição de clipes e suporte a ASIO

O modelo de edição de clipes foi refeito. Agora, os blocos de áudio podem ser selecionados diretamente pelo cabeçalho, agrupados para edição em massa (movimentação, corte e time stretching) e movidos livremente entre faixas mono e estéreo.

Na parte de gravação e reprodução, as novidades incluem:

• ASIO nativo no Windows: As compilações oficiais para Windows agora incluem suporte a reprodução e gravação via ASIO diretamente, sem necessidade de compilação manual.
• Agulha de reprodução dinâmica: O cursor de reprodução (playhead) permanece visível e pode ser arrastado durante a navegação.
• Busca sem interrupção: É possível saltar para diferentes partes da linha do tempo sem parar a reprodução.
• Mapeamento de canais: A interface de configuração de áudio agora suporta dispositivos padrão do sistema e permite mapeamento personalizado de canais.

Formato .aup4 e migração sem volta

A nova arquitetura introduz o formato de projeto .aup4, necessário para armazenar as novas propriedades visuais, dados de clipes e miniaturas de visualização que agora aparecem na tela inicial do software.

Projetos antigos (.aup3 e .aup) podem ser importados para o Audacity 4.0. O processo converte o arquivo para .aup4 mantendo o original intacto. Contudo, projetos salvos em .aup4 não podem ser abertos em versões anteriores do Audacity, o que exige cautela em ambientes de colaboração onde a equipe utiliza versões diferentes do programa.

Ausências temporárias: o que ficou de fora

Devido à magnitude da reescrita em Qt, a equipe de desenvolvimento confirmou que vários recursos presentes no Audacity 3 não estão disponíveis no lançamento do 4.0. A previsão é que sejam reintegrados em atualizações futuras:

• Faixas de Tempo (Time Tracks);
• Faixas de Nota/MIDI;
• Mixer;
• Gerenciador de Macros e scripts;
• Suporte a plugins VAMP e LADSPA;
• Opção de “reproduzir na velocidade” (Play-at-speed).

Algumas ferramentas de exportação, geradores de análise e efeitos específicos também estão ausentes nesta versão inicial. Aproveite e instalar o Audacity neste tutorial em qualquer distro Linux.

A decisão representa mais uma mudança no tratamento da realidade aumentada (RA) dentro do Android. Para quem utiliza o celular Galaxy para medir objetos, distâncias ou criar desenhos virtuais sobre imagens da câmera, a notícia exige atenção. Os aplicativos podem continuar funcionando em aparelhos onde já estão instalados, mas a própria Samsung alerta que alguns recursos podem deixar de funcionar corretamente e que futuras atualizações do sistema não terão suporte de compatibilidade.

Entenda o fim do Samsung Quick Measure e do AR Doodle

O Quick Measure foi criado para transformar a câmera do smartphone em uma ferramenta de medição baseada em realidade aumentada. O aplicativo permite estimar distâncias e dimensões de objetos físicos, oferecendo uma alternativa rápida para situações em que o usuário não tem uma fita métrica por perto.

Já o AR Doodle segue uma proposta mais criativa. O recurso permite desenhar virtualmente sobre pessoas, objetos e ambientes vistos pela câmera, mantendo os traços posicionados no espaço durante a gravação de vídeos. Em aparelhos compatíveis com S Pen, a experiência também podia aproveitar a caneta para criar os desenhos. A própria Samsung documenta esse funcionamento em seus materiais de suporte.

Os dois recursos fizeram parte da estratégia de realidade aumentada da Samsung durante uma fase em que fabricantes de smartphones apostavam fortemente em experiências de RA diretamente integradas ao sistema e à câmera.

A situação mudou gradualmente. Com a chegada da One UI 7, a Samsung deixou de concentrar esses recursos no antigo AR Zone e passou a distribuí-los como aplicativos independentes. A própria documentação da empresa informa que, em aparelhos com Android 15 e One UI 7.0, o AR Doodle precisa ser baixado separadamente pela Galaxy Store.

Agora, essa separação chega ao fim.

Qual é a data de encerramento do Quick Measure?

A Samsung estabeleceu 31 de dezembro de 2026 como a data de encerramento dos serviços do Quick Measure e do AR Doodle. Depois desse prazo, os aplicativos deixarão de receber novos downloads e atualizações.

Isso não significa necessariamente que o aplicativo desaparecerá imediatamente de todos os celulares. Usuários que já possuem o software instalado poderão continuar utilizando-o, mas sem garantia de funcionamento completo.

A Samsung também afirma que não fornecerá suporte de compatibilidade para futuras atualizações do sistema operacional. Na prática, isso é especialmente importante para quem pretende atualizar o Galaxy para novas gerações da One UI.

O que acontece com o Samsung Quick Measure já instalado?

Quem utiliza o Samsung Quick Measure atualmente não precisa necessariamente desinstalar o aplicativo ou procurar imediatamente por uma alternativa.

Até 31 de dezembro de 2026, a Samsung mantém o encerramento programado. Depois disso, entretanto, a empresa deixa claro que novos downloads e suporte de atualização serão interrompidos. O aplicativo existente poderá continuar funcionando, mas determinadas funções podem apresentar problemas.

O principal ponto de atenção está nas futuras versões do Android e da One UI.

Um aplicativo que depende de APIs de câmera, sensores, rastreamento espacial e componentes do sistema pode deixar de funcionar corretamente quando uma nova versão altera APIs ou requisitos de compatibilidade. Por isso, mesmo que o Quick Measure continue instalado, não há garantia de que ele permanecerá operacional indefinidamente.

Na prática, quem considera o recurso importante deve baixar o aplicativo enquanto ele ainda estiver oficialmente disponível e começar a avaliar uma alternativa antes do fim do suporte.

Há ainda um detalhe relevante: versões recentes da One UI já apresentam restrições. Relatos e verificações publicadas após o anúncio indicam que os aplicativos podem não aparecer em determinados aparelhos com versões mais recentes do sistema, como alguns modelos Galaxy lançados em 2026.

Por que a Samsung está abandonando esses recursos?

A Samsung não apresentou uma explicação técnica detalhada para o encerramento. O comunicado disponível na Galaxy Store informa apenas que os serviços serão encerrados e que a empresa pretende retornar futuramente com serviços aprimorados.

A mudança, entretanto, acontece dentro de um movimento maior.

O antigo AR Zone concentrava diversas experiências de realidade aumentada, incluindo AR Doodle, Quick Measure, Deco Pic, AR Emoji e outras ferramentas. A partir da One UI 7, a Samsung passou a reorganizar essa estrutura, separando ferramentas e reposicionando recursos dentro do sistema Galaxy.

Esse movimento mostra que a realidade aumentada deixou de ser tratada necessariamente como um grande pacote independente. O foco da indústria também mudou para inteligência artificial, câmera computacional e recursos contextuais, áreas que passaram a ocupar mais espaço na experiência dos smartphones.

Isso não significa que a RA esteja desaparecendo. Pelo contrário: tecnologias como o Google ARCore continuam oferecendo infraestrutura para aplicativos Android que utilizam rastreamento de movimento, detecção de superfícies e compreensão do ambiente.

Alternativas ao Samsung Quick Measure no Android

A descontinuação do Quick Measure da Samsung não significa o fim da medição por realidade aumentada no Android. Existem alternativas de terceiros, embora a experiência e a precisão possam variar conforme o aparelho, câmera, sensores e condições do ambiente.

AR Measure

O AR Measure é uma alternativa recente disponível na Google Play. O aplicativo utiliza ARCore para transformar a câmera em uma espécie de fita métrica virtual.

O funcionamento é simples: o usuário movimenta o smartphone para que o ambiente seja mapeado, seleciona dois pontos na tela e recebe a distância estimada. Também é possível encadear vários pontos para medir comprimento, largura e altura de objetos.

Para quem procura algo mais próximo da proposta original do Samsung Quick Measure, essa é uma das opções que vale testar.

CamToPlan

Outra alternativa é o CamToPlan, voltado principalmente para medições de ambientes.

O aplicativo utiliza realidade aumentada para criar plantas baixas, medir distâncias, áreas e superfícies e exportar resultados. Isso pode ser interessante para reformas, decoração, imóveis e pequenas medições domésticas.

Por ser mais completo, também pode ser mais complexo do que o Quick Measure para quem deseja apenas medir rapidamente uma parede ou objeto.

Google Lens e o ecossistema ARCore

O Google Lens não é um substituto direto do Quick Measure. Seu foco principal está em reconhecer objetos, textos, plantas, animais, produtos e outros elementos capturados pela câmera.

Ainda assim, ele representa uma alternativa importante para quem utilizava recursos de câmera e realidade aumentada de maneira mais ampla.

Para aplicativos que realmente dependem de medição espacial, o ponto mais importante é verificar se o smartphone é compatível com Google ARCore. A plataforma possui uma lista oficial de aparelhos certificados e utiliza câmera, sensores de movimento e recursos de compreensão espacial para viabilizar experiências de RA.

O futuro das ferramentas de RA nos celulares Galaxy

O fim do Samsung Quick Measure e do AR Doodle marca o encerramento de uma fase da estratégia de realidade aumentada da Samsung, mas não necessariamente o abandono definitivo da tecnologia.

A própria empresa afirma que pretende retornar com serviços aprimorados no futuro, embora ainda não tenha revelado quais produtos ou recursos substituirão diretamente os aplicativos atuais.

Para os usuários, a principal consequência é prática: não é recomendável depender exclusivamente desses aplicativos a longo prazo.

Quem usa o Quick Measure ocasionalmente pode migrar para uma solução baseada em ARCore. Já quem utiliza a ferramenta profissionalmente ou para medições importantes deve lembrar que aplicativos de realidade aumentada fornecem estimativas, e não devem substituir instrumentos profissionais quando precisão é essencial.

A mudança também reforça uma tendência no ecossistema Galaxy: aplicativos antigos estão sendo gradualmente reorganizados ou substituídos conforme a Samsung reformula a experiência da One UI.

Se você ainda usa o Samsung Quick Measure ou o AR Doodle, vale aproveitar os últimos meses de suporte para testar alternativas e descobrir qual delas funciona melhor no seu Galaxy.

A novidade chama atenção principalmente entre desenvolvedores e entusiastas de automação. A proposta permite configurar até cinco agentes de IA, cada um potencialmente voltado para uma finalidade diferente, dentro de uma experiência integrada ao mensageiro. Ao mesmo tempo, existem limitações importantes e uma mudança relevante no tratamento de privacidade que precisa ser compreendida antes de qualquer configuração.

O recurso também representa uma mudança de postura interessante diante da popularização de agentes autônomos e da concorrência com plataformas como o Telegram, tradicionalmente mais abertas a bots e automações. Para quem já utiliza IA local ou serviços hospedados na nuvem, o WhatsApp pode se tornar uma interface muito mais acessível para interagir com seus próprios sistemas.

Como funciona a conexão de agentes de IA no WhatsApp

De acordo com informações sobre o recurso em testes, o WhatsApp está preparando uma opção para que o usuário forneça uma chave de API associada a um agente de inteligência artificial de terceiros.

A ideia é relativamente simples: em vez de o WhatsApp precisar oferecer diretamente cada modelo ou serviço de IA disponível no mercado, o usuário poderá conectar agentes externos compatíveis por meio de suas próprias credenciais.

O sistema prevê a possibilidade de adicionar até cinco agentes de IA. Isso abre espaço para diferentes configurações. Um agente poderia ser utilizado para responder perguntas gerais, enquanto outro ficaria responsável por programação, produtividade, atendimento pessoal ou acesso a uma infraestrutura de IA executada localmente.

Para a comunidade Linux e Open Source, o conceito é particularmente interessante. Um usuário poderia, por exemplo, manter um modelo de linguagem em seu próprio servidor e utilizar uma camada de API para permitir a interação com esse agente diretamente pelo WhatsApp.

Isso não significa, porém, que o WhatsApp esteja hospedando esses modelos. A plataforma funciona como uma interface para a conexão, enquanto o processamento e as regras de cada agente continuam dependendo do serviço ou infraestrutura de terceiros.

O processo de integração e limites de uso

A autenticação acontece por meio da chave API, que funciona como uma credencial para autorizar a comunicação entre o WhatsApp e o serviço externo.

O modelo oferece uma alternativa potencialmente mais organizada para quem atualmente depende de ferramentas não oficiais. Em vez de utilizar métodos que simulam o comportamento de um usuário ou exploram interfaces não destinadas à automação, a integração passa a utilizar um mecanismo previsto pela própria plataforma.

Entretanto, há uma limitação importante: o recurso está direcionado a conversas individuais. Pelo que foi observado nos testes, os agentes não podem ser utilizados livremente dentro de grupos do WhatsApp.

Essa restrição reduz algumas possibilidades de automação colaborativa, mas também ajuda a manter o recurso sob um escopo mais controlado. Aplicações como bots de suporte em grupos, assistentes para comunidades ou agentes responsáveis por moderar conversas coletivas continuam dependendo de outras soluções e APIs específicas.

Outro ponto importante é que o suporte a cinco agentes não significa necessariamente que cinco modelos diferentes precisem ser utilizados. A possibilidade pode ser aproveitada de acordo com a arquitetura escolhida pelo usuário, incluindo diferentes serviços, agentes especializados ou configurações distintas.

Fim dos banimentos por uso de automações não oficiais

Um dos aspectos mais relevantes da novidade está relacionado ao histórico de bloqueios de contas associados a automações não oficiais.

Durante anos, usuários interessados em bots e inteligência artificial precisaram recorrer a ferramentas de terceiros para conectar sistemas automatizados ao WhatsApp. Dependendo da implementação e do comportamento do bot, essas soluções poderiam entrar em conflito com as regras da plataforma e resultar em limitações ou bloqueios.

Uma integração nativa muda esse cenário.

Se o recurso chegar ao público de maneira ampla e dentro das condições previstas pelo WhatsApp, desenvolvedores poderão contar com uma camada oficial de comunicação, reduzindo a dependência de métodos alternativos e potencialmente instáveis.

Isso não significa que qualquer automação estará automaticamente autorizada. As regras de uso, limites de API e políticas do WhatsApp continuam sendo determinantes. A diferença é que a plataforma passa a oferecer uma maneira própria de conectar determinados agentes externos.

Para o usuário final, o benefício mais evidente é a perspectiva de maior estabilidade e previsibilidade.

Privacidade e segurança das conversas com IA terceirizada

A maior facilidade de integração também traz uma questão que merece atenção: privacidade.

Conversas realizadas com agentes de IA de terceiros não devem ser tratadas da mesma maneira que uma conversa tradicional entre usuários do WhatsApp. A informação enviada ao agente precisa chegar ao serviço responsável pelo processamento, o que cria uma relação diferente daquela existente em uma conversa convencional protegida pelo modelo de segurança do mensageiro.

Um aspecto positivo informado sobre a implementação é o isolamento do agente. O serviço conectado não teria acesso livre aos demais chats, mídias e informações armazenadas na conta do usuário.

Esse isolamento é importante porque impede que um agente conectado simplesmente passe a consultar toda a atividade existente no WhatsApp. O escopo da integração fica limitado à interação destinada ao próprio agente.

Por outro lado, existe uma diferença fundamental relacionada à criptografia ponta a ponta. As conversas específicas com agentes terceirizados não contam necessariamente com o mesmo modelo de criptografia ponta a ponta aplicado às conversas privadas tradicionais entre usuários.

Esse detalhe deve ser considerado antes de enviar informações sensíveis.

Senhas, documentos confidenciais, dados financeiros, informações corporativas e outros conteúdos privados não devem ser compartilhados com um agente simplesmente porque ele está disponível dentro do WhatsApp. A conveniência da interface não elimina as responsabilidades relacionadas ao serviço que processa os dados.

Para desenvolvedores, também será essencial verificar onde os dados são processados, por quanto tempo ficam armazenados, quais modelos são utilizados e se as informações podem ser utilizadas para treinamento. Esses detalhes podem variar conforme o provedor do agente.

Agentes de IA no WhatsApp podem mudar as automações

A integração representa algo maior do que simplesmente adicionar um chatbot ao aplicativo. O avanço dos agentes autônomos de IA está transformando modelos de linguagem em sistemas capazes de executar tarefas, utilizar ferramentas externas e trabalhar com diferentes fontes de informação.

Colocar essa tecnologia dentro de um aplicativo de mensagens usado diariamente reduz uma barreira importante: a necessidade de acessar interfaces específicas para cada serviço.

Imagine, por exemplo, receber pelo WhatsApp uma resposta de um agente conectado a um servidor doméstico, consultar informações de um sistema pessoal ou interagir com uma IA especializada sem abrir outro aplicativo.

Para a comunidade técnica, isso pode estimular arquiteturas híbridas combinando WhatsApp, APIs, modelos locais, servidores Linux e serviços de nuvem.

Também existe uma dimensão competitiva. Plataformas de mensagens que oferecem ambientes mais amigáveis para bots e automações já conquistaram espaço entre desenvolvedores. Ao permitir agentes externos de maneira nativa, o WhatsApp sinaliza que pretende acompanhar essa tendência sem necessariamente abrir mão do controle sobre sua infraestrutura.

Conclusão e o impacto para o ecossistema de inteligência artificial

O suporte nativo a agentes de IA no WhatsApp pode representar uma das mudanças mais interessantes na relação entre mensageria e inteligência artificial. A possibilidade de conectar até cinco agentes por chave API, ainda que com limitações como o uso em conversas individuais, cria novas oportunidades para automação, produtividade e experimentação.

Para desenvolvedores e entusiastas de IA local, o recurso também pode funcionar como uma ponte entre modelos hospedados em servidores próprios e uma das plataformas de comunicação mais populares do mundo.

Entretanto, a questão da privacidade não pode ser deixada em segundo plano. O isolamento do agente é um ponto positivo, mas a ausência da criptografia ponta a ponta tradicional nessas interações exige atenção especial sobre quais informações serão compartilhadas com serviços externos.

Por enquanto, o ponto central é que o recurso ainda está associado a testes e desenvolvimento, portanto sua disponibilidade, funcionamento definitivo e condições de uso podem mudar antes de uma liberação ampla.

Se a novidade chegar ao público da maneira prevista, ela poderá tornar o WhatsApp uma interface muito mais interessante para agentes personalizados e automações baseadas em IA.