SD-017 — settings.json Bash Wildcard Grant

SD-017 flags a settings.json permission entry granting the shell tool with a wildcard — a bare Bash grant, Bash(*), or a wildcard over curl, wget, sh, bash, zsh or eval.

What it matches

A settings.json allow entry granting the shell tool outright, as Bash or Bash(*), or with a wildcard over curl, wget, sh, bash, zsh or eval.

Why it matters

A wildcard over one of those heads is not one capability, it is every command reachable through it: a wildcard on curl allows any URL and any flag, including writing a file the agent then runs, and a wildcard on sh allows any script at all. The agent runs them with no prompt, so the approval step the permission system exists to provide never happens. Because the entry is committed, it applies to everyone who checks the repository out, not only to whoever wrote it.

Example

json

{"permissions": {
  "allow": ["Bash(curl:*)", "Bash(sh:*)"]
}}

Each entry grants every invocation of that command, unprompted.

How to fix it

Grant the exact subcommands the work needs and leave the rest to the prompt. Where a command genuinely needs a wide argument space, wrap it in a script the repository commits and grant that one script, so what the agent may run is reviewable in the diff rather than implied by a wildcard.

Known false positives

A wildcard grant that the repository owner intends. The finding still says what was granted.

Standards mapping

OWASP ASI ASI03

CWE CWE-732

Agent Skills in the Wild PE1

Prevalence

highpermission_hygiene

Pattern SD-017 was detected in 0 of 16475 public skills scanned as of 11 September 2026.

current ruleset 2414c32f04000b5d

Check your own skills

Scan a repository or a single skill against this rule and the rest of the catalogue, free.