T09 · Insecure Skill Coding Practices
- Location
scripts/find_emails.py:54- Finding
TLS Certificate Validation Disabled for All HTTPS Requests
- Content
View full analysis
- Remediation
View remediation
Security audit
Security checks for vulnerabilities and agentic risk
This skill does what it advertises, but it actively discovers and verifies personal email addresses in ways users should review carefully before installing.
Install only if you are comfortable with a tool that contacts websites, DNS, Google, hunter.io, and recipient mail servers to find and verify email addresses. Use it only for authorized, targeted lookups, prefer --no-verify unless SMTP probing is necessary, and avoid using it to build unsolicited outreach lists or guess personal addresses without a legitimate basis.
scripts/find_emails.py:54TLS Certificate Validation Disabled for All HTTPS Requests
scripts/find_emails.py:286Unvalidated Target Domain Permits Requests to Unintended Network Services
SKILL.md:22Unpinned Third-Party Dependency Installation
The skill clearly performs network actions including web scraping, DNS lookups, search queries, and SMTP recipient verification, but it declares no explicit tool scope or permission boundary. That mismatch can let the skill be invoked with broader network capability than users or policy expect, reducing visibility and control over outbound interactions with third-party systems.
The description is framed broadly around prospecting leads, outreach, and building contact lists, which can cause the skill to be selected for common business requests without sufficient scrutiny. Because the skill performs personal data discovery and active verification against mail servers, broad invocation language increases the chance of privacy-invasive or policy-violating use in routine workflows.
The skill explicitly supports generating likely personal email addresses from a person's name and verifying them via SMTP, but the description lacks a clear privacy, consent, and anti-harassment warning. In context, this makes the capability more dangerous because it facilitates identifying and validating personal contact data for outreach or targeting, which can enable spam, stalking, or unauthorized profiling.
The search and scraping logic sends requests containing the target domain to external sites, including Google and hunter.io, without clearly warning that target information will be disclosed to third parties. In a lead-generation/email-finding skill this is especially sensitive because the queried domains and patterns can reveal prospecting targets, investigations, or internal workflow, creating privacy and operational exposure.
The script performs active SMTP RCPT probing against third-party mail servers, which discloses the operator's interest in specific domains and guessed addresses and may trigger logging, blocking, or abuse responses. In this skill context, email enumeration and validation are core features, so the behavior is intentional, but the lack of explicit warning/consent and the default-on verification make the privacy and policy risk materially higher.
The docstring states that, because web_search is unavailable, the function will 'try common directories.' However, the implementation constructs outbound requests to a Google search URL and a hunter.io domain-search endpoint instead of directory pages. This is a direct contradiction between documentation and behavior, not merely omitted detail.
The CLI defines '--verify' as a store_true flag with default=True, so it does not meaningfully enable anything that was disabled; verification is actually governed by 'do_verify = not args.no_verify'. This makes the documented behavior of the '--verify' option misleading relative to the code's actual control flow.
No suspicious patterns detected.