ClawHub
Back to skill

Security audit

Breach Check

Security checks for vulnerabilities and agentic risk

Overview

The skill does the advertised breach checking, but it leaves sensitive lookup destinations and privacy handling under-specified enough that users should review it before installing.

Install only if you are comfortable with the agent contacting breach-check services. For passwords, require the Pwned Passwords range API with only the first five SHA-1 hex characters sent. For email or phone checks, use only explicitly approved HTTPS endpoints and give consent before any plaintext identifier, full hash, or long hash prefix is transmitted. Avoid enabling periodic monitoring unless you understand where the data will be sent and how to disable it.

A.I.G

Vulnerability Patterns
  • Insecure Skill Coding PracticesFinds exploitable flaws such as hardcoded secrets or command injection
  • Skill Instruction HijackingAlters the agent's session goals or safety constraints when the skill loads
  • Agent Memory PoisoningWrites attacker-controlled rules into memory that affect later sessions
  • Remote Payload Retrieval and ExecutionFetches external code whose behavior can change after review
  • Embedded Malicious CodeShips malicious scripts inside the skill and executes them locally
Findings (1)

T09 · Insecure Skill Coding Practices

Warning
Location
SKILL.md:13
Finding

Unrestricted Third-Party Breach Lookup May Disclose Sensitive Identifier Hashes

Content
View full analysis

Vulnerability Details

File Location: SKILL.md:13
Vulnerability Type: Untrusted external service selection and insufficient protection of sensitive identifiers
Risk Level: Medium

Vulnerable Code Snippet:

markdown
2. **Query breach DB** — call Have I Been Pwned API v3 (or equivalent) with hash prefix. Respect rate limits (1.5s delay between calls).

Technical Analysis

The phrase or equivalent permits the agent or a future implementation to transmit hash prefixes to an unspecified external service. The Skill does not define an endpoint allowlist, required transport security, minimum privacy properties, retention restrictions, certificate validation requirements, or the precise prefix length for email and phone queries.

Unsalted SHA-256 hashes of email addresses and phone numbers are pseudonymous rather than reliably anonymous. Both identifier types can come from constrained or enumerable input spaces. A service receiving a full hash or sufficiently long prefix can hash candidate identifiers and compare the results, potentially recovering or narrowing down the original value. Query metadata, including IP address, timing, and repeated checks, can also support profiling.

The password workflow separately specifies the established five-character SHA-1 prefix model used by the Pwned Passwords range API. However, the Skill does not establish an equivalent verified k-anonymity protocol for email and phone lookups. Its broad instruction may therefore cause an implementation to use an incompatible API, disclose more identifier material than intended, or fall back to submitting plaintext identifiers despite the stated privacy guarantee.

Attack Path

  1. A user supplies an email address or phone number for a breach check.
  2. The Skill hashes the identifier according to its workflow.
  3. The agent selects an unspecified service under the permitted or equivalent clause.
  4. The hash, hash prefix, and asso ...[truncated 968 chars]
Remediation
View remediation

Remediation Suggestions

  1. Replace or equivalent with an explicit allowlist of reviewed HTTPS endpoints and exact API versions.
  2. Document the precise request format and privacy properties for each supported data type.
  3. Restrict the Pwned Passwords workflow to its documented range endpoint, sending only the first five hexadecimal characters of the SHA-1 password hash.
  4. Do not represent email or phone lookup as k-anonymous unless the selected service provides a specifically verified protocol for those identifiers.
  5. If a supported account-breach API requires a plaintext email address or phone number, obtain explicit user consent before transmission and clearly disclose the destination, data sent, purpose, and retention implications.
  6. Reject unapproved endpoints rather than selecting arbitrary “equivalent” services.
  7. Require TLS certificate validation, bounded timeouts, response-size limits, rate limiting, and strict response-schema validation.
  8. Avoid logging raw identifiers, complete hashes, request URLs containing sensitive values, or plaintext credentials.
  9. Separate password checking from account-identifier checking so the privacy guarantees of one protocol are not incorrectly applied to the other.

SkillSpector

Vulnerability Patterns
  • Prompt InjectionInstruction Override, Hidden Instructions, Exfiltration Commands
  • Data ExfiltrationExternal Transmission, Env Variable Harvesting, File System Enumeration
  • Privilege EscalationExcessive Permissions, Sudo/Root Execution, Credential Access
  • Supply ChainUnpinned Dependencies, External Script Fetching, Obfuscated Code
  • Excessive AgencyUnrestricted Tool Access, Autonomous Decision Making, Scope Creep

Static analysis

No suspicious patterns detected.