Security Vulnerability Audit Report — ScorpioX Clang Codebase

Executive Summary

The ScorpioX codebase is a large, multi-component C project comprising a terminal multiplexer, email server (SMTP/IMAP), HTTP server, AI provider clients, a KVM-based VM hypervisor, file transfer utilities, and more. The project demonstrates good security awareness in many areas — using snprintf over sprintf in 2,172 out of 2,192 format calls, performing bounds-checked header parsing in the HTTP server, and sanitizing filenames in network receive paths. However, critical and high-severity vulnerabilities exist, primarily in shell command injection (232 system()/popen() calls, many with insufficiently sanitized input), missing null checks after allocation (166 instances), and 20 unbounded sprintf calls that can cause heap/stack buffer overflows. The email server and HTTP server — both network-facing — have the highest exposure.

Vulnerability Summary

1. Buffer Overflow Analysis

1.1 Unbounded sprintf Calls (20 instances)

The codebase contains 20 sprintf calls without bounds checking. While the project predominantly uses snprintf (2,172 calls), the remaining sprintf calls represent real overflow risks:

1.2 Unbounded strcpy and strcat (37 instances)

// scorpiox-wsl.c:1278-1279 — argv concatenation into fixed buffer
char command_buf[4096] = {0};
for (int i = arg_start + 1; i < argc; i++) {
    if (command_buf[0]) strcat(command_buf, " ");
    strcat(command_buf, argv[i]);  // NO BOUNDS CHECK
}

// scorpiox-traffic.c:926-927 — same pattern
char cmdline[4096] = {0};
for (int i = 0; i < argc; i++) {
    if (i > 0) strcat(cmdline, " ");
    strcat(cmdline, argv[i]);  // NO BOUNDS CHECK
}

Long argument lists will overflow these 4096-byte stack buffers, corrupting the return address.

// scorpiox-unshare.c:140
strcpy(buf + dlen + 1, prog);  // prog length unchecked

// scorpiox-agent.c:1452
strcpy(out + len - 4, ".dll");  // assumes len >= 4

1.3 Stack Buffer Analysis

The codebase uses 2,311 stack-allocated char buffers. Notable large allocations:

• sxmail_dkim.c:414 — char sign_data[32768] (32KB on stack)
• sx_dll.c:288 — char enqueue_buf[8192] (in global struct)
• sxmail_imap.c:927 — char resp[8192]
• sxmail_queue.c:896 — char bounce[8192]

Stack exhaustion risk on deeply nested calls with 8KB+ buffers per frame.

2. Format String Analysis

2.1 Direct Format String Vulnerabilities

No classic format string vulnerabilities were found (i.e., printf(user_input) without format string). All printf/fprintf calls use string literals as format specifiers. This is well-implemented.

2.2 Indirect Format Risks

The snprintf calls that build command strings for system() can indirectly introduce format-related issues if the resulting command string is interpreted by the shell. This is primarily a command injection risk (see §6).

3. Integer Overflow Analysis

3.1 Multiplication Before Allocation

// sx_http.c:44 — curl write callback
size_t real_size = size * nmemb;  // Can overflow on 32-bit

While curl guarantees size == 1, the contract allows arbitrary values. On 32-bit platforms, size * nmemb can wrap to a small value, causing subsequent memcpy to write beyond the buffer.

// sx_http.c:48 — doubling strategy
size_t newcap = buf->cap * 2;  // Can overflow to 0

If cap is near SIZE_MAX/2, doubling wraps to 0 or a small value. The follow-up realloc(buf->data, newcap) with newcap=0 frees the buffer, and subsequent memcpy writes to freed memory.

3.2 Integer Truncation

// sxtmux_backend_sxmux.c:62
int len = (int)strlen(keys);  // Truncates on strings > 2GB (theoretical)

// sxmux_session.c:28
int len = (int)strlen(tmp);

19 instances of casting strlen() (returns size_t) to int. On 64-bit systems this truncates for strings > 2GB. While unlikely in practice, this violates C safety invariants.

3.3 realloc Doubling Overflow

// sx_mcp.c:701
while (len + need >= cap) { cap *= 2; buf = realloc(buf, cap); }

• cap *= 2 can overflow to 0 on repeated doublings
• No null check on realloc return — old buf is leaked and buf becomes NULL
• Subsequent snprintf(buf + len, ...) dereferences NULL

Same pattern in sx_provider_gemini_wasm.c:56, sx_provider_openai.c:323.

4. Memory Safety Analysis

4.1 Missing Null Checks After Allocation (166 instances)

4.2 Potential Use-After-Free

The realloc pattern without null check is the primary use-after-free risk:

