Forgejo

• Outcome: Pass
• Latest audit: Sep 10, 2026 · 3:25 PM UTC
• Version: 0.1.0

Overview

This Forgejo helper is coherent and purpose-aligned, but users should treat its token, secrets, and install examples carefully.

Install only if you intend to manage Forgejo resources through Tea CLI. Use a narrowly scoped token, avoid pasting real tokens into commands that may be logged, review what secret and variable commands will reveal, and prefer a pinned or otherwise trusted Tea CLI installation source when possible.

A.I.G

Vulnerability Patterns

• Insecure Dependencies: Introduces malicious components through unsafe dependency sources
• 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

Findings (2)

T08 · Insecure Dependencies

Warning

• Location: SKILL.md:22
• Finding: Unpinned Tea CLI Dependency<![CDATA[ ## Vulnerability Details **File Location**: `SKILL.md`, lines 22–27 **Vulnerability Type**: Unpinned third-party executable dependency **Risk Level**: Medium ```yaml { "id": "go", "kind": "go", "module": "code.gitea.io/tea@latest", "bins": ["tea"], "label": "Install Tea CLI (go)", }, ``` ### Technical Analysis The Go installation configuration uses `code.gitea.io/tea@latest`. The `@latest` selector is mutable and may resolve to a different release each time installation occurs. Consequently, the executable installed by this Skill can change without any corresponding modification to, or security review of, the Skill itself. The declared module path is consistent with the expected Tea CLI project, and there is no direct evidence that the current upstream package is malicious. Nevertheless, dynamically selecting the latest executable release creates a supply-chain risk because a compromised upstream release, maintainer account, or distribution channel could introduce altered code into subsequent installations. ### Attack Path 1. An attacker compromises the upstream project, a maintainer account, or the relevant package distribution process. 2. The attacker publishes a malicious release that becomes the version resolved by `@latest`. 3. A user or agent installs the Tea CLI using the Skill's Go installation configuration. 4. Go downloads and installs the compromised release. 5. Subsequent `tea` commands execute attacker-controlled code with the permissions of the user running the CLI. ### Impact Assessment Successful exploitation could permit arbitrary code execution under the installing or invoking user's account. The resulting scope may include access to local files, environment variables, configured Forgejo credentials, and repositories or Forgejo resources authorized by the user's token. This configuration does not itself provide privilege escalation beyond the permissions of the user executing the installed program. ]]>
• Remediation: <![CDATA[ ## Remediation Suggestions - Replace `@latest` with a specific, reviewed semantic version, for example `code.gitea.io/tea@vX.Y.Z`. - Review release notes and security advisories before updating the pinned version. - Use Go's checksum database and module verification controls where applicable. - If the upstream project publishes signed releases or provenance attestations, verify them before approving an update. - Introduce a controlled dependency-update process that tests and reviews each new version before changing the pin. ]]>

T09 · Insecure Skill Coding Practices

Warning

• Location: SKILL.md:89
• Finding: Forgejo Access Token Passed Through Command-Line Arguments<![CDATA[ ## Vulnerability Details **File Location**: `SKILL.md`, lines 89–93 **Vulnerability Type**: Sensitive credential exposure through command-line arguments **Risk Level**: Medium ```bash tea login add --name my-forgejo --url https://forgejo.example.com --token <your-token> ``` ### Technical Analysis The documentation instructs users to supply a Forgejo access token directly as a command-line argument. When the placeholder is replaced with a real credential, the token may be retained in shell history, terminal session recordings, automation logs, audit telemetry, or process-command-line data. On systems where process arguments are visible to other users or monitoring services, the token may also be exposed while the command is running. The issue depends on a user following the example with a real token and on the host's history, process visibility, and logging configuration. ### Attack Path 1. A user replaces `<your-token>` with a valid Forgejo access token and executes the documented command. 2. The shell, terminal recorder, automation platform, process monitor, or logging system captures the complete command line. 3. A local user, administrator, log reader, or attacker with access to the captured data retrieves the token. 4. The attacker submits the token to the configured Forgejo instance. 5. The attacker performs operations permitted by the token until it expires or is revoked. ### Impact Assessment The exposed token grants the attacker the same Forgejo API and repository permissions assigned to that credential. Depending on its scope, this may include reading private repositories, accessing issues and pull requests, modifying repository content, interacting with CI/CD configuration, or viewing and changing repository variables and secret metadata. The maximum impact is bounded by the token's scopes, the associated account's privileges, and server-side authorization rules. ]]>
• Remediation: <![CDATA[ ## Remediation Suggestions - Prefer a Tea-supported interactive login flow that reads the token through a hidden prompt rather than a command-line argument. - If supported, provide the token through a protected credential store or another input mechanism that does not expose it in process arguments. - Avoid placing tokens in shell history, scripts, CI command output, or terminal recordings. - Configure automation systems to mask secrets and prevent command echoing. - Use narrowly scoped, short-lived tokens and rotate them regularly. - Restrict access to shell history and operational logs. - Immediately revoke and replace any token suspected of having been recorded or disclosed. ]]>

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

Missing User Warnings

Medium

• Confidence: 93% confidence
• Finding: The skill explicitly instructs users to list repository secrets via `tea actions secrets list --repo owner/repo` without any warning that this touches sensitive security configuration. Even if the command may only reveal secret names rather than values, exposing the existence and naming of secrets can aid reconnaissance, and the lack of caution normalizes handling sensitive resources without user confirmation or least-privilege considerations.

Static analysis

No suspicious patterns detected.