New Zealand's Manage My Health portal connects roughly 1.8 million New Zealanders to around 355 medical practices. It holds the most sensitive data a person can have on file: lab results, specialist referrals, discharge summaries, imaging reports, prescriptions and clinical correspondence. At the end of December 2025, an attacker using the alias "Kazu" announced they had taken a copy of a huge slice of it.
What makes this breach worth studying isn't its sophistication. It's the opposite. As New Zealand's Privacy Commissioner later concluded, this wasn't an elite nation-state operation—it was a combination of ordinary, avoidable security weaknesses. The kind that exist in a great many production systems right now.
The Office of the Privacy Commissioner found the breach affected nearly 100,000 people, though early estimates from the company ran as high as 120,000–127,000 patients—about 6–7% of its user base. Around 86,000 of those affected were in the Northland region, across roughly 50 general practices. Some of the stolen files dated back to 2017.
What Actually Happened
According to the company, the attacker didn't break a lock—they used a key. The CEO described it as someone coming "through the front door" using a valid user password. But a valid login should never have been enough to reach hundreds of thousands of other people's records. That's the part that turned a single compromised account into a national incident.
A Single Valid Credential
The attacker authenticated to the portal using legitimate-looking credentials. The portal lacked multi-factor authentication, so a username and password were the only barrier to entry. Once inside, the session was trusted.
One Account, Everyone's Documents
The document-storage module did not properly enforce who a given account was allowed to read. The Privacy Commissioner's inquiry pointed to safeguards that let a single account reach far beyond its own data—the textbook signature of broken access control.
428,337 Files, Then a Ransom
The attacker downloaded 428,337 files totalling roughly 108 GB, then demanded a US$60,000 ransom, threatening to publish the data on the dark web. New Zealand's High Court granted interim injunctions in early January 2026 to restrain dissemination.
The Real Failure: Broken Access Control
It's tempting to read "they used a valid password" and conclude this was a credential problem. It wasn't—at least not primarily. Stolen and phished credentials are a constant. Any system holding sensitive data must assume that, sooner or later, some account will be compromised. The question that decides whether that becomes a footnote or a front-page headline is: once authenticated, what is that account actually allowed to touch?
This is Broken Object Level Authorization (BOLA)—also known as IDOR (Insecure Direct Object Reference). It is the number one risk on the OWASP API Security Top 10 for a reason: it's everywhere, it's invisible until exploited, and it's devastating. The pattern looks like this:
# The vulnerable pattern: authentication without authorization
GET /api/documents/482193 Authorization: Bearer <valid-token>
# Server checks: "Is this a valid, logged-in session?" -> YES
# Server FAILS to check: "Does THIS user own document 482193?"
# Returns the document. Increment the ID. Repeat 428,337 times.The fix is conceptually simple and operationally relentless: every single object access must verify ownership, not just authentication. The user reading document 482193 must be provably entitled to that document. Authentication answers "who are you?" Authorization answers "what are you allowed to see?"—and skipping the second question is how 100,000 people's records leave the building behind one login.
You can reissue a leaked credit card. You cannot reissue a person's mental-health history, HIV status, pregnancy records, or cancer diagnosis. Medical data is permanent, deeply personal, and uniquely useful for extortion, discrimination and targeted fraud. When the asset can never be "rotated," prevention is the only real control you have.
What the Privacy Commissioner Found
In its Phase 1 findings, the Office of the Privacy Commissioner concluded that both Manage My Health and Health New Zealand had breached Rule 5 of the Health Information Privacy Code—the obligation to ensure reasonable security safeguards for patient information. Crucially, the Commissioner stated that no single failure caused the breach; it was a combination of security weaknesses.
That combination reportedly included:
- No multi-factor authentication on a portal holding national-scale medical records
- Insufficient access controls that allowed one account to reach data well beyond its own
- Gaps in monitoring—an account pulling hundreds of thousands of documents did not trip an alarm in time
- Data-retention issues, with records reportedly continuing to flow from some practices after their contracts had ended
Perhaps the most uncomfortable detail: the risks weren't unknown. A university cybersecurity researcher had publicly flagged the absence of MFA and the exposure of unencrypted files two years earlier, and the Privacy Commissioner had separately warned the company of security risks roughly six months before the breach. The Commissioner has since signalled intent to issue compliance notices and to push for the Ministry of Health to verify that patient portals meet sector security standards. New Zealand's privacy regulator is also lobbying for the power to levy multi-million-dollar fines—a regime the country has historically lacked.
Why This Matters for Your Platform
You may not run a health portal. It doesn't matter. If your API returns records keyed by an ID—orders, invoices, messages, accounts, files—you have the exact same exposure surface. The Manage My Health breach is a checklist of failures that generalize to almost any data-bearing API:
1. Authentication Is Not Authorization
A logged-in session is the start of a security decision, not the end of it. Every request for a specific resource needs an ownership check. If your code path can fetch object N without confirming the caller is entitled to object N, you have a BOLA waiting to be enumerated.
2. Assume Credentials Will Be Compromised
Phishing, reuse, infostealers, and leaked tokens mean a valid login is not proof of a legitimate user. MFA raises the cost of account takeover dramatically; phishing-resistant MFA (passkeys, WebAuthn) raises it further. There is no defensible reason for a portal of national medical records to rely on a password alone.
3. Bulk Access Should Be Loud
One account reading 428,337 documents is not normal behaviour—it is an alarm that should have fired long before file 5,000. Rate limiting, velocity tracking and anomaly detection turn "silent mass exfiltration" into "blocked after the first anomalous burst."
4. Minimize and Expire What You Hold
Data you don't store can't be stolen. Records flowing in from practices that had already left the platform is the breach equivalent of leaving the lights on in an empty building. Retention limits, deletion workflows and encryption at rest shrink the blast radius when—not if—something goes wrong.
Treat every endpoint that returns a record as if the caller is hostile and already authenticated. Build the ownership check into a shared layer—an API gateway or middleware—so it can't be forgotten on the one new endpoint a developer ships at 5pm on a Friday. Authorization that depends on every engineer remembering it is authorization that will eventually fail.
How KnoxCall Helps
KnoxCall sits in front of your APIs as a security and credential gateway, which means the controls that were missing here become centralized policy rather than per-endpoint hope:
- Centralized authentication and scoped access: Enforce strong auth and least-privilege scopes at the gateway, so a single compromised credential can't read the whole database.
- Intelligent rate limiting: Per-user, per-IP and per-endpoint limits that make sequential enumeration and bulk pulls impractical.
- AI-powered anomaly detection: Flag and block the "one account suddenly downloading everything" pattern in real time.
- Comprehensive audit logging: Every request recorded for forensics—so "what was accessed and by whom" is answerable in minutes, not weeks.
- Secrets and credential isolation: Keep raw API keys and database credentials out of application code and third-party hands entirely.
None of this is exotic. It's the boring, layered discipline that turns a compromised login into a contained event instead of a national headline.
Key Takeaways
- The breach required no advanced exploit—just a valid login and an authorization layer that didn't check ownership.
- Broken Access Control (BOLA/IDOR) is the #1 API security risk and the core failure here.
- Authentication tells you who; authorization decides what they can see. You need both, on every object.
- MFA, rate limiting, anomaly detection and data minimization would each have blunted this attack.
- Health data can't be rotated—prevention is the only real control, and the warnings here were ignored for two years.