T09 · Insecure Skill Coding Practices
- Location
scripts/serve.sh:91- Finding
Unconditional Execution of Model-Supplied Remote Code
- Content
View full analysis
- Remediation
View remediation
Security audit
Security checks for vulnerabilities and agentic risk
This benchmarking skill is mostly coherent, but it can run model-supplied code and force-kill broad SGLang processes without enough scoping or warning.
Review this skill carefully before installing, especially on shared GPU hosts. Only use it with trusted model repositories or local model files, because it always enables model remote code execution. Avoid running the bundled stop.sh as-is where unrelated SGLang jobs may exist; require PID-scoped cleanup or manual confirmation before killing processes.
scripts/serve.sh:91Unconditional Execution of Model-Supplied Remote Code
scripts/stop.sh:11Overbroad Force-Termination of Unrelated SGLang Processes
The skill instructs the agent to stop processes and verify GPU cleanup, including killing sglang instances and interacting across host/container boundaries, but that destructive operational behavior is not surfaced in the high-level description. Hidden or under-disclosed process-control behavior is dangerous because users may invoke a 'benchmark' skill without realizing it can terminate active workloads or disrupt shared systems.
The skill instructs the agent to stop processes and verify GPU cleanup, including killing sglang instances and interacting across host/container boundaries, but that destructive operational behavior is not surfaced in the high-level description. Hidden or under-disclosed process-control behavior is dangerous because users may invoke a 'benchmark' skill without realizing it can terminate active workloads or disrupt shared systems.
The skill instructs the agent to stop processes and verify GPU cleanup, including killing sglang instances and interacting across host/container boundaries, but that destructive operational behavior is not surfaced in the high-level description. Hidden or under-disclosed process-control behavior is dangerous because users may invoke a 'benchmark' skill without realizing it can terminate active workloads or disrupt shared systems.
The skill instructs the agent to stop processes and verify GPU cleanup, including killing sglang instances and interacting across host/container boundaries, but that destructive operational behavior is not surfaced in the high-level description. Hidden or under-disclosed process-control behavior is dangerous because users may invoke a 'benchmark' skill without realizing it can terminate active workloads or disrupt shared systems.
The skill instructs the agent to stop processes and verify GPU cleanup, including killing sglang instances and interacting across host/container boundaries, but that destructive operational behavior is not surfaced in the high-level description. Hidden or under-disclosed process-control behavior is dangerous because users may invoke a 'benchmark' skill without realizing it can terminate active workloads or disrupt shared systems.
The skill describes reading and writing files, copying scripts, generating reports, and manipulating workspace artifacts, but it declares no explicit tool scope or permissions boundary. That creates unnecessary capability ambiguity and increases the chance an agent may perform filesystem actions broader than the user expects, especially in a remote/containerized environment.
Skill enables autonomous high-impact decisions without human-in-the-loop verification. Critical operations (destructive commands, financial transactions, data deletion) should require explicit user confirmation.
If the environment looks broken (missing module, version mismatch, ABI error, import crash), **STOP** and report the symptom to the user. Let the user decide whether to reinstall.
What you CAN do without asking:
- Inspect versions: `pip show sglang`, `python -c "import sglang; print(sglang.__file__)"`
- Read source files in the editable install
- Set environment variables for the run
The instruction to probe for an existing server without asking the user authorizes autonomous interaction with local services and process discovery. In shared or sensitive environments, even seemingly harmless health checks and process enumeration can reveal service presence, operational state, ports, and process details that the user did not explicitly approve disclosing or touching.
Check if a sglang server is already running — don't ask the user, just probe:
curl -s http://localhost:30000/health && echo "Server is running" || echo "No server running"
Large whitespace padding was detected (a block of blank lines or a long run of spaces). This can push injected instructions below or to the right of the visible area so a human reviewer never sees them while the agent still reads them. Manual review of the hidden content is recommended.
`--tp-size` in sglang is the **world size** (total GPUs), NOT tensor parallelism degree. The script derives it from the first number in CONFIG (e.g., `DP4EP4` → `--tp-size 4`).
| CONFIG | sglang flags generated | Why |
| ------------ | ------------------------------------------------------------------------------------------------------ | ---------------------------------------------------------------------------- |
| `TP8` | `--tp-size 8` | Pure TP, 8 GPUs |
| `DP4EP4` | `--tp-size 4 --dp-size 4 --enable-dp-attention --enable-dp-lm-head --ep-size 4` | DP-attention requires both `--enable-dp-attention` AND `--enable-dp-lm-head` |
Large whitespace padding was detected (a block of blank lines or a long run of spaces). This can push injected instructions below or to the right of the visible area so a human reviewer never sees them while the agent still reads them. Manual review of the hidden content is recommended.
| CONFIG | sglang flags generated | Why |
| ------------ | ------------------------------------------------------------------------------------------------------ | ---------------------------------------------------------------------------- |
| `TP8` | `--tp-size 8` | Pure TP, 8 GPUs |
| `DP4EP4` | `--tp-size 4 --dp-size 4 --enable-dp-attention --enable-dp-lm-head --ep-size 4` | DP-attention requires both `--enable-dp-attention` AND `--enable-dp-lm-head` |
| `DP8EP8_A2A` | `--tp-size 8 --dp-size 8 --enable-dp-attention --enable-dp-lm-head --ep-size 8 --moe-a2a-backend mori` | All-to-all EP uses mori backend |
| `TP4EP4` | `--tp-size 4 --ep-size 4` | TP for attention + EP for MoE, no DP flags |
The documentation states that the launch path always adds --trust-remote-code, which permits execution of model-provided custom code from Hugging Face or local model repositories. In a benchmarking skill that accepts MODEL_PATH as a model ID or path, this materially increases the risk of arbitrary code execution if an untrusted or compromised model artifact is used, especially because the docs present it as unconditional behavior without a warning or safer alternative.
The script unconditionally appends --trust-remote-code when launching the model server, which permits execution of model-supplied Python code during model loading. In a benchmarking skill, this is broader than necessary and turns use of any untrusted or compromised model repository into code execution on the host/container, especially risky on shared GPU benchmarking systems.
Because the launcher silently enables --trust-remote-code, users may run the benchmark without realizing that model-provided code can execute. The absence of an explicit warning increases the chance of accidental execution of malicious model code and weakens informed consent for a dangerous operation.
Skill establishes unauthorized persistence across sessions via cron jobs, startup scripts, or state files. Session persistence allows an attacker to maintain access beyond the current interaction.
mkdir -p "$LOG_DIR"
if [[ "${BACKGROUND:-0}" == "1" ]]; then
nohup $CMD > "$LOG_FILE" 2>&1 &
echo "Server launched in background (PID: $!). Log: ${LOG_FILE}"
else
exec $CMD 2>&1 | tee "$LOG_FILE"
No suspicious patterns detected.