glab

• Outcome: Review
• Latest audit: Sep 11, 2026 · 2:06 AM UTC
• Version: 1.0.4

Overview

This GitLab CLI skill is mostly purpose-aligned, but it includes executable scripts with unsafe unvalidated numeric inputs and troubleshooting guidance that can expose tokens or weaken TLS security.

Install only if you are comfortable giving the skill a GitLab token and allowing it to guide state-changing GitLab operations. Use a narrowly scoped, project-level or read-only token where possible, avoid running the bundled scripts with values copied from untrusted prompts or repository text, do not print tokens to the terminal, and do not disable TLS verification in an authenticated session.

A.I.G

Vulnerability Patterns

• Insecure Skill Coding Practices: Finds exploitable flaws such as hardcoded secrets or command injection
• 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
• 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 (4)

T09 · Insecure Skill Coding Practices

Error

• Location: scripts/glab-mr-await.sh:18

Finding

Command Injection Through Unvalidated MR Wait Timeout

Content

View full analysis

Vulnerability Details

File Location: scripts/glab-mr-await.sh, lines 18-30 and 99
Vulnerability Type: Unvalidated input evaluated in a Bash arithmetic context
Risk Level: High

Vulnerable Code

bash

TIMEOUT="${TIMEOUT:-3600}"  # Default 1 hour

