Attack on the Civil Defense alert system: what the failure reveals about the security of public systems

Between June 19 and 20, 2026, someone with legitimate credentials belonging to Civil Defense agents sent about ten false alerts through Brazil's National Civil Defense System, which uses cell broadcast infrastructure to reach every mobile phone in a region. Roughly 30 million people received extreme-level warnings in the early hours of Saturday. The core failure was not sophisticated: a high-impact system was protected only by a username and password, with no second factor and no adequate access control.

The case is interesting less for who did it and more for what it exposes about the security of critical public systems. Let's separate the noise from the technical lesson.

What happened, in technical terms

Cell broadcast is a channel designed for emergencies: floods, landslides, tornadoes — situations in which the message must override anything else on the device, including silent mode. It is the same technology that, in Europe, warns entire populations ahead of a climate catastrophe. By nature, such an alert assumes that what is being communicated is serious enough to justify the interruption.

In the incident, this channel was used to send false alerts, some accompanied by landslide and tornado warnings, others with joke content. The system was taken offline at around 1 a.m. During the attack, the team blocked credentials and new credentials were used to resume the broadcasts, which points to the compromise of more than one account. The Federal Police is investigating who was responsible, without ruling out the involvement of authorized users.

The failure was not sophisticated: the basics of access control were missing

Based on public information, two problems stand out, both in the most basic terrain of application security — what OWASP treats as access control.

The first is the absence of a second authentication factor. If the compromise of a single credential was enough to send messages to 30 million people, then there was no additional layer between the password and the broadcast. For a system with this reach, a username and password are insufficient, no matter how strong the password. A code from an authenticator app, or even a weaker factor sent through another channel, would already have significantly raised the cost of the attack.

The second is the lack of scope segregation. A technical report on the case indicates that a single account should not have been able to send alerts to more than one region. If that rule existed but was broken, it was probably not encoded in the system, relying instead on manual configuration. When an integrity rule is critical, the system itself must prevent its violation, not trust whoever assigns access. There are reports that a captcha existed, but of the kind that asks for the result of a math problem — trivial to bypass and irrelevant in the face of the authentication failure.

The root cause: threat modeling that was not done

Failures like this are rarely a one-off oversight. They indicate that the step before development did not happen: threat modeling. To model threats is, before writing code, to map what can go wrong in a system, which actors are capable of attacking it, the impact of each scenario, and from that, to specify which security mechanisms are mandatory. Only then come the implementation and the actual testing of those mechanisms.

A system that reaches 30 million people, through a channel whose delivery the recipient cannot refuse, and whose purpose is to communicate a risk to life, has an extremely high impact profile. Even minimal threat modeling would have made strong authentication and privilege segregation non-negotiable requirements. The absence of these controls suggests that the modeling was poorly done or simply never existed. Without it, implementation is left adrift, guided by the intuition of whoever is coding at that moment.

The problem is structural, not isolated

This is not an outlier. Brazil's Federal Court of Accounts (TCU) has for years been pointing out low security maturity in public agencies. In an audit of web hosting, email, and DNS services, the TCU concluded that most security-practice indices show a low or intermediate maturity level, leaving most organizations and their clients exposed to attacks. The identified causes were direct: a lack of resources or investment, of staff, and of training, as well as low effectiveness in implementing the standards.

The volume of incidents matches this diagnosis. Considering the federal Executive branch agencies, the TCU recorded an increase from 3,402 information security incidents in 2022 to 5,302 in 2024. It is the same pattern we find in the field. When we run a pentest, it is common for the client's team to believe the system is secure — and not out of incompetence: the understanding of those who develop is oriented toward functionality and delivery, not toward the ways it can be broken. That is precisely the gap that an external, specialized perspective fills.

Security research is not the same as intrusion

It is worth separating two things that coverage of the case tends to blur. Finding a flaw and exploiting it to cause impact — sending false alerts — is a crime, and the perpetrator answers for it. That is different from good-faith security research, in which a vulnerability is identified, the responsible party is notified through official channels, the flaw is not exploited to cause harm, and, once a reasonable deadline has passed without a fix, the problem is disclosed with due proof that an attempt to warn was made. The first conduct destroys trust in a system that can save lives. The second helps fix it before someone with bad intentions gets there.

Frequently asked questions

What caused the attack on the Civil Defense alert system?

Based on public information, the compromise of legitimate agent credentials, combined with the absence of a second authentication factor and of privilege segregation by region. A single compromised credential was enough to send alerts on a national scale, which indicates basic access control failures.

What is threat modeling and why does it matter here?

Threat modeling is the analysis, done before development, of what can go wrong in a system, who can attack it, and the impact of each scenario, in order to then define the mandatory security controls. In the Civil Defense case, adequate modeling would have made strong authentication and access segregation non-negotiable requirements, given the system's reach.

Would a second authentication factor have prevented the attack?

There is no absolute guarantee, but it would have greatly raised the cost of the attack. If the compromise of a single password allowed messages to be sent to millions of people, an additional layer of verification would have broken the most likely chain of the attack. For high-impact systems, single-factor authentication is inadequate.

Is this only a public-sector problem?

Low maturity is more visible in public systems because of resource and staffing constraints, pointed out in TCU audits. But the pattern of underestimating risk for lack of a security mindset also appears in the private sector, whenever the priority is delivering functionality and security is left for later.

Assess the exposure of your critical systems

If your organization operates high-impact systems and has not yet gone through threat modeling or an independent security test, we can discuss the scope. We do threat modeling and pentesting to identify — before an incident — what needs to be protected and how.

Get in touch with BrownPipe

---

Vinícius Serafim is a partner and consultant at BrownPipe Consultoria, a specialist in pentesting and application security. BrownPipe has worked in information security and data protection since 2012. This content was produced with AI assistance and is derived from episode #421 – Alerta da Defesa Civil of the Segurança Legal podcast, hosted by Guilherme Goulart and Vinícius Serafim. Watch the full episode on YouTube: youtu.be/MxZVb6xFl6c.