Vulnerability Report: Remote Code Execution (RCE) via Command Injection

[okba14]

Severity: CRITICAL

Vulnerability Type: Command Injection / RCE

Endpoint: POST /api/command

Vulnerability Code Analysis

The flaw lies in the implementation of subprocess.Popen where the parameter shell=True is utilized. This setting treats the entire command string as a raw shell instruction, allowing user-supplied input (like ; or &&) to be interpreted as system commands, leading to Command Injection.

Vulnerable Locations:

• File: hexstrike_server.py
• Lines: 5274, 6878

Description

The application is vulnerable to Remote Code Execution (RCE) via the /api/command endpoint. The server uses subprocess.Popen with the parameter shell=True set to True. This allows an attacker to inject arbitrary operating system commands (Command Injection) via the command parameter in the JSON request.

Proof of Concept (PoC)
The following request writes a file to the server's filesystem (/tmp/poc.txt) and reads it back to verify execution :

curl -X POST http://localhost:8888/api/command \
  -H "Content-Type: application/json" \
  -d '{"command": "echo \"CRITICAL_VULNERABILITY_DETECTED\" > /tmp/poc.txt && cat /tmp/poc.txt"}'

Result:

The server successfully returned the content of the newly created file :

{
  "stdout": "CRITICAL_VULNERABILITY_DETECTED\n",
  "success": true,
  "return_code": 0
}

This vulnerability allows a complete server compromise. An attacker can:

• Read Sensitive Data: Access environment variables (containing API keys, database passwords) and system files (e.g., /etc/passwd).
• Write/Modify Files: Write webshells or alter system configurations.
• Server Takeover: Execute arbitrary commands to gain full control over the underlying operating system.
  Remediation
  To fix this vulnerability, replace the unsafe shell=True usage with shell=False and use a list of arguments. This prevents the shell interpreter from executing injected metacharacters.

Recommended Fix (Python) :

import shlex

# Safe implementation
args = shlex.split(command)
process = subprocess.Popen(
    args, 
    shell=False, 
    stdout=subprocess.PIPE, 
    stderr=subprocess.PIPE, 
    text=True
)

Reported By :
Name: GUIAR OQBA
Email: [ techokba@gmail.com ]

[dominitas]

Hi @okba14 ,

I noticed this issue. We at Roxonn help teams and developers pay for completed GitHub tasks without hiring full-time contractors.

If this is useful, I’d be happy to show how it works.

– Domantas

[okba14]

Hello,
Thank you for reaching out. To clarify, my action was reporting a security vulnerability as part of a responsible disclosure process, not offering implementation or development services.
At this stage, I am awaiting feedback from the project maintainers regarding the assessment of the vulnerability and its security handling.
Once this aspect is clarified, other discussions can be considered if appropriate.

GUIAR OQBA
techokba@gmail.com

[dominitas]

@okba14 thank for replying in the meantime you can check out our website: https://app.roxonn.com/ and linkedin: https://www.linkedin.com/company/roxonn/?viewAsMember=true

[bcoles]

This isn't a vulnerability. This is intentional functionality. This API endpoint is intended to execute arbitrary commands. The suggested mitigation does not mitigate the "vulnerability", as users are expected to provide their own executable and arguments (the user could simply provide "/bin/sh").

Exposing the API to all network interfaces is potentially an issue, as per #122.

[okba14]

Labeling this as “intentional functionality” does not remove the risk.
An unauthenticated, network-exposed API that allows arbitrary command execution is unauthenticated remote command execution by definition, regardless of intent.
If this is meant for trusted local use, exposing it by default without authentication is an unsafe default configuration.

[bcoles]

Labeling this as “intentional functionality” does not remove the risk. An unauthenticated, network-exposed API that allows arbitrary command execution is unauthenticated remote command execution by definition, regardless of intent. If this is meant for trusted local use, exposing it by default without authentication is an unsafe default configuration.

Correct. This is a dupe of #122.