Third-Party Software Security Review — ScorpioX Code

Software: ScorpioX Code Type: AI-Powered Development Tool / CLI Platform Language: Pure C (zero external dependencies) Audit Date: 2026-04-29 Codebase Commit: b79400081eaa311219dd5d16aa7813f6ccbebba4 Classification: CONFIDENTIAL — For Corporate Review Only

---

1. Executive Summary

This report presents a comprehensive security audit of ScorpioX Code, an AI-powered development CLI platform written in pure C11 with zero external package-manager dependencies. The audit was conducted by 13 specialized automated agents covering supply chain, build provenance, network communications, TLS, credential handling, file I/O, buffer safety, memory safety, command injection, privilege management, Windows deployment, telemetry, and install/distribution security.

Key Metrics

Summary Assessment

The codebase demonstrates strong security fundamentals: zero use of unsafe C functions (sprintf, strcpy, strcat, gets), comprehensive snprintf/strncpy usage (2,232+ bounded format calls), all secrets loaded from runtime configuration with empty compiled defaults, TLS 1.2+ enforced by default with certificate verification enabled, and all telemetry disabled by default. The vendored dependencies (mbedTLS 3.6.6, yyjson 0.12.0, stb_image 2.30) are all current with no known unpatched CVEs.

The primary risk areas are:

Install & Distribution Security (HIGH) — Missing HTTPS scheme on an install URL (curl | bash), no code signing, SHA256 checksums co-located with binaries, and container image downloads lacking integrity verification.

Command Injection (HIGH) — Multiple system() calls with environment-variable or config-driven inputs, particularly on Windows code paths where fork()+execvp() is unavailable.

Memory Safety (MEDIUM) — 93 allocation sites without NULL checks, 6 in critical network code paths, plus resource leaks on error paths.

File I/O (MEDIUM) — Predictable temp file names in two code paths, unbounded API request/response logging to disk.

For Windows workstation deployment, the risk profile is LOW. All 10 Windows-specific findings are informational. The Windows build uses safe process APIs (_spawnvp, CreateProcess), SHA256-verified downloads, configurable endpoints, and no hardcoded secrets.

---

2. Deployment Scope — Windows Workstation

2.1 Primary Deployment: Windows Workstation

The following binaries are compiled for and deployed on Windows:

Additional Windows-compiled binaries include: scorpiox-voice, scorpiox-server, scorpiox-otp, scorpiox-transcript, scorpiox-conv, scorpiox-rewind, scorpiox-debug, scorpiox-logger, scorpiox-printlogs, scorpiox-systemprompt, scorpiox-search, scorpiox-agent, scorpiox-tasks, scorpiox-skills, scorpiox-planmode, scorpiox-askuserquestion, scorpiox-gemini, scorpiox-mcp, scorpiox-beam, scorpiox-host, scorpiox-openai, scorpiox-claudecode-fetchtoken, scorpiox-claudecode-refreshtoken, scorpiox-codex-refreshtoken, scorpiox-claudecode-models, scorpiox-codex-fetchtoken, scorpiox-gemini-fetchtoken, scorpiox-server-fetchtoken, scorpiox-server-http2tcp, scorpiox-sdk, scorpiox-email, scorpiox-server-email, scorpiox-usage, scorpiox-emit-session, scorpiox-frp, scorpiox-hook, scorpiox-tmux, scorpiox-multiplexer, scorpiox-mirror-git, scorpiox-vault-git, scorpiox-dns, scorpiox-kql, libsx.dll.

2.2 Server-Side / Linux-Only (Not Deployed to Workstations)

2.3 Windows-Filtered Findings

The vast majority of critical, high, and medium findings relate to Linux-only components (container runtime, VM runner, MITM proxy) or Linux-only code paths (fork()+execvp() patterns, Unix temp files, privileged port binding). The Windows deployment surface is materially safer.

---

3. Changes Since Last Audit

Findings Delta by Severity

Key changes: The overall risk rating remains MEDIUM. The significant increase in total findings reflects the expanded scope (13 specialized agents vs 5 broad agents), not a degradation in code quality. Critical findings decreased from 11 to 3, indicating that previous broad-scope agents over-classified some findings. The codebase grew by ~5,400 lines with vendor library updates (mbedTLS).

---

4. Supply Chain & Dependencies

Risk: LOW

The project has a minimal dependency footprint with zero external package-manager dependencies for the core C build.

Vendored Libraries

