Back to skill

Security audit

Bounty Hunter Pro

Security checks for vulnerabilities and agentic risk

Overview

This bug-bounty scanning skill is mostly coherent, but it needs Review because it combines autonomous network scanning with weak scope enforcement, cloud analysis of possible secrets, unverified tool installation, and unattended cron persistence.

Install only if you are comfortable reviewing and tightening the workflow first: use exact hostname/domain-boundary authorization, verify scanner tool provenance and hashes, keep secret analysis local or redact before cloud use, and avoid the cron job unless you add expiry, logging, and removal steps.

Vulnerability Patterns
  • System PersistenceInstalls backdoors, hooks, services, or scheduled tasks that survive the run
  • Insecure DependenciesIntroduces malicious components through unsafe dependency sources
  • 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
Findings (4)

T09 · Insecure Skill Coding Practices

Error
Location
SKILL.md:121
Finding
Authorization Check Permits Out-of-Scope Targets## Vulnerability Details **File Location**: `SKILL.md`, lines 121-128 **Vulnerability Type**: Authorization boundary bypass caused by unsafe suffix matching **Risk Level**: High **Vulnerable Code:** ```python # ALWAYS check before scanning def is_authorized(target): with open("authorized_targets.txt") as f: authorized = [line.strip() for line in f] return any(target.endswith(auth) or target == auth for auth in authorized) # FAIL SAFE if not is_authorized(target): raise ValueError(f"UNAUTHORIZED: {target} not in authorized_targets.txt") ``` ### Technical Analysis The authorization function uses unrestricted string suffix matching. If `example.com` is authorized, an unrelated hostname such as `attacker-example.com` also satisfies `target.endswith("example.com")`. The documented wildcard syntax is also not implemented correctly. An entry such as `*.example.com` is treated as a literal suffix rather than as a controlled wildcard expression. The function additionally does not show hostname parsing, canonicalization, internationalized-domain-name handling, trailing-dot normalization, or rejection of URLs containing user information, ports, and paths. The check therefore fails to establish a proper DNS label boundary between the requested target and an authorized base domain. ### Attack Path 1. Add `example.com` to `authorized_targets.txt`. 2. Request a scan of an unrelated hostname such as `attacker-example.com`. 3. The expression `target.endswith("example.com")` evaluates to true. 4. The fail-safe exception is not raised. 5. The scanner proceeds against a target outside the intended authorization scope. ### Impact Assessment An operator or attacker able to supply the scan target can cause subdomain enumeration, endpoint probing, JavaScript analysis, and vulnerability scanning against unauthorized infrastructure. This does not directly grant local operating-system privileges, but it bypa ...[truncated 131 chars]
Remediation
## Remediation Suggestions - Parse input as a hostname instead of comparing arbitrary strings or complete URLs. - Convert hostnames to lowercase, remove a single trailing dot, and normalize internationalized domain names consistently. - Reject credentials, paths, query strings, fragments, malformed labels, and unexpected ports before authorization. - For a base domain, require either exact equality or a dot-delimited subdomain boundary: ```python target == authorized_domain or target.endswith("." + authorized_domain) ``` - Parse wildcard entries explicitly. Permit only a documented form such as `*.example.com`, and translate it into a label-aware comparison. - Ignore blank lines and comments in the authorization file. - Log the normalized target, matched scope entry, authorization decision, and current authorization expiry. - Add negative tests for `attacker-example.com`, `example.com.attacker.net`, trailing-dot variants, mixed case, and malformed URLs.

other

