Back to skill

Security audit

拉卡拉MOSS接口演示

Security checks for vulnerabilities and agentic risk

Overview

This payment-order demo openly calls an external MOSS API, but its test-only and no-real-payment claims are not enforced in the code.

Install only if you are comfortable with a script sending order number, amount, subject, remark, and callback URL to Lakala's MOSS endpoint. Treat generated links as potentially payment-capable unless the provider independently confirms the merchant and endpoint are sandbox-only, and avoid real merchant data, real customer data, or production amounts without adding sandbox enforcement and confirmation prompts.

Vulnerability Patterns
  • 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
  • Remote Payload Retrieval and ExecutionFetches external code whose behavior can change after review
Findings (2)

T09 · Insecure Skill Coding Practices

Error
Location
scripts/create_order.py:39
Finding

Test-only payment safety claims are not enforced by the implementation

Content
View full analysis

Vulnerability Details

File Location: scripts/create_order.py:39-62
Related Locations: SKILL.md:10-20, README.md:3-9, scripts/create_order.py:229-230
Vulnerability Type: Unenforced security boundary and misleading operational scope
Risk Level: High

Vulnerable Code

python
url = "https://moss.lakala.com/ord-api/unified/v3"

request_data = {
    "head": {
        "versionId": "1.0",
        "serviceId": "lfops.moss.order.pay",
        "serviceSn": generate_service_sn(),
        "systemCode": "MOSS",
        "channelId": "API",
        "businessChannel": "C00000404"
    },
    "request": {
        "order_no": order_no,
        "total_amount": str(total_amount),
        "mer_no": "M00002042",
        "pay_scene": "0",
        "account_type": "ALIPAY,WECHAT,UQRCODEPAY",
        "order_eff_time": "30",
        "subject": subject,
        "remark": remark,
        "callback_url": callback_url
    }
}

The successful execution path also displays the returned payment URL and directs the user to use it to complete payment.

Technical Analysis

The Skill documentation states that all operations occur in a test environment, do not involve real funds, and produce links without payment capability. The implementation does not technically enforce those guarantees.

The script sends an order directly to https://moss.lakala.com/ord-api/unified/v3, specifies Alipay, WeChat, and UnionPay QR payment channels, extracts the returned counter URL, and presents it as a payment link. It contains no sandbox environment selector, test-host allowlist, mock transport, test-merchant verification, maximum test amount, or explicit confirmation before the external request.

The hardcoded merchant number M00002042 is described as a test merchant, but that status is not verified by the code. Consequently, the repository alone cannot establish that the endpoint and returned links are i ...[truncated 1639 chars]

Remediation
View remediation

Remediation Suggestions

  1. Replace the endpoint with a provider-documented sandbox endpoint or use a local mock server by default.
  2. Require explicit environment configuration, such as --environment sandbox, and reject any other environment unless the user provides separate, informed confirmation.
  3. Maintain an allowlist of approved sandbox hosts and validate the configured endpoint before transmitting an order.
  4. Verify that the merchant identifier is assigned to the sandbox environment rather than relying on a documentation statement.
  5. Validate returned payment URLs against an approved sandbox hostname before displaying them.
  6. Add a strict test-amount ceiling and clearly label every generated order and URL as sandbox data.
  7. Do not tell users that payment is impossible unless that property is guaranteed by enforceable technical controls.
  8. For any production-capable mode, require explicit confirmation, separate merchant configuration, authentication or signing controls, and prominent warnings that funds may be transferred.
  9. Document exactly which order fields are sent to the external service and obtain user confirmation before transmission.

T08 · Insecure Dependencies

Note
Location
SKILL.md:23
Finding

Runtime dependency is installed without a reproducible version and integrity constraint

Content
View full analysis

Vulnerability Details

File Location: SKILL.md:23
Related Location: README.md:36-39
Vulnerability Type: Unpinned third-party dependency
Risk Level: Low

Vulnerable Code

bash
pip install requests

The README provides only a lower bound:

text
requests>=2.28.0

Technical Analysis

The installation command resolves whichever compatible requests release and transitive dependencies are available at installation time. The repository contains no lock file, exact version pin, or package integrity hashes.

The package name is legitimate, and the project does not configure a suspicious package source. Therefore, this finding does not establish dependency confusion, typosquatting, or an actively malicious dependency. The risk is that installation is not reproducible and future package or transitive dependency changes enter the execution environment without project-level review.

