GHSA-r587-7jh2-4qr3
Fix: jesec/flood@103f53cGHSA-r587-7jh2-4qr3 is a remote code execution vulnerability in flood. O3 Security confirms whether GHSA-r587-7jh2-4qr3 is actually reachable in your code before you act, and blocks exploitation at runtime until you patch.
Server secret was included in static assets and served to clients
Real-World Exposure
floodReal-time download stats are indexed for npm and PyPI packages. This vulnerability affects npm packages — download data is not available via public APIs for these ecosystems.
Description
Impact
Server JWT signing secret was included in static assets and served to clients.
This ALLOWS Flood's builtin authentication to be bypassed. Given Flood is granted access to rTorrent's SCGI interface (which is unprotected and ALLOWS arbitrary code execution) and usually wide-ranging privileges to files, along with Flood's lack of security controls against authenticated users, the severity of this vulnerability is CRITICAL.
Background
Commit 8d11640b imported config.js to client (frontend) components to get disableUsersAndAuth configuration variable. Subsequently contents of config.js are compiled into static assets and served to users. Unfortunately config.js also includes secret.
Intruders can use secret to sign authentication tokens themselves to bypass builtin access control of Flood.
Patches
Commit 042cb4ce removed imports of config.js from client (frontend) components. Additionally an eslint rule was added to prevent config.js from being imported to client (frontend) components.
Commit 103f53c8 provided a general mitigation to this kind of problem by searching static assets to ensure secret is not included before starting server (backend).
Workarounds
Users shall upgrade if they use Flood's builtin authentication system.
While maintainers will do their best to support it, Flood cannot guarantee its in-house access control system can stand against determined attackers in high-stake environments.
Use
HTTP Basic Author other battle-hardened authentication methods instead of Flood's in-house one. You can usedisableUsersAndAuthto avoid duplicate authentication.
Users are advised to check out the wiki for more information on security precautions.
References
Introduction to JSON Web Tokens
For more information
If you have any questions or comments about this advisory:
- Open an issue in issue tracker
- Email us at [email protected]
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 📦npm | flood | ≥ 2.0.0&&< 3.0.0 | 3.0.0 |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for flood. 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 flood to 3.0.0 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-r587-7jh2-4qr3 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-r587-7jh2-4qr3 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-r587-7jh2-4qr3. 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-r587-7jh2-4qr3 in your dependencies?
O3 detects GHSA-r587-7jh2-4qr3 across npm dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.