What is arbitrary code execution?
Arbitrary code execution is when an attacker tricks your system into running their malicious code without permission. Think of it like someone breaking into your house and using your computer to do whatever they want.
When attackers achieve ACE, they can execute any commands they choose on your system. This lets attackers run code with the privileges of the compromised process—which could be a low-privilege web service account or a high-privilege system daemon. The actual control level depends on what permissions the exploited application already has. It's one of the worst types of security vulnerabilities because it hands over complete system access to the attacker.
Cloud environments change the blast radius calculus for ACE attacks. If network segmentation is weak and services run with excessive permissions, attackers who compromise a container or VM may pivot to other resources. However, robust network policies (VPC segmentation, security groups), least-privilege IAM roles, and runtime isolation controls significantly limit how far attackers can spread from a single compromised workload.
Secure Coding Best Practices [Cheat Sheet]
Protect your cloud workloads from ACE attacks with proven secure coding best practices.
How arbitrary code execution attacks work
ACE attacks start with attackers looking for weak spots in your system. They scan for exposed services, outdated software, or input fields that don't check what users type in. Once they find a vulnerability, they create specially designed input to exploit it.
The exploitation phase is where attackers take control of how your program runs. They corrupt memory structures—overwriting return addresses on the stack, manipulating vtable pointers in C++ objects, or chaining together ROP (Return-Oriented Programming) gadgets. After gaining control flow, they deliver payloads such as shellcode injected into executable memory, malicious DLLs or shared objects loaded into the process, or gadget-based execution that bypasses modern protections like DEP (Data Execution Prevention).
Cloud attacks can get more complicated because services often share network paths, IAM trust relationships, and data access patterns. However, strong network segmentation (private subnets, security groups, service mesh policies), zero-trust identity controls (scoped IAM roles, service accounts with minimal permissions), and runtime isolation (container security contexts, VM-level boundaries) markedly reduce the attack surface. Attackers might exploit a vulnerability in a container image, use misconfigured permissions to run code in a Lambda function, or chain together multiple vulnerabilities across different services. Cloud resources come and go quickly, so attackers need to work fast to maintain their access.
Here's how attacks typically unfold:
Discovery: Finding vulnerable services and ways to get in
Exploitation: Triggering the vulnerability to take control
Payload delivery: Injecting malicious code into memory
Execution: Running commands the attacker controls
Persistence: Setting up backdoors to maintain access
Arbitrary code execution vs remote code execution
People often use these terms interchangeably, but they mean different things. Arbitrary code execution covers any situation where an attacker runs unauthorized code, whether they're sitting at your computer or halfway around the world.
Remote code execution is a specific type of ACE that happens over a network. RCE vulnerabilities are especially dangerous because attackers don't need physical access or existing credentials. If your vulnerable service is exposed to the internet, anyone can potentially exploit it.
This distinction matters when you're deciding what to fix first. RCE vulnerabilities in internet-facing services need immediate attention. Local ACE vulnerabilities might be less urgent if you have other security controls limiting who can access your systems. But in cloud environments, even "local" vulnerabilities can become remotely exploitable through connected services or container escapes.
The main differences include:
Attack vector: RCE always happens over a network, while ACE can include attacks from inside the system
Prerequisites: RCE just needs network access, but ACE might require someone already having some system access
Risk level: RCE usually poses higher immediate risk for services exposed to the internet
Detection: RCE creates network traffic patterns you can spot, while local ACE might only show up in system logs
Common arbitrary code execution vulnerability types
Several types of vulnerabilities commonly lead to arbitrary code execution. Understanding these helps you spot potential ACE risks in your environment.
Buffer overflow vulnerabilities happen when programs write data beyond the space allocated in memory. Attackers send carefully crafted input that overwrites adjacent memory, including important addresses that control where the program goes next. This lets them redirect the program to run their malicious code. Stack-based and heap-based overflows are the most common types.
Insecure deserialization occurs when applications convert data back into objects without checking if it's safe. Attackers manipulate these objects to include malicious code that runs during the conversion process. Modern web applications and APIs that exchange complex data are particularly vulnerable to insecure deserialization. For example, Wiz Research identified an Apache Parquet-related risk that affected a significant portion of scanned cloud environments in their customer base (Wiz Research, May 2025).
Command injection lets attackers insert system commands into application inputs that get passed to the operating system. This happens when applications build system commands using
data from users without cleaning it first. Web applications that call system utilities or cloud functions that use command-line tools are common targets.
Memory corruption bugs include various problems like use-after-free, double-free, and type confusion errors. These bugs corrupt program memory in ways that let attackers control where the program goes next. Modern attackers use techniques like heap spraying and ROP chains to exploit these vulnerabilities.
What is Code-to-Cloud Security?
Code-to-cloud security protects applications across the entire software development lifecycle (SDLC), from code all the way to runtime in the cloud.
Read more
Real-world arbitrary code execution attack examples
Real ACE vulnerabilities have caused major security incidents that show just how damaging these flaws can be.
Log4Shell (CVE-2021-44228) was a critical RCE vulnerability in the Apache Log4j logging library. Attackers could trigger code execution just by getting an application to log a specially crafted string. This affected countless Java applications across cloud environments and required massive cleanup efforts.
Spring4Shell (CVE-2022-22965) targeted the Spring Framework, letting attackers execute code by manipulating class loader access. This hit cloud-native applications built on Spring Boot particularly hard, showing how one framework vulnerability can affect entire application ecosystems.
Registry misconfigurations can enable code execution risks in the software supply chain by allowing unauthorized image modifications. Separately, container escape vulnerabilities like runC (CVE-2019-5736) let attackers break out of container isolation to execute code on the underlying host system, compromising all containers on that host. These show the unique ACE
risks in containerized environments where traditional security boundaries don't work the same way.
Serverless function exploits have emerged as attackers target Lambda functions and other serverless platforms. Vulnerabilities in function runtimes or custom layers can lead to code execution that compromises entire serverless applications.
NPM supply chain attack analysis shows how supply chain attacks increasingly leverage ACE vulnerabilities in dependencies and third-party libraries. Attackers compromise popular packages to inject malicious code that executes when applications import these dependencies.
Detecting arbitrary code execution attempts in runtime
Catching ACE attempts as they happen requires more than just looking for known attack signatures. Modern detection focuses on watching for unusual behavior and spotting anomalies.
Process behavior monitoring tracks system calls, how processes are created, and memory operations to spot suspicious activity. Unusual parent-child process relationships, unexpected new processes, or processes running from temporary directories often signal ACE exploitation.
Network traffic analysis examines communication patterns for signs of exploitation and what happens after. Reverse shells, command-and-control traffic, and unusual outbound connections from services that normally stay quiet all warrant investigation.
File integrity monitoring catches unauthorized changes to system files, programs, and configuration files that often come with ACE attacks. Attackers frequently modify files to maintain access or gain higher privileges after getting initial code execution.
Memory forensics analyzes process memory for signs of exploitation like shellcode, ROP gadgets, or injected libraries. Advanced detection systems can spot code execution in memory even when attackers use sophisticated hiding techniques.
Runtime sensors and eBPF-based monitoring provide deep visibility into system behavior with minimal performance overhead—typically under 2-3% CPU impact. eBPF operates in kernel space and uses efficient event filtering, making it suitable for production workloads where traditional tracing would be too expensive.
Cloud providers offer native security services that generate telemetry useful for ACE detection:
AWS: CloudTrail logs API activity, GuardDuty detects threats using ML, and Security Hub aggregates findings across services.
Azure: Activity Logs track control-plane operations, Microsoft Defender for Cloud provides threat detection, and Azure Monitor collects runtime telemetry.
GCP: Cloud Logging captures audit logs, Security Command Center identifies vulnerabilities and threats, and Chronicle SIEM analyzes security data.
These native services provide valuable signals, but they operate in silos within each cloud provider. A unified security platform correlates these signals across multi-cloud environments, enriches them with infrastructure context (network paths, permissions, data sensitivity), and prioritizes the ACE risks that create actual attack paths to your critical assets.
How to prevent arbitrary code execution vulnerabilities
Secure coding practices form your first line of defense. Always validate and sanitize all user input before processing it. Use memory-safe programming languages when possible, or follow secure coding best practices if you can't. Run applications with the minimum permissions they need to function. Use frameworks that handle security concerns automatically.
Infrastructure hardening reduces your attack surface and limits what attackers can do if they get in. Segment your network to isolate critical services and limit lateral movement. Implement strong authentication and authorization controls. Maintain secure baseline configurations for all systems. Use minimal container base images and apply security policies.
Vulnerability management ensures you find and fix ACE risks quickly. Scan your code, containers, and infrastructure regularly. Track and update third-party components and dependencies. Maintain an SBOM (Software Bill of Materials) for visibility into your supply chain. Apply security patches as soon as they're available. Perform regular penetration testing and code reviews. Understand where sensitive data resides using DSPM (Data Security Posture Management) to prioritize ACE risks near critical data stores.
Runtime protection provides your last line of defense. Isolate applications to limit the damage from exploitation. Monitor for and block exploitation attempts in real-time. Deploy runtime sensors for deep visibility into what's happening in your workloads.
Watch 5-minute demo
Watch the demo to learn how Wiz Code scans infrastructure as code, container images, and CI/CD pipelines to catch risks early—before they reach the cloud.
Watch now
How Wiz protects against arbitrary code execution risks
Wiz delivers a unified, code-to-cloud security platform engineered to prevent arbitrary code execution, protecting applications from development through runtime.
Wiz Code integrates security into your SDLC, scanning code, pull requests, and CI/CD pipelines for vulnerabilities, misconfigurations, and malicious code—including deserialization vulnerabilities in AI models. It catches ACE risks early in your development workflow.
Wiz Defend, with Wiz's Runtime Sensor, provides real-time threat detection, validating runtime vulnerabilities, identifying Python-related issues, and reactively terminating malicious processes. When suspicious activity occurs—unauthorized process execution, reverse shell connections, privilege escalation attempts—Wiz automatically correlates it on the Security Graph, showing you the attack path, blast radius, and affected assets.
The Wiz Security Graph contextualizes risks by mapping how vulnerabilities connect to network exposure, identity permissions, and sensitive data. It automatically identifies "toxic combinations" where ACE vulnerabilities create exploitable paths to your critical assets, helping you focus on the vulnerabilities that pose real threats.
The Wiz unified policy engine ensures consistent security across code, CI/CD, and cloud environments. Code-to-Cloud Visibility and Remediation traces risks back to source code and provides one-click fix suggestions in developer environments, enabling you to fix the root cause and not just the symptom.
Want to see how graph-based context and unified code-to-cloud protection change your ACE defense strategy? Request a demo to get a personalized walkthrough of how Wiz identifies attack paths from code to cloud to runtime.
See Wiz in Action
Watch how teams detect and prevent ACE attacks across their cloud environments.
