Git Delegation Management

• Outcome: Review
• Latest audit: Sep 12, 2026 · 8:51 AM UTC
• Version: 1.0.0

Overview

This skill is openly meant to delegate Git work, but it gives worker messages broad control over host-authenticated Git operations and workspace paths without clear authorization or containment safeguards.

Review carefully before installing. This skill should only be used in a tightly controlled environment where Worker requests are authenticated, repositories and remotes are allowlisted, workspace paths are derived server-side, and destructive Git actions require explicit approval. As written, a mistaken or untrusted `git-request:` could cause authenticated pushes, history changes, access to private repositories, or cross-task workspace changes under the Manager's credentials.

A.I.G

Vulnerability Patterns

• Skill Instruction Hijacking: Alters the agent's session goals or safety constraints when the skill loads
• Unauthorized Access and Privilege Escalation: Obtains permissions beyond the task's legitimate needs
• Agent Memory Poisoning: Writes attacker-controlled rules into memory that affect later sessions
• Remote Payload Retrieval and Execution: Fetches external code whose behavior can change after review
• Embedded Malicious Code: Ships malicious scripts inside the skill and executes them locally

Findings (2)

T01 · Skill Instruction Hijacking

Error

• Location: SKILL.md:111
• Finding: Unrestricted privileged Git command delegation from untrusted Workers<![CDATA[ ## Vulnerability Details **File Location**: `SKILL.md`, lines 14-18, 25-39, and 111-132 **Vulnerability Type**: Privileged instruction hijacking and missing command authorization controls **Risk Level**: Critical ### Vulnerable Code ```markdown The Manager has access to: - Host's `.gitconfig` via `/host-share/.gitconfig` (symlinked to `/root/.gitconfig`) - Git credentials (SSH keys, credential helpers) configured on the host This allows git operations to use the correct author name, email, and authentication. ``` ```markdown **Extract:** - `task-id`: Task identifier - `workspace`: Path to work in (for clone: parent directory; for other ops: repo directory) - `operations`: List of git commands to execute (literally what to run) - `context`: (Optional) What the Worker is trying to accomplish ``` ```markdown ## What Operations Can Be Delegated **Any git operation**, including but not limited to: | Category | Commands | |----------|----------| | Repository | `git clone`, `git init` | | Branches | `git branch`, `git checkout`, `git switch` | | Remote | `git remote`, `git fetch`, `git pull`, `git push` | | Commits | `git add`, `git commit`, `git reset`, `git revert` | | History | `git log`, `git show`, `git diff` | | Rebase | `git rebase`, `git rebase -i` | | Cherry-pick | `git cherry-pick` | | Merge | `git merge` | | Stash | `git stash` | | Tags | `git tag` | | Submodules | `git submodule` | | Config | `git config` (local to repo) | If git can do it, the Worker can delegate it. ``` ### Technical Analysis The skill explicitly instructs a Manager possessing host Git credentials to execute Worker-supplied Git commands literally. It does not define a structured command parser, operation allowlist, repository authorization check, remote allowlist, argument validation, or approval requirement for destructive and externally visible operations. Treating commands as safe merely because they invoke Git does not establish a security boundary. Git supports h ...[truncated 2032 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions 1. Replace literal command execution with a structured request schema containing an enumerated operation and separately validated arguments. 2. Allow only the minimum required operations. Deny Git aliases, hooks, external helpers, `git config`, `git -c`, arbitrary executables, submodule commands, and all shell syntax. 3. Bind each authenticated Worker and task to an explicit repository, branch set, and approved remote URL. Resolve authorization on the Manager side rather than trusting request fields. 4. Use per-repository, short-lived credentials with read-only access by default. Never expose general host Git credentials to delegated workflows. 5. Require explicit human or policy approval for pushes, force pushes, resets, rebases, remote changes, tags, submodules, and history rewriting. 6. Execute approved operations in an isolated environment with a minimal environment, disabled hooks, sanitized Git configuration, no host SSH agent, and restricted network access. 7. Validate every argument against operation-specific rules and reject options that alter configuration, credential helpers, protocol handlers, upload-pack, receive-pack, or executable paths. 8. Record the authenticated requester, normalized repository, exact validated operation, resulting commit identifiers, and authorization decision in tamper-resistant audit logs. ]]>

T05 · Unauthorized Access and Privilege Escalation

Error

• Location: SKILL.md:48
• Finding: Worker-controlled task and workspace paths lack containment validation<![CDATA[ ## Vulnerability Details **File Location**: `SKILL.md`, lines 48-68 and 73-76 **Vulnerability Type**: Path traversal, workspace escape, and cross-task authorization failure **Risk Level**: High ### Vulnerable Code ```bash task_id="task-YYYYMMDD-HHMMSS" workspace="/root/hiclaw-fs/shared/tasks/${task_id}/workspace/{repo-name}" # Sync from MinIO mc mirror "hiclaw/hiclaw-storage/shared/tasks/${task_id}/" \ "/root/hiclaw-fs/shared/tasks/${task_id}/" # Check for processing marker bash /opt/hiclaw/agent/skills/task-coordination/scripts/check-processing-marker.sh "$task_id" if [ $? -ne 0 ]; then # Respond with git-failed: explaining the conflict exit 1 fi # Create processing marker bash /opt/hiclaw/agent/skills/task-coordination/scripts/create-processing-marker.sh "$task_id" "manager" 15 ``` ```bash cd "$workspace" # Execute each git command git clone https://github.com/org/repo.git git checkout -b feature-auth ``` ### Technical Analysis The skill extracts `task-id` and `workspace` from a Worker message and subsequently uses task-derived paths for local filesystem access, processing-marker operations, and MinIO synchronization. It does not require canonicalization, verify that the path remains beneath the authenticated task directory, reject traversal components, or detect symlink escapes. Shell quoting prevents word splitting and some command-injection forms, but it does not prevent an absolute path, `../` traversal, a symlink pointing outside the task directory, or selection of another task's directory. The processing marker only coordinates concurrent access; it does not establish that the requester is authorized to access the selected task or workspace. The later use of `mc mirror ... --overwrite` increases the potential scope because an incorrectly selected local or object-storage prefix can cause unauthorized data to be read, propagated, or overwritten. ### Attack Path 1. A malicious Worker supplies a forged task identifier or a wo ...[truncated 1211 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions 1. Do not accept raw workspace paths from Workers. Derive the workspace server-side from an authenticated, immutable task record. 2. Validate task identifiers against a strict format and verify that the requester owns or is explicitly authorized for the referenced task. 3. Resolve the task root and workspace with `realpath` or an equivalent canonicalization API before access. 4. Enforce that the canonical workspace begins with the canonical assigned task root followed by a path separator; reject absolute paths, traversal components, malformed identifiers, and containment failures. 5. Open directories using race-resistant filesystem APIs where possible, and reject symlinks or mount-point escapes throughout the path. 6. Scope MinIO credentials to a single task prefix and construct object-storage paths from trusted identifiers rather than Worker input. 7. Avoid unconditional `--overwrite`. Use versioning, conflict detection, and explicit authorization before replacing remote objects. 8. Apply processing markers only after authorization and canonical path validation. Bind each marker to the authenticated task and requester. 9. Run Git operations in an isolated per-task workspace with filesystem permissions that prevent access to sibling task directories. ]]>

SkillSpector

Vulnerability Patterns

• Data Exfiltration: External Transmission, Env Variable Harvesting, File System Enumeration
• Excessive Agency: Unrestricted Tool Access, Autonomous Decision Making, Scope Creep
• Trigger Abuse: Overly Broad Trigger, Shadow Command Trigger, Keyword Baiting Trigger
• Prompt Injection: Instruction Override, Hidden Instructions, Exfiltration Commands
• Privilege Escalation: Excessive Permissions, Sudo/Root Execution, Credential Access

Findings (4)

Vague Triggers

High

• Confidence: 95% confidence
• Finding: The skill advertises itself for executing git operations broadly on behalf of workers, without narrowing invocation to authenticated, structured, and policy-validated requests. In practice, this can cause the manager to use privileged host git credentials for requests that were triggered too easily or in the wrong context, enabling unauthorized repository access or destructive changes.

Missing User Warnings

High

• Confidence: 95% confidence
• Finding: The skill explicitly relies on the host's `.gitconfig` and credentials but does not warn about the security consequences of using those credentials for delegated operations or about the risk of destructive git commands. In this context, missing warnings and safeguards are dangerous because workers can indirectly cause authenticated pushes, history rewrites, or access to private repositories through the manager's trust boundary.

Vague Triggers

Medium

• Confidence: 97% confidence
• Finding: The activation condition is based solely on the presence of the literal string `git-request:`, which is ambiguous and trivially injectable in normal conversation or untrusted content. Because the skill then instructs the manager to execute the supplied operations literally, a low-friction trigger can lead directly to privileged action with host credentials.

Scope Creep

Low

• Category: Excessive Agency

Content

## What Operations Can Be Delegated

**Any git operation**, including but not limited to:

| Category | Commands |
|----------|----------|

• Confidence: 93% confidence
• Finding: The statement that workers may delegate 'any git operation' creates major scope creep in a privileged skill. In this specific context, it is especially dangerous because 'git' includes features that can execute programs, rewrite configuration, invoke hooks or helpers, manipulate submodules, and perform destructive history changes, all while using host-managed credentials.

Static analysis

No suspicious patterns detected.