ScorpioX CLI — Unified Security Assessment Report

Audit Date: 2026-04-28 Codebase: scorpiox/clang Commit: b85fca9891f8ff39fce93868947ce31fe9fed50e Branch: main Total Lines of Code: 369,205 (C + H files) Project Lines (excl. vendor): 143,309 Auditors: 5 automated Security Audit Agents Classification: CONFIDENTIAL — For Corporate Review Only

---

Table of Contents

[Executive Summary](#1-executive-summary)

[Application Overview](#2-application-overview)

[Architecture & Supply Chain](#3-architecture--supply-chain)

[Network Security](#4-network-security)

[Data Handling & Privacy](#5-data-handling--privacy)

[Code Security Vulnerabilities](#6-code-security-vulnerabilities)

[Permissions & System Access](#7-permissions--system-access)

[Consolidated Risk Matrix](#8-consolidated-risk-matrix)

[Conclusion & Recommendations](#9-conclusion--recommendations)

[Appendix: Audit Methodology](#10-appendix-audit-methodology)

---

1. Executive Summary

TL;DR for Management

This report presents the findings of a comprehensive, five-domain security audit of the ScorpioX CLI codebase — a 369,205-line C11 platform comprising 45+ executables that provide AI agent orchestration, rootless containers, a mail server, a DNS server, a KVM hypervisor, and supporting tools.

Overall Risk Rating: MEDIUM

The ScorpioX codebase demonstrates several exceptional security strengths that are rare in projects of this scale:

However, the audit identified 11 critical findings and 14 high-severity findings that require attention:

No evidence of intentional backdoors, malware, or data exfiltration was found. All network communications serve legitimate application purposes.

---

2. Application Overview

What is ScorpioX CLI?

ScorpioX CLI is a multi-binary C11 platform that provides a terminal-based AI agent shell and a suite of infrastructure tools. The platform is designed to run as a self-contained system with minimal external dependencies.

Core Components

Technology Stack

• Language: C11 (gcc/clang)
• Build: CMake (no FetchContent, no network downloads)
• Vendored Deps: yyjson (JSON, MIT), mbedTLS (TLS/crypto, Apache-2.0)
• System Deps: libcurl, openssl, zlib, zstd, nghttp2, ncurses (statically linked on Linux)
• Platforms: Linux (primary, static musl), macOS (ARM64), Windows (MinGW), WASM (Emscripten)

---

3. Architecture & Supply Chain

Source: 01-architecture.md

3.1 Supply Chain Security Assessment

Rating: LOW risk — The core build pipeline is exemplary.

The ScorpioX build system achieves a level of supply chain security that is uncommon in modern software:

• Zero package manager dependencies for the core C build — no package.json, requirements.txt, Cargo.toml, go.mod, or equivalent
• Two vendored libraries compiled from source (yyjson: ~15K LOC, mbedTLS: ~210K LOC) — both MIT/Apache-2.0 licensed, well-audited
• No FetchContent or ExternalProject in CMake — the build is fully offline-capable
• No pre-built vendor binaries — all vendor code is compiled during the build process
• Static linking on Linux via musl produces standalone executables with no runtime library resolution

3.2 Dependency Breakdown

Total: 369,205 LOC
├── Vendored (yyjson + mbedTLS): 225,896 LOC (61%)
└── Project code: 143,309 LOC (39%)

3.3 Build Pipeline

3.4 Architecture Findings

---

4. Network Security

Source: 02-network.md

4.1 Network Footprint

ScorpioX is a heavily networked application with:

• 20+ outbound external endpoints (AI APIs, search engines, distribution, telemetry)
• 6 inbound server components (SMTP:25/587, IMAP:993, HTTP:8080, TCP:9800/9801, WebSocket:6080)
• IPC channels via Unix domain sockets and named pipes
• Infrastructure networking via FRP reverse proxy and slirp4netns container networking

4.2 AI Provider Connectivity

4.3 Critical: TLS Certificate Verification Disabled

SSL/TLS certificate verification is disabled in 8 locations across the codebase:

4.4 Critical: Plaintext Token Transport

OAuth bearer tokens are transmitted over unencrypted raw TCP on port 9800:

• Connects to proxy.scorpiox.net:9800 / 20.53.240.54:9800
• Server sends JSON with access_token and expires_at fields
• No TLS, no encryption, no integrity protection
• An attacker on the network path can intercept valid OAuth tokens

4.5 Network Findings Summary

---

5. Data Handling & Privacy

Source: 03-data-handling.md

5.1 Data Flow Overview

User Input ──► sx.c (TUI) ──► Provider (API) ──► AI Response
     │              │              │                    │
     ▼              ▼              ▼                    ▼
 Bash exec    Conversation    HTTP Request          Display
 (sx_exec)    .json save     (credentials)        (sxui_*)
     │              │              │                    │
     ▼              ▼              ▼                    ▼
 /tmp files   .scorpiox/     Traffic capture     Session log
              sessions/      .scorpiox/traffics/  events.jsonl

5.2 PII Data Handled

5.3 Critical: Hardcoded Secrets in WASM Binary

The file sx_config_embedded.c contains secrets compiled directly into the binary:

These can be trivially extracted from the distributed WASM binary using strings.

5.4 Critical: Weak Password Hashing

Email authentication (sxmail_auth.c:121) uses unsalted SHA-256:

• No per-user salt — identical passwords produce identical hashes
• SHA-256 is not a password hashing algorithm (too fast — GPU cracking at billions/sec)
• Vulnerable to rainbow table and precomputed dictionary attacks

5.5 Encryption Capabilities

5.6 Data Handling Findings Summary

---

6. Code Security Vulnerabilities

Source: 04-vulnerabilities.md

6.1 Vulnerability Summary

The code audit of 148 C source files (141,971 LOC excl. vendor) identified 23 vulnerabilities:

6.2 Critical Vulnerabilities

V-01: Command Injection via IMAP DELETE (CVSS 9.8)

File: sxmail_maildir.c:704 system("rm -rf ''") — an attacker with mailbox access can create a folder name containing '; ;' and trigger execution via IMAP DELETE.

V-02: Command Injection in VM Runner (CVSS 9.8)

File: scorpiox-vm.c:488-493 system(cmd) with URL/path from user config passed through curl/wget — single-quote injection in URLs can execute arbitrary commands.

V-03: Command Injection in Main Shell (CVSS 9.1)

File: sx.c (5 locations)

Multiple system() calls building commands from session data, config values, and file paths without proper escaping.

V-04: Command Injection in Agent (CVSS 9.1)

File: scorpiox-agent.c (12 call sites) system() and popen() with agent-provided paths, find -exec with unsanitized directory names.

6.3 High-Severity Vulnerabilities

6.4 Positive Security Practices

Despite the vulnerabilities, the codebase demonstrates good security awareness in several areas:

• ✅ snprintf over sprintf: 2,172 out of 2,192 format calls use the bounded variant (99.1%)
• ✅ No format string vulnerabilities: All printf-family calls use string literal format specifiers
• ✅ Bounds-checked HTTP header parsing: Server validates field lengths before copy
• ✅ Filename sanitization: Network receive paths sanitize filenames
• ✅ Process monitoring: Dedicated sx_procmon.c tracks fork/reap counts and resource leaks
• ✅ API key redaction in logs: Providers log key=* instead of actual values

6.5 Unsafe Function Usage

---

7. Permissions & System Access

Source: 05-permissions.md

7.1 Privilege Model

The vast majority of ScorpioX binaries operate at user-level privileges without requiring root:

No privilege escalation detected:

• No setuid/setgid/seteuid calls in first-party code
• No prctl or seccomp calls (gap — no privilege dropping either)
• No ptrace usage

7.2 Process Spawning

The codebase contains 656 process spawning call sites across multiple mechanisms:

7.3 Container Isolation (scorpiox-unshare)

7.4 Permissions Findings Summary

---

8. Consolidated Risk Matrix

8.1 All Findings by Severity

8.2 Findings by Severity Count

8.3 Findings by Domain

---

9. Conclusion & Recommendations

9.1 Overall Assessment

The ScorpioX CLI codebase is a well-architected, security-conscious C project that achieves exceptional supply chain security through its zero-dependency, vendored, statically-linked build model. The codebase is remarkably self-contained — a property that eliminates entire categories of modern software supply chain attacks.

However, the project's broad scope (45+ binaries spanning AI agents, containers, VMs, email, DNS, HTTP servers, and more) creates a correspondingly large attack surface. The most significant risks stem from:

Unsafe shell command construction — the pervasive use of system() and popen() with string-concatenated commands is the single largest security concern

Disabled TLS verification — undermines the security of all network communications

Hardcoded credentials — particularly in the WASM binary distribution path

Missing defense-in-depth for containers — no seccomp, no IPC isolation

9.2 Priority Remediation Roadmap

Immediate (Week 1-2) — Critical Items

Short-term (Sprint 1-2) — High Items

Medium-term (Quarter) — Systemic Improvements

Long-term (Backlog)

9.3 Positive Findings Summary

It is important to note the many areas where ScorpioX demonstrates strong security practices:

• ✅ Zero external build dependencies — supply chain risk near zero for core build
• ✅ 99.1% of format calls use snprintf (bounded)
• ✅ No format string vulnerabilities found
• ✅ No privilege escalation code (setuid/seteuid) in any binary
• ✅ API keys redacted in log output
• ✅ Rootless container runtime with namespace isolation
• ✅ Static linking eliminates runtime library attacks
• ✅ Process monitoring subsystem (sx_procmon.c) tracks resource leaks
• ✅ Session data auto-excluded from git (.gitignore)
• ✅ AES-128-CFB encryption capability available for sensitive config
• ✅ Dedicated config cascade with per-project override support
• ✅ mmap() used without PROT_EXEC — no JIT/self-modifying code
• ✅ Full code provenance from single organization

---

10. Appendix: Audit Methodology

10.1 Scope

This audit covered the entire ScorpioX CLI codebase at commit b85fca9891f8ff39fce93868947ce31fe9fed50e on the main branch. The scope included 259 .c files and 234 .h files totaling 369,205 lines of code, of which 143,309 lines are first-party project code and 225,896 lines are vendored third-party libraries (yyjson, mbedTLS).

10.2 Audit Domains

10.3 Methodology

Each audit domain was assessed using automated static analysis augmented by manual code review:

Pattern Matching — Grep-based searches for known-vulnerable function calls (system, popen, sprintf, strcpy, strcat), security-sensitive operations (setuid, mmap, ioctl), and credential patterns

Data Flow Analysis — Tracing data from input (network, file, environment) through processing to output (network, file, display)

Configuration Review — Analysis of build systems (CMake), Dockerfiles, release scripts, and runtime configuration

Dependency Enumeration — Inventory of all vendored, system, and external dependencies

Severity Scoring — CVSS v3.1 base scores for code vulnerabilities; qualitative severity for architecture/process findings

10.4 Limitations

• This audit was performed via static analysis only — no runtime testing, fuzzing, or penetration testing was conducted
• Vendored library code (yyjson, mbedTLS) was not audited — these are well-known, externally-audited projects
• WASM-specific behavior was assessed via source review only — no browser-based testing
• Windows-specific code paths (*.ps1 scripts, MinGW builds) received limited coverage
• The audit did not verify whether hardcoded credentials are still valid or have been rotated

10.5 Tools Used

• Source code grep and pattern analysis
• Line counting (wc -l, cloc)
• Git log analysis for provenance
• CMakeLists.txt analysis for build process
• Manual C code review for vulnerability assessment

---

Report compiled on 2026-04-28 by Security Audit Agent ScorpioX CLI Security Assessment — Commit b85fca9 — CONFIDENTIAL