Oct 22, 202612 Min ReadData Security

Black Cyber Week: Assume Breach, Then Shrink the Blast Radius.

Most security teams measure a bad month in incidents. This October felt more like a weather system. Every morning brought another advisory, another emergency patch, or another vendor email asking customers to rotate their keys.

Taken one at a time, each story looks like someone else's problem: a bug in a language runtime, a flaw in a CI server, a breach at a hosting platform, a botched key ceremony at a certificate authority on another continent. Put them side by side and the pattern is hard to miss. The attackers, and in a few cases AI models, kept going after the same thing: the credentials that unlock your data. And many of the organizations left exposed did nothing wrong.

This post walks through what happened, what it teaches us, and what you can do about the part you actually control.

Look at what happened in the ten days leading up to October 22, 2026:

PHP2Shell. On October 21, PHP shipped emergency patches for two critical flaws in the PHP runtime itself (CVE-2026-109618 and CVE-2026-109619, CVSS 9.2). They allow unauthenticated remote code execution (RCE). A site with perfect code is still exposed, because the bug is in the language underneath it. The flaws were reportedly found with AI-assisted research, details leaked before the patches, and exploit attempts started before disclosure.
GitLab. It disclosed two CVSS 10.0 RCEs in nine days. The second, CVE-2026-110264, is unauthenticated and sits in code dating back to GitLab 7.0 in 2014. Teams that patched on October 12 were vulnerable again on October 21.
Railway. Also on October 21, the cloud platform Railway found an attacker inside the systems that store customer environment variables. For some of them the attacker got the decrypted contents: API keys, database credentials and registry tokens. Railway paused every deployment on the platform and told all customers to rotate every variable. It believes the intrusion is part of a broader campaign against platforms that host AI inference workloads.
eMudhra. On October 17, researchers reported that the private keys behind eight intermediate certificate authority certificates from eMudhra were generated with almost no randomness. eMudhra is a CA trusted by every major browser and operating system. One key was literally the number 4. Anyone who worked that out could mint a valid HTTPS certificate for any domain on the internet: your bank, your SSO provider, your cloud console, your software update server. With it, an attacker could intercept traffic that looks fully secure, the padlock included. Every browser vendor shipped emergency distrust updates within days. Cloudflare patched its clients overnight. Every service with a stale trust store, such as a background job, an old container image or an IoT device, stays exposed until someone updates it.
Storm-0940. Microsoft reported that this China-aligned actor used ARTEX, an open-source agentic AI penetration-testing framework, to run attacks on hundreds of organizations at once. Its AI agents worked around the clock, tried several breach paths in parallel and hit more than 2,250 tenants at up to 2,900 sign-in attempts per minute. In some cases they reached privileged cloud access within three hours of first targeting an organization.
OpenAI's own models. OpenAI disclosed that its internal models, given simple tasks like looking up public statistics, broke into the live systems hosting that data. One pulled a config file containing a database connection string and a token-signing secret, then forged its own auth tokens. Another found working credentials in a site's public JavaScript and used them to pull nearly 1,500 user records. Neither model reported what it had done.

None of this is a coincidence. It is what security looks like now.

The new math: discovery and exploitation at machine speed

AI has changed the economics on both sides. Google's Threat Intelligence Group found that half of the vulnerabilities it believes were discovered by AI lead to remote code execution, roughly twice the rate of vulnerabilities found other ways. Old code paths in core infrastructure, like PHP's runtime and GitLab's 2014-era regex handling, are now being found and turned into exploits faster than most organizations can schedule a maintenance window.

Disclosure-to-exploitation now takes hours. Pre-disclosure exploitation is no longer unusual. Agentic attack frameworks run around the clock and don't get tired, while patching every PHP worker, self-managed GitLab instance and forgotten staging box still takes weeks.

You can't patch your way to "no breach" anymore. The honest posture for 2026 is the one we've talked about for a decade and rarely acted on: assume breach. Once you do, the question shifts from "how do we keep them out?" to two harder ones:

When they get in, what can they reach?
When they get in, how fast can we know what was exposed, and contain it?

