crates.io · skilo
skilo add follows symbolic links, allowing arbitrary local file disclosure from a malicious skill source
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.
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.
skilo add.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.
Is your project exposed to this? Stateward checks every dependency on every pull request and flags it only if your code actually reaches it.
Check my repoSources: CISA KEV (public domain), OSV.dev & GitHub Advisory Database (CC-BY-4.0), FIRST EPSS, NVD/CWE (public domain). Served live from the Stateward advisory database.