FIESP Data Breach: 34 Million Brazilian Records Exposed in an Unsecured Elasticsearch Database

Brazil presents real challenges for cybersecurity incident reporting. In a September 2018 incident, a Brazilian booking platform exposed the personal data of roughly 500,000 individuals; identifying and reaching the responsible company proved difficult, and the database was secured only with help from social media followers who tracked down the right contact.

What Happened: The FIESP Elasticsearch Exposure

On November 12th, 2018, security researcher Bob Diachenko—while scanning for exposed Elasticsearch databases via Binaryedge.io—identified an unsecured instance holding personal records compiled by FIESP (Federação das Indústrias do Estado de São Paulo), Brazil's largest industrial federation, representing roughly 130,000 industries across 131 employers' unions.

The exposed Elasticsearch instance contained 180,104,892 total records spread across multiple indices.

What Data Was Exposed

Three indices contained personal information belonging to Brazilian citizens. The largest held 34,817,273 individual records, including:

• Full name
• RG number (Brazilian national ID)
• CPF (taxpayer registry number)
• Sex and date of birth
• Full home address
• Email address and phone number

Timeline: From Discovery to Shutdown

• November 12, 2018—Bob Diachenko discovers the exposed Elasticsearch instance and attempts to notify FIESP; the initial outreach goes unanswered.
• November 14, 2018—After days without a response, journalist Paulo Brito contacts FIESP's press office directly via Twitter to escalate the report.
• November 15, 2018—The database is finally taken offline, days after the initial notification.

This is a familiar pattern in these reports: the technical discovery is often the easy part—getting a large organization to actually respond is what takes the longest and leaves data exposed the longest.

Why Open Elasticsearch Instances Are Dangerous

Open Elasticsearch instances lack authentication by default, which means anyone who finds them can read, modify, or destroy the data inside—no password required. Beyond simply viewing records, an attacker with this level of access could install malware, deploy ransomware, gain full administrative control, remotely access server resources, and execute arbitrary code. Elastic publishes its own guidance on securing a cluster, and the baseline recommendation hasn't changed since 2018: authentication and network restrictions should never be optional.

FIESP is far from an isolated case. The same misconfiguration has produced a new headline-grabbing exposure almost every year since—see our year-by-year timeline of major Elasticsearch data breaches, which tracks the pattern from 2018 through 2026, including a 2024 incident that exposed 223 million Brazilian citizens through the same kind of unauthenticated instance.

FIESP's Response—and a Contradiction

When Brazilian outlets asked FIESP about the exposure, the organization stated it was "investigating alleged access to its registration database." It claimed the exposed data contained "only registration information," with no sensitive data or passwords involved. FIESP maintained there was no evidence personal information had actually been exposed or misused.

That statement sits uneasily next to what was documented in the open database itself: RG numbers and CPF numbers are Brazil's national identity and taxpayer registry numbers—precisely the identifying data that enables identity theft and fraud when combined with a full name, address, and date of birth. Calling this "only registration information" understates what was actually sitting in the open.

Regulatory Fallout: The MPDFT Investigation

The exposure didn't end with a quiet database shutdown. On November 22, 2018, Brazil's Ministério Público do Distrito Federal e Territórios (MPDFT)—specifically its Special Unit for Data Protection and Artificial Intelligence, coordinated by prosecutor Frederico Meinberg Ceroy—opened a formal civil inquiry into the incident. The inquiry's stated purpose was to examine the circumstances of the security incident and determine responsibility for any resulting damages. (Tecnoblog, Conjur)

What This Means for LGPD Compliance Today

Brazil's Lei Geral de Proteção de Dados (LGPD)—the country's GDPR-equivalent—had been signed into law just months before this breach, in August 2018, but it had no active enforcement mechanism at the time. LGPD's practical enforcement didn't begin until August 2021, and its dedicated regulator, the ANPD (Autoridade Nacional de Proteção de Dados), wasn't created until Decree No. 10.474/2020. That's why the response to the FIESP breach came from a public prosecutor's office using general civil-inquiry powers, rather than from a data protection authority.

A comparable exposure today would look very different: data like CPF numbers, RG numbers, and full addresses falls squarely within LGPD's scope, and a breach of this scale would likely trigger mandatory breach notification to the ANPD and potential fines. If you're evaluating this from a compliance standpoint, it's worth reading LGPD alongside its European counterpart—see how bug bounty programs support GDPR compliance for the parallel framework.

How to Secure Elasticsearch Deployments

If your organization runs Elasticsearch (or any similar document database), a few baseline steps would have prevented this exact incident:

• Enable authentication and TLS encryption before the cluster ever goes live—never rely on network obscurity alone.
• Never bind Elasticsearch directly to a public IP address; restrict access to a VPC, private network, or VPN.
• Use a firewall or security group to allow-list only the specific hosts that need access.
• Regularly scan your own infrastructure with the same tools attackers use (Binaryedge, Shodan, Censys) to catch accidental exposure before someone else does.
• Follow Elastic's official security setup guidance rather than defaults, and audit cluster configuration whenever a new environment is spun up.

FIESP Data Breach: FAQ