T09 · Insecure Skill Coding Practices
- Location
scripts/check_data.py:44- Finding
Hard-Coded SMTP Authentication Credential
- Content
View full analysis
- Remediation
View remediation
Security audit
Security checks for vulnerabilities and agentic risk
This skill is a real market-data checker, but it can automatically email validation details to a fixed recipient using a hard-coded SMTP credential.
Review before installing. Do not use this skill with sensitive JSON files unless email alerts are disabled or rebuilt to require explicit opt-in, configurable recipients, redaction, and secret-based configuration. The embedded SMTP credential should be revoked and removed, and imports should be made package-relative so validators load only from the installed skill.
scripts/check_data.py:44Hard-Coded SMTP Authentication Credential
scripts/check_data.py:165Automatic Transmission of Validation Data to a Fixed External Recipient
scripts/check_data.py:19Module Hijacking Through External Workspace Import Precedence
The skill is presented as a local data-quality checker, but the documentation also reveals outbound SMTP email alerts, fixed recipients/senders, and filesystem activity outside the core task. Undisclosed external transmission and broader local access materially expand the attack surface and can leak sensitive validation results or market data context to third parties.
The skill is presented as a local data-quality checker, but the documentation also reveals outbound SMTP email alerts, fixed recipients/senders, and filesystem activity outside the core task. Undisclosed external transmission and broader local access materially expand the attack surface and can leak sensitive validation results or market data context to third parties.
The skill is presented as a local data-quality checker, but the documentation also reveals outbound SMTP email alerts, fixed recipients/senders, and filesystem activity outside the core task. Undisclosed external transmission and broader local access materially expand the attack surface and can leak sensitive validation results or market data context to third parties.
The file embeds live SMTP configuration and an authentication secret directly in source code, while also enabling outbound email transmission. Hard-coded credentials are easily leaked through source control, logs, backups, or reuse across environments, and they provide a built-in channel for unauthorized external communication.
Automatic alert email transmission combined with hard-coded SMTP credentials is not disclosed through a clear user-facing safety notice or consent mechanism. In the context of a data-quality checker, this hidden network behavior increases the risk of silent data leakage and unauthorized use of embedded credentials.
The skill is presented as a local market-data quality checker, but it transmits alert content externally via SMTP. Those emails can include file paths and detailed validation issues, creating an unjustified data exfiltration path for potentially sensitive business or market data and violating least-privilege expectations for a local validation tool.
The skill documentation describes file-reading behavior but does not declare any explicit tool scope or permissions boundary. In an agent setting, missing scope declarations increase the chance of over-broad file access, unexpected data exposure, or misuse beyond the intended market_data.json target.
The skill advertises automatic alert emails without clearly warning that validation details may be transmitted externally. This undermines informed consent and can expose operational or market-sensitive data through outbound messaging that users may not expect from a local checker.
The configuration exposes fixed sender and recipient email addresses and SMTP details without a clear warning or consent flow for outbound communication. In context, this is more dangerous because the skill claims to be a data-quality tool, so users may not anticipate external transmission of potentially sensitive content or operational metadata.
Embedding hard-coded email alerting in documentation for a local validation skill introduces an unrelated exfiltration channel. Even if intended for operational alerting, fixed external recipients and mail infrastructure can send potentially sensitive data-quality failures, filenames, or business information outside the expected execution boundary.
The module title and descriptive text are written entirely in Chinese and describe the tool behavior without indicating any language choice or locale opt-in. This can violate language/locale policy when a skill implicitly enforces one language for user-visible behavior.
The docstring states the checker 'uniformly returns' results, but the implementation also performs side effects including persistent logging and external email alerts. This mismatch is security-relevant because operators or users may trust it as a pure local validation component, while it actually writes sensitive operational details to disk and can transmit them externally.
The file’s natural-language instructions, field names, and validation messages are exclusively in Chinese, indicating the checker is designed around a fixed Chinese-language schema and output style. There is no indication of user choice, opt-in, or documented region-specific justification for enforcing this locale, which matches the language/locale policy concern.
This Python file contains natural-language documentation entirely in Chinese, and the generated validation messages are also hard-coded in Chinese. Under the stated policy, forcing a specific language without user opt-in or documented locale justification is a language/locale policy violation.
The checker emits failure messages and categories only in Chinese, which constrains downstream user-visible output to a single language. The file does not provide any opt-in, fallback, or justification for this locale restriction.
The module docstring and user-facing rule descriptions are entirely in Chinese, and the file provides no indication that language choice is configurable or that the skill is intentionally limited to a Chinese-language environment. Per the policy, forcing a specific language without user opt-in is a natural-language policy violation.
The file’s natural-language descriptions and messages are entirely in Chinese, including the module docstring and validation rule text. Under the stated policy, forcing a specific language without user opt-in is a locale/language policy violation unless it is clearly documented as region-specific or optional, which is not present here.
This is a real validation flaw: ALLOWED_TYPES = (int, float) combined with isinstance(v, ...) will accept bool values because bool subclasses int in Python. In a market-data quality checker, True/False can silently pass as numeric values (1/0), undermining data integrity checks and potentially causing bad downstream decisions or false acceptance of malformed financial data.
The manifest description and trigger phrases are entirely in Chinese, which can amount to a language/locale constraint if the skill expects Chinese-only invocation. There is no indication that users may invoke it in other languages or that the Chinese-only scope is intentional and justified.
This code file's natural-language docstrings and operational descriptions are entirely in Chinese, including the skill name and validation rules, with no indication that another language is supported or that Chinese is a justified locale constraint. Under the policy, forcing a specific language without user opt-in can be a natural-language policy violation.
The module header says all required fields in market_data.json are checked and explicitly lists market metrics 'price / change / volume' as supported structure. However, in _check_market_null at L125-L135, only the 'price' field is enforced as non-empty; 'change' and 'volume' are iterated but never validated, contradicting the documented scope of the null check.
The class documentation states in line L025 that '政策/企业动态列表非空(允许空列表)', which is internally contradictory and implies list-oriented validation. In the implementation at L76-L94, the checker does not validate list non-emptiness at all; instead it accepts only dict-typed values for these fields, creating a clear documentation-to-code mismatch.
The module docstring is written entirely in Chinese, and the class docstring continues that language choice. Under the stated policy, forcing a specific language without user opt-in or a documented regional justification is a natural-language locale violation.
The file’s natural-language documentation and validation messages are written entirely in Chinese, including the class docstring and user-facing error text. This creates a locale-specific behavior without any visible opt-in or documented justification that the skill is intended only for Chinese-speaking users or a China-specific compliance context.
No suspicious patterns detected.