glab-cli-skill

• Outcome: Pass
• Latest audit: Sep 15, 2026 · 1:43 AM UTC
• Version: 1.0.0

Overview

The skill is a GitLab CLI guide whose GitLab actions are expected and disclosed, though users should avoid its command-line token example.

Install only if you want Codex guidance for glab workflows. Before running any mutating GitLab command, verify the project, host, branch, and object ID. Prefer interactive login or stdin-based token input, and do not paste real GitLab tokens into command-line arguments.

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 (1)

T09 · Insecure Skill Coding Practices

Warning

• Location: references/auth.md:35

Finding

GitLab Access Token Exposed Through Command-Line Arguments

Content

View full analysis

Vulnerability Details

File Location: references/auth.md, lines 35–36
Vulnerability Type: Access-token exposure through command-line arguments
Risk Level: Medium

Vulnerable code snippet:

bash

# Non-interactive login with explicit token
glab auth login --hostname gitlab.example.org --token glpat-xxxx

Technical Analysis

The documentation recommends supplying a GitLab personal access token through the --token command-line argument. Although glpat-xxxx is only a placeholder, users following this example may replace it with a real token.

Command-line secrets may be retained in shell history, terminal session logs, diagnostic output, or process telemetry. Depending on the operating system and local security configuration, process arguments may also be visible to other local users or monitoring services while the command is running. The safer stdin-based examples elsewhere in the same file do not eliminate the risk created by explicitly recommending this alternative.

Attack Path

1. A user replaces glpat-xxxx with a valid GitLab access token.
2. The shell records the command in its history, or a terminal logger, process monitor, audit service, or diagnostic collector captures the command arguments.
3. An attacker or unauthorized local principal obtains access to that record or observes the process arguments.
4. The attacker extracts the token and authenticates to the corresponding GitLab instance.
5. The attacker performs actions permitted by the token scopes and the associated user's project permissions.

Impact Assessment

A stolen token may allow access to private GitLab projects, repository content, issues, merge requests, pipelines, job logs, and API resources available to the token holder. The documented minimum scopes include api and write_repository, so compromise may permit repository writes and remote mutations in addition to data disclosure.

The exact impact is bo ...[truncated 188 chars]

Remediation

View remediation

Remediation Suggestions

• Remove the example that places a token directly in the --token command-line argument.
• Recommend glab auth login --stdin and source the token from a protected secret manager or another mechanism that does not expose it in command history.
• Avoid storing tokens in plaintext files. If a temporary token file is unavoidable, create it with owner-only permissions, keep it outside shared directories, and securely delete it immediately after use.
• Add an explicit warning that tokens must not be entered as command-line arguments, committed to repositories, included in scripts, or copied into logs.
• Use narrowly scoped, short-lived tokens and rotate or revoke any token suspected of appearing in shell history or telemetry.
• Ensure CI systems use masked and protected secret variables rather than literal command arguments.

SkillSpector

Vulnerability Patterns

• Data Exfiltration: External Transmission, Env Variable Harvesting, File System Enumeration
• Prompt Injection: Instruction Override, Hidden Instructions, Exfiltration Commands
• Privilege Escalation: Excessive Permissions, Sudo/Root Execution, Credential Access
• Supply Chain: Unpinned Dependencies, External Script Fetching, Obfuscated Code
• Excessive Agency: Unrestricted Tool Access, Autonomous Decision Making, Scope Creep

Findings (2)

Missing User Warnings

Medium

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

Finding

This markdown file includes a POST example that creates or modifies GitLab resources, but it does not warn users that glab api can perform write operations against live remote objects. Because the documentation presents both read and write patterns together without disclosure, users may not appreciate that the command can change server-side data.

Content

No source excerpt is available for this finding.

Missing User Warnings

Medium

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

Finding

The documentation includes an example that places a GitLab access token directly on the command line via --token glpat-xxxx. Even as an example, this encourages a pattern that can expose credentials through shell history, process listings, terminal logging, or audit tooling, which is especially risky in a CLI-authentication guide where users may copy commands verbatim.

Content

No source excerpt is available for this finding.

Static analysis

No suspicious patterns detected.