Back to skill

Security audit

headhunter-pro

Security checks for vulnerabilities and agentic risk

Overview

This recruiting skill is broadly coherent, but it understates network, credential, persistence, and sensitive candidate-data behavior enough that users should review it before installing.

Install only after narrowing permissions and operating rules: remove workspace memory access, avoid broad GitHub tokens, verify and pin any helper skills, do not enable cron or automated candidate messaging without separate informed approval, and minimize candidate data to job-relevant fields with clear consent, retention, and deletion practices.

Vulnerability Patterns
  • Unauthorized Access and Privilege EscalationObtains permissions beyond the task's legitimate needs
  • 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 (6)

T05 · Unauthorized Access and Privilege Escalation

Error
Location
skill.yml:45
Finding
Excessive access to agent memory and overprivileged GitHub credentials<![CDATA[ ## Vulnerability Details **File Location**: `skill.yml:45-48`; related credential guidance at `SKILL.md:858-860` **Vulnerability Type**: Least-privilege violation **Risk Level**: High ### Vulnerable Code Snippet ```yaml permissions: file_access: read: ["workspace/candidates/**", "workspace/memory/*.md"] write: ["workspace/candidates/*/profile.md", "workspace/candidates/*/recommendation.md"] ``` Related GitHub authentication guidance: ```bash # Method 1: GitHub Personal Access Token # Generate a token with the recommended scopes: repo, read:user export GITHUB_TOKEN="your_personal_access_token" # Method 2: GitHub CLI login gh auth login ``` The comments above are faithful English renderings of the source instructions. ### Technical Analysis The Skill requests read access to `workspace/memory/*.md`, although its declared purpose is candidate screening, recommendation writing, outreach generation, interview assessment, client management, and talent mapping. General agent memory is not necessary to perform those tasks. The Skill also recommends a GitHub personal access token with `repo` and `read:user` scopes. The classic `repo` scope can expose private repositories and grants substantially broader repository access than is needed to search public repositories or inspect public contributor activity. The combination is particularly risky because the Skill also recommends multiple GitHub helper Skills. A compromised or overly broad helper could inherit the exported token and use it to access private repositories. ### Attack Path 1. A user enables the Skill with the permissions declared in `skill.yml`. 2. The Skill or a dependency reads unrelated persistent state from `workspace/memory/*.md`. 3. The user follows the GitHub setup instructions and exports a token with `repo` scope. 4. A GitHub helper process inherits `GITHUB_TOKEN`. 5. The helper uses the token to enumerate or read private repositories beyond the recruitment task’s legitim ...[truncated 699 chars]
Remediation
<![CDATA[ ## Remediation Suggestions 1. Remove `workspace/memory/*.md` from the Skill’s read permissions. 2. Restrict file access to the specific candidate records supplied for the current task. 3. Use a fine-grained GitHub token limited to explicitly selected repositories. 4. Grant only read-only metadata or content permissions required for a defined workflow. 5. Do not request the classic `repo` scope for public contributor searches. 6. Avoid exporting credentials into a general shell environment. Pass credentials only to the specific trusted process that requires them. 7. Document credential lifetime, revocation, rotation, and storage requirements. 8. Prevent third-party helper Skills from automatically inheriting GitHub credentials unless separately approved. ]]>

T08 · Insecure Dependencies

Error
Location
SKILL.md:849
Finding
Unverified and unpinned third-party Skill dependencies<![CDATA[ ## Vulnerability Details **File Location**: `SKILL.md:849-854` **Vulnerability Type**: Untrusted Skill supply chain **Risk Level**: High ### Vulnerable Code Snippet ```text Install GitHub Skills: - github-cli — comprehensive GitHub CLI operations - github-search — deep repository search and analysis - openclaw-github-assistant — repository, issue, and CI management - github-workflow — Actions and pull-request workflows - github-actions-generator — CI/CD scenario generation ``` This is a faithful English rendering of the source list. ### Technical Analysis The Skill recommends installing five executable third-party Skills using only generic package names. It does not provide: - Authoritative registry identifiers or source repositories. - Trusted publisher identities. - Exact versions or immutable commit hashes. - Integrity hashes or signatures. - A permission and behavior review for each dependency. Generic names such as `github-search` and `github-workflow` are susceptible to name collision, package substitution, and typosquatting. Some recommended components also provide repository, issue, CI, and workflow management capabilities that exceed the read-only requirements of candidate discovery. The danger is amplified by nearby instructions recommending an exported GitHub token with private-repository scope. ### Attack Path 1. A user follows the prerequisite instructions and searches a registry for one of the listed names. 2. The package name resolves to a malicious, substituted, or compromised Skill. 3. The package is installed without a verified publisher, version, or integrity check. 4. The dependency runs with access to the Skill environment. 5. It obtains candidate data, workspace files, or an inherited `GITHUB_TOKEN`. 6. It accesses private repositories, modifies GitHub resources, or transmits sensitive information. ### Impact Assessment A malicious dependency could potentially obtain: - The current user’s GitHub token and its associa ...[truncated 411 chars]
Remediation
<![CDATA[ ## Remediation Suggestions 1. Remove dependencies that are not essential to the declared recruitment workflows. 2. Identify every dependency using a fully qualified registry or repository identifier. 3. Pin each dependency to a reviewed version or immutable commit. 4. Publish trusted maintainer identities, checksums, and signature-verification instructions. 5. Audit each dependency’s code, network behavior, requested permissions, and credential access. 6. Prefer a single read-only GitHub integration over multiple administration and CI-oriented Skills. 7. Isolate dependencies in a sandbox without access to agent memory or candidate files by default. 8. Do not expose GitHub credentials until the selected dependency has been independently verified and explicitly authorized. ]]>

T08 · Insecure Dependencies

Warning
Location
SKILL.md:3751
Finding
Unpinned runtime package installation with unconditional upgrades<![CDATA[ ## Vulnerability Details **File Location**: `SKILL.md:3751-3755` **Vulnerability Type**: Mutable Python dependency installation **Risk Level**: Medium ### Vulnerable Code Snippet ```bash # Method 1: Hugging Face Transformers pip install --upgrade transformers torch torchaudio soundfile ``` The comment is a faithful English rendering of the source instruction. ### Technical Analysis The command installs or upgrades four Python packages without exact versions, hashes, or a lockfile. It also allows mutable transitive dependencies to be selected at installation time. Python package installation can execute build-system and installation logic. Consequently, a compromised future release, dependency-confusion event, or malicious package retrieved from a misconfigured index could execute code with the invoking user’s privileges. The unconditional `--upgrade` option may also replace versions that were previously reviewed and validated by the host environment. ### Attack Path 1. A user follows the voice-workflow installation guide. 2. `pip` resolves the latest available versions from its configured package indexes. 3. A compromised release, malicious index entry, or unsafe transitive dependency is selected. 4. Package build or installation logic executes locally. 5. The package gains the invoking process’s filesystem and network access. 6. The affected environment may then expose candidate data or become unstable due to incompatible upgrades. ### Impact Assessment Potential impact includes: - Arbitrary code execution with the privileges of the user running `pip`. - Access to candidate records and other files readable by that user. - Exposure of environment variables or credentials. - Replacement of trusted packages with incompatible or compromised releases. - Availability failures in other applications sharing the same Python environment. ]]>
Remediation
<![CDATA[ ## Remediation Suggestions 1. Create a dedicated virtual environment or container for the voice workflow. 2. Pin all direct and transitive dependencies to reviewed versions. 3. Use a lockfile containing cryptographic hashes. 4. Install with hash enforcement, such as `pip install --require-hashes`. 5. Configure an explicitly trusted package index and disable unintended supplemental indexes. 6. Remove unconditional `--upgrade` behavior from end-user instructions. 7. Scan packages and container images before distribution. 8. Document tested Python, operating-system, and accelerator versions. 9. Run model processing without access to unrelated candidate records or credentials. ]]>

T05 · Unauthorized Access and Privilege Escalation

Error
Location
SKILL.md:3672
Finding
Persistent scheduled monitoring and automated messaging exceed declared permissions<![CDATA[ ## Vulnerability Details **File Location**: `SKILL.md:3672-3687`; conflicting manifest declarations at `skill.yml:50-56` **Vulnerability Type**: Undeclared persistence and external communication **Risk Level**: High ### Vulnerable Code Snippet ```text OpenClaw recruiter workflow automation Night monitoring: The agent monitors GitHub, LinkedIn, and hiring boards at night and sends candidate summaries in the morning. Setup method: use cron scheduled tasks. - Scan candidate LinkedIn activity once per week. - Automatically notify the recruiter when hiring signals are found. Automatic candidate follow-up: Automatically follow up with candidates through WhatsApp, Telegram, or WeChat. State tracking: - Record every communication in the candidate profile. - Automatically determine follow-up timing. - Select a communication strategy based on candidate classification tags. ``` This is a faithful English rendering of the source instructions. The manifest states: ```yaml connectors: [] external_api: false limitations: - "Cannot access real-time data from external recruiting platforms." - "Candidate contact details must be manually provided by the user." ``` The quoted limitation text is translated into English. ### Technical Analysis The operational instructions direct users to create cron-based monitoring that survives the initiating Skill run. They also describe access to LinkedIn, GitHub, hiring boards, WhatsApp, Telegram, and WeChat. These behaviors conflict with the manifest’s declarations that the Skill has no connectors, uses no external APIs, and cannot access real-time recruiting-platform data. The package does not define authorization, credential handling, audit logging, rate limiting, data retention, consent, or removal procedures for the scheduled tasks. Although the source does not contain a cron command that automatically installs a job, it explicitly instructs the user to establish persistent scheduled execution. That persistence ...[truncated 1233 chars]
Remediation
<![CDATA[ ## Remediation Suggestions 1. Remove the cron, night-monitoring, and automatic-messaging instructions from the default Skill. 2. If persistence is an intended feature, declare it explicitly in the manifest and require separate informed consent. 3. Declare every external platform, connector, API, and destination domain. 4. Require human approval before every outbound candidate message. 5. Use narrowly scoped, revocable credentials for each external platform. 6. Add audit logs showing task creation, execution, data access, and outbound actions. 7. Define rate limits, quiet hours, candidate opt-out controls, and consent requirements. 8. Provide explicit commands and documentation to list, disable, and remove every scheduled task. 9. Establish retention and deletion limits for monitoring data. 10. Keep persistent workers isolated from agent memory and unrelated candidate records. ]]>

T05 · Unauthorized Access and Privilege Escalation

Error
Location
SKILL.md:977
Finding
Cross-platform contact inference contradicts the candidate-data boundary<![CDATA[ ## Vulnerability Details **File Location**: `SKILL.md:977-988`; related instructions at `SKILL.md:886` and `SKILL.md:1064` **Vulnerability Type**: Undeclared collection and correlation of personal contact information **Risk Level**: High ### Vulnerable Code Snippet ```text Calyflow six-step automated GitHub sourcing: 1. Research target repositories and determine the target candidate profile. 2. Find repositories using GitHub search. 3. Extract maintainers and top contributors. 4. Find contact information by inferring it from profiles, commit email addresses, and linked social accounts. 5. Score and rank candidates by commits, stars, pull-request quality, and technical fit. 6. Automatically generate a candidate brief containing GitHub data and matching analysis. ``` This is a faithful English rendering of the source instructions. The manifest separately states: ```yaml limitations: - "Candidate contact details must be manually provided by the user." ``` ### Technical Analysis The workflow directs the Skill to enumerate public contributors, extract commit email addresses, correlate linked social identities, infer contact information, score individuals, and generate candidate records. That behavior directly contradicts the declared limitation that candidate contact details must be supplied manually by the user. It also creates a privacy-sensitive identity-resolution pipeline that combines information from multiple platforms without a documented consent or lawful-purpose check. Commit email addresses may be technically public while still being published for source-control attribution rather than recruiting outreach. Cross-platform correlation increases the sensitivity of the resulting profile. ### Attack Path 1. The workflow searches repositories associated with a target technology. 2. It enumerates maintainers and high-frequency contributors. 3. It inspects profiles and commit metadata for email addresses. 4. It follows linked acco ...[truncated 770 chars]
Remediation
<![CDATA[ ## Remediation Suggestions 1. Remove commit-email harvesting and inferred contact discovery from the workflow. 2. Accept contact information only when manually supplied by an authorized user or explicitly provided by the candidate for recruitment. 3. Do not correlate identities across platforms without documented consent and lawful purpose. 4. Separate technical proof-of-work analysis from contact discovery. 5. Add provenance metadata for every retained candidate field. 6. Define retention periods and provide deletion and opt-out procedures. 7. Prevent inferred data from being written to persistent candidate profiles by default. 8. Require a human privacy review before any outreach based on publicly discovered information. 9. Align `SKILL.md` behavior with the limitations and permission declarations in `skill.yml`. ]]>

T09 · Insecure Skill Coding Practices

Warning
Location
implementation/prompt-template.md:45
Finding
Sensitive demographic and family-status data included in candidate reports without minimization controls<![CDATA[ ## Vulnerability Details **File Location**: `implementation/prompt-template.md:45-48`; related profiling guidance at `SKILL.md:210` and `SKILL.md:670` **Vulnerability Type**: Unsafe processing and persistence of sensitive personal data **Risk Level**: Medium ### Vulnerable Code Snippet ```text First section: Basic information - Date of birth, gender, marital status, location, educational institution, and language ability. - Include these fields when provided; otherwise omit them. ``` This is a faithful English rendering of the source instructions. Related candidate-profile guidance includes: ```text - Build candidate profiles using age, education, tenure, level, and project experience. - Record age band, family status, and location. ``` ### Technical Analysis The Skill directs recommendation reports and candidate profiles to include date of birth, gender, marital or family status, age, and location. These attributes are unnecessary for most skills-based recruitment evaluations and can expose candidates to discriminatory decision-making. The instruction to include the data whenever it is provided is not an adequate security or privacy control. The package does not specify: - A necessity or proportionality assessment. - Candidate consent. - Field-level access restrictions. - Redaction from generated reports. - Retention and deletion periods. - A prohibition on using protected attributes in scoring. Because the manifest allows candidate profiles and recommendation reports to be written to persistent files, these fields may remain available after the immediate task concludes. ### Attack Path 1. A resume or user input contains age, date of birth, gender, marital status, or family information. 2. The prompt template places the information in the recommendation report. 3. The report is written to a persistent candidate file. 4. Recruiters or downstream systems use the report during screening. 5. Protected or sensitive attributes influence ranki ...[truncated 655 chars]
Remediation
<![CDATA[ ## Remediation Suggestions 1. Remove date of birth, gender, marital status, family status, and age from default reports and profiles. 2. Collect only fields demonstrably necessary for the role and lawful recruitment process. 3. Exclude protected attributes from all automated scores, rankings, and recommendations. 4. Redact sensitive fields before writing recommendation reports. 5. Add field-level access controls for any legally required demographic data. 6. Require documented consent and purpose before retaining sensitive personal information. 7. Define automatic retention and deletion periods. 8. Maintain an audit trail of access to sensitive candidate fields. 9. Add fairness testing to ensure that protected attributes and close proxies do not influence candidate outcomes. ]]>
Vulnerability Patterns
  • Data ExfiltrationExternal Transmission, Env Variable Harvesting, File System Enumeration
  • MCP Tool PoisoningHidden Instructions, Unicode Deception, Parameter Description Injection
  • Prompt InjectionInstruction Override, Hidden Instructions, Exfiltration Commands
  • Privilege EscalationExcessive Permissions, Sudo/Root Execution, Credential Access
  • Supply ChainUnpinned Dependencies, External Script Fetching, Obfuscated Code
Findings (4)

Intent-Code Divergence

Medium
Confidence
97% confidence
Finding
The skill explicitly claims 'only file operations + text generation, no external network calls', but the documented workflows repeatedly instruct use of networked tools and services such as GitHub CLI, LinkedIn, Apollo, online demos, and monitoring external sites. This is a security-relevant misrepresentation because operators or policy engines may trust the declared behavior and permit installation/execution under false assumptions.

Missing User Warnings

Medium
Confidence
91% confidence
Finding
The README explicitly declares write access to candidate profile and recommendation files in the workspace, but it does not warn users that running the skill may modify existing data or create persistent records containing sensitive candidate information. In a recruiting context, silent writes are risky because they can overwrite notes, store personal data without clear operator awareness, and create audit/privacy issues even without any external exfiltration.

Missing User Warnings

High
Confidence
97% confidence
Finding
The template instructs inclusion of highly sensitive personal data such as birth date, sex, marital status, and location in recommendation reports when provided. In a recruiting context, this increases privacy exposure and can facilitate unlawful or discriminatory processing, especially because the template provides no minimization, consent, or jurisdiction-specific compliance warning.

Missing User Warnings

Medium
Confidence
91% confidence
Finding
The template directs maintaining talent maps with candidate gap annotations and long-term tracking windows, but gives no retention limit, consent model, access control guidance, or privacy notice. In a recruiting workflow, persistent profiling of candidate deficiencies and follow-up history can create unnecessary personal-data accumulation, misuse risk, and regulatory exposure if retained or shared broadly.

Static analysis

No suspicious patterns detected.