GHSA-74P7-6H78-GW8P

skillctl: argument injection, path traversal in --dest, FIFO/device DoS, hardlink exfiltration, and commit-trailer forgery

Following the path-safety patches in GHSA-wx3m-whqv-xv47 (v0.1.2), a comprehensive multi-angle audit surfaced five further vulnerabilities, now patched in v0.1.3:

1. source_sha argument injection in git ls-tree (CRITICAL). InstalledSkill.source_sha deserialized from .skills.toml (committed, PR-mergeable) flowed unvalidated into git ls-tree -r -z <refspec> -- <path>. Because the refspec sits before --, an attacker who slipped a malicious .skills.toml into a PR could set source_sha = "--name-only" / --abbrev=0 / --output=… and corrupt the diff classifier (which drives pull / push destructive decisions), or forge a divergence state to trick push --on-divergence overwrite into clobbering the wrong content.
2. FIFO / device / socket denial-of-service in copy_dir_all (CRITICAL). The file-type branch only checked is_dir() / is_symlink(); a FIFO inside a skill folder fell through to fs::copy, which blocks indefinitely waiting for a writer. A character device like /dev/zero would read until OOM. Reachable on skillctl add against any adversarial library.
3. add --dest arbitrary-directory wipe in agent mode (HIGH). --dest accepted absolute paths and .. traversal without validation, so a single invocation skillctl add --dest /Users/victim/.ssh --on-conflict overwrite --skill <maliciously-named> would remove_dir_all arbitrary directories, no .skills.toml round-trip required. Reachable in any non-interactive / agent-driven workflow where flag values may be attacker-supplied.
4. Commit-message trailer forgery via skill names (HIGH). Skill names were spliced verbatim into git commit -m "update skill: <name>" and into the commit.message field of --json output. A skill named foo\nCo-Authored-By: evil@x produced a forged commit trailer that downstream tooling (Linear, GitHub commit-bot, release-notes scrapers) treats as real authorship metadata.
5. Hardlink exfiltration via the round-trip (HIGH). fs::symlink_metadata reports a regular file for hardlinks (shared inode), and fs::copy reads the target content. An untrusted agent writing <project>/my-skill/data as a hardlink to ~/.ssh/id_rsa would have shipped the SSH key content to the (possibly public) library on the next skillctl push or detect.

Input manipulates file paths to reach files outside the intended directory, such as configuration or credential files. Typical impact: unauthorized file read or write outside the intended directory.

Kodem intelligence

Already deployed Kodem?

Fixed in v0.1.3:

• InstalledSkill::validate rejects any source_sha that isn't 40–64 hex characters.
• fs_util::copy_dir_all only allows regular files and directories; FIFO / socket / device / other special files are rejected with AppError::Config.
• commands::add::resolve_destination rejects .. unconditionally and rejects absolute paths in non-interactive / --json mode.
• New src/sanitize.rs module: validate_identifier (strict, no control bytes / newlines / ESC, used for skill name + individual tags) and validate_message_safe (lenient, allows \n + \t, rejects \r + DEL + C0/C1 controls, used for description and --message). Wired at the skill::discover and read_tags boundaries so poisoned skills are dropped silently and poisoned descriptions/tags are stripped from otherwise-valid skills.
• fs_util::copy_dir_all checks metadata.nlink() > 1 on regular files (Unix) and refuses hardlinked content.

All checks are lexical or single-syscall (symlink_metadata, metadata). No canonicalize, no TOCTOU windows. 23 new unit + integration tests cover each rejection class; cargo test: 95 pass; clippy clean; cargo audit clean.

1. What is GHSA-74P7-6H78-GW8P? GHSA-74P7-6H78-GW8P is a high-severity path traversal vulnerability in skillctl (rust), affecting versions < 0.1.3. It is fixed in 0.1.3. Input manipulates file paths to reach files outside the intended directory, such as configuration or credential files.
2. Which versions of skillctl are affected by GHSA-74P7-6H78-GW8P? skillctl (rust) versions < 0.1.3 is affected.
3. Is there a fix for GHSA-74P7-6H78-GW8P? Yes. GHSA-74P7-6H78-GW8P is fixed in 0.1.3. Upgrade to this version or later.
4. Is GHSA-74P7-6H78-GW8P exploitable, and should I be worried? Whether GHSA-74P7-6H78-GW8P is exploitable in your environment depends on whether the vulnerable code is present and reachable. A CVSS score is a worst-case rating; it does not account for your specific deployment, configuration, or usage patterns. Kodem, an Intelligent Application Security platform, uses runtime intelligence to show which vulnerabilities actually execute in production, so you can focus on the ones that represent real risk. Get a demo
5. What actually determines whether GHSA-74P7-6H78-GW8P is exploitable, and how bad it is? Exploitability and impact are not fixed properties of a CVE. They depend on runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A high CVSS score on a dependency that never runs is not the same as real risk. Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter.
6. How do I fix GHSA-74P7-6H78-GW8P? Upgrade skillctl to 0.1.3 or later.

Other vulnerabilities in skillctl