FRAUD ALERT

A stolen password, a leaked bank record or a weakness buried somewhere in a website's code. None of it feels urgent — until the money disappears, a customer's identity gets misused, or a business realises, often weeks too late, that cybercriminals have been quietly helping themselves to its data all along. A string of recent cybersecurity incidents — involving digital certificate-provider eMudhra Ltd, cloud database company PingCAP, and the PHP programming language (a free, open-source, server-side scripting language powering nearly 70% of all websites) — shows just how differently these weaknesses can play out, and how distinguishably they can hurt.

 

There is a warning closer to home, too. State Bank of India (SBI) has identified 3,897 customer records circulating on the dark web containing personally identifiable information during a preliminary scan of data. The Bank says it examined around 375,000 records in all, and has appointed an independent cybersecurity agency, empanelled by the Indian computer emergency response team (CERT-In), to investigate the suspected compromise.

 

The Internet Freedom Foundation (IFF), however, raised a pointed question: Had SBI actually told the affected customers? Its disclosure to the stock exchanges, the IFF noted, didn't make clear whether those customers had been notified directly — and it called for that communication to happen without further delay.

 

There is a lesson in all of this for ordinary people, companies and chartered accountants (CAs) alike: a data breach does not automatically mean your money has been stolen. But it can hand criminals exactly the information they need to come after it later. The right response is not panic. It is working out what was actually exposed, securing the accounts that matter, and staying alert for anyone trying to exploit what's leaked.

 

 

One of the more unsettling incidents involves eMudhra's international website-security certificate business. Digital certificates allow your browser to verify that a website is who it claims to be — they are the backbone of secure HTTPS connections.

 

 

According to a CERT-In advisory issued on 21 October 2026, eight intermediate certificate authorities were affected after their private keys were generated with insufficient randomness. That weakness meant the keys could be recovered almost instantly, potentially letting someone forge fraudulent certificates to impersonate genuine websites. CERT-In made it clear that eMudhra's separate digital signature certificate and eSign services were not affected by this incident.

 

For most ordinary users, the immediate risk has been contained by browser-makers, who moved quickly to block the affected certificates. But there is a technical catch worth noting: not every application verifies certificate revocation the same way browsers do. Some server-side software relies on certificate stores that are not automatically updated in the same sweep.

 

For most people, the sensible response is simply this: keep your browser, operating system and apps updated and never override a certificate warning just because a website looks familiar. If your browser says a connection is not safe, that is not the moment to enter your banking details, passwords or card information — whatever the site claims to be.

 

Businesses need to go further. According to security experts, IT teams should check whether their servers, applications, or container images rely on any affected certificates, update the relevant certificate stores, and thoroughly test everything once the issue is fixed. 

 

Do not try this on your home or personal PC or laptop. This genuinely is not something you should try to patch your system by running unfamiliar commands you have found online.

 

 

The third incident involves two critical vulnerabilities in PHP, the programming language that quietly runs a huge share of the world's websites. Tracked as CVE-2026-109618 and CVE-2026-109619, these flaws could let an unauthenticated attacker execute malicious code on vulnerable servers. Security advisories published by PHP on 21 October 2026 urged organisations to apply the available fixes urgently.

 

In plain terms: a criminal may be able to exploit a vulnerable server before ever logging into the website at all. 

 

The reason is that PHP runs on a web server, processes data and returns the result to the user's browser as standard HTML. Therefore, a password-protected dashboard, or a site's usual login checks, may do nothing to stop an attack that never needed to log in in the first place.

 

Nevertheless, remember, this is primarily a warning for website owners, hosting-providers and IT administrators. They should identify exactly which PHP versions are running, install the appropriate security updates, and remove or discard any unsupported versions that no longer receive patches. When immediate patching is not possible, systems need to be isolated or protected using mitigation steps recommended by qualified administrators and the official advisory. No web developer should assume a site is safe simply because its visible pages are still loading normally, PHP said.

 

For small businesses — including those who have outsourced their website to someone else entirely — ask your hosting provider or developer, in writing, whether the site runs an affected PHP version, when it was patched, and whether the logs have actually been checked for suspicious activity. Keep that response on file.

 

According to BuiltWith, at present there are 23.96mn (million) customers who use PHP. It includes Wikipedia, Facebook, WordPress, Flickr, Yahoo and Mailchimp, among others.

 

 

The incident involving PingCAP, which runs the TiDB Cloud database service, shows a rather different kind of danger — one where stolen access credentials let an attacker walk straight through the front door, without needing to break any locks at all.

 

PingCAP says an unauthorised party used stolen service-account credentials to access certain internal systems between 9th September and 7 October 2026, copying data and lifting source code along the way. The company began disabling the affected credentials the moment it discovered the breach, on 7 October 2026. Its investigation found exposed information including account and contact details, SQL editor text and error logs, project information, and some business and billing records. PingCAP maintains it has found no evidence that data stored within TiDB itself was touched, though its investigation continues.

 

