Security audit

Aiding Shifu

Security checks for vulnerabilities and agentic risk

Overview

This Aiding Shifu skill fits its login and work-order purpose, but it handles account tokens and customer data in unsafe and under-disclosed ways that users should review before installing.

Install only if you are comfortable with this skill handling Aiding Shifu account tokens and customer work-order data. Prefer a revised version that removes bundled credentials, stops displaying/copying/printing raw tokens, avoids localStorage for secrets, restricts postMessage to trusted origins or removes it, generates QR codes locally or first-party, and asks clearly before sending customer names, phone numbers, and addresses.

SkillSpector

Vulnerability Patterns

Data ExfiltrationExternal Transmission, Env Variable Harvesting, File System Enumeration
Excessive AgencyUnrestricted Tool Access, Autonomous Decision Making, Scope Creep
Trigger AbuseOverly Broad Trigger, Shadow Command Trigger, Keyword Baiting Trigger
Behavioral ASTexec() Call, eval() Call, Dynamic Import
MCP Tool PoisoningHidden Instructions, Unicode Deception, Parameter Description Injection

Findings (19)

Context-Inappropriate Capability

Medium

Confidence: 98% confidence
Finding: On successful login, the page displays the returned authentication token directly in the UI and later persists it in browser storage. Exposing bearer credentials to the page and to anyone with local browser access, extensions, or injected script greatly increases the chance of account compromise, and this behavior is broader than a normal QR-login UX requires.

Context-Inappropriate Capability

High

Confidence: 99% confidence
Finding: The code posts the login token to window.opener using a wildcard target origin '*', which allows any opener origin to receive the credential. If this login page is opened by an untrusted or compromised site, that site can capture the token immediately after login and impersonate the user.

Intent-Code Divergence

Medium

Confidence: 90% confidence
Finding: The comment claims the token is stored locally only for display, but the implementation also transmits it to the opener window. This mismatch is dangerous because it hides the true credential flow from reviewers and users, increasing the likelihood that sensitive data handling is misunderstood and left unsecured.

Context-Inappropriate Capability

Medium

Confidence: 98% confidence
Finding: The script prints `result.token` or related identifiers directly to stdout after login succeeds. Authentication material in console output can be captured by terminal history, logs, CI wrappers, screen recording, or shoulder surfing, exposing credentials beyond the stated purpose of helping a user log in.

Context-Inappropriate Capability

Medium

Confidence: 91% confidence
Finding: The page explicitly displays the raw authentication token and provides a one-click copy action, which unnecessarily increases the exposure of bearer credentials. In this skill context, a login helper for installation-service workflows does not need to reveal reusable tokens to end users, so this broadens the chance of credential theft, accidental sharing, or misuse by other tools.

Intent-Code Divergence

Medium

Confidence: 96% confidence
Finding: The implementation contradicts its own comment by persisting the token and user profile in localStorage and also sending both to a parent window. This expands the attack surface for sensitive authentication data: any XSS, malicious extension, shared device user, or untrusted opener can access and reuse these credentials.

Vague Triggers

Medium

Confidence: 86% confidence
Finding: The login trigger phrase includes very broad terms such as '登录', which may match unrelated user requests and cause the skill to initiate authentication flows unexpectedly. In a skill with WebFetch, local file access, and Execute privileges, accidental activation raises the chance of unnecessary credential handling and unintended side effects.

Missing User Warnings

Medium

Confidence: 94% confidence
Finding: The skill documents storing access tokens in a local config file but provides no clear warning, consent flow, retention policy, or protection guidance. Local plaintext token storage increases the risk of credential leakage through other tools, repository exposure, shared environments, or accidental file reads.

Missing User Warnings

Medium

Confidence: 90% confidence
Finding: The work-order flow collects customer name, phone number, and address, which are sensitive personal data, but the skill does not present a privacy notice, consent expectation, or data-minimization guidance. In practical use, this can normalize transmitting personal data to APIs without adequate user awareness or legal/operational safeguards.

Missing User Warnings

Medium

Confidence: 96% confidence
Finding: The script persists an authentication token to a predictable config file under the user's home directory without setting restrictive permissions or clearly warning the user that long-lived credentials are being stored. On multi-user systems, compromised accounts, backup/sync tools, or malware with user-level access, this token could be recovered and reused to access the user's account.

Missing User Warnings

Medium

Confidence: 98% confidence
Finding: The code prints the authentication token to stdout, even if truncated, which can expose sensitive credentials through terminal scrollback, shell logging, CI logs, screen recording, or support transcripts. Any party that captures console output may obtain enough of the token, or the full token if logging behavior changes later, to facilitate account compromise.

Missing User Warnings

High

Confidence: 97% confidence
Finding: The page stores the authentication token in localStorage and sends it to another window without any visible disclosure or consent. This removes meaningful user awareness around highly sensitive credential handling and increases exposure to token theft through XSS, malicious browser contexts, or deceptive embedding flows.

Missing User Warnings

Medium

Confidence: 96% confidence
Finding: The QR code is generated by embedding the login URL into a request to a third-party service, which discloses the login URL and associated login session data outside the platform. For QR-login flows, that URL is often a sensitive one-time login artifact; leaking it to an external service can enable session hijacking or third-party tracking.

Missing User Warnings

High

Confidence: 99% confidence
Finding: Printing a login token without masking or warning creates direct credential disclosure. In this skill context, the script is specifically performing platform login, so leaked tokens could grant account access or session hijacking and are more dangerous than a generic debug print.

Missing User Warnings

Medium

Confidence: 88% confidence
Finding: The code writes the QR code to a predictable temporary file and launches it via `exec`, but does not clearly disclose those side effects or constrain the execution method. While `qrPath` itself is locally generated, using the shell unnecessarily increases risk surface and the temp file may remain accessible to other local users or processes.

Missing User Warnings

Medium

Confidence: 97% confidence
Finding: The login request places the phone number and SMS code in the URL query string, even though it uses POST. Query parameters can be logged by browsers, proxies, reverse proxies, analytics systems, and server access logs, causing leakage of one-time authentication secrets and personal data.

Missing User Warnings

Medium

Confidence: 94% confidence
Finding: Displaying, copying, and retaining the authentication token without clear warning or justification exposes a bearer credential that can grant account access if stolen. In a consumer-facing login page, this is more dangerous because users may not understand the sensitivity of the token and may paste it into chat tools or screenshots.

Missing User Warnings

Medium

Confidence: 95% confidence
Finding: Saving the authentication token and user information in localStorage makes them accessible to any script running in the page origin, including injected scripts from XSS or compromised dependencies. Because this skill handles login to a real service, local persistence of secrets significantly increases the likelihood and persistence of account compromise.

Missing User Warnings

High

Confidence: 99% confidence
Finding: Posting the token and user info to window.opener with a wildcard target origin allows any opener window, including an unexpected or malicious one, to receive sensitive login data. This is a direct credential exfiltration path and is especially dangerous in a popup-based login flow where opener trust is not enforced.

Static analysis

Detected: suspicious.dangerous_exec

Shell command execution detected (child_process).

Critical

Code: suspicious.dangerous_exec
Location: tools/login/login.js:202

Shell command execution detected (child_process).

Critical

Code: suspicious.dangerous_exec
Location: tools/login/run-login.js:30