){kind=link}
Em outubro de 2025, um pesquisador de segurança chamado Jatin Banga identificou uma vulnerabilidade crítica de autorização nos servidores do Instagram que permitia o acesso completo a conteúdo de contas privadas sem qualquer forma de autenticação.
A descoberta, feita acidentalmente durante o desenvolvimento de uma ferramenta de automação de workflows HTTP, revelou uma falha que potencialmente expôs dados privados de centenas de milhões de usuários.
smart_display
Nossos vídeos em destaque
A vulnerabilidade permitia que requisições completamente não autenticadas obtivessem links diretos de CDN para fotos e vídeos de contas configuradas como privadas, incluindo legendas e metadados completos das publicações.
O ataque não exigia login, relacionamento de seguidor ou qualquer tipo de credencial, apenas conhecimento técnico básico de requisições HTTP.
Como a vulnerabilidade funcionava
O exploit identificado por Banga baseava-se em uma falha de autorização server-side. Ao enviar uma requisição GET não autenticada para instagram.com/[username] utilizando headers específicos de navegadores mobile, o servidor do Instagram retornava uma resposta HTML contendo um objeto JSON denominado polaris_timeline_connection.
Dentro desse objeto, o array edges continha URLs diretas de CDN para o conteúdo privado da conta-alvo, incluindo imagens em resolução completa, vídeos e legendas das publicações.
Não se tratava de um problema de cachê ou de configuração de CDN. O backend do Instagram estava ativamente gerando e retornando dados privados para requisições não autorizadas, falhando em validar permissões antes de popular a resposta. O servidor simplesmente não verificava se quem estava pedindo a informação tinha autorização para recebê-la.
Durante análise técnica detalhada, Banga identificou um comportamento específico que chamou de “estado de gatilho”. Quando as requisições com headers mobile eram processadas para determinadas contas privadas vulneráveis, o servidor retornava “0 seguidores / 0 seguindo” independentemente do número real de seguidores da conta.
Nesse estado corrompido, os dados privados da timeline eram incorretamente disponibilizados na resposta. Era como se o sistema entrasse em um modo de operação anômalo onde as verificações de privacidade eram simplesmente ignoradas.
A extensão do problema
Seguindo protocolos éticos de pesquisa em segurança, Banga limitou rigorosamente todos os testes a contas sob seu controle ou com permissão explícita dos proprietários. Em uma amostra de 7 contas autorizadas para teste, 2 apresentaram a vulnerabilidade, uma taxa de aproximadamente 28%.
Considerando que o Instagram possui mais de 1 bilhão de usuários ativos, e que a descoberta inicial ocorreu acidentalmente em uma conta não autorizada, a taxa real de exploração pode ser significativamente superior.
A vulnerabilidade não afetava todas as contas privadas uniformemente. Análises preliminares sugeriram correlação com a idade das contas, com perfis mais antigos demonstrando maior suscetibilidade. No entanto, a causa raiz exata permanece indeterminada, dado que a Meta não conduziu investigação técnica aprofundada conforme documentado nas comunicações oficiais.
O processo de divulgação responsável
Entre 12 e 15 de outubro de 2025, Banga passou por um processo de ida e volta com a Meta ao reportar a vulnerabilidade. O primeiro relatório foi rejeitado em 5 minutos por interpretação equivocada, mas o segundo, com linguagem técnica mais precisa, iniciou uma investigação apropriada.
A Meta pediu testes em sua própria conta (2fa_2fa), onde o exploit falhou, revelando que a vulnerabilidade era condicional. Banga então conseguiu permissão de um terceiro usuário (its_prathambanga), demonstrou o exploit com sucesso extraindo 30 URLs privadas, e enviou análise técnica completa explicando o mecanismo de duas etapas da falha.
O patch silencioso e a contradição
Em 16 de outubro de 2025, durante testes de rotina de verificação, Banga identificou que a vulnerabilidade não era mais reproduzível. Todas as contas previamente vulneráveis passaram a retornar respostas vazias. A Meta havia implementado uma correção silenciosa sem qualquer notificação ao pesquisador.
Exatamente 48 horas após Banga fornecer os nomes específicos das contas vulneráveis, o problema estava corrigido nessas contas exatas.
Banga documentou a mudança em vídeo cronometrado e enviou um follow-up solicitando confirmação oficial da correção. A resposta veio apenas onze dias depois, em 27 de outubro, e foi desconcertante: “Não conseguimos reproduzir esse problema.” O caso foi categorizado como “Não Aplicável”, sem elegibilidade para recompensa de bug bounty.
O pesquisador respondeu no mesmo dia apontando a contradição lógica evidente, já que a Meta havia explicitamente solicitado contas vulneráveis adicionais durante a investigação, recebeu os nomes específicos dessas contas, e essas contas exatas foram corrigidas em 48 horas.
A resposta final da equipe de segurança da Meta, em 29 de outubro, foi ainda mais enigmática: “O fato de um problema irreproduzível ter sido corrigido não muda o fato de que não era reprodutível na época.
Mesmo que o problema fosse reprodutível, é possível que uma mudança tenha sido feita para corrigir um problema diferente e esse problema foi corrigido como um efeito colateral não intencional.” O caso foi mantido como “Não Aplicável”, efetivamente negando que a vulnerabilidade tivesse existido.
O que ficou sem investigação
A análise da comunicação oficial entre Banga e a Meta revela lacunas significativas no processo de investigação que levantam questões sobre a profundidade da análise conduzida pela empresa.
Banga ofereceu proativamente compartilhar logs completos de rede incluindo headers X-FB-Debug, que permitiriam rastreamento interno completo das requisições problemáticas nos sistemas da Meta.
Esses headers contêm identificadores únicos de servidores e processos internos que facilitariam enormemente a identificação da causa raiz. A oferta foi ignorada.
O pesquisador também forneceu uma lista detalhada discriminando quais contas eram exploráveis e quais não eram, um conjunto de dados pronto para análise diferencial que poderia esclarecer as condições específicas que tornavam determinadas contas vulneráveis.
Este tipo de dataset comparativo é extremamente valioso para diagnóstico de bugs condicionais, permitindo que engenheiros identifiquem padrões e características comuns entre as contas afetadas. Nenhuma análise foi solicitada ou conduzida com base nessa informação.
Sem identificação da causa raiz, não há confirmação técnica de que o problema subjacente foi completamente resolvido ou apenas remediado superficialmente. Existe diferença fundamental entre corrigir sintomas e corrigir causas: um patch que apenas esconde o problema pode permitir que ele reapareça em outras condições ou contextos não testados.
Documentação e preservação de evidências
Banga implementou um protocolo rigoroso de documentação com verificação de integridade temporal. Ele preservou o script de prova de conceito em Python que demonstrava a extração automatizada de URLs de CDN privadas, capturou screenshots comparativos da mesma requisição antes e depois da implementação da correção, e gravou quatro vídeos timestampados com hashes SHA256 pré-calculados para verificação de integridade.
Toda a comunicação oficial com o programa de bug bounty da Meta foi arquivada em formato PDF, e logs técnicos completos foram preservados, incluindo headers de rede, amostras de respostas de contas vulneráveis versus não-vulneráveis, e as URLs de CDN que foram expostas.
Todas essas evidências foram coletadas em um repositório Git público durante o processo de investigação e reporte, entre 12 e 17 de outubro de 2025, estabelecendo timestamps criptograficamente verificáveis através do histórico de commits. Esta metodologia impede a fabricação ou modificação retroativa das evidências.
A preservação meticulosa de evidências é particularmente relevante neste caso, dado que a Meta posteriormente negou que o problema fosse reproduzível. Os hashes SHA256 dos vídeos, os commits do Git com timestamps imutáveis, e a documentação detalhada de cada etapa do processo fornecem um registro verificável e independente de que a vulnerabilidade existiu e foi demonstrada de forma reproduzível.
Escalação e divulgação pública
Seguindo práticas padrão de divulgação coordenada de vulnerabilidades, que estabelecem uma janela de 90 dias para que organizações respondam antes de divulgação pública, Banga estendeu o período para 102 dias, dando à Meta tempo adicional além do protocolo padrão.
Em 4 de novembro de 2025, Banga enviou um apelo formal solicitando reabertura do caso e condução de análise de causa raiz apropriada. Ele enfatizou que a questão não era financeira — não se tratava da recompensa de bug bounty — mas de garantir que a correção implementada era completa e que o problema havia sido adequadamente diagnosticado.
Ofereceu novamente compartilhar dados técnicos comparativos detalhados e notificou que, caso o caso fosse encerrado novamente sem investigação adequada da causa raiz, procederia com divulgação pública responsável após o período padrão da indústria.
A Meta não respondeu a este último apelo. Após 102 dias sem resposta ou reconhecimento, em 22 de janeiro de 2026, Banga enviou uma notificação formal de divulgação pública, confirmando que o período de coordenação havia transcorrido, listando os materiais a serem incluídos na divulgação, e oferecendo uma janela adicional de 48 horas para resposta da Meta antes da publicação.
Dois dias depois, em 24 de janeiro de 2026, ele tornou pública toda a documentação da vulnerabilidade, do processo de reporte e das comunicações com a Meta.
Acompanhe o TecMundo nas redes sociais. Inscreva-se em nosso canal do YouTube e newsletter para mais notícias de segurança e tecnologia.