Security audit
Security checks for vulnerabilities and agentic risk
This appears to be a legitimate peer-to-peer agent networking skill, but it needs Review because it installs persistent software and exposes powerful remote command, forwarding, and self-update capabilities.
Install only if you intend to run a persistent peer-to-peer daemon with agent-to-agent networking features. Prefer verified or pinned release installation over the unsigned auto-starting shell installer, keep the API bound to loopback unless you add TLS and strong access controls, protect the durable token and owner keys, and require explicit human approval for remote exec, port forwarding, file transfer, and upgrade/apply actions.
A networking skill that also supports remote execution materially increases the attack surface from communication to code execution on peer systems. In an agent setting, this can let a model move from exchanging messages to triggering commands or workloads on remote hosts, which is a major privilege boundary change.
Tool parameters are crafted to achieve unintended or unsafe behavior. Parameter abuse can bypass intended safety checks (e.g. shell=True, --force, dangerous glob patterns).
x0x sync enroll # POST /sync/devices/enroll {} — owner-key-sign a DeviceEnrollment for THIS machine
x0x sync devices # GET /sync/devices — enrolled devices + last-sync status
x0x sync revoke <machine_id> # DELETE /sync/devices/:machine_id — next stream from it is refused
An authenticated self-update/apply endpoint enables modification of the installed daemon, which is effectively a self-modification mechanism. Even if intended for maintenance, such functionality is dangerous in agent ecosystems because compromise of API credentials or unsafe agent prompting can turn it into arbitrary software replacement and persistence.
| Voice 1:1 (datagram + fallback) | library (`voice` feature) | `--example voice_call` | GA (lib) · 2nd concurrent call refused (typed `SessionConflict` via `start_lane`; `IoError`-wrapped via trait `start()`) |
| Diagnostics (11 areas) | `/diagnostics/*` | `x0x diagnostics <area>` | GA |
| Durable history | `/history*` | `x0x history scopes/list/message/search/stats/purge` | GA (local-only; Tier-2 Home backfill designed, not shipped — [Stores, files, and history](https://github.com/saorsa-labs/x0x/blob/main/docs/skill/stores.md) §4.10, §5.1) |
| Self-update | daemon: `/upgrade(+/apply)` · CLI: read-only check | `x0x upgrade --check`; authenticated `POST /upgrade/apply` to install | GA |
---
The documented install path copies executables into ~/.local/bin, making them persist across sessions and future agent runs. Persistence is not inherently malicious, but in a skill ecosystem it is security-relevant because it establishes durable executable presence and can outlive the original authorization context.
*) printf 'Unsupported platform: %s-%s\n' "$OS" "$ARCH" >&2; exit 1 ;; esac curl -sfL "https://github.com/saorsa-labs/x0x/releases/latest/download/x0x-${PLATFORM}.tar.gz" | tar xz mkdir -p ~/.local/bin cp "x0x-${PLATFORM}/x0xd" "x0x-${PLATFORM}/x0x" ~/.local/bin/ && chmod +x ~/.local/bin/x0xd ~/.local/bin/x0x
The skill instructs downloading and executing a remote shell installer from GitHub, and the text explicitly states that this path does not verify GPG signatures and automatically starts/stops daemons. This creates a classic supply-chain risk: if the script source, transport endpoint, or repository is compromised, arbitrary code executes on the host with persistence side effects.
Option B: shell installer (installs and starts the daemon) — download and review the script before running it. It downloads over HTTPS but does not verify GPG signatures. It stops the selected existing instance and starts the installed daemon automatically; --autostart additionally enables startup on boot. There is no --start opt-in. Run this option only when your human has authorized the install and daemon startup. To install the binaries before starting a daemon, use Option A and follow §1.2 when authorized.
curl -sfLO https://raw.githubusercontent.com/saorsa-labs/x0x/main/scripts/install.sh
less install.sh && sh install.sh
Data is being sent to an external URL. This could be legitimate telemetry or data exfiltration. Manual review is recommended.
curl -X POST "http://$API/subscribe" -H "Authorization: Bearer $TOKEN" -H "Content-Type: application/json" -d '{"topic":"hello-world"}'
curl -X POST "http://$API/publish" -H "Authorization: Bearer $TOKEN" -H "Content-Type: application/json"
-d '{"topic":"hello-world","payload":"'$(echo -n "Hello!" | base64 | tr -d '\n')'"}' # tr -d '\n': BOTH GNU and BSD base64 wrap long output at 76 cols — unwrapped it breaks the JSON
curl -N -H "Authorization: Bearer $TOKEN" "http://$API/events" # SSE; fields nested under "data"
Topics starting `local:` are never gossipped — same-daemon IPC only.
The manifest and top-level description present the skill as secure networking/messaging, but the documented capability matrix also exposes remote execution, file transfer, port forwarding, and authenticated self-update/apply. That is a scope expansion beyond what a user would reasonably infer from the skill metadata, increasing the chance an agent or operator authorizes far more powerful actions than intended.
Self-update and apply-to-install capabilities allow the skill or its managed daemon to modify installed binaries after initial deployment, which exceeds the expected role of a messaging/networking component. In autonomous environments, that creates a supply-chain and integrity risk because an agent may be able to change its own executable base or daemon version.
No suspicious patterns detected.