Error
Location
SKILL.md:27
Finding
Potential Disclosure of Discovered Secrets to a Cloud LLM## Vulnerability Details **File Location**: `SKILL.md`, lines 27-38 **Vulnerability Type**: Sensitive data exposure through external analysis **Risk Level**: High **Relevant Skill Configuration:** ```markdown ### 1. nightwatch.py — Scanner - Certificate Transparency (crt.sh) for subdomains - JS file analysis for secrets - Multi-threaded (10 workers default) - Outputs to `findings_incremental.json` ### 2. analyze_daemon.py — Analyzer - Watches `findings_incremental.json` - Entropy filtering to reduce false positives - Two-stage LLM analysis: - Fast: qwen2.5-coder:1.5b - Deep: glm-5:cloud - Outputs to `live_analysis.md` ``` ### Technical Analysis The documented workflow scans JavaScript for secrets, writes findings to `findings_incremental.json`, and subjects findings to two-stage LLM analysis. The deep-analysis model is explicitly identified as `glm-5:cloud`. The Skill does not document redaction or tokenization of discovered credentials before cloud submission. It also does not define user consent, endpoint restrictions, transport requirements, data-retention controls, tenant isolation, or a prohibition against sending raw target source code and credentials externally. Because the referenced analyzer implementation is absent from the audited project, the exact request payload and endpoint cannot be verified. Nevertheless, the documented design creates a direct risk that sensitive findings will cross the local trust boundary. ### Attack Path 1. The scanner retrieves JavaScript from an authorized target. 2. Secret detection identifies a token, API key, credential, or other sensitive value. 3. The raw finding is written to `findings_incremental.json`. 4. `analyze_daemon.py` reads the finding for deep analysis. 5. If the documented cloud stage receives the raw finding, the secret and associated target context are transmitted to an external service. 6. The data may then be processed or retained out ...[truncated 535 chars]
Remediation
## Remediation Suggestions - Make local-only analysis the default for all findings that may contain secrets. - Detect and replace secret values with stable placeholders before any external request. - Send only the minimum metadata needed for classification; do not send raw credentials or complete source files. - Require explicit, informed operator approval before enabling cloud analysis. - Document and enforce approved model endpoints, TLS requirements, authentication, retention periods, data residency, and provider training opt-out settings. - Apply an outbound network allowlist to the analyzer. - Encrypt findings at rest and restrict permissions on `findings_incremental.json` and `live_analysis.md`. - Add audit logs that record what categories of data were transmitted without logging the secret values themselves. - Supply `analyze_daemon.py` for review and add tests proving that secret material cannot enter cloud-bound payloads.

T08 · Insecure Dependencies

Error
Location
SKILL.md:44
Finding
Scanner Archives Are Extracted Without Provenance or Integrity Verification## Vulnerability Details **File Location**: `SKILL.md`, lines 44-55 **Vulnerability Type**: Unverified third-party executable dependencies **Risk Level**: High **Vulnerable Setup Instructions:** ```bash # Install tools cd ~/workspace/bounty_hunting/tools unzip subfinder.zip unzip httpx.zip unzip nuclei.zip # Configure authorized targets echo "example.com" > ~/workspace/bounty_hunting/authorized_targets.txt echo "*.example.com" >> ~/workspace/bounty_hunting/authorized_targets.txt ``` ### Technical Analysis The setup extracts three archives expected to contain security-scanning executables, but it does not specify trusted download locations, pinned versions, cryptographic checksums, release signatures, or post-extraction validation. File names such as `subfinder.zip`, `httpx.zip`, and `nuclei.zip` do not establish provenance. A substituted archive can contain modified tools or additional files. Extraction into a predictable tool directory also creates archive path-traversal or overwrite risk if an archive contains unsafe paths and the extraction utility does not prevent them. The provided commands do not themselves download or execute the archives. Exploitation therefore depends on an attacker or compromised distribution channel being able to supply or replace one of the expected files before installation or later execution. ### Attack Path 1. An attacker compromises the source, transfer path, or writable directory used to obtain the scanner archive. 2. The attacker places a modified archive under an expected name such as `nuclei.zip`. 3. The operator follows the documented setup instructions without verifying a signature or checksum. 4. The malicious executable is extracted into `~/workspace/bounty_hunting/tools`. 5. A later scan invokes the substituted tool as though it were legitimate. 6. The executable runs with the permissions of the scanning account and can access its files, findings, credentials, and ...[truncated 390 chars]
Remediation
## Remediation Suggestions - Specify official HTTPS release URLs and pin exact tool versions. - Publish and verify SHA-256 or stronger checksums before extraction. - Verify vendor signatures or attestations where available. - Download into a newly created, permission-restricted staging directory. - Inspect archive paths before extraction and reject absolute paths, parent-directory traversal, symlinks, and unexpected files. - Extract each tool into an isolated versioned directory rather than a shared writable directory. - Validate the resulting executable identity and permissions before invocation. - Prevent untrusted users from writing to the tool directory. - Record dependency versions and hashes in a lock file or software bill of materials. - Prefer a trusted package manager or reproducible build process when supported.