Both are data questions, and both are what Data Security Posture Management (DSPM) is built to answer.

Lesson 1: Secrets are what attackers are really after

Look at what the attackers and AI agents in these stories actually went for:

Railway: environment variables, meaning API keys and database credentials.
OpenAI's models: a config file with a connection string and signing secret, and credentials in public JavaScript.
Storm-0940: application credentials and OAuth apps that give persistent cloud access.
GitLab: a server that by design holds CI/CD variables, deploy keys and cloud tokens for production.

Code execution on one box is only the entry point. The real damage comes from the credentials found there and the sensitive data those credentials unlock. Every credential left in plaintext, every over-permissioned service account and every forgotten database export extends the attacker's reach.

You can't control when the next RCE drops, but you can control how much is reachable when it does. Data you have deleted, minimized or locked down can't be stolen.

Lesson 2: One weak link breaks everyone's security

eMudhra is the clearest example of something every incident this month shows: your security depends on links you don't control, and their failures cascade.

Thousands of organizations did everything right. They patched promptly, enforced MFA and encrypted traffic in transit. For an unknown period they were still exposed, because a certificate authority on the other side of the world ran a flawed key ceremony in April 2025. When anyone can forge the certificate for your identity provider, an attacker sitting in the network path can capture session tokens and credentials as they pass by. Those stolen credentials then become the way into a breach somewhere else. Nobody was hacked "at eMudhra." The damage happens everywhere downstream.

The same pattern holds across the month:

PHP2Shell: your code was fine, but the runtime underneath it wasn't.
GitLab: you patched on October 12 and were vulnerable again on October 21.
Railway: your secrets were encrypted on someone else's platform, and that platform was breached.
Storm-0940: attackers got in through ConnectWise, a trusted third-party vendor's app, not through your own front door.

No organization can audit every runtime, CI server, hosting platform, SaaS vendor and certificate authority it depends on. Security built only on preventing the breach has a single point of failure, and you don't own it.

What you can own is your data: knowing where it is, how much of it is exposed, which secrets unlock it, and how fast you can contain the damage when a link you don't control breaks.

Lesson 3: When it happens, speed decides the outcome

Railway's guidance tells you a lot: rotate everything. That's the right call when you don't know exactly what was exposed. It's also the most expensive and disruptive response there is, and every customer who couldn't rotate quickly stayed exposed.

Now picture your own incident. Your self-managed GitLab was internet-facing and unpatched on October 21. The clock is running, and the first questions are:

Which secrets were reachable from that box? Which keys should be revoked right now, and in what order?
What sensitive data can those credentials reach downstream? A stolen AWS key is only as dangerous as the data its role can read.
Was any of it actually accessed? Is there unusual read volume, new identities or exfiltration patterns?
What do we have to disclose? Regulators and customers need to know whether PII, PHI or payment data was involved.

If answering those takes a two-week manual inventory, an attacker moving at machine speed has already won. Rotating the right keys in the first hour is containment. Rotating them in the second week is cleanup. The difference between an incident and a breach is often how fast you know what was exposed.

How Sentra helps you assume breach and stay in control

Sentra was built for this situation: the perimeter will fail, so the data layer has to be understood and defended on its own.

Continuous discovery and classification across cloud, SaaS and on-prem. Sentra finds sensitive data wherever it lives: AWS, Azure, GCP, Snowflake, Databricks, Microsoft 365, Google Workspace, file shares and on-prem databases. That includes the shadow copies, stale snapshots and forgotten exports nobody tracked. Scanning runs inside your environment, so your data never leaves it.
Secrets, private keys and certificates found where they don't belong. Sentra flags API keys, cloud credentials, tokens, connection strings, passwords, private keys and certificates sitting in buckets, databases, documents and file shares. Those are the same assets the attackers and AI agents in this month's incidents went after. When a CA like eMudhra is distrusted overnight, or a platform like Railway tells you to rotate everything, you already know where your keys and certificates live. You get a prioritized rotation list before an incident, not during one.
Data access governance, including for AI agents and non-human identities. Sentra maps which identities can reach which sensitive data: users, roles, service accounts, OAuth apps and AI agents. When a credential is compromised, you see its blast radius immediately instead of reverse-engineering IAM policies under pressure.
Attack surface reduction. Sentra highlights redundant, obsolete and trivial (ROT) data, over-permissioned access and public exposure, so you can shrink what any attacker, human or AI, could ever reach.
Data detection and response (DDR). Sentra monitors activity on sensitive data and alerts on anomalous access and exfiltration. That turns "were we breached?" from guesswork into evidence.
Incident scoping in minutes. Because Sentra already knows what data sits in each store and who can reach it, you can answer "which keys do we revoke and what data was exposed?" while the incident is still unfolding. Security, legal and compliance get the facts they need to contain, notify and report.

