Security audit
Security checks for vulnerabilities and agentic risk
The home-security controls are clearly explained, but unsafe token caching could let a local attacker execute commands or obtain alarm-system access.
Wait for corrected cache handling before connecting a real alarm account. The fix should use private, verified storage, secure file replacement, and strictly numeric expiry validation. Review the separately supplied login script, retain confirmation for alarm and lock changes, and display PINs only when explicitly requested. No live account behavior was tested.
references/ss-helpers.shAttacker-precreated shared token cache enables Bash arithmetic injection
Arbitrary command execution with the victim's privileges, potentially exposing the SimpliSafe refresh token and enabling unauthorized alarm or lock operations. This exceeds a temporary-file robustness issue because attacker-controlled file content reaches shell execution.
Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.
`ss_api <METHOD> <PATH> [JSON_BODY]` attaches auth, prints the body on stdout,
and on a non-2xx prints to **stderr** and returns 1 — so a failure never looks
like an empty result. Access tokens are cached in `$TMPDIR` (0600) and re-minted
only when stale; the helpers never write to the repo's `.env`.
## Resolve first
The cache described here uses a predictable filename under TMPDIR, falling back to shared /tmp, without verifying file ownership or rejecting symlinks. An attacker able to pre-create that path can arrange for the bearer token to be written into an attacker-readable file, because umask does not change existing file permissions; a stolen token can control the alarm and locks.
# not rotate refresh tokens, so there is nothing to write back, and the MCP
# server's own state is never touched.
#
# The minted access token is cached in this skill's OWN state file under
# TMPDIR (mode 0600), never in the repo's .env.
SS_CLIENT_ID='42aBZ5lYrVW12jfOuu3CQROitwxg9sN5'
The referenced token function reads an existing predictable cache without checking ownership or permissions and later writes it using ordinary shell redirection. This is the same cache vulnerability identified at line 17: an attacker-precreated writable file can retain permissive access despite umask 077, exposing credentials for a physical security system.
return 1
}
# Print a valid access token, minting one only when the cache is cold or stale.
# SimpliSafe access tokens last 3600s; refresh 120s early to avoid a race.
ss_access_token() {
local now
Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.
}
# Print a valid access token, minting one only when the cache is cold or stale.
# SimpliSafe access tokens last 3600s; refresh 120s early to avoid a race.
ss_access_token() {
local now
now=$(date +%s)
Without declared permissions the skill's intent is opaque and cannot be validated.
Data is being sent to an external URL. This could be legitimate telemetry or data exfiltration. Manual review is recommended.
SS_CLIENT_ID='42aBZ5lYrVW12jfOuu3CQROitwxg9sN5'
SS_AUTH_URL='https://auth.simplisafe.com/oauth/token'
SS_API_BASE='https://api.simplisafe.com/v1'
SS_TOKEN_CACHE="${TMPDIR:-/tmp}/simplisafe-skill-token.json"
# Resolve the refresh token. Prints it, or fails with an actionable message.
Data is being sent to an external URL. This could be legitimate telemetry or data exfiltration. Manual review is recommended.
body=$(jq -nc --arg cid "$SS_CLIENT_ID" --arg rt "$rt" \
'{grant_type:"refresh_token", client_id:$cid, refresh_token:$rt}')
response=$(curl -sS -X POST "$SS_AUTH_URL" -H 'Content-Type: application/json' -d "$body") || return 1
access=$(printf '%s' "$response" | jq -r '.access_token // ""')
if [ -z "$access" ]; then