McDonald's AI Hiring Bot Exposed 64 Million Applicants Behind the Password 123456

What Happened

McHire sits at the front door of one of the largest hourly hiring systems in the world. More than 90 percent of McDonald's franchisees use the platform. A job seeker finds an opening, then chats with Olivia, a recruiting assistant built by Paradox.ai. Olivia collects the applicant's name and contact details, asks about available shifts, moves the person through a Traitify personality test, and keeps the conversation attached to the application for restaurant staff to review.

That experience looks like an AI story because a chatbot mediates it. The security failure behind it was much older and much less exotic. Researchers Ian Carroll and Sam Curry found a sign-in path for Paradox team members next to McDonald's single sign-on flow. They tried 123456 as the username and 123456 as the password. The credentials worked. According to reporting on the incident, they belonged to a test account that had been dormant since 2019.

The account opened a test restaurant's administrative view. By itself, that was already a serious identity-control failure: a legacy account, a known-default credential pattern, and meaningful access surviving for years. But it did not yet establish the story's enormous potential scope. That came when the researchers applied to one of the test restaurant's jobs, opened their own Olivia conversation from the restaurant side, and watched how the browser fetched the candidate record.

The request used an internal endpoint identified by Carroll as PUT /api/lead/cem-xhr. Its key parameter was a lead_id. Their test applicant's identifier was about 64,185,742. When they decremented that number, the server returned another applicant's record, including unmasked contact data. There was no object-level authorization decision confining the logged-in account to the test applicant or an approved restaurant population.

One old credential crossed the identity boundary. One insecure direct object reference, or IDOR, erased the boundary between applicant records. Together they created a repeatable path across an estimated 64 million applications containing names, email addresses, phone numbers, addresses, availability, application-state history, form inputs, raw Olivia chats, and authentication tokens that could sign into the applicant-facing interface.

What "64 Million" Means, and What It Does Not

Breach headlines tend to collapse three different quantities into one: records that a vulnerability could reach, records researchers inspected to prove the finding, and records an unknown attacker actually stole. They are not interchangeable. Here, the high sequential lead_id and the ability to move from one applicant to another supported the estimate that the path covered about 64 million applications. That number describes exposure scope: how far an unauthorized caller could potentially travel.

It is not evidence that 64 million distinct people were compromised, nor proof that 64 million records were downloaded. One person can submit more than one application, and the sources do not establish that every numeric identifier maps to a unique applicant. The researchers limited their inspection, and Paradox's account says five candidates' information was viewed by them. No source provided evidence of malicious mass extraction.

Precision does not make the incident smaller. A door that can open onto millions of sensitive records is a critical design failure even when the people who discover it are careful and the vendor closes it quickly. Security programs are supposed to evaluate the credible blast radius before an adversary demonstrates it. Waiting for proven theft turns a preventive control question into an incident-response question.

The right statement is therefore two-sided: the McHire flaws put an estimated 64 million application records within a repeatable unauthorized path, while the available evidence indicates limited researcher access and no known criminal exploitation. Good governance can hold both facts at once.

Why You Should Care Even If You Do Not Run a Hiring Bot

The first lesson is that an AI system is never only a model. McHire was also an identity service, an administrative application, a multi-party vendor relationship, a backend API, a repository of private conversations, and an account-recovery mechanism. The model could have behaved perfectly and the incident path would still exist. Prompt injection against Olivia reportedly went nowhere; ordinary application-security testing found the consequential weakness.

The second lesson is about trust. Applicants did not choose Paradox, design the retention model, or negotiate which restaurant users could see their data. They entered information because they believed they were applying to McDonald's. The recognizable brand collected the trust; the vendor platform processed the data; franchisees used the workflow. Accountability has to span all three. A contract can allocate duties, but it cannot make the applicant's risk disappear.

The third lesson is that scale converts familiar bugs into governance events. A weak test login on an isolated demonstration system is bad hygiene. A weak login chained to a production-adjacent API with sequential access to a nationwide applicant corpus is a different category of exposure. Risk is not the sum of isolated findings. It is the authority those findings create when combined.

Every enterprise deploying AI should ask the same question of its surrounding application: if one forgotten identity is compromised, what can the next trusted service be persuaded to return? The answer must be enforced at every object boundary, not assumed from the login screen.

The Research Path Started With a Real Application

Carroll and Curry did not begin with inside knowledge. They saw complaints about Olivia producing nonsensical answers, found the public McHire job site, and applied to a local McDonald's. Olivia collected their email, phone number, and shift availability, then moved them to a personality test that asked them to classify statements such as whether they enjoyed overtime.

They first tried the kind of attack most people now associate with AI systems: prompt injection. That route was unproductive. Olivia appeared restricted to preset responses, and the candidate-side workflow stalled at the point where a human would review the application. This detail matters. It is evidence that the obvious AI attack surface was not the useful path, while a conventional administrative surface nearby still accepted the weakest imaginable credentials.

After the default login opened the test restaurant, the researchers could observe the hiring workflow from both sides. They submitted an application to a test posting and viewed their own in-progress Olivia conversation from the administrative inbox. That controlled, self-generated record provided a legitimate reference request. Comparing what the browser sent for their record with what the server returned for a neighboring identifier exposed the authorization gap.

