Threat intel
SBI leak: 375,000 rows claimed, 3,897 records confirmed
SBI found 3,897 customer records in a dark web dataset an actor sells as 375,000 rows. What the gap means, the phishing risk, and what bank IT should check.
On 21 October 2026, State Bank of India (SBI), the country's largest lender, told the stock exchanges that it suspects a breach of customer data. Its own preliminary analysis of about 375,000 records found on the dark web identified 3,897 customer records with personal information: names, registered mobile numbers, dates of birth, gender, email and residential addresses, branch details, Customer Information File (CIF) identifiers, lead IDs and metadata from loan and lead records. SBI says its core business functions continue to operate normally.
The bank's filing came five days after alerts from its threat intelligence provider, the Defence Cyber Agency and CERT-In, India's national computer emergency response team. Those alerts followed a post by an actor calling itself Siriusim, who offered what it described as about 375,000 rows of customer data in CSV format plus 2,722 PDF files, including loan applications, Know Your Customer (KYC) documents and account-opening forms. If you bank with SBI, expect phone calls and messages that already know your details. If you run IT for a bank, lender or loan agent, this is a good week to check where your own KYC files and customer exports live.
Who said what
Two different parties produced the two numbers, and reports have blurred them. The 375,000 figure and the 2,722 PDFs come from the seller's post on BreachForums, a cybercrime marketplace, which the account CyberPulse56 flagged on X on 16 October and India Today reported on 19 October. Nobody outside the seller has verified that post, and early coverage said it was unclear whether the data was new or recycled from older leaks.
The 3,897 figure comes from SBI itself, in its exchange filing. The bank says it "promptly activated its cyber incident response and containment protocols", has engaged an independent agency empanelled by CERT-In, and that a detailed investigation is needed to establish the authenticity and completeness of the data and where it came from. The filing does not name Siriusim, does not say how the data left, and does not mention the 2,722 PDFs. The fields it lists do not include passwords, PINs or one-time passwords, and no stolen funds have been reported.
Reading the gap between 375,000 and 3,897
The two numbers measure different things. 375,000 is a row count in a file the seller controls. 3,897 is the number of rows the bank, so far, has matched to real customers with personal data attached. The rest could be duplicates, rows with no personal fields, records belonging to someone else, or data the bank has not yet matched. SBI's preliminary findings do not show that all 375,000 entries hold compromised personal information, or that 375,000 customers are affected. Equally, 3,897 is a first count that may rise as the matching continues, and one customer can appear in several records.
The PDFs matter more than the row count. A scanned KYC pack or loan file can hold an identity document, a photograph, a signature, income papers and a home address in one place, which is far more useful to a fraudster than a CSV line. Until SBI says whether those files are genuine, treat that part of the claim as open.
The field list gives one hint about the source. Lead IDs and "metadata associated with loan and lead records" are what a loan origination or customer relationship management (CRM) system holds, where a prospect is tracked before and while they apply. That points toward the systems and partners that handle loan sourcing, away from the core banking ledger. SBI has not said this; it is our inference from the field names.
The phishing risk, for customers of any bank
A caller who knows your name, date of birth, branch and the loan you asked about sounds like your bank. That is what this data buys a fraudster, and it works against customers of any bank whose records are traded. The usual scripts are a "KYC update" that will freeze your account unless you act today, a loan approval that needs a processing fee, or a fraud alert that asks you to read back a one-time password.
Customers should hang up and call the bank on the number printed on their card or passbook. No bank asks for a PIN, OTP, CVV or full card number by phone, SMS, WhatsApp or email, and none asks you to install a screen-sharing or "support" app. Report suspected fraud to the bank first and then on the national portal at https://cybercrime.gov.in. Banks should tell customers this directly now, by SMS and in the app, rather than wait for the investigation to finish, because the calls start as soon as the data is for sale.
What a financial-services IT team should check
- KYC and loan document stores. Find every place scanned identity documents and loan files live: document management systems, object storage buckets, shared drives, email attachments and archives. Check who and what can read them, whether any bucket or share is reachable from the internet, and whether access is logged per file. A service account that can list and download every PDF is the account an attacker wants.
- Third-party vendors and loan sourcing partners. Direct selling agents, loan origination platforms, CRM providers, collection agencies and KYC verification services often hold copies of the same documents. Ask each one where your customer data sits, how long they keep it, and when they last reviewed access. Contracts should require them to tell you about a suspected incident within hours, since CERT-In expects incidents reported within six hours of being noticed.
- Export and reporting jobs. Bulk CSV exports for analytics, marketing, reconciliation or data migration are a common source of leaked rows. List scheduled exports, where their output lands, and who receives it. Alert when an account downloads far more records than usual, or when a new archive file (.zip, .7z, .csv) appears on a file share or leaves the network.
- Dark web and threat intelligence monitoring. SBI learned of this from outside parties. Make sure a provider watches forums and Telegram channels for your brand, domains, BIN ranges and sample data, and that an alert reaches someone who can act the same day.
- Matching and customer notification. When a sample appears, match it against your systems by CIF or account number to count real customers, de-duplicate, and work out which fields each person lost. Prepare the customer message, the call-centre script and the regulator notice in advance, so the first notification goes out within days rather than weeks.
If you hold a sample of a leaked dataset, the fastest way to find the source is often in the data itself: which system generates that ID format, which columns appear together, and the date of the newest record. That narrows the search to one application or one partner.
Getting help
Our attack surface management service looks for exposed storage, forgotten portals and leaked data tied to your organisation, and our security operations team can set up the bulk-download and export alerts described above. If you want help with a vendor review or a notification plan, open the chat and Yaali, our AI agent, will pass your question to an engineer.
Sources: Deccan Herald, India.com, DT Next (PTI), The Statesman via Asia News Network, Business Standard, Cyber Security News, VARINDIA, OODA Loop, SQ Magazine.