Why 2026’s Biggest Breaches Started With a Password, Not a Hack

Three of the largest security stories of 2026 have almost nothing in common on the surface — a cloud data platform, a learning management system used by thousands of schools, and a Japanese telecom’s shared email infrastructure — yet all three trace back to the same root cause. The Snowflake hacker’s guilty plea confirmed the 2024 campaign reached at least 165 organizations and exposed records tied to over 100 million people, achieved entirely through stolen, unrotated credentials on accounts with no multi-factor authentication; Instructure paid a ransom to stop a leak of roughly 275 million Canvas user records, only for the attackers to publish the data anyway; and KDDI disclosed that a single third-party software flaw in shared email infrastructure exposed up to 14.22 million accounts across six separate internet service providers at once. None of these three incidents required a sophisticated zero-day. Every one of them started with access, not exploitation.

At Webtoz, this is exactly the kind of risk our technology consultancy engagements are built to surface, closely tied to the architectural rigor behind custom software development and the trust boundaries any serious system needs.

This guide covers what actually happened in the Snowflake, Instructure, and KDDI breaches, what all three genuinely have in common despite looking unrelated, why paying a ransom doesn’t guarantee the data stays private, and what least-privilege access control and technical due diligence actually look like when implemented properly rather than as a compliance checkbox.

1. Three Breaches, One Root Cause

Security researchers looking back across 2026’s breach reporting keep landing on the same uncomfortable observation: the year’s most consequential incidents weren’t won with novel exploitation techniques. Credential compromise, phishing, and third-party or supply-chain access account for the majority of this year’s largest breaches by records exposed, a pattern that holds true whether the entry point was old infostealer-harvested passwords, a support-ticket vulnerability in a free tier product, or a flaw in software a vendor didn’t even know it was running. That’s a genuinely different problem than a zero-day, and it calls for a genuinely different kind of defense.

It’s worth being precise about why this distinction matters so much in practice. A zero-day is largely outside a victim organization’s control — you patch as fast as you reasonably can once one is disclosed, and there’s a real limit to how much faster that process can go. Credential-based access, by contrast, is preventable with controls that have existed for years: multi-factor authentication, credential rotation, and least-privilege scoping. When breaches of this scale keep happening through these avenues anyway, it points to a gap in operational discipline, not a gap in available technology.

2. The Snowflake Hacker’s Guilty Plea

Connor Riley Moucka’s guilty plea in federal court closed the legal chapter on one of the most consequential cloud data theft campaigns on record, and the technical details underlying the case are worth sitting with. Moucka and his co-conspirators reached at least 165 organizations and exposed records tied to at least 100 million people, entirely through credentials that had been harvested by infostealer malware years earlier, never rotated, on Snowflake customer accounts that simply didn’t have multi-factor authentication enabled — there was no exploit and no flaw in Snowflake’s own platform at any point in the campaign. The group collected more than $2.5 million in ransom payments and caused victim companies upwards of $9.5 million in direct losses, with publicly linked organizations including AT&T, Ticketmaster, Santander, and LendingTree among others.

Perhaps the most telling detail in the entire case is how avoidable it was on paper. Multi-factor authentication was available, well understood, and simply not switched on for the affected accounts. Snowflake has since moved to enforce MFA by default for new accounts and is rolling out a phased mandate for all remaining human and service accounts, but the years-long gap between “this control exists” and “this control is actually enforced everywhere” is exactly where a breach of this scale became possible.

3. Instructure and Canvas: Paying Wasn’t the Ending

The Instructure Canvas breach illustrates a different but related lesson — this time about what a ransom payment actually buys, and what it doesn’t. After attackers linked to the ShinyHunters group breached Instructure’s systems and claimed roughly 275 million records across nearly 9,000 institutions, Instructure paid a ransom shortly before the attackers’ deadline specifically to prevent the data from being published — and reporting indicates the group leaked or continued threatening exposure of the data regardless, undermining the entire premise that payment guarantees silence. The exposed data included names, email addresses, student ID numbers, and — perhaps most sensitive of all — private messages exchanged between students, teachers, and parents.

This sequence exposes the structural weakness in ransom payments as a security strategy: by the time an organization even discovers a breach has occurred, the data has typically already been copied. A payment buys a promise from a criminal organization not to publish data it has already exfiltrated, and that promise carries no enforcement mechanism whatsoever. Re-extortion — a criminal group returning to a victim who already paid, and demanding payment again — is a pattern security researchers have documented with increasing frequency, and it works precisely because the leverage never actually goes away once data has left an organization’s control.