NPM Dependencies (Optional Bridge Only)

• No package-lock.json present — dependency pinning missing for the bridge component.
• No node_modules/ committed. Bridge is optional, not part of core build.

System Dependencies

Resolved at build time via system packages: libcurl, pthreads, X11 (optional), Python3 (build-time), Perl (build-time). No FetchContent, vcpkg, conan, or CPM usage.

Findings

---

5. Build System & Code Provenance

Risk: LOW

Security Hardening Flags

Findings

---

6. Network Endpoints

Risk: MEDIUM

The codebase contains 145+ hardcoded URLs, 30+ IP addresses, and 40+ unique domains. All production endpoints use HTTPS. Key categories:

Production Infrastructure Endpoints

Third-Party API Endpoints

Findings

---

7. TLS/SSL Security

Risk: LOW

The codebase has a well-designed centralized TLS configuration via sx_curl_set_tls(). Certificate verification is enabled by default, TLS 1.2 is the minimum protocol version, and mbedTLS is configured appropriately.

Findings

Positive Findings

• TLS 1.2 minimum enforced in all configurations
• Certificate verification ON by default with documented dev-only bypass
• mbedTLS configured with strong cipher suites
• MITM proxy tool (scorpiox-traffic) is Linux-only and does not affect Windows deployment

---

8. Hardcoded Credentials

Risk: LOW No critical or high-severity hardcoded credentials found. All API key, password, secret, and token configuration fields use empty string defaults populated at runtime. The codebase follows a configuration-driven approach where secrets are loaded from files, environment variables, SSH, HTTP endpoints, or TCP sockets.

Findings

---

9. File I/O & Data Handling

Risk: MEDIUM

Config files and logs use chmod 0600; session directories use 0700; mkstemp() is used for most temp files. However, several medium-severity issues exist.

Findings

Positive Findings

• ✅ Consistent mkstemp() usage with XXXXXX templates across most of codebase
• ✅ sx_config_is_sensitive() masks KEY/PASS/SECRET/TOKEN values in log output
• ✅ Config files protected with chmod 0600
• ✅ Session/socket directories use 0700
• ✅ Path traversal validation in maildir
• ✅ Atomic file operations via write-to-temp-then-rename pattern
• ✅ Password hashing (SHA256) for email accounts, not plaintext

---

10. Buffer Safety

Risk: LOW

The codebase demonstrates excellent buffer safety discipline. Zero uses of sprintf, strcpy, strcat, gets, or scanf in project-owned code.

Metrics

Safe-to-unsafe ratio: ∞ (no unsafe function calls)

Findings

---

11. Memory Safety

Risk: MEDIUM

The codebase contains 525 dynamic allocation calls (291 malloc, 90 calloc, 110 realloc) across ~110 source files with ~1,395 free() calls. The project generally follows a safe realloc pattern. However, 93 allocation sites lack NULL-check validation.

Findings

Positive Findings

• ✅ No confirmed use-after-free or double-free vulnerabilities
• ✅ Safe realloc pattern: tmp = realloc(ptr, ...); if (!tmp) { free(ptr); return; } ptr = tmp;
• ✅ No PROT_EXEC mmap usage

---

12. Command Injection

Risk: HIGH

The codebase contains ~80 system() calls, ~30 popen() calls, and ~50 exec*() calls. Many files demonstrate awareness of injection risks with is_safe_shell_arg() validation and explicit fork()+execvp() usage. However, several high-severity vectors remain.

Findings

Positive Findings

• ✅ is_safe_shell_arg() validation blocks ;|&$\(){}'\n\r<> on critical paths
• ✅ Multiple files contain explicit comments about replacing system() with fork()+execvp()
• ✅ Windows paths generally use _spawnvp() (argv-based, no shell interpolation)
• ✅ Unix paths increasingly use fork()+execvp() for safety

---

13. Privilege & Access Control

Risk: MEDIUM

No direct setuid()/setgid() calls in project source. However, several components require root or elevated privileges to function.

Components Requiring Elevated Privileges

Component	Requirement	Platform
scorpiox-unshare --privileged	Real root (skips user namespace)	Linux
scorpiox-vm	/dev/kvm access (kvm group or root)	Linux
scorpiox-vm	/dev/net/tun (CAP_NET_ADMIN)	Linux
scorpiox-thunderbolt4	/dev/bpf* (sudo required)	macOS
scorpiox-dns	Port 53 binding (privileged port)	Linux
scorpiox-server-email	Ports 25/587/993 (privileged ports)	Linux

