Network Communications Audit Report

Codebase: scorpiox/clang Audit Date: 2026-04-28 Auditor: Security Audit Agent Scope: All network communications, endpoints, protocols, and telemetry in 224 non-vendor C/H source files (~143,309 LOC)

---

1. Executive Summary

The scorpiox codebase is a heavily networked application with extensive outbound HTTP/HTTPS communications to multiple AI provider APIs, internal infrastructure services, and external search engines. It also includes inbound server components (SMTP, IMAP, HTTP, WebSocket, TCP) and infrastructure networking (FRP reverse proxy, container networking via slirp4netns, Unix domain sockets for IPC).

Key Findings

---

2. Network Activity Summary

2.1 Outbound Communications (Client-Initiated)

The application makes outbound network connections for the following purposes:

AI Provider API Calls — Primary function; sends user prompts/tool results, receives AI completions

Token Fetching — OAuth token retrieval via HTTP, SSH, or raw TCP

Usage Telemetry — Posts token usage statistics and session events to scorpiox.net

Web Search — Queries search engines (Mojeek, Brave, DuckDuckGo, Google, Bing, Yahoo, Yandex, Startpage, Ecosia, Qwant, Searx)

Voice Transcription — Sends audio to Whisper API endpoint

Distribution Downloads — Fetches container images, executables, firmware, self-updates

URL Fetching — General-purpose HTTP fetcher for ReadDocs tool

FRP Reverse Proxy — Connects to FRP server for reverse tunneling

Email Relay — Outbound SMTP relay via smarthost

MX Delivery — Direct SMTP delivery to remote mail servers

Git Operations — Clone/push via HTTPS with embedded PAT tokens

2.2 Inbound Communications (Server Components)

The codebase includes several server components that listen for inbound connections:

2.3 Internal Communications (IPC)

---

3. Endpoint Inventory

3.1 AI Provider Endpoints

3.2 ScorpioX Infrastructure Endpoints

3.3 OAuth Token Endpoints

3.4 Web Search Endpoints

3.5 Hardcoded Internal IPs

---

4. Protocol Analysis

4.1 HTTP/HTTPS (libcurl)

Implementation: sx_http.c wraps libcurl for all HTTP requests via sx_http_request().

• Method: GET, POST, PUT, DELETE supported
• Timeouts: Configurable, defaults to 600 seconds
• Cancel: Supports mid-request cancellation via callback
• Streaming: SSE (Server-Sent Events) streaming for AI provider responses
• Headers: Up to 32 custom headers per request
• CA Bundle: Windows builds use a custom CA bundle path via sx_get_ca_bundle_path()

Relay Mode: When HTTP_RELAY=1, all HTTP requests are serialized over a custom SXH1 binary protocol via plain TCP to relay.scorpiox.net:9801, eliminating curl/TLS dependencies on the client side. The relay server performs the actual HTTPS request.

4.2 Raw TCP

Token Fetching (scorpiox-claudecode-fetchtoken.c, scorpiox-codex-fetchtoken.c, scorpiox-gemini-fetchtoken.c):

• Connects to TCP_HOST:TCP_PORT (default: proxy.scorpiox.net:9800 / 20.53.240.54:9800)
• No TLS — raw plaintext TCP
• Server sends JSON containing OAuth access tokens on connect, then closes
• Tokens include access_token and expires_at fields
• ⚠️ CRITICAL: OAuth bearer tokens transmitted in cleartext

HTTP Relay (sx_http_relay.c):

• Custom binary protocol SXH1/SXR1 over plain TCP
• Serializes full HTTP requests (method, URL, headers, body)
• Returns HTTP status code + response body
• Default: 127.0.0.1:9801 or configurable

4.3 SMTP/IMAP (Email Server)

Inbound SMTP (sxmail_smtp.c):

• Listens on ports 25 (MTA) and 587 (submission)
• Supports STARTTLS upgrade via mbedTLS
• AUTH PLAIN (base64-encoded credentials)
• DKIM signing for outbound messages

Inbound IMAP (sxmail_imap.c):

• Listens on port 993 (implicit TLS)
• Full IMAP4rev1 implementation

Outbound SMTP (sxmail_queue.c):

• MX lookup via getaddrinfo() + res_query() (DNS)
• Direct delivery to port 25 of MX host
• Smarthost relay with optional STARTTLS (mbedTLS)
• AUTH PLAIN over TLS for relay authentication

4.4 FRP Reverse Proxy (sx_frp.c)