T06 · System Persistence

Warning
Location
SKILL.md:131
Finding
Daily Cron Entry Creates Unattended Cross-Session Scanning Persistence## Vulnerability Details **File Location**: `SKILL.md`, lines 131-136 **Vulnerability Type**: Persistent scheduled execution **Risk Level**: Medium **Persistent Execution Configuration:** ```bash # Daily scan at 2am (low-traffic time) 0 2 * * * cd ~/workspace/bounty_hunting && python nightwatch.py ``` ### Technical Analysis The Skill instructs the operator to create a cron schedule that executes `nightwatch.py` every day. The task survives completion of the initiating session and runs unattended. The documentation does not require explicit persistence consent, provide removal instructions, define an expiration date, or demonstrate that authorization is revalidated against current scope immediately before every scheduled scan. The referenced `nightwatch.py` file is absent, so its actual safety checks cannot be confirmed. The relative command `python nightwatch.py` also relies on environment-dependent interpreter resolution and a user-writable script path. If the script or relevant execution environment is modified, cron will execute the changed content on the next run. ### Attack Path 1. The operator installs the documented cron entry. 2. The initiating audit or bounty-hunting session ends, but the cron entry remains active. 3. Program authorization expires, target scope changes, or `nightwatch.py` is replaced in the writable workspace. 4. At 2:00 a.m., cron executes the current script without interactive confirmation. 5. Scanning may continue outside the current authorization period, or modified code may run with the cron owner's privileges. ### Impact Assessment The scheduled task obtains repeated code execution as the account that owns the cron entry. It can continue network scanning and access files available to that account across sessions. No root-level installation is shown, but unattended execution increases the duration and reach of any scope error or later script compromise.
Remediation
## Remediation Suggestions - Require explicit operator consent before installing any scheduled task. - Default to one-time execution rather than persistent scheduling. - Revalidate normalized target scope, authorization status, and authorization expiry immediately before every scheduled scan. - Disable scanning automatically when the authorization record expires or cannot be verified. - Use an absolute, pinned interpreter path and an immutable or integrity-checked script path. - Run under a dedicated least-privileged account with restricted filesystem and network access. - Add rate limits, execution timeouts, locking to prevent overlapping jobs, and comprehensive audit logging. - Provide exact commands for listing and removing the cron entry. - Prefer a managed scheduler with explicit ownership, expiry, monitoring, and revocation controls. - Supply `nightwatch.py` for security review before enabling recurring execution.
Vulnerability Patterns
  • Trigger AbuseOverly Broad Trigger, Shadow Command Trigger, Keyword Baiting Trigger
  • 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
Findings (1)

Vague Triggers

Medium
Confidence
90% confidence
Finding
The usage prompt is broadly phrased as 'Run bounty hunt on [TARGET]' and then directs multi-stage scanning, which creates a low-friction trigger for offensive security actions. Although the file includes scope-safety language, the invocation pattern is still permissive and could be reused with attacker-supplied targets or in contexts where authorization is not independently enforced, leading to unauthorized reconnaissance or scanning.

Static analysis

No suspicious patterns detected.