How severe is GHSA-6xx4-9wp6-65p7?

GHSA-6xx4-9wp6-65p7 has a CVSS score of 6.5/10, rated MEDIUM. Review your exposure and patch according to your risk tolerance.

Which packages are affected by GHSA-6xx4-9wp6-65p7?

GHSA-6xx4-9wp6-65p7 affects the following packages: skilo (crates.io). Ecosystems affected: crates.io.

How do I fix GHSA-6xx4-9wp6-65p7?

Update skilo to 0.11.1 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-6xx4-9wp6-65p7 is resolved across your whole dependency graph.

How do I detect GHSA-6xx4-9wp6-65p7 in my crates.io dependencies?

Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for skilo, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.

How do I mitigate GHSA-6xx4-9wp6-65p7 if there is no patch (or I can't update yet)?

If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.

Is GHSA-6xx4-9wp6-65p7 actively exploited in the wild?

No public exploit code has been indexed for GHSA-6xx4-9wp6-65p7 yet. This does not mean the vulnerability cannot be exploited — absence of public exploits does not imply safety. Apply the recommended fix and use O3 Security to monitor your exposure.

When was GHSA-6xx4-9wp6-65p7 published, and has it been updated?

GHSA-6xx4-9wp6-65p7 was published on July 28, 2026 and was last updated on July 28, 2026. Advisory data evolves as severity scores, affected ranges, and exploit intelligence are revised — always check the latest version of the advisory before acting.

🦀

🦀 crates.io

Not in CISA KEV

MEDIUM severity

skilo add follows symbolic links, allowing arbitrary local file disclosure from a malicious skill sourceGHSA-6xx4-9wp6-65p7

MEDIUMFix: manuelmauro/skilo#11

GHSA-6xx4-9wp6-65p7 is a medium-severity (CVSS 6.5) vulnerability in skilo. A fix is available for skilo — see the affected versions and patch details below.

Published

Jul 28, 2026

Updated

Jul 28, 2026

Affected

1 pkg

Patched

1 / 1

Exploits

None indexed

Exploitation data as of Jul 28, 2026 · OSV.dev, FIRST.org (EPSS)

Real-World Exposure

1 pkg affected

🦀skilo

Real-time download stats are indexed for npm and PyPI packages. This vulnerability affects crates.io packages — download data is not available via public APIs for these ecosystems.

Description

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.

Affected Packages

1 total 1 fixed

Ecosystem	Package	Vulnerable range	Fix
🦀crates.io	`skilo`	≥ 0.5.0&&< 0.11.1	0.11.1`cargo update -p skilo --precise 0.11.1`

Detection & mitigation playbook

Open-source dependency

Detect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for skilo, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.
Fix
Update skilo to 0.11.1 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-6xx4-9wp6-65p7 is resolved across your whole dependency graph.
Workarounds
If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.

Frequently Asked Questions

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

O3 Security · Impact-Aware SCA

Is GHSA-6xx4-9wp6-65p7 in your dependencies?

Find it across crates.io, including transitive dependencies.

Scan my dependencies How O3 SCA works