Back to skill

Security audit

Shlink CLI

Security checks for vulnerabilities and agentic risk

Overview

This Shlink CLI skill is mostly purpose-aligned, but its install and troubleshooting instructions create avoidable risks around unverified code and API key exposure.

Review this skill carefully before installing. Prefer a pinned, verified release or commit, avoid sudo/global installation until provenance is checked, and never print or paste the full SHLINK_API_KEY. Use a least-privilege Shlink API key and revoke it if it may have been displayed or shared.

Vulnerability Patterns
  • Insecure DependenciesIntroduces malicious components through unsafe dependency sources
  • Insecure Skill Coding PracticesFinds exploitable flaws such as hardcoded secrets or command injection
  • Skill Instruction HijackingAlters the agent's session goals or safety constraints when the skill loads
  • Agent Memory PoisoningWrites attacker-controlled rules into memory that affect later sessions
  • Remote Payload Retrieval and ExecutionFetches external code whose behavior can change after review
Findings (2)

T08 · Insecure Dependencies

Warning
Location
SKILL.md:28
Finding

Unpinned Remote Source and Dependency Resolution

Content
View full analysis

Vulnerability Details

File Location: SKILL.md, lines 28-34
Vulnerability Type: Supply-chain exposure through mutable remote source and unverified dependencies
Risk Level: Medium

bash
Repository:

- GitHub: https://github.com/ParinLL/shlink-cli

Install from source:

```bash
git clone https://github.com/ParinLL/shlink-cli.git
cd shlink-cli
go mod tidy
go build -o shlink-cli .
text

### Technical Analysis

The installation procedure clones the repository's mutable default branch rather than a specific reviewed release or commit. It then runs `go mod tidy`, which resolves the dependency graph, before building the resulting source. The instructions provide no commit pin, release checksum, signature verification, or dependency-integrity verification procedure.

Consequently, the code built by a user can differ from the code reviewed during the skill audit. A malicious or compromised upstream repository could modify the CLI source or its dependency declarations. A compromised dependency source could similarly affect dependency resolution. The resulting binary would appear to be the expected Shlink CLI while containing attacker-controlled behavior.

The use of HTTPS protects transport integrity but does not protect against compromise of the upstream repository, maintainer account, release process, or dependencies.

### Attack Path

1. An attacker compromises the upstream repository, a maintainer account, or a referenced dependency.
2. The attacker adds malicious code to the default branch or causes an unsafe dependency version to be resolved.
3. A user follows the documented `git clone` command without selecting a known, reviewed commit.
4. `go mod tidy` resolves the current dependency graph, and `go build` incorporates the affected code into the binary.
5. The user executes the binary to administer Shlink and supplies `SHLINK_API_KEY`.
6. The malicious code runs with the user's OS privileges and
...[truncated 707 chars]
Remediation
View remediation

Remediation Suggestions

  • Pin installation instructions to a reviewed release tag and immutable commit hash.
  • Provide expected SHA-256 checksums or cryptographic signatures for released source archives and binaries.
  • Require users to verify the checksum or signature before building or installing the CLI.
  • Use the repository's committed go.mod and go.sum files rather than recommending go mod tidy as an installation step.
  • Prefer go mod download followed by go mod verify to validate downloaded module contents against go.sum.
  • Document the exact verified release and commit to prevent a tag from being silently moved.
  • Recommend reviewing provenance attestations or reproducible-build results when available.
  • Avoid system-wide installation until the artifact's provenance and integrity have been verified.

T09 · Insecure Skill Coding Practices

Warning
Location
SKILL.md:80
Finding

Troubleshooting Guidance May Disclose the Shlink API Key

Content
View full analysis

Vulnerability Details

File Location: SKILL.md, lines 80-81
Vulnerability Type: Plaintext secret exposure through unsafe diagnostic output
Risk Level: Medium

text
1. Missing `SHLINK_BASE_URL` or `SHLINK_API_KEY`
   - Re-export variables and verify with `echo`.

Technical Analysis

The troubleshooting guidance recommends verifying environment variables with echo. If interpreted as echo "$SHLINK_API_KEY", this prints the complete API key in plaintext.

Terminal output may be retained in session recordings, CI logs, support transcripts, screenshots, clipboard history, or screen-sharing sessions. This advice also conflicts with the safety instruction later in the file stating that full API keys must never be exposed in logs or shared output.

The vulnerability does not independently transmit the credential. Exploitation depends on a user following the recommendation in an observable or recorded environment.

Attack Path

  1. A user encounters an authentication or configuration problem.
  2. Following the documented troubleshooting guidance, the user runs a command such as echo "$SHLINK_API_KEY".
  3. The complete key is displayed in the terminal.
  4. The terminal is recorded, shared with support, captured in a screenshot, copied into a ticket, or viewed by another party.
  5. An unauthorized party obtains the key and sends requests to the configured Shlink REST API.
  6. The attacker performs any operation authorized by that API key until it is revoked or expires.

Impact Assessment

Exposure compromises the confidentiality of SHLINK_API_KEY. An attacker can assume the API privileges granted to the key, potentially including creating, listing, updating, or deleting short URLs and managing tags, visits, domains, or other Shlink resources described by the skill.

The exact scope is limited by the key's permissions, the Shlink instance's configuration, network accessibility, and any server-side ...[truncated 71 chars]

Remediation
View remediation

Remediation Suggestions

  • Replace the recommendation to use echo with a presence check that does not reveal the value:

    bash
    if [ -n "${SHLINK_API_KEY:-}" ]; then
      echo "SHLINK_API_KEY is set"
    else
      echo "SHLINK_API_KEY is missing"
    fi
    
  • Check SHLINK_BASE_URL separately because it is not equivalent in sensitivity to the API key.

  • If identification is necessary, display only a short masked suffix rather than the complete secret.

  • Explicitly instruct users never to paste keys into tickets, logs, screenshots, chat messages, or shared terminals.

  • Ensure debug mode redacts API keys from request headers, URLs, environment diagnostics, and error messages.

  • Advise immediate revocation and replacement of any key that may have been displayed or shared.

  • Apply least-privilege scopes and expiration policies to API keys where supported.

Vulnerability Patterns
  • Privilege EscalationExcessive Permissions, Sudo/Root Execution, Credential Access
  • Prompt InjectionInstruction Override, Hidden Instructions, Exfiltration Commands
  • Data ExfiltrationExternal Transmission, Env Variable Harvesting, File System Enumeration
  • Supply ChainUnpinned Dependencies, External Script Fetching, Obfuscated Code
  • Excessive AgencyUnrestricted Tool Access, Autonomous Decision Making, Scope Creep
Findings (1)

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 · SKILL.md (reported line 40)May include surrounding context.

Optional global install:

bash
sudo install shlink-cli /usr/local/bin/

Required Environment

Static analysis

No suspicious patterns detected.