Índice do artigofaltam 6 min de leitura
A senha estava forte e o segundo fator, ligado. Ainda assim a conta foi usada por outra pessoa, porque o que vazou não foi a senha.
Em 30 de agosto de 2026 a Anthropic começou a desligar assinantes das próprias contas do Claude. O motivo não foi vazamento de banco de dados nem senha fraca: um programa de roubo de informação instalado na máquina do usuário copiou o cookie de sessão do navegador, e quem reapresentou esse cookie foi tratado pelo serviço como alguém que já tinha feito login.
Para a empresa que paga assinatura de ferramenta de IA para o time, o caso vale menos pelo susto e mais pela pergunta que ele obriga a fazer: em que conta cada uma dessas assinaturas está, quem consegue revogar uma sessão e o que existe salvo dentro dela.
Resumo do artigo
- A empresa avisou por e-mail aos afetados em 30 de agosto de 2026, e não há página publicada por ela sobre o caso nas fontes consultadas.
- Foram nomeadas seis famílias de malware, cinco no Windows e uma no macOS, com a ressalva de que são as identificadas "até agora".
- A resposta teve três ações: desligar as sessões, remover o meio de pagamento salvo e devolver as cobranças não autorizadas.
- Nenhum número de impacto foi divulgado: nem contas afetadas, nem consumo drenado, nem valor devolvido.
O que a Anthropic avisou, e por que o aviso chegou por e-mail
O aviso partiu da própria empresa e descreve um ator malicioso usando programas comuns de roubo de informação. O texto que circulou diz, na tradução direta, que a empresa tomou conhecimento de um ator que usa esse tipo de malware "para roubar sessões de login do Claude dos computadores das pessoas, e então usar essas sessões para acessar contas Claude e consumir o uso delas".
Duas coisas nesse aviso importam para quem decide. A primeira é o caminho: ele chegou por e-mail aos usuários afetados, e o texto ficou conhecido porque foi reproduzido por veículos de segurança. Até a apuração deste artigo, as reportagens consultadas não apontam página publicada pela empresa sobre o caso. A segunda é o verbo: a empresa descreve consumo de uso, não extração de dados, e não afirma nada sobre o que mais foi acessado.
Para quem administra as contas, essa diferença é operacional. O consumo drenado a empresa identificou e devolveu. O que aconteceu com o conteúdo de cada conta ninguém informou, e é justamente o que o seu inventário interno precisa responder.
Por que senha forte e segundo fator não impedem esse roubo
O segundo fator protege o login, e este ataque não passa pelo login. Depois que você entra, o serviço entrega ao navegador um cookie de sessão para não pedir autenticação a cada clique. É esse cookie que o malware copia, e quem o reapresenta é tratado como alguém já autenticado.
- Você entra na conta, com senha e segundo fator, exatamente como manda a boa prática.
- O serviço emite um cookie de sessão para o seu navegador, que passa a valer como prova de que aquele login aconteceu.
- O malware copia esse cookie da máquina infectada, junto com senhas salvas e outros dados do navegador.
- O atacante reapresenta o cookie e entra sem senha e sem segundo fator, porque para o serviço o login já ocorreu.
A consequência prática é que a higiene de senha, que continua necessária, não é suficiente. Sessão autenticada é uma credencial, e é a única que a política de senha da sua empresa não alcança.
As famílias de malware nomeadas, e o que "até agora" significa
Seis famílias foram nomeadas, cinco no Windows e uma no macOS. A empresa qualificou a lista como as identificadas até aquele momento, e essa qualificação é parte do fato: o número descreve o que foi visto, não o universo do que existe.
- VidarWindows. Família de roubo de informação de uso amplo.
- Lumma (LummaC2)Windows. Aparece nas campanhas mais recentes de roubo de credencial.
- StealCWindows. Coleta dados salvos no navegador.
- RedLineWindows. Uma das mais distribuídas dessa categoria.
- AcreedWindows. Também citada na campanha descrita pela empresa.
- Atomic Stealer (AMOS)macOS. Descrita como presente num número pequeno de Macs.
Nenhuma delas é novidade para quem trabalha com segurança. O que muda é o alvo: até pouco tempo, o prêmio de um roubo desse tipo era o banco e o e-mail. Agora a assinatura de IA entrou na lista, porque ela tem consumo faturável e meio de pagamento do outro lado.
O que a empresa fez, e os números que ela não deu
A resposta descrita tem três ações, e nenhuma delas veio acompanhada de número. É uma diferença que vale registrar, porque a ausência de dado limita o que qualquer análise pode afirmar.
O que foi informado
Três ações de contenção- Desligar as sessões dos afetados, para invalidar o que foi copiado.
- Remover o meio de pagamento salvo nas contas atingidas.
- Devolver as cobranças não autorizadas identificadas.
O que não foi informado
Nenhum número de impacto- Quantas contas foram afetadas.
- Quanto consumo foi drenado.
- Quanto foi devolvido.
Vale separar duas leituras que costumam ser confundidas. A empresa ter respondido rápido é resposta, não veredito sobre o tamanho do problema. E o silêncio sobre os números não é confissão de nada: é apenas silêncio, e o que se pode dizer sobre ele é que ele existe.
O que a sua empresa perde quando a sessão vaza
O consumo faturável é a perda visível, e provavelmente a menor. A tabela abaixo separa o que este caso permite afirmar do que continua sem dado, para a empresa que paga assinatura de IA para o time.
| Componente | O que este caso permite dizer |
|---|---|
| Consumo faturável | Foi drenado e a empresa devolveu cobranças. Valor não divulgado. |
| Meio de pagamento salvo | Estava na conta. A empresa removeu das contas atingidas. |
| Histórico de conversa | SEM DADO. A sessão dá acesso à conta, e nada foi informado sobre leitura de histórico. |
| Integrações ligadas à conta | SEM DADO. Depende do que cada assinante conectou. |
| Tempo do time para revogar e reconfigurar | SEM DADO. Depende do tamanho da sua operação. |
| Política interna e contrato | SEM DADO. Nada foi dito sobre exigência contratual de aviso. |
Componentes preenchidos com o aviso da empresa reproduzido em 30 de agosto de 2026 e com a apuração de 8 de setembro de 2026. "SEM DADO" indica ausência de informação pública, não ausência de risco.
O item que merece atenção é o terceiro. Numa empresa, o histórico de conversa de uma ferramenta de IA costuma guardar trecho de contrato, dado de cliente e discussão de projeto, e ninguém trata esse histórico como repositório sensível porque ele não parece um repositório.
Para quem este caso não muda nada
Se a sua empresa não paga assinatura de navegador para o time, este caso específico não é o seu risco. Operação que consome IA só por chave de API dentro de um sistema no servidor não tem cookie de sessão de usuário para ser copiado, e o problema dela é outro: rotação e escopo de chave.
Também muda pouco para quem já opera com dispositivo gerenciado, sessão curta por login único e sem meio de pagamento pessoal salvo em ferramenta de trabalho. Nesse desenho a janela de reprodução do cookie é pequena e o estrago tende a ficar contido, que é o que o desenho existe para reduzir.
Vale a honestidade de dizer onde o caso é fraco como evidência: ele é um aviso de um fornecedor, sem número, sobre malware que já existia. Não é uma tendência medida nem uma mudança de patamar. É um lembrete caro de uma mecânica antiga que ganhou um alvo novo.
O que muda para a empresa brasileira, com a LGPD no meio
Se o histórico de conversa da ferramenta contém dado pessoal, o acesso indevido a ele é incidente de segurança, e a LGPD tem rito para isso. O artigo 48 prevê a comunicação à Autoridade Nacional de Proteção de Dados e ao titular quando o incidente puder acarretar risco ou dano relevante, o que transforma uma questão de conta pessoal em obrigação da empresa.
A dificuldade prática aqui é anterior à lei: a maioria das empresas não sabe dizer o que o time colou dentro da ferramenta. Sem esse inventário, não há como avaliar risco relevante, e a decisão sobre comunicar acaba sendo tomada no escuro.
Redação do artigo 48 da Lei 13.709/2018 conferida no texto publicado em 8 de setembro de 2026. A avaliação de risco relevante é do controlador, caso a caso.
A decisão desta semana
O levantamento que este caso pede cabe numa tarde e não depende de ferramenta nova. A pergunta que ele responde é simples: se uma sess ão vazar amanhã, quanto tempo até você fechar a porta.
- Liste as assinaturas de IA que a empresa paga e em que conta cada uma está, pessoal ou corporativa.
- Confira se o meio de pagamento fica salvo dentro dessas contas.
- Descubra, em cada ferramenta, onde fica a revogação de sessão e quem na sua empresa consegue acioná-la.
- Defina se o acesso passa a exigir login único com sessão curta, em vez de conta criada com e-mail pessoal.
- Escreva o que não pode ser colado dentro da ferramenta, e informe o time.
- Registre quem avisa quem quando uma conta é comprometida, antes de precisar.
Feita a lista, sobra uma pergunta que só o seu dado responde: quantas dessas assinaturas estão no nome de uma pessoa e não da empresa? O número costuma surpreender, e ele é a medida real de quanto da sua operação de IA depende de um navegador que você não administra.
Fontes e método
O aviso da Anthropic foi reproduzido pelo BleepingComputer em 30 de agosto de 2026 e pelo Help Net Security em 31 de agosto de 2026, com repercussão posterior no TechCrunch em 8 de setembro de 2026. A apuração deste artigo é de 8 de setembro de 2026.
A declaração da empresa, a lista de famílias de malware e as três ações de resposta constam nas duas primeiras fontes, que são independentes entre si. A explicação de por que o cookie de sessão contorna o segundo fator vem do Help Net Security. A ausência de números de impacto e a ausência de página publicada pela empresa até a data de consulta são registradas pelas duas. Nenhum número deste artigo é medição da X-Apps, e a Anthropic é empresa externa, citada como objeto de análise.
Quer mapear onde a sua operação de IA está exposta?
Solicite um orçamento e comece pelo inventário de contas, sessões e dados que passam pelas ferramentas.
Perguntas frequentes
Não por si só. A sessão roubada é um login que já aconteceu, e ela continua válida até ser revogada. Trocar a senha só ajuda quando o serviço invalida as sessões abertas junto com a troca, o que nem todo serviço faz.
Contra tentativa de login, sim. Contra reprodução de sessão, não. O segundo fator é verificado no momento do login; o cookie emitido depois dele é o que o atacante copia e reapresenta.
Não é o que as fontes descrevem. O malware roda na máquina do usuário e copia o cookie do navegador. A empresa informou ter desligado as sessões afetadas, removido o meio de pagamento salvo e devolvido cobranças não autorizadas.
Não foi informado. As reportagens que reproduziram o aviso registram que a empresa não divulgou número de contas, volume de consumo drenado nem valor devolvido.
O aviso é sobre contas Claude. A mecânica de cópia e reprodução de cookie, no entanto, não é específica de um serviço: ela vale para qualquer sessão de navegador que o time mantenha aberta.
