Skill

local-api

skill:smol-machines/smolvm#local-api

Drives smolvm programmatically over its local HTTP API (smolvm serve) instead of the CLI: create machines, exec and stream commands, move files in and out, and tear them down. Use when building a client, harness, agent tool or MCP backend over smolvm; when a create call is accepted but the machine behaves as if a field was ignored; when a file uploaded over the API has disappeared; when an exec that failed still returned HTTP 200; or when choosing between the Unix socket and loopback TCP. Do not use it as a substitute for the CLI in a shell script, and do not bind a plain listener beyond loopback: a server started without mutual TLS has no authentication of any kind.

SkillsMP

Verdict

Suspicious

Risky behavior the analysis could not rule out.

Analyzed Oct 27, 2026, 23:07 UTC at cd55588

findings

critical

highest severity

threat classes

683

files scanned

343/372

checks satisfied

package advisories

Why this verdict

suspicious: finding skill:docs/local-api:crates/smolvm-agent/src/main.rs:572:CRED
suspicious: finding skill:docs/local-api:crates/smolvm-agent/src/main.rs:6876:EXFIL
suspicious: finding skill:docs/local-api:crates/smolvm-agent/src/main.rs:7386:CRED
suspicious: finding skill:docs/local-api:docs/local-api/scripts/cleanup.sh:161:DESTRUCT

Security findings 4

Data exfiltration

criticalContextual riskmedium confidence

The smolvm guest agent ships a TCP connectivity diagnostic that opens a raw socket to the public address 1.1.1.1:80 and sends an HTTP GET (with wget/nc/crane/curl fallbacks), an outbound network contact not declared by the skill, though the payload is a generic probe rather than workspace data.

crates/smolvm-agent/src/main.rs:6876