4. KDDI: One Flaw, Six ISPs

KDDI’s breach adds a third dimension to this pattern: third-party and shared-infrastructure risk, where a single point of failure multiplies across every organization that depends on it. KDDI operates a shared email platform used by six separate Japanese internet service providers — STNet, J:COM, Chubu Telecommunications, NIFTY, BIGLOBE, and KDDI Web Communications — and when attackers exploited a vulnerability in unnamed third-party software integrated into that shared system, the resulting exposure of up to 14.22 million email addresses and passwords hit every one of those six providers’ customer bases simultaneously, even though none of the ISPs themselves had a flaw in their own systems. KDDI detected the intrusion on June 17, 2026, and notified Japan’s Personal Information Protection Commission the same day, though the exact split between hashed and plaintext-stored passwords hasn’t been fully disclosed.

The architecture itself is the risk factor here as much as the underlying software flaw. Shared infrastructure is efficient — one platform serving six ISPs instead of six separately built systems — but it also means a single vulnerability, in software none of the six ISPs directly controlled or audited themselves, became a breach affecting all of their customers at once. That’s a direct illustration of why third-party and supply-chain risk assessment can’t stop at “does our own code have vulnerabilities” — it has to extend to every shared dependency an organization’s data actually flows through.

5. What These Breaches Have in Common

Even where a technical flaw was involved, as with KDDI, the underlying pattern is the same: access and trust boundaries, not sophisticated exploitation, determined how far each breach ultimately spread. A well-scoped, least-privilege architecture would have limited the blast radius in every one of these three cases, regardless of exactly how the initial access was gained.

6. Why “Logged In, Not Hacked” Keeps Happening

It’s worth asking directly why organizations with real security budgets and real security teams keep experiencing breaches through avoidable access-control gaps rather than sophisticated attacks. The honest answer is that access control is unglamorous, ongoing operational work rather than a one-time project — enforcing MFA across every account, rotating credentials on a real schedule, and scoping third-party access tightly all require sustained discipline long after the initial rollout, and it’s exactly the kind of control that quietly erodes over time as new accounts get created, new vendors get onboarded, and nobody circles back to audit whether the original access-control decisions still hold.

Zero-days get headlines and dedicated incident response playbooks precisely because they’re dramatic and unpredictable. Credential and access-control failures rarely get the same attention internally, specifically because they feel mundane and preventable — right up until they’re the reason a company’s name appears in a breach disclosure alongside 100 million exposed records.

7. Least-Privilege Access Control That Actually Works

Genuine least-privilege architecture goes considerably further than simply requiring a password and calling it done. It means every account, human or service, has multi-factor authentication enforced without exception, credentials get rotated on a real cadence rather than only after an incident forces the issue, third-party and vendor access is scoped tightly to exactly what a specific integration needs rather than broad standing access, and every privileged connection — the kind that let one flaw expose six ISPs’ worth of customers at once — is treated as a genuine risk surface requiring its own audit, not an implementation detail nobody revisits. This is precisely the kind of technical due diligence our technology consultancy engagements are built around.

8. Common Mistakes

These mistakes recur across nearly every access-control-driven breach, including all three covered above.

• Treating MFA as optional or opt-in: Leaving it available but not enforced across every account that touches sensitive data.
• Never rotating credentials proactively: Only rotating passwords and keys after a breach forces the issue.
• Granting broad, standing access to vendors: Giving third parties more access than a specific integration genuinely requires.
• Assuming a ransom payment guarantees data stays private: Treating payment as a resolution rather than a gamble with no enforcement mechanism.
• No audit of shared or third-party infrastructure: Only assessing risk in systems an organization directly controls, not what it depends on.
• Deprioritizing access control behind more visible security work: Investing in perimeter defenses while access-control discipline quietly erodes.

9. Final Thoughts: Access Control Is the Whole Game

A hundred million people’s data exposed through unrotated passwords. Two hundred and seventy-five million records leaked despite a paid ransom. Fourteen million accounts compromised because six companies shared one platform with an unaudited flaw. None of it required a brilliant attacker or a novel technique — it required an organization somewhere along the chain to leave a door unlocked, and it’s a pattern that will keep repeating for as long as access control gets treated as a one-time setup task instead of ongoing operational discipline. The organizations that avoid becoming next year’s version of this story are the ones auditing their access boundaries now, not the ones waiting for a guilty plea to make the lesson unavoidable.

Want a genuine technical due diligence review of your access control and third-party exposure? Explore our technology consultancy services, review our pricing, or contact us to discuss where your access boundaries actually stand.