When doubt exists about the scope of risk, companies must take preventive action anyway.
Em dezembro de 2025, o iFood foi alvo de um ataque cibernético que expôs dados pessoais de 1,2 milhão de usuários — um episódio que, como tantos outros na era digital, levanta questões que vão além da tecnologia: sobre confiança, transparência e a responsabilidade das empresas diante da fragilidade dos dados que guardam. A empresa afirma ter contido o dano rapidamente e nega que informações financeiras tenham sido comprometidas, mas a decisão de não notificar a autoridade reguladora brasileira trouxe à tona o peso das obrigações legais e éticas que acompanham o ato de custodiar a identidade de milhões de pessoas. No espaço entre a versão oficial e as alegações de hackers na dark web — que falam em 43,8 milhões de afetados e dados de cartão de crédito —, os usuários aguardam uma verdade que ainda não chegou.
- Um ataque silencioso em dezembro de 2025 expôs nomes e CPFs de 1,2 milhão de brasileiros, documentos que carregam peso de identidade nacional e abrem portas para fraudes e roubo de identidade.
- A decisão do iFood de não comunicar o incidente à ANPD gerou tensão imediata com o órgão regulador, que lembrou publicamente que a LGPD exige notificação em até três dias úteis — independentemente de certeza sobre o dano.
- Na dark web, um hacker afirma ter roubado dados de 43,8 milhões de usuários, incluindo informações de cartão de crédito, e fixou 10 de junho como prazo para o iFood negociar um resgate — alegação que a empresa rejeita categoricamente.
- O abismo entre as duas narrativas — a do iFood, que fala em contenção rápida e dano limitado, e a do hacker, que aponta uma violação de escala muito maior — deixa reguladores, usuários e o mercado sem uma resposta definitiva sobre o que de fato foi comprometido.
O iFood confirmou na quarta-feira que um ataque cibernético ocorrido em dezembro de 2025 expôs dados pessoais de cerca de 1,2 milhão de usuários — aproximadamente 2% de sua base de clientes. Segundo a empresa, os protocolos de segurança contiveram o incidente rapidamente. As informações comprometidas incluíam nomes e números de CPF, o documento de identificação fiscal que funciona como identidade nacional no Brasil. O iFood foi enfático ao afirmar que senhas, métodos de pagamento e registros financeiros não foram acessados.
A decisão da empresa de não notificar a Autoridade Nacional de Proteção de Dados (ANPD) gerou reação imediata. O iFood avaliou que o incidente não atingia o limiar de risco relevante exigido pela legislação para obrigar a comunicação. A ANPD discordou: confirmou não ter recebido qualquer notificação e solicitou as informações necessárias, lembrando que a LGPD exige que empresas comuniquem tanto a autoridade quanto os usuários afetados em até três dias úteis após qualquer incidente com potencial de causar risco — sem que seja necessário ter certeza sobre o dano para que a obrigação se aplique.
Enquanto isso, um usuário do Breach Forums, fórum conhecido na dark web, afirmou ter roubado dados de 43,8 milhões de usuários do iFood — incluindo CPFs, e-mails, telefones e dados de cartão de crédito —, e estabeleceu 10 de junho como prazo para que a empresa entrasse em contato e pagasse um resgate não especificado. O iFood rejeitou a alegação, reafirmando que apenas 1,2 milhão de usuários foram afetados e que nenhuma informação financeira foi comprometida.
As duas versões não podem ser simultaneamente verdadeiras. De um lado, a narrativa controlada de uma empresa com obrigações legais e uma equipe de segurança. Do outro, um ator anônimo fazendo exigências em um fórum de hackers. Para os milhões de brasileiros cujos dados podem estar circulando sem seu conhecimento, a resposta definitiva ainda não chegou.
iFood acknowledged on Wednesday that a cyberattack in December 2025 had exposed the personal data of roughly 1.2 million of its users—about 2 percent of its customer base. The breach, the company said, was contained swiftly by its security protocols.
The compromised information included names and CPF numbers, the Brazilian tax identification document that functions as a national ID. iFood was emphatic about what was not taken: no passwords were exposed, no payment methods were breached, no financial records were touched. The company characterized the incident as isolated and quickly neutralized.
When it came to notifying regulators, iFood made a calculation. The company did not report the breach to Brazil's data protection authority, the ANPD, reasoning that the incident did not meet the threshold of causing relevant risk or harm to the affected users under the agency's criteria. That decision drew immediate scrutiny. The ANPD responded by confirming it had received no notification from iFood, then requested the necessary information. The agency also reminded the company—and the public—of what Brazil's data protection law actually requires: notification to both the ANPD and affected individuals within three business days of any security incident that could cause relevant risk or damage. The law does not demand certainty about harm; it demands that companies assess the nature of the data involved, the number of people affected, and the potential consequences. When doubt exists about the scope of risk, the law says, companies must take preventive action anyway.
But the dispute over the breach's true scale had only begun. A cybersecurity monitoring site called Dark Web Informer reported that a user on Breach Forums, a known gathering place for hackers, had claimed to have stolen data from 43.8 million iFood users—not 1.2 million. According to the hacker's post, the stolen information included CPF numbers, full names, email addresses, phone numbers, and credit card data. The hacker set a deadline: iFood had until June 10 to contact them and pay an unspecified ransom.
iFood rejected the claim outright. The company restated its position: 1.2 million users were affected, and only basic registration data was exposed. No credit cards, no financial information. The gap between these two narratives—the company's controlled disclosure and the hacker's far larger claim—left users and regulators in an uncomfortable space. One account came from iFood itself, backed by its security team and its legal obligations. The other came from an anonymous actor on the dark web, making demands. Both could not be true. The question of which was accurate, and what it meant for millions of Brazilians whose personal information might be in circulation, remained unresolved.
Notable Quotes
The breach was an isolated incident, rapidly neutralized by security protocols, with no compromise of passwords, payment methods, or financial records.— iFood statement
When doubt exists about the scope of risks and damages involved, the controller must adopt adequate preventive measures.— ANPD (Brazil's data protection authority)
The Hearth Conversation Another angle on the story
Why did iFood wait until now to disclose a breach that happened in December?
The company says it contained the attack quickly and didn't believe it met the legal threshold for notification. But that's exactly what the data protection authority is questioning—whether iFood should have made that call alone.
So the ANPD is saying they should have reported it anyway?
Essentially, yes. The law says when there's doubt about whether harm could occur, you report it. You don't get to decide unilaterally that the risk is too low.
And the hacker claiming 43.8 million users—how credible is that?
That's the unsettling part. We don't know yet. The hacker has a deadline, a specific number, and is asking for money. iFood denies it completely. But the gap between what iFood says happened and what the hacker claims is so large that someone is either lying or doesn't understand what they actually stole.
What's the real danger for the 1.2 million people iFood admits were affected?
CPF numbers and names are enough for identity theft in Brazil. Someone could open accounts, take out loans, file fraudulent tax returns. It's not as immediately dangerous as stolen credit cards, but it's serious.
Why wouldn't iFood just report it to be safe?
Liability, probably. The moment you notify regulators and users, you're admitting a breach happened. You're opening yourself to lawsuits, regulatory fines, reputational damage. If you can argue it doesn't meet the threshold, you avoid all that—unless the regulator disagrees.