90 incidents on record · 2026 Headlights Incident reports by Ellie Harris · Melbourne
10 new this week Library last updated 13 July 2026
← The incident library
HD-INC-027
Recruitment technology · United States · 2025 · Data exposure & egress

McDonald's AI hiring bot left the details of as many as 64 million job applicants behind the password 123456

By Ellie Harris · Filed Disclosed 30 June 2025

Alleged: McDonald's, Paradox.ai (McHire) developed or deployed the AI system implicated in this incident. Details are drawn from public reports; parties are presumed innocent of any wrongdoing not established by an official finding.

McDonald's AI hiring bot left the details of as many as 64 million job applicants behind the password 123456

What happened

McHire is the platform McDonald’s franchisees used to recruit staff, fronted by an AI chatbot named Olivia, built by Paradox.ai, that screened applicants and collected their details. In June 2025, security researchers Ian Carroll and Sam Curry looked at how it was secured.

On a login page meant for staff of Paradox, the vendor, they found a dormant test administrator account whose username and password were both “123456”, with no multi-factor authentication. Paradox later said the account had not been logged into since 2019. Those credentials gave them administrator access to live hiring data. Inside, they found a second flaw: applicant records were numbered sequentially, and the system would hand over any record if you simply asked for its number. By counting down through the IDs, a person could pull anyone’s data: full names, contact details, the transcripts of their chats with Olivia, shift preferences, personality-test results, and tokens that could be used to impersonate a candidate. The IDs ran up to about 64 million, which is the figure usually attached to the breach. That number is the upper bound of what was reachable, not a confirmed count of complete profiles: Paradox said most records held little personal information, and that only a handful of the records the researchers actually opened contained full personal details.

The researchers disclosed the problem to Paradox.ai and McDonald’s on 30 June 2025. The companies acknowledged it within the hour, and by 1 July the default credentials were disabled and the weak endpoint was closed. There was no evidence that anyone malicious had reached the data first, but there was also, by the nature of the flaw, no way for the company to prove who had.

What an auditable version would have shown

The most uncomfortable question after a breach like this is the one the company usually cannot answer: did anyone else get in, and what did they take? The flaw had reportedly been reachable for a long time, the credentials were trivial, and the records could be enumerated one by one. The only honest answer the company could give was that it had no indication of misuse, which is not the same as proof there was none.

An auditable system would record every access to applicant records: which account, from where, which records, and when. A pattern of one account walking sequentially through millions of IDs is exactly the shape of event such a record would make visible, in real time or in hindsight. The difference between “we have no evidence of misuse” and “here is the complete access log, and nothing anomalous appears in it” is the difference between hoping and knowing.

Where the gap was

The gap was that a system holding the records of tens of millions of applicants could neither keep that data inside a trust boundary nor record who crossed it.

An EgressGate governs sensitive data leaving, or being reachable from outside, the trust boundary. Personal data of millions of applicants, classified as sensitive, should never have been retrievable by an unauthenticated or trivially authenticated request, and the gate’s job is to refuse exactly that. A ConductRecord then logs each access decision, so that the question “who reached this data, and when?” has an answer that does not depend on the attacker’s goodwill in disclosing it.

The deployed system had a default password instead of a boundary, and counted on the absence of evidence instead of the presence of a record.

What governance should have looked like

An AI hiring tool collects some of the most sensitive data an ordinary person ever hands over, and at enormous scale. The governance has to match the stakes, not the convenience of standing the bot up quickly.

Access to that data should be gated on real authentication and real authorisation, with sensitive records treated as something that may not leave the boundary without a recorded, justified reason. Every access should be logged in a form the company can produce, so that after any incident the question of exposure is answered with evidence rather than with the absence of it. The vendors and employers that build that in can stand in front of the people whose records were reachable and show exactly what happened to their data. The ones that do not are left saying they have no reason to think anything went wrong, which is the weakest sentence in security.

The reference implementation of EgressGate and ConductRecord is open source. It lives at github.com/saffronandindia/headlights-oss, Apache 2.0 licensed and free to install. The repository is public now.

Sources

The mailing list

Fresh incident reports every week. One email to match.

We add new incidents to the library regularly, and send a single short email each week with what's new. The library stays free and open; this is just how you keep up with it.

No tracking. Unsubscribe in one click.

The record

An auditable system would have produced a signed, tamper-evident record the moment this happened: what the system did, the version that did it, the basis it acted on, and the action taken, and McDonald's, Paradox.ai (McHire) could have produced it on demand.

This is the record the system as deployed did not produce in a signed, auditable form.

What this teaches
Capture what happened when it happens
What the system did, the version that did it, the basis it acted on, and the action taken, recorded at the moment, not reconstructed after.
Sign it, so no one has to trust the record-keeper
A tamper-evident entry. Edit it later and the signature breaks. The record does not ask for the benefit of the doubt.
Make it verifiable by anyone
A court, a regulator, a customer's lawyer can check the record themselves, without taking the company, or us, at our word.

Headlights summarises publicly reported AI incidents. All summaries are independently written, attributed to their original sources, and intended for research and educational purposes. Allegations are identified as such until established through official findings.

Last reviewed June 2026. This report is based on the sources listed above and reflects information available at the time of review; later developments may not be captured. Where a person is described as charged with or alleged to have done something, that allegation is unproven unless a conviction or a court or regulatory finding is stated. Headlights publishes journalism and commentary, not legal advice.

Want to write back?

Direct to my inbox.

ellie@useheadlights.com →