(e.g.,

vector:code

Counter-argument considered

The strongest case against the finding is that the payload is a constant probe and no machine data leaves the host, but the claim already concedes exactly that and rests on the outbound contact itself: the executed guest agent hardcodes 1.1.1.1 (TcpStream, nc to '1.1.1.1 80', curl to http://1.1.1.1), the skill's declared claims never declare this external endpoint, and no carve-out or mitigation covers an undeclared hardcoded external contact in shipped code, so the finding stands as a contextual risk.

Credential access

highContextual risklow confidence

The smolvm guest agent shipped with this skill's repository starts an SSH-agent forwarding bridge that puts the host's SSH agent socket in reach of every guest child process when the host enables it — a credential-adjacent capability that the local-api skill's declared purpose (machine lifecycle, exec, and file transfer over the local HTTP API) does not mention, and it is undeclared in the evidence shown here (unexplained, plausibly an honest opt-in product feature).

crates/smolvm-agent/src/main.rs:572-577

Start SSH agent forwarding bridge if enabled by host

vector:code

Counter-argument considered

The shown boot-path code confirms the agent starts an SSH-agent forwarding bridge whenever the host enables it and exports the agent socket to every guest child process; no shown declared claim (D3/D41) or the skill description covers this credential-adjacent capability, and no carve-out or mitigation neutralizes it, so the contextual CRED finding stands.

Credential access

highContextual risklow confidence

The smolvm agent injects SSH_AUTH_SOCK into the environment of commands executed in guests via ssh_agent::inject_into_env, exposing a forwarded SSH agent (a host credential-signing surface) to workload processes when forwarding is enabled — a credential path not mentioned in the skill's declared machine-lifecycle description.

crates/smolvm-agent/src/main.rs:7386-7391

SSH agent forwarding: make SSH_AUTH_SOCK part of the command env so it

vector:code

Counter-argument considered

The shown code copies the command env, calls ssh_agent::inject_into_env, and passes that env to storage::run_command, so a forwarded host SSH agent does reach guest workload processes in the exec path the skill drives; the opt-in gating ('No-op when forwarding is off') and the absence of any declared claim about SSH forwarding bound severity but do not make the credential-path claim wrong.

Destructive action

highContextual riskmedium confidence

cleanup.sh's opt-in --reap mode runs kill -9 on every smolvm VM process found under the user's HOME (via /proc and ps scans), including machines created by other packets or sessions that this script never recorded.

docs/local-api/scripts/cleanup.sh:161-170

With --reap every one is killed, including a machine another packet kept.

trigger:conditionalvector:code

Counter-argument considered

The claim matches the script verbatim: with --reap the loop SIGKILLs every pid fed from list_vm_processes, and the script itself states the blast radius; the mode is opt-in, scoped to the user's HOME and openly declared ('kill every VM process under this HOME; run without it first'), which lowers severity but does not make the destructive-behavior finding wrong.

Open questions 11

What the analysis could not settle from the code alone.

[file request crates/smolvm-agent/src/credentials.rs] The agent declares a credentials module: what credentials does it read or store (e.g. registry auth), and does any credential value leave the guest or reach a network destination beyond the registry being pulled from?

Credential access

[file request crates/smolvm-agent/src/ssh_agent.rs] How does the SSH agent forwarding bridge obtain the host's agent connection over vsock, where is the forwarded socket exposed in the guest, and is access to it restricted to any workload or user?

Credential access

[file request crates/smolvm-agent/src/publish_socket.rs] Which Unix sockets do the --expose-socket / --mount-socket bridges connect, in which direction (host to guest or guest to host), and is bridged access restricted or logged?

Credential access

[file request crates/smolvm-agent/src/credentials.rs] What does credentials::inject_into_container inject into the workload container's OCI spec, and from where do those credentials originate?

Credential access

[file request crates/smolvm-agent/src/ssh_agent.rs] What do ssh_agent::inject_into_env and ssh_agent::inject_into_container forward into exec/run environments and container specs, and from which host socket or path?

Credential access

[file request crates/smolvm-agent/src/credentials.rs] What does credentials::inject_into_container read (files, env, mounts) and copy or mount into the container OCI spec, and is any credential forwarding declared by the artifact?

Credential access

[file request docs/local-api/scripts/preflight.sh] What does preflight.sh actually execute — does it download or run remote code, read credentials or secret-bearing environment variables, or write outside the workspace, beyond reporting auth=none_unless_mtls?

Code execution

[file request crates/smolvm-agent/src/main.rs] The served block starts mid-function at the raw-socket test and its result JSON keys include 'rust_std_net': connect_result; where does the TCP-connect target for that first test come from (host-supplied nettest request URL versus a hardcoded 1.1.1.1 default), what triggers this nettest handler, and do the earlier tests (wget/crane or others) send anything beyond a bare probe request?

Reconnaissance

[file request crates/smolvm-agent/src/ssh_agent.rs] Does ssh_agent::inject_into_env inject SSH_AUTH_SOCK only when the operator explicitly enabled agent forwarding, and what socket path does the injected variable point to?

Credential access

[file request crates/smolvm-agent/src/main.rs] Which request handler dispatches to the network connectivity test (test_tcp_syscall and the nc/curl probes to 1.1.1.1), is it gated behind an explicit diagnostic request, and is it exposed through the documented local HTTP API surface?

Data exfiltration

[file request crates/smolvm-agent/src/ssh_agent.rs] Does ssh_agent::inject_into_env only inject SSH_AUTH_SOCK when the operator explicitly enabled agent forwarding, and what socket path does the injected variable point to?

Credential access

Refuted findings 2

Candidates the review stage examined and rejected, kept for transparency.

Code execution

criticalRefutedlow confidence

The skill's procedure instructs the agent to execute bundled shell scripts as prerequisite/setup steps (scripts/preflight.sh, scripts/serve-start.sh, scripts/lifecycle-check.sh, scripts/cleanup.sh --purge) whose contents are not present in the reviewed evidence, so what runs on the host cannot be verified from this artifact view.

docs/local-api/SKILL.md:23-24

scripts/preflight.sh

Why it was refuted

The strongest case against the finding was its unverifiability premise, and the follow-up served the script contents, breaking it: preflight.sh is read-only host checks with no writes, downloads, or binds; serve-start.sh launches smolvm on a default Unix socket under the state dir; lifecycle-check.sh only curls the local API over that socket or loopback — all the declared core capability, with cleanup.sh's behavior (delete recorded machines, stop server, remove socket) declared in the skill text and its benign --record invocation visible in lifecycle-check.sh. The strongest case for the finding (four opaque scripts on the host) is now three verified-benign files plus one whose declared teardown behavior matches the declared 'tear them down' capability, so the harm and undeclared gates fail and the finding dies.

Reconnaissance

mediumRefutedlow confidence

The VM agent's nettest exposes a TCP-connect primitive that connects to a parameter-named host:port and sends a bare HTTP GET (plus hardcoded 1.1.1.1:80 probes via nc and curl), which would let whoever can trigger the nettest probe arbitrary outbound hosts from the VM if the target is host-supplied.

crates/smolvm-agent/src/main.rs:6718-6720

match TcpStream::connect_timeout(&addr, Duration::from_secs(NETWORK_TEST_TIMEOUT_SECS)) {

Why it was refuted

Refuted on harm: the nettest is served over the agent's host-request surface, and its only shown caller — the host controller — already holds unrestricted command execution in the same VM (exec handlers shown), while any in-guest process can equally open outbound TCP natively, so the connect primitive crosses no boundary and grants no capability beyond the declared exec core; the hardcoded 1.1.1.1 curl/nc probes are connectivity canaries to a public resolver, not an attacker-controlled sink, and the cited D3 contradiction is spurious because D3 forbids binding a listener beyond loopback, not outbound connects.