Skip to content
You can now search across every topic, entity and event.What's new
Remote Code Execution
Concept

Remote Code Execution

The vulnerability class where an attacker runs arbitrary code on a remote system over a network.

Last refreshed: 24 June 2026 · Appears in 1 active topic

Key Question

Why does an unauthenticated RCE mean a vendor patch is urgent?

Timeline for Remote Code Execution

#818 Jun

Mentioned in: Splunk lands its first-ever KEV entry

Cybersecurity: Threats and Defences
#79 Jun

Mentioned in: Arista refuses to patch KEV flaw

Cybersecurity: Threats and Defences
#79 Jun
#128 Mar

Mentioned in: F5 reclassifies DoS bug to 9.8 RCE

Cybersecurity: Threats and Defences
View full timeline →
Common Questions
What is remote code execution and why is it so dangerous?
Remote Code Execution (RCE) is a vulnerability class that lets an attacker run arbitrary commands on a target system over the network without physical access. Unauthenticated RCE requires no prior login, making it the highest-severity vulnerability category.Source: NIST / CISA
Why was the F5 vulnerability reclassified from low risk to critical?
CVE-2025-53521 in F5 BIG-IP APM was initially rated medium-severity DoS. F5 reclassified it to unauthenticated RCE with CVSS 9.8 in March 2026 after active exploitation evidence changed the assessed attack class; CISA added it to KEV simultaneously.Source: F5 / CISA
What is the difference between RCE and a denial-of-service vulnerability?
A denial-of-service (DoS) flaw makes a service unavailable. An RCE flaw lets an attacker execute arbitrary code on the target, gaining the equivalent of interactive access. RCE is categorically more severe because the attacker can then install malware, steal data, and move laterally. A CVE can be reclassified from DoS to RCE after initial analysis, as happened with CVE-2025-53521 in F5 BIG-IP APM.Source: NIST NVD / CISA KEV

Background

Remote Code Execution (RCE) is the most severe class of software vulnerability. It allows an attacker to run arbitrary commands or programs on a target system across a network, without needing physical access. The combination of no authentication requirement (unauthenticated RCE) and high-privilege execution is the worst-case outcome for any exposed service.

RCE flaws arise from a range of root causes: memory-safety errors (buffer overflows, use-after-free), deserialisation of untrusted input, server-side template injection, and logic errors that allow code paths reserved for authenticated users to be reached without a valid session. CVSS scoring places unauthenticated RCE at 9.0 to 10.0 on the v3.1 scale; authenticated variants typically score 8.0 to 8.8. These scores inform patch-priority triage but are point-in-time assessments: the F5 BIG-IP APM case (2026) showed that a CVE initially classed as medium-severity denial-of-service was subsequently reclassified as an unauthenticated RCE with CVSS 9.8, exposing organisations that had deferred patching.

RCE vulnerabilities are the primary vehicle for initial access in enterprise intrusions. Once executed, an attacker can install persistent backdoors, move laterally across the network, escalate privileges, and exfiltrate data. CISA's Known Exploited Vulnerabilities (KEV) catalogue is the primary signal for RCE flaws under active exploitation; federal agencies face mandatory remediation deadlines. Defenders prioritise network segmentation, rapid patching, and exploit-telemetry feeds (such as Shadowserver) to track exposed instances before a patch cycle closes.

More questions
Why does an unauthenticated RCE get a higher CVSS score than an authenticated one?
CVSS v3.1 raises the score when the Attack Requirements are minimal and no authentication is needed (Attack Vector: Network, Privileges Required: None). Unauthenticated RCE typically scores 9.0-10.0 because any internet-reachable instance is immediately exploitable without stolen credentials, whereas authenticated RCE requires the attacker to already hold an account on the target.Source: CVSS v3.1 specification
How does CISA decide which RCE vulnerabilities go on the KEV list?
CISA adds a CVE to the Known Exploited Vulnerabilities (KEV) catalogue when it has credible evidence of active exploitation in the wild, regardless of CVSS score. Once listed, federal agencies have a mandatory Deadline (usually 21 days) to patch. KEV membership is therefore a stronger patch-priority signal than CVSS alone, because it confirms real-world attacker activity rather than theoretical exploitability.Source: CISA KEV catalogue
What makes a CVE reclassification from DoS to RCE so dangerous for patch teams?
Patch teams triage CVEs at initial disclosure. A medium-severity DoS may be deferred to a routine patch cycle. When the same CVE is reclassified as an unauthenticated RCE months later, organisations that deferred patching are now exposed to full code execution on internet-facing systems. The F5 BIG-IP APM reclassification in March 2026 demonstrated this risk: over 14,000 exposed instances were unpatched at reclassification time.Source: F5 / CISA / Shadowserver
How do defenders track exposed instances after an RCE vulnerability is disclosed?
Shadowserver Foundation and Shodan scan the public internet for services matching the fingerprint of a vulnerable version. Defenders cross-reference internal asset inventories against published scan data to estimate exposure windows. CISA and vendor advisories typically publish expected patch timelines; organisations that cannot patch immediately apply compensating controls such as access-control lists, WAF rules, or network isolation.Source: Shadowserver / CISA advisories