Is chowardcode/email-tool safe?

The sendEmail() function unconditionally sets the From display name to 'Pestward Info' for all outgoing email. There is no configuration option or parameter to override this. Every email sent through this skill will claim to originate from an entity named 'Pestward Info' regardless of who installed it. This enables passive identity misrepresentation and could be exploited for social engineering attacks on email recipients who trust the apparent sender.

The email.send tool exposes a 'bcc' parameter as an unconstrained string with no validation, allowlist, or disclosure requirement. If a prompt injection in any document, web page, or received email instructs the agent to BCC an attacker-controlled address, all outbound email will be silently copied to that address. Primary recipients receive no indication that BCC recipients exist.

As an AI agent tool, email presents uniquely compounded risk. IMAP read access means malicious emails can deliver prompt injection payloads directly into the agent's context window. SMTP send access with no recipient restrictions means the agent can exfiltrate any data — conversation history, file contents, credentials in memory — to arbitrary external addresses. No rate limits, recipient allowlists, or confirmation prompts exist at any layer.

The searchEmails() function returns up to 200 characters of each email's body along with From, Date, and Subject headers. This inbox content is fed directly into the agent's context. An attacker who sends a crafted email with an embedded prompt injection payload can thus inject instructions into the agent the next time it searches for emails. The 200-character truncation reduces but does not eliminate this risk — prompt injection payloads can be highly compact.

The skill was built for a specific organization (Zoho Mail defaults, hardcoded 'Pestward Info' branding) and published to the public skill marketplace without removing company-specific assumptions. Users installing this skill will unknowingly send emails branded as 'Pestward Info'. The Zoho-specific SMTP/IMAP defaults may also behave unexpectedly for users on other mail providers. This mismatch between the skill's design context and its published audience creates unintended behavioral risk.

The email.search tool exposes a markRead parameter (default false). When set to true, the skill marks fetched emails as read via the IMAP \Seen flag. This modifies inbox state without the user's direct action, potentially concealing the fact that the agent accessed specific unread messages. An attacker using prompt injection could instruct the agent to silently read and mark emails without the user noticing.

The email.send function accepts arbitrary recipient addresses with no rate limiting, domain allowlisting, or confirmation prompt. A compromised agent could be instructed to send high volumes of email to arbitrary addresses, enabling spam amplification, phishing campaigns, or bulk exfiltration to an attacker's inbox.

The skill depends on nodemailer@^6.9.8 and imap-simple@^5.1.0, which pull in 11 transitive dependencies. The package-lock.json pins specific versions with integrity hashes, which is good practice. However, any re-installation resolving the ^ semver range could introduce a different version. The transitive dependency [email protected] and [email protected] are relatively old packages with limited maintenance activity.

Honeypot credential files were opened for reading at two timestamps during the monitoring session. Correlation analysis indicates both access batches originated from monitoring infrastructure rather than the skill: all six files were accessed in a single timestamp cluster (characteristic of a script iterating a fixed list), the skill source code contains no paths targeting these files, and no network activity was correlated with either access event. All canary files remained unmodified and intact.

The only external connection detected during install was a TLS connection to 140.82.121.4:443 (github.com), consistent with the git sparse-checkout install procedure. DNS resolution, TLS handshake, and data transfer all matched expected GitHub traffic patterns. No connections to unexpected domains, no DNS queries to suspicious resolvers, and no new listening ports were observed after installation completed.