Security audit

Sqlformat

Security checks for vulnerabilities and agentic risk

Overview

This skill claims to format and lint SQL, but its artifacts mainly record SQL inputs into persistent plaintext local logs and exports.

Review carefully before installing. Do not use this with production SQL, secrets, customer data, or proprietary schema details unless you are comfortable with that content being saved locally in plaintext and later exported. A safer version should implement real SQL formatting/linting and make any history logging explicit, optional, permission-hardened, redacted, and deletable.

A.I.G

Vulnerability Patterns

Insecure Skill Coding PracticesFinds exploitable flaws such as hardcoded secrets or command injection
Skill Instruction HijackingAlters the agent's session goals or safety constraints when the skill loads
Agent Memory PoisoningWrites attacker-controlled rules into memory that affect later sessions
Remote Payload Retrieval and ExecutionFetches external code whose behavior can change after review
Embedded Malicious CodeShips malicious scripts inside the skill and executes them locally

Findings (3)

T09 · Insecure Skill Coding Practices

Warning

Location: scripts/script.sh:5
Finding: Potentially Sensitive SQL Is Persisted Without Enforced Access Controls
Content: View full analysis
> "$DATA_DIR/history.log"; } ``` Core commands subsequently persist the complete input in both a command-specific log and the unified history log. For example: ```bash check) shift if [ $# -eq 0 ]; then echo "Recent check entries:" tail -20 "$DATA_DIR/check.log" 2>/dev/null || echo " No entries yet. Use: sqlformat check " else local input="$*" local ts=$(date '+%Y-%m-%d %H:%M') echo "$ts|$input" >> "$DATA_DIR/check.log" local total=$(wc -l < "$DATA_DIR/check.log") echo " [Sqlformat] check: $input" echo " Saved. Total check entries: $total" _log "check" "$input" fi ;; ``` The same storage pattern is repeated for the other core commands through line 286. ### Technical Analysis The script stores complete SQL input in plaintext under the user's home directory. It does not set a restrictive `umask`, explicitly create the data directory with mode `0700`, or explicitly create log files with mode `0600`. The effective permissions therefore depend on the caller's current umask and any pre-existing directory or file permissions. Under a permissive environment, the resulting files may be readable by other local users or processes. SQL text can contain sensitive information, including: - Database names and schema details - Customer or operational data embedded in statements - Authentication tokens or passwords embedded in connection or migration queries - Proprietary business logic - Internal table and column names Each input is duplicated: once in the command-specific log and again in `history.log`. ...[truncated 1172 chars]
Remediation: View remediation

T09 · Insecure Skill Coding Practices

Warning

Location: scripts/script.sh:54
Finding: Unescaped User Input Produces Unsafe JSON and CSV Exports
Content: View full analysis
"$out" local first=1 for f in "$DATA_DIR"/*.log; do [ -f "$f" ] || continue local name=$(basename "$f" .log) while IFS='|' read -r ts val; do [ $first -eq 1 ] && first=0 || echo "," >> "$out" printf ' {"type":"%s","time":"%s","value":"%s"}' "$name" "$ts" "$val" >> "$out" done < "$f" done echo "\n]" >> "$out" ;; csv) echo "type,time,value" > "$out" for f in "$DATA_DIR"/*.log; do [ -f "$f" ] || continue local name=$(basename "$f" .log) while IFS='|' read -r ts val; do echo "$name,$ts,$val" >> "$out"; done < "$f" done ;; ``` ### Technical Analysis The export function places user-controlled log content directly into JSON string literals and CSV fields without format-appropriate encoding. For JSON, characters such as double quotes, backslashes, control characters, and embedded newlines are not escaped. A crafted value can terminate the intended string, inject additional JSON structure, or make the export syntactically invalid. For CSV, values containing commas, double quotes, or newlines are not quoted according to CSV rules. In addition, values beginning with spreadsheet formula prefixes such as `=`, `+`, `-`, or `@` may be interpreted as formulas when the export is opened in spreadsheet software. This is an output-injection issue rather than shell-command injection. The shell correctly quotes the variables during writing, but the destination data formats ...[truncated 1392 chars]
Remediation: View remediation

T09 · Insecure Skill Coding Practices

Note

Location: scripts/script.sh:103
Finding: Search Terms Beginning With Hyphens Are Interpreted as grep Options
Content: View full analysis
}" echo "Searching for: $term" for f in "$DATA_DIR"/*.log; do [ -f "$f" ] || continue local m=$(grep -i "$term" "$f" 2>/dev/null || true) if [ -n "$m" ]; then echo " --- $(basename "$f" .log) ---" echo "$m" | sed 's/^/ /' fi done } ``` ### Technical Analysis Although `"$term"` is shell-quoted, quoting does not prevent a value beginning with `-` from being parsed as an option by `grep`. The command does not use the conventional `--` end-of-options delimiter. Consequently, an attacker-controlled term can alter `grep` behavior rather than being treated solely as a search pattern. Depending on the installed `grep` implementation and accepted options, this may change matching behavior, request expensive processing, or cause failures. No direct shell-command execution is present because the value is not evaluated by the shell and remains a single argument. ### Attack Path 1. An attacker controls or influences the term passed to `sqlformat search`. 2. The term begins with a hyphen and resembles one or more supported `grep` options. 3. The script executes `grep -i "$term" "$f"` without an end-of-options delimiter. 4. `grep` interprets the term as an option instead of the intended pattern. 5. Search behavior is modified, output becomes unreliable, or resource consumption increases according to the injected option. ### Impact Assessment The confirmed impact is limited to the search operation and the privileges of the invoking user. It may cause incorrect search results, command errors, or localized resource consumption. The reviewed code does not establish a path from this issue to arbitrary shell command execution, privilege escalation, persistenc ...[truncated 28 chars]
Remediation: View remediation

SkillSpector

Vulnerability Patterns

Data ExfiltrationExternal Transmission, Env Variable Harvesting, File System Enumeration
Excessive AgencyUnrestricted Tool Access, Autonomous Decision Making, Scope Creep
MCP Tool PoisoningHidden Instructions, Unicode Deception, Parameter Description Injection
Prompt InjectionInstruction Override, Hidden Instructions, Exfiltration Commands
Privilege EscalationExcessive Permissions, Sudo/Root Execution, Credential Access

Findings (9)

Tp4

High

Category: MCP Tool Poisoning
Confidence: 99% confidence
Finding: The skill presents itself as a SQL formatting and linting tool, but the documentation makes clear that its primary behavior is persistent storage of all user inputs and activity in local plain-text logs. This mismatch is dangerous because users may submit sensitive SQL queries, schema details, credentials embedded in connection strings, or business data under the assumption they are being processed transiently, when in fact they are retained and searchable.
Content: No source excerpt is available for this finding.

Description-Behavior Mismatch

High

Category: Not specified by scanner
Confidence: 98% confidence
Finding: The manifest and introductory text describe a SQL formatter/linter, but the documented behavior is that arbitrary inputs are stored as records in local logs. This creates a security and privacy risk because operators may feed confidential SQL, customer data, or internal query logic into the tool without realizing it functions as a persistent data collection utility.
Content: No source excerpt is available for this finding.

Intent-Code Divergence

High

Category: Not specified by scanner
Confidence: 99% confidence
Finding: The command table claims operations such as check, validate, format, lint, explain, and convert, but nearby text states these commands merely record timestamped entries or show recent entries. Misleading command semantics can cause users to rely on nonexistent validation or transformation while unintentionally depositing sensitive SQL into logs, increasing both operational and confidentiality risk.
Content: No source excerpt is available for this finding.

Description-Behavior Mismatch

High

Category: Not specified by scanner
Confidence: 98% confidence
Finding: The skill advertises SQL formatting, linting, and conversion, but the implementation does none of that and instead builds a persistent input-collection utility. This deceptive mismatch is dangerous because users may paste sensitive SQL, credentials, schema details, or production queries into a tool they reasonably believe is a harmless formatter, resulting in silent retention of data.
Content: No source excerpt is available for this finding.

Intent-Code Divergence

High

Category: Not specified by scanner
Confidence: 98% confidence
Finding: The help text markets numerous SQL-processing commands, but the handlers merely append raw input to log files. This is deceptive behavior that makes the skill context more dangerous: users are primed to submit sensitive SQL content under false assumptions, enabling covert collection rather than the promised processing.
Content: No source excerpt is available for this finding.

Missing User Warnings

Medium

Category: Not specified by scanner
Confidence: 95% confidence
Finding: The skill description does not prominently warn that SQL inputs and activity are stored persistently in plain-text files. Because SQL often contains sensitive table names, literals, business logic, or even accidental secrets, silent retention materially increases exposure through local compromise, backups, shoulder surfing, or later export/search operations.
Content: No source excerpt is available for this finding.

Context-Inappropriate Capability

Medium

Category: Not specified by scanner
Confidence: 95% confidence
Finding: The script creates a local data store and includes logging, search, export, recent activity, and reporting features that are unrelated to a normal SQL formatter/linter. In this skill context, those capabilities expand data collection and retrieval of potentially sensitive SQL inputs, increasing exposure far beyond what users would expect from the advertised functionality.
Content: No source excerpt is available for this finding.

Missing User Warnings

Medium

Category: Not specified by scanner
Confidence: 91% confidence
Finding: The export feature aggregates previously logged content into additional files without clearly warning that the output may contain accumulated sensitive SQL inputs. This increases the blast radius of prior data collection by making stored material easier to package, copy, and disclose.
Content: No source excerpt is available for this finding.

Missing User Warnings

Medium

Category: Not specified by scanner
Confidence: 95% confidence
Finding: User input is written verbatim to persistent log files in the user’s home directory with no consent, warning, sanitization, or retention policy. Because SQL inputs often contain secrets, table names, internal schema, or live query text, this can create unintended local disclosure and later exfiltration risk from backups, shared systems, or subsequent export commands.
Content: No source excerpt is available for this finding.

Static analysis

No suspicious patterns detected.