// When realloc fails, it returns NULL but does NOT free the old pointer.
// However, assigning the result to the same variable:
buf = realloc(buf, cap);  // If this returns NULL, old buf is leaked
                           // and buf is now NULL — subsequent use = crash

This pattern appears in:

• sx_mcp.c:701
• sx_provider_gemini_wasm.c:56
• sx_provider_openai.c:323
• sx_provider_claude_code.c:580

4.3 Memory Leaks

Return paths that skip free():

• sx_api.c:367: sprintf chain into buf = malloc(total) — if the function returns early after partial construction, buf is leaked (though no early returns exist currently)
• General: many functions allocate multiple resources without cleanup-on-error patterns (no goto cleanup idiom)

5. Command Injection Analysis

5.1 Overview

The codebase contains 232 system()/popen()/exec*() calls. This is the most significant attack surface.

5.2 Critical: Shell Metacharacter Injection via Single Quotes

Multiple locations use single-quote wrapping to "protect" user input in shell commands:

// sxmail_maildir.c:704 — CRITICAL: email folder name from IMAP client
snprintf(cmd, sizeof(cmd), "rm -rf '%s'", path);
system(cmd);  // If path contains: foo'; rm -rf /; echo '

// scorpiox-vm.c:488 — CRITICAL: URL from config
snprintf(cmd, sizeof(cmd), "curl -fSL --progress-bar -o '%s' '%s'", dest, url);
system(cmd);  // If url contains single quotes

// scorpiox-unshare.c:427
snprintf(cmd, sizeof(cmd), "tar xf '%s' -C '%s'", tar_path, rootfs_dir);

// scorpiox-server.c:688
snprintf(cmd, sizeof(cmd), "git -C '%s' rev-parse HEAD 2>&1", repo_dir);

Single-quote wrapping is not sufficient — an attacker providing a value like '; malicious_command; echo ' breaks out of the quotes.

5.3 Critical: Argument Concatenation

// scorpiox-agent.c:1313 — find -exec with agent directory
snprintf(cmd, sizeof(cmd),
    "find '%s' -name '*.csproj' -exec grep -li 'scorpiox\\.agent\\.dotnet' {} \\;",
    agent_dir);
FILE *fp = popen(cmd, "r");

5.4 High-Risk system() Calls by Component

6. Race Condition Analysis

6.1 Threading Model

The codebase uses POSIX threads in two primary areas:

• sx_dll.c: Worker thread with mutex-protected event queue and input queue — properly synchronized
• sx_cache_keepalive.c: Keepalive thread with mutex protection — properly synchronized

Both use pthread_mutex_lock/unlock consistently. No obvious data races in the mutex-protected sections.

6.2 Thread-Unsafe Static Buffers

static char sx_xhr_response_buf[65536];  // Line 39
static char json[4096];                   // Line 303
static char json[32768];                  // Line 388
static char body_copy[65536];            // Line 639

These are in WASM context (single-threaded), so this is low-risk in practice but violates safe coding principles.

6.3 Signal Handler Safety

// sx_term.c:515
static void term_sigwinch(int sig) {
    (void)sig;
    g_term.resized = true;  // Safe: volatile-style flag pattern
}

The handler only sets a boolean flag — this is the correct async-signal-safe pattern. However, signal() is used instead of sigaction(), which has undefined behavior for re-entrant signals on some platforms.

6.4 TOCTOU (Time-of-Check-Time-of-Use)

// scorpiox-unshare.c:124,141
return access(prog, X_OK) == 0;
// ... later ...
execve(buf, ...);  // File could have changed between access() and exec()

30+ instances of stat()/access() followed by open()/exec(). Low risk in most contexts (local programs, not setuid) but technically exploitable.

6.5 PID File Races

// sxmux_session.c:1558
if (fscanf(pf, "%d", &existing_pid) == 1 && existing_pid > 0) {
    // Check if pid is alive, then decide to reuse
    // Race: pid could die and be recycled between check and use
}

7. Compiler Warning Analysis

Compilation with -Wall -Wextra -Wformat-security -Wstack-protector produced 95 unique warnings:

• system() return in scorpiox-unshare.c (8 instances) — cannot detect failed commands
• read() / write() in scorpiox-unshare.c, sx_term.c — potential partial I/O
• chdir() in scorpiox-unshare.c — process may operate in wrong directory

8. Positive Security Findings

The codebase demonstrates several good security practices:

9. CVSS Risk Scoring Summary

10. Remediation Recommendations

Priority 1 — Critical (Immediate)

   #define SX_ALLOC(ptr, size) do { \
       (ptr) = malloc(size); \
       if (!(ptr)) { SX_ERROR("OOM at %s:%d", __FILE__, __LINE__); abort(); } \
   } while(0)
   

   char *tmp = realloc(buf, cap);
   if (!tmp) { free(buf); return -1; }
   buf = tmp;