GHSA-rm43-82j9-r4mj
Fix: dep0we/atomic-agents-stack@ec474f4GHSA-rm43-82j9-r4mj is a security vulnerability in atomic-agents-stack. O3 Security confirms whether GHSA-rm43-82j9-r4mj is actually reachable in your code before you act, and blocks exploitation at runtime until you patch.
atomic-agents-stack: Dashboard HTTP server path traversal allows arbitrary file read
Real-World Exposure
atomic-agents-stackReal-time download stats are indexed for npm and PyPI packages. This vulnerability affects PyPI packages — download data is not available via public APIs for these ecosystems.
Description
The optional dashboard HTTP server (atomic_agents/dashboard/serve.py) builds filesystem paths directly from the request path and serves them without a containment check. It is the only per-request untrusted-path site in the codebase that does not route through _io.safe_resolve_under. Literal ../ segments survive urlparse and Path joining, so a request can read files outside the intended agents_root (including via the static branch).
Impact: arbitrary file read. The default bind is loopback, but --host is an operator-settable documented flag; binding 0.0.0.0 exposes this to the LAN. Even on loopback it is reachable via DNS-rebinding from a browser or SSRF from a co-located service.
Affected: dashboard/serve.py (DashboardHandler.do_GET / _serve_file), all versions through 1.0.0.
Fix: route every served path through _io.safe_resolve_under against the intended root and return 404 on PathTraversalError; reject ../separators early; optionally refuse a non-loopback --host unless an explicit auth/allow flag is set (matching serve/_app.py).
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 🐍PyPI | atomic-agents-stack | all versions | 1.1.0 |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for atomic-agents-stack. 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 atomic-agents-stack to 1.1.0 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-rm43-82j9-r4mj 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-rm43-82j9-r4mj 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-rm43-82j9-r4mj. 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-rm43-82j9-r4mj in your dependencies?
O3 detects GHSA-rm43-82j9-r4mj across PyPI dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.