VDB
KO
MEDIUM 6.5

GHSA-6xx4-9wp6-65p7

skilo add follows symbolic links, allowing arbitrary local file disclosure from a malicious skill source

Details

### 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.

Are you affected?

Enter the version of the package you're using.

Affected packages

crates.io / skilo
Introduced in: 0.5.0 Fixed in: 0.11.1

Upgrade skilo to 0.11.1 or newer (ecosystem crates.io).

References