Unauthenticated RCE on the trust anchor: why three injection classes still dominate

This piece is about the shared mechanism, not any single product. But the 2026 public record makes the shapes concrete, so we use it as the worked example. CISA's Known Exploited Vulnerabilities catalog lists a Microsoft SharePoint deserialization-of-untrusted-data issue allowing unauthenticated code execution over the network, tracked as CVE-2026-20963; a Fortinet FortiClient EMS SQL injection allowing an unauthenticated attacker to execute unauthorized code or commands via crafted HTTP requests, tracked as CVE-2026-21643; and a BeyondTrust Remote Support and Privileged Remote Access OS command injection allowing unauthenticated remote command execution, tracked as CVE-2026-1731. Three vendors, three products, one underlying lesson. We do not republish exploit detail. We explain why this family is the one to hunt on your own perimeter, and how to recognize it before it is used against you. Verifiable security.

The class in one paragraph

Every one of these bugs is the same sentence with a different verb: untrusted input crosses a boundary into an interpreter that was supposed to receive only trusted input. In deserialization, the interpreter is the object deserializer, and the untrusted bytes become a live object graph whose construction the attacker controls. In SQL injection, the interpreter is the database, and the untrusted string becomes part of the query the server executes. In command injection, the interpreter is the operating system shell, and the untrusted field becomes part of a command line. The reason all three keep producing unauthenticated remote code execution is that the dangerous code path is reachable before login, on an endpoint that exists to accept input from the outside world. A collaboration server has to accept documents and requests. A security console has to accept management traffic. A remote-access gateway has to accept connection attempts. The pre-auth surface is, by design, the part that talks to strangers, and when a stranger's input reaches an interpreter there, the result is execution with the server's privileges, which on these systems is high.

What makes the family worth treating as one thing is the target selection. These are not random web apps. They are trust anchors: a collaboration platform that holds the organization's documents and identity integrations, a security product that manages other security products, a privileged-access gateway whose entire purpose is to broker high-trust sessions. Compromising any of them is not a foothold on the edge of the network, it is a foothold at its center.

How to recognize your exposure: input, interpreter, position

You can assess this risk without reproducing any exploit, because the exposure is determined by three readable facts, none of which require sending a malicious payload.

1. Is the product internet-facing, and which endpoints answer pre-authentication? The dangerous surface is the set of endpoints that respond before login. Knowing which collaboration, console, and gateway endpoints answer from outside tells you where an injection bug would land, independent of any specific CVE.
2. What version is it, and does that version appear in the known-exploited catalog? Version is the highest-signal fact for this family, because the catalog ties each injection bug to specific builds. A public-facing, catalog-listed version is an active risk by definition, since the catalog records observed exploitation.
3. What privilege does the service run with? The blast radius of an injection bug is the privilege of the process that gets injected. A service running as a high-privilege account turns a single crafted request into high-privilege execution. Knowing the run-as account tells you how bad a hit would be before one ever happens.

Three different weaknesses, one structure: untrusted input reaching an interpreter pre-auth on a trust anchor. Illustrative, not from any specific host.

Why this family is genuinely dangerous, and where to be precise

Be exact about the severity, because that precision is the brand. An unauthenticated injection bug on a trust anchor is close to the worst case in vulnerability terms: no credentials required, code execution achieved, and the compromised host is one the rest of the environment defers to. The post-exploitation does not need to be inventive, because the position is already privileged. Where to be careful is in the scope of the claim: not every deployment of these products is internet-facing, not every build is affected, and a patched or internal-only instance carries a small fraction of the risk. The work is to determine, for your environment, which trust-anchor surfaces are exposed and on which versions, rather than assuming every one is vulnerable.

It is also worth being clear that these classes are old and well-understood, which is exactly why they are dangerous rather than why they are safe. Deserialization, SQL injection, and command injection have been in the public weakness catalogs for years; their continued presence at the top of the exploited list is a statement about how hard they are to fully eliminate from large, long-lived codebases, not a sign that they are exotic. The defenses are known. The work is finding the instances that still have the bug, before someone else does.

These are not random web apps. They are trust anchors. A foothold here is not on the edge of the network, it is at its center.

And to be clear about what this is and is not: where a public catalog assigns a CVE to a specific build, that is a software vulnerability in the vendor's code, and patching is the fix. What we add is not a new CVE. It is the exposure determination for you: which trust-anchor surfaces are reachable, on which versions, running as what privilege, and therefore which carry the catalog's risk right now. We do not invent vulnerabilities, and we are skeptical of anyone who claims one without proof. We find where a known one lands on your perimeter.

What to do about it

How Celvex catches this

The reason this family persists is not that the defenses are unknown. It is that these systems are filed under trusted infrastructure, so the same input-validation scrutiny applied to a public web app is quietly skipped for the collaboration server or the security console. The discipline is to apply the boundary question everywhere a stranger's input can reach an interpreter: which of my trust anchors take outside input pre-auth, on what version, at what privilege. Answer that, and the family stops being a surprise.

Verifiable security. Find it. Prove it. Fix it. Verify the fix held. That is what we ship.