GHSA-wx3m-whqv-xv47
skillctl: Path traversal and symlink-follow in skillctl allow arbitrary file disclosure and deletion
Details
## Impact
`skillctl` 0.1.0 and 0.1.1 contained four path-safety vulnerabilities that, in combination, allowed an attacker to:
1. **Exfiltrate arbitrary files on the operator's machine** by publishing a malicious skills library containing a symlink inside a skill folder (e.g. `niania → /home/user/.aws/credentials`). The symlink fell through `entry.file_type().is_dir()` in `fs_util::copy_dir_all`, was dereferenced by `fs::copy`, and the target's content was copied into the project. A subsequent `skillctl push` would have published the secret to the (possibly public) library — what the reporter called "round-trip path exfiltration".
2. **Delete arbitrary directories outside the project or library root** by crafting a `.skills.toml` with a malicious `destination` or `source_path` field. Both were deserialized as `PathBuf` with zero validation. Because `Path::join` lets an absolute right-hand side replace the base, `destination = "/home/user/.ssh"` made `cwd.join(...)` resolve outside the project; `..` traversal was equally unguarded. Downstream `remove_dir_all` in `replace_folder_contents` then wiped arbitrary writable directories on `skillctl pull` / `push` / `detect`. `.skills.toml` is the exact kind of file teams commit and exchange via PR; a single merged malicious PR was sufficient to weaponise the maintainer's next `skillctl pull --all`.
3. **`detect --target` accepted `..` traversal**, even though absolute paths were rejected. `--target ../../../etc` would have written outside the library root.
4. **Fork-name validation accepted `.` and `..` literally**, so a fork named `..` would have produced a `Path::join` resolving to the parent directory and `fs::rename` could have clobbered it.
## Patches
Fixed in [v0.1.2](https://github.com/umanio-agency/skillctl/releases/tag/v0.1.2):
- Symlinks inside skill folders are hard-rejected at copy time (both top-level source and any descendant entry). - `.skills.toml` `destination` and `source_path` are validated at load time and reject absolute paths, `..` components, and Windows-prefix components. - A new `path_safety::safe_join` helper is wired (defense-in-depth) at every destructive call site in `pull.rs` / `push.rs`. - `detect --target` and the interactive custom-path prompt go through the same `validate_relative_subpath` helper. - `validate_fork_name` explicitly rejects `.` and `..`.
Threat-model note: the fix is purely lexical (component-level) plus an explicit symlink check at copy time. No filesystem `canonicalize` calls were added, avoiding TOCTOU windows.
## Credit
Reported privately on 2026-05-19 by **firebaguette** via the Umanio Discord (the reporter declined GitHub credit, so this advisory carries no structured credits field).
Are you affected?
Enter the version of the package you're using.
Affected packages
0 Fixed in: 0.1.2 Upgrade skillctl to 0.1.2 or newer (ecosystem crates.io).
References
- https://github.com/umanio-agency/skillctl/security/advisories/GHSA-wx3m-whqv-xv47 [WEB]
- https://github.com/umanio-agency/skillctl/commit/827fff5c0698dd9e48e777d5907cf7bc19b91aca [WEB]
- https://github.com/umanio-agency/skillctl [PACKAGE]
- https://github.com/umanio-agency/skillctl/releases/tag/v0.1.2 [WEB]