Findings

#	Severity	Finding
P-1	Critical	--privileged container mode disables user namespace — real root, no isolation
P-2	High	scorpiox-unshare auto-writes /etc/subuid//etc/subgid when running as root
P-3	High	scorpiox-thunderbolt4 requires sudo for raw BPF access
P-4	High	40+ system() calls across multiple files create shell injection surface
P-5–P-12	Medium (8)	Privileged port bindings, GPU passthrough, network namespace bypass, daemon processes

Positive Findings

• ✅ No setuid()/setgid() calls in project code
• ✅ Full rootless container runtime with proper namespace isolation (default mode)
• ✅ User namespace UID/GID mapping follows best practices
• ✅ Mount propagation set to MS_REC | MS_PRIVATE
• ✅ /proc mounted with MS_NOSUID | MS_NODEV | MS_NOEXEC
• ✅ OverlayFS for stateless container writes

---

14. Windows Deployment Analysis

Risk: LOW

The Windows build is well-engineered with proper platform abstractions, safe process execution, and no hardcoded secrets.

Windows Build Architecture

Aspect	Detail
Compiler	MinGW GCC (WinLibs POSIX UCRT)
Linking	Fully static (-static, CURL_STATICLIB)
System Libs	ws2_32, crypt32, advapi32, bcrypt, gdi32, user32
DLL	Optional libsx.dll for C# P/Invoke

Windows-Specific Security Properties

• Process execution: Uses _spawnvp() (argv-based) and CreateProcess — no system() for user input
• Downloads: SHA256-verified via WinINet (InternetOpenA, InternetReadFile)
• WSL2 integration: Safe wsl.exe invocation via _popen() with sanitized distro names
• Self-update: Download → SHA256 verify → MoveFileA rename with rollback
• Config: Standard %USERPROFILE%\.claude\scorpiox-env.txt — no system directory writes

Findings (All Informational)

#	Finding
W-1	Network endpoints contact external APIs (all configurable, all HTTPS)
W-2	WinINet used for downloads (SHA256 verified)
W-3	WSL2 distro management via wsl.exe
W-4	CreateProcess for shell commands with temp .bat files
W-5	Winsock initialization (standard)
W-6	DLL exports 6 functions for P/Invoke
W-7	Static linking with vendored libraries
W-8	GNU tools distribution via scorpiox-busybox
W-9	Standard Windows file paths
W-10	Self-update mechanism (SHA256 verified)

---

15. Telemetry and Tracking

Risk: LOW All telemetry is disabled by default. No network calls related to tracking occur unless explicitly opted in via configuration.

Default Configuration

Config Key	Default	Effect
USAGE_TRACKING	0 (disabled)	Token usage reporting
EMIT_SESSION_TRACKING	0 (disabled)	Full conversation reporting
WA_BRIDGE_AUTO_UPDATE	on-demand	Only when WhatsApp feature is used

Data Collection (When Opted In)

Feature	Data Collected	Privacy Impact
Usage Tracking	Session ID, provider, model, token counts, hostname, username, OS	Medium — machine fingerprint
Session Tracking	Full conversation content (prompts, responses, tool output)	High — complete conversation data

Findings

#	Severity	Finding
TL-1	Low	Stale comment says USAGE_TRACKING default is 1 but compiled default is 0
TL-2	Info	Session telemetry sends full conversation content when enabled
TL-3	Info	Usage tracking collects hostname/username when enabled

Corporate Deployment Recommendation

No configuration changes needed for zero tracking — the defaults already disable all telemetry. For additional hardening:

• Remove scorpiox-usage and scorpiox-emit-session binaries from installation
• Block code.scorpiox.net at firewall/proxy level

---

16. Install Script & Distribution Security

Risk: HIGH

This is the highest-risk area of the audit. The distribution pipeline has significant gaps in integrity verification and code signing.

Findings

