French Data Breach: MisterTemp Job Agency Exposed Millions of Records

What Happened: An Unprotected Elasticsearch Cluster Found During Routine Scanning

On December 21st, 2018, HackenProof identified an unsecured Elasticsearch database during routine Shodan-based scanning. The database belonged to MisterTemp, a French online temporary employment agency. At least two separate IP addresses were hosting passwordless Elasticsearch clusters, both fully reachable from the open internet.

The primary index alone held roughly 2.9 million records—a substantial share of France's temp-staffing job seeker population, sitting with no authentication in front of it.

What Data Was Exposed

The exposed records included:

• Full names and email addresses
• Physical addresses and birthdates
• Nationality and mobile phone numbers
• Educational background and work experience
• Links to external AWS storage containing resumes and scanned identity documents
• In some cases, social security card numbers and passport numbers

That last category—scanned social security cards and passports, linked directly from candidate records via exposed AWS storage URLs—pushes this well past a typical contact-information leak. Combined with the AWS access credentials visible in the same records, this wasn't just a privacy exposure; it was a set of live keys sitting next to the documents they could be used to retrieve.

The Ransom Note Inside the Database

The exposed instance also contained a "readme" index—a signature left by automated extortion bots that scan for open Elasticsearch and MongoDB instances, wipe or encrypt the data they find, and demand a Bitcoin payment for its return. Its presence here meant MisterTemp's database wasn't just exposed to anyone who found it manually; it had already been discovered by opportunistic, automated attackers scanning for exactly this kind of misconfiguration.

Timeline: From Discovery to Shutdown

• December 21, 2018—HackenProof discovers the exposed cluster and emails MisterTemp; the only response is an automated holiday out-of-office reply.
• December 28, 2018 and into January 2019—HackenProof sends further notifications, including to CERT-FR, France's national computer emergency response team.
• January 9, 2019—French security researcher Damien Bancal calls MisterTemp's senior management directly and urges immediate action.
• January 9, 2019—The database is secured the same day, within minutes of the call, according to Bancal's own report.

Nearly three weeks passed between the first disclosure attempt and the database actually coming down—and what finally moved it wasn't an email to a security contact, but a phone call to a company executive. It's a pattern that shows up again and again in these reports: automated or written disclosure gets lost in the holidays; a direct human escalation is what actually gets a fix.

MisterTemp's Response

MisterTemp acknowledged the exposure and attributed it to human error—reportedly connected to a test environment left improperly secured. Alexandre Pham, director of Alphyr (MisterTemp's parent company at the time), addressed the incident publicly but did not clearly state whether the roughly 2.9 million affected job seekers would be individually notified, which GDPR requires when a breach poses a high risk to the people involved.

Would This Trigger a CNIL Fine Under GDPR Today?

This breach happened seven months after GDPR took full effect across the EU, which makes the lack of any public follow-through notable. We found no public sanction or formal decision from France's data protection authority, the CNIL, against MisterTemp or Alphyr for this incident—despite the exposure including sensitive identity documents and financial-adjacent data. That doesn't necessarily mean nothing happened privately; internal breach notifications filed with CNIL aren't published. But there's no public record that this ever became a CNIL enforcement matter.

A comparable exposure discovered today would very plausibly not get off that easily. Two CNIL decisions since then set a clear benchmark. In December 2021, payments company Slimpay was fined €180,000 after an internal research server was left completely unsecured from 2015 to 2020, exposing roughly 12 million people's names, addresses, phone numbers, and banking details—CNIL cited both inadequate security under GDPR Article 32 and a failure to notify affected individuals, a structural match to what happened here. More strikingly, in January 2026, France Travail (the successor to Pôle emploi, France's national employment agency) was fined €5 million after attackers reached two decades of jobseeker records—social security numbers, addresses, phone numbers—through weak authentication and access controls that the organization had itself flagged internally but never fixed. If a French employment-data controller exposed millions of job seekers' identity documents today, a fine in that range is a realistic outcome, not a hypothetical one.

Is Exposed Elasticsearch Still a Problem in 2026?

Yes, and the numbers are worse than they were in 2018. A multi-year study covering May 2021 through May 2026 tracked nearly 66,000 exposed database systems and found that 46.3% already carried a ransom or wipe note by the time researchers found them—for Elasticsearch specifically, 97.9% of exposed instances had already been compromised. The "readme" ransom note MisterTemp's database carried wasn't a one-off; it's now closer to the default outcome for an unsecured Elasticsearch instance left open for any meaningful length of time.

Job and recruitment platforms specifically have kept showing up in this pattern. In August 2026, a German HR platform, Talentsconnect, was found with a misconfigured MongoDB instance offering public read and write access to more than 5 million job listings across 843 companies, along with live credentials for major recruitment and HR systems. In 2022, an Italian sales-recruitment platform, Tuoagente, left an open Elasticsearch instance exposing over 100,000 sales-agent profiles and 40,000 CVs. The specific database engine changes; the underlying mistake—authentication left off by default on a system holding sensitive career and identity data—doesn't.

MisterTemp Was Breached Again in 2026

The company at the center of this 2019 incident is still operating—and it's worth knowing the story didn't end there. Alphyr rebranded as Mistertemp Group, now operating multiple staffing brands (including Aquila RH, Lynx RH, and Vitalis Médical) across more than 230 agencies. In July 2026, the group suffered another intrusion, disclosed publicly on August 27, 2026: unauthorized access to names, emails, phone numbers, and nationality data. This time, the company reported that no banking data, passwords, or identity documents were affected, said CNIL was notified, and confirmed a criminal complaint had been filed.

That's a materially better-handled disclosure than in 2019—a clear scope statement, regulator notification, and a legal complaint, rather than a holiday auto-reply and a three-week wait for a phone call to work. But it's also a reminder that securing a database once, under pressure, doesn't make an organization's data practices durable—the same company, seven years on, is still a target.

How to Secure Elasticsearch Deployments

The specific misconfiguration behind this breach—Elasticsearch reachable from the open internet with no authentication—remains entirely preventable:

• Enable authentication and TLS encryption before any Elasticsearch cluster goes live; Elasticsearch does not require this by default, so it's the operator's responsibility to turn it on.
• Never bind Elasticsearch to a public IP address; restrict it to a private network, VPC, or VPN.
• Use a firewall or security group to allow-list only the specific hosts that legitimately need access.
• Treat linked storage—S3 buckets, document URLs, access keys referenced inside database records—as part of the same security boundary as the database itself; a locked-down database with exposed storage credentials inside it isn't actually locked down.
• Regularly scan your own infrastructure with the same tools attackers use, including Shodan, Censys, and Binaryedge, to catch an exposed instance before it's found and ransomed by an automated bot.
• Build and rehearse an incident response process that doesn't depend on a single email reaching the right inbox during a holiday period—a direct escalation path matters, as this case shows directly.

MisterTemp Data Breach: FAQ