A database said to hold sensitive customer records tied to Iran's Bank Mellat surfaced in dark web intelligence reporting on 15 August 2026. Figures differ by source: Undercode News, citing a Dark Web Intelligence alert, reports "more than 32.1 million records" at roughly 6.34 GB in CSV format in one write-up, while a second Undercode piece covering the same alert describes exposure "connected to as many as 32 million accounts." Neither figure has been independently verified, and Bank Mellat has issued no public statement. Every source available on this incident is OTHER-tier reporting derived from a single short dark web post. Treat the numbers as claims, not findings.
What Happened
On the morning of 15 August 2026, at approximately 10:50 AM per Undercode's account, a Dark Web Intelligence post announced a Bank Mellat breach exposing tens of millions of records. Undercode published two write-ups within roughly twenty minutes of each other. The first describes a listing with more than 32.1 million records, a 6.34 GB CSV file, and published sample records. The second characterises the same alert as short on detail, noting it did not supply a full database size, a threat actor name, a database timestamp, technical indicators, or evidence of what the 32 million figure actually counts.
The two accounts are not identical, and the difference matters. One presents a fairly specific listing profile; the other stresses that the underlying alert was thin. The most defensible reading is that a listing exists with sample data attached, and that the surrounding detail in circulation exceeds what the original post substantiated.
Both write-ups flag the same dating problem. Undercode reports that the information dates back to 2025, and that a previous incident in June 2025 involved publication of data allegedly belonging to more than 32 million Mellat Bank accounts. The overlap in record counts is close enough that this may be a resurfacing or repackaging of a known 2025 dataset rather than evidence of a fresh August 2026 compromise. No source establishes which.
There is also a category problem. As Undercode notes, 32 million records is not the same as 32 million people. Banking datasets routinely carry multiple rows per customer covering accounts, histories, and transactions. A record count is an upper bound on victims, not a headcount.
What Was Taken
Undercode's first report lists the fields reportedly present in the dataset: national identification codes, account numbers, full names, identification numbers, dates of birth, addresses, card numbers, and mobile phone numbers. If authentic, that combination is close to a complete identity package. National ID code plus date of birth plus address plus mobile number supports account takeover and KYC impersonation; card numbers and account numbers extend that into direct financial fraud and highly credible smishing against Iranian banking customers.
The format compounds the exposure. CSV is trivially searchable, splittable, and redistributable, which means the dataset does not need a buyer to cause harm. Once a file of this shape circulates, containment is effectively impossible.
Sample records were reportedly published alongside the listing. Samples demonstrate that structured data exists. They do not establish provenance. As Undercode's own analysis puts it, apparently structured records do not by themselves prove who collected them, when, or from where. A dataset attributed to Bank Mellat could originate from a third-party processor, an aggregator, an older breach, or a merge of several sources.
Why It Matters
Bank Mellat is one of Iran's largest financial institutions, founded in 1980, headquartered in Tehran, with operations spanning multiple countries according to public company profiles. A confirmed exposure at that scale would be a national-level event.
It also lands on top of a bad year for Iranian banking. Undercode notes that during June 2026, cyberattacks and major service disruptions affected several Iranian financial institutions including Bank Mellat, with authorities acknowledging attacks against shared banking infrastructure. IranWire's reporting describes a nationwide banking network blackout beginning 13 June and still unresolved 26 days later, arriving in several distinct waves and hitting major state-owned banks first. IranWire's framing goes further, arguing the outage functioned as a de facto freeze on public deposits and questioning whether official explanations of a technical glitch or security breach are complete. That is an analytical claim from one outlet, not an established fact, but it captures the credibility vacuum around Iranian bank incident disclosure.
That vacuum is the real story here. Compare the contemporaneous Bank of Baroda case in India. When roughly 1 TB of data attributed to BoB appeared on the dark web in late July 2026, the bank published a statement within a day: it confirmed the compromise of an employee email account, said unauthorised access to certain data followed, stated that core banking systems were not accessed, and announced a forensic investigation conducted with regulators. The Financial Express reports that researchers went on to build a public checker letting customers test whether their branch appeared in the leaked directory structure. None of that has an equivalent on the Bank Mellat side. Defenders and customers get a dark web screenshot and silence.
Note that the Baroda material describes an entirely separate incident at a different institution. It is included here as a disclosure benchmark, not as evidence about Bank Mellat.
The Attack Technique
Unknown. No source identifies an intrusion vector, a threat actor, or a timeline for the Bank Mellat dataset. The Dark Web Intelligence alert reportedly carried no technical indicators at all.
What can be said is what the surrounding threat landscape looks like. Independent researcher Ali Amini has published a technical analysis of what he designates FirmBurn, a firmware zero-day abused alongside SCSI PassThru commands to wipe storage at several major Iranian banks during the Iran-Israel conflict, targeting Dell EMC storage systems with what he assesses as APT-level, professionally developed wiper malware. That is a single independent researcher's analysis of destructive attacks, and it is a distinct class of activity from bulk data theft. There is no reported link between FirmBurn and the 32 million record dataset. Anyone drawing one is speculating.
Two comparison points are worth holding. The Baroda breach traced back to a single compromised employee mailbox, a reminder that terabyte-scale exposure does not require exotic tradecraft. And public LinkedIn profiles show Bank Mellat staffing a security operations centre and incident response function out of Tehran, including a senior incident response analyst in post since 2019 and an information security expert working in the bank's SOC since 2020. The bank is not without a detection capability. Its absence from the public record here is a disclosure posture, not necessarily a capability gap.
What Organizations Should Do
Treat unattributed bulk listings as an intelligence problem before a comms problem. Pull the samples, check field structure and formats against your own schemas, and determine whether the data could have come from you, a processor, or an aggregator. Attribution in a listing title is a marketing claim.
Check for recycled data before declaring a new breach. The Mellat figures closely match a June 2025 publication. Maintain a hashed index of previously exposed records so a resurfacing can be distinguished from a fresh compromise within hours rather than weeks.
Harden the mailbox path. Baroda's terabyte started with one employee email account. Enforce phishing-resistant MFA, restrict bulk mailbox export and delegation, and alert on anomalous mass download from mail and file-sharing services.
Instrument the data layer, not just the perimeter. Row-count thresholds on queries against customer tables, egress volume baselines, and alerting on unusual CSV or bulk export jobs catch the exfiltration stage that endpoint controls miss.
Inventory third-party copies of your customer data. Processors, marketing platforms, and analytics vendors hold extracts that carry your brand when they leak. Contractually require breach notification and audit where full-fidelity copies live.
Pre-write the disclosure. The gap between Baroda's next-day statement and Bank Mellat's silence is the difference between a controlled incident and an open-ended one. Have a holding statement, a customer-lookup plan, and a regulator contact path ready before you need them.
Shift downstream controls to assume PII is public. Where national ID, date of birth, and mobile number may already be circulating, knowledge-based authentication is dead. Move to device binding, transaction signing, and out-of-band confirmation for high-risk actions.
Sources: Bank Mellat Data Leak: 32 Million Records Raise Fresh Questions Abo... | Bank of Baroda initiates forensic investigation on data breach that... | Iran’s Bank Mellat Faces Renewed Data-Breach Alarm as 32 Million Ac... | Iran's Banking Outage: Strategic Safeguard or Systematic ... | parastoo jafarnezhad | Shahram Tahmasebi | Bank of Baroda data breach: How to check if your personal details w... | FirmBurn:How Firmware Zero‑Day & SCSI PassThru Burned Iran Banks