Autonomous GitHub Team

• Outcome: Review
• Latest audit: Sep 14, 2026 · 9:47 PM UTC
• Version: 1.2.0

Overview

The skill is open about needing GitHub write access, but it tells users to run external bash scripts with a write-scoped token without immutable verification.

Install only if you are comfortable auditing the external repository yourself. Use a disposable fork or test repository first, create a fine-grained single-repository token with the minimum permissions, do not store broad account tokens in config.env, verify the exact upstream commit before running, and require branch protection plus human review before any production merge or release.

A.I.G

Vulnerability Patterns

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

Findings (1)

T03 · Remote Payload Retrieval and Execution

Error

• Location: SKILL.md:66

Finding

Execution of Mutable Third-Party Code with a Write-Capable GitHub Token

Content

View full analysis

Vulnerability Details

File Location: SKILL.md, lines 66–77
Vulnerability Type: Remote third-party payload retrieval and execution
Risk Level: High

Vulnerable Code

bash

# 1. Clone the repo (pinned to v1.0.0 tag)
git clone --branch v1.0.0 https://github.com/captainsvbot/AutonomousGitHubTeam.git
cd autonomous-github-team

# 2. Configure — edit config.env
cp config.example.env config.env
nano config.env   # set GH_TOKEN and TARGET_REPO

# 3. Audit the agents first (important!)
# Review agents/*.sh before running anything

# 4. Run
bash agents/orchestrator.sh

Related metadata at lines 27–29 also defines an external clone operation and represents the version only through a pinnedRef tag:

text

"command": "git clone https://github.com/captainsvbot/AutonomousGitHubTeam.git /path/to/autonomous-github-team",
"pinnedRef": "v1.0.0",
"note": "Clone is pinned to a specific release tag. Always review the tagged commit before running.",

Technical Analysis

The Skill instructs users to download Bash scripts from a third-party GitHub repository and execute agents/orchestrator.sh after placing a write-capable GitHub personal access token in config.env. None of the downloaded executable files are included in the audited project, so their implementation and effective behavior cannot be validated from this package.

Although the clone command selects the v1.0.0 tag, a Git tag is not equivalent to immutable commit verification. A mutable or replaced tag can resolve to different content after the Skill has been reviewed. The instructions do not verify an expected commit SHA, cryptographic signature, or trusted content digest before executing the downloaded scripts.

The metadata clone command is even less restrictive because the actual command does not specify a branch, tag, or commit. The separate pinnedRef metadata property does not, by itself, prove that the clone operation check ...[truncated 2266 chars]

Remediation

View remediation

Remediation Suggestions

1. Vendor the required scripts into the Skill package so the exact executable content is available during review.
2. If remote retrieval is unavoidable, resolve and pin an immutable full Git commit SHA rather than relying on a release tag.
3. After cloning, explicitly check out the expected commit and verify that git rev-parse HEAD exactly matches the approved SHA.
4. Publish trusted SHA-256 digests or signed release artifacts and verify them before executing any script. Abort on verification failure.
5. Update the metadata clone command so its executable command enforces the approved revision rather than relying only on the separate pinnedRef field.
6. Review the complete transitive execution chain, including every script, executable, package, and remote resource invoked by agents/orchestrator.sh.
7. Run the payload in an isolated container or disposable virtual machine with restricted filesystem access, outbound network controls, and no unrelated credentials.
8. Use a short-lived, fine-grained GitHub token restricted to one test repository and only the permissions required for the selected operation.
9. Avoid storing the token in a plaintext project configuration file where possible. Supply it through a protected secret manager and ensure it is not inherited by unnecessary subprocesses.
10. Enforce branch protection, mandatory independent review, signed commits where appropriate, and environment approval gates for releases.
11. Test exclusively against an isolated fork before granting access to a production repository.
12. Revoke and rotate the token immediately if integrity verification fails or the external repository is suspected of compromise.

SkillSpector

Vulnerability Patterns

• Privilege Escalation: Excessive Permissions, Sudo/Root Execution, Credential Access
• Trigger Abuse: Overly Broad Trigger, Shadow Command Trigger, Keyword Baiting Trigger
• Prompt Injection: Instruction Override, Hidden Instructions, Exfiltration Commands
• Data Exfiltration: External Transmission, Env Variable Harvesting, File System Enumeration
• Supply Chain: Unpinned Dependencies, External Script Fetching, Obfuscated Code

Findings (2)

Credential Access

High

• Category: Privilege Escalation
• Confidence: 86% confidence

Finding

The skill explicitly instructs users to create and supply a GitHub personal access token with repository write, PR write, and issue write permissions. While operationally necessary for the advertised functionality, this still represents a real credential-access and privileged-operation risk: compromise, misuse, or accidental invocation could let the skill modify code, create PRs, manipulate issues, and potentially influence release workflows in the target repository.

Content

Scanner excerpt · SKILL.md (reported line 88)May include surrounding context.

md

- Read and write issues

**Create a dedicated token for this skill:**
1. GitHub → Settings → Developer Settings → Personal Access Tokens → Fine-grained tokens
2. Scope to **only the specific repository** you want the team to operate on
3. Grant only: `contents: read and write`, `pull requests: read and write`, `issues: read and write`
4. **Never** use your main account token with broad org access

Vague Triggers

Medium

• Category: Not specified by scanner
• Confidence: 94% confidence

Finding

The trigger phrases are broad enough to activate on common software-development requests such as AI code review, CI/CD automation, or automated bug fixing. Because this skill performs high-impact actions against GitHub repositories and can execute third-party scripts with a write-scoped token, accidental invocation materially increases the chance of unintended repo changes or privileged workflow execution.

Content

No source excerpt is available for this finding.

Static analysis

No suspicious patterns detected.