Entry 01 of this series attacked "local exploit" — a precondition label promoted into a threat category. This entry attacks its symmetric twin from a different angle. "Remote code execution" makes the same precondition error on the network-reach side, then compounds it by bundling a downstream outcome label into the same compound term. One label, two structural mistakes, both committed in the slot where threat classification should live. The framework dissolves the compound by sending each half to its proper layer and leaving the cluster — the cause — where it has always belonged.
§ 1The term in the wild
"Remote code execution" carries different precise meanings across the contexts in which it operates, and the slippage between them is what makes the term resistant to fix.
The most disciplined usage is the CVSS coarse-severity sense: a CVE with AV:N (Network attack vector) and high impact on confidentiality, integrity, or availability gets tagged as "RCE-class" for triage and patch prioritisation. Microsoft's Security Response Center uses "Remote Code Execution" as one of its standard impact categories alongside "Elevation of Privilege," "Information Disclosure," and others. NVD descriptions follow the same convention. In these uses, the label is doing severity-bucket work: telling defenders where on the patch-priority queue this CVE sits, without claiming anything about cause.
The exploit-marketplace and red-team usage is narrower: "RCE" implies arbitrary code execution where the attacker chooses the payload, often with the additional implication that no authentication is required. A "pre-auth RCE" is the highest-tier acquisition in any exploit market, and the phrase carries a precise operational meaning even though it is silent on the underlying cluster.
The press, vendor-marketing, and risk-register usage is looser: "RCE" stands in for any sufficiently severe CVE that ends with the attacker running something on the target. "Critical RCE in Log4j," "RCE in Spring Framework," "RCE flaw in Confluence" — these are all true descriptions in the CVSS sense, but they conceal the cluster diversity underneath. Log4j (Log4Shell) and Spring4Shell are server-side input-processing failures. Browser "RCE" CVEs are client-side rendering failures. SolarWinds-class RCEs are supply-chain trust acceptance. The label is identical; the cause structures are radically different.
The marketing usage is the loosest: this product protects against RCE.
A defender reading that sentence cannot tell what they are buying — input-validation hardening, browser sandboxing, supply-chain attestation, or behavioural exec-call monitoring are all defences against different things that look the same when collapsed into one category.
§ 2Why it fails the TLCTC test
Three structural failures, two of which are unique to this entry's compound-label shape.
First, precondition treated as category. The "remote" half is a vector qualifier — CVSS AV:N — describing the access requirements for triggering the bug. This is the exact mirror of Entry 01's argument about "local" / AV:L. Used as a triage descriptor, "remote" is precise and useful. Used as a cluster substitute, it tells defenders where the attacker stands but says nothing about which cause-side mechanism the attacker exploits.
Second, outcome treated as category. The "code execution" half is a downstream effect — what state the target lands in after the cluster step succeeds. Under §6.2 Rule 1 and SG-4, outcomes are not threat categories. "Code execution" belongs on the consequence side of the chain or as the cluster step #7 when foreign executable content actually runs. Either home is structurally valid; the threat-category slot is not.
Third, compound label hides R-EXEC. This is the failure unique to RCE. The framework's R-EXEC rule says that #7 Malware MUST be recorded if and only if Foreign Executable Content is interpreted, loaded, or executed. In colloquial "RCE" usage, this distinction is invisible — the term covers both pure FEC cases (shellcode payloads, downloaded binaries) and data-only control-flow hijack cases (Calif M5, classic ROP, JIT spraying without payload introduction). These are structurally different attacks that share an outcome label. The framework keeps the distinction because the defensive surface differs sharply: anti-malware execution monitoring catches the FEC case and misses the data-only case entirely.
§ 3The framework's positive answer: dissolve the compound
The framework's response to a compound label is to send each part of the compound to its proper layer. "Remote code execution" splits cleanly into three things, each of which has a different home.
The compound label loses nothing by being decomposed. The CVSS severity tag retains its triage usefulness. The R-EXEC determination either adds a #7 step or doesn't, recording the FEC fact precisely. And the cluster name — the thing the framework was designed to assert — finally appears in the analysis.
§ 4The cluster decompositions
Every CVE the industry tags as "RCE" has a cause cluster underneath. Five patterns cover the overwhelming majority of cases.
The dominant cause of "remote RCE" CVEs
A network-reachable service accepts inbound input and the server-side code path fails. Per R-ROLE, the vulnerable component is the server. If FEC then runs (shellcode, webshell write, downloaded payload), R-EXEC appends #7 as a separate step.
Canonical examples Log4Shell (CVE-2021-44228, JNDI lookup in log format string) · Spring4Shell (CVE-2022-22965, ClassLoader binding) · Confluence OGNL injection (CVE-2022-26134) · ProxyLogon (CVE-2021-26855) · MOVEit Transfer SQLi (CVE-2023-34362) · the entire "deserialization in web framework" CVE family
The "RCE via document or browser" pattern
The target reaches out and consumes attacker-influenceable content; the client-side parsing or rendering code fails. Browser RCEs, document-handler RCEs, PDF-renderer RCEs. Per R-ROLE, the vulnerable component is acting in client role. R-EXEC commonly appends #7 if shellcode runs; the Calif M5 case showed the data-only variant where it does not.
Canonical examples Pegasus FORCEDENTRY iMessage parser chain (CVE-2021-30860) · Pwn2Own Chrome/Firefox/Safari renderer exploits · classic IE/Edge use-after-free chains · WebP libwebp heap overflow (CVE-2023-4863) · Office document-handler RCE family (CVE-2017-11882, Equation Editor)
The "RCE via design" pattern
No code flaw is exploited; the execution outcome comes from legitimately designed capability being used in unintended context. Template engines designed to execute templates, deserialisers designed to construct objects, formula engines designed to evaluate expressions, file-upload-and-execute endpoints designed for exactly that. These cases get labelled "RCE" but classify cleanly under #1, not #2. R-EXEC still adds #7 if FEC ultimately runs.
Canonical examples Office DDE field execution (designed feature) · spreadsheet formula injection where the engine is doing exactly what it is designed to do · authenticated file-upload-and-execute on a webshell endpoint when the server is designed to execute uploads · Jenkins Groovy console for authenticated admins · MSSQL xp_cmdshell for sysadmins · GraphQL/server-side template injection where the rendering is the design
The "RCE via trusted update" pattern
A trust-acceptance event lets attacker-controlled code arrive on the target through a trusted distribution channel. The cluster step is at the moment the third-party trust artefact is accepted as authoritative. The code execution follows from the design — that's #7 via R-EXEC — but the cause is the supply-chain trust acceptance, not the execution.
Canonical examples SolarWinds SUNBURST (compromised update) · 3CX cascading supply-chain compromise · ua-parser-js / event-stream malicious npm publishes · XZ Utils backdoor (CVE-2024-3094)
The rare "RCE = just #7" case
When the labelled "RCE" is purely the execution of foreign code with no enabling vulnerability chain. User opens an executable. Macro runs because macros are enabled. Loader executes a DLL placed where the loader looks. These are #7-only paths. They rarely get called "RCE" in CVE advisories — there's no CVE — but they appear in incident reports, where the label "RCE" sometimes covers them in the absence of a clearer description.
Canonical patterns user-initiated executable run · macro-enabled document execution · DLL-search-order hijack with planted payload · authenticated PsExec deployment of arbitrary binary (preceded by #4/#1)
A sixth pattern appears occasionally: #5 Man-in-the-Middle → #3 → #7 chains, where an on-path attacker injects a malicious response that a client then parses and executes. Classic auto-update attacks without signature checks fall here. The chain has three causes; the press coverage usually calls the whole thing "RCE in <product>."
§ 5The R-EXEC discipline: not every "code execution" is #7
The most subtle structural point this entry makes — and the one the colloquial label most aggressively hides — is that "code execution" in industry vocabulary does not map cleanly onto the framework's #7 step. R-EXEC is precise: #7 is recorded if and only if Foreign Executable Content is interpreted, loaded, or executed by the target.
Two structurally different attacks both produce "code execution" outcomes:
The defensive consequence is sharp. Anti-malware execution monitoring, application allowlisting, behavioural exec-call detection — all of these target the FEC case (Case A) and miss the data-only case (Case B) by construction. A control programme that classifies all RCE as #7 and invests accordingly is preparing for half the attack surface. The R-EXEC rule prevents this collapse by forcing the analyst to record the FEC fact precisely. The label "RCE" has no such discipline.
The Calif M5 post ("The Calif M5 Exploit Is a Textbook #2 → #2 Chain") walks Case B in detail. The press described that incident as a kernel RCE that bypassed Memory Integrity Enforcement. The TLCTC reading carries no #7 step at all — the chain is pure #2 → #2, data-only, even though the colloquial outcome was "remote kernel code execution at root."
§ 6The Entry 01 mirror
This entry pairs structurally with Entry 01. Both attack CVSS Attack Vector qualifiers promoted into threat categories; they differ in which qualifier and which side of the chain the misuse sits on.
Together the two entries bracket the CVSS vocabulary problem completely. Attack-vector qualifiers (AV:L and AV:N) are useful as severity-bucket inputs and useless as cluster substitutes. Neither side of the network-reach axis names a cause. Both sides hide the same diversity of cluster patterns. The fix is symmetric: keep the vector qualifier where it does triage work, and name the cluster when threat classification is the task at hand.
§ 7The fix
"Remote code execution" survives as a CVSS-style coarse-severity bucket. Microsoft will keep using it in MSRC bulletins. NVD will keep using it in CVE descriptions. Patch-prioritisation tools will keep using it for queue ordering. None of that needs to change; the term does legitimate work in those contexts.
When threat classification, control design, or analytical reporting is the task, decompose the compound. Name the cluster — #2 for server-side input handlers, #3 for client-side parsers and renderers, #1 for designed-execution capability misuse, #10 for trust-acceptance compromises. Apply R-EXEC honestly: append #7 if foreign executable content runs, do not append it if the attack is data-only no matter what the colloquial outcome label suggests. Record the boundary crossings the chain makes with the appropriate operators. The label "RCE" disappears from the analysis, and three structurally distinct facts — what made it possible, whether foreign code ran, where the boundary crossed — appear in its place.◆