Because the script imports requests and uses it for communication with the payment API, dependency behavior directly affects the Skill's network requests and processing of payment-service responses.

Attack Path

  1. A user follows the documented installation command.
  2. The package manager resolves the latest compatible package and transitive dependency versions from the configured index.
  3. Those versions are installed without comparison to repository-controlled hashes.
  4. A compromised, unexpectedly changed, or incompatible future dependency executes when the script imports or invokes it.
  5. Such dependency code runs with the same operating-system permissions as the user running the Skill.

Impact Assessment

A compromised dependency could theoretically access data and network resources available to the Python process or alter requests sent to the payment endpoint. Its privileges would be limited to those of the account running the installation and script.

No malicious dependency is pr ...[truncated 197 chars]

Remediation
View remediation

Remediation Suggestions

  1. Pin requests and all transitive dependencies to reviewed versions in a requirements or lock file.
  2. Add verified SHA-256 hashes and install with hash enforcement, such as pip install --require-hashes -r requirements.txt.
  3. Generate dependencies from a controlled lock process and review upgrades before merging them.
  4. Configure an approved package index explicitly in deployment environments.
  5. Add automated dependency vulnerability scanning and update monitoring.
  6. Keep the documented installation command synchronized with the locked dependency file rather than recommending an unconstrained direct installation.
Vulnerability Patterns
  • Data ExfiltrationExternal Transmission, Env Variable Harvesting, File System Enumeration
  • Trigger AbuseOverly Broad Trigger, Shadow Command Trigger, Keyword Baiting Trigger
  • MCP Least PrivilegeUnderdeclared Capability, Wildcard Permission, Missing Permission Declaration
  • MCP Tool PoisoningHidden Instructions, Unicode Deception, Parameter Description Injection
  • Prompt InjectionInstruction Override, Hidden Instructions, Exfiltration Commands
Findings (6)

Tp2

High
Category
MCP Tool Poisoning
Confidence
85% confidence
Finding

Mixing characters from multiple Unicode scripts in a single identifier is a common technique to create visually ambiguous tool names.

Content

No source excerpt is available for this finding.

Vague Triggers

Medium
Category
Not specified by scanner
Confidence
96% confidence
Finding

The README advertises auto-discovery by mentioning a broad natural-language trigger phrase, which can cause the skill to activate unintentionally when a user casually references '拉卡拉MOSS支付'. For a payment-order skill, unintended activation is more sensitive than a generic utility because it may initiate order-creation flows or expose payment links during ordinary conversation.

Content

No source excerpt is available for this finding.

Undeclared Tool Scope

Medium
Category
MCP Least Privilege
Confidence
88% confidence
Finding

The skill describes making outbound API calls to create test orders, but it declares no explicit tool scope or permissions. That mismatch can cause the runtime to grant broader-than-necessary network capability or leave reviewers unable to verify intended external access, which increases the risk of unauthorized data egress or unexpected remote interactions if the skill is modified or abused.

Content

No source excerpt is available for this finding.

External Transmission

Medium
Category
Data Exfiltration
Confidence
80% confidence
Finding

The script transmits user-supplied order data and a callback URL to an external payment API endpoint. In this demo/payment context, external transmission is expected, but it still poses security risk because sensitive business data is sent off-host and the callback URL is not validated, which can enable misrouting of payment notifications or data exposure to unintended domains.

Content

Scanner excerpt · scripts/create_order.py (reported line 67)May include surrounding context.

python
"Content-Type": "application/json"
        }

        response = requests.post(
            url,
            json=request_data,
            headers=headers,

Missing User Warnings

Low
Category
Not specified by scanner
Confidence
80% confidence
Finding

This markdown file documents sending payment-related fields such as merchant number, order number, amount, and callback URL to a remote HTTPS API. Under the markdown-file criteria for missing user warnings, the description lacks any caution about data sensitivity, production-vs-test use, or privacy/integrity implications of transmitting real transaction data.

Content

No source excerpt is available for this finding.

Natural-Language Policy Violations

Low
Category
Not specified by scanner
Confidence
91% confidence
Finding

This code file contains user-facing natural-language text entirely in Chinese, including the module docstring and CLI help/output, with no indication that the skill is intentionally limited to Chinese-speaking users. Under the policy, forcing a specific language without opt-in is a natural-language policy violation.

Content

No source excerpt is available for this finding.

Static analysis

No suspicious patterns detected.