auto-customer-support

• Outcome: Review
• Latest audit: Sep 16, 2026 · 5:45 AM UTC
• Version: 1.0.0

Overview

This is a coherent customer-support scaffold, but its runnable server is exposed with debug mode and unauthenticated webhook/escalation routes, so it needs review before use.

Install only for development or a controlled internal environment unless you first disable Flask debug mode, bind to localhost or a protected interface, add authentication/signature validation and rate limits to the endpoints, and pin dependencies. Do not connect it to real customer channels or ticket systems until those controls are in place.

A.I.G

Vulnerability Patterns

• Unauthorized Access and Privilege Escalation: Obtains permissions beyond the task's legitimate needs
• Insecure Dependencies: Introduces malicious components through unsafe dependency sources
• 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

Findings (3)

T09 · Insecure Skill Coding Practices

Error

• Location: scripts/server.py:62
• Finding: Flask Development Debugger Exposed on All Network Interfaces<![CDATA[ ## Vulnerability Details **File Location**: `scripts/server.py:62-70` **Vulnerability Type**: Exposed development debugger **Risk Level**: High ```python if __name__ == '__main__': p = argparse.ArgumentParser() p.add_argument('--faq', default='skills/auto-customer-support/data/faq.csv') p.add_argument('--port', type=int, default=5005) args = p.parse_args() FAQ = load_faq(args.faq) app.run(host='0.0.0.0', port=args.port, debug=True) ``` ### Technical Analysis The application unconditionally enables Flask debug mode while binding the server to `0.0.0.0`. This makes the development server and its verbose debugging behavior reachable through every available network interface unless an external firewall prevents access. When an unhandled exception occurs, Flask debug responses can disclose source code, local filesystem paths, configuration details, stack frames, and runtime values. Depending on the Werkzeug version, deployment environment, and debugger protections, access to the interactive debugger could potentially permit execution of Python code in the server process context. Flask's built-in server is not designed for production deployment and should not be exposed to untrusted networks. ### Attack Path 1. An operator starts the application using the documented command. 2. The server listens on every network interface with debug mode enabled. 3. A network-reachable attacker sends requests designed to trigger an unhandled exception. 4. The resulting debug response exposes internal application and environment information. 5. If the interactive debugger is exposed and its protection is bypassed or compromised, the attacker may execute Python statements with the privileges of the server process. ### Impact Assessment A successful attack can disclose application source, local paths, runtime data, and configuration details. Under conditions where interactive debugger access is obtained, the attacker could execute arbitrary co ...[truncated 281 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions - Disable debug mode by default: ```python app.run(host='127.0.0.1', port=args.port, debug=False) ``` - Bind to `127.0.0.1` during local development unless remote access is explicitly required. - Use a production WSGI server such as Gunicorn or Waitress for deployed environments. - If development debugging is needed, require an explicit development-only flag and ensure it cannot be enabled in production. - Place the service behind a properly configured reverse proxy and firewall. - Add centralized exception handling that returns generic errors without exposing stack traces or runtime values. - Run the service under a dedicated, minimally privileged operating-system account. ]]>

T05 · Unauthorized Access and Privilege Escalation

Warning

• Location: scripts/server.py:36
• Finding: Webhook and Escalation Endpoints Lack Authentication<![CDATA[ ## Vulnerability Details **File Location**: `scripts/server.py:36-58` **Vulnerability Type**: Missing endpoint authentication and authorization **Risk Level**: Medium ```python @app.route('/webhook', methods=['POST']) def webhook(): data = request.get_json() or {} message = data.get('message','') sender = data.get('sender') if not message: return jsonify({'error':'missing message'}), 400 item, score = best_match(message) threshold = float(os.environ.get('CONFIDENCE_THRESHOLD', '0.6')) if item and score >= threshold: reply = item['answer'] return jsonify({'reply': reply, 'confidence': score, 'escalate': False}) else: # low confidence -> escalate return jsonify({'reply':'抱歉，我不确定如何回答。我们会尽快将您的问题转人工处理。', 'confidence': score, 'escalate': True}) @app.route('/escalate', methods=['POST']) def escalate(): data = request.get_json() or {} # stub: in real integration, create ticket in Zendesk/Feishu/etc. return jsonify({'status':'escalated','data':data}) ``` ### Technical Analysis Neither endpoint validates the caller through a provider signature, API token, mutual TLS certificate, timestamp, nonce, or other authentication mechanism. The service also binds to all network interfaces, making these routes available to any network-reachable client unless protected by external controls. The `sender` value is accepted but not authenticated, allowing callers to claim arbitrary sender identities. The `/escalate` route currently only echoes input and does not create an external ticket, which limits its immediate effect. Nevertheless, it reports a successful escalation to every caller and establishes an insecure access-control pattern that would become more serious if the documented ticket-system integration were implemented without adding authorization. No replay protection, request throttling, or request body-size controls are implemented in the application. ### Attack Path 1. An ...[truncated 1300 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions - Require authentication on both endpoints. - For third-party webhooks, validate the provider's cryptographic signature over the raw request body using a secret stored in an environment variable or secret manager. - For internal clients, require a scoped bearer token or mutual TLS. - Validate timestamps and unique event identifiers to reject stale or replayed requests. - Do not trust the request-provided `sender` field until it has been bound to an authenticated provider identity. - Apply stricter authorization to `/escalate` than to ordinary FAQ requests. - Add per-client rate limits, maximum request body sizes, timeouts, and abuse monitoring. - Return an authorization error rather than a successful escalation status when caller validation fails. - Reassess authorization before connecting the escalation route to any external ticketing or messaging system. ]]>

T08 · Insecure Dependencies

Note

• Location: SKILL.md:27
• Finding: Flask Dependency Is Installed Without Version or Integrity Pinning<![CDATA[ ## Vulnerability Details **File Location**: `SKILL.md:27` **Vulnerability Type**: Unpinned third-party dependency **Risk Level**: Low ```text 1) 安装依赖：uv pip install flask ``` ### Technical Analysis The installation instruction resolves Flask without a version constraint, lockfile, or package hash. As a result, the installed dependency set can change over time even when the project itself has not changed. This prevents reproducible builds and may introduce a future incompatible or vulnerable release. It also leaves transitive dependency versions uncontrolled. The audit found no evidence of typosquatting, a malicious package name, or an unsafe package index; the risk comes specifically from unconstrained dependency resolution and absent integrity verification. ### Attack Path 1. A user follows the documented installation command. 2. The package manager resolves the latest Flask release and its transitive dependencies at installation time. 3. A newly vulnerable, compromised, or incompatible release may be selected without project review. 4. That code is imported and executed when `scripts/server.py` starts. Exploitation depends on a problematic package release or compromised dependency distribution path; no such compromise is established by the audited files themselves. ### Impact Assessment Potential impact includes non-reproducible deployments, unexpected behavior, service outages, and exposure to vulnerabilities introduced by future dependency versions. If a resolved package were compromised, code would execute with the permissions of the user installing or running the service. ]]>
• Remediation: <![CDATA[ ## Remediation Suggestions - Declare Flask and all transitive dependencies in a version-controlled dependency manifest and lockfile. - Pin versions to reviewed releases, for example through `pyproject.toml` and `uv.lock`. - Use package hashes or another integrity-verification mechanism where supported. - Install only from a trusted, explicitly configured package index. - Run dependency vulnerability scanning in continuous integration. - Update pinned versions through a controlled review and testing process rather than resolving unrestricted versions during deployment. ]]>

SkillSpector

Vulnerability Patterns

• Data Exfiltration: External Transmission, Env Variable Harvesting, File System Enumeration
• Trigger Abuse: Overly Broad Trigger, Shadow Command Trigger, Keyword Baiting Trigger
• 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

Findings (9)

Lp3

Medium

• Category: MCP Least Privilege
• Confidence: 88% confidence
• Finding: The skill describes capabilities that rely on environment-based secrets and external integrations, but it declares no explicit tool scope or permission boundaries. In an agent ecosystem, missing scope metadata can cause the skill to be invoked with broader access than intended, increasing the chance of unauthorized secret access or unsafe execution assumptions.

Vague Triggers

Medium

• Confidence: 95% confidence
• Finding: The trigger phrases are broad, natural-language requests that could match ordinary user conversations and unintentionally activate the skill. In a customer-support automation context, accidental invocation could expose webhook behavior, initiate message handling flows, or cause unintended outbound integrations/escalations.

External Transmission

Medium

• Category: Data Exfiltration

Content

2) 启动服务（开发）：
   uv run python skills/auto-customer-support/scripts/server.py --port 5005
3) 测试请求：
   curl -X POST http://localhost:5005/webhook -H "Content-Type: application/json" -d '{"message":"如何退款","sender":"user-123"}'

输出（示例）
- 成功匹配时返回：{ "reply": "...", "confidence": 0.95, "escalate": false }

• Confidence: 60% confidence
• Finding: Data is being sent to an external URL. This could be legitimate telemetry or data exfiltration. Manual review is recommended.

Natural-Language Policy Violations

Medium

• Confidence: 96% confidence
• Finding: The entire auto-reply template is written in Chinese and provides no indication that recipients can choose another language or that the template is intended only for a Chinese-language audience. This can violate a language/locale policy when the skill is used in broader contexts without explicit user opt-in.

Natural-Language Policy Violations

Medium

• Confidence: 95% confidence
• Finding: The FAQ entries and responses are entirely in Chinese, which implies the skill is designed to interact in a fixed language. There is no indication in this file that users can choose another language or that the Chinese-only scope is explicitly justified as a region-specific skill.

Natural-Language Policy Violations

Medium

• Confidence: 93% confidence
• Finding: All user and bot utterances are written in Chinese, and the example gives no indication that other languages are supported or that the language requirement is optional. Under the policy, forcing a specific language without user opt-in is a natural-language policy violation.

Vague Triggers

Medium

• Confidence: 90% confidence
• Finding: The phrase '任何能 POST JSON 的平台' defines the integration scope extremely broadly without constraints or examples of what should not be connected. For a markdown guide, this creates an ambiguous trigger/invocation boundary and could encourage unintended integrations.

Natural-Language Policy Violations

Medium

• Confidence: 97% confidence
• Finding: The fallback reply is always returned in Chinese, regardless of the user's input language or any stated locale setting. This creates a natural-language policy issue because the skill enforces a language without opt-in or justification.

Natural-Language Policy Violations

Low

• Confidence: 84% confidence
• Finding: The file presents all operational guidance exclusively in Chinese, which can amount to a language-policy issue when no user language choice or justification is provided. The content does not indicate that the skill is region-specific or intentionally limited to Chinese-speaking users.

Static analysis

No suspicious patterns detected.