When the AI wasn't the weak link: the McHire applicant data exposure

What happened

In June 2025, security researchers Ian Carroll and Sam Curry disclosed a vulnerability chain in McHire, the McDonald's hiring platform built by Paradox.ai and used by the vast majority of McDonald's franchises. Public reporting from Wired and BleepingComputer puts the exposed dataset at roughly 64 million job applicants, with names, email addresses, phone numbers, and chat transcripts accessible to anyone who took the same path the researchers did.

The headline that travelled fastest framed this as a prompt-injection attack on the chatbot "Olivia". That framing is wrong. The researchers say they did try prompt injection first, and it failed: the bot was tightly constrained to canned responses and never had backend data it could be tricked into leaking. The compromise had nothing to do with the language model.

The actual entry point was a Paradox.ai administrative login page on McHire, reachable from the public internet. The researchers tried the credentials "123456" / "123456" on a test account that, according to public reporting, had been left active since 2019. They got in.

Once inside, a classic Insecure Direct Object Reference (IDOR) on the applicant API let them increment a numeric ID and pull any applicant's record. No exploitation of the model, no novel technique, no zero-day. Default credentials plus an unauthenticated object reference.

Why this pattern keeps repeating

The interesting failure here is not technical, it is organisational. The chatbot was the visible, "AI" component, so it absorbed the security attention. The boring web admin behind it was the actual blast radius, and almost no one was looking at it that way.

This happens whenever a buyer treats an AI vendor as an AI product rather than as a SaaS application that happens to contain a model. The model gets a red-team review. The admin console, the applicant API, the storage bucket, the audit logging, the credential rotation policy — the things that have decades of known failure modes — get treated as plumbing.

The supplier incentive structure reinforces it. AI vendors ship fast, often before they have a mature security program, and their customers' procurement teams ask about model behaviour rather than about the surrounding application. A test account from 2019 with the password "123456" survives that gap for years because nobody scoped the review to find it.

The most expensive AI breaches of the next two years will not be model exploits. They will be 1990s-era web vulnerabilities in the application wrapped around the model.

The attacker's playbook step-by-step

The disclosed sequence was short, and that is the uncomfortable part. A skilled attacker did not need a chain of novel primitives.

Step 1: enumerate the AI vendor surface

Identify the third-party vendor behind the visible chatbot. In this case the bot identified itself as built by Paradox.ai, which pointed at a separate administrative surface — a login page on the same McHire domain.

Step 2: try the obvious credentials

Default and weak credentials remain the highest-yield attack against vendor admin panels. Reporting indicates a single test account with "123456" / "123456" was enough.

Step 3: pivot from admin to data

The admin role exposed an internal applicant API. The API used a sequential numeric identifier and did not check that the calling account was authorised to read each specific applicant. Iterating the ID returned arbitrary records.

Step 4: confirm scope and disclose

The researchers stopped at proof-of-impact, validated the size of the dataset, and reported to Paradox.ai and McDonald's. Paradox.ai disabled the test account and reportedly fixed the IDOR within hours of disclosure.

What defenders missed

Three things, in roughly decreasing order of severity.

First, no credential hygiene on the vendor's admin surface. A test account that predated the production deployment, with a six-character numeric password, was reachable from the public internet five years after it was created. Any periodic credential audit would have found it.

Second, no authorisation check on the applicant API. IDOR is one of the oldest, most well-documented web vulnerabilities in the OWASP catalogue. The fact that an authenticated admin call returned arbitrary applicant records means the API enforced authentication but not authorisation.

Third, no security review of the boring surface. The chatbot got attention because it was the AI. The admin login, the API gateway, and the storage of 64 million PII records did not get the same scrutiny — at McDonald's, at Paradox.ai, or at the franchisees who deployed McHire.

A practical defensive checklist

The fixes are unglamorous. They are also what would have prevented this incident.

• Inventory every authentication surface exposed by any AI vendor you use, including admin panels, test environments, and customer-support tools. Treat them like crown-jewel web apps, not like plumbing for the model.
• Require vendors to attest, in writing, that no default or shared credentials exist in production, and that test accounts created during onboarding are deleted at go-live.
• Run authenticated IDOR/BOLA tests against every API the vendor exposes, especially APIs that return per-user records. OWASP API Security Top 10 ranks this #1 for good reason.
• Force SSO with your identity provider for every vendor admin surface, so credentials cannot drift independently and old accounts die when employees leave.
• Cap admin session privileges so a single compromised admin account cannot enumerate the entire applicant or customer dataset.
• Require the vendor to log and alert on bulk-read patterns against sensitive APIs. Pulling tens of millions of applicant records should not look the same as a normal day.

How modern offensive testing would have caught this

A scoped, authorised offensive engagement against the McHire vendor surface — not against the chatbot — would have found this in the first afternoon. The relevant checks are well-trodden: credential-spray against the admin login, authenticated horizontal access control on every parameterised API, and review of test accounts and reset workflows.

The model itself does not need a red team in this story. The model behaved correctly. The chatbot's guardrails held. The lesson is that a thorough application security review of the wrapping product would have flagged every step of the kill chain before it was ever live.

What to watch next

Expect more of this. AI vendors are absorbing more sensitive workflows — hiring, claims, customer service, scheduling — and the backend administrative consoles around those workflows now hold concentrations of regulated personal data that previously sat in less reachable systems.

Two things to watch in your own programme: which AI vendors hold the highest concentration of regulated personal data on your behalf, and what your contractual right to test their admin surface looks like. If you cannot run an authenticated application security review against the vendor's panel, you are trusting that the next test account was deleted, the next API enforces authorisation, and the next default password was rotated. The McHire disclosure shows what happens when that trust is misplaced.