McHire breach shows default credentials still break identity controls

At a glance

What this is: McHire exposed millions of applicant records because default credentials, missing MFA, and an IDOR flaw left the platform open to administrative access and broad data exposure.

Why it matters: IAM teams should treat this as a reminder that human-facing identity controls, API authorisation, and credential hygiene all fail together when one layer is left weak.

By the numbers:

• more than 64 million chat records including sensitive applicant information such as names, email addresses and phone numbers
• 88 percent of attacks against basic web applications involved the use of stolen credentials

👉 Read Unixi's analysis of the McHire breach and credential failure chain

Context

The primary identity failure here was not sophisticated exploitation but weak access control. Default credentials, no MFA, and an IDOR weakness together turned a hiring platform into a broad data exposure event, which is a familiar pattern whenever authentication and object-level authorisation are treated as separate problems.

For IAM practitioners, the lesson cuts across human identity, application access, and non-human identity governance. When a business workflow depends on browser-based access, the organisation still needs strong authentication, least privilege, and auditability at every step, including administrative access paths and API-driven record retrieval.

Key questions

Q: What breaks when a platform still relies on default credentials?

A: Default credentials destroy the trust boundary before any deeper control can help. Attackers can reach administrative functions without needing phishing, malware, or a known exploit. Once that happens, MFA, logging, and monitoring become damage-limitation controls rather than preventive ones. The practical answer is to eliminate default access paths entirely before a system reaches production.

Q: Why do weak credentials and IDOR create a larger breach than either flaw alone?

A: Weak credentials open the door, but IDOR determines how far the attacker can move once inside. A valid session should still be restricted to the specific object or record it is allowed to access. When object-level checks are missing, one compromised login can expose millions of records instead of a single account.

Q: How do security teams know if API authorisation is actually working?

A: They should test whether each identity can only complete the specific actions it is supposed to perform, then compare that result with runtime logs and anomaly patterns. If valid credentials can still retrieve excessive data, call restricted methods, or chain privileged actions, the policy is not holding.

Q: Who is accountable when applicant data is exposed through weak identity controls?

A: Accountability usually sits with the application owner, the identity team, and the security function together because the failure spans authentication, authorisation, and lifecycle governance. If default credentials remain active or MFA is not enforced, the organisation has accepted preventable exposure. Compliance reviews should map that responsibility to the control owner, not only to incident response.

Technical breakdown

Default credentials and missing MFA

Default credentials collapse access assurance before any deeper control can help. If a system ships or remains configured with predictable credentials, attackers do not need phishing, malware, or advanced exploit chains to reach an administrative session. MFA is the compensating control that raises the cost of simple credential reuse, but it only works when it is enforced on all privileged paths. In this case, administrative access was obtained through a weak username and password combination, which means the platform failed at the first gate rather than at the detection layer.

Practical implication: remove default credentials from every production path and require MFA on all privileged access.

IDOR and object-level authorisation failure

An insecure direct object reference, or IDOR, occurs when an application exposes internal object identifiers and fails to verify whether the authenticated user is allowed to access the referenced record. This is a separate control problem from login security. Even with valid access, the application must still enforce record-level authorisation on every request. When that check is missing, an attacker can move from one permitted object to many unauthorised ones by changing identifiers, which is why application-layer access control is as important as authentication.

Practical implication: enforce per-object authorisation checks and test whether record identifiers can be manipulated to expose other users' data.

Stolen credentials and long-lived compromise

The mention of malware and credentials dating back to 2019 suggests that exposed or reused credentials can persist long after their original compromise. This is the classic long-tail credential problem: once a credential is stolen, every system that still trusts it remains exposed until the credential is revoked or rotated. That risk is not limited to human users. Any shared account, service credential, or admin token that survives across years extends the attack window and complicates incident scoping.

Practical implication: inventory legacy credentials, revoke anything that has outlived its purpose, and bind rotation to account ownership.

Threat narrative

Attacker objective: The attacker’s objective was to obtain broad access to applicant records and related internal data by abusing weak identity controls.

1. Entry occurred through predictable default credentials, allowing administrative login without needing a phishing or exploit campaign.
2. Escalation followed because the lack of MFA and weak access checks let the attacker navigate beyond the intended user boundary.
3. Impact came from IDOR-enabled access to millions of chat records and applicant details, expanding the breach beyond a single account compromise.

