Breaches Weekly, 18–24 Oct 2026: 9.5M Lalafo Records, Claimed Samsung Defect Lists and 2.7M METRO Rows

Also this week: Ransomware Weekly, 18–24 Oct 2026: 282M MAG-labelled rows and Clop's 65.8M-row Thermos listing.

Covers leaks indexed by HaveIBeenRansom between 2026-10-18 00:00 and 2026-10-24 23:59 UTC. Each case shows when it was posted and when its data became searchable. How we pick cases, read records and score attribution: methodology.

Why these three

For this edition, the default selection requires both posting and indexing within 18–24 October. These three earlier postings are included as explicit exceptions for volume or impact. Each became searchable on 18–24 October; their recorded posting dates are earlier. We included Lalafo for its 9,518,194 indexed records and profile-linking fields, and the Samsung-labelled file for engineering defect records and partner identifiers. METRO Russia's contact fields, associated with 2,736,739 indexed rows, justify its inclusion. None is confirmed by the named company.

These are newly searchable claims, not three new incidents. Extortion reposts remain in Ransomware Weekly. We provisionally include the MAG-labelled file there on a hypothesised FulcrumSec link (moderate analytic confidence); its provenance is unverified. We found one candidate posted and indexed in the window, with 16,089 rows, but its metadata did not establish an organisation or exceptional impact. The exceptions below were selected for their evidenced scale and content.

Key findings

The Lalafo and METRO samples contain dates ending in 2023; extraction dates remain unknown. HIBR records their postings in 2026, which does not establish first-ever publication. All three attribution scores are below 50/100. Missing or misparsed organisation domains and incomplete corroboration limit these heuristic scores. Domain-filtered readings cannot establish the contents or age of every record.

1 · Lalafo (posted by Database World ROC)

HIBR entry: Lalafo on HaveIBeenRansom

What happened. A file named lalafo.kg.7z was posted on the Database World ROC Telegram channel on 15 September 2026. HIBR indexed it on 18 October. Lalafo is a classifieds marketplace; .kg is Kyrgyzstan's country domain. We found no public statement or press report about a Lalafo incident.

Scale. 9,518,194 records from a single JSON file. 5,290,890 records (55.59%) contain an email address.

What the data contains. The sampled structure resembles a MongoDB user-profile export. In the gmail.com records we profiled, every record holds a user ID, username, account creation time, online status, "pro" and business-profile flags; 99.8% hold a user hash, 94.2% an avatar link, 88.8% linked social profiles, 84.4% a last-visit time and 13.2% a mobile number. Across 2,000 records read in the gmail.com and mail.ru slices, all dates fall in 2022–2023, the latest on 6 April 2023. No identity documents were classified.

Corporate vs Personal. Personal mailboxes dominate at 92.28%. The "corporate" class (7.72%) includes email.com, site.com and privaterelay.appleid.com; this classification does not mean the addresses belong to Lalafo or prove that any are placeholders.

Attribution confidence: 31/100 (low). Only 57 addresses sit on lalafo.kg (10 of 40 points), Lalafo labels appear in the content (15 of 15), and a third-party concentration penalty took 8 points. For a consumer platform that is expected: users do not have Lalafo addresses. The profile structure (pro accounts, business profiles, last-visit times) fits a classifieds platform. Hypothesis, not fact: a Lalafo user table is likely, with low analytic confidence until independently corroborated.

Why it stands out this week. Its 9.5M indexed records and sampled profile links justify an exception for scale and consumer exposure despite the earlier posting date. Marketplace users are a standard target for fake-buyer and fake-delivery scams. A username, email, linked social profiles and sometimes a phone number are enough to make those messages look real.

2 · Samsung (posted by BFRepoV3Files)

HIBR entry: Samsung on HaveIBeenRansom

What happened. BFRepoV3Files posted Samsung Electronic - part 1 on 21 September 2026. HIBR indexed it on 24 October, the last day of the window. The name says "part 1", and HIBR also lists a "part 3" entry whose metadata was not available. We found no Samsung statement and no press report about this file.

Scale. 4,562,447 total records. Separate file-type counts: text 4,491,412, JSON 44,137, CSV 26,882, spreadsheets 26,182, documents 706. These do not reconcile with the total and must not be added. HIBR also lists PDF, XML, database and email files. Only 5,138 records (0.11%) contain an email address; the examined slice concerns engineering work.

What the data contains. We read 120 of the 2,501 records on partner.sec.co.kr, the largest corporate domain. They come from spreadsheets named DEFECT_LIST_…_Basic_close and …_Basic_resolve, with fields for issue ID, title, main engineer ID, tag (69.2%) and reproduction path (70.0%). Two of the top "domains" are not domains at all: 2.0-service.multihal and a string beginning com.samsung.android.gallery are Android service and package names that the email parser picked up. Hypothesis, not fact: the text files may be device logs attached to defect tickets (low analytic confidence). We did not read them.

Corporate vs Personal. Corporate addresses make up 83.94% of email-bearing records and personal addresses 16.06%.