# Parse args
shift || true
while [[ $# -gt 0 ]]; do
    case $1 in
        --timeout|-t)
            TIMEOUT="$2"
            shift 2
            ;;

bash

if [[ $ELAPSED -ge $TIMEOUT ]]; then
    echo "⏰ Timeout after ${TIMEOUT}s"
    exit 1
fi

Technical Analysis

TIMEOUT can originate from either the process environment or the --timeout command-line argument. The script does not verify that it contains only a non-negative integer before using it as an operand in a Bash arithmetic comparison.

Bash recursively evaluates variable contents in arithmetic contexts. Crafted arithmetic expressions can therefore cause expansions, including command substitutions embedded in array-index expressions, to be evaluated. If an attacker can influence the script environment or the argument passed by an automation agent, the comparison can become a command-execution sink.

The use of quotation marks around the initial assignments does not mitigate this issue because the dangerous interpretation occurs later, inside the arithmetic comparison.

Attack Path

1. An attacker influences a workflow, prompt, configuration, or wrapper that supplies TIMEOUT or --timeout.
2. The attacker supplies a value constructed as a Bash arithmetic expression containing a command substitution.
3. The script stores that value without validation.
4. Execution reaches [[ $ELAPSED -ge $TIMEOUT ]].
5. Bash evaluates the attacker-controlled arithmetic expression and executes the embedded command.
6. The command runs with the operating-system privileges and accessible credentials of the user or automation account running the skill.

Impact Assess

...[truncated 510 chars]

Remediation

View remediation

Remediation Suggestions

Validate all numeric settings immediately after argument parsing and before any arithmetic operation:

bash

if [[ ! "$TIMEOUT" =~ ^[0-9]+$ ]]; then
    echo "Error: timeout must be a non-negative integer" >&2
    exit 2
fi

Additional hardening should include:

• Check that --timeout has a following value before reading $2.
• Impose a reasonable upper bound to prevent excessive execution time.
• Validate MR_NUMBER as an integer before passing it to glab.
• Validate every environment-derived value before using it in arithmetic or command construction.
• Avoid passing arguments generated directly from untrusted issue, merge-request, or prompt content.

T09 · Insecure Skill Coding Practices

Error

• Location: scripts/glab-pipeline-watch.sh:14

Finding

Command Injection Through Unvalidated Pipeline Timeout and Interval

Content

View full analysis

Vulnerability Details

File Location: scripts/glab-pipeline-watch.sh, lines 14-27 and 88
Vulnerability Type: Unvalidated input evaluated in Bash arithmetic and timing operations
Risk Level: High

Vulnerable Code

bash

TIMEOUT="${TIMEOUT:-1800}"  # Default 30 min
INTERVAL="${INTERVAL:-5}"

# Parse args
while [[ $# -gt 0 ]]; do
    case $1 in
        --timeout|-t)
            TIMEOUT="$2"
            shift 2
            ;;
        --interval|-i)
            INTERVAL="$2"
            shift 2
            ;;

bash

if [[ $ELAPSED -ge $TIMEOUT ]]; then
    echo -e "\r⏰ Timeout after ${TIMEOUT}s  "
    exit 2
fi

Technical Analysis

Both TIMEOUT and INTERVAL accept values from environment variables or command-line arguments without type or range validation. TIMEOUT is subsequently evaluated as part of a Bash arithmetic comparison. As with the MR wait script, attacker-controlled arithmetic expressions may trigger command substitution during recursive arithmetic evaluation.

INTERVAL is passed to sleep. Although it is quoted and is not itself an immediate shell-injection sink, the lack of validation allows negative, malformed, or excessively large values to disrupt monitoring. It should be treated as part of the same untrusted numeric-input boundary.

The parser also silently ignores unknown options and does not explicitly verify that options requiring values have received them, making accidental or attacker-induced misuse harder to detect.

Attack Path

1. An attacker gains influence over the environment or arguments used to launch the pipeline watcher.
2. A crafted arithmetic expression is supplied through TIMEOUT or --timeout.
3. The value is stored unchanged.
4. The monitoring loop reaches the timeout comparison.
5. Bash evaluates the crafted operand and executes its embedded command substitution.
6. The payload runs with the permissions and ...[truncated 774 chars]

Remediation

View remediation

Remediation Suggestions

Enforce numeric formats and safe ranges after parsing:

bash

if [[ ! "$TIMEOUT" =~ ^[0-9]+$ ]] || (( TIMEOUT > 86400 )); then
    echo "Error: timeout must be an integer from 0 to 86400" >&2
    exit 2
fi

if [[ ! "$INTERVAL" =~ ^[1-9][0-9]*$ ]] || (( INTERVAL > 3600 )); then
    echo "Error: interval must be an integer from 1 to 3600" >&2
    exit 2
fi

The parser should also:

• Reject options that do not have a following value.
• Reject unknown options instead of silently shifting past them.
• Validate environment-provided defaults under the same rules as command-line values.
• Avoid constructing invocations from untrusted natural-language or repository content without an explicit validation layer.

T09 · Insecure Skill Coding Practices

Error

• Location: references/troubleshooting.md:504

Finding

Troubleshooting Guidance Exposes the GitLab Access Token

Content

View full analysis

Vulnerability Details

File Location: references/troubleshooting.md, line 504
Vulnerability Type: Plaintext secret disclosure through terminal output
Risk Level: High

Vulnerable Code

bash

echo $GITLAB_TOKEN

Technical Analysis

The troubleshooting guide instructs the user or agent to print the complete GITLAB_TOKEN. This is not necessary to determine whether the variable is set. The value can be retained in terminal scrollback, agent transcripts, CI job logs, remote-session recordings, support bundles, or screen-sharing captures.

The token is the primary credential required by the skill. Its disclosure can consequently turn a routine authentication diagnostic into credential compromise. The absence of shell quoting is an additional correctness issue, but the primary security problem is printing the secret at all.

Attack Path

1. A user or automated agent encounters an authentication problem.
2. It follows the troubleshooting instruction and executes echo $GITLAB_TOKEN.
3. The complete token is written to standard output.
4. The output is captured by a transcript, CI logger, terminal recording, support system, or another observer.
5. An attacker retrieves the token and authenticates to the configured GitLab instance.
6. The attacker performs any operation permitted by the token's scopes and the associated account's project access.

Impact Assessment

The resulting privileges are bounded by the token's scopes and the GitLab account's authorization. A read-only token may expose private source code, merge requests, issues, job information, and project metadata. A token with api, repository write, or administrative scopes may permit modification or deletion of projects, pipelines, variables, issues, merge requests, settings, and other protected resources.

Remediation

View remediation

Remediation Suggestions

Remove all instructions that display the token. Test only whether it is present:

bash

if [[ -n "${GITLAB_TOKEN:-}" ]]; then
    echo "GITLAB_TOKEN is set"
else
    echo "GITLAB_TOKEN is not set"
fi

Additional safeguards should include:

• Use glab auth status to verify authentication without disclosing credentials.
• Never include tokens in command-line arguments where process listings or shell history may expose them.
• Redact tokens from logs and support output.
• Rotate any token that has already been printed in a logged or shared environment.
• Continue recommending project-level and minimally scoped tokens.

T09 · Insecure Skill Coding Practices

Warning

• Location: references/troubleshooting.md:466

Finding

Troubleshooting Guidance Disables TLS Certificate Verification

Content

View full analysis

Vulnerability Details

File Location: references/troubleshooting.md, line 466
Vulnerability Type: Insecure transport configuration
Risk Level: Medium

Vulnerable Code

bash

export GIT_SSL_NO_VERIFY=true

Technical Analysis

Setting GIT_SSL_NO_VERIFY=true disables server-certificate verification for subsequent Git HTTPS operations in the current shell. Although the guide labels the measure as suitable only for development or testing, exporting it creates persistent shell-session state and the document does not immediately unset it.

Without certificate verification, Git cannot reliably authenticate the remote server. An attacker who can intercept network traffic, control DNS, operate a hostile proxy, or influence routing can impersonate the GitLab server and observe or alter transferred data.

Attack Path

1. A user encounters a certificate validation error.
2. The user follows the guide and exports GIT_SSL_NO_VERIFY=true.
3. The user performs an authenticated Git operation in the same shell.
4. An attacker positioned on the network impersonates the GitLab endpoint with an untrusted certificate.
5. Git accepts the endpoint because verification is disabled.
6. The attacker intercepts sensitive traffic or supplies altered repository content.

Impact Assessment

The setting can compromise the confidentiality and integrity of Git HTTPS traffic. Depending on the authentication method and protocol behavior, an attacker may capture credentials or session material, observe private repository data, modify cloned or fetched source code, redirect pushes, or inject malicious code into a developer or CI workflow. The setting does not itself grant local elevated privileges, but it weakens a core trust boundary for authenticated repository operations.

Remediation

View remediation

Remediation Suggestions

Remove the recommendation to disable TLS verification. Replace it with guidance to:

• Install the self-hosted or corporate certificate authority in the operating system trust store.
• Configure a trusted CA bundle using git config --global http.sslCAInfo /path/to/ca-bundle.pem.
• Verify the expected GitLab hostname and certificate chain.
• Correct proxy, DNS, and system-clock configuration.
• Use a command-scoped diagnostic only in an isolated environment with no credentials if disabling verification is absolutely unavoidable.
• Explicitly restore secure configuration before any authenticated operation.

SkillSpector

Vulnerability Patterns

• Data Exfiltration: External Transmission, Env Variable Harvesting, File System Enumeration
• Privilege Escalation: Excessive Permissions, Sudo/Root Execution, Credential Access
• Tool Misuse: Tool Parameter Abuse, Chaining Abuse, Unsafe Defaults
• Rogue Agent: Self-Modification, Session Persistence
• YARA Signatures: Malware Match, Webshell Match, Cryptominer Match

Findings (16)

Credential Access

High

• Category: Privilege Escalation
• Confidence: 70% confidence

Finding

Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.

Content

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

md

bins: [glab, jq]
      envs:
        - name: GITLAB_TOKEN
          description: GitLab personal access token. Recommend minimal scopes (read_api for read-only).
          secret: true
          required: true
        - name: GITLAB_HOST

Credential Access

High

• Category: Privilege Escalation
• Confidence: 70% confidence

Finding

Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.

Content

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

md

bins: [glab, jq]
      envs:
        - name: GITLAB_TOKEN
          description: GitLab personal access token. Recommend minimal scopes (read_api for read-only).
          secret: true
          required: true
        - name: GITLAB_HOST

Missing User Warnings

High

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

Finding

This section includes glab repo delete owner/project and repository archive/unarchive commands with no warning about destructive or high-impact effects on hosted repositories. Documentation that enables deletion of repositories should clearly warn users about permanence and the need to verify the target project.

Content

No source excerpt is available for this finding.

Credential Access

High

• Category: Privilege Escalation
• Confidence: 70% confidence

Finding

Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.

Content

Scanner excerpt · references/commands-detailed.md (reported line 431)May include surrounding context.

md

glab snippet create --title "Script" myfile.sh

# Create private snippet
glab snippet create --title "Secret" --private secret.txt

# View snippet
glab snippet view <snippet-id>

Credential Access

High

• Category: Privilege Escalation
• Confidence: 90% confidence

Finding

Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.

Content

Scanner excerpt · references/commands-detailed.md (reported line 507)May include surrounding context.

md

glab ssh-key list

# Add SSH key
glab ssh-key add ~/.ssh/id_rsa.pub

# Add SSH key with title
glab ssh-key add ~/.ssh/id_rsa.pub --title "Work laptop"

Credential Access

High

• Category: Privilege Escalation
• Confidence: 90% confidence

Finding

Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.

Content

Scanner excerpt · references/commands-detailed.md (reported line 510)May include surrounding context.

md

glab ssh-key list

# Add SSH key
glab ssh-key add ~/.ssh/id_rsa.pub

# Add SSH key with title
glab ssh-key add ~/.ssh/id_rsa.pub --title "Work laptop"

Chaining Abuse

High

• Category: Tool Misuse
• Confidence: 75% confidence

Finding

Tool calls are chained to bypass individual safety checks or escalate capabilities beyond what any single tool call would allow.

Content

Scanner excerpt · references/troubleshooting.md (reported line 58)May include surrounding context.

brew upgrade glab

Linux (depends on package manager)

sudo apt update && sudo apt upgrade glab

text

## Authentication Issues

YARA rule 'backdoor_persistence': Backdoor persistence with malicious payloads (shell commands, SSH key injection, hidden root users) [malware]

High

• Category: YARA Match
• Confidence: 75% confidence

Finding

YARA rule matched a known malware signature (reverse shell, backdoor, ransomware, C2 framework, or info stealer).

Content

Scanner excerpt · references/troubleshooting.md (reported line 488)May include surrounding context.

CA bundle:

bash

git config --global http.sslCAInfo /path/to/cert.pem

Environment Variable Issues

GITLAB_HOST Not Recognized

Issue: Commands still using gitlab.com instead of self-hosted instance

Solutions:

1. Export variable in current shell:

   bash

   export GITLAB_HOST=gitlab.example.org
   

2. Add to shell profile (~/.bashrc, ~/.zshrc):

   bash

   echo 'export GITLAB_HOST=gitlab.example.org' >> ~/.bashrc
   source ~/.bashrc
   

3. Or use flag for each command:

   bash

   glab mr list -R gitlab.example.org/owner/repo
   

GITLAB_TOKEN Not Working

Issue: Token set but authentication still failing

Solutions:

1. Verify token is exported:

   bash

   echo $GITLAB_TOKEN
   

2. Ensure no spaces in token:

   bash

   export GITLAB_TOKEN=glpat-xxxxxxxxxxxxxxxxxxxx
   

3. Token should not be quoted in export:

   bash

   # Correct
   export GITLAB_TOKEN=glpat-xxx
   
   # Incorrect
   export GITLAB_TOKEN="glpat-
   

Missing User Warnings

Medium

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

Finding

This markdown reference includes commands that merge, close, and modify merge requests, including deleting the source branch, but it provides no cautionary note about repository state changes or irreversible consequences. Under the markdown-file warning criteria, user-facing documentation should disclose actions that can affect project data or workflow integrity.

Content

No source excerpt is available for this finding.

Missing User Warnings

Medium

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

Finding

The file documents deleting pipelines and canceling running pipelines without any accompanying warning that these actions can interrupt CI/CD execution or remove pipeline history. For markdown skills, operations affecting system integrity or workflow state should be disclosed to users.

Content

No source excerpt is available for this finding.

Missing User Warnings

Medium

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

Finding

The API section shows generic POST, PUT, and DELETE operations that can create, alter, or remove GitLab resources, but it does not warn that these requests modify remote project data. Because these examples are broad and powerful, the markdown should disclose the impact before users reuse them.

Content

No source excerpt is available for this finding.

Missing User Warnings

Medium

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

Finding

The file documents creating private snippets, exporting variables to a file, and importing variables without warning that these operations may expose sensitive configuration or secrets if mishandled. Markdown guidance should disclose privacy and data-handling risks when commands can affect confidential data.

Content

No source excerpt is available for this finding.

Missing User Warnings

Medium

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

Finding

Adding or deleting SSH and deploy keys directly affects repository authentication and infrastructure access, yet the documentation presents these commands without any user warning. This omission matters because misuse can grant unauthorized access or break automation.

Content

No source excerpt is available for this finding.

Sudo/Root Execution

Medium

• Category: Privilege Escalation
• Confidence: 70% confidence

Finding

Commands invoke sudo or root privileges. Verify this elevated access is necessary and justified.

Content

Scanner excerpt · references/troubleshooting.md (reported line 58)May include surrounding context.

brew upgrade glab

Linux (depends on package manager)

sudo apt update && sudo apt upgrade glab

text

## Authentication Issues

Session Persistence

Medium

• Category: Rogue Agent
• Confidence: 90% confidence

Finding

The troubleshooting guide recommends creating a new token with broad scopes including api and write_repository without encouraging least privilege or temporary use. Over-scoped long-lived tokens increase exposure if stolen and can enable unauthorized API access or repository modification across accessible projects.

Content

Scanner excerpt · references/troubleshooting.md (reported line 115)May include surrounding context.

md

- User doesn't have project permissions

**Solutions:**
1. Create new token with required scopes:
   - api
   - read_api
   - read_user

Missing User Warnings

Medium

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

Finding

The guide instructs users to print and export GitLab tokens directly in the shell, which can expose credentials via terminal history, screen sharing, logs, shell startup files, or process inspection. In a troubleshooting context this is not overtly malicious, but it normalizes unsafe secret-handling practices and increases the chance of credential leakage.

Content

No source excerpt is available for this finding.

Static analysis

No suspicious patterns detected.