Vazamentos & Privacidade
Discord: CVE-2026-24332 e o canal lateral de presença
A falha de presença do Discord em 2026: invisible, snapshots, eventos, remediação relatada e um laboratório de privacidade.
Um estado privado pode vazar mesmo quando a interface mostra a palavra correta. A CVE-2026-24332 descreve um caso de presença no Discord: usuários invisíveis podiam ser distinguíveis de usuários realmente offline pela representação transmitida no serviço. O interesse técnico está no canal lateral criado pela diferença entre ausência de evento e evento explicitamente marcado como offline.
O registro e sua atualização
O registro CVE-2026-24332 delimita o serviço WebSocket hospedado até 16 de janeiro de 2026. Foi publicado em janeiro e atualizado em setembro. A nota atual do registro menciona relato de terceiros sugerindo remediação posteriormente em 2026. Portanto, este artigo não afirma que a técnica continue funcionando hoje.
O registro remete à pesquisa original sobre invisibilidade no Discord. O endereço dessa pesquisa não estava acessível na revisão editorial, por isso os detalhes deste texto são delimitados ao registro CVE consultado. A documentação oficial de eventos do Gateway ajuda a compreender que aplicações recebem eventos estruturados. Documentar a API não equivale a divulgar a implementação interna completa do serviço afetado.
| Elemento | Interpretação |
|---|---|
| Estado mostrado | Invisible ou offline na interface |
| Diferença relatada | Presença de registro versus ausência |
| Efeito | Inferência de atividade, não execução de código |
| Escopo temporal | Serviço descrito até janeiro de 2026 |
| Situação posterior | Nota de possível remediação, sem versão de cliente indicada |
Ausência também comunica informação
Dois estados que devem ser indistinguíveis precisam produzir observações compatíveis. Mostrar offline em ambos não resolve se um aparece no snapshot e o outro não. O observador pode ignorar o texto do status e usar apenas a existência do registro.
Essa é uma questão de não interferência: uma escolha privada não deveria modificar a saída disponível a um observador sem autorização para conhecê-la. O princípio vale para presença, indicadores de digitação, recibos de leitura e respostas de recuperação de conta. Em cada caso, o canal pode ser conteúdo, timing, tamanho ou existência da mensagem.
Não se deve confundir a inferência com acesso a mensagens privadas. O registro descreve exposição de estado de atividade. Qualquer afirmação sobre leitura de chats, roubo de conta ou execução remota exigiria evidência de outra falha.
Snapshots, eventos e caches precisam concordar
Um serviço em tempo real costuma combinar um snapshot inicial com eventos incrementais. Corrigir só um desses caminhos pode deixar o outro revelando a diferença. Reconexão, retomada de sessão, alteração de comunidade e caches são pontos importantes para verificar consistência.
Também é necessário testar transições: online para invisible, offline para invisible e reconexão durante uma mudança. Um evento atrasado pode expor uma escolha depois que a interface já passou a escondê-la. A política deve vigorar antes da emissão para todos os observadores, não apenas no componente visual do usuário.
Uma inferência precisa de análise estatística quando há mensagens ausentes por perda, limitação de taxa ou cache. Ausência em uma captura isolada não identifica um estado com certeza. O relatório deve explicar quais condições controlou e quais fontes de ruído permanecem.
Laboratório: equivalência de observação
O exemplo usa três pessoas inventadas e gera uma visão pública que exclui tanto offline quanto invisible. Não conecta ao Discord, não acompanha usuários e não utiliza tokens. Demonstra a propriedade de equivalência pretendida para uma política de presença fictícia.
import json
def eventos_publicos(usuarios):
return [{'id':u['id'],
'status':u['status']} for u in usuarios if u['status'] not in ('offline',
'invisible')]
usuarios = [{'id':'pessoa-a',
'status':'online'},
{'id':'pessoa-b',
'status':'invisible'},
{'id':'pessoa-c',
'status':'offline'}]
eventos = eventos_publicos(usuarios)
assert eventos == [{'id':'pessoa-a','status':'online'}]
assert not any(e['id'] in ('pessoa-b','pessoa-c') for e in eventos)
print(json.dumps({'modelo_local':True,
'eventos':eventos,
'estados_privados_indistinguiveis':True},
ensure_ascii=False))
A lista pública contém somente pessoa-a. As outras duas identidades não aparecem. Os asserts verificam que a classificação privada não produz um marcador diferencial nesse pequeno modelo. Em uma implementação real, também devem ser avaliados tamanho de mensagens, sequência, timing e outras saídas.
Excluir um evento pode não bastar se outro canal revelar o mesmo estado. Por exemplo, uma mudança no número de membros ativos ou na ordem de elementos pode preservar a correlação. O teste precisa olhar para o conjunto de observações que um participante efetivamente recebe.
Plano de testes com contas autorizadas
| Caminho | Verificação |
|---|---|
| Snapshot inicial | Estados privados sem diferença indevida |
| Atualização incremental | Mesma política aplicada |
| Reconexão | Cache não restaura marcador antigo |
| Mudança de estado | Eventos transitórios não revelam a opção |
| Erro ou limite | Mensagem não inclui dados suprimidos |
Em uma avaliação autorizada, utilize apenas contas de laboratório e ambientes que você administra. Defina quem é o observador e qual informação a política permite. Guarde uma captura reduzida com os campos indispensáveis, pois identificadores de usuários e comunidades são dados que não precisam aparecer em uma publicação didática.
Para testar uma correção, compare observações equivalentes durante janelas bem definidas. Uma única mensagem ausente pode ser efeito de transporte. Repita casos controlados, preserve os resultados negativos e registre versão, período e política aplicada. Não transforme um experimento pequeno em alegação de monitoramento universal.
Mitigação e comunicação com usuários
O controle principal está no serviço que decide o que transmitir. Um cliente que esconde um elemento na tela não impede que outro cliente interprete o payload já recebido. A proteção precisa ocorrer antes de entregar a informação ao observador.
Para equipes que desenvolvem recursos semelhantes, explicite a semântica de cada opção de privacidade. “Não mostrar online” pode ser entendido pelo usuário como “não permitir inferir atividade”. Se o serviço não oferece essa garantia, a documentação precisa ser clara. Essa diferença é parte do design de segurança, não apenas uma escolha de rótulo.
Registros de segurança devem informar produto, período afetado e nível de certeza sobre correção. Como este caso envolve um serviço hospedado, não há no registro uma versão universal de aplicativo que possa ser indicada como patch definitivo. Atualizar o cliente continua sendo boa manutenção, mas não substitui a confirmação do comportamento do serviço.
Perguntas frequentes
A técnica ainda funciona? Não foi testada contra usuários reais nesta tarefa. O registro atualizado inclui informação de possível remediação posterior.
É uma invasão da conta? O impacto descrito é inferência de presença, sem demonstração de controle da conta.
O programa é um monitor de pessoas? Não. Trabalha exclusivamente com uma lista sintética em memória.
O caso mostra que uma opção de privacidade deve ser avaliada pelo que um observador consegue distinguir. A aparência da interface é apenas uma parte desse contrato.
