The system functioned perfectly until 8:15 a.m., then something changed.
Em uma democracia, poucos momentos são tão delicados quanto aquele em que os cidadãos depositam sua confiança em um sistema para registrar sua voz. No dia 21 de novembro de 2021, o aplicativo desenvolvido para a eleição interna do PSDB entrou em colapso pouco depois das 8h, deixando apenas 3 mil votos registrados de um universo de quase 45 mil eleitores habilitados. A fundação responsável pelo sistema aponta para um possível ataque externo, mas reconhece que a verdade ainda aguarda investigação independente — e com ela, a legitimidade da própria eleição.
- Das 44.828 pessoas aptas a votar, apenas cerca de 3 mil conseguiram registrar seu voto — uma lacuna que coloca em xeque toda a validade da prévia.
- Às 8h15, o sistema passou de estável para sobrecarregado em questão de minutos, com demandas de processamento incompatíveis com o número real de eleitores.
- A Faurgs descarta falha interna e aponta para um ataque hacker como explicação 'muito plausível', argumentando que a infraestrutura na Microsoft Azure era mais do que suficiente para o volume esperado.
- Dez versões preliminares, duas auditorias prévias, reconhecimento facial e inteligência artificial — toda a preparação não foi suficiente para impedir o colapso no dia decisivo.
- A fundação admite que não pode provar sozinha o que ocorreu, e que apenas uma auditoria conduzida por empresas especializadas externas poderá esclarecer se houve ataque, sobrecarga ou falha de design.
Na quarta-feira, 24 de novembro, a Fundação de Apoio à Universidade Federal do Rio Grande do Sul — a Faurgs — divulgou uma nota sugerindo que o aplicativo desenvolvido para a prévia do PSDB pode ter sido alvo de um ataque hacker. A fundação havia sido contratada para criar o sistema em 90 dias, e no dia da votação, 21 de novembro, a plataforma deveria processar os votos de 44.828 filiados.
O dia começou sem problemas. Das 7h em diante, cerca de dois mil votos foram registrados normalmente. Mas às 8h15 algo mudou: entre aquele momento e as 18h, o sistema passou a enfrentar demandas atípicas de processamento — incompatíveis com o número de eleitores cadastrados. Ao fim do dia, apenas três mil votos haviam sido contabilizados. A diferença entre o eleitorado habilitado e os votos efetivamente registrados era gritante e sem explicação clara.
A Faurgs apresentou duas hipóteses: falha de capacidade da infraestrutura ou ataque externo que gerou congestionamento artificial. A fundação inclinou-se pela segunda, classificando-a como 'muito plausível' diante do comportamento do tráfego e do fato de que a plataforma Microsoft Azure utilizada teria capacidade de sobra para o volume real de usuários. A empresa destacou que havia produzido dez versões preliminares do sistema, passado por duas avaliações de uma empresa independente contratada pelo próprio PSDB e realizado testes bem-sucedidos em 18 de novembro, com reconhecimento facial biométrico e inteligência artificial para detecção de anomalias.
Ainda assim, toda essa preparação não evitou o colapso. A Faurgs garantiu que os votos registrados permaneceram seguros e que o aplicativo estaria pronto para operar novamente assim que as condições se normalizassem. Mas a nota também continha uma admissão implícita: a fundação não tem condições de determinar sozinha o que ocorreu. Será necessária uma auditoria conduzida por empresas especializadas externas para descobrir se houve ataque, sobrecarga simples ou uma combinação dos dois fatores. Enquanto essa resposta não chega, a legitimidade da prévia permanece suspensa — e com ela, uma pergunta sem resposta sobre o que de fato aconteceu naquele domingo de novembro.
On Wednesday, November 24th, the foundation that built the voting app for Brazil's PSDB party primary election released a statement suggesting the system may have been attacked by hackers. The Fundação de Apoio à Universidade Federal do Rio Grande do Sul, or Faurgs, had been contracted to develop the application on a 90-day timeline. By election day on November 21st, the system was supposed to handle votes from 44,828 registered party members.
What actually happened that day tells a story of technical failure, finger-pointing, and unanswered questions. The app functioned normally from 7 a.m. onward, processing roughly two thousand votes without incident. Then, at 8:15 a.m., something changed. Between 8 a.m. and 6 p.m., the system experienced what Faurgs described as atypical demands on its data processing capacity—demands that seemed incompatible with the number of voters who had registered. By the time voting ended, only about three thousand votes had been recorded in total. The gap between registered voters and actual votes cast was stark and unexplained.
Faurgs presented two possible explanations in its statement. The first was straightforward: the system simply couldn't handle the traffic. The second was more dramatic: hackers had attacked the application starting at 8:15 a.m., creating artificial congestion that overwhelmed the infrastructure. The foundation leaned toward the hacker theory, calling it "very plausible" given the timing and the nature of the processing surge. The company emphasized that the platform it used—Microsoft Azure—had more than enough capacity to handle the actual number of voters, which suggested the problem came from outside the application itself.
Faurgs had prepared for this election carefully, or so the statement suggested. The company had produced ten preliminary versions of the system before settling on a final design that worked both as a mobile app and a web platform. An independent firm hired by the PSDB had evaluated the system twice, and Faurgs said it had addressed every risk that was flagged. System tests conducted at the PSDB's own facilities on November 18th had gone smoothly, with all security and performance measures in place. The foundation had even implemented biometric facial recognition and artificial intelligence systems to detect anomalies in data flows.
Yet none of that preparation prevented what happened on voting day. Faurgs was careful in its language: the software itself worked perfectly under normal conditions, the company said. The instability came from external factors. The roughly three thousand votes that were recorded remained secure and uncounted, the foundation assured the party. The app was ready to be used again whenever conditions normalized.
But the statement also contained an implicit admission of limits. Faurgs acknowledged that determining what actually caused the outage would require an independent audit by specialized firms—not an investigation led by Faurgs itself. The company could point to the suspicious timing and the unusual traffic patterns, but it could not definitively prove whether hackers had struck, whether the infrastructure simply buckled under unexpected load, or whether some combination of both had occurred. The PSDB would need to hire outside experts to find out. Until then, the question of what went wrong on November 21st remained open, and the legitimacy of the primary election itself hung in the balance.
Notable Quotes
The Faurgs foundation considers it very plausible that hackers attacked the application starting at 8:15 a.m., given that the system functioned perfectly from 7 a.m. onward with about two thousand votes processed.— Faurgs statement
The instability occurred due to conditions external to the application itself, as the platform used has capacity for far more access than the size of the electoral body.— Faurgs statement
The Hearth Conversation Another angle on the story
Why would hackers target a party primary election app? What's the value in disrupting it?
That's the question nobody's answered yet. You disrupt an election to either steal data, delegitimize the result, or make a political point. But Faurgs didn't investigate deeply enough to know which one it was—or if it was any of those things.
The company says the system worked fine until 8:15 a.m. How confident can we be in that claim?
Only as confident as the logs they kept. If someone was attacking the system, they might have been probing it earlier without leaving obvious traces. The sudden spike at 8:15 could be when they went all-in, or it could be when normal traffic finally overwhelmed an undersized system.
But Faurgs says Microsoft Azure could handle way more traffic than 44,000 voters. So wouldn't that rule out a simple overload?
In theory, yes. But that assumes the problem was with Azure itself. What if the bottleneck was somewhere else—the app's code, the database, the connection between them? A platform can be massive and still fail if the application built on top of it is poorly designed.
So Faurgs is basically saying, "It wasn't our fault, but we can't prove it."
More or less. They're saying the software performed as designed, the infrastructure was adequate, and therefore something external must have happened. But they're also admitting they can't prove that without an independent audit. It's a defensive posture.
What happens to the three thousand votes that were recorded?
They're supposedly secure and preserved. But if the election results are contested, those votes might not matter. The real question is whether the PSDB can trust any result from a system that failed this badly on the day that counted.
Will we ever actually know what happened?
Only if the PSDB hires those independent auditors and makes the findings public. And that's a big if. Sometimes these things stay murky by design.