Love Electric: alleged breach, 877,000 driver records for sale at $600

The seraphims account offers the database, 999-row sample

On 26 August 2026 a seller with the account name “seraphims” claimed on an English-language forum to possess the Love Electric driver database. Love Electric Financial Services Limited is a Scottish company based in Edinburgh, registered with Companies House under number SC374952. It operates as an administrator of salary sacrifice schemes for electric vehicles, an FCA-regulated credit broker and a service provider to UK employers. Its privacy policy states that it processes personal data in accordance with UK law. The company claims to work with more than 1,500 businesses.

The seller offered 877,000 records for $600 in cryptocurrency, with a negotiable price. A free sample of 999 rows was published. Ransomnews examined the sample and considered it consistent with a real production database. However, the figure of 877,000 records remains unverified: only 0.11% of the alleged dataset was observed. Love Electric was contacted for comment but had not responded at the time of publication.

What the sample contains: 24 columns and unchanged identity data

The sample was a 999-row CSV with 24 columns, named in a way that indicated an export of the table dbo.drivers from Microsoft SQL Server. The columns included identifiers (id, quote_id, user_id), first name, surname, email, phone, date of birth, address, city, postcode, National Insurance number, driving licence number, consent flag, timestamp fields and employment. The 999 rows break down into 731 primary drivers and 268 additional drivers. There are exactly 731 distinct quote IDs: each quote has a single primary driver and all 268 additional drivers refer to an existing quote, with no orphan records.

The consent flag for National Insurance is empty for all 268 additional drivers. It is populated for each of the 731 primary drivers. National Insurance numbers appear only on primary drivers.

The population is not uniform. About 71% of rows lacked a name, address or city. 74% lacked a phone number. 85% lacked a National Insurance number. In total, 147 records contained a National Insurance number and 287 contained a driving licence number. The geography of postcodes was concentrated on Edinburgh and central Scotland, with records extending to England. Dates of birth ranged from 1946 to 1999, concentrated on people born in the 1970s and 1980s.

Verification of UK driving licences produced significant results. Of 108 full-length numbers, 98.1% had a surname block matching the record’s surname. 97.2% had an initial matching the first name. 78.7% had a date-of-birth encoding matching the stored date. The remaining errors are compatible with real manual entry, not synthetic data. Driving licence numbers appeared in different lengths. Only 53% of National Insurance numbers matched the expected HMRC format. Phone numbers were present in three different formats.

Email addresses belonged predominantly to UK corporate domains attributable to identifiable employers, to Love Electric itself, or to a European software consultancy. They were not dominated by consumer providers such as Gmail. The database structure appeared normal: it included a soft-delete field, integer foreign keys for quotes and occupations, regional values for Scotland, England, Wales and Northern Ireland, and a “Jane Doe” test record. The 999 rows do not correspond to 999 individuals: they refer to 731 quotes and to only 58 distinct surname–date-of-birth combinations. One person appeared 48 times.

The db2_ prefix in the filename suggests that the table may belong to one among multiple databases. The figure of 877,000 could refer to a broader collection rather than only the drivers table.

The zero-day claim does not hold up against timestamps

The seller claimed an August 2026 attack via a zero-day on a third-party system. However, all rows in the sample show a created_at timestamp falling within a six-second window on 14 August 2022. This pattern is consistent with a bulk migration to a newer platform. It does not prove when or how the data was exfiltrated, nor whether the claimed zero-day played a role.

The account “seraphims” was created on 22 July 2026. By 26 August it had published nine listings, roughly two per week. Several were described as scrapes rather than breaches. At the time of checking, the Love Electric listing had received no replies and had only 52 views. The account’s reputation score was 30, resulting from a single positive vote on 17 August with the comment “keep scrapping”.

Ransomnews states that it did not access or scan Love Electric systems, did not purchase the full dataset, and did not validate identifiers against live services. It analysed only the free sample, removed identifying information from the publication, and notified Love Electric before disclosure, offering to share the listing and sample with the incident response team.

Why National Insurance and driving licences make the case serious

The exposed data includes National Insurance numbers and driving licence numbers. These cannot be changed or replaced like a password. The main risk is targeted phishing. An attacker holding a name, date of birth, address, employer and National Insurance number can craft more credible messages. They can impersonate HMRC, payroll teams, the employer or the leasing provider.

The $600 price does not represent a serious valuation of the data’s value. It appears designed for a quick sale. If the seller holds more than the published sample, multiple buyers can obtain the same information, widening the exposure. The case highlights the risk associated with third-party suppliers that process high-value identity data. If a provider handles National Insurance numbers, driving licences, employment data and contact details, its security deserves the same level of scrutiny as any highly sensitive internal system.

What drivers, customers and security managers should do

Drivers who have used Love Electric should treat unexpected messages about vehicle schemes, payroll or tax matters as suspicious. They should verify the sender through a trusted phone number or website, without using the contacts contained in the message. Until verified, the figure of 877,000 records should not be treated as confirmed. The genuineness of the sample and the total number of records held by the seller are separate questions.

The investigation should check for the third-party access mentioned by the seller and the legacy migration of 14 August 2022. It should not assume the zero-day claim to be fact. For client companies and security managers, the case should be considered an operational supplier-management problem. A review of controls over those who process high-value identity data is needed. Notification procedures should only be activated after appropriate verification.