Breaches seen in the wild

• MongoBleed breach — MongoBleed exposed secrets across 87K MongoDB servers.
• IOS app secrets leakage report — iOS apps leaking hardcoded secrets and credentials endangering user privacy.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Default credentials are not a convenience problem. They are an identity assurance failure. The breach worked because the system trusted a credential pattern that should never have reached production. Once default access exists, MFA becomes a partial mitigation rather than a baseline control, and the organisation has already accepted avoidable identity risk. The practitioner conclusion is simple: if default credentials still exist, the access model is already broken.

IDOR shows that authentication is not authorisation. A valid login does not mean a user can reach every object behind that session, yet many programmes still treat those as the same control layer. This breach shows that record-level checks must be enforced independently of login success, especially in platforms handling applicant or customer data. The practitioner conclusion is to test object access, not just login strength.

Long-lived credential residue creates hidden exposure windows. The reference to stolen credentials dating back to 2019 shows how old access artefacts keep creating present-day risk. That is a governance problem, not just a detection problem, because dormant or forgotten credentials remain trusted until they are actively removed. The practitioner conclusion is to treat credential retirement as a lifecycle control, not a cleanup task.

Credential hygiene is the common failure mode across human access, application sessions, and shared secrets. The same weak trust assumption can expose employees, applicants, and internal services if identity governance is fragmented. Passwordless adoption may reduce one part of the problem, but the broader issue is whether every privileged path is continuously governed. The practitioner conclusion is to align authentication, authorisation, and lifecycle review in one control model.

From our research:

• From our research: 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, according to The State of Non-Human Identity Security.
• 45% of organisations cite lack of credential rotation as the top cause of NHI-related attacks, according to the same research.
• For lifecycle context, see NHI Lifecycle Management Guide for how provisioning, rotation, and offboarding reduce long-tail access risk.

What this signals

Default credentials and weak object checks are still the fastest route from ordinary access to major exposure, which means identity teams need to treat application authorisation as part of the access stack rather than as a separate engineering issue. Passwordless adoption can help, but only if it is paired with stronger control over administrative paths and record-level access.

The governance gap is increasingly about control coverage, not awareness. Organisations that still tolerate stale accounts, shared secrets, or inconsistent MFA enforcement will keep finding that one weak login can become a data breach with very little attacker sophistication.

For practitioners building the next phase of their programme, the right question is not whether identity controls exist, but whether they actually constrain every object, session, and credential lifecycle. The closest analogue in our research is the NHI lifecycle problem, where access outlives the business purpose that created it.

For practitioners

• Eliminate default access paths before launch Inventory every admin, support, and break-glass account, then remove any default username and password combinations from production systems and test environments.
• Require MFA on all privileged workflows Apply MFA to administrative logins, support consoles, and any browser-based workflow that can retrieve applicant, customer, or internal records.
• Test for object-level authorisation failures Run IDOR testing against record identifiers, session-bound APIs, and export functions to confirm that changing an object reference never exposes another subject’s data.
• Retire stale credentials on a fixed lifecycle Set an ownership model for every credential, then revoke or rotate secrets that have remained valid beyond the business purpose that created them.

Key takeaways

• McHire failed at the identity layer first, because default credentials and missing MFA gave attackers a path into administrative access.
• The scale mattered because an IDOR flaw turned one weak login into access to more than 64 million chat records and applicant details.
• The control that would have mattered most was not just stronger login security but enforced object-level authorisation and credential lifecycle cleanup.

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.
• 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.
• Credential Hygiene: Credential hygiene is the discipline of creating, storing, using, and separating passwords and secrets in a controlled way. It includes avoiding reuse, keeping work and personal accounts separate, and making the governed path easy enough that people do not work around it.

What's in the full article

Unixi's full article covers the operational detail this post intentionally leaves for the source:

• The exact McHire attack path and the sequence researchers used to reach administrative access.
• The full explanation of the IDOR weakness and how it exposed applicant chat records at scale.
• The article's discussion of passwordless access and the vendor's product context for browser-based applications.
• The additional references to malware and stolen credentials dating back to 2019.

👉 Unixi's full post covers the breach mechanics, IDOR exposure, and the passwordless access context.

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 building or maturing an IAM programme, it is worth exploring.