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-28 Codebase Commit: 2b6f3d37e8fc5ffacf967ddcf2682415887cb525 Classification: CONFIDENTIAL — For Corporate Review Only

---

1. Executive Summary

This report presents the findings of a comprehensive security audit of ScorpioX Code, an AI-powered development tool and CLI platform written in pure C. The audit was conducted by 13 specialized automated agents, each targeting a specific security domain. The codebase comprises 399,383 lines of code (171,633 first-party, 227,750 vendored) across 492 source files.

Overall Risk Rating: HIGH

The audit identified 240 total findings across all domains:

Key Risk Areas:

TLS/Certificate Verification (CRITICAL): SSL certificate verification is systematically disabled across most cURL-based HTTP clients and all mbedTLS client connections. Token-fetching modules transmit authentication credentials over plaintext HTTP. Only two modules correctly enforce certificate verification.

Command Injection (HIGH): Windows cmd.exe injection vectors exist in the HTTP server component via unsanitized HTTP query parameters and JWT claims. A web search module on Windows passes user queries into popen() without shell escaping.

Install & Distribution (HIGH): The primary install command lacks an HTTPS scheme prefix. Release builds generate no SHA256 checksums. No code signing exists. SHA256 verification is silently skipped when sidecar files are unavailable.

Memory Safety (MEDIUM): 46 findings including dangerous realloc patterns that lose pointers on failure, memory leaks on error paths, and 23+ unchecked strdup return values in API handling code.

Network Endpoints (CRITICAL): 149 hardcoded URL references in first-party code, including 4 plaintext HTTP endpoints transmitting authentication tokens and a hardcoded public IP address compiled into the WASM binary.

Key Strengths:

• Zero external package manager dependencies for the core C build
• Static linking reduces runtime dependency attack surface
• No setuid/setgid binaries; no calls to setuid()/setgid()
• 99.6% safe string operation ratio (2,841 safe vs. 12 unsafe calls)
• Zero sprintf, strcpy, gets, or scanf usage in first-party code
• All telemetry disabled by default with explicit opt-in required
• Secure mkstemp() used throughout for temp file creation
• Strong compiler hardening flags (-fstack-protector-strong, -D_FORTIFY_SOURCE=2, -fcf-protection)

---

2. Deployment Scope — Windows Workstation

2.1 Primary Deployment: Windows Workstation

The software is evaluated for deployment on Windows workstations. Server-side components (email server, container runtime, VM hypervisor) are not in scope for this deployment.

2.2 Windows Binaries (56 executables + 1 DLL)

The following binaries compile for and ship on Windows:

2.3 Linux-Only Binaries (Not Deployed on Windows)

2.4 Windows-Filtered Findings

When scoped to Windows workstation deployment only (excluding Linux-only binaries and server-only components):

---

3. Changes Since Last Audit

Previous Audit: 9bfa5b461aa008cd7a1713d37c9aa6c44cecc4ce (2026-04-28) Current Audit: 2b6f3d37e8fc5ffacf967ddcf2682415887cb525 (2026-04-28) Lines of Code Change: 378,558 → 399,383 (+20,825 lines, +5.5%) Previous Overall Risk: HIGH Current Overall Risk: HIGH Key Changes:

• Findings reduced by 56% overall (549 → 240), primarily from reduced informational and medium findings due to improved audit methodology precision
• Critical findings increased by 4 — new install-script agent identified 3 critical distribution security issues not previously audited; network endpoint findings now scoped more precisely
• High findings decreased by 5 — improvements in code patterns and refined analysis
• Codebase grew by ~20,800 lines — new features added while maintaining similar risk profile
• New audit agents added: telemetry-tracking and install-script agents are new in this audit cycle, covering previously unaudited areas

---

4. Supply Chain & Dependencies

Agent: supply-chain | Risk: MEDIUM | Findings: 8 (0C, 0H, 2M, 3L, 3I)

4.1 Dependency Overview

4.2 Vendored Libraries

4.3 Key Findings

• MEDIUM: Two pre-built ELF binaries (scorpiox-ws2tcp, scorpiox-ws2tcp-arm64) committed to the repository without provenance verification
• MEDIUM: MBEDTLS_SSL_VERIFY_NONE used in 3 locations, disabling certificate chain validation in mail relay and FRP tunnel clients
• LOW: No checksum verification for gnuwin64 downloaded packages
• LOW: npm dependency uses caret version range permitting minor/patch drift; only bun.lock present (no package-lock.json)

4.4 Positive Observations

• No FetchContent or ExternalProject in CMake — all third-party code is vendored locally
• No downloads during the CMake build process
• Clear license files for all vendored libraries
• mbedTLS 3.6.3 is current LTS with latest security patches

