Oct 23, 20269 Min ReadData Security

What Is RCE, and Why Your Security Tools Shouldn't Hold Your Data

VP Product Marketing & Analyst Relations

In one week this October, PHP, GitLab and a major cloud platform all made headlines for the same reason: attackers could run their own code on systems they were never supposed to touch. The PHP and GitLab flaws were remote code execution bugs. The cloud platform, Railway, went one step further and told every customer to rotate every secret it was holding for them.

That last part is the lesson most teams miss. When you hand a vendor standing access to your data or your credentials, their breach becomes your breach. And in 2026, the question is no longer whether a vendor gets hit. It is what the attacker finds when they get there.

This post explains what Remote code execution (RCE) is, why it has become the most dangerous class of vulnerability, and why the security tools you trust with your data should be built so that compromising them gets an attacker nothing.

What is RCE?

RCE is a vulnerability that lets an attacker run their own commands on a system they don't own, over a network, without physical access. If ordinary bugs let an attacker peek through a window, RCE hands them the keys to the building.

Most RCE flaws follow the same pattern:

An application accepts input. A web form, an API call, an uploaded file, a regex pattern, a serialized object.
It trusts that input too much. The code fails to validate it, or the parser underneath mishandles it.
The input gets treated as instructions. Instead of being stored or displayed, the attacker's payload is executed by the server.
The attacker now runs code with the application's privileges. Whatever the app can read, write or call, the attacker can too.

That last step is why RCE sits at the top of every severity scale. The October flaws in the PHP runtime (CVE-2026-109618 and CVE-2026-109619) scored 9.2 out of 10. GitLab's regex engine flaw scored a perfect 10. Both were exploitable without logging in.

Why RCE is getting more common with AI

AI agents are now doing both halves of the attacker's job: finding the bug and using it.

On the finding side, Google's Threat Intelligence Group reported that half of the vulnerabilities it believes were discovered by AI lead to RCE, roughly double the rate for bugs found other ways. The GitLab flaw had been sitting in code since 2014. Old code paths that humans walked past for a decade are now being found and weaponized in hours.

On the execution side, agentic frameworks run attacks without a human at the keyboard. Microsoft reported that Storm-0940 used ARTEX, an open-source agentic pentesting tool, to hit more than 2,250 tenants at up to 2,900 sign-in attempts per minute. In some cases its agents reached privileged cloud access within three hours. Even well-meaning agents go off script: OpenAI disclosed that its own models, given simple lookup tasks, broke into live systems, pulled secrets from config files and forged auth tokens to finish the job.

Agents don't sleep, don't wait for a maintenance window and try many paths in parallel. Once one gets code running on a server, it goes straight for the credentials and data that server can reach.

The practical takeaway: you will not patch fast enough to stay ahead every time. Some RCE will land somewhere in your stack or your supply chain. The question is what it reaches when it does.

The worst place for an RCE: a vendor that holds your data

Code execution on one server is only the entry point. The damage comes from what that server can reach: the credentials stored on it and the data those credentials unlock.

Now apply that to your vendors. Many SaaS tools work by copying your data, or a sample of it, into their own cloud. Others keep long-lived credentials to your accounts on their side so their platform can read your data whenever it needs to. Either way, the vendor becomes a single place where an attacker can harvest access to hundreds of customers at once.

This is not hypothetical. In October:

Railway found an attacker inside the systems storing customer environment variables. Some API keys, database credentials and registry tokens were exposed in decrypted form. Every customer was told to rotate everything.
Storm-0940 got into organizations through a trusted third-party app, not their own front door, and hit more than 2,250 tenants.
GitLab servers hold CI/CD variables, deploy keys and cloud tokens by design. An unauthenticated RCE there is a direct line to production.

The customers in these stories mostly did nothing wrong. They trusted a platform that held something valuable on their behalf, and the platform became the target.

The irony is sharpest with security tools. A data security product often needs to see your most sensitive data to classify it. If it does that by pulling your data into its own cloud, or by keeping the keys to read it from outside, you have built the attacker a shortcut to exactly the data you were trying to protect.

Assume breach, including your vendors

Assume breach means planning as if an attacker is already inside. Most teams apply that to their own network. Fewer apply it to the tools they plug into it.

The honest version covers both. For every vendor that touches sensitive data, ask one question: if this vendor is fully compromised tomorrow, what does the attacker get?

The answer is the vendor's blast radius. A vendor that stores copies of your data, or holds standing credentials to read it from outside your environment, has a blast radius as big as your data estate. A vendor whose cloud only ever sees metadata, and holds no keys to your data, has a blast radius close to zero.

You can't control when the next RCE drops in a runtime, a CI server or a SaaS platform. You can control how much of your data sits behind each of them.

How Sentra is built so a breach of Sentra exposes none of your data

Sentra is an agentic data security platform, so it has to understand your most sensitive data. That creates a real design question: how do you give a security tool deep visibility into your data without turning it into another place that data can be stolen from? Our answer was to make sure Sentra’s own cloud never needs to hold your data, or the access to it.