Attribution confidence: 27/100 (low). The organisation domain could not be read from the file name, so the email-domain factor scored 0. Samsung labels in the content earned 15 of 15. sec.co.kr is a Samsung Electronics domain and samsung.com is present, so the data fits the label better than the score suggests. The automated score still stands, because which Samsung unit or supplier the data came from is not established.

Why it stands out this week. It is a corporate engineering leak in a series that is usually about consumers. HIBR identifies 825 personal email-bearing records; that count alone does not measure all personal exposure. For Samsung's partners and suppliers, defect lists with engineer IDs show who works on what and provide material for targeted phishing.

3 · METRO Russia (metro-cc.ru) (posted by STORM)

HIBR entry: METRO Russia on HaveIBeenRansom

What happened. A CSV named for metro-cc.ru was posted in the STORM Telegram chat on 5 October 2026, the most recent posting of the three. HIBR indexed it on 19 October. metro-cc.ru is the domain of METRO Cash & Carry's Russian wholesale business. We found no statement from METRO.

Scale. 2,736,739 rows in a single CSV file, and almost every row (2,736,685) carries an email address.

What the data contains. Every row we read has the same five fields filled: ID, DATE_CREATE, PHONE, CARD and NAME. The file does not say what CARD holds. METRO's wholesale model relies on customer cards, so a customer-card number is the most plausible reading, but it is a hypothesis; we do not reproduce or describe the values. Across 2,000 rows read in the mail.ru and gmail.com slices, 93–98% of the dates fall in 2022 and the latest is 11 January 2023.

Corporate vs Personal. Personal mailboxes make up 96.24%. The corporate class (3.76%) is again consumer mail in practice: vk.com, plus ro.ru, lenta.ru and myrambler.ru, which are Rambler consumer mail domains.

Attribution confidence: 45/100 (medium). A small number of metro-cc.ru addresses (10 of 40 points) and METRO labels in the content (15 of 15) give a medium score. A customer file is not expected to contain many company addresses.

Why it stands out this week. It is the smallest selected file by rows; the five fields were populated throughout the profiled slice. A phone number, a name and an email address in the same record provide the details needed for SIM-swap, smishing and account-recovery fraud. The card field could make a "your METRO card" message look legitimate.

Not included this week

• keccel.com (8,485,790 indexed records; posted 11 July, indexed 18 October) is larger than Samsung or METRO, but size alone does not justify a date exception. HIBR reports only 369 email-bearing records and insufficient attribution evidence. A bounded reading of 160 domain-filtered records did not yield structured field names or ISO dates through our parser. That limit to our coverage leaves the presence of sensitive content unresolved. We could not establish enough about its impact to feature the case.
• mafmarket.ru (2,920,053 records; posted 15 September, indexed 18 October) was also considered. A 160-record slice contained mail-related fields, with parsed dates in 2021–2022. We prioritised METRO's much larger email-bearing count and directly observed contact schema when assessing impact. This does not establish that the mafmarket file is harmless.
• A file labelled Engie (9,959,200 records, posted 11 September) was left out. Its five most common email domains each hold between 16.64% and 16.71% of addresses, and every address is personal. Real customer bases are rarely that even. Hypothesis, not fact: the file is generated or padded. Its attribution could not be computed.
• An Omaze-labelled file (3,019,688 records, posted 28 September) was left out because the dates in the records we read fall in 2014–2017, the latest in March 2017. It is likely an old dataset re-posted, not a 2026 leak.
• A 91,436,226-line file labelled Rambler.ru (posted 12 July) was left out because HIBR could not compute its attribution and nothing in the metadata dates it.

What they have in common

• None of the three is confirmed; all score under 50/100. Organisation-domain limitations and missing corroboration require caution about dataset ownership.
• The corporate/personal split describes domain classes, not ownership. Consumer mail and relay domains can appear in the corporate class.
• Dates in the Lalafo and METRO samples end in early 2023. The indexed posting dates are in 2026; neither date establishes when the full datasets were extracted.

What defenders can do

• Marketplaces (Lalafo): watch for login and password-reset spikes on accounts with linked social profiles. Warn sellers that buyers will not ask them to "confirm a payment" through a link.
• Hardware makers and suppliers (Samsung): check defect-tracking exports for partner-portal accounts and engineer IDs, rotate partner credentials that appear in them, and remind engineering teams that a message quoting a real defect ID is not proof it is genuine.
• Retail and loyalty programmes (METRO Russia): ask mobile operators to flag SIM-swap requests for affected numbers where that is possible. Never ask customers to confirm a card number by SMS, and say so publicly.
• Fraud teams: don't trust a dataset just because its channel or file name says it is new. Check the dates in the records, as with Omaze, and the shape of the domain mix, as with Engie, before acting on a leak.

Is your email or phone number in one of these leaks? Check it for free · Get an alert if it shows up in a new leak

DarkEye Threat Research · Data: HaveIBeenRansom · Indexing methodology peer-reviewed in MDPI Electronics · Attribution confidence is a heuristic estimate (method v2.0), not a formal attribution.

← Previous edition · All Breaches Weekly editions