---

5. Build System & Code Provenance

Agent: build-provenance | Risk: LOW | Findings: 12 (0C, 0H, 4M, 2L, 6I)

5.1 Build Configuration

5.2 Compiler Hardening

5.3 Key Findings

• MEDIUM: Position Independent Executable (PIE) not enabled — reduces ASLR effectiveness
• MEDIUM: Full RELRO not enabled — GOT overwrite protection absent
• MEDIUM: Bridge binary (Makefile) lacks -fstack-protector-strong and -D_FORTIFY_SOURCE=2
• MEDIUM: Model header generator can make network calls if --fetch flag is passed (currently frozen)
• INFO: All 493 C/H source files trace to single-organization authorship (987 commits, SX_VERSION macro tracks version)

---

6. Network Endpoints

Agent: network-endpoints | Risk: CRITICAL | Findings: 66 (4C, 5H, 16M, 14L, 27I)

6.1 Endpoint Summary

• 149 hardcoded URL references in first-party code
• 218 URL references in vendored code (documentation only — no runtime impact)
• 21 distinct active network domains contacted at runtime

6.2 Critical Endpoints

6.3 High-Risk Endpoints

6.4 DNS Configuration

Default DNS resolvers are hardcoded to Google (8.8.8.8) and Cloudflare (1.1.1.1), which leak DNS query data to third-party providers (MEDIUM).

---

7. TLS/SSL Security

Agent: tls-security | Risk: CRITICAL | Findings: 10 (3C, 2H, 3M, 1L, 1I)

7.1 Critical Findings

7.2 High Findings

7.3 Positive Observations

• Two files (scorpiox-codex-refreshtoken.c, scorpiox-claudecode-refreshtoken.c) correctly enforce full certificate verification — proves the codebase has the pattern available
• mbedTLS 3.6.3 supports TLS 1.2/1.3 with modern cipher suites
• No deprecated SSL 2.0/3.0 or TLS 1.0/1.1 protocol support

---

8. Hardcoded Credentials

Agent: credential-hardcode | Risk: LOW | Findings: 5 (0C, 0H, 1M, 2L, 2I)

8.1 Findings

8.2 Positive Observations

• Configuration-driven architecture with most credential fields left empty
• No actual API keys, passwords, or tokens found in source code
• The sx_config_embedded.c file properly uses empty strings for all credential slots except the placeholder noted above

---

9. File I/O & Data Handling

Agent: file-io | Risk: MEDIUM | Findings: 16 (0C, 2H, 4M, 4L, 6I)

9.1 High Findings

9.2 Medium Findings

9.3 Positive Observations

• Secure mkstemp() used consistently — zero tmpnam()/tmpfile() usage
• Sensitive directories created with 0700 permissions
• File operations use bounded snprintf for path construction

---

10. Buffer Safety

Agent: buffer-safety | Risk: LOW | Findings: 8 (0C, 0H, 2M, 3L, 3I)

10.1 String Operation Safety Ratio

Safe-to-unsafe ratio: 99.6%

10.2 Key Findings

---

11. Memory Safety

Agent: memory-safety | Risk: MEDIUM | Findings: 46 (3C, 8H, 18M, 12L, 5I)

11.1 Allocation Statistics

• 913 dynamic allocation sites in 97 non-vendor C source files
• Mixed NULL-check discipline: critical paths generally checked, but many strdup/malloc calls omit validation

11.2 Critical Findings

11.3 High Findings

---

12. Command Injection

Agent: command-injection | Risk: HIGH | Findings: 21 (3C, 5H, 6M, 3L, 4I)

12.1 Execution Function Usage

12.2 Critical Findings

12.3 High Findings

12.4 Positive Observations

• Many Unix code paths intentionally use fork()+execvp() to avoid shell injection, with explicit comments noting this choice
• SX_SANITIZE_CMD macro exists and is applied in many Windows code paths — the critical findings are cases where it was missed
• Windows CreateProcessA used in several modules instead of system()

---

13. Privilege & Access Control

Agent: privilege-access | Risk: MEDIUM | Findings: 15 (1C, 2H, 4M, 3L, 5I)

13.1 Key Findings

13.2 Windows-Specific Access

• No setuid/setgid equivalent requested
• No Windows service installation
• No Windows registry modifications
• No UAC elevation requests
• Process spawning primarily uses CreateProcessA on Windows

---

14. Windows Deployment Analysis

Agent: windows-deployment | Risk: LOW | Findings: 8 (0C, 0H, 3M, 2L, 3I)

