Qantas: the breach that happened anyway, and the regulator that said the controls still worked

Background

Qantas, like most airlines, runs part of its customer-service operation through an outsourced contact center — a third-party platform staffed by agents who don't work for Qantas directly but have real access into Qantas's own CRM, built on Salesforce. That platform supports something most customers never think about: Salesforce Connected Apps, a mechanism that lets an external tool or integration request access to a Salesforce org, approved by whoever's logged in at the time. In most Salesforce configurations, an ordinary end user — not an administrator — can approve that connection themselves, by entering a short code. That single design detail is most of this story.

From one phone call to 5.7 million records, and how fast it was shut down

What actually happened

On June 28, 2025, someone called an agent at the overseas third-party provider that staffs part of Qantas's contact center, identifying themselves as Qantas IT support. The call wasn't asking for a password or a one-time code pushed to a phone — it walked the agent through Salesforce's own Connected App authorization flow and asked them to enter an 8-digit connection code read out over the call. The agent did. That single approval was enough: no credential was stolen, no system was exploited, no malware was involved. An ordinary platform feature did exactly what it was built to do, for someone it should never have been doing it for.

Over the next two days, the attacker used that access to pull customer records out of the platform — Qantas now puts the figure at roughly 5.7 million customers, though the number moved as the investigation progressed: Qantas's first public estimate, on July 2, was "up to 6 million," refined a week later to the more specific 5.7 million figure once the full extraction was mapped. Names, email addresses, phone numbers, dates of birth and frequent-flyer numbers were taken. Payment card data, passport details and account login credentials were not among them.

Qantas detected unusual activity on the platform on June 30 and revoked the compromised account the same day — a two-day window from first call to full lockdown, which is fast by almost any industry benchmark for an incident that started with a human being talked into something, not a technical alarm firing on an exploit.

The stolen data surfaced later that year: in October 2025, the extortion group behind the theft published it to a leak site, in apparent defiance of an injunction a New South Wales court had issued barring its release. Maurice Blackburn, an Australian law firm, lodged a representative complaint with the Office of the Australian Information Commissioner (OAIC) on July 17, 2025, separate from and parallel to the regulator's own inquiry.

Almost exactly a year after the breach, on July 16–17, 2026, the OAIC closed its preliminary inquiries. Privacy Commissioner Carly Kind declined to open a formal, Commissioner-initiated investigation — not a dismissal of what happened, but a specific finding that Qantas's pre-breach conduct met its obligations under the Australian Privacy Principles.

Root cause

Timeline

Detection

What to monitor for in your own environment

Containment, eradication & recovery

Security control analysis

Controls that would have prevented or limited this

Blast radius

How the confirmed record count sharpened over ten days

What they got right

This is the rare case study where "what they got right" is also, almost word for word, the regulator's own explanation for why no fine followed. The OAIC's closure specifically credited pre-engagement security assessments and ongoing audits of Qantas's third-party contact-center provider — meaning Qantas wasn't just trusting a vendor's word on security, it had a standing review process and could produce evidence of using it.

It also pointed to contractual requirements holding that vendor to defined security standards, role-based access controls that limited what the compromised session could actually reach, and staff training that was active and current even though this particular vishing technique fell outside what it was built to catch. None of that prevented the breach. All of it is exactly the kind of evidence an organization needs on hand when a regulator comes asking afterward — and most organizations, after a breach this size, don't have it.

The response speed matters too: detecting the activity and revoking the compromised account within roughly 48 hours of the first call kept this from becoming a longer-running compromise with a wider blast radius. A regulator weighing "reasonable steps" is weighing the whole chain, not just the moment of failure — and Qantas's chain held everywhere except the one link that mattered.

Why this keeps happening

Third-party and vendor-channel compromise is becoming the default way into organizations that have otherwise done the obvious things right. Qantas wasn't breached through its own infrastructure — it was breached through a platform operated by a company it contracted with, using a feature of a SaaS product (Salesforce) that neither Qantas nor its vendor built. That's a genuinely different risk surface than a phishing email landing in an employee's inbox, and most security programs still model vendor risk as a paperwork exercise rather than a live attack surface.

This specific technique — vishing a contact-center or help-desk agent and walking them through a legitimate platform's own app-authorization flow rather than asking for a password outright — shows up across a broader 2025 campaign against Salesforce customers, with other organizations including Allianz Life, Google, and brands under LVMH and Adidas reportedly affected by related activity. Security researchers tracking the cluster associate much of it with the UNC6040 group, overlapping with the ShinyHunters extortion brand. The exact membership and branding of any coordinated "coalition" behind these campaigns is murkier and more disputed than the headlines suggest — the attribution that holds up is the technique, not necessarily a single unified group behind every instance of it.

Vishing works precisely because it targets the layer that's hardest to patch: a person doing their job, following what sounds like a legitimate internal process, under no obvious pressure to be suspicious. A contact-center agent fielding dozens of calls a day has no structural reason to doubt a caller who sounds like internal IT and is pointing them toward a real Salesforce screen, not a fake one.

Lessons for your own environment

1. A vendor's security posture is now part of your own attack surface, and it needs the same scrutiny

   The breach happened at a third-party platform, not inside Qantas's own infrastructure — and the thing that protected Qantas from a worse regulatory outcome was having actually audited that vendor beforehand, not just signed a contract with a security clause in it.

2. A SaaS platform's default settings are a control surface you own, even when you didn't build the platform

   The specific gap here — a non-admin user able to approve a new app connection with a verbal code — is a configuration choice inside Salesforce, not a vulnerability Salesforce needs to patch. Review what your own and your vendors' SaaS platforms allow by default, not just what they're capable of restricting.

3. Vishing doesn't need to ask for a password to get what it wants

   This attack never requested a credential. It asked someone to complete a legitimate-looking authorization step on a real platform screen. Awareness training built around "don't give out your password" misses an entire category of social engineering that asks for something else entirely.

4. Fast detection and response genuinely changes the outcome, not just the headline

   A two-day window from first contact to full account revocation is a large part of why this didn't become a longer-running, more damaging compromise — and a meaningful part of why the regulator closed the file without a fine.

5. Evidence of due diligence has to exist before the breach, not get assembled after it

   Qantas could show the OAIC a standing vendor-audit program and documented access controls because those things already existed as routine practice, not because they were built in response to the incident. A regulator asking "what did you do beforehand" wants a paper trail, not a promise.

6. A closed regulatory inquiry is not the end of an organization's exposure

   The OAIC's decision not to formally investigate doesn't resolve the separate Maurice Blackburn representative complaint or any civil claim arising from the breach — those tracks run independently, on their own timeline, regardless of what the regulator concludes.

CISO & board lessons

• The business case for vendor security review programs is usually made in the abstract — "it reduces risk." This incident is a concrete, dated example of that program directly producing a specific, favorable regulatory outcome. Use it to defend that budget line the next time it's questioned.
• A board should understand that "we were breached" and "we failed our duty of care" are two different findings, and a regulator can and does distinguish between them. That distinction is only available to an organization that can produce evidence — audits, contracts, training records, incident timelines — not one that can only assert it did the right things.
• The specific gap that let this happen — a SaaS platform's default authorization behavior — is the kind of finding that's easy to miss in a standard vendor security questionnaire, because it's a configuration choice, not a listed control. Ask not just whether a vendor has access controls, but what their platform allows a single authenticated user to approve on their own.
• Incident response speed is a genuine, measurable lever on regulatory and reputational outcome, not just an operational nicety. The gap between detection and containment here was days, not weeks — treat that capability as something worth investing in and testing, not something you assume you have.

Action plan

Could this happen in your organization?

• Do you know every SaaS platform integration a non-administrator employee or vendor agent could approve on their own, with no secondary review?
• Has your organization's own Connected App (or equivalent) authorization setting ever been reviewed specifically for who can approve new connections, not just who can access data?
• When did you last audit the security practices of a vendor or contact-center provider with access to customer data — and could you produce that audit on short notice?
• Does your phishing/social-engineering awareness training include a scenario where the caller isn't asking for a password, but walking someone through a legitimate-looking authorization step?
• If a vendor-operated platform were compromised today, would your detection coverage actually notice, or does your monitoring stop at your own infrastructure's edge?
• Could your organization produce, within 48 hours of a regulator's request, documented evidence of vendor security reviews, access controls, and training records predating an incident?
• Do you know how long it would take your team to detect and revoke a compromised session on a third-party platform you don't operate yourself?

If this happened to you: what to ask, and what to say

Knowing the lesson isn’t the same as knowing what to do with it Monday morning. A security lead, a CISO, and a customer-facing team each need something different from this incident.