GHSA-wx3m-whqv-xv47
skillctl: Path traversal and symlink-follow in skillctl allow arbitrary file disclosure and deletion
GHSA-wx3m-whqv-xv47 is a high vulnerability (CVSS 7.1) in skillctl, published June 5, 2026. No source lists public exploit code. Fixed in skillctl 0.1.2.
- Severity
- 7.1 HighCVSS 4.0, GitHub Advisories
- Exploit chance
- UnscoredNo EPSS score yet
- Exploitation
- None knownNot on CISA’s or ENISA’s lists
- Fixed in
0.1.2skillctl
Description
Impact
skillctl 0.1.0 and 0.1.1 contained four path-safety vulnerabilities that, in combination, allowed an attacker to:
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 throughentry.file_type().is_dir()infs_util::copy_dir_all, was dereferenced byfs::copy, and the target's content was copied into the project. A subsequentskillctl pushwould have published the secret to the (possibly public) library — what the reporter called "round-trip path exfiltration".Delete arbitrary directories outside the project or library root by crafting a
.skills.tomlwith a maliciousdestinationorsource_pathfield. Both were deserialized asPathBufwith zero validation. BecausePath::joinlets an absolute right-hand side replace the base,destination = "/home/user/.ssh"madecwd.join(...)resolve outside the project;..traversal was equally unguarded. Downstreamremove_dir_allinreplace_folder_contentsthen wiped arbitrary writable directories onskillctl pull/push/detect..skills.tomlis the exact kind of file teams commit and exchange via PR; a single merged malicious PR was sufficient to weaponise the maintainer's nextskillctl pull --all.detect --targetaccepted..traversal, even though absolute paths were rejected.--target ../../../etcwould have written outside the library root.Fork-name validation accepted
.and..literally, so a fork named..would have produced aPath::joinresolving to the parent directory andfs::renamecould have clobbered it.
Patches
Fixed in v0.1.2:
- Symlinks inside skill folders are hard-rejected at copy time (both top-level source and any descendant entry).
.skills.tomldestinationandsource_pathare validated at load time and reject absolute paths,..components, and Windows-prefix components.- A new
path_safety::safe_joinhelper is wired (defense-in-depth) at every destructive call site inpull.rs/push.rs. detect --targetand the interactive custom-path prompt go through the samevalidate_relative_subpathhelper.validate_fork_nameexplicitly 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).
Attack profile
How easy it is to exploit
- Attack vector
- Network
- Complexity
- Low
- Privileges needed
- None
- User interaction
- Passive
What an attacker can affect
- Confidentiality
- High
- Integrity
- None
- Availability
- Low
Affected packages
| Package | Affected | Fixed |
|---|---|---|
skillctlcrates.io | before 0.1.2 | 0.1.2 |
What each source reports
GitHub Advisories Score used 7.1
skillctl: Path traversal and symlink-follow in skillctl allow arbitrary file disclosure and deletion
Impact
skillctl 0.1.0 and 0.1.1 contained four path-safety vulnerabilities that, in combination, allowed an attacker to:
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 throughentry.file_type().is_dir()infs_util::copy_dir_all, was dereferenced byfs::copy, and the target's content was copied into the project. A subsequentskillctl pushwould have published the secret to the (possibly public) library — what the reporter called "round-trip path exfiltration".Delete arbitrary directories outside the project or library root by crafting a
.skills.tomlwith a maliciousdestinationorsource_pathfield. Both were deserialized asPathBufwith zero validation. BecausePath::joinlets an absolute right-hand side replace the base,destination = "/home/user/.ssh"madecwd.join(...)resolve outside the project;..traversal was equally unguarded. Downstreamremove_dir_allinreplace_folder_contentsthen wiped arbitrary writable directories onskillctl pull/push/detect..skills.tomlis the exact kind of file teams commit and exchange via PR; a single merged malicious PR was sufficient to weaponise the maintainer's nextskillctl pull --all.detect --targetaccepted..traversal, even though absolute paths were rejected.--target ../../../etcwould have written outside the library root.Fork-name validation accepted
.and..literally, so a fork named..would have produced aPath::joinresolving to the parent directory andfs::renamecould have clobbered it.
Patches
Fixed in v0.1.2:
- Symlinks inside skill folders are hard-rejected at copy time (both top-level source and any descendant entry).
.skills.tomldestinationandsource_pathare validated at load time and reject absolute paths,..components, and Windows-prefix components.- A new
path_safety::safe_joinhelper is wired (defense-in-depth) at every destructive call site inpull.rs/push.rs. detect --targetand the interactive custom-path prompt go through the samevalidate_relative_subpathhelper.validate_fork_nameexplicitly 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).
- Record
GHSA-wx3m-whqv-xv47- CVSS 4.0
- 7.1 High
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:P/VC:H/VI:N/VA:L/SC:N/SI:N/SA:N - Weakness
- CWE-22, CWE-61
- Updated
- 2026-11-02
OSV 7.1
skillctl: Path traversal and symlink-follow in skillctl allow arbitrary file disclosure and deletion
Impact
skillctl 0.1.0 and 0.1.1 contained four path-safety vulnerabilities that, in combination, allowed an attacker to:
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 throughentry.file_type().is_dir()infs_util::copy_dir_all, was dereferenced byfs::copy, and the target's content was copied into the project. A subsequentskillctl pushwould have published the secret to the (possibly public) library — what the reporter called "round-trip path exfiltration".Delete arbitrary directories outside the project or library root by crafting a
.skills.tomlwith a maliciousdestinationorsource_pathfield. Both were deserialized asPathBufwith zero validation. BecausePath::joinlets an absolute right-hand side replace the base,destination = "/home/user/.ssh"madecwd.join(...)resolve outside the project;..traversal was equally unguarded. Downstreamremove_dir_allinreplace_folder_contentsthen wiped arbitrary writable directories onskillctl pull/push/detect..skills.tomlis the exact kind of file teams commit and exchange via PR; a single merged malicious PR was sufficient to weaponise the maintainer's nextskillctl pull --all.detect --targetaccepted..traversal, even though absolute paths were rejected.--target ../../../etcwould have written outside the library root.Fork-name validation accepted
.and..literally, so a fork named..would have produced aPath::joinresolving to the parent directory andfs::renamecould have clobbered it.
Patches
Fixed in v0.1.2:
- Symlinks inside skill folders are hard-rejected at copy time (both top-level source and any descendant entry).
.skills.tomldestinationandsource_pathare validated at load time and reject absolute paths,..components, and Windows-prefix components.- A new
path_safety::safe_joinhelper is wired (defense-in-depth) at every destructive call site inpull.rs/push.rs. detect --targetand the interactive custom-path prompt go through the samevalidate_relative_subpathhelper.validate_fork_nameexplicitly 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).
- Record
GHSA-wx3m-whqv-xv47- CVSS 4.0
- 7.1 High
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:P/VC:H/VI:N/VA:L/SC:N/SI:N/SA:N - Weakness
- CWE-22, CWE-61
- Updated
- 2026-11-02
History
| Recorded | Changed | Sources |
|---|---|---|
| first indexed | GitHub Advisories, OSV |
Dates are when Every CVE recorded each change. Upstream dates may differ.