#	Severity	Finding
IS-1	Critical	Install URL missing https:// scheme — potential plaintext HTTP download piped to bash
IS-2	High	No code signing on any distributed binary (GPG, cosign, Authenticode all absent)
IS-3	High	SHA256 checksums co-located with binaries on same server — compromised server defeats verification
IS-4	High	Container image downloads have zero integrity verification
IS-5	High	Container bootstrap curl \	tar with no hash verification
IS-6	Medium	Bridge SHA256 bypass: invalid .sha256 format allows unverified install
IS-7	Medium	Firmware download (SeaBIOS) has no integrity verification
IS-8	Medium	curl \	bash install pattern — inherently risky
IS-9	Medium	No reproducible builds — no SOURCE_DATE_EPOCH, unpinned Docker images
IS-10	Low	Distribution via SMB to NAS — network-level trust for upload integrity
IS-11	Low	WSL self-update dead code (defined but never called)
IS-12	Low	macOS codesign uses ad-hoc signature (--sign -), not Developer ID

---

17. Consolidated Risk Matrix

#	Area	Finding	Severity	Status	Recommendation
IS-1	Distribution	Install URL missing https:// scheme	Critical	Open	Add https:// prefix to install URL in scorpiox-sdk.c:1228
CJ-1	Command Injection	iMessage user content reaches system() via AppleScript	Critical	Open	Sanitize message content before AppleScript interpolation (macOS-only)
P-1	Privilege	--privileged container mode disables all isolation	Critical	By Design	Document risk; restrict --privileged flag usage
IS-2	Distribution	No code signing on distributed binaries	High	Open	Implement GPG signing for Linux, Authenticode for Windows
IS-3	Distribution	SHA256 checksums co-located with binaries	High	Open	Host checksums on separate infrastructure or use code signing
IS-4	Distribution	Container images downloaded without integrity check	High	Open	Verify SHA256 of container image tarballs before extraction
IS-5	Distribution	Container bootstrap curl \	tar unverified	High	Open	Add hash verification to container bootstrap scripts
CJ-2	Command Injection	Env var SCORPIOX_DOCS_PYTHON reaches system()	High	Open	Use fork()+execvp() for dependency checks (Linux-only)
CJ-3	Command Injection	TUI ! shell escape — direct system()	High	By Design	Document risk for automated/remote TUI scenarios
CJ-4	Command Injection	Windows CGI builds cmd.exe from HTTP params	High	Mitigated	SX_SANITIZE_CMD strips dangerous chars; consider reject-not-strip
CJ-5	Command Injection	SQLite file paths reach system()	High	Open	Use fork()+execvp() for file copy operations
MS-H1–6	Memory Safety	Missing NULL checks in network code	High	Open	Add NULL checks after allocation in sx_request.c, sx_http.c, etc.
P-2	Privilege	Auto-writes to /etc/subuid//etc/subgid	High	Open	Require explicit user confirmation before modifying system files
P-3	Privilege	BPF raw access requires sudo	High	By Design	Document requirement (macOS-only)
P-4	Privilege	40+ system() calls across codebase	High	Ongoing	Migrate to fork()+execvp() — several files already converted
T-1	TLS	HTTP relay forwards API traffic unencrypted	Medium	By Design	Warn user when HTTP relay is active
BF-1	Buffer	Unclamped snprintf accumulation (sdk)	Medium	Open	Add if (cpos >= sizeof(buf)) break; clamping
BF-2	Buffer	Unclamped snprintf accumulation (wsl)	Medium	Open	Add offset clamping after each snprintf
F-1	File I/O	Predictable temp file in editor flow	Medium	Open	Replace with mkstemp()
F-2	File I/O	Predictable temp file on Windows POST	Medium	Open	Use GetTempFileNameA()
F-3	File I/O	API bodies logged indefinitely	Medium	Open	Add log rotation with size limits
IS-6	Distribution	Bridge SHA256 bypass on invalid format	Medium	Open	Treat invalid .sha256 format as failure
IS-7	Distribution	Firmware download unverified	Medium	Open	Pin SHA256 hash for BIOS firmware
IS-8	Distribution	curl \	bash install pattern	Medium	By Design	Provide two-step download-then-verify alternative
IS-9	Distribution	No reproducible builds	Medium	Open	Pin Docker image digests, set SOURCE_DATE_EPOCH
S-1	Supply Chain	Unpinned Docker base image	Medium	Open	Pin alpine to digest
S-2	Supply Chain	curl source download without checksum	Medium	Open	Add SHA256 verification to Dockerfile
B-1	Build	No noexecstack on static builds	Medium	Open	Add -z,noexecstack to static link flags
B-2	Build	Network-capable build-time code gen	Medium	Mitigated	MODELS_FROZEN=True gate — consider removing network option
MS-M1–15	Memory Safety	Resource/memory leaks on error paths	Medium	Open	Fix cleanup in tb4_transport.c, sx_term.c, etc.
CJ-6–11	Command Injection	Various system() with validated inputs	Medium	Mitigated	Continue migration to execvp()
N-1–3	Network	Hardcoded IPs/endpoints in embedded config	High	Open	Move to deployment-time configuration
P-5–12	Privilege	Privileged ports, GPU passthrough, etc.	Medium	By Design	Document requirements; all Linux-only