This is a useful testing pattern for defenders: create two controlled users in different authorization scopes, record a valid request for each, then cross the identifiers, sessions, roles, and tenant context. The important question is not whether the identifier is hard to guess. It is whether the server proves that the current caller is entitled to the requested object.

An ID Is an Address, Not an Authorization Decision

Authentication and authorization are frequently treated as one control because both appear near the word "access." They answer different questions. Authentication establishes who presented the request. Authorization decides whether that identity may perform this action on this object for this purpose. The McHire session could be authentic and the request could still be unauthorized.

The lead_id told McHire which record to retrieve. It did not prove the restaurant, test account, support user, or current session had a relationship with that applicant. In a secure design, the server derives the allowed restaurant or tenant scope from trusted session context, queries only inside that scope, and denies a requested object that falls outside it. The client should not be able to expand authority by editing a number.

Replacing sequential numbers with random identifiers would make enumeration less convenient, but it would not repair the control. A leaked link, browser history entry, log line, support ticket, or guessed identifier could still expose the object. Randomness is defense in depth. Per-object, server-side authorization is the boundary.

The response payload also matters. Returning raw chat messages and an applicant authentication token alongside ordinary contact fields increased the consequence of each unauthorized read. Data minimization is not only about storage. It is also about ensuring an endpoint returns no more than the caller needs for the approved task.

Disclosure and Remediation Timeline

The primary disclosure records a fast initial response once the report reached the right people. It also records a preventable coordination problem: the researchers could not find a public security contact for the affected service and resorted to emailing people until the report reached an owner. A good response clock cannot start until a researcher knows where to send the evidence.

Why the Two Findings Multiplied Each Other

Security findings are often triaged one ticket at a time. That habit can understate combined authority. A weak password finding might be classified around the privileges visible in the test account. An IDOR might be classified around one unauthorized record. The real risk emerged from the path: the weak identity supplied a session, the admin workflow revealed the API shape, the IDOR supplied cross-record reach, and the response supplied both sensitive data and reusable tokens.

No individual step needed to provide total control. The system assembled it. This is why modern validation has to consider trajectories, even when the actor is a human researcher and the application is not an autonomous agent. The question is not merely whether the login was accepted or whether one API request was syntactically valid. It is whether the sequence stayed within the purpose and population approved for that identity.

Rate limits and enumeration alerts would have reduced the blast radius, but they are compensating controls. They should detect a caller walking record IDs in sequence, requesting an unusual volume, or collecting tokens. They cannot replace authorization. A slow attacker, a distributed attacker, or an attacker who targets selected people can remain below a volume threshold. Every object still needs an explicit allow decision.

The dormant account also shows why identity reviews must test effective access, not merely list accounts. "Test," "legacy," and "inactive" are descriptions, not controls. If an identity can authenticate and reach a production-linked workflow, it remains part of the live attack surface until the system expires or disables it.

By the Numbers

Potential scope and confirmed access are deliberately shown as different measures.

Exposure Scope Is Not the Same as Confirmed Impact

The strongest incident analysis separates what a flaw made possible from what evidence shows occurred. Overstate impact and the analysis becomes easy to dismiss. Understate reachable scope because no criminal was caught and the organization learns the wrong lesson. The table below keeps the categories separate.

Risk Severity Analysis

Severity should reflect the credible chain, not a sensationalized victim count. The primary controls below are ordered by how directly they enabled unauthorized access and how broadly they could affect the business.

The Vendor Operated the Platform. The Brand Still Owned the Trust.

McDonald's emphasized in public reporting that the platform was operated by a third-party vendor. That is a relevant technical fact, not a complete governance answer. Applicants encountered a McDonald's hiring process. Franchisees depended on McHire. Paradox built and operated the system. Each party held a different form of authority, and no party could protect the applicant alone.

The enterprise customer must validate the vendor's identity lifecycle, object-authorization design, logging, data minimization, vulnerability intake, incident response, and evidence of remediation. The vendor must build and operate those controls. Franchisees need roles limited to their legitimate candidates and tasks. The brand needs a way to see whether controls that protect people applying under its name remain effective over time.

Annual questionnaires are poorly matched to this risk. A test account can outlive a review. A new endpoint can introduce an IDOR between assessments. A response object can accumulate fields as product teams add features. Governance therefore needs recurring technical evidence: account inventories, expiry tests, authorization test results, access telemetry, data-flow changes, and closure proof for critical findings.

Paradox said it promptly remediated the vulnerabilities, committed to additional review, and later launched a bug bounty program. Those are constructive responses. The deeper standard is whether the organization can continuously demonstrate that the same class of authority failure cannot reappear elsewhere in the platform.

A Practical Action Plan

The response is not to abandon conversational hiring or to add a generic "AI security" control. It is to make authority explicit throughout the service. Identity, object, field, purpose, volume, and time are separate dimensions. A request clears only when the system can validate all of the dimensions that matter for the action.

Governance Checklist

Can your organization prove that one weak identity cannot become cross-record access in an AI-enabled service?

AuthorityGate 8-Gate Governance Mapping

McHire crossed identity, object, vendor, behavior, data, approval, and recovery boundaries. The eight gates work as a chain because no single control can cover that full path.