Breaches Weekly, 4–10 Oct 2026: A 642M-Row Courier File, a Utility Dump and a Microloan Database

Also this week: Ransomware Weekly, 4–10 Oct 2026: Suunto, CyrusOne and an Akira listing five months old

Period covered: 2026-10-04 00:00 UTC → 2026-10-10 23:59 UTC, selected by indexing date in HaveIBeenRansom (HIBR). Each case shows both its publication date and its indexing date. Breaches are limited to leaks first posted in 2026. Data: HaveIBeenRansom (/api/fullmetadata/<id>).

Why these three

A breach qualifies this week if HIBR indexed it between 4 and 10 October and it was first posted in 2026, even when it was posted months earlier. Only leaks first posted in 2026 qualify; re-indexed historical compilations from 2023–2025 (mostly Telegram archive channels, e.g. a 177M-row Dubsmash backup posted in 2024) are excluded. CDEK and full_db were posted on Telegram channels on 18 and 16 September, and the zaimer.kz database on 6 January, so none is a new claim; what changed this week is that the data became searchable. We chose them for volume and for the sensitivity of what the posts say they contain. These are non-ransomware breaches: the sellers and sharers are data-trading channels, not extortion groups.

Everything below is what the posts claim and what HIBR's indexed data shows. We have not verified who owns any dataset, and a domain in a leak does not prove how anyone got in.

Key Findings

The records without an email are not empty. They hold other fields (addresses, account numbers, phone numbers, amounts), so "% with email" understates how much personal data each dataset holds. We have not quantified the non-email types.

How to read the percentages

Personal means an address on a fixed list of free-webmail providers; Corporate is everything else, so it does not mean "belongs to the victim". Shares in the top-5 tables are within their class. For CDEK and full_db.zip HIBR's per-domain record view returned no records when we queried it, so we could not read record content; for those two our analysis uses the indexed metadata and the posts' own descriptions. For zaimer.kz we read 13 records for zaimer.kz and 500 for gmail.com, in context, and they describe only those records. Claims taken from a post are labelled as claims.

1 · The CDEK file (642 million rows)

What happened. On 18 September a Telegram channel that trades databases posted a file it describes as a "cleaned version" of a file from CDEK, a Russian logistics company. The title carries a 2022 date, so the underlying data is probably old; the post does not say how it was obtained. HIBR indexed it on 6 October.

Scale. 642,290,466 records, all CSV rows. 7.5% of records contain an email address (48,265,891 addresses). The rest hold other fields we could not read.

Corporate vs Personal. 11.44% Corporate, 88.56% Personal.

Several corporate domains look like logistics and shipping companies. That fits a courier's client and counterparty base, but it is a hypothesis; the Corporate class is also where mail relays and unrelated domains land.

Attribution confidence: 0/100 (very low). The score is not informative here: the "organisation" HIBR could test was derived from the archive's file name, not from CDEK. A 0 means we have no evidence for or against the claim, not that it is false.

Why it stands out this week. It is by far the largest 2026 leak indexed in the period (about 48 times the next 2026 leak indexed this week, full_db.zip at 13.4M), and a courier's records typically combine names, phones and addresses.

