By Deepak Kumar Nath | Cybersecurity Entrepreneur and Technology Leader
October 2026 was a reminder that cybersecurity is no longer just an IT concern. It is a business priority, a leadership responsibility and the foundation of digital trust.
Two developments stand out. On 18 October, eMudhra revoked eight intermediate certificate authorities after a cryptographic weakness was found. On 21 October, the LiteLLM project disclosed a malicious release distributed through PyPI and container registries. Both show how a weakness in trusted technology can cause damage far beyond where it first appears.
For business leaders, the real question is not how many incidents occurred. It is whether your organisation can identify its exposure, contain a compromise and recover before a technical problem becomes a business crisis. That is the central lesson of what I call Black October: our digital ecosystem runs on layers of trust, and every layer needs continuous testing.
Black October 2026: The Incidents Every Business Leader Should Understand
This timeline separates when an incident happened from when it became public. It covers confirmed disclosures and vulnerabilities, though some investigations are still ongoing.
15–16 October | Rank Math PRO: a trusted WordPress plugin was compromised. Some downloads of Rank Math PRO version 3.0.123 contained malware during a defined distribution window. The vendor removed the affected files and released version 3.0.124. The free WordPress.org version was not affected.
Lesson: a download from a legitimate vendor can still be dangerous if its distribution process is compromised, and updating the plugin may not remove persistence already established on a website.
16–19 October | ConnectWise Cloud Backup (formerly SkyKick): application identities compromised. ConnectWise reported unauthorised access involving application identities in this environment. It suspended affected services, disabled identities, reset credentials and began a phased recovery. Its initial statements said there was no indication that partner backup data had been compromised.
Lesson: service-provider credentials can reach deep into customer environments. Review third-party application permissions and investigate your own tenants rather than assuming a provider’s containment settles every downstream risk.
17–18 October | eMudhra: weak intermediate certificate keys. An independent researcher reported that eight eMudhra Global TLS intermediate certificate authorities had weak private keys, caused by insufficient randomness during key generation. eMudhra revoked them on 18 October and said they had not issued end-entity certificates, with no infrastructure compromise or customer-data breach. CERT-In also issued an advisory.
Lesson: digital trust depends on the processes behind certificates, not just the presence of encryption. Track your certificate dependencies and trust-store updates.
19 October | OVHcloud CLI: malicious release binaries. OVHcloud disclosed that a compromised developer account was used to replace command-line interface binaries with malicious versions. The affected downloads (releases 0.11.0 to 0.15.0) were available for about 93 minutes. The company said its source code and build chain were not affected and released a clean version, 0.16.0.
Lesson: a clean source repository does not guarantee safe binaries. Release integrity, signed artefacts and controlled publishing permissions matter.
19–22 October | OpenCode and Railway: exposure of AI and cloud credentials. OpenCode notified some users that API keys used with external AI providers had been exposed. Separately, Railway reported unauthorised access to internal systems and possible decryption of environment variables containing secrets. Its preliminary report estimated that up to 1.85% of workspaces may have had some variables potentially compromised, which is an exposure estimate, not a confirmed count.
Lesson: API keys and environment variables can unlock AI services, databases, cloud accounts and pipelines. Rotating secrets must go hand in hand with log review and investigation of any access gained.
21 October | LiteLLM: a malicious release reached PyPI and container registries. LiteLLM confirmed that version 1.107.0 was compromised. The malicious files used Python startup mechanisms to run code automatically, creating a risk of credential theft. The package was removed and the project published a detailed account of the attack chain. CERT-In issued an advisory on 23 October.
Lesson: supply-chain incidents can hit systems even when the compromised package’s main functionality isn’t in use. Inventory your dependencies and review your build environments.
21–23 October | PHP2Shell and GitLab: critical vulnerabilities. Two PHP vulnerabilities, CVE-2026-109618 and CVE-2026-109619, were disclosed on 21 October. Exploitation could allow remote code execution or access to sensitive process memory. CERT-In also published a critical advisory on multiple GitLab CE/EE vulnerabilities on 22 October. Check the exact products and versions you run against the advisories.
Lesson: once a vulnerability is public, an unpatched system becomes an urgent operational risk. Asset visibility and a tested emergency-patching process shorten the gap.
This timeline is not proof of a single coordinated campaign. Each incident had its own circumstances.
India’s Cybersecurity Picture: Data Exposure, Ransomware and Digital Trust
These global incidents matter to Indian enterprises, but the domestic picture deserves attention in its own right. India’s digital economy rests on banking systems, manufacturers, public services, cloud infrastructure and third-party providers, and a weakness in any of them can reach customers and partners well beyond the original organisation.
1. SBI: reported exposure of 3,897 customer records. On 21 October, Reuters reported that the State Bank of India had disclosed a cyberattack involving 3,897 customer records found on the dark web. The data reportedly included names, mobile numbers, dates of birth, email and residential addresses, customer identifiers and loan records. SBI said it had engaged an independent cybersecurity agency and that account balances remained safe. Records appearing on the dark web are a serious warning, but they don’t by themselves establish how the data was obtained or which systems were compromised. The investigation will clarify that. Even without balances, this kind of personal data can fuel targeted phishing, identity fraud and social engineering, which is why data minimisation, access monitoring, third-party risk management and clear communication matter so much for financial institutions.
2. Tata Electronics: supply-chain risk reaches manufacturing. In June 2026, Tata Electronics confirmed an incident affecting some of its systems after the World Leaks extortion group claimed to have published confidential documents. Reuters reported that the full dataset’s authenticity could not be independently verified, and the company said operations were unaffected. Even when production continues normally, manufacturers hold designs, engineering documents and partner information that are commercially sensitive. Supplier security deserves board-level attention, backed by controlled access, monitoring, clear reporting obligations and tested response plans, not just contractual assurances.
3. Bank of Baroda: identity is a critical security boundary. In July 2026, Bank of Baroda confirmed unauthorised access to certain data through a compromised employee email account. The bank said its core banking systems remained secure, and the full scope of the data accessed was not publicly established. An email account can open the door to correspondence, documents and other systems. Multifactor authentication, session monitoring, least-privilege access and rapid account containment matter even for organisations with mature network security.
4. Bajaj Auto: containment and continuity matter. Bajaj Auto disclosed a ransomware incident on 23 June 2026 affecting the company and its technology subsidiary. It said it had taken precautionary measures, that the impact had been mitigated based on information available at the time, and that it had reported the incident to CERT-In. Public disclosures did not establish whether data was stolen. Not every ransomware incident can be contained without disruption, but response speed, network segmentation, management coordination and external incident-response support influence how far an attack spreads.
5. HDFC Asset Management: internal infrastructure as a pressure point. Court material on HDFC Asset Management’s May 2026 incident describes problems accessing its VMware environment, disruption to several infrastructure components and an extortion message claiming data had been exfiltrated. Such claims should not be treated as proof that the alleged volume of data was actually stolen. The practical takeaway: separate critical infrastructure, control privileged accounts tightly, monitor lateral movement and keep backups isolated from the credentials and systems used in production.
Together, these cases show that cybersecurity can’t be reduced to a vulnerability score or a count of leaked records. Organisations need to understand the path an attacker might take, what that path could reach and how quickly they could contain it.
A cyber-aware workforce and citizen base form the foundation of a cyber-safe future.
What These Incidents Reveal About Enterprise Security
- Trust can be exploited. Packages, certificates, plugins and third-party services are trusted because they come from established providers. That trust needs verification, secure release practices and continuous monitoring.
- Credentials widen the blast radius. A stolen API key or privileged identity can open systems far beyond the original point of compromise. Restricting permissions and revoking exposed credentials quickly limits the damage.
- Gaps aren’t always sophisticated. Unpatched systems, secrets committed to repositories and overly broad cloud permissions are still common. Basic controls remain essential.
- Detection is only the beginning. Organisations also need to contain, investigate, communicate with affected parties and restore services safely.
None of this is purely technical. It takes coordination across IT, security, engineering, legal, compliance and leadership.
Seven Actions Enterprises Should Prioritise Now
Rather than reacting to every headline with a disconnected security purchase, I believe organisations should focus on these:
- Build an accurate asset inventory. Know your internet-facing applications, cloud resources, APIs, dependencies, certificates and admin interfaces. Unknown assets mean unknown risks.
- Prioritise critical vulnerabilities. Weigh severity alongside exploitability, exposure, available mitigations and business impact. Patch verified fixes promptly and document exceptions.
- Rotate exposed credentials and investigate their use. Revoke affected keys, tokens and certificates, then review authentication logs, cloud activity, source-control history and unusual resource consumption. Rotation can’t undo what an attacker has already done.
- Strengthen software supply-chain controls. Use dependency scanning, trusted sources, integrity verification, protected release pipelines and restricted publishing rights. Maintain SBOMs where feasible.
- Improve detection and response. Centralise logs, monitor privileged activity, set clear escalation paths and make sure alerts reach people who can act. A SOC should help contain incidents, not just generate alerts.
- Validate backups and recovery plans. Keep recovery copies isolated from production credentials, restrict access and test restores regularly. Confirm recovered systems are trustworthy before reconnecting them.
- Test controls continuously. Use vulnerability assessments, authorised penetration testing, application and API security testing, configuration reviews and incident-response exercises to find weaknesses before an attacker does.
The goal isn’t to eliminate every risk. It is to reduce the likelihood of compromise, limit its impact and improve your ability to recover.
AI Security: A New Layer of Enterprise Risk
The October incidents involving AI development tools and exposed API credentials show why AI security belongs alongside conventional application and infrastructure security. AI tools often connect to code repositories, databases, cloud platforms and external model providers. If those integrations use excessive permissions or poorly protected credentials, a compromise can spread into other business systems.
At the same time, AI can help defenders with alert analysis, threat investigation, anomaly detection and workflow automation, provided there is proper human oversight and access control.
My view is simple: adopt AI where it creates real value, but understand what data it can access, which credentials it uses, what actions it can take and how those actions are monitored. AI adoption without security governance creates risks that are hard to see until an incident occurs.
Building Cyber Resilience Beyond Compliance
Compliance frameworks provide structure, but a successful audit doesn’t guarantee lasting security. Vulnerabilities appear between assessments, employees adopt new tools, suppliers change their systems and attackers adapt. Resilience is an ongoing cycle of assessment, remediation, monitoring, response and recovery.
At Threatsys, this is how we approach cybersecurity: helping organisations find weaknesses, understand their exposure and strengthen their defences through VAPT, application and API security testing, security monitoring and incident response.
For business leaders, the key is tying these activities to measurable outcomes. How quickly are critical vulnerabilities fixed? How long does it take to detect suspicious activity? Can privileged access be revoked fast? How reliably can critical systems be restored? Measures like these turn cybersecurity from a set of technical controls into a practical business capability.
The Next Vulnerability Will Not Wait
Black October should be remembered not just for the incidents themselves, but for the questions they raise about preparedness, accountability and digital trust. Do we know which systems are exposed? Can we spot compromised credentials before they become a wider incident? Are our third-party dependencies monitored? Can our teams contain an attack without losing control of critical operations? Have we tested whether our backups will actually work when we need them?
Every enterprise should be asking these questions now, not after a breach.
The strongest organisations won’t necessarily be the ones that never face an incident. They will be the ones that understand their risks, act decisively, learn from failures and recover without letting a technical compromise become a prolonged business crisis.
Threats evolve. Our preparedness must evolve faster. Security never takes a month off, and neither should our commitment to building a safer digital future.
About the Author
Deepak Kumar Nath — MD & CEO, Threatsys Technologies; Entrepreneur, Cybersecurity Expert, Lead Auditor, TedxSpeaker; CISA, CISSO, CCISO, CPENT, LPT, CIPP, CPTE, CEH, ISO 27001 LA, CHFI, ECSA.
