Security audit
Security checks for vulnerabilities and agentic risk
This GitHub CLI skill has a legitimate analysis use, but its references also cover broad write, admin, token, extension, and codespace commands beyond the advertised read-oriented purpose.
Install only if you want a broad GitHub CLI reference available to the agent. Use a least-privilege token, prefer read-only scopes for analysis tasks, and require explicit approval before any command that writes to GitHub, prints tokens, manages secrets/keys, installs extensions, or uses codespaces.
The documented alias feature permits shell evaluation through sh when aliases start with ! or use --shell, which is effectively a command-execution primitive. For a repository-analysis skill, this creates a direct path from GitHub-oriented input into arbitrary local shell execution, greatly increasing the blast radius from prompt injection or misuse.
Secret-management commands such as listing, setting, and deleting GitHub secrets enable direct modification or reconnaissance of sensitive repository, organization, or user configuration. These capabilities are unrelated to passive repository analysis and could be abused to exfiltrate, replace, or destroy security-critical secrets.
Including gh auth token gives the skill an explicit capability to print active authentication tokens, enabling direct credential disclosure to terminal output, logs, or downstream tools. This is especially dangerous because the skill's declared use case does not require token retrieval at all, making the exposure unnecessary and highly sensitive.
The skill is described as a GitHub repository analysis and file-fetching tool, but this documentation explicitly includes gh workflow run, which triggers remote GitHub Actions execution. That materially expands the capability surface from read-oriented analysis into state-changing CI execution, creating a path to spend runner resources, trigger deployment-like workflows, or operate with repository permissions unexpectedly.
Remote workflow execution is especially dangerous in this context because the skill's stated purpose gives users reason to expect passive analysis, not active mutation of repository state. Triggering workflows can execute arbitrary repository-defined automation under GitHub Actions, potentially consuming secrets, changing infrastructure, or causing downstream side effects beyond mere code inspection.
Including workflow enable/disable administration commands in a skill advertised for remote analysis is an unjustified privilege expansion. An agent using this skill could change repository CI behavior, disable protective workflows, or re-enable dormant automation without the user expecting any write-side effects from an analysis tool.
Workflow enable/disable operations are administrative controls unrelated to repository analysis and can weaken repository defenses by suppressing scans, tests, or policy enforcement workflows. In an analysis-branded skill, their presence is more dangerous because operators may invoke the skill without realizing it can modify security-relevant automation settings.
Rerun, cancel, and delete are operational control actions that exceed the declared analysis role and can alter or erase CI execution outcomes. In practice, this can be abused to retrigger privileged automation, interrupt evidence-producing jobs, or remove run records, making the mismatch between skill purpose and capability security-significant.
The documented commands include destructive workflow run management such as canceling and deleting runs, which is inconsistent with an analysis/discovery skill. These operations can disrupt CI visibility, destroy audit-relevant execution history, and interfere with engineering or security workflows in a target repository.
Including issue deletion/locking functionality in an analysis-oriented skill creates unnecessary write-side and destructive capability. In agent contexts, this mismatch is dangerous because prompt injection or operator confusion can turn a read-only task into unauthorized modification of GitHub resources.
This documentation exposes capabilities far beyond the skill's stated purpose of remote repository analysis and file fetching, including issue/project mutation and shell-evaluated aliases. That scope expansion increases the chance an agent will perform destructive repository actions or execute arbitrary shell commands under the guise of using this skill.
Codespace access, SSH, file copy, and port forwarding/visibility operations provide remote execution-adjacent and data movement capabilities that exceed simple repository analysis. These features can expose internal services, move files between local and remote environments, or expand access to active development environments.
The documented capability set substantially exceeds the stated purpose of remote repository analysis and file fetching. It includes authentication, secret and key management, codespace access, and other administrative write operations that create unnecessary high-risk authority and expand the attack surface far beyond least privilege.
The authentication documentation notes tokens may be stored in plain text if a credential store is unavailable and encourages token-based flows and environment-variable usage. In the context of an analysis-only skill, documenting and potentially enabling these credential-handling paths expands risk of token exposure through local files, environment inheritance, or automation logs.
The default authentication mode is a web-based browser flow. After completion, an authentication token will be stored securely in the system credential store. If a credential store is not found or there is an issue using it gh will fallback to writing the token to a plain text file. See gh auth status for its stored location.
Alternatively, use --with-token to pass in a personal access token (classic) on standard input. The minimum required scopes for the token are: repo, read:org, and gist. Take care when passing a fine-grained personal access token to --with-token as the inherent scoping to certain resources may cause confusing behaviour when interacting with other resources. Favour setting GH_TOKEN for fine-grained personal access token usage.
Alternatively, gh will use the authentication token found in environment variables. This method is most suitable for "headless" use of gh such as in automation. See gh help environment for more info.
Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.
$ gh variable set MYVARIABLE --org myOrg --repos repo1,repo2,repo3
$ gh variable set -f .env
Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.
$ gh variable set MYVARIABLE --org myOrg --repos repo1,repo2,repo3
$ gh variable set -f .env
Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.
$ gh variable set MYVARIABLE --org myOrg --repos repo1,repo2,repo3
$ gh variable set -f .env
---
Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.
$ gh variable set MYVARIABLE --org myOrg --repos repo1,repo2,repo3
$ gh variable set -f .env
---
SSH and GPG key management allows the skill to alter account trust material, potentially adding attacker-controlled keys or deleting legitimate ones. Since this has no connection to repository analysis, its presence creates unnecessary account-takeover and integrity risks.
The skill metadata frames gh-cli as a read-oriented tool for remote repository analysis, file fetching, comparison, and discovery, but this file documents state-changing commands such as merging, editing, reviewing, commenting on, closing, locking, and reopening pull requests. That capability expansion violates least privilege and can let an agent take write actions against GitHub resources when a user or orchestrator may reasonably expect read-only behavior.
The documented project administration commands include editing, closing, deleting, copying, marking templates, and mutating project items, which materially exceed the stated analysis/fetching/comparison purpose of the skill. In practice, this mismatch could enable unauthorized project management changes under the guise of a repository-analysis tool, increasing the risk of accidental or induced destructive actions.
The documented command set is far broader than the skill's stated purpose of remote repository analysis, file fetching, and discovery. It includes many write, admin, and destructive operations (for example delete, rename, edit, deploy-key, fork, release, issue/project mutation), which creates a dangerous capability mismatch that could lead an agent to modify GitHub state when only read-oriented behavior was expected.
Secrets and variables management capabilities are unrelated to the declared repository-analysis use case and enable reading or modifying sensitive CI/CD configuration and metadata. This broadens the privilege boundary and increases the chance of credential misuse, persistence, or unauthorized workflow manipulation.
Extension installation and execution allow code from external repositories or local sources to be fetched and run as executables, which is well beyond repository analysis. In a tool-using agent, this can become an arbitrary code execution path with access to the host environment and GitHub credentials.
The inclusion of gh api gives arbitrary authenticated GitHub API access, which bypasses the supposed repository-analysis-only scope and can reach many write or administrative endpoints depending on token permissions. In an agent setting, this dramatically expands the attack surface because crafted prompts or tool arguments could induce unintended state changes or sensitive data access.
No suspicious patterns detected.