The Odido data breach began with a convincing telephone call to the Dutch telecom company’s customer service helpdesk. By impersonating an IT colleague, an attacker obtained credentials and a multi-factor authentication token that opened the way into Odido’s Salesforce environment.
How the Odido data breach began with one call
Investigators say a Dutch-speaking man contacted Odido’s helpdesk on 5 and 6 February 2026. He used specific English-language IT terminology and presented himself confidently as a colleague from the company’s IT department.
The caller told an employee that an urgent technical problem needed to be fixed. The worker was persuaded to access what appeared to be a legitimate internal system, but it was actually a credential-harvesting setup controlled by the attackers.
During the interaction, the attacker captured the employee’s username, password and multi-factor authentication token. This allowed the attackers to overcome a security control that would ordinarily require more than a password before granting access.
The incident was not based on a newly disclosed software vulnerability or an unpatched product version. Instead, it relied on social engineering, a fraudulent login process and the theft of a valid authentication token. The employee’s legitimate access became the route into the customer environment.
Access to the Salesforce customer system
With the stolen credentials, the attackers entered Odido’s Salesforce-based customer relationship management system. This platform was used to record and manage interactions with customers of both Odido and its budget subsidiary, Ben.
Odido confirmed that unauthorised access to its customer contact system occurred on 7 and 8 February 2026. The company said the intrusion was stopped as soon as it was detected.
Approximately 90 GB of information, representing about 15 million rows, was reportedly extracted two days after the initial calls. The attackers used legitimate Salesforce application programming interfaces, or APIs, to export the information.
This method is important to understanding the Odido data breach. Rather than deploying conspicuous malware or exploiting a technical flaw, the attackers used authorised functions with stolen access. API requests can resemble normal business activity, making malicious exports more difficult to distinguish from legitimate use unless identity, volume and behaviour are closely monitored.
Odido data breach affected 6.39 million people
Odido’s final confirmed figure places the number of affected people at approximately 6.39 million. The population includes active and inactive customers of Odido and Ben, making the incident one of the largest reported compromises of personal information in the Netherlands.
Earlier estimates ranged from 6.1 million to 6.2 million people. ShinyHunters claimed it had obtained almost 21 million records, but this higher figure may include duplicate records and internal corporate metadata rather than 21 million separate individuals.
Have I Been Pwned subsequently confirmed that roughly six million unique email addresses appeared across four data releases. This broadly supports Odido’s assessment of the number of individuals involved, while allowing for multiple database rows relating to each customer.
Information reportedly exposed
The stolen dataset reportedly contained a wide range of personal and financial identifiers. The exposed fields included:
- Full names, dates of birth and customer numbers
- Home addresses, telephone numbers and email addresses
- IBAN bank account details
- Passport and driving licence numbers
Odido has said account passwords, call records and billing data were not compromised. ShinyHunters disputed part of that account, claiming that plaintext passwords and internal corporate documents were also obtained. Based on the available reporting, these conflicting claims have not been reconciled, so the company’s confirmed scope should be distinguished from the attackers’ assertions.
ShinyHunters published the stolen Odido data
ShinyHunters reportedly demanded approximately EUR 1 million in exchange for not publishing the stolen information. Odido refused to pay and later defended that decision publicly.
The group began releasing the information in stages on 26 February 2026. It had published what it described as the complete cache by 1 March 2026, meaning the extortion threat moved from threatened disclosure to confirmed public distribution.
As of the latest reporting, the original unauthorised access had been terminated, but copies of the data had already been released. The present risk therefore comes from the continuing availability and possible reuse of stolen information, rather than an ongoing connection to Odido’s Salesforce system.
Police release the suspected caller’s voice
Dutch police have made the suspected caller’s voice public as part of an effort to identify him. The recording is notable because the initial compromise depended heavily on spoken persuasion, apparent familiarity with workplace processes and the credible use of technical language.
The voice appeal also provides an unusually direct view of the human element behind the Odido data breach. The caller allegedly created urgency, established false authority and guided the employee towards an attacker-controlled credential capture process, all without needing to defeat the Salesforce platform itself.
Why this Salesforce intrusion matters
The incident demonstrates how multi-factor authentication can be undermined when an attacker captures both credentials and a valid token through the same social engineering exchange. MFA remained present, but the attacker persuaded a legitimate user to supply the elements needed to pass it.
It also shows why SaaS data exports require their own monitoring. Legitimate APIs can move large quantities of information quickly, and stolen employee access can make those requests appear authorised at a basic level.
Actions organisations should take after the Odido breach
Organisations using Salesforce or comparable SaaS platforms should focus on controls that address the specific techniques seen in this incident:
- Review helpdesk procedures for verifying internal callers, especially requests involving login pages, authentication tokens or urgent access changes.
- Alert on unusual API export volumes, new access patterns and large downloads from customer systems.
- Restrict bulk export permissions to roles that genuinely require them and regularly review those privileges.
- Ensure employees can independently verify IT requests through a known internal channel before entering credentials.
- Investigate authentication events where a password and MFA approval are followed by unusual Salesforce API activity.
For affected customers, unsolicited messages that reference accurate contact, identity or banking details should be treated cautiously. Such information can make later impersonation attempts appear credible, even when the sender does not have access to an account password.
Originally reported by cybersecuritynews.com.
