64 Million Job Applicants Exposed Because the Password Was "123456"

Two security researchers wanted to test McDonald's AI hiring chatbot. They started the way you'd expect, by trying to trick the AI itself into misbehaving. That didn't work; the chatbot held up fine. So they poked around the rest of the site and noticed a login link for the vendor's staff. On a whim, they tried the username and password "123456."

They were immediately logged in, with administrator access, no second factor, no lockout. From there, a second simple flaw let them page through applicant records one by one. In a security review that took a few hours, they found they could reach the personal data of as many as 64 million people who had applied for jobs at McDonald's: names, contact details, and their full chat transcripts with the hiring bot.

Here's the most important sentence in this entire article: the AI did not fail. The chatbot worked exactly as designed. What failed was the ordinary, boring security around it, a forgotten test account and a decade-old password. And that is precisely why this case matters for any business buying an AI tool.

What happened

McDonald's, like many large employers, uses an AI-powered hiring platform to handle the flood of applications. The platform, called McHire, was built by a vendor, Paradox.ai, and features a chatbot named Olivia that collects applicants' information and walks them through the early steps of applying. It's used across a large share of McDonald's franchises, which is how a single weakness could touch tens of millions of records.

The researchers, Ian Carroll and Sam Curry, first tried prompt-injection attacks on Olivia, the kind of jailbreak that has embarrassed other companies' bots. Olivia resisted. The AI layer was not the weak point.

The weak point was mundane in the extreme. The site had a login for the vendor's own team members. It accepted "123456" as both username and password. It had no multi-factor authentication. And behind it sat not just a harmless test area but live administrative access. The account, the vendor later acknowledged, hadn't been used since 2019 and should have been decommissioned years earlier. Once inside, the researchers hit a second common flaw, a system that let them retrieve other people's records simply by changing an ID number in the web address, and the full scale of the exposure opened up.

To their credit, the researchers disclosed responsibly rather than exploiting it, and both companies fixed the flaws within about a day. But the theoretical exposure covered essentially every application the system had ever handled.

Why "the AI worked" is the whole point

It would be easy to lump this in with the other AI horror stories, but that misreads it, and the misreading is dangerous. Nothing about the artificial intelligence went wrong here. No hallucination, no rogue agent, no jailbreak. The chatbot did its job.

The failure was in the plumbing: account management, password policy, access controls, basic web security, the same fundamentals that protect any piece of software handling sensitive data. The lesson is that slapping "AI" on a product does not make its security any better than any other vendor's software, and it does not exempt it from the due diligence you'd apply to anything else touching your customers' or applicants' data.

This is the trap: AI products get evaluated on their AI. Buyers get excited about the model, the capabilities, the demo, and forget to ask the unglamorous questions they'd ask any other software vendor. How are accounts managed? Is multi-factor authentication enforced? Who has access to the data, and where does it live? How are old test accounts retired? A dazzling AI capability sitting on top of 2019-grade security hygiene is exactly what produced a 64-million-record exposure.

The part that makes this your problem

Notice whose name is in the headlines. The security hole was in the vendor's system, but the exposed data belonged to people who applied to McDonald's, and it's McDonald's, along with its franchisees, that carries the reputational and regulatory weight. When you deploy a vendor's AI tool and feed it your customers', applicants', or employees' data, that vendor's security failures become your breach. The public doesn't distinguish between you and your subcontractor. Regulators increasingly don't either.

Most mid-market businesses are now being pitched AI tools constantly, hiring bots, customer-service bots, intake systems, analytics platforms, each of which wants to be fed sensitive data. Every one of those vendors is a potential version of this story. The excitement around AI is causing a lot of organizations to onboard these tools far faster than they'd ever onboard a traditional software vendor, and with far less scrutiny.

How to buy an AI tool without inheriting its breach

Run the same security due diligence you'd run on any vendor. An AI product is a software product. Ask about penetration testing, credential and password policies, multi-factor authentication, encryption, and data handling. The AI capability is not a reason to skip these questions; if anything, the volume of sensitive data these tools ingest is a reason to ask harder.

Ask specifically about account lifecycle. This breach came through a forgotten account that should have been shut off years earlier. Ask any AI vendor directly how test and administrative accounts are created, monitored, and decommissioned, and whether multi-factor authentication is mandatory on every one. A vague answer is itself a finding.

Know where your data goes and who can reach it. Before you hand a tool your applicants' or customers' information, understand where that data is stored, who at the vendor can access it, and what happens to it if you stop using the product. Data you can't account for is data you can't protect.

Minimize what you feed it. The more sensitive data a tool collects and retains, the bigger the blast radius when something goes wrong. Push vendors on why they need each field, and limit the tool to the minimum information required to do its job. The safest record in a breach is the one that was never collected.

The real lesson

We help businesses adopt AI, and a large part of that work is unglamorous: evaluating vendors, checking how data is handled, making sure the security fundamentals are in place before a single record flows in. It's not the exciting part of AI. It's the part that keeps an exciting AI project from becoming a breach notification.

Sixty-four million people's data sat behind the password "123456" because a sophisticated AI product was treated as though its intelligence excused it from basic security. It doesn't. An AI tool is a software vendor with a data footprint, and it deserves every hard question you'd ask any other company you trust with the people who rely on you. Ask them before you sign, not after the researchers or the attackers find the answer for you.