GHSA-55f6-4pr5-c7m5
Kahi has privilege-drop and socket/log permission issues
Blast Radius
github.com/kahiteam/kahiReal-time download stats are indexed for npm and PyPI packages. This vulnerability affects Go packages — download data is not available via public APIs for these ecosystems.
Description
Kahi releases up to and including v0.1.0-alpha.8 contain three privilege/permission issues, all fixed in v0.1.0-alpha.9. They were identified in a full-codebase security review on 2026-05-26.
Affected versions
All releases <= v0.1.0-alpha.8.
Patched version
v0.1.0-alpha.9.
Details
1. Per-process privilege drop not applied (High)
A process configured with user = "uid:gid" had its credential resolved but never attached to the spawned child, so the process ran with the supervisor's inherited privileges (root, when the supervisor runs as root) instead of the configured lower-privilege user. The intended privilege isolation did not occur, and no error was raised.
2. Privilege drop did not reset supplementary groups (Medium)
When the daemon dropped privileges it set the primary gid and uid but never called setgroups(2), so the launching user's supplementary groups (for example docker, which is root-equivalent) remained active after the drop and were inherited by child processes.
3. FastCGI unix socket world-accessible by default (Medium)
A FastCGI unix-domain socket was chmod-ed only when socket_mode was explicitly configured. With socket_mode unset the socket kept the umask-dependent default (commonly world-accessible), allowing any local user to connect to it.
Remediation
Upgrade to v0.1.0-alpha.9. Privilege handling is now fail-closed: the configured credential is applied or the process refuses to start, supplementary groups are reset via setgroups before setgid/setuid, and FastCGI unix sockets default to 0700.
Workarounds (for <= v0.1.0-alpha.8)
- Do not rely on per-process
user; run the supervisor directly as the intended unprivileged user. - Set an explicit restrictive
socket_modeon FastCGI programs. - Avoid running the supervisor as root where possible.
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 🐹Go | github.com/kahiteam/kahi | all versions | 0.1.0-alpha.9 |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for github.com/kahiteam/kahi. O3's reachability analysis confirms whether the vulnerable code path is actually invoked in your application, so you act on real exposure instead of every transitive match.
Fix
Update github.com/kahiteam/kahi to 0.1.0-alpha.9 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-55f6-4pr5-c7m5 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.
How O3 protects you
O3 pinpoints whether GHSA-55f6-4pr5-c7m5 is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.
Tailored to GHSA-55f6-4pr5-c7m5. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.
Frequently Asked Questions
Is GHSA-55f6-4pr5-c7m5 in your dependencies?
O3 detects GHSA-55f6-4pr5-c7m5 across Go dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.