Scanning happens inside your environment. Sentra’s scanners run in your own cloud account or on-prem network. They read and classify data in place, using compute that lives in your environment and is tagged so your team can see exactly what Sentra deployed. Nothing is copied out to be scanned. If an attacker compromised Sentra tomorrow, there would be no stash of customer data waiting for them.
Only metadata leaves. What Sentra’s SaaS receives is the result of the scan: which data store holds which kinds of sensitive data, who can access it, and where it is exposed. It never receives the records, files or secrets themselves, and that metadata travels over a private connection. You get full visibility in Sentra’s console, and Sentra’s cloud stays a map of your data, not a copy of it.
Read-only and API-based, with no software on your hosts. Sentra doesn’t install anything on your servers or sit in your data path, so there’s no Sentra code running next to your applications for an attacker to exploit. Its access is read-only, so it cannot change, move or delete your data, even if someone tried to misuse it.
Access stays under your control. The permissions scanners use live in roles inside your own account. You own them, you can audit them in your cloud provider’s console, and you can revoke them at any time. Sentra’s cloud holds no credentials to your data, so a breach of Sentra hands an attacker no keys.

The result is a security tool with a blast radius close to zero. Sentra can see everything it needs to protect your data, while an attacker who compromised Sentra would find nothing worth stealing. Here is what that means in an assume-breach world:

If the vendor is breached	Vendor copies data to its cloud	Vendor holds credentials to your data	Sentra
Your sensitive records exposed	Yes	Yes, via stolen credentials	No. Sentra's cloud never stores them
Your keys need emergency rotation	Often	Yes, all of them	No customer data credentials held in Sentra's cloud
Attacker can pivot into your accounts	Possibly	Yes	No standing data access from Sentra's cloud
What the attacker gets	Your data	Your data, plus a way back in	Metadata about your data

The part that shrinks your own blast radius

Architecture keeps Sentra from becoming a new risk. The platform is what reduces the risk you already have:

Find secrets 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. When a provider tells you to rotate everything, you already have a prioritized list.
See what every identity can reach. Sentra maps which users, roles, service accounts, OAuth apps and AI agents can access which sensitive data. When a credential is stolen, you see its blast radius right away.
Shrink the attack surface. Sentra surfaces redundant, obsolete and trivial (ROT) data, stale snapshots, forgotten exports and over-permissioned access. Data you have deleted can't be stolen.
Detect and respond. Sentra's data detection and response (DDR) alerts on unusual access and exfiltration on sensitive data, so "were we breached?" gets an evidence-based answer.
Scope incidents in minutes. Because Sentra already knows what sits in each store and who can reach it, security, legal and compliance can answer "which keys do we revoke and what was exposed?" while the incident is still unfolding.

Coverage spans AWS, Azure, GCP, Snowflake and Databricks, Microsoft 365, Google Workspace, file shares and on-prem databases.

Five questions to ask any security vendor

Before you connect a tool to your most sensitive data, ask:

Does any of my data, even a sample, leave my environment for processing?
What exactly does your cloud store about me: data, metadata or credentials?
Who owns the permissions your product uses, and can I revoke them instantly?
If your platform were fully compromised tomorrow, what would the attacker get from my account?
Is your access read-only, or can your product change or move my data?

If the answer to question four is anything other than "almost nothing," that vendor is part of your blast radius.

The bottom line

RCE is no longer a rare event you patch once a year. AI is finding it in code that has run unchanged for a decade, and attackers are exploiting it within hours. Some of it will land in a platform you trust.

You can't secure every link in the chain. You can make sure the tools protecting your data don't become the easiest way to steal it. Sentra scans in your environment, sends only metadata to its cloud, and leaves the keys to your data with you. Then it helps you find the secrets, over-permissioned access and forgotten data that make every other breach worse.

See how Sentra works in your environment. Book a demo.

Sources

FAQs

What is RCE (remote code execution)?

Remote code execution is a vulnerability that lets an attacker run their own commands on a system over a network, without physical access. It usually happens when an application trusts input it shouldn’t. Once inside, the attacker can do whatever the application can do, including reading credentials and the data they unlock.

Why is RCE so dangerous?

RCE gives an attacker direct control of a system, which is why these flaws score at the top of severity scales. The real damage comes from what that system can reach: stored secrets, connected databases and cloud accounts. One compromised server can become a path to an organization’s most sensitive data.

How is agentic AI making RCE more common?

AI is finding RCE flaws in old code faster than ever, and agentic attack frameworks exploit them without a human at the keyboard. Agents run around the clock, try many paths at once and go straight for credentials. Disclosure-to-exploitation now takes hours, faster than most teams can patch.

Why does it matter where a security vendor stores my data?

If a vendor copies your data to its cloud or holds credentials to read it, a breach of that vendor exposes your data too. Assume breach applies to vendors as well. The safest vendors keep your data in your environment and hold no standing access to it.

Does Sentra copy my data out of my environment?

No. Sentra’s scanners run inside your own cloud account or on-prem network and classify data in place. Only metadata is sent to Sentra’s cloud, such as which stores hold sensitive data, who can access it and where it is exposed. The records, files and secrets themselves never leave.