Por que o iFood escondeu vazamento de dados por 6 meses?

Seis meses. Esse foi o tempo entre o momento em que o iFood identificou uma falha em seus sistemas e o dia em que a empresa admitiu publicamente que dados de 1,2 milhão de usuários haviam sido expostos. A confirmação só veio após criminosos anunciarem a venda das informações em fóruns da dark web, forçando a plataforma a sair do silêncio. Para especialistas em cibersegurança e direito digital, a conduta da empresa contraria a Lei Geral de Proteção de Dados (LGPD) e expõe uma falha estrutural na cultura de segurança da companhia.

O incidente ocorreu em dezembro de 2025. Segundo apuração do TecMundo, a origem da brecha foi uma falha do tipo IDOR no Sistema iFood de Resposta às Autoridades (SIRA) — um portal interno usado para atender requisições judiciais, administrativas e de órgãos de segurança pública. A vulnerabilidade permite que um usuário acesse dados de outras pessoas simplesmente alterando parâmetros de uma requisição, sem que o sistema verifique autorização específica.

Como a falha foi explorada e por que demorou a ser descoberta

Segundo o criminoso identificado como "Harold Baker", que entrou em contato com o TecMundo, uma conta policial comprometida teria dado acesso ao sistema SIRA. A extração dos dados ocorreu de forma gradual ao longo de aproximadamente três meses — estratégia deliberada para não disparar alertas nos mecanismos de monitoramento da plataforma.

O caso só veio a público em 28 de maio de 2026, quando um usuário identificado como "bacen" anunciou no BreachForums ter acesso a 43,8 milhões de registros de clientes brasileiros do iFood e estabeleceu prazo até 10 de junho para que a empresa pagasse resgate. O iFood negou inicialmente qualquer invasão. Após novos arquivos serem revelados, a plataforma reconheceu a falha de segurança na quarta-feira, 3 de junho, e confirmou que 1,2 milhão de usuários tiveram nome e CPF expostos.

A empresa negou que os 43,8 milhões de registros alegados pelos criminosos tenham sido comprometidos e afirmou que senhas, dados bancários e meios de pagamento não foram afetados.

O argumento que a LGPD não autoriza

O iFood justificou a ausência de notificação à Autoridade Nacional de Proteção de Dados (ANPD) alegando que o incidente não configurou "risco ou dano relevante" aos titulares — critério previsto no Artigo 48 da LGPD para a comunicação obrigatória. Para os especialistas ouvidos pelo Times Brasil — Licenciado Exclusivo CNBC, o argumento não se sustenta.

"É difícil concordar, porque a própria empresa não pode estabelecer isso. Se cada um arbitrar por conta própria, não haveria necessidade de regulamentações e leis. São dados cadastrais, dados que são importantes. A lei existe e ela preconiza que exista a notificação."

A afirmação é de Arthur Igreja, especialista em tecnologia. A lógica é direta: se o controlador dos dados pudesse definir unilateralmente o que constitui "risco relevante", a LGPD perderia sua função regulatória.

Fernando De Falchi, gerente de Engenharia de Segurança da Check Point Software Brasil, explica que a avaliação de risco inicial cabe ao controlador, mas essa análise não é definitiva. "A ANPD pode apurar incidentes não comunicados por meio do Processo de Apuração de Incidente, solicitar informações ao controlador e, se constatar risco relevante, determinar a comunicação. A ANPD é a autoridade final para verificação de conformidade."

ANPD cobra explicações e iFood responde

A Autoridade Nacional de Proteção de Dados confirmou ao Estadão que não recebeu comunicação formal do iFood sobre o incidente e passou a cobrar explicações da empresa apenas após a repercussão pública do caso. O órgão lembrou que a LGPD determina que incidentes com potencial de gerar risco aos titulares devem ser comunicados tanto à autoridade quanto aos próprios usuários em até três dias úteis.

Para Marcelo Branquinho, CEO da TI Safe, empresa especializada em cibersegurança de infraestruturas críticas, a decisão do iFood de avaliar o risco por conta própria coloca a empresa em terreno juridicamente perigoso.

"Se o controlador decidir ocultar o fato baseando-se em sua própria interpretação e a ANPD posteriormente entender que havia risco relevante, a companhia fica sujeita a punições graves por omissão, infração deliberada e má-fé corporativa."

Branquinho também rebateu o argumento da empresa de que não houve vazamento de dados bancários ou senhas. "O cruzamento de histórico de endereços, telefones e CPFs viabiliza golpes de engenharia social altamente refinados, como falsos motoboys, falsas confirmações de compras e golpes de atualização de cadastro. A escala de 1,2 milhão de pessoas afetadas, por si só, já caracteriza impacto de grande escala, tornando a dispensa de notificação um posicionamento juridicamente frágil."

