Back to skill

Security audit

Bill Tracker

Security checks for vulnerabilities and agentic risk

Overview

This skill is a straightforward Bill Tracker API helper, but it handles sensitive financial data and a long-lived session token that users should protect carefully.

Install only if you trust the Bill Tracker server configured in BILL_TRACKER_URL. Use HTTPS for any remote server, reserve http://localhost only for local development, keep BILL_TRACKER_SESSION_TOKEN out of logs and shared shell history, and rotate or revoke the token if it may have been exposed.

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 (1)

T09 · Insecure Skill Coding Practices

Warning
Location
SKILL.md:11
Finding

Long-Lived Financial Session Token Can Be Transmitted Without Enforced TLS

Content
View full analysis

Vulnerability Details

File Location: SKILL.md, lines 11–12; related authentication instructions at lines 35–37 and 73–92
Vulnerability Type: Sensitive token exposure through insecure transport configuration
Risk Level: Medium

markdown
- `BILL_TRACKER_URL` - Base URL (e.g. https://your-server.com or http://localhost:1337)
- `BILL_TRACKER_SESSION_TOKEN` - Session token for authentication (obtained once via POST /api/mcp/token)

The related instructions state:

markdown
Store the returned `sessionToken` in `BILL_TRACKER_SESSION_TOKEN`. Tokens are long-lived; no need to re-verify on every request. (Codes expire in 10 minutes.)

Authentication examples transmit this token in an HTTP header:

bash
curl -s -X POST -H "X-Parse-Session-Token: $BILL_TRACKER_SESSION_TOKEN" -H "Content-Type: application/json" \
  -d '{"days": 3}' \
  "${BILL_TRACKER_URL}/api/mcp/upcoming-transactions"

Technical Analysis

BILL_TRACKER_URL is configurable, and the documentation explicitly permits an http:// URL without requiring that plaintext HTTP be limited to a validated loopback destination. The documented curl commands then transmit BILL_TRACKER_SESSION_TOKEN as a bearer-equivalent authentication header to that configured endpoint.

Because the token is described as long-lived, interception has greater security consequences than exposure of a short-lived credential. The commands also do not constrain permitted URL schemes or redirect protocols. If a remote plaintext endpoint is configured, or if redirects are accepted under an unsafe configuration, a network-positioned attacker may observe the token and sensitive financial responses.

This issue does not independently grant system privileges and requires an insecure or attacker-influenced endpoint configuration. Nevertheless, the skill lacks safeguards that prevent such a configuration.

Attack Path

  1. A user, deployment script, or atta ...[truncated 1272 chars]
Remediation
View remediation

Remediation Suggestions

  1. Require HTTPS for every non-loopback Bill Tracker endpoint.
  2. Permit plaintext HTTP only after validating that the parsed hostname is an explicit loopback address such as 127.0.0.1 or ::1; do not rely only on string-prefix checks.
  3. Validate BILL_TRACKER_URL before use and reject unsupported schemes, embedded credentials, malformed hosts, and untrusted destinations.
  4. For remote requests, constrain curl with options such as --proto '=https' --proto-redir '=https' and fail on insecure redirects.
  5. Avoid disabling certificate verification and document that curl -k or --insecure must not be used.
  6. Prefer short-lived, narrowly scoped session tokens and provide explicit token expiration, rotation, and revocation mechanisms.
  7. Store the token in a protected secret store rather than plaintext configuration, and ensure it is not written to logs, command traces, or user-visible output.
  8. Consider binding tokens to the intended audience and applying server-side rate limiting, anomaly detection, and immediate revocation after suspected disclosure.
Vulnerability Patterns
  • Data ExfiltrationExternal Transmission, Env Variable Harvesting, File System Enumeration
  • Prompt InjectionInstruction Override, Hidden Instructions, Exfiltration Commands
  • Privilege EscalationExcessive Permissions, Sudo/Root Execution, Credential Access
  • Supply ChainUnpinned Dependencies, External Script Fetching, Obfuscated Code
  • Excessive AgencyUnrestricted Tool Access, Autonomous Decision Making, Scope Creep
Findings (1)

External Transmission

Medium
Category
Data Exfiltration
Confidence
60% confidence
Finding

Data is being sent to an external URL. This could be legitimate telemetry or data exfiltration. Manual review is recommended.

Content

Scanner excerpt · SKILL.md (reported line 22)May include surrounding context.

  1. Request a verification code (sent to email):
bash
curl -s -X POST -H "Content-Type: application/json" \
  -d '{"email":"user@example.com"}' \
  "${BILL_TRACKER_URL}/api/mcp/request-code"

Static analysis

No suspicious patterns detected.