Reports around this incident have also raised a separate, more familiar concern: secrets and credentials turning up in support tickets. It is a useful reminder that a password, a cloud access key or an application programming interface (API) key pasted into a help-desk ticket can become a genuine security risk the moment that ticketing system — or the provider's own environment — is compromised.

 

So what should you actually do if your organisation uses TiDB Cloud? Security experts advise you to follow the provider's security updates closely and work out which of your records were affected. Rotate every relevant API key, database password and cloud credential — especially anything that was ever shared in a support ticket, a log, or an attachment. Revoke old keys outright rather than simply generating replacements alongside them. Review your access logs for anything unfamiliar, check whether any exposed keys carried excessive permissions, and watch for unexpected downloads, new users, or changes to your cloud storage.

 

If a single key could access several systems, assume all of them need to be reviewed until the investigation proves otherwise. And don't wait around for evidence that money has actually gone missing — a leaked credential can just as easily be used to enter a system, quietly copy data, or simply plant a foothold for a bigger attack later.

 

 

The SBI incident brings all of this much closer to home for millions of Indian households. The Bank's preliminary analysis of roughly 375,000 dark-web records identified 3,897 customer records containing personally identifiable information — names, mobile numbers, dates of birth, email and residential addresses, customer identifiers, and loan-related records. SBI insists customer balances remain safe, and that an independent cybersecurity agency is now investigating.

 

After the Internet Freedom Foundation (IFF) and the media called on SBI to notify affected customers directly, the lender responded. In a post on X on 23 October 2026, SBI said it has individually informed all customers whose data was identified as being involved, through email and/or WhatsApp. "We reiterate that your account balances and funds are safe with us."

 

An important point here is that a name and mobile number alone probably won't get anyone into your bank account. But combine them with a date of birth, an address, a customer ID or loan details and suddenly a fraudulent call or message becomes a great deal more convincing. A criminal might pose as a bank employee, claim there is an issue with a loan application, or ask you to ‘confirm’ a transaction — and the personal details they already hold will make them sound entirely genuine.

 

If you are an SBI customer, don't assume your account has been compromised just because records have surfaced online. Equally, don't dismiss the risk simply because your account balance is not reduced. Stay alert to unexpected calls, emails or messages referencing your personal or loan details. Never share a one-time passcode (OTP), personal identification number (PIN), password or card verification value (CVV) code with anyone, and never install an app or share your screen because a caller claiming to represent the bank asks you to.

 

Use the bank's official contact channels to verify anything that feels even slightly off. Check your transactions and account alerts regularly. And if you spot an unauthorised transaction, contact the bank immediately, secure the affected payment method, and report it through the proper channels — including the national cybercrime free helpline 1930. Speed genuinely matters when you are trying to limit the damage.

 

 

Chartered accountants (CAs) are not responsible for managing a client's technology or IT systems. But they are often among the first people a client calls when a bank account is misused, invoices get tampered with, or confidential records turn up somewhere they shouldn't. CAs are well placed to help organise the response, preserve the evidence, and work out the financial fallout.

 

Start by asking exactly what information or access may have been exposed — customer records, payroll data, tax documents, banking credentials, supplier details, cloud access keys, accounting-system logins. Help the client document the incident properly: the date it was discovered, which systems were involved, what steps were taken, and any suspicious transactions that followed. Preserve the relevant emails, logs, invoices and bank statements, rather than deleting anything in a rush to tidy up.

 

Next, make sure the client contacts their bank and relevant service-providers, changes any compromised credentials, revokes any exposed access and reviews recent transactions and account permissions. If a website or cloud system is involved, bring in a qualified cybersecurity specialist — a password change alone will not help much if an attacker has already copied data or built another way back in.

 

CAs should also help assess whether the incident touches financial reporting, customer obligations, contractual commitments or applicable notification duties. Where personal data may be involved, the client needs proper legal and privacy advice on what they are obliged to do next. Do not promise that a breach is harmless before the facts are in, and do not tell affected customers their information is safe simply because no financial loss has been identified yet.

 

Finally, it is worth reviewing the basics before the next incident arrives: multi-factor authentication (MFA), unique passwords, restricted access to financial systems, secure handling of customer documents, regular software updates, tested backups and a clear incident-response plan. Employees should be told plainly never to paste passwords, API keys, or customer secrets into support tickets or unapproved tools.

 

The common thread running through all these incidents is not that every breach ends in fraud. It is that small weaknesses can ripple far beyond the system they started in. A compromised certificate, a leaked cloud key, an unpatched website, a customer record floating around the dark web — any one of these may just be the first step in a much longer chain. 

 

The right time to act is the moment the exposure comes to light — not when the first fraudulent transaction finally appears on an SMS or your bank statement.