Security audit

Free Ai

Security checks for vulnerabilities and agentic risk

Overview

The skill is a real deal-finding playbook, but it asks the agent to handle accounts, browser sessions, verification codes, API keys, payments, and persistent user data with insufficient boundaries.

Install only if you are comfortable with an agent helping create accounts, observing browser sessions, handling API keys, and saving account-related progress. Prefer manual signup and key storage, do not let it read your mailbox or payment details, avoid cross-region or reseller paths that may violate terms, and use a pinned or checksum-verified install source rather than the unpinned npx command.

A.I.G

Vulnerability Patterns

Unauthorized Access and Privilege EscalationObtains permissions beyond the task's legitimate needs
Insecure DependenciesIntroduces malicious components through unsafe dependency sources
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

Findings (4)

T08 · Insecure Dependencies

Error

Location: README.md:21
Finding: Unpinned npx Installation Executes Mutable Third-Party Code<![CDATA[ ## Vulnerability Details **File Location**: `README.md:21-28` and `README.zh-CN.md:21-28` **Vulnerability Type**: Supply-chain risk from unpinned executable dependencies **Risk Level**: High ### Vulnerable Code ```markdown ## ⚡ Install（一行安装） ```bash npx skills add laowang-ai-xbb/free-ai-token ``` - **Requirements**: any Agent Skills-compatible client with web access enabled. Node.js 18+ is needed for `npx`. - **No terminal? Manual install**: download the latest zip from Releases and unzip it into your client's skills directory. ``` ### Technical Analysis The documented installation command invokes `npx` without pinning the `skills` package to a specific version. It also identifies the Skill by a mutable repository name rather than an immutable release tag or commit hash. `npx` can retrieve and execute package code during installation. Consequently, the effective installer code may differ from the code reviewed in this audit. The project does not provide a checksum, cryptographic signature, lock file, pinned installer version, or immutable Skill revision in this installation path. The audited repository does not itself contain a confirmed malicious installer, and there is no evidence that the current package is compromised. The vulnerability is that compromise of the package registry account, installer package, repository account, or mutable upstream revision could turn the documented installation command into a remote code-execution path. ### Attack Path 1. An attacker compromises the package publishing account, repository account, or another mutable component used by the `npx skills` installation process. 2. The attacker publishes a modified package version or replaces the repository content referenced by `laowang-ai-xbb/free-ai-token`. 3. A user follows the documented command without a version or integrity constraint. 4. `npx` downloads the current package and executes its installation behavior. 5. The malicious package or mutable Skill ...[truncated 885 chars]
Remediation: <![CDATA[ ## Remediation Suggestions 1. Pin the installer package to an audited version, for example: ```bash npx skills@X.Y.Z add laowang-ai-xbb/free-ai-token@v2.9.5 ``` 2. Prefer an immutable commit hash or signed release rather than a mutable repository branch. 3. Publish SHA-256 checksums for release archives and document verification before extraction. 4. Sign releases using a verifiable mechanism such as Sigstore or signed Git tags. 5. Use `npx --ignore-scripts` where compatible, or clearly document whether lifecycle scripts are executed. 6. Document the exact registry and package publisher so users can verify provenance. 7. Make the verified archive installation method the recommended path for security-sensitive environments. 8. Add automated release checks that confirm the archive contents match the signed source revision. ]]>

T09 · Insecure Skill Coding Practices

Warning

Location: assets/vendor-cache.md:73
Finding: User Email Addresses and Account Associations Are Persisted Without Retention Controls<![CDATA[ ## Vulnerability Details **File Location**: `assets/vendor-cache.md:73-79` and `assets/vendor-cache.md:125-133` **Vulnerability Type**: Persistent storage of personal account metadata **Risk Level**: Medium ### Vulnerable Code ```markdown ## Persistence ladder (where to actually write) 1. **Host persistent memory / ledger tool** — preferred when the host exposes one. 2. **This file** — when the skill directory is writable. 3. **Session-only** — and TELL the user this run's discoveries/preferences were NOT persisted. Never claim "saved" when nothing was written. ``` ```markdown - `accounts`: registration ledger — entries shaped `{platform, email, session_confirmed_on, notes}`; reused for session-first fast paths (`auto-register.md` §0.1 step 5) and never re-asking answered intake questions. Sessions expire — re-verify before trusting. - `checkpoints`: in-progress registrations **and purchases** — `{platform, stage, updated_on}`; `stage` ∈ `preflight` / `intake` / `submitted` / `email_verified` / `key_created` / `saved` / `purchased` / `plan_active`. ``` ### Technical Analysis The Skill directs the Agent to persist account records containing the user's email address, platform association, session-confirmation date, and arbitrary notes. It prefers host-level persistent memory and falls back to a Markdown file in the Skill directory. Although vendor records and unverified discoveries have 30-day cleanup rules, no equivalent expiration or deletion rule is defined for `accounts` or `checkpoints`. The storage policy also lacks: - Explicit user consent before retaining the email address. - Encryption requirements. - Access-control requirements for the cache file or host ledger. - Data minimization or email masking. - A user-facing command to inspect or delete retained records. - A restriction on what may be placed in the free-form `notes` field. The project explicitly prohibits API keys and passwords from entering this file, which re ...[truncated 1392 chars]
Remediation: <![CDATA[ ## Remediation Suggestions 1. Make account-record persistence opt-in and request explicit consent before the first write. 2. Default registration state to session-only storage. 3. Avoid storing complete email addresses. Use a masked value, provider-local account ID, or user-defined alias where possible. 4. Define a short retention period for account records and checkpoints, such as 7–30 days. 5. Automatically remove completed or abandoned checkpoints after their retention period. 6. Add user commands to list, export, and delete all retained personal data. 7. Require restrictive file permissions when writing the cache, such as owner read/write only. 8. Use an encrypted credential or private-data store when identifiable account records must persist. 9. Constrain `notes` to a structured allowlist and prohibit personal data, mailbox content, tokens, and authentication details. 10. Document the exact retained fields and retention period in the README privacy and safety section. ]]>

T05 · Unauthorized Access and Privilege Escalation

Warning

Location: references/capability-check.md:17
Finding: Registration Workflow Performs Overbroad Local and Browser-Session Enumeration<![CDATA[ ## Vulnerability Details **File Location**: `references/capability-check.md:17-39` and `references/auto-register.md:40-58` **Vulnerability Type**: Excessive local-environment and authenticated-session access **Risk Level**: Medium ### Vulnerable Code ```markdown | Capability | How to probe (name-agnostic) | If present | |---|---|---| | **Browser automation** | List available tools/skills; look for anything that can open a URL + observe the page (screenshot / snapshot / DOM read) + click / type. Confirm with a live micro-test: open `example.com`, take a snapshot. | browser-capable profile | | **Live web search** | Any web-search tool/connector answers a trivial query | can hunt fresh deals | | **Secure storage** | Can write a file with restricted permissions / call an OS keychain CLI / host credential store | keys can be stored per `auto-register.md` §3 ladder | | **Persistent memory** | Host exposes a memory/ledger tool | cache & preferences persist (persistence ladder rung 1) | **Installed-app awareness:** when the flow will ask "where to configure the key", probe the user's installed apps/clients first — intake options may only list tools the user actually has. Never offer a target app that isn't installed. ``` ```markdown 2. Blocked or doubtful → check proxy state silently (**READ-ONLY**), then guide the user to open their proxy if they have one, and RE-TEST THROUGH THE USER'S BROWSER: open the platform homepage and confirm it renders. **Gate 2 — Right browser, one window.** For a login path, enumerate open browser windows and attach to the one whose title/URL shows the platform AND holds the login session; if none is found, ask ONE line ("which browser are you logged in with?"). ``` ### Technical Analysis The registration workflow authorizes multiple forms of host and browser inspection: - Listing available tools and Skills. - Probing secure-storage and persistent-memory facilities. - Inspecting installed applications and clients. - R ...[truncated 2083 chars]
Remediation: <![CDATA[ ## Remediation Suggestions 1. Require explicit consent before inspecting installed applications, browser windows, proxy state, keychains, or persistent-memory systems. 2. Replace broad application inventory with a direct question asking which client the user wants to configure. 3. Scope browser discovery to the named vendor domain and avoid collecting unrelated window titles or URLs. 4. Ask the user to select or foreground the correct browser window rather than automatically enumerating all windows. 5. Require a per-action confirmation before attaching to an authenticated session. 6. Prohibit screenshots or DOM capture outside the selected vendor tab. 7. Define a minimal capability probe that checks only whether a required operation is available, without inventorying all tools. 8. Do not persist proxy details, unrelated installed applications, window titles, URLs, or session observations. 9. Add a structured allowlist of information that the capability check may inspect and retain. 10. Record consent state for the current task only; do not infer continuing consent in later sessions. ]]>

T05 · Unauthorized Access and Privilege Escalation

Error

Location: references/auto-register.md:213
Finding: Agent May Read Authentication Codes from a Logged-In Mailbox Without Explicit Per-Access Consent<![CDATA[ ## Vulnerability Details **File Location**: `references/auto-register.md:213-226` **Vulnerability Type**: Insufficient authorization boundary for mailbox and OTP access **Risk Level**: High ### Vulnerable Code ```markdown ### 2.2 Human-verification gates (pause automation) | Gate | What happens | |---|---| | Email verification code sent to inbox | Ask user to read it to you (or read from an already-logged-in mailbox if legitimately available). Pause. | | SMS code | Pause; ask user for the code. Never guess. | | Google/GitHub/Apple OAuth | Pause; let user complete the SSO in the visible browser, then resume. | | CAPTCHA / reCAPTCHA / slider | Pause; ask user to solve it in the browser. | | Anti-bot / device-fingerprint block | Stop automating; degrade to §4 steps. | **Gate handoff protocol (every pause):** 1. ONE atomic request, precisely guided — e.g. "open your mailbox, find the mail from Groq, tell me the 6 digits; inbox empty? check the spam folder". 2. Email-code fallback order: wait ~60 s → check spam/junk → still nothing → suggest a Gmail/Outlook address → re-send ONCE at most. ``` ### Technical Analysis The primary path asks the user to retrieve the email verification code, but the parenthetical alternative permits the Agent to read it from an already authenticated mailbox when “legitimately available.” That phrase does not define: - How explicit user consent is obtained. - Whether consent must be granted for each mailbox access. - Which mailbox, folder, sender, or message may be opened. - Whether message bodies, subjects, or adjacent messages may be observed. - Whether the code may be placed in the Agent transcript or logs. - Whether mailbox-derived data may be retained. A mailbox is a highly sensitive authenticated resource. Access to one registration email can expose unrelated private correspondence, password-reset messages, financial notices, account identities, or authentication codes for other services. The Skill correctly p ...[truncated 1607 chars]
Remediation: <![CDATA[ ## Remediation Suggestions 1. Remove the autonomous mailbox-reading alternative entirely. 2. Require the user to retrieve and enter email verification codes personally. 3. If mailbox assistance is retained, require explicit, one-time consent immediately before access. 4. Restrict consent to a named mailbox, expected sender, and specific registration message. 5. Do not permit inbox-wide searches, unrelated folder access, or inspection of adjacent messages. 6. Prefer a user-mediated copy operation in which the Agent never receives the complete mailbox view. 7. Treat verification codes as secrets: do not echo, persist, cache, log, or include them in screenshots. 8. Clear code-bearing page state and tool artifacts where the host supports secure deletion. 9. Add an explicit prohibition against reading password-reset messages, financial messages, or authentication emails for unrelated services. 10. Apply the same user-controlled handoff model used for SMS codes and OAuth to all email verification. ]]>

SkillSpector

Vulnerability Patterns

Prompt InjectionInstruction Override, Hidden Instructions, Exfiltration Commands
Data ExfiltrationExternal Transmission, Env Variable Harvesting, File System Enumeration
Excessive AgencyUnrestricted Tool Access, Autonomous Decision Making, Scope Creep
Tool MisuseTool Parameter Abuse, Chaining Abuse, Unsafe Defaults
Trigger AbuseOverly Broad Trigger, Shadow Command Trigger, Keyword Baiting Trigger

Findings (22)

Description-Behavior Mismatch

Medium

Confidence: 94% confidence
Finding: The file defines persistent storage for account records and workflow checkpoints including registration and purchase state, which expands the skill from simple deal discovery into tracking user account activity. In this skill's context, that is risky because it supports automated account creation and subscription purchasing, creating unnecessary collection and retention of user-associated data that could be misused, exposed, or used to facilitate evasive account farming.

Context-Inappropriate Capability

Medium

Confidence: 92% confidence
Finding: Persisting account identifiers and purchase progress is not well-justified for a deal-hunting skill and materially increases privacy and abuse risk. Because the overall skill advertises auto-registration, key wiring, and region-based cheap subscription acquisition, this storage can enable repeated account creation, tracking of transactional state, and operational scaling of potentially policy-violating behavior.

Context-Inappropriate Capability

Medium

Confidence: 95% confidence
Finding: The skill explicitly recommends proxy usage and preferred exit-node regions to work around reachability barriers during account registration. In the context of a skill whose purpose is to obtain low-cost or free API access, this materially facilitates bypassing geographic/platform controls and goes beyond neutral setup guidance.

Context-Inappropriate Capability

Medium

Confidence: 94% confidence
Finding: The instruction to read verification codes from an already-logged-in mailbox expands the agent's access from vendor signup into email-account content, which is a separate, highly sensitive account boundary. Even if framed as convenience, it normalizes credential-adjacent access and increases the risk of exposing inbox data or one-time codes through the agent workflow.

Context-Inappropriate Capability

Medium

Confidence: 89% confidence
Finding: The scheduled scan flow goes beyond answering user queries by instructing the skill to write to a skill-writable cache and maintain persisted state. In a skill focused on finding deals and keys, this expands data handling and introduces unauthorized retention or cross-session profiling risk, especially if the host exposes persistent storage without granular consent.

Context-Inappropriate Capability

Medium

Confidence: 92% confidence
Finding: The persistence ladder establishes a profile ledger with region, targets, saved picks, filters, and language, creating durable user state not strictly necessary for the skill's core purpose. Because the skill also targets account registration and deal hunting, this state can be used to infer user behavior and preferences across sessions, increasing privacy and abuse risk if persistence is silent or poorly scoped.

Vague Triggers

Low

Confidence: 89% confidence
Finding: The trigger phrase "How can I use AI for free?" is broad enough to match ordinary conversation unrelated to this specific skill. In agent ecosystems that auto-activate skills from description or trigger overlap, this can cause unintended invocation of a skill that performs live web research and potentially guides account setup, expanding attack surface and creating opportunities for unsafe or policy-sensitive assistance.

Vague Triggers

Low

Confidence: 87% confidence
Finding: The Chinese trigger example "怎么免费用AI？" is similarly overbroad and likely to collide with normal user conversation. Because this skill is designed to search for free or cheap access paths and can progress into setup guidance, accidental activation increases the chance of unnecessary web actions, confusing responses, or steering users toward sensitive account-registration workflows.

Vague Triggers

Medium

Confidence: 87% confidence
Finding: The trigger list includes broad phrases like pricing comparisons and cheap/free AI access that overlap with normal informational requests. In this skill's context, unintended invocation is more dangerous than usual because the skill is explicitly designed to move quickly into account registration, key handling, configuration, and purchase guidance with minimal clarification.

Missing User Warnings

High

Confidence: 96% confidence
Finding: The description advertises auto-registration and automatic wiring of API keys into downstream agents without surfacing credential, privacy, account-lockout, billing, or terms-of-service risks up front. Because this skill targets acquisition and handling of third-party credentials, users may be led into sensitive actions without informed consent, increasing the chance of secret exposure, unauthorized account changes, or risky use of gray-market providers.

Natural-Language Policy Violations

Medium

Confidence: 92% confidence
Finding: The skill explicitly recommends switching to specific proxy exit-node countries to overcome access blocking, which operationally guides users around regional or provider access controls. In the context of a skill focused on obtaining cheap/free AI access and automating account setup, this is more dangerous because it can facilitate geo-restriction evasion and policy bypass rather than neutral troubleshooting.

Missing User Warnings

Medium

Confidence: 92% confidence
Finding: The skill directs immediate recording of reachability and account-related findings into vendor-cache.md without explicit user notice or consent. That creates undisclosed persistence of operational/account history, which can expose sensitive metadata about the user's platforms, login state, and regional access constraints.

Missing User Warnings

Medium

Confidence: 93% confidence
Finding: Although the skill says to avoid echoing keys in chat, it still authorizes writing secrets into local credential stores or .env files without an explicit risk disclosure or per-destination confirmation. This can lead to sensitive API keys being stored in locations the user does not expect, potentially in plaintext (.env) or in environments shared with other tools.

Missing User Warnings

Medium

Confidence: 95% confidence
Finding: The persistence/checkpoint sections require saving mid-flow findings and registration stages to vendor-cache.md, again without an explicit warning that user-related operational history is retained. Checkpoints such as platform, stage, and account status can reveal meaningful behavioral and account metadata if later accessed by other components or users.

Natural-Language Policy Violations

Medium

Confidence: 84% confidence
Finding: Mandating a Chinese scheduled-scan footer and format regardless of user preference creates an output-language override that can confuse users and reduce transparency about automated actions. While not a direct code-execution issue, it can impair informed consent and usability, particularly when the skill otherwise claims language selection support.

Vague Triggers

Low

Confidence: 86% confidence
Finding: The string encourages users to continue with broad follow-up phrases like “find me more options” or “cheap memberships,” which are generic enough to match ordinary conversation outside a narrowly scoped deal-finding flow. In this skill’s context, broad triggers are more dangerous because the skill is explicitly designed to steer users toward acquiring free/cheap tokens, memberships, and cross-region offers, so accidental invocation could route benign chat into risky acquisition workflows.

Missing User Warnings

Medium

Confidence: 95% confidence
Finding: The text says the agent may generate a password, store it safely, and tell the user where it lives, which normalizes credential generation and storage by the skill without explaining storage boundaries, encryption, retention, or user consent. In this skill’s context, that is especially risky because the broader functionality includes auto-registering accounts and wiring keys into tools, creating a pathway for the system to handle sensitive credentials and API secrets in ways users may not fully understand or control.

Ssd 3

Medium

Confidence: 91% confidence
Finding: The skill explicitly instructs persistence of preferences and confirmed discoveries into a writable cache before sending output, creating a retention surface for interaction-derived user data. Even if it says not to store plaintext keys in that cache, retained region, language, intent, pricing interests, account progress, and checkpoints can still reveal sensitive behavioral data and become a privacy or cross-session misuse risk.

Ssd 3

Medium

Confidence: 89% confidence
Finding: The post-success continuity rule reuses previously collected tool information to continue configuration automatically without re-confirmation. In a credential-handling workflow, this increases the risk of acting on stale, misunderstood, or overly broad consent and can propagate secrets or account changes into tools the user did not intend to configure in that moment.

Ssd 3

Medium

Confidence: 97% confidence
Finding: Telling the user to disclose email or SMS verification codes in chat creates a direct secret-leakage channel. One-time codes are authentication factors; capturing them in conversation logs or agent memory can enable account takeover or later misuse, especially if logs are retained or shared.

Autonomous Decision Making

Medium

Category: Excessive Agency
Content: **Post-success continuity (don't drop the user at the finish line):** the intake already asked which tool they use — on key capture, load that `agents/*` doc and start the config walkthrough **without asking again**; then offer, in one line, the scheduled scan (`/scan`) to watch price drops / quota resets at the trust peak.
Confidence: 84% confidence
Finding: The instruction to start the configuration walkthrough 'without asking again' authorizes autonomous continuation after key capture. In this skill's context, that autonomy is riskier because the subsequent steps can affect external applications, credentials, and persistent setup, so skipping a fresh confirmation reduces user control over sensitive downstream actions.

Tool Parameter Abuse

High

Category: Tool Misuse
Content: �qa}r�� ''~�C!�ZK�KA� �<��i�X�5��0��3 O��.��q �D\��Yi�� k"�c�J�JȵPû{��J��j�w�V~��m>2W��:W!.� 2�,�4��CU��Z��R�BN' \��m�I�J��2-� �J,>ׁ��[O�R I!(��h��6�t�p 0H�2��:' *6/��U��$��ɽ#K��ʌ;�� !DojQ��
Confidence: 97% confidence
Finding: The skill’s stated purpose is to find free or cheap API tokens/keys, auto-register accounts, and wire discovered keys into downstream agents and clients. In context, that is highly indicative of credential harvesting/acquisition and automated propagation of secrets into tools, which creates a clear path for unauthorized use of third-party services, account abuse, and exfiltration of sensitive credentials.

Static analysis

No suspicious patterns detected.