O elo mais fraco: quando o back-office vira porta de entrada

Além da discussão sobre notificação, os especialistas apontam que a origem da brecha revela um problema mais profundo na arquitetura de segurança da plataforma. O SIRA, sistema que processa requisições de juízes, promotores e delegados, operava sem autenticação reforçada e sem mecanismos eficazes contra extração gradual de dados.

"Revela o clássico erro de priorizar a segurança do core business, o aplicativo do usuário final, enquanto plataformas internas de back-office permanecem negligenciadas. O ecossistema é tão forte quanto o seu elo mais fraco."

A análise é de Zanini, especialista em segurança digital. "Se o SIRA lida com dados que envolvem investigações criminais e ordens judiciais, a falta de autenticação multifator de alta garantia expõe uma desconexão preocupante entre a sensibilidade do dado armazenado e o nível de investimento em segurança naquele ativo."

De Falchi reforça que sistemas com esse perfil de acesso exigem controles proporcionais ao risco. "Sistemas como o SIRA lidam com dados sensíveis e integrações com autoridades, o que reforça a importância de controles de acesso robustos como prática padrão em ambientes de alto risco."

Padrão de comportamento: transparência em xeque

O vazamento ocorre num momento em que o iFood acumula questionamentos sobre transparência. Em 27 de maio, um dia antes de o caso vir à tona nos fóruns da dark web, a Secretaria Nacional do Consumidor (Senacon) abriu processo administrativo sancionador contra a plataforma por descumprimento da Portaria 61/2026, que obriga as empresas de delivery a informar aos consumidores quanto do valor pago vai para o entregador e quanto fica com a plataforma. A multa pode chegar a R$ 14 milhões.

O Instituto SIGILO, organização dedicada à defesa dos direitos de titulares de dados, anunciou que vai notificar formalmente a ANPD e avalia a propositura de Ação Civil Pública por danos morais coletivos, caso reste demonstrada negligência na proteção dos sistemas.

A resposta do iFood: "incidente isolado e rapidamente neutralizado"

Procurado, o iFood afirmou ao Times Brasil não ter encontrado qualquer evidência de que 43 milhões de dados haviam sido vazados. Segundo a plataforma, o material disponibilizado na internet se refere a um "incidente isolado de dezembro de 2025" e "rapidamente neutralizado pelos protocolos de segurança". A empresa reiterou que o evento envolveu apenas dados cadastrais como nome e CPF, sem comprometimento de senhas, meios de pagamento ou registros financeiros, com impacto restrito a cerca de 2% da base de usuários.

Sobre a ausência de notificação à ANPD, o iFood afirmou que o incidente "foi tratado e avaliado em estrita conformidade com a legislação, que dispensa o reporte e comunicação quando o evento não acarreta risco ou dano relevante aos titulares, de acordo com os critérios regulatórios definidos pela ANPD". A empresa disse ainda que todas as comunicações com usuários são feitas exclusivamente pelos canais oficiais da plataforma.

O precedente que o iFood está criando

O caso do iFood não é apenas um incidente de segurança — é um teste sobre os limites da autorregulação em matéria de proteção de dados. Se uma das maiores plataformas de delivery do Brasil pode decidir unilateralmente que um vazamento de 1,2 milhão de registros não merece notificação, o que impede que outras empresas façam o mesmo?

A LGPD foi desenhada para evitar exatamente esse tipo de discricionariedade. O Artigo 48 não dá ao controlador o poder de definir o que é "risco relevante" — ele impõe o dever de comunicar e deixa à ANPD a palavra final. Quando a empresa inverte essa lógica, não está apenas violando a lei: está sinalizando que a conformidade é opcional.

O que está em jogo não é apenas a multa que o iFood pode receber — é o precedente que se forma. Se a ANPD não reagir com rigor, a mensagem será clara: vazamentos podem ser escondidos, desde que a empresa seja grande o suficiente para resistir à pressão pública. Se a autoridade responder com sanções exemplares, o recado será outro: a LGPD vale para todos, inclusive para os gigantes do delivery.

Resta saber se o iFood entendeu que a transparência não é um custo operacional — é o preço de operar em um mercado regulado. A resposta virá nas multas, nas ações civis e, talvez mais importante, na confiança dos 1,2 milhão de usuários que descobriram, pela dark web, que seus dados estavam à venda.

Versão em áudio disponível no topo do post.