xinjianxue-skill-anxiety-global

• Outcome: Review
• Latest audit: Sep 14, 2026 · 2:59 PM UTC
• Version: 1.0.1

Overview

This skill is not overtly malicious, but it should be reviewed because it asks users to paste a sensitive account-binding code into chat and sends identifying profile data to a paid external API.

Install only if you are comfortable linking your XinJianXue account to the agent, pasting a one-time authorization code into the chat, storing service credentials in the host credential store, sending birth/gender/location details to www.xinjianxue.com, and spending account tokens for each report. Prefer a browser-based authorization flow or a dedicated secret-entry mechanism if the publisher offers one.

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

other

Warning

• Location: SKILL.md:74
• Finding: Excessive Collection and External Transmission of Personal Profile Data<![CDATA[ ## Vulnerability Details **File Location**: `SKILL.md:74`, `SKILL.md:203-210` **Vulnerability Type**: Excessive personal-data collection and third-party disclosure **Risk Level**: Medium ### Code Snippet ```markdown > ⚠️ **Before you start**: calling this service sends personal information about the subject — date of birth (plus time, if known), gender, place of birth, current location — to the XinJianXue API (`www.xinjianxue.com`) for processing; it is used only for this one analysis and is not stored. This AI calls under your account identity and consumes tokens per call. **Please confirm you understand and agree before starting.** ``` ```markdown - There are two input tiers; **both are billed at tier b (basic) — tier a costs no extra tokens**: - **a (full)**: the subject's date and time of birth + gender + place of birth (country + state/region/city) + current location - **b (basic)**: only the subject's date of birth + gender + current location - **Both tiers must provide**: gender, date of birth (if the user knows the time of birth, include it and the call is automatically upgraded to tier a), and the subject's current location (country + state/region/city) - **Tier a additionally requires**: the exact hour + minute of birth, and the place of birth (country + state/region/city) ``` ### Technical Analysis The Skill requires an Agent to collect and transmit a combination of birth date, potentially exact birth time, gender, birthplace, and current location to an external service. These attributes can form a highly identifying profile when combined. Although the Skill requires user confirmation before transmission, the mandatory input set exceeds what is necessary for ordinary anxiety and rumination guidance. It also states that the remote service does not retain the information, but that server-side property cannot be verified from this repository. This is primarily a privacy and data-minimization issue rather than evidence that the Skil ...[truncated 1155 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions 1. Provide a local, non-report mode that offers anxiety and rumination guidance without transmitting personal data. 2. Apply strict data minimization. Do not require exact birth time, birthplace, or current city unless each field is demonstrably necessary. 3. Obtain granular consent that identifies every field, the recipient, processing purpose, retention period, and token charge. 4. Permit users to omit optional fields without blocking ordinary emotional-support functionality. 5. Publish and technically enforce retention and deletion controls rather than relying solely on an unverifiable statement in the Skill. 6. Avoid collecting data about another person unless that person's explicit, verifiable consent has been obtained. 7. Require encrypted transport, restricted server-side access, logging controls, and contractual limits on secondary processing. ]]>

T09 · Insecure Skill Coding Practices

Error

• Location: SKILL.md:133
• Finding: Sensitive One-Time Authorization Code Collected Through Ordinary Chat<![CDATA[ ## Vulnerability Details **File Location**: `SKILL.md:133-143` **Vulnerability Type**: Plaintext sensitive credential handling **Risk Level**: High ### Code Snippet ```markdown ### Step 2: Ask the user for the XinJianXue AI authorization code and complete the binding **The AI must stop here and ask the user for the XinJianXue AI authorization code.** It is a one-time credential, **usable only to bind the license above to the user's account**, and for nothing else. Use this fixed wording: > "Open the official website **www.xinjianxue.com → sign in → "Personal Center" (个人中心) → "AI Assistant Authorization Code" (AI 助手授权码)**, and send me the 8-character authorization code shown there; I need it to complete the account binding. > Reminder: this code is a **sensitive one-time credential** that is voided the moment the binding succeeds — please confirm you are talking to the official XinJianXue AI assistant (service domain `www.xinjianxue.com`) and send it only to me, this one AI; do not post it in a group chat, do not screenshot or share it, and do not give it to any other AI." `POST /api/xinjianxue/ai/license/bind` with body: ```json { "license": "XJX-AI-xxxxxxxxxxxxxxxx", "auth_code": "<the 8-character code the user sent>" } ``` ``` ### Technical Analysis The Skill correctly identifies the authorization code as a sensitive credential, but then requires the user to paste that credential into an ordinary conversation. Chat messages may be retained in conversation history, observability systems, model-provider telemetry, backups, moderation pipelines, browser storage, or support tooling. The fact that the code is one-time use limits the exposure window but does not eliminate the vulnerability. Anyone who obtains and redeems the code before the intended Agent can bind the user's account to an unintended Agent identity. Warning the user not to share the code does not protect it from the systems that process and store the conversation. ### Attack Pat ...[truncated 1197 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions 1. Replace chat-based code collection with a browser-mediated authorization flow, such as OAuth authorization code flow with PKCE. 2. Have the user enter the credential directly on the official service domain rather than sending it through the Agent conversation. 3. Bind authorization requests to the intended license, Agent instance, redirect URI, and a cryptographically random state value. 4. Set a short expiration time and enforce atomic, single-use redemption. 5. Prevent authorization codes from appearing in application logs, telemetry, traces, analytics, model context, or conversation history. 6. If a dedicated secret-entry control is unavoidable, ensure that it bypasses ordinary chat storage and is masked in the interface. 7. Add an account-side confirmation screen that displays the Agent identity before the binding becomes effective. ]]>

T09 · Insecure Skill Coding Practices

Error

• Location: SKILL.md:96
• Finding: Long-Lived API Credential Included in Report Request Bodies<![CDATA[ ## Vulnerability Details **File Location**: `SKILL.md:96-101`, `SKILL.md:218-227` **Vulnerability Type**: Insecure API credential transmission and logging exposure **Risk Level**: High ### Code Snippet ```markdown > ⚠️ Where the credentials go (per the server implementation; the three entry points differ): > - Item 5 (report): **`api_key` must be in the body** (the report logic reads only the body); `license` may go in the body or in a header. > - Item 4 (bill): GET has no body, so **both credentials can only go in headers**. > - Item 3 (verify): body or headers, either works. ``` ```json { "license": "XJX-AI-xxxxxxxxxxxxxxxx", "api_key": "<API_KEY>", "birth": "1990-01-01 08:30", "gender": "Female", "country": "United States", "place": "New York City", "current_country": "United States", "current_place": "New York City" } ``` ### Technical Analysis The report endpoint requires a long-lived API key to be placed in the JSON request body. Request bodies are commonly captured by reverse proxies, API gateways, application diagnostics, distributed tracing, error-reporting platforms, and debugging middleware. Credential-bearing bodies can therefore be retained in more systems and for longer periods than properly redacted authentication headers. TLS protects the request in transit from passive network interception, but it does not protect the credential from endpoint-side body logging or from authorized infrastructure components that terminate TLS. The same body combines the API key with personal report inputs, increasing the sensitivity of any leaked request record. ### Attack Path 1. The Agent sends a report request containing the license, API key, and subject profile in the JSON body. 2. A proxy, gateway, tracing system, application logger, debugging component, or error handler records the body. 3. An attacker compromises the logging system or obtains access through excessive employee or service permissions. 4. The attacker extrac ...[truncated 931 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions 1. Redesign the report endpoint to accept credentials only in a standard authorization header. 2. Replace long-lived API keys with short-lived, narrowly scoped access tokens. 3. Configure gateways, proxies, application servers, tracing platforms, and error handlers to redact authentication material and sensitive profile fields. 4. Never log complete request bodies for this endpoint. Use an allowlist of non-sensitive diagnostic fields where logging is necessary. 5. Support credential rotation and immediate revocation without requiring the entire account onboarding process to be repeated. 6. Restrict the credential to report creation and deny unrelated account operations. 7. Add replay protections, usage alerts, rate limits, and anomaly detection for unexpected report generation. 8. Ensure secrets are loaded from dedicated credential storage and are never placed in conversation history, configuration files, or model memory. ]]>

SkillSpector

Vulnerability Patterns

• Excessive Agency: Unrestricted Tool Access, Autonomous Decision Making, Scope Creep
• Prompt Injection: Instruction Override, Hidden Instructions, Exfiltration Commands
• Data Exfiltration: External Transmission, Env Variable Harvesting, File System Enumeration
• Privilege Escalation: Excessive Permissions, Sudo/Root Execution, Credential Access
• Supply Chain: Unpinned Dependencies, External Script Fetching, Obfuscated Code

Findings (1)

Autonomous Decision Making

Medium

• Category: Excessive Agency

Content

Call `POST /api/xinjianxue/ai/license/verify` (include credentials if you have them; body or headers are both accepted). **The only criterion is `pass`:**

- `pass: true` → **already onboarded**: use the APIs directly, and do not ask the user for any credential.
- No credentials / `pass: false` → act on the returned `msg`; **go to Step 1 only once you have confirmed "never onboarded"**. Do not blindly re-apply (re-applying produces an extra license that nobody uses).

### Step 1: Apply for the AI business license (once only)

• Confidence: 80% confidence
• Finding: Skill enables autonomous high-impact decisions without human-in-the-loop verification. Critical operations (destructive commands, financial transactions, data deletion) should require explicit user confirmation.

Static analysis

No suspicious patterns detected.