2 · full_db.zip (a US utility's customer records, claimed)

What happened. The Telegram channel Database World ROC posted the file on 16 September. The post text names CenterPoint Energy, dated 21 August 2026, and claims 6,734,894 customer records (about 48.8 GiB raw). The fields it lists include account numbers, holder and contact names, phone numbers, service and billing addresses, amounts due, autopay and billing-programme flags, email, a driver's-licence number and the last four digits of a Social Security number. That list is the poster's description; we did not read the fields. HIBR indexed the file on 10 October.

Scale. 13,390,539 records, almost evenly split between CSV (6,671,543) and JSON (6,718,996). Each is close to the 6.7 million the post claims. A plausible reading is that the same customer set exists in two formats and HIBR counts both; that is our hypothesis. 42.0% of records contain an email.

Corporate vs Personal. 19.56% Corporate, 80.44% Personal (of 5,623,185 addresses).

The Corporate class is mixed: ISP addresses (bellsouth.net, suddenlink.net), a university, a homebuilder and a utility-billing service. That spread is what a consumer customer base looks like, and it argues against an employee-mailbox dataset. It does not identify the data owner.

Attribution confidence: insufficient evidence. HIBR could not evaluate enough factors because the file's label is generic ("full_db.zip") and the utility name only appears in the post. We therefore give no percentage. The match between the post's 6.7 million and the 6.7 million-per-format counts is suggestive, not proof.

Why it stands out this week. If the post is accurate, it combines contact data with partial national identifiers for utility customers, which supports identity-fraud and targeted-phishing use. If you are a customer of the utility named, treat the claim as unconfirmed and watch for official notices.

3 · zaimer.kz database (8 million rows)

What happened. The Telegram channel CHAT BZD posted an archive named zaimer.kz_23.02.2024_1.9M.7z, which HIBR dates 6 January 2026. The post, in Russian, describes zaimer.kz as an online service that gives microloans to a bank account. It lists the data as of 23 February 2024 with three row counts: clients 1,946,965, passports 1,947,928 and potential clients 5,071,359, and the fields full name, sex, phone number, email "and other". Those three counts add up to about 8.97 million, roughly a million more than HIBR indexed; we do not know why. The data itself is older than the posting date. HIBR indexed it on 6 October.

Scale. 7,957,022 records, all CSV rows from three files, which matches the three tables the post lists. 7.8% of records contain an email address (617,610 addresses), so the email count understates the personal data in the file.

What the data contains. For zaimer.kz, 13 records matched. All are rows of the potential_clients file for addresses such as info.…@zaimer.kz, showing loan-application workflow state (steps such as PHONE, PHOTO, PASSPORT, EMPLOYMENT and CLIENT_CREATED), a contract ID and a phone number: they look like staff or test addresses on the service's own domain, not applicants. In the 500 records we read for gmail.com, 100% come from that same file and carry first, last and patronymic names. 74.0% carry a reference to a face-verification provider and 82.0% a photo-check status; 62.4% are at the CLIENT_CREATED step, 18.0% at PHOTO, 9.6% at EMPLOYMENT and 9.4% at PASSPORT. 68.4% carry an identity-registry block: a 12-digit IIN (Kazakhstan's national identification number), birth date and birthplace, registered address, and identity-document fields (number, issuing body, validity dates). Another 9.0% carry only a passport block with an ID number, so 77.4% of the records read include a national ID or document number. 77.2% carry a registered address, and 62.4% list contact persons (relatives, friends) with name and phone, plus declared income. We saw no images, only image references. Distinct emails are 97.0% of the 500.

Corporate vs Personal. 2.84% Corporate, 97.16% Personal (of 617,610 addresses).

Most of the "Corporate" entries are typos of webmail providers (gmai.com, gmil.com, qmail.com, mai.ru), the kind of mistakes people make when typing an address into a loan form. That shows how loose the Corporate label is, and that this is a consumer audience.

Attribution confidence: 45/100 (medium). The declared domain zaimer.kz appears on 11 distinct addresses (0.09% of corporate addresses) and in 0.4% of record contents. HIBR flags the corporate domains as a multi-tenant mix. Incident confirmation and dataset-to-incident linkage are not evaluated, so the score says the data fits the named service, not that it was breached.

Why it stands out this week. It is a consumer-finance dataset: names, phones, national ID and document numbers, birth data and addresses of people who applied for microloans, plus the names and phones of their relatives and friends. That supports identity fraud and phishing that quotes a real loan application. It is also the only one of the three that is clearly not recent: the post dates the data to February 2024.

What they have in common

• All three were posted on Telegram data-sharing channels well before HIBR indexed them, from under three weeks (CDEK) to nine months (zaimer.kz). A publication-date filter would have hidden them from this week's view.
• None names a confirmed victim. Each rests on a post's claim or on a file name, and the Corporate-class statistics cannot tell us who owns the data.
• Personal webmail is 80–97% of email addresses in each, so the realistic risk is to consumers: phishing, credential stuffing and identity fraud, more than to corporate networks.

What defenders can do

Check whether your organisation's domain or your customers' addresses appear. If your service reuses passwords across consumer accounts, force resets and enable multi-factor authentication for accounts with addresses on these lists. Treat unsolicited messages that quote account numbers, billing amounts or a loan application as suspicious.

Is your email or phone number in one of these leaks? Check if your organization appears on HaveIBeenRansom

DarkEye Threat Research · Data: HaveIBeenRansom · Attribution confidence is a heuristic estimate (method v2.0), not a formal attribution.