Zero-day, exploit, RCE and buffer overflow: what they mean
Understand how vulnerabilities, exploits, zero-day attacks, remote code execution and buffer overflows relate, and how to prioritize a response.
Security advisories often combine a weakness, an attack technique and an impact in one sentence. These describe different parts of an incident. Understanding the difference helps teams identify exposure and decide what evidence to collect before taking action.
## Vulnerability and exploit
A vulnerability is a weakness in a system or its implementation that can be used to compromise security. An exploit is a method, sequence of actions or code that takes advantage of a vulnerability. A proof of concept can demonstrate a condition under specified circumstances; it does not prove every installation is exploitable or that malicious actors have used it. A public exploit may require particular software versions, configuration, access or other preconditions. See the [NIST definition of vulnerability](https://csrc.nist.gov/glossary/term/vulnerability).
## What does zero-day mean?
A zero-day attack exploits a vulnerability not previously known to defenders. In everyday reporting, zero-day may also describe a newly discovered vulnerability for which a fix was not available when exploitation was discovered; accounts vary, so check the timeline and who knew what. The term does not mean that exploitation continues after a fix, that a patch is now unavailable, or that a public proof of concept proves active use. [NIST's zero-day attack entry](https://csrc.nist.gov/glossary/term/zero_day_attack) uses the previously unknown vulnerability definition.
Once a vulnerability is disclosed, compare the advisory with the deployed versions and exposure. [CISA's Known Exploited Vulnerabilities catalog](https://www.cisa.gov/known-exploited-vulnerabilities-catalog) lists vulnerabilities for which CISA has evidence of exploitation in the wild; an entry is a strong prioritization signal, not evidence that your particular organization was compromised. Absence from the catalog is not proof that exploitation has not occurred.
## What is remote code execution?
Remote code execution (RCE) means an actor can cause code to run on a target system from a remote context, subject to the conditions of the specific flaw. It describes a possible impact, not the underlying cause or a guarantee of administrator access. For example, a vulnerable network service might process a crafted request and run code with the service's own permissions. A separate privilege-escalation flaw or misconfiguration would be needed to gain additional privileges if the initial execution is restricted.
Privilege escalation means obtaining permissions beyond those initially held. Local privilege escalation (LPE) commonly describes an actor with an existing foothold gaining higher permissions on the same system. In the [Linux kernel incident analysis](https://blog.mithril.fund/linux-kernel-lpe-kev-convergence?lang=en), the scenario is a low-privilege user reaching root; other cases and prerequisites differ. RCE can be an initial step and privilege escalation a later step, but they are distinct outcomes and neither automatically follows from the other.
## What is a buffer overflow?
A buffer is an area of memory used to hold data. A buffer overflow occurs when an operation writes beyond the space intended for that buffer, potentially corrupting other memory. Depending on the program, environment and exploitability, the result may be a crash, changed data or code execution; not every overflow produces RCE. Out-of-bounds reads can expose data and are a related but distinct class of error. [MITRE CWE-120](https://cwe.mitre.org/data/definitions/120.html) describes the specific case of copying input without checking its size; it should not be used as a catch-all for every out-of-bounds condition.
## What should defenders do?
Inventory affected products and versions, check whether the vulnerable component is actually reachable, and read vendor prerequisites and mitigation guidance. Prioritize confirmed exploitation and business impact alongside exposure, not a label alone. Apply supported fixes or temporary mitigations after testing when practical; reduce unnecessary exposure and privileges, and monitor for relevant activity. If compromise is suspected, preserve relevant evidence and use an incident-response process rather than assuming a patch removes an attacker. For developers, memory-safe approaches, boundary checks, testing and compiler protections can reduce risk; no one measure covers every flaw.
For identifiers and severity scoring, see [CVE, CVSS and CWE explained](https://blog.mithril.fund/cve-cvss-cwe-explained?lang=en). Sources reviewed on 2026-10-30.