• Implements FRP (Fast Reverse Proxy) wire protocol
• TCP → yamux multiplexing → FRP messages (JSON payloads)
• AES-128-CFB encryption on control stream
• Auth: MD5(token + timestamp) → hex string
• TLS with mbedTLS for FRP server connections (VERIFY_NONE ⚠️)
• Heartbeat ping/pong every 30 seconds

4.5 WebSocket (ws2tcp.c)

• WebSocket-to-TCP bridge for VNC (noVNC)
• Listens on port 6080
• Upgrades HTTP connections to WebSocket
• Proxies bidirectionally between WebSocket and TCP backend
• Token-based routing to different backends

4.6 Unix Domain Sockets (sxmux_session.c)

• Terminal multiplexer IPC
• AF_UNIX / SOCK_STREAM
• Socket files in /tmp/ or runtime dir
• Binary protocol with message types (create, attach, resize, sendkeys, output, etc.)

4.7 Container Networking (scorpiox-unshare.c)

• Uses CLONE_NEWNET for network namespace isolation
• slirp4netns for userspace networking (TAP device)
• Port forwarding via slirp4netns API socket (AF_UNIX)
• DNS via slirp at 10.0.2.3 or host resolv.conf copy
• Auto-port allocation for port+:target syntax

---

5. Telemetry Assessment

Rating: MODERATE — Two opt-in telemetry systems exist

5.1 Usage Tracking (scorpiox-usage.c)

• Default State: Disabled (USAGE_TRACKING=0 in both sx_config.c and sx_config_embedded.c)
• Endpoint: https://code.scorpiox.net/usage-send
• Trigger: Called fire-and-forget from agent loop after each API response
• Data Sent:

- Session ID

- Provider name (claude, gemini, openai)

- Model name

- Token counts (input, output, cache_read, cache_write)

- Service tier

- Project name (basename of cwd)

- Git branch (auto-detected)

- Machine metadata: hostname, username, OS, arch, OS version, scorpiox version

5.2 Session Event Tracking (scorpiox-emit-session.c)

• Default State: Disabled (EMIT_SESSION_TRACKING=0)
• Endpoint: https://code.scorpiox.net/sessions-send
• Data Sent:

- Session ID + sequence number

- Message type (user, assistant, tool_call, tool_result, error, thinking, system_prompt)

- Full message text (up to 1MB from file)

- Provider and model name

- Project name, git branch

- Machine metadata: hostname, username, OS, arch

5.3 Cache Keep-Alive (sx_cache_keepalive.c)

• Not telemetry but generates automatic network traffic
• Sends "keepalive, respond ok" to the AI provider when idle for ~4:30
• Purpose: Keep Claude's prompt cache warm
• Default: Disabled in native (CACHE_KEEPALIVE=0), enabled in WASM config

5.4 Traffic Logging

• All AI provider requests/responses logged to .scorpiox/traffics/ directories
• Includes raw HTTP, parsed messages, and usage JSON
• Local-only — not transmitted unless session tracking is enabled

---

6. TLS/SSL Security Analysis

6.1 Certificate Verification Disabled — 🔴 CRITICAL

Certificate verification is explicitly disabled in 8 locations:

Impact: All token fetch/refresh operations and email TLS are vulnerable to man-in-the-middle attacks. An attacker on the network path could intercept OAuth tokens, API keys, and email credentials.

6.2 TLS Version

• sxmail_tls.c: Enforces minimum TLS 1.2 (MBEDTLS_SSL_VERSION_TLS1_2) — ✅ Good
• sxmail_queue.c: Uses MBEDTLS_SSL_PRESET_DEFAULT — No explicit minimum set
• sx_frp.c: Uses MBEDTLS_SSL_PRESET_DEFAULT — No explicit minimum set
• Main HTTP via libcurl: Uses libcurl defaults (system-dependent, typically TLS 1.2+)

6.3 CA Bundle

• Windows builds use a custom CA bundle path (sx_get_ca_bundle_path())
• Linux/macOS rely on system CA store
• No certificate pinning anywhere

6.4 Podman Registry

• TMUX_PODMAN_TLS_VERIFY=false in embedded config — disables registry TLS verification

---

7. Data Flow Diagrams

7.1 AI Provider Request Flow

User Input
    │
    ▼
