A zero-day exploit does not announce itself with a CVE number. Before a vendor publishes an advisory, defenders cannot rely on a signature, a fixed-version check, or a scanner rule that names the flaw. They have to recognize the attack through what changes during execution.
In Kubernetes, that behavior often crosses several layers. A request reaches an application, vulnerable code runs inside a container, the process accesses credentials or the network, and the attacker attempts to expand control through the pod, node, cluster, or cloud account. Each step creates evidence even when the original vulnerability is unknown.
The Attack Begins as Normal Application Traffic
Many zero-day attacks start with an ordinary protocol interaction. The attacker sends an HTTP request, API message, file, serialized object, or other input the application is expected to accept.
The edge signal may be weak
A web application firewall can identify known payloads and abnormal request patterns. It has less certainty when a new exploit uses valid syntax, an unfamiliar encoding, or a logic path that has no public signature. The request may resemble normal customer traffic until it reaches the vulnerable code.
This is why the first reliable signal may appear inside the workload. A parser takes an unexpected branch, a library invokes a rarely used function, or the application creates a process it has never created before.
Exploitation Changes the Execution Path
The vulnerability converts attacker-controlled input into unintended behavior. That behavior varies by flaw, but the transition is observable.
Code execution leaves relationships
Remote code execution may appear as a child shell, an interpreter launched by a service, memory with executable permissions, or a new outbound connection. A file-read flaw may cause the application to access a service account token or configuration file outside its normal path. Server-side request forgery may direct the workload toward a metadata service or an internal administration endpoint.
The individual event is not always unique to an attack. Applications legitimately start subprocesses and make outbound calls. The stronger signal is the relationship between the input, the code path, and the action. Runtime security becomes useful here because it can evaluate behavior even when no CVE or signature exists yet.
The attacker tests the environment
After initial execution, an attacker often determines where the process is running and what it can access. Commands or API calls may enumerate environment variables, mounted volumes, network routes, DNS names, service account tokens, or cloud metadata.
In Kubernetes, discovery may also include namespace and pod enumeration through the API server. The impact depends on the workload's permissions. A pod with no API access and narrow network policy offers fewer options than one with an automatically mounted token and broad RBAC.
The Attack Moves Beyond the First Container
Initial code execution becomes a larger incident when the attacker can cross a boundary.
Credential use can look legitimate
A service account token or cloud workload identity is a valid credential. When an attacker uses it, authentication may succeed and the API request may look structurally correct. Defenders need context about which workload used the identity, which process or code path initiated the call, and whether that behavior is normal for the service.
Unexpected secret reads, token access, namespace discovery, or cloud API calls are important signals. So are new RoleBindings, deployed pods, or changes to workload specifications.
Container escape changes the scope
Some exploits target the container runtime or kernel rather than the application. A successful escape may expose the host file system, other workloads, node credentials, or the container management interface.
Indicators include access to host-mounted paths, unusual namespace operations, changes under procfs or sysfs, use of powerful Linux capabilities, and interaction with a runtime socket. The Kubernetes restricted Pod Security Standard reduces many common prerequisites by disallowing privileged containers, limiting capabilities, and requiring stronger security settings.
Detection Without a Known Signature
Behavioral detection should focus on high-value transitions rather than attempting to label every anomaly as malicious.
Useful execution-time signals include:
- An internet-facing service launching a shell or interpreter
- A code path reading a token, private key, or sensitive configuration it does not normally use
- A workload contacting a new external destination or cloud metadata endpoint
- A service account enumerating cluster resources or creating new workloads
- A container attempting namespace changes, privileged mounts, or access to the runtime socket
- A process writing an executable file and then launching it
Context determines priority. A shell in a build job may be expected, while the same shell under a public API service deserves immediate investigation. Baselines should therefore be tied to the workload and its role rather than applied uniformly across the cluster.
Preserve Evidence Before the Workload Disappears
Kubernetes may replace a compromised pod during scaling, deployment, or recovery. The new replica does not retain the old process tree, memory state, or writable layer.
Security teams should capture evidence continuously and associate it with stable metadata. At minimum, that includes the image digest, deployment, namespace, service account, node, process lineage, network activity, file access, and Kubernetes audit events. Application-level context can add the request, library, function, or call chain that initiated the behavior.
Centralized evidence also protects the investigation if the attacker deletes a pod or modifies local logs. Retention should be long enough to cover the delay between exploitation and detection.
Contain the Behavior While the Vulnerability Is Unknown
Before a patch exists, teams can still reduce exposure. They can narrow ingress, disable the affected feature, block a destination, revoke a credential, isolate a workload, enforce a stricter RuntimeClass, or add a targeted admission or runtime policy.
The response should focus on the observed attack path. Broad changes made without evidence may create outages while leaving the real path open. A clear timeline helps the team choose the smallest control that breaks the chain.
Conclusion
A CVE eventually gives the vulnerability a name and supports inventory-based remediation. It does not create the first evidence of the attack. That evidence appears when the workload behaves differently.
Teams that capture execution context can detect the exploit path, contain its effects, and preserve an investigation before a signature exists. When the advisory arrives, they can use the same evidence to identify which workloads were exposed and whether exploitation occurred.
Related DevToolLab Tools
- Kubernetes Manifest Linter - flag privileged containers and added Linux capabilities before a workload ships.
- JWT Decoder - read a service account token's claims to see which namespace and service account it belongs to.
- Kubernetes Secret Decoder - decode a Secret's base64 values to see what a compromised pod could have read.
- CVSS Calculator - score the flaw with CVSS v3.1 once the advisory and its vector string arrive.
Related Guides
- Container Security Tools Compared - image scanners plus runtime defense with Falco and Tetragon
- Best eBPF Observability Tools - eBPF instrumentation that sees process and network events inside a pod
- Non-Human Identity Security - service account tokens and the other machine credentials an attacker reuses
- Supply Chain Security Tools - SBOMs and signed images that answer "which workloads were exposed" faster