T09 · Insecure Skill Coding Practices
- Location
SKILL.md:28- Finding
Unrestricted Credential-Bearing Network Requests and Unsafe Shell Fallback
- Content
View full analysis
- Remediation
View remediation
Security audit
Security checks for vulnerabilities and agentic risk
This API helper is mostly purpose-aligned, but it under-discloses a shell/curl fallback and can send user-provided credentials to arbitrary endpoints.
Install only if you are comfortable with the agent making outbound API calls on your behalf. Use scoped or test credentials, verify the exact hostname before any authenticated request, avoid production secrets, and do not allow the exec/curl fallback unless you explicitly need it and can review the command safely.
SKILL.md:28Unrestricted Credential-Bearing Network Requests and Unsafe Shell Fallback
The manifest presents the skill as a built-in web_fetch connector, but the body introduces an alternative path using exec/curl. This mismatch can cause the orchestrator or user to approve the skill under a narrower trust model than it actually uses, leading to unintended command execution capability in practice.
The manifest description is very broad and can cause the skill to trigger on a wide range of generic API-related requests. Over-broad activation is risky here because the skill is capable of making outbound authenticated requests and, per the documentation, may escalate to exec/curl fallback, so accidental invocation could lead to unnecessary external data transmission or use of a broader execution path than intended.
Data is being sent to an external URL. This could be legitimate telemetry or data exfiltration. Manual review is recommended.
User provides: API URL + what they want. Agent handles everything.
> User: "Hent brukerinfo fra https://api.example.com/v1/users/123"
>
> Agent runs: `web_fetch https://api.example.com/v1/users/123` (with auth headers if provided)
>
Data is being sent to an external URL. This could be legitimate telemetry or data exfiltration. Manual review is recommended.
User provides: API URL + what they want. Agent handles everything.
> User: "Hent brukerinfo fra https://api.example.com/v1/users/123"
>
> Agent runs: `web_fetch https://api.example.com/v1/users/123` (with auth headers if provided)
>
Introducing exec/curl broadens the skill from a web request helper into one that may invoke a shell, which is a materially more powerful capability than advertised. Even though the example is simple, normalizing exec as a fallback increases the chance of unsafe handling of user-supplied URLs, headers, or tokens and undermines least-privilege expectations.
The skill claims it does not require external tools, yet elsewhere instructs the agent to fall back to shell execution via exec/curl. That discrepancy weakens user expectations and expands the execution surface from constrained web_fetch to general command execution, which can expose secrets in process arguments, bypass tool-level safeguards, or enable command-injection-adjacent misuse if future prompts are interpolated unsafely.
The trigger phrase 'query {url}' is generic enough to match innocuous requests without sufficient context or confirmation. In a skill that can contact arbitrary external endpoints, generic triggers increase the chance of accidental outbound requests, though the impact is lower than direct code execution because the action is still within the stated API-calling domain.
No suspicious patterns detected.