sx.c (main loop)
    │
    ├──► sx_provider_*.c  (build JSON request)
    │         │
    │         ▼
    │    sx_http.c / sx_http_relay.c
    │         │
    │         ├──[HTTP_RELAY=0]──► libcurl ──► HTTPS ──► api.anthropic.com
    │         │                                          api.openai.com
    │         │                                          generativelanguage.googleapis.com
    │         │
    │         └──[HTTP_RELAY=1]──► TCP:9801 ──► relay.scorpiox.net ──► target API
    │
    ├──► scorpiox-usage (fire-and-forget)
    │         │
    │         └──► HTTPS POST ──► code.scorpiox.net/usage-send
    │
    └──► scorpiox-emit-session (fire-and-forget, if enabled)
              │
              └──► HTTPS POST ──► code.scorpiox.net/sessions-send

7.2 Token Acquisition Flow

Provider init (needs OAuth token)
    │
    ├──[TOKEN_MODE_LOCAL]──► Read ~/.claude/.credentials.json
    │
    ├──[TOKEN_MODE_REMOTE]──► HTTP GET ──► token.scorpiox.net/claude
    │                                       token.scorpiox.net/codex
    │                                       token.scorpiox.net/gemini
    │
    ├──[TOKEN_MODE_SSH]──► SSH ──► remote_host ──► cat ~/.claude/.credentials.json
    │   (uses scorpiox-sshpass with hardcoded password "xboxone")
    │
    └──[TOKEN_MODE_TCP]──► Raw TCP ──► proxy.scorpiox.net:9800
                            (20.53.240.54:9800)
                            ⚠️ PLAINTEXT — tokens in cleartext

7.3 Email Data Flow

Inbound:
    Remote MTA ──► TCP:25 ──► sxmail_smtp.c (EHLO/AUTH/STARTTLS)
                                │
    Remote MUA ──► TCP:587 ──► sxmail_smtp.c (submission, AUTH required)
                                │
                                ▼
                         sxmail_queue.c (local store)
                                │
    Remote MUA ──► TCP:993 ──► sxmail_imap.c (TLS, FETCH/SELECT/SEARCH)

Outbound:
    sxmail_queue.c ──► MX lookup (getaddrinfo) ──► TCP:25 ──► Remote MX
                   └──► Smarthost relay (TLS) ──► TCP:465/587 ──► Relay host

---

8. Hardcoded Credentials — 🔴 CRITICAL

The following credentials are embedded in source code (primarily in sx_config_embedded.c for WASM builds):

---

9. DNS Resolution Analysis

9.1 DNS Calls

9.2 Domains Resolved at Runtime

All domains in the endpoint inventory (Section 3) are resolved via standard system DNS. No custom DNS resolver is used. No DNS-over-HTTPS or DNS-over-TLS.

DNS audit logging is configurable (DNS_AUDIT_LOG=0/1, DNS_AUDIT_LOG_DIR=/var/log/scorpiox-dns) but disabled by default.

---

10. Data Exfiltration Pattern Analysis

10.1 Base64 + Network Send

Base64 encoding is used in the following network contexts:

10.2 File Read + Network Send

10.3 Assessment

No unintentional data exfiltration patterns detected. All file-read-to-network patterns serve legitimate application purposes. However, the session tracking feature (EMIT_SESSION_TRACKING=1) would transmit complete conversation transcripts including tool outputs, file contents, and command results to code.scorpiox.net.

---

11. Risk Assessment

11.1 Risk Matrix

11.2 Recommendations

CRITICAL: Enable TLS certificate verification — Replace all CURLOPT_SSL_VERIFYPEER=0 and MBEDTLS_SSL_VERIFY_NONE with proper verification. Use system CA store or bundled CA certificates.

CRITICAL: Remove hardcoded credentials — Move all API keys, passwords, and tokens to environment variables or a secrets manager. Never embed in source code.

HIGH: Encrypt token transport — Add TLS to the raw TCP token fetch protocol (port 9800). Use the existing mbedTLS integration.

MEDIUM: Add certificate pinning — Pin certificates for critical endpoints (api.anthropic.com, api.openai.com, code.scorpiox.net).

MEDIUM: Audit session tracking — Document what data is collected when EMIT_SESSION_TRACKING=1. Consider excluding tool output content.

MEDIUM: Set minimum TLS versions — Explicitly set mbedtls_ssl_conf_min_tls_version(TLS1_2) on all mbedTLS connections, not just sxmail_tls.c.

LOW: Implement DNSSEC validation — For MX lookups and critical hostname resolution.

---

12. Appendix: Source Files with Network Activity

---

End of Network Audit Report