subscription-slayer

• Outcome: Pass
• Latest audit: Sep 16, 2026 · 10:43 AM UTC
• Version: 0.1.2

Overview

This skill is a local subscription-audit helper that reads user-provided JSON and generates analysis and draft cancellation emails, with no hidden network access, persistence, or automatic account changes.

Install only if you are comfortable giving the tool a subscription JSON file you choose. Treat the waste scores and cancellation emails as drafts: verify dates, costs, cancellation URLs, support email addresses, and account details yourself before acting or sending anything.

A.I.G

Vulnerability Patterns

• Insecure Skill Coding Practices: Finds exploitable flaws such as hardcoded secrets or command injection
• Skill Instruction Hijacking: Alters the agent's session goals or safety constraints when the skill loads
• Agent Memory Poisoning: Writes attacker-controlled rules into memory that affect later sessions
• Remote Payload Retrieval and Execution: Fetches external code whose behavior can change after review
• Embedded Malicious Code: Ships malicious scripts inside the skill and executes them locally

Findings (2)

T09 · Insecure Skill Coding Practices

Warning

• Location: scripts/subscription_tracker.py:284
• Finding: Unverified Cancellation Email Recipient Inference## Vulnerability Details **File Location**: `scripts/subscription_tracker.py:284-295` **Vulnerability Type**: Untrusted recipient inference and potential sensitive-information disclosure **Risk Level**: Medium ### Vulnerable Code ```python def generate_cancellation_email(sub: dict) -> str: """Generate a cancellation email for a subscription.""" name = sub.get("name", "the service") # Guess email and company from name company = name.split()[0] if name else "the company" domain = company.lower().replace(" ", "") + ".com" email = f"support@{domain}" subject = f"Cancellation Request — {name} Subscription (Account #[YOUR ACCOUNT ID])" return EMAIL_TEMPLATE.format( email=email, subject=subject, company=company, name=name ) ``` ### Technical Analysis The cancellation recipient is derived from the first word of the user-controlled subscription name. The code assumes that the corresponding company owns a matching `.com` domain and that `support@<domain>` is its cancellation address. It performs no authoritative lookup, validation, allowlisting, or user confirmation. The generated message requests that users insert their full name, account email, and account/member ID. Consequently, an incorrect inferred recipient could receive sensitive account-identifying information. The documentation advises users to verify the address, but the generated output itself presents the guessed address as the `To` recipient and does not technically enforce verification. The script only generates text and does not send email itself. Exploitation therefore depends on a user or integrating agent sending the generated message without independently verifying the recipient. ### Attack Path 1. An attacker influences an imported subscription record or convinces the user to analyze a crafted record. 2. The attacker chooses a subscription name whose first word corresponds to a domain controlled ...[truncated 874 chars]
• Remediation: ## Remediation Suggestions 1. Remove recipient inference from subscription names. 2. Add an explicit `support_email` field to the input schema and require the user to supply it. 3. Validate the address syntactically and reject malformed domains or control characters. 4. Label all unverified contact information prominently and omit the `To` field until verification is complete. 5. Require an explicit recipient-preview and confirmation step before any integrating agent sends an email. 6. Prefer the verified cancellation URL supplied by the subscription provider. 7. If provider contact mappings are supported, maintain a curated mapping tied to verified provider domains rather than deriving addresses heuristically. 8. Minimize sensitive content in templates and advise users not to include account identifiers unless the verified provider requires them.

T09 · Insecure Skill Coding Practices

Note

• Location: scripts/subscription_tracker.py:76
• Finding: Future Dates Are Misinterpreted as Historical Dates## Vulnerability Details **File Location**: `scripts/subscription_tracker.py:76-78` **Vulnerability Type**: Improper semantic date validation **Risk Level**: Low ### Vulnerable Code ```python def days_between(d1: date, d2: date) -> int: """Return the number of days between two dates.""" return abs((d2 - d1).days) ``` This function is used for `last_used` and `start_date` calculations: ```python days_unused = days_between(last_used, reference_date) ``` ```python age_days = days_between(start_date, reference_date) ``` ### Technical Analysis Applying `abs()` discards the direction of the date difference. A future `last_used` date is therefore treated as if the subscription had not been used for the equivalent number of days. A future `start_date` is similarly treated as subscription age. Because these values directly contribute to the waste score, malformed or manipulated future dates can substantially inflate a subscription's score and cause it to be classified as a cancellation candidate. The issue affects the integrity of financial recommendations rather than system confidentiality or execution privileges. ### Attack Path 1. A malformed data source or attacker-controlled subscription record supplies a future `last_used` or `start_date`. 2. `parse_date_safe()` accepts the value because it is syntactically valid ISO date data. 3. `days_between()` applies `abs()` to the negative difference. 4. The future date becomes a large positive number of elapsed days. 5. The scoring algorithm adds inactivity or subscription-age points. 6. The tool may incorrectly recommend cancellation and include the subscription in projected savings. ### Impact Assessment No system privileges, code execution, or direct data access can be obtained through this flaw. The affected scope is the accuracy and integrity of waste scores, savings estimates, and cancellation recommendations. A user relying on the result could ...[truncated 78 chars]
• Remediation: ## Remediation Suggestions 1. Preserve date direction instead of applying `abs()`: ```python return (d2 - d1).days ``` 2. Reject or explicitly flag future `last_used` dates. 3. Reject future `start_date` values unless the application intentionally supports scheduled subscriptions. 4. Return structured validation errors rather than silently assigning misleading scores. 5. Validate that the top-level JSON value is a list and that each entry has correctly typed, semantically valid fields. 6. Add tests covering future dates, invalid dates, leap days, missing dates, and dates equal to the reference date.

SkillSpector

Vulnerability Patterns

• Data Exfiltration: External Transmission, Env Variable Harvesting, File System Enumeration
• MCP Least Privilege: Underdeclared Capability, Wildcard Permission, Missing Permission Declaration
• Prompt Injection: Instruction Override, Hidden Instructions, Exfiltration Commands
• Privilege Escalation: Excessive Permissions, Sudo/Root Execution, Credential Access
• Supply Chain: Unpinned Dependencies, External Script Fetching, Obfuscated Code

Findings (2)

Lp3

Medium

• Category: MCP Least Privilege
• Confidence: 84% confidence
• Finding: The skill advertises command execution over local files (`analyze subs.json`, `cancel subs.json`) but does not declare any explicit tool scope or permissions for file access. This creates an authorization ambiguity where an agent may read user-provided local files without clear policy boundaries, increasing the risk of unintended access to sensitive financial or personal data if the filename/path is influenced by the user or runtime context.

Missing User Warnings

Low

• Confidence: 89% confidence
• Finding: The cancellation feature generates ready-to-send messages and presents them in a way that could prompt users to take consequential account actions without sufficiently prominent verification guidance. Because the tool guesses recipient email addresses from subscription names and may include inaccurate or mismatched account details, users could mistakenly send cancellation requests to the wrong party or act on incorrect recommendations.

Static analysis

No suspicious patterns detected.