T09 · Insecure Skill Coding Practices
- Location
v2ex_monitor.py:78- Finding
Authenticated API Requests Disable TLS Certificate Verification
- Content
View full analysis
- Remediation
View remediation
Security audit
Security checks for vulnerabilities and agentic risk
This V2EX monitoring skill is mostly purpose-aligned, but it handles the user's API key unsafely enough that it should be reviewed before installation.
Install only if you are comfortable giving the skill a V2EX API token and storing that token locally. Prefer using a limited/revocable token, avoid running it on untrusted networks until TLS verification is fixed, and treat any token used with this version as potentially exposed if MCP outputs or logs are retained.
v2ex_monitor.py:78Authenticated API Requests Disable TLS Certificate Verification
v2ex_mcp.py:307MCP Configuration Response Discloses the Complete API Key
v2ex_monitor.py:172API Key Is Persisted in a Plaintext Configuration File Without Explicit Access Restrictions
requirements.txt:1Third-Party Dependencies Are Installed Without Version or Integrity Pinning
This code disables both certificate verification and hostname checking for HTTPS requests made via urllib3 by setting check_hostname to False and verify_mode to ssl.CERT_NONE. That allows a man-in-the-middle attacker to intercept or modify API responses and capture the Bearer API key, which is especially risky because the tool authenticates to a remote service and trusts returned JSON.
The documentation instructs users to supply a V2EX API key and use features that retrieve notifications and account-linked information, but it does not clearly warn that the key will be transmitted to V2EX and that account-specific data will be fetched and stored locally. This can lead users to expose sensitive credentials or personal account data without informed consent, especially when the skill is integrated into higher-automation agent environments.
The module docstring and all user-facing CLI descriptions are written only in Chinese, which imposes a specific language on users without any opt-in or alternative locale support. Under the policy, forcing a specific language without user choice is a natural-language policy violation.
The natural-language descriptions and user-facing strings in this file are entirely in Chinese, with no indication that language is configurable or intentionally restricted to a Chinese-only audience. Under the language/locale policy, forcing a specific language without opt-in can be a policy violation.
The tool dispatcher calls get_client() before checking which tool was requested, so even the v2ex_config tool cannot run unless an API key is already present. This creates a denial-of-service/bootstrap failure for the skill's own configuration path and can prevent recovery or first-time setup.
The v2ex_config tool persists the API key in a JSON file on disk in plaintext, with no warning, no file permission hardening, and no safer secret-storage option. Any local user, backup system, log collector, or later-compromised process with access to that directory could recover the token and use it to access the user's V2EX account data.
The API key is stored in plaintext in a local JSON config file without warnings, permission hardening, or use of a secure secret store. On multi-user systems, shared workstations, backups, or compromised local accounts, this can expose the credential and allow unauthorized access to the V2EX account or API usage.
The natural-language instructions, headings, usage guidance, and warnings are all presented in Chinese, which effectively forces a specific language for users of the skill. There is no opt-in, alternate language option, or explanation that the skill is intended only for a Chinese-language audience or region-specific use case.
The dependency 'urllib3' is unpinned, so builds may resolve to different versions over time, including versions with known security defects or breaking behavior. In a security-sensitive skill, this weakens supply-chain integrity and makes it impossible to verify whether a safe version is consistently installed.
urllib3
mcp
pydantic
requests
The manifest does not pin a version for 'urllib3', and the package has multiple known advisories, so the actual installed version may be vulnerable without any visibility from this file alone. Because urllib3 is a core HTTP client component, affected versions could expose the skill to request handling flaws, credential leakage, or denial-of-service conditions depending on runtime usage.
The dependency 'mcp' is unpinned, which allows environment-dependent resolution to potentially vulnerable or incompatible releases. Because MCP-related packages may expose protocol/server behavior, lack of version control increases uncertainty and supply-chain risk.
urllib3
mcp
pydantic
requests
The 'mcp' package is unpinned despite multiple known advisories, and MCP libraries can directly influence server/client protocol security behavior. If an affected version is installed, the skill could inherit vulnerabilities such as access control weaknesses, DNS rebinding exposure, or validation flaws that materially increase attack surface.
The dependency 'pydantic' is unpinned, so installations are not reproducible and may pull in vulnerable or behavior-changing releases. This is a common dependency hygiene issue that can enable avoidable exposure when upstream security issues are disclosed.
urllib3
mcp
pydantic
requests
The manifest leaves 'pydantic' unpinned even though there are known advisories affecting some versions, making the deployed security posture unverifiable. If an affected release is installed, the skill may be exposed to denial-of-service or parsing/validation-related bugs depending on how user input is processed.
The dependency 'requests' is unpinned, allowing future installs to resolve unpredictably and potentially include versions affected by known vulnerabilities. For networking libraries, this creates unnecessary risk because security posture can change without code changes.
urllib3
mcp
pydantic
requests
The 'requests' dependency is unpinned while multiple known advisories exist, so this requirements file cannot demonstrate that a non-vulnerable version will be installed. Since requests often handles outbound HTTP, affected versions may enable credential leakage, TLS-related issues, or unsafe URL handling in downstream code.
This markdown file states that data will be stored in a local v2ex_monitor_data/ directory, which affects user data on disk. The description does not include any warning or disclosure about what is retained, how long it persists, or that running the skill will create local files in the working directory.
The tool descriptions for v2ex_get_notifications and v2ex_get_my_info indicate retrieval of current-user notifications and personal information, which are privacy-relevant remote API operations. The file contains no user-facing warning or disclosure about accessing account-specific data beyond the functional description.
The file's natural-language interface and generated output are entirely in Chinese, including descriptions, status messages, and report content. Because the skill does not offer a language selection or document a justified locale restriction, it violates the language/locale policy described for this audit.