Cybersecurity Awareness Month Is Going Great: 12 Real Incidents, One Month, and Why You Could Be Next

October is Cybersecurity Awareness Month, and attackers clearly did not get the memo: twelve serious, publicly reported incidents landed in this one month alone.

They hit banks, police records, government-linked trust services, developer platforms, popular programming languages, and one of the world's biggest professional services firms. Some were careless mistakes, like a private key left exposed. Some were clever attacks, like malware slipped into a trusted software package. Some were old problems that never got fixed.

In this post we walk through all twelve in plain language, look at what they have in common, and explain why the honest answer to "could this happen to us?" is yes. We finish with a practical checklist and a short note on how GTIS can help. The details below come from public threat-intelligence reporting from October 2026. Where a claim is still unverified, we say so.

The 12 incidents at a glance

Here is the full list in one place. Each one is explained in the sections that follow.

Leaked data and identities

• eMudhra: a private key was exposed, and 8 keys were allegedly forged over 17 months.

• SBI: mobile numbers, dates of birth, addresses and loan data of 3,897 customers were found online.

• Rajasthan Police: 70,000 identity records leaked, with 59,460 phone numbers offered for sale.

• PHP (8.2): a critical remote code execution flaw affecting about 70% of the web, including WordPress, Drupal and Laravel.

• GitLab: remote code execution with no login needed.

• Node.js: 10 CVEs patched, including RCE and a TLS bypass, with exploits already in the wild.

• Plex: the Plex/Plex2Shell flaw is being actively exploited.

• Railway: API keys and database passwords exposed in a breached environment.

• OpenCode: leaked API keys that could be misused for console access and data theft.

• PyPI: malware in v1.107.0 that steals credentials and works as a backdoor.

• FortiGate: the FortiBleed leak put about 74,000 firewall VPN logins in circulation, now tied to ransomware.

• PwC: the Everest group claims 590 GB of HR data was stolen through a third-party vendor (unverified).

Part 1: When identity and trust are what leak

The first three incidents are about the thing every digital service depends on: knowing who someone really is.

eMudhra: a private key that was not private. eMudhra provides digital trust services, the kind of technology that proves a signature or certificate is genuine. The report says one private key was exposed and that eight keys were allegedly forged over 17 months. Think of it as a master key to a building being copied. Everything that relied on that key, for a year and a half, was only as trustworthy as the person holding the copy. The lesson is that a key's secrecy is the whole security model, and if you cannot say who has touched a key, you cannot say it is safe.

SBI: personal and loan data found online. Details of 3,897 customers were reported to be publicly findable, including mobile numbers, dates of birth, addresses and loan information. That is exactly what a fraudster needs for a convincing phone call that starts with "I'm calling from your bank about your loan." Even a leak this size, small by bank standards, gives scammers a ready-made target list.

Rajasthan Police: records and phone numbers for sale. Around 70,000 identity records were reported leaked, with 59,460 numbers offered for sale. When the people who investigate crime become a data source for criminals, the damage goes beyond privacy. It touches public trust and, in some cases, personal safety.

The common thread: in each case, sensitive material that was not tightly controlled was enough to cause real harm.

Part 2: The software everyone runs had critical holes

Four of the twelve incidents are flaws in widely used software. Two phrases come up again and again, so here is what they mean:

• Remote code execution (RCE): an attacker can run their own commands on your server from afar. It is usually the most severe kind of bug.

• Unauthenticated: the attacker does not need a username or password to do it.

PHP (8.2). A critical RCE was reported in PHP, which powers a huge share of websites. The report puts the reach at about 70% of the web, including WordPress, Drupal and Laravel sites. You do not have to write PHP yourself to be exposed; your website, your blog or a plugin vendor may be running it for you.

GitLab. An unauthenticated RCE means a stranger could take over a server that holds your source code, pipelines and often your secrets, without logging in at all.

Node.js. Ten CVEs were patched, including RCE and a TLS bypass, and the report says exploits were already in the wild. In other words, attackers were using these flaws before many teams had finished reading the advisory.

Plex. The Plex/Plex2Shell issue is under active exploitation. Plex is a home and small-office media server, which shows how attackers go after anything exposed to the internet, not just corporate systems.

The pattern is speed. Once a flaw is public, the gap between "patch released" and "attackers using it" can be days or even zero. Every day an unpatched server sits online is a day of open risk.

Part 3: Leaked keys and poisoned packages

Modern software is built on secrets (API keys, database passwords, tokens) and on code borrowed from other people. Three incidents this month show what happens when either one goes wrong.

Railway. API keys and database passwords were exposed in a breached environment. Credentials stored in an environment are only as safe as that environment. Once it falls, every system those secrets unlock is at risk too.

OpenCode. Leaked API keys could be misused for console access and data theft. An API key is effectively a password for software. Anyone who finds one can act as your application, often with no alert and no second factor.

PyPI. Malware was found in version 1.107.0, designed to steal credentials and act as a backdoor. This is a supply-chain attack: instead of breaking into thousands of companies one by one, the attacker poisons something thousands of developers already trust and lets them install it themselves. If your build pulled that version, the malware ran inside your own environment.

What connects them is trust. We trust our cloud platforms, our dependencies and our keys, usually without checking. Attackers are betting we will keep doing so.

