T09 · Insecure Skill Coding Practices
- Location
payment_success_rate_expert/scripts/query_antom_psr_data.py:17- Finding
Merchant Authentication Token Is Transmitted to an Undisclosed API Endpoint
- Content
View full analysis
- Remediation
View remediation
Security audit
Security checks for vulnerabilities and agentic risk
The skill’s reporting workflow is mostly coherent, but it handles merchant and email credentials too broadly and sends the merchant token to a different API host than the documentation names.
Review this skill before installing. Use it only if you trust the actual Antom API host in the code, can store merchant and SMTP credentials securely, and are comfortable with report data being sent by email. Prefer scoped and revocable merchant tokens, an app-specific SMTP password, restrictive permissions on ~/antom/conf.json, TLS-only SMTP, and careful recipient review before sending reports.
payment_success_rate_expert/scripts/query_antom_psr_data.py:17Merchant Authentication Token Is Transmitted to an Undisclosed API Endpoint
payment_success_rate_expert/scripts/query_antom_psr_data.py:49Query and Report Operations Access Credentials Beyond Their Functional Requirements
payment_success_rate_expert/scripts/send_psr_report.py:134SMTP Authentication Can Be Performed over an Unencrypted Connection
SKILL.md:20Reusable Merchant and SMTP Secrets Are Stored in a Plaintext Configuration File
payment_success_rate_expert/requirements.txt:1Third-Party Dependencies Are Installed with Open-Ended Version Constraints and No Integrity Verification
The skill presents itself as a general Antom assistant, yet behavior includes sending outbound email via SMTP using stored credentials and operating on local files. Combining hidden messaging capability with local secret access materially raises abuse potential, since the skill could exfiltrate reports or sensitive business data under the guise of routine assistance.
The skill presents itself as a general Antom assistant, yet behavior includes sending outbound email via SMTP using stored credentials and operating on local files. Combining hidden messaging capability with local secret access materially raises abuse potential, since the skill could exfiltrate reports or sensitive business data under the guise of routine assistance.
The skill presents itself as a general Antom assistant, yet behavior includes sending outbound email via SMTP using stored credentials and operating on local files. Combining hidden messaging capability with local secret access materially raises abuse potential, since the skill could exfiltrate reports or sensitive business data under the guise of routine assistance.
The skill advertises broad Antom assistance but declares no explicit tool scope while documentation indicates use of local configuration files, network access to the Antom portal/API, and outbound email. Missing permission boundaries increases the chance the skill can access files, secrets, or network resources without clear user expectation or platform enforcement.
The description is broad enough to invite activation for almost any Antom-related request, despite the skill appearing to have narrower payment-success-rate and reporting functionality. Overbroad invocation increases the likelihood that sensitive actions occur in contexts where the user did not intend to invoke a privileged reporting or data-access workflow.
Telling users the assistant can handle all Antom-related queries and operations creates an overly expansive trust boundary. In context, the skill has access to merchant configuration and reporting workflows, so broad activation language may cause users to disclose secrets or trigger actions outside the skill's safe, intended scope.
The documentation tells users to ask the copilot for a merchant token while also warning that the token should be kept secure. This contradiction normalizes requesting or exposing a credential through the assistant, increasing the risk of secret disclosure, accidental logging, or misuse of a token that can authenticate to merchant APIs.
The skill describes capabilities that transmit payment success rate data to an external endpoint and can email generated reports, but it does not prominently warn users that payment-related operational data and recipient information may leave the local environment. This lack of disclosure can lead to unintentional sharing of sensitive business data, especially when the skill is invoked automatically or by non-expert users.
The statement that the skill is 'automatically called by the antom_copilot main skill based on user intent' is overly broad and does not define clear trigger conditions, approval gates, or scope limits. In a skill that can pull payment-related data and send emails, vague auto-invocation increases the risk of unintended execution, surprise data transmission, or report sending without sufficiently explicit user confirmation.
The script validates and requires SMTP/email credentials even though it never uses them for its stated function of querying payment success rate data. Unnecessary access to unrelated secrets expands the script's privilege scope, increases the chance of secret exposure through future changes, debugging, or misuse, and is inconsistent with least-privilege design.
The script silently accesses a configuration structure containing sensitive SMTP credentials as part of normal execution without any user-facing need or disclosure. Even if the credentials are not transmitted here, collecting and validating unrelated secrets creates unnecessary secret exposure risk and makes the skill harder to trust and audit.
Data is being sent to an external URL. This could be legitimate telemetry or data exfiltration. Manual review is recommended.
try:
print(f"Fetching data from Antom, date range: {date_range}...")
response = requests.post(API_ENDPOINT, headers=headers, json=payload, timeout=30)
response.raise_for_status()
result = response.json()
The code reads SMTP credentials from a local config file and uses them to authenticate to an external mail server, giving the skill outbound communication ability with privileged local secrets. Even if intended for automation, this expands the trust boundary beyond intent analysis/delegation and increases the risk of credential misuse, unauthorized sending, and data leakage if the skill is triggered unexpectedly or modified.
This script has the capability to send external emails with locally generated report attachments to arbitrary recipients supplied via CLI. In the context of a skill described as a central assistant/delegator, that is a materially broader side effect that can enable unauthorized data exfiltration or accidental disclosure of sensitive merchant reporting data if invoked by an untrusted workflow or user.
Automatic intent-based delegation is described without clear thresholds or constraints, which can cause the skill to activate or route tasks too broadly. While less severe than hidden capabilities, vague activation rules can still lead to unintended processing of sensitive merchant data or initiation of report workflows.
This requirements file contains natural-language comments in Chinese describing the skill components, with no indication that language choice is optional or justified by a region-specific constraint. Under the policy, forcing a specific language without user opt-in can be a locale/language policy violation.
Using requests>=2.25.0 allows any newer version to be installed, making builds non-reproducible and potentially pulling in a vulnerable or behavior-changing release. In a skill that likely performs network access, an unexpected dependency version can increase exposure to known library flaws or break security assumptions.
# Payment Success Rate Expert - Python Dependencies
# 能力一:query_antom_psr_data.py
requests>=2.25.0
# 能力二:analyse_and_gen_report.py
matplotlib>=3.3.0
The manifest does not pin requests, so the project cannot demonstrate that installed versions avoid known advisories. Because requests is commonly used for outbound HTTP and credential-bearing sessions, unverifiable versions may expose sensitive data or TLS/authentication assumptions depending on the resolved release.
An unpinned matplotlib dependency permits uncontrolled version drift across environments. While this library is typically less security-sensitive than network-facing components, unreviewed upgrades can still introduce vulnerable transitive behavior, parsing issues, or execution-time instability.
requests>=2.25.0
# 能力二:analyse_and_gen_report.py
matplotlib>=3.3.0
reportlab>=3.6.0
numpy>=1.19.0
reportlab>=3.6.0 is risky because ReportLab has had serious issues including RCE/SSRF classes of vulnerabilities, and the unpinned spec makes it impossible to know what will actually be installed. If this skill generates reports from user-influenced content, dependency drift could directly expose a dangerous parsing/rendering surface.
# 能力二:analyse_and_gen_report.py
matplotlib>=3.3.0
reportlab>=3.6.0
numpy>=1.19.0
# 能力三:send_psr_report.py
ReportLab has a history of high-impact issues, including code execution and SSRF-related flaws, and the unpinned dependency means the actual installed version cannot be verified as safe. In a reporting skill that likely processes generated document content, this context makes the issue more dangerous because document rendering is directly part of intended functionality.
numpy>=1.19.0 allows arbitrary newer releases, reducing reproducibility and making it harder to assess whether deployed environments include affected versions. The direct security risk is usually lower than for network or document-processing libraries, but supply-chain and vulnerable-version exposure still exist.
# 能力二:analyse_and_gen_report.py
matplotlib>=3.3.0
reportlab>=3.6.0
numpy>=1.19.0
# 能力三:send_psr_report.py
# 仅使用Python标准库,无需额外依赖
Because NumPy is not pinned, it is unclear whether deployments use a version affected by known advisories. Although the package is generally less exposed than HTTP or document-rendering libraries in this skill, unverifiable dependency state still weakens supply-chain assurance and patch management.
This code emits a warning string containing Chinese text ('时出错') inside otherwise English-language user-facing CLI output. That forces a specific language/locale presentation without user opt-in, which fits the natural-language locale policy violation category.
The module docstring and CLI description present this script as generating a payment success rate PDF report, but the implementation also persists a separate executive summary text file to disk. Writing an extra artifact is a broader behavior than the stated report-generation description and is not mentioned in the documentation.
No suspicious patterns detected.