14.1 Build Configuration

• MinGW (GCC) with static linking via CMake+Ninja
• 56 executables + 1 shared library (libsx.dll)
• 2 Windows-only binaries: scorpiox-wsl.exe, scorpiox-busybox.exe

14.2 Findings

14.3 Positive Observations

• Sound platform abstraction with proper #ifdef guards
• Correct Winsock initialization patterns (WSAStartup)
• CreateProcessA preferred over system() in most Windows paths
• No Windows registry modifications
• No UAC elevation requests
• No persistent Windows services installed

---

15. Telemetry and Tracking

Agent: telemetry-tracking | Risk: LOW | Findings: 9 (0C, 0H, 0M, 2L, 7I)

15.1 Telemetry Status: Disabled by Default

All telemetry features are disabled by default in compiled defaults, shipped config, and WASM embedded config. No network calls related to telemetry or analytics occur unless explicitly enabled by the user.

15.2 Telemetry Features

15.3 Key Findings

15.4 Positive Observations

• Explicit opt-in required for all telemetry
• No phone-home behavior at application startup
• No background update checks
• Usage tracking does NOT collect conversation content
• Clear separation between metadata telemetry and content telemetry

---

16. Install Script & Distribution Security

Agent: install-script | Risk: HIGH | Findings: 16 (3C, 4H, 5M, 2L, 2I)

16.1 Critical Findings

16.2 High Findings

16.3 Medium Findings

---

17. Consolidated Risk Matrix

---

18. Conclusion & Recommendations

18.1 Overall Assessment

ScorpioX Code demonstrates strong foundational security practices in its C codebase — particularly in buffer safety (99.6% safe), absence of privilege escalation mechanisms, and disabled-by-default telemetry. However, significant security gaps exist in TLS certificate verification, distribution integrity, and Windows command injection vectors that warrant remediation before enterprise deployment.

18.2 Priority Recommendations

Immediate (Critical — Before Deployment):

Enable TLS certificate verification across all cURL and mbedTLS client connections. The codebase already demonstrates correct verification in *-refreshtoken.c files — replicate this pattern across all token-fetch and email modules.

Migrate all token endpoints to HTTPS. Replace http://token.scorpiox.net/* URLs with https:// equivalents in sx_config_embedded.c, scorpiox-codex-fetchtoken.c, and scorpiox-gemini-fetchtoken.c.

Fix Windows command injection vectors in scorpiox-server.c by applying SX_SANITIZE_CMD to HTTP query parameters and JWT claims, and in scorpiox-websearch.c by using CreateProcessA instead of popen().

Implement distribution integrity: Generate SHA256 checksums in release scripts, enforce verification (fail-closed), and add code signing (Authenticode for Windows, GPG for Linux).

Short-Term (High — Within 30 Days):

Fix dangerous realloc patterns (use temporary variable).

Add NULL checks for all strdup/malloc return values in API and provider modules.

Add username validation in mail subsystem to prevent path traversal.

Default HTTP server to 127.0.0.1 binding.

Enable PIE and Full RELRO compiler flags.

Medium-Term (Medium — Within 90 Days):

Clean up temp file management — ensure all mkstemp files are unlinked by the consumer.

Replace all system() calls with CreateProcessA (Windows) / execvp() (Linux) where feasible.

Make OAuth endpoints and DNS resolvers configurable rather than hardcoded.

Add -fPIE/-pie and -Wl,-z,relro,-z,now to the bridge Makefile.

18.3 Risk Acceptance Notes

For Windows workstation deployment specifically, the risk profile is somewhat improved:

• Linux-only critical finding (root requirement in Thunderbolt4) does not apply
• Container runtime privilege escalation findings do not apply
• Windows Firewall provides default inbound protection for the 0.0.0.0 binding issue
• The primary concerns remain TLS verification, command injection, and distribution integrity

---

19. Appendix: Audit Methodology

19.1 Agents Deployed

19.2 Scope

• In scope: All 492 C/H source files in first-party code; vendored library configuration; build scripts; installation scripts; documentation
• Out of scope: Vendored library internals (mbedTLS, yyjson) except for configuration; runtime behavior testing; penetration testing; third-party API security

19.3 Limitations

• Static analysis only — no dynamic testing or runtime behavior verification
• Findings are based on source code review; actual exploitability may differ
• Vendor library security relies on upstream CVE tracking (mbedTLS 3.6.3 is current LTS)
• Windows-specific behavior inferred from #ifdef guards and platform abstraction patterns

---

Report generated by 13 automated security audit agents. All findings should be validated by human security reviewers before remediation prioritization. End of Report