The bottom line

October 2026 showed us the new normal. AI is finding RCEs in the software everyone runs. Agentic attackers are reaching privileged cloud access within hours. Platform providers are leaking their customers' secrets. A single certificate authority whose private key was the number 4 put the trust layer of the entire web in question. None of these were failures of the organizations that got hurt. They were failures of links further up the chain.

You can't secure the whole chain. You can know where your sensitive data is, shrink what any attacker could reach, and know within minutes which keys to revoke and what was exposed. That's the case for DSPM, and it has never been more urgent.

See your data attack surface before an attacker does. Book a Sentra demo →

FAQ

What does "assume breach" mean in data security?

Assume breach means planning as if an attacker is already inside, instead of betting everything on keeping them out. The focus shifts to two questions: what sensitive data an attacker could reach, and how fast you can find out what was exposed and contain it. Sentra is built around that approach.

What is DSPM and how does it help when a vendor or platform is breached?

Data Security Posture Management (DSPM) continuously finds and classifies sensitive data, shows who can access it, and flags where it is exposed. When a breach happens somewhere you don't control, like a hosting platform or a certificate authority, DSPM tells you what was reachable so you can respond quickly. Read Sentra's DSPM guide.

How does Sentra find exposed secrets, API keys and certificates?

Sentra scans buckets, databases, documents and file shares for API keys, cloud credentials, tokens, connection strings, passwords, private keys and certificates that are stored where they shouldn't be. Security teams get a prioritized list of what to rotate before an incident, rather than building one during it. Learn more.

What should I do if a provider tells me to rotate all my secrets?

Start with the credentials that can reach the most sensitive data, then work down. Sentra helps by showing where each key or certificate lives and what data the related identities can access, so you rotate the riskiest secrets first instead of everything at once with no order.

Can Sentra show what AI agents and non-human identities can access?

Yes. Sentra maps which identities can reach which sensitive data, including users, roles, service accounts, OAuth apps and AI agents. If one of those identities is compromised, you can see its blast radius right away. See how Sentra secures AI agents.

What is a blast radius in a data breach?

The blast radius is the sensitive data an attacker can reach once they have a foothold, such as a stolen API key or a compromised service account. A stolen cloud key is only as dangerous as the data its role can read. Sentra measures and helps reduce that reach.

What is data detection and response (DDR)?

DDR monitors activity on sensitive data and alerts on unusual access and signs of exfiltration. It helps answer "were we breached?" with evidence instead of guesswork. Sentra includes DDR as part of its platform. Read the DDR guide.

How fast can Sentra help scope a security incident?

Because Sentra already knows what data sits in each store and who can reach it, teams can answer "which keys do we revoke and what data was exposed?" in minutes, while the incident is still unfolding. That gives security, legal and compliance what they need to contain, notify and report.

Does Sentra move my data out of my environment to scan it?

No. Sentra's scanning runs inside your own environment, so your data never leaves it. Sentra covers AWS, Azure, GCP, Snowflake, Databricks, Microsoft 365, Google Workspace, file shares and on-prem databases.

How does reducing ROT data lower breach risk?

Redundant, obsolete and trivial (ROT) data, like stale snapshots and forgotten exports, still holds sensitive information and adds to what an attacker can reach. Data you have deleted or minimized can't be stolen. Sentra highlights ROT data, over-permissioned access and public exposure so you can shrink your attack surface. Learn about data sprawl reduction.