---

18. Conclusion & Recommendations

Overall Assessment

ScorpioX Code demonstrates strong security engineering fundamentals for a C-based project of this scale. The codebase achieves zero unsafe C function usage, comprehensive input validation on critical paths, secure defaults for TLS and telemetry, and a clean dependency profile with up-to-date vendored libraries. The code quality indicates an experienced development team with active security awareness.

Risk Rating

Scope	Rating	Rationale
Overall	MEDIUM	Install/distribution gaps and residual system() usage offset strong fundamentals
Windows Workstation	LOW	All Windows-specific findings are informational; safe process APIs used throughout
Linux Server	MEDIUM-HIGH	Container runtime, VM, and server components have broader attack surface

Priority Recommendations

Immediate (Critical/High):

Fix install URL — Add https:// prefix to get.scorpiox.net URL in scorpiox-sdk.c:1228

Implement code signing — Authenticode for Windows binaries, GPG for Linux

Add container image verification — SHA256 check before extraction in scorpiox-unshare.c

Add NULL checks — 6 high-severity missing checks in network provider code

Sanitize iMessage content — Escape shell metacharacters before AppleScript interpolation

Short-Term (Medium):

Migrate system() to execvp() — Prioritize scorpiox-docs.c, scorpiox-search.c, scorpiox-init.c

Fix predictable temp files — Replace fopen() with mkstemp() in sx.c:615 and Windows POST handler

Add log rotation — Size-limited rotation for api.log and session logs

Host checksums separately — Move .sha256 files to different infrastructure than binaries

Fix snprintf accumulation — Add clamping in scorpiox-sdk.c and scorpiox-wsl.c

Long-Term:

Reproducible builds — Pin Docker images by digest, set SOURCE_DATE_EPOCH

Memory safety sweep — Address remaining 72 low-severity NULL check gaps

npm lockfile — Add package-lock.json for bridge component

Firmware integrity — Pin SHA256 hashes for all downloaded firmware

---

19. Appendix: Audit Methodology

Agents Deployed

#	Agent	Scope	Report
1	supply-chain	Dependencies, vendored libs, build-time downloads	01-supply-chain.md
2	build-provenance	CMake config, compiler flags, hardening	02-build-provenance.md
3	network-endpoints	URLs, IPs, ports, domains in source	03-network-endpoints.md
4	tls-security	TLS config, certificate verification, protocol versions	04-tls-security.md
5	credential-hardcode	API keys, passwords, tokens, secrets in source	05-credential-hardcode.md
6	file-io	Temp files, permissions, data at rest, logging	06-file-io.md
7	buffer-safety	Buffer overflow, unsafe functions, format strings	07-buffer-safety.md
8	memory-safety	malloc/free, NULL checks, use-after-free, leaks	08-memory-safety.md
9	command-injection	system(), popen(), exec*(), shell metacharacters	09-command-injection.md
10	privilege-access	setuid, root access, namespaces, daemon processes	10-privilege-access.md
11	windows-deployment	Windows binaries, APIs, platform-specific risks	11-windows-deployment.md
12	telemetry-tracking	Data collection, phone-home, opt-in/out behavior	12-telemetry-tracking.md
13	install-script	Distribution, install scripts, code signing, integrity	13-install-script.md

Methodology

• Static analysis of all project-owned C source files (excluding vendor code unless explicitly noted)
• Pattern matching for unsafe functions, hardcoded values, and known vulnerability patterns
• Manual verification of all automated findings to eliminate false positives
• Cross-referencing between agents to identify compound risk scenarios
• Platform-specific analysis separating Windows, Linux, and macOS code paths
• Configuration review of build system, deployment scripts, and default settings

Scope Limitations

• Runtime behavior was not tested (no dynamic analysis or fuzzing)
• The get.scorpiox.net` install script content was not available for review
• Vendor library code (mbedTLS, yyjson, stb_image) was reviewed for version/CVE status only, not line-by-line
• Network endpoints were identified from source code; actual network behavior was not monitored