Skip to main content
Version: v1

Remote Code Execution (RCE)

RCE

What is it?

Remote Code Execution (RCE) occurs when an attacker is able to execute arbitrary code or system commands on the server through an API.

RCE is one of the most critical vulnerabilities, as it allows attackers to gain full control over the application environment, access sensitive data, pivot to internal systems, or deploy persistent backdoors.

In APIs, RCE typically arises from unsafe handling of user input in contexts such as command execution, dynamic code evaluation, deserialization, or template rendering.

What are specific examples?

  • Executing system commands via unsanitized input (e.g., ; ls, && cat /etc/passwd)
  • Unsafe deserialization of user-controlled data
  • Use of dangerous functions (eval, exec, system) on user input
  • Template engines executing injected expressions
  • File upload leading to execution of malicious scripts
  • Chaining injection vulnerabilities (e.g., command injection → RCE)

Test case FAQs

When is this test case applicable?

  • APIs executing system commands or interacting with the OS
  • Endpoints handling file uploads or dynamic script execution
  • APIs using template engines or interpreters
  • Systems performing deserialization of user-controlled input
  • High-risk integrations with external tools or services

How does it work?

Prerequisites

  • Identification of execution points (command, script, template, deserialization)
  • Ability to inject controlled payloads into input parameters
  • Monitoring capability for execution side effects (response, timing, behavior)

Test sequence

  1. Identify input vectors that may reach execution contexts:
    • Query parameters
    • Request body
    • Headers
    • File uploads
  2. Inject payloads targeting different execution paths:
    • Command injection payloads
    • Code execution expressions
    • Deserialization gadgets
  3. Send crafted requests and monitor:
    • Direct output in response (in-band execution)
    • Time delays (blind execution)
    • Behavioral changes (file creation, response anomalies)
  4. Attempt payload chaining across multiple inputs or endpoints
  5. Validate if arbitrary commands or code execution is achieved

Success/Failure indications

  • Failure (vulnerable):

    • Execution of injected commands or code
    • Sensitive system data returned in responses
    • Observable side effects (delays, file access, process execution)
    • Ability to chain inputs into execution paths
  • Success (secure):

    • Inputs are sanitized and do not reach execution contexts
    • No observable execution behavior from injected payloads
    • Strict separation between user input and system-level operations

What is the solution?

  • Avoid dynamic code execution (eval, exec, etc.)
  • Use safe APIs instead of shell/system command execution
  • Sanitize and validate all inputs rigorously
  • Implement strong input/output encoding and escaping
  • Use secure deserialization practices (avoid untrusted data)
  • Sandbox execution environments where necessary
  • Apply least privilege principles to system processes
  • Continuously test for injection paths leading to execution

References

Was this page helpful?