State Bank of India (SBI) confirmed on 21 October 2026 that 3,897 customer records were found exposed on the dark web. Around the same week, Bengaluru based eMudhra revoked eight intermediate certificate authorities after weak cryptographic keys were discovered, while the PHP team released emergency fixes for two critical PHP2Shell flaws. Together, the three incidents show how a bank data leak, a broken digital trust chain and a bug in website code can put millions of users at risk at the same time.
What Is a Data Breach?
A data breach is an incident where private or protected information is copied, viewed or stolen without permission. The State Bank of India incident, CERT-In advisories and global trackers use this term when names, phone numbers, passwords or financial details move from a secure system to an unauthorised person.
A data breach in cyber security always involves unauthorised access. A hacker may break into a server, misuse a valid login, or trick an employee into sharing a password. Once inside, the attacker can copy customer records, financial files or login tokens. The SBI case was flagged as a suspected breach after such customer data appeared on the dark web, which is a hidden part of the internet often used to trade stolen information.
A data leak is slightly different from a data breach, though the two terms are often mixed. A leak means data becomes visible by mistake, for example when a database is left open on the internet without a password. A breach means someone actively takes or views that data without approval. Every breach includes unwanted exposure, but not every exposure is proven to be a breach until investigators confirm that someone actually accessed the data.
| Term | What It Means | Example |
|---|---|---|
| Data breach | Private data is accessed or stolen without permission | Customer phone numbers copied from a bank server by a hacker |
| Data leak | Private data is left visible by error, whether or not it is stolen | A database kept open online without a password |
| Cyber attack | Any hostile attempt to damage or break into computer systems | Phishing mail, malware or ransomware sent to bank staff |
| Dark web exposure | Stolen or leaked data found on hidden networks | 3.75 lakh records reviewed in the SBI incident |
Data breaches in India have risen as banking, welfare payments and identity services moved online. This is why bank data breach news now draws quick action from regulators, law enforcement and the national cyber response system.
SBI Data Exposure on the Dark Web
The State Bank of India (SBI) told stock exchanges on 21 October 2026 that it had faced an incident involving the loss of certain customer data. SBI is India’s largest public sector commercial bank, headquartered in Mumbai, with origins going back to the Bank of Bengal in 1806 and reconstitution as SBI under the State Bank of India Act in 1955. The disclosure was made under market listing norms that require listed companies to inform investors about material incidents.
SBI said it first received alerts on 16 October 2026 from three sources acting together. The sources were its Threat Intelligence Service Provider, the Defence Cyber Agency and the Indian Computer Emergency Response Team (CERT-In). The alerts warned about suspected exposure of SBI customer data on the dark web. SBI then started its cyber incident response process and asked an independent cybersecurity agency to investigate the source and scale of the leak.
Preliminary review covered about 3,75,000 records found on the dark web. From this large set, SBI identified 3,897 customer records containing Personally Identifiable Information (PII). PII means details that can point to a specific person, such as name, mobile number, date of birth, gender, email address and home address. SBI also reported branch details, Customer Information File (CIF) numbers, lead IDs and metadata linked to loan and lead files among the material under review.
| Date in October 2026 | What SBI Reported |
|---|---|
| 16 October | Threat intelligence provider, Defence Cyber Agency and CERT-In alert SBI about suspected dark web exposure |
| 21 October | SBI informs stock exchanges about loss of certain data and names 3,897 affected customer records out of 3.75 lakh records reviewed |
| 23 October | SBI says it has individually informed all affected customers by email and WhatsApp and assures that funds remain safe |
SBI said there was no impact on business continuity and that customer funds stayed safe. The bank added that a detailed probe was still needed to confirm the authenticity and completeness of the data and to trace how the exposure happened. This careful wording matters because the initial online claim, linked to an actor using the name Siriusim, had not been fully verified when the bank made its filing.
The incident raised a common public question: is SBI safe for deposits and digital use. SBI’s response focused on two reassurances. First, core banking and payment systems continued to work normally. Second, affected customers were contacted directly and advised to stay alert against phishing calls, fake links and requests for one time passwords. Customers who did not receive such a message were not part of the identified set of 3,897 records, based on the bank’s statement as of October 2026.
eMudhra Weak Cryptographic Key Flaw
eMudhra Limited told customers on 20 October 2026 that the private keys of eight of its emSign G3 intermediate certificate authorities were cryptographically weak and could be recovered from public data. An independent security researcher reported the problem on 17 October 2026. eMudhra accepted the finding, saying a script error during key generation was at fault, and revoked all eight intermediates the next day.
A cryptographic key is a long secret value that locks and unlocks digital information. In website security, the private key must stay secret while the public key is shared openly. If the private key is weak because it was made with too little randomness, an attacker can work backwards from the public certificate and find the private key. That is what happened here. The strength effectively fell from a very high level to only a few bits of unpredictability, so recovery became trivial.
The flaw began during a Key Generation Ceremony held on 30 April 2025. A Key Generation Ceremony is a tightly controlled event where keys for certificate authorities are created inside special hardware called Hardware Security Modules. eMudhra uses modules rated at FIPS 140-2 Level 3, which is a global security standard for such devices. During a wrap and unwrap test step, which moves keys securely inside the hardware, the process produced a second set of weak P-384 keys alongside the original strong keys. Staff then used the weak keys by mistake to seek certificates, partly because the key labels looked similar. The same weak requests were also sent to Sectigo for cross certification with the Comodo AAA system.
The impact was serious because a certificate authority is an organisation trusted to issue digital certificates that browsers accept. If attackers hold the private keys of intermediate authorities, they can sign fake Transport Layer Security (TLS) certificates for any website. TLS is the technology that shows the padlock in a browser and keeps passwords and payments private. With forged certificates, attackers in a position to intercept traffic could impersonate banks, read or change data, and hijack user sessions through a meddler in the middle attack.
Browser and operating system makers moved fast. Google and Mozilla confirmed the weakness and blocked the affected intermediates. Red Hat issued security bulletin RHSB-2026-012 and linked the event to tracking IDs including CVE-2026-114406, CVE-2026-111943, CVE-2026-91403 and CVE-2026-113812. Other platforms, from programming language tools to enterprise firewalls, pushed revocation updates. eMudhra stopped issuing new certificates under its G3 root for the affected chain and said no certificates had been issued directly from some of the weak intermediates before revocation, though every certificate that reached public transparency logs was treated as untrusted.
What Is eMudhra Digital Signature?
An eMudhra digital signature is a legally valid electronic signature backed by a Digital Signature Certificate (DSC) issued by eMudhra as a licensed Certifying Authority. eMudhra Limited of Bengaluru has held a licence from the Controller of Certifying Authorities (CCA) since 7 November 2008 under the Information Technology Act, 2000. The CCA operates the Root Certifying Authority of India and supervises all licensed authorities in the country.
eMudhra is India’s largest certifying authority by market share and supports income tax filing, company filings with the Ministry of Corporate Affairs, goods and services tax work, e-tendering, banking, foreign trade and railway tenders. Users apply online, complete identity verification, download the certificate or store it on a USB token, and sign with tools such as emSigner or eMudhra eSign. A Class 3 DSC, which needs in person or video verification, is the standard for high value transactions like e-auctions. The October 2026 flaw did not affect domestic DSC issuance under the CCA root in the same way. It hit the global website certificate chain under the emSign G3 root, which browsers worldwide trust for TLS.
PHP2Shell Vulnerabilities in the PHP Language
The PHP security team released emergency patches on 21 October 2026 for two critical flaws tracked together as PHP2Shell. The flaws are listed as CVE-2026-109618 and CVE-2026-109619 and carry a CVSS version 4.0 score of 9.2, which denotes critical severity. Both allow unauthenticated remote code execution, which means an attacker can run commands on a server without any login.
PHP is a popular programming language that runs websites on the server side. Content systems such as WordPress, Drupal and Joomla are built with PHP, so a bug in the language itself puts many separate websites at risk even when their own application code is clean. Security teams demonstrated working attacks against standard container images of these three platforms in test conditions.
The root cause lies in how PHP handles a request that stops midway, for example when the server runs out of memory. PHP left internal data only partly set up and then processed that invalid state during cleanup. CVE-2026-109618 involves an out of memory error in upload progress handling that leads to use after free, a condition where software keeps using memory after it has been released. CVE-2026-109619 involves session handling that reuses stale references in a similar way. In addition to code execution, researchers showed that attackers could read worker memory without login, which may expose passwords, authentication tokens and API keys.
| Item | Detail for PHP2Shell |
|---|---|
| Flaw IDs | CVE-2026-109618 (out of memory corruption) and CVE-2026-109619 (session lifecycle issue) |
| Severity | CVSS 4.0 score 9.2, critical, unauthenticated remote code execution |
| Highest risk setup | Apache servers using mod_php, though all web facing PHP setups need attention |
| Fixed versions | PHP 8.5.12, PHP 8.4.27, PHP 8.3.36 and PHP 8.2.35 released on 21 October 2026 |
| Early activity | Threat monitoring reported exploit attempts from 17 October 2026, four days before patches |
Administrators were asked to update to a fixed release or a vendor supplied patched package at once and to take stock of every server that runs PHP, including hidden internal tools. Setting memory_limit to minus one was shared as a temporary block for one attack path, but the PHP team and analysts stressed that patching is the only complete fix. Systems that cannot be patched quickly should be isolated or taken offline until they are secured.
What Is a PHP Vulnerability?
A PHP vulnerability is a security weakness in the PHP language runtime that attackers can misuse to steal data or take control of a website server. PHP2Shell is an example where flawed memory handling after an interrupted request lets an outsider disclose memory or execute code. Such core language bugs differ from flaws in a single app because one fix protects all sites on that PHP version.
Why Cybersecurity Matters and How Breaches Can Be Prevented
Cybersecurity matters because banks, hospitals, power grids and schools now run on connected computers. A single breach can steal money, stop services and shake public trust. Strong passwords, quick patches and alert monitoring protect citizens, businesses and national systems from such harm.
Breaches happen through a small set of repeat paths. Phishing messages trick staff or customers into sharing one time passwords. Weak or reused passwords let attackers guess their way in. Old software with known flaws, like unpatched PHP, gives outsiders a direct entry point. Open databases, weak keys and unchecked file uploads also leave doors open. In the eMudhra case, the path was different but instructive. Even audited hardware processes can fail when code and human checks miss a weak key.
Prevention starts with basics that work for both large firms and ordinary users. Organisations must list all internet facing systems, apply security patches without delay and force multi factor authentication for admin access. Certificate owners must check revocation through Certificate Revocation Lists and Online Certificate Status Protocol checks, which confirm whether a certificate is still trusted. Users can lower risk by using unique passwords, turning on transaction alerts, ignoring links in unknown messages and verifying digital signatures only through official portals such as CCA licensed providers. Regular backups kept offline help recovery if ransomware or data wiping follows a breach.
India’s Cyber Safety Net: CERT-In and Data Protection Rules
The Indian Computer Emergency Response Team (CERT-In) sits at the centre of India’s response system. CERT-In has operated since January 2004 as the national nodal agency for cyber incidents under the Ministry of Electronics and Information Technology. Its mandate comes from Section 70B of the Information Technology Act, 2000, as strengthened by the 2008 amendment. The team collects and analyses incident reports, issues forecasts, alerts and advisories, coordinates emergency action and publishes guidelines on security practices.
CERT-In’s directions of 28 April 2022 require government bodies, companies and service providers to report specified cyber incidents within six hours of noticing them. SBI’s chain of alerts from its own provider, the Defence Cyber Agency and CERT-In reflects this reporting culture in action. The Defence Cyber Agency, which works on military cyber operations and coordination, added defence grade monitoring to a civilian banking case, showing how closely these networks now overlap.
The legal backdrop has also tightened. The Digital Personal Data Protection Act, 2023 lays down duties for handling personal data and provides for a Data Protection Board of India to inquire into breaches. While detailed enforcement is being phased in, the law signals that large data custodians must adopt reasonable safeguards, report breaches and face penalties for lapses. For citizens hit by bank cyber fraud, the practical steps remain quick reporting to the bank, filing a complaint on the national cybercrime portal or helpline 1930, and keeping written records of all messages from the bank.
Key Takeaways
- SBI informed stock exchanges on 21 October 2026 that 3,897 customer records with personal details were found among 3.75 lakh dark web records reviewed.
- eMudhra revoked eight emSign G3 intermediate CAs after weak P-384 keys from the 30 April 2025 ceremony were reported on 17 October 2026.
- PHP2Shell flaws CVE-2026-109618 and CVE-2026-109619 carry a CVSS 4.0 score of 9.2 and were fixed in PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35.
- CERT-In, operational since January 2004 under Section 70B of the IT Act, 2000, is India’s nodal agency for incident response and mandates reporting within six hours.
- eMudhra Limited is licensed by the Controller of Certifying Authorities since 7 November 2008 and issues Class 3 DSCs used for tax, company filings and e-tendering.
