TL;DR: McDonald’s AI hiring platform McHire exposed millions of applicant records after researchers used default credentials and found no MFA, while an IDOR flaw enabled access to more than 64 million chat records, according to Unixi. The breach shows that basic identity controls still fail at scale when credential hygiene and object-level authorisation are weak.
At a glance
What this is: This is a breach analysis of McHire in which default credentials, missing MFA and an IDOR flaw combined to expose millions of applicant records and more than 64 million chat records.
Why it matters: It matters because IAM teams still cannot treat password hygiene, MFA and object-level authorisation as separate problems when a public-facing workflow is handling sensitive identity data.
Context
Default credentials and missing MFA remain a basic identity control failure, not a niche hygiene issue. When a public-facing application exposes administrative access through weak login controls, the organisation is relying on assumptions that no longer hold once the system is reachable from the internet.
In this case, the identity problem was compounded by an IDOR flaw that allowed access to chat records tied to applicants. That combination turns a login weakness into a data exposure event, because access control failed both at authentication and at object-level authorisation.
McHire is a useful example of how identity control gaps show up in AI-enabled hiring workflows. The starting position is typical of many exposed business applications, where convenience and rapid deployment outrun governance.
Key questions
Q: What breaks when credentials do not expire by default?
A: When credentials do not expire by default, access persists beyond the original business need and becomes harder to govern through ordinary reviews. The main failure is lifecycle drift: nobody can rely on the platform to age out the secret, so revocation, ownership, and accountability become manual tasks that are often delayed or missed.
Q: Why do missing MFA controls create outsized risk when attackers already have stolen login details?
A: Missing MFA matters because stolen credentials alone should not be enough to open support systems, admin consoles, or identity workflows. When MFA is absent or inconsistent, an attacker can turn a single password theft into broad visibility, session abuse, and lateral movement across connected services. MFA is not perfect, but it raises the cost of reuse and forces additional proof of identity.
Q: How should teams test for IDOR in systems that store personal data?
A: Teams should validate each object request against the caller’s actual entitlement, not just their session state. If a user can swap an identifier and retrieve another person’s record, the application has an authorisation failure. Testing needs to cover view, export, search and history functions, because IDOR often appears where record enumeration is easiest.
Q: Should organisations prioritise passwordless migration before fixing application authorisation gaps?
A: No. Passwordless reduces credential theft and reuse risk, but it does not repair broken object-level authorisation or insecure record handling. The safer sequence is to remove obvious login weaknesses, enforce MFA where passwords remain, and validate application-level access checks before assuming a new authentication method will change the outcome.
Technical breakdown
Default credentials as an administrative entry point
Default credentials are pre-set usernames and passwords that remain active when deployment, onboarding or hardening controls are weak. In this breach, researchers reportedly used the combination '123456' to gain administrative access. That is not sophistication, it is control failure: the application accepted a known secret as if it were proof of identity. In IAM terms, the system had no meaningful assurance that the party presenting the credential was entitled to the role it unlocked. Once an admin session is established, every downstream control depends on the integrity of that first authentication step.
Practical implication: remove all default credentials from externally reachable systems before production exposure.
Why missing MFA turns weak authentication into full compromise
Multifactor authentication adds a second proof step so that a stolen or guessed password is not enough on its own. Where MFA is absent, the security model collapses to one factor and attackers only need a single reusable secret. In this article, the lack of MFA allowed the administrative login to work with the default password alone. That makes authentication brittle even before any application bug is considered. For IAM teams, the lesson is that credential quality and MFA coverage are coupled controls, not independent ones. Weak passwords with no second factor create a predictable compromise path.
Practical implication: enforce MFA on privileged and public-facing administrative access, not just employee SSO.
IDOR and object-level authorisation failures
An Insecure Direct Object Reference, or IDOR, happens when an application exposes internal object identifiers and fails to verify that the caller is authorised for the specific record being requested. In this breach, that allowed access to more than 64 million chat records, including applicant names, email addresses and phone numbers. This is an authorisation failure, not an authentication failure. The login proved only that someone could enter the system; IDOR determined whether they could enumerate and read other people’s records once inside. That distinction matters because many breach reviews focus on login controls while leaving object-level access paths untouched.
Practical implication: test every record-fetching endpoint for object-level authorisation, not just authentication.
Threat narrative
Attacker objective: The objective was to gain privileged access to applicant records and related internal data through weak authentication and broken object-level controls.
- Entry occurred when researchers used the default username and password combination '123456' to reach administrative access.
- Credential abuse was amplified because MFA was not required, so the login accepted a single weak factor as sufficient proof.
- Escalation followed through an IDOR flaw that exposed more than 64 million chat records and related applicant data.
- Impact included broad exposure of personal information and evidence that stolen credentials dating back to 2019 had already appeared on internal devices.
Breaches seen in the wild
- Dropbox Sign breach 2024: A compromised back-end service account gave attackers Dropbox Sign customer data, including API keys, OAuth tokens and MFA information.
- Uber breach 2022: A contractor's stolen password and MFA fatigue gave a Lapsus$-linked attacker Uber's internal tools; Uber rotated keys to many services.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Default credentials are still a governance failure, not an implementation footnote. This breach worked because a public-facing system allowed a known password to stand in for identity assurance. Once an administrative account can be reached with a trivial secret, the rest of the control stack is already behind. Practitioners should treat default credential exposure as evidence that onboarding and hardening governance failed before an attacker ever touched the application.
Object-level authorisation is where many identity programmes actually break. Authentication may be enough to open the door, but IDOR decides which records are visible once inside. That means access policy, session context and per-object checks must be evaluated together, not as separate workstreams. The practitioner implication is simple: if your programme only measures login strength, it is missing the control that exposed the data.
Passwordless migration does not fix a weak authorisation model. Replacing passwords with passkeys or tokens reduces credential reuse and guessing risk, but it does not repair an application that exposes records through broken object references. The industry too often treats stronger authentication as the end state when the real problem is end-to-end access control. Teams should read this breach as proof that authentication modernisation and application authorisation hardening have to move in parallel.
AI-enabled hiring workflows widen the blast radius of basic IAM mistakes. The fact that this system handled applicant data inside a modern digital workflow did not change the fundamentals of identity risk. It did, however, increase the number of records and trust relationships exposed when the controls failed. Practitioners should assume that automation in hiring or onboarding amplifies the consequences of old credential habits, not that it eliminates them.
What this signals
Credential hygiene is now a programme-level control, not a user-behaviour problem. Teams should treat default password removal, MFA coverage and privileged access review as one governance chain. When any link is weak, the entire application becomes easier to enter and harder to contain.
This breach also shows why passwordless programmes must be paired with application authorisation testing. Stronger login methods reduce one class of compromise, but they do not stop exposed records if the application still trusts manipulated object identifiers.
The identity lesson is broader than hiring platforms. Any workflow that stores personal or operational data behind simple login logic can fail in the same way if authentication, authorisation and lifecycle control are managed as separate workstreams.
For practitioners
- Eliminate default credentials before internet exposure Inventory externally reachable applications, verify that every administrative and service account has a unique secret, and block deployment if any preset login remains active.
- Require MFA on privileged application access Apply MFA to administrative and support accounts that can reach production systems, especially where login portals remain password-based for users or operators.
- Test object-level authorisation on every sensitive endpoint Review record retrieval, export and chat-history endpoints for IDOR by validating that the caller is authorised for each object returned.
- Separate authentication hardening from authorisation remediation Track passwordless rollout, MFA coverage and object-level access testing as distinct controls so one improvement does not mask another gap.
Key takeaways
- McHire demonstrates that default credentials and absent MFA can still produce a straightforward path into privileged systems.
- The exposure extended beyond login failure, because IDOR allowed access to tens of millions of chat records tied to applicants.
- Teams should treat credential hardening, MFA rollout and object-level authorisation testing as linked controls, not optional layers.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10, OWASP API Security Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST SP 800-53 Rev 5 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-04 — Insecure Authentication | The breach began with a weak default login and no MFA, making authentication the first failed control. |
| NHI-01 — Improper Offboarding | Stale credentials dating back to 2019 indicate unmanaged identity lifecycle and persistence risk. | |
| Recommendation — Remove default credentials and require stronger authentication before exposing administrative interfaces. Revoke and retire stale credentials so dormant access paths cannot survive unnoticed. | ||
| OWASP API Security Top 10 | API1 — Broken Object Level Authorization | The IDOR flaw allowed access to records that the caller should not have been able to read. |
| Recommendation — Test every object-fetching endpoint for Broken Object Level Authorization before release. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Authenticator lifecycle and MFA enforcement are directly implicated by the weak credentials used here. |
| Recommendation — Apply IA-5 to manage, rotate and enforce stronger authenticators across privileged access paths. | ||
| MITRE ATT&CK | TA0006;TA0004 — Credential Access; Privilege Escalation | The attack relied on credential abuse to obtain elevated access to internal records. |
| Recommendation — Map exposed login paths to Credential Access and Privilege Escalation so detection focuses on account takeover. | ||
Key terms
- Default Credential: A default credential is a factory-set or preset username, password, or secret that remains unchanged after deployment. In NHI environments, it is a high-risk failure because it creates predictable access to privileged systems and often survives into production unless ownership and hardening are explicitly enforced.
- Multi-Factor Authentication: Multi-factor authentication requires two or more independent verification factors before access is granted. In practice, it reduces the chance that a stolen password alone will open a system, but it only works well when applied consistently across all high-risk access paths and identity types.
- Insecure Direct Object Reference: Insecure direct object reference is an access control flaw where an application exposes an identifier that allows callers to reach records or objects they should not be able to access. In practice, it means the system trusts the request too much and fails to verify object-level permission on each access.
- Passwordless Authentication: An authentication approach that removes passwords and uses a device-bound cryptographic key plus local user verification. It reduces phishing and replay risk, but it only improves assurance when enrollment, recovery, and revocation are tightly governed.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.
Published by the NHIMG editorial team on August 2, 2026.
Updated on October 12, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org