Carnival Corporation began notifying nearly 6 million customers that a social engineering attack in April had given an attacker access to names, addresses, phone numbers, dates of birth, and government-issued identification numbers.
The incident started on April 10, 2026, when an attacker deceived a Carnival employee into granting access to a portion of the company's IT systems. Carnival's security team detected the unauthorized activity four days later, on April 14. By April 22, the company had confirmed that personal information had been copied.
ShinyHunters, the extortion group tied to multiple large-scale incidents over the past year, listed Carnival on their pay-or-leak portal on April 18, claiming exfiltration of more than 8.7 million records. Carnival has confirmed 5,995,277 individuals in its official regulatory notifications. BleepingComputer reported that the exposed data includes names, addresses, email addresses, phone numbers, dates of birth, and government-issued identification numbers including driver's licenses and passport numbers. The company is offering eligible U.S. residents two years of credit monitoring.
Two things stand out: the scale of data accessible through a single compromised employee account, and what that implies about the application's access control model.
What scanners would have missed
The entry point here was human. No CVE was assigned to this breach. A standard vulnerability scanner looking for known software weaknesses would have found nothing to flag.
That is worth being precise about. Conventional scanning tools operate on a specific model:
- SAST scans source code for injection flaws, hardcoded secrets, and insecure patterns.
- DAST fuzzes HTTP endpoints for authentication bypass, input validation failures, and misconfigurations.
- SCA checks third-party libraries against databases of known CVEs.
- Secrets scanning looks for exposed tokens and API keys in the codebase and repositories.
None of these tools ask the question this breach exposed: can a legitimately authenticated employee account access records for millions of customers, with no volume controls and no behavioral anomaly detection? That is not a code vulnerability. It is an access control design problem.
CVSS scores assume a specific attacker model. An unauthenticated attacker probing an open endpoint might generate a critical CVSS score. An authenticated attacker operating within a valid session, using a valid export function, generates no CVSS score at all. The application behaves exactly as designed. The problem is that the design imposes no ceiling on how much data a single session can reach.
The specific failure mode here is the combination of overly broad employee data access and the absence of volume-based controls on bulk operations. Neither of those surfaces in a scanner output. They require testing with valid credentials, at the behavioral layer, with a clear-eyed question about what a compromised account enables.
What Sekura would have shown
The relevant phase is Phase 4, exploit synthesis.
In this phase, the Sekura agent takes a hypothesis surfaced during dynamic probing and attempts to construct a deterministic proof. The hypothesis: a standard employee credential can access customer records at a scale far beyond what the role's function requires.
The agent authenticates using test credentials mapped to a support-level role. It enumerates the data access patterns available to that role: which customer records can be queried, whether bulk operations are subject to volume limits, and whether large-volume data access triggers any anomaly detection. Finding that the support role has unrestricted access to the customer dataset, the agent constructs a proof demonstrating the extraction scope.
The finding produced would state: a support-role session token allows access to customer PII at scale, with no effective volume threshold and no export anomaly detection. The proof artifact is the demonstrated extraction scope, showing record count and data types accessible in a single session.
I think this is the class of finding that most organizations are not testing for, because they assume legitimate access equals acceptable access. Sekura's position is that authenticated access with no ceiling is a finding. A working path to 5.9 million records that requires only valid credentials is still a working exploit.
Sekura does not detect social engineering. That is outside application security scope. The question Sekura answers is: once a credential is in an attacker's hands, what does the application allow them to do?
The bigger pattern
This is an account-takeover-to-exfiltration chain. The attacker's technical foothold was a valid credential, not a zero-day. The damage multiplier was the application's access model.
ShinyHunters has applied this approach across multiple incidents in 2025 and 2026. The group identifies organizations where employee roles carry broad data access, then acquires credentials through social engineering or infostealer malware. The credential is a commodity. The access model is what determines the scale of what follows.
I believe this category of breach is significantly underrepresented in standard pentesting scope. Security exercises often model social engineering as ending at the click. What happens after the click, specifically what the application allows a compromised account to do, is the part that determined whether 5,000 records were exposed or 6 million.
The 6 million records here were not taken through a zero-day or a misconfigured public endpoint. They came through a valid account, via standard application functions, because nothing constrained how much data a single session could reach. That is an access control problem you can test for.
If you want to see what proof-first looks like on your own attack surface, book a POC.