GHSA-6xx4-9wp6-65p7 json
skilo add follows symbolic links, allowing arbitrary local file disclosure from a malicious skill source
published 3mo ago modified 3mo ago
- cvss
- 6.5
- version 3.1, GitHub
- cisa kev
- Not listed
- not in CISA's catalog
- epss
- —
- no score, EPSS covers CVEs only
- public exploits
- 0
- none known
Summary
### Impact
`skilo add` installs a skill by recursively copying the skill directory into the target skills directory. The copy routine (`copy_dir_all`) classified each entry with `std::fs::DirEntry::file_type()` — which does **not** follow symlinks — and then copied non-directory entries with `std::fs::copy()`, which **does** dereference symlinks.
As a result, a skill containing a symbolic link such as `reference.txt -> /home/<user>/.ssh/id_rsa` was copied as a regular file whose contents are the link's **target**. A malicious skill source — for example a git repository installed via `skilo add github.com/<attacker>/<skills>`, or a local path — could read arbitrary files readable by the user running `skilo add` (SSH keys, cloud credentials, `.env` files, etc.) and place their contents inside the installed skill directory, where the user or their agent may later read, share, or sync them.
This is arbitrary local file disclosure (CWE-59 / CWE-61, symlink following) triggered by installing an untrusted skills source.
### Patches
Fixed in **0.11.1**. `copy_dir_all` now rejects symbolic-link entries at any recursion depth (failing closed with a dedicated error) instead of dereferencing them.
### Workarounds
- Only install skills from sources you trust. - Inspect a skill source for symbolic links before running `skilo add`.
### Affected versions
Introduced together with the `skilo add` command in 0.5.0 and present through 0.11.0. Releases before 0.5.0 do not include the `add` command.
Patch / fix
- crates.io skilo 0.11.1
- github.com/manuelmauro/skilo@c14bdc2 commit
- github.com/manuelmauro/skilo#11 pull request
- github.com/manuelmauro/skilo/releases/tag/v0.11.1 release
Is GHSA-6xx4-9wp6-65p7 in your dependencies? Fencer shows which of your repositories are affected as soon as an advisory lands, and opens the fix as a pull request.
Check with FencerCVSS scores
| assigned by | version | score | vector |
|---|---|---|---|
| GitHub | 3.1 | 6.5 | CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:N/A:N |
Affected packages
| ecosystem | package | affected | fixed in |
|---|---|---|---|
| crates.io | skilo | >=0.5.0, <0.11.1 |
0.11.1 |
Classification
References
Sources
- GitHub Advisory GHSA-6xx4-9wp6-65p7
Fencer Intel keeps one entry per vulnerability: the CVE id wins, then GHSA, and records that alias each other are merged, except that two CVEs always keep separate entries. The same data is available as JSON.