Part 4: Your front door and your vendors

The last two incidents are about the edges of an organization: the firewall at the perimeter and the partners outside it.

FortiGate (FortiBleed). About 74,000 firewall VPN logins were reported leaked and are now tied to ransomware. A VPN login is a front-door key to a company network. When valid credentials are on sale or in circulation, a ransomware crew does not need to break in. It can simply sign in. If your organization runs these devices, the questions are whether they are patched, whether those credentials were rotated, and whether MFA is enforced on every VPN account.

PwC (claimed). The Everest ransomware group alleges it stole 590 GB of HR data through a third-party vendor. This is a claim, not a confirmed finding, and the report itself marks it as unverified. Even so, the pattern is real and common. The target was not the firm's own network but a vendor connected to it. Your security is only as strong as the weakest company you share data with.

A fair note on sources: public reporting in the early days of an incident is often incomplete and later gets corrected, so treat numbers and attributions as reported, not final.

What the twelve have in common

Four themes run through all of them, and none of them is exotic.

• Secrets are the new crown jewels. Four of the twelve involve exposed or forged keys, passwords or logins (eMudhra, Railway, OpenCode, FortiGate). One leaked secret can unlock everything behind it.

• Patching is a race. Four are software flaws, and some were exploited before most people had patched (PHP, GitLab, Node.js, Plex).

• Trust is exploited. Malicious packages, vendors and trusted platforms were used to reach the real target (PyPI, PwC, Railway).

• Data lives longer than we think. Records from banks and police were still findable or for sale well after they were collected (SBI, Rajasthan Police).

None of these themes requires a nation-state attacker. They reward the basics done well and punish the basics done late.

You could be next, and so could your organization

It is tempting to read this list and think, "Those are big names. We are too small to be a target." That belief is exactly what attackers count on.

Look at who was on the list: a bank, a police force, a security vendor, a Big Four firm, and open-source tools used by ordinary developers and hobbyists. Attackers did not choose them for their fame. Automated scanners look for any exposed server, any reused password, any unpatched version, and any leaked key. They do not check who owns it first.

Here are five honest questions to ask this week:

1. Do you run any of the affected software? PHP, GitLab, Node.js, Plex, FortiGate, or a website built on WordPress, Drupal or Laravel. Do you know which versions, and who is responsible for updating them?

2. Could a leaked key or password be hiding in your code, logs or cloud settings? Most teams have at least one old key nobody remembers creating.

3. Is MFA enforced everywhere, especially on VPNs, admin panels and email? "Available" is not the same as "enforced."

4. Do you know which vendors hold your data, and what they do to protect it? A vendor's breach becomes your breach notification.

5. If something went wrong tonight, would you find out in minutes or in months? In the eMudhra case, the reported exposure ran for 17 months.

If any of those answers is "I'm not sure," that is useful information. It means the gap is visible now, while you can still close it on your own terms instead of after an incident.

What to do this week

The closing line of the October roundup says it best: patch, rotate credentials, enforce MFA, vet your vendors. Here is how to turn that into a checklist.

Patch

• List every internet-facing system and the software version it runs

• Update PHP, GitLab, Node.js, Plex and FortiGate firmware to the latest fixed versions

• Update CMS platforms and plugins (WordPress, Drupal, Laravel packages)

• Set an owner and a deadline for critical patches (days, not months)

Rotate credentials

• Rotate API keys, database passwords and tokens, starting with anything stored in environments or repositories

• Scan code, logs and CI settings for hard-coded secrets

• Reset VPN and firewall credentials if you run FortiGate

• Review who can access signing keys and certificates, and replace them if in doubt

Enforce MFA

• Turn MFA on for VPN, email, admin consoles, cloud and code platforms, with no exceptions

• Remove old accounts and unused access

Vet your vendors

• List the third parties that hold your data or have network access

• Ask each one how they protect it and how fast they would tell you about a breach

• Pin and review software dependencies, and avoid auto-updating production to brand-new package versions

Be ready

• Write a one-page incident plan: who decides, who is called, who talks to customers

• Turn on logging and alerts so unusual logins and data transfers get noticed

How GTIS can help

A checklist is a good start, but the hard part is knowing where you stand and keeping it that way. That is what GTIS (Globaltech & Infosec Pvt. Ltd.) focuses on, through two connected practices: baseline management and risk assessment.

• Baseline management defines what "secure" looks like for your systems (configurations, patch levels, access rules) and checks regularly that you still match it. Many of this month's incidents, such as unpatched servers, forgotten keys and weak VPN access, are baseline drift.

• Risk assessment identifies your assets, threats and weaknesses, scores each risk, and builds a prioritized register so your time and budget go to what matters most. Each finding comes with a remediation plan and an owner, so nothing is left sitting in a report.

Together they answer the questions from this post in an organized way: what do we run, where are we exposed, what do we fix first, and how do we know it stayed fixed?

October ends, but the threats do not. If you want a clear view of your own exposure before it shows up in someone else's roundup, get in touch with the GTIS team for a risk assessment conversation.

Contact GTIS — Get Expert Cybersecurity Consultation | GTIS

Stay patched, stay skeptical, and use MFA.

Sources: public threat-intelligence reporting, October 2026. Claims about PwC and the Everest group are unverified and alleged.