The AI hiring chatbot, a forgotten test account and the password 123456

McHire is a hiring chatbot, called Olivia, built by Paradox.ai and used for McDonald's job applicants in the US. Applicants chat with it, give their contact details and availability, and are moved through the hiring process.

Security researchers Ian Carroll and Sam Curry looked at it in June 2025. On the sign-in page they found a small link for Paradox team members. They tried the username and password 123456, and it worked. It made them the administrator of a test restaurant inside McHire, whose only staff were Paradox employees.

They reported it to Paradox and McDonald's on 30 June 2025. According to the researchers' timeline, the credentials stopped working that evening, and Paradox confirmed the issues were resolved on 1 July. Paradox published its own account on 9 July.

The password was the first fault. Paradox says the test account had not been logged into since 2019, its password had never been changed, and it should have been decommissioned.

The second fault mattered more. From inside the test account, the researchers applied to one of its test jobs and watched the requests the system made. One internal API call took an applicant ID number. Lowering that number returned other applicants' records. This is called an insecure direct object reference: the system checked that someone was signed in, but not whether that person was allowed to see that particular record.

Either fault alone would have been contained. A forgotten account with no route to real data is untidy; a record lookup with no permission check is serious but needs a way in. Together they connected a test restaurant to real applicants.

The researchers wrote that the flaw allowed anyone to retrieve the personal data of more than 64 million applicants, including name, email address, phone number, address, where the candidate was in the process and their form answers, along with a token that gave access to their chat messages.

That is a measure of what was exposed, not of what was taken. Paradox says the researchers pulled down seven chat interaction records, five of which were for US-based candidates, and that the data involved was names, email addresses, phone numbers and IP addresses, with no Social Security numbers. Paradox also says no other client was affected.

Both statements can be true. The lesson does not depend on which number you prefer: an organisation found out from outsiders that an old account could reach every applicant it had.

Paradox's blog post was direct: “We take responsibility for this issue. Full stop.” It revoked the test credentials, patched the API within hours, and launched a bug bounty programme with a security contact for researchers.

McDonald's told the press it was disappointed by an unacceptable vulnerability from a third-party provider, and that the issue was resolved the day it was reported. That is a fair description of the fix, but the applicants were McDonald's applicants, the chatbot carried McDonald's name, and the coverage was about McDonald's. Using a vendor moves the work. It does not move the reputational risk.

On 17 July 2025 KrebsOnSecurity reported that information-stealing malware had infected a Paradox administrator's device in Vietnam at the end of June 2025, and that the stolen data showed weak, reused passwords for Paradox accounts linked to several other large clients. Paradox confirmed the infection to Krebs.

That report is separate from the McHire flaw and we do not know what, if anything, was done with the stolen data. We mention it because it points the same way: the risk around an AI product often sits in the ordinary accounts and passwords of the people who run it.

None of this needs specialist AI security. It needs someone to write down what the system can reach and test it on purpose.

First, list every account that can sign in to the AI system, including the vendor's support and test accounts, and remove any nobody uses. A test account last used in 2019 should not exist in 2025.

Second, no shared, default or guessable passwords on administrator access, and multi-factor sign-in wherever the system allows it. Ask the vendor how its own staff sign in, not only how yours do.

Third, test access to records, not just access to the system. Sign in as one user and try to read another user's record by changing an ID. It is the oldest test in web security and the one that failed here.

Fourth, ask the vendor for evidence rather than a promise: when the system was last tested by someone independent, what was found, and whether there is a route for outside researchers to report problems. Paradox only launched a bug bounty after this incident.

Fifth, agree in writing who tells whom, and how fast, when something goes wrong. Here the researchers chose to tell both companies at once. You cannot rely on that.

If an AI tool handles personal data for you, such as applicants, patients or customers, you are usually the controller and the vendor is your processor. UK GDPR Article 28 says you may only use processors that give sufficient guarantees to implement appropriate technical and organisational measures. Asking the questions above is how you show you checked.

Our AI Control Review looks at one AI workflow in a day: what it can access, what it can change, where a person must approve an action and what evidence remains. It is an engineering review, not a certification, and it is the kind of check this incident shows is worth doing before someone else does it for you.