# GHSA-r587-7jh2-4qr3: Server secret was included in static assets and served to clients

> Exposure of JWT signing secret in static assets allows attackers to bypass authentication and execute arbitrary code via rTorrent interface.

- **Severity:** Not scored
- **Exploited in the wild:** Not known
- **Login needed:** Not needed
- **Attackable:** Over the internet
- **Victim action needed:** Not needed
- **Fix available:** Yes
- **Published:** 26 Aug 2020

## What is GHSA-r587-7jh2-4qr3?

GHSA-r587-7jh2-4qr3 is a vulnerability in flood, published on 26 Aug 2020. An attacker can exploit it over the internet without logging in, with no action from the victim.

### Official 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 Auth` or other battle-hardened authentication methods instead of Flood's in-house one. You can use `disableUsersAndAuth` to avoid duplicate authentication.

Users are advised to check out the [wiki](https://github.com/jesec/flood/wiki) for more information on security precautions.

### References
[Wiki - Security precautions](https://github.com/jesec/flood/wiki/Security-precautions)

[Introduction to JSON Web Tokens](https://jwt.io/introduction/)

### For more information
If you have any questions or comments about this advisory:
* Open an issue in [issue tracker](https://github.com/jesec/flood/issues)
* Email us at [jc@linux.com](mailto:jc@linux.com)

## Which versions are affected by GHSA-r587-7jh2-4qr3?

2 open source packages ship an affected version, including flood.


| Package | Ecosystem | Affected | Fixed in |
| --- | --- | --- | --- |
| `flood` | npm | From 2.0.0 | 3.0.0 |
| `flood` | npm | From 2.0.0 | 3.0.0 |

## How do I fix GHSA-r587-7jh2-4qr3?

Upgrade flood to 3.0.0 or later.

## Is GHSA-r587-7jh2-4qr3 being exploited?

There is no known exploitation of GHSA-r587-7jh2-4qr3 in the wild and no public exploit code.

## Fix prompt for AI coding agents

```text
Check this codebase for GHSA-r587-7jh2-4qr3 and fix it if it is affected.

What it is: GHSA-r587-7jh2-4qr3 is a vulnerability in flood, published on 26 Aug 2020. An attacker can exploit it over the internet without logging in, with no action from the victim.
Exploitation: There is no known exploitation of GHSA-r587-7jh2-4qr3 in the wild and no public exploit code.

Affected packages and fixed versions:
- flood (npm): affected from 2.0.0; fixed in 3.0.0
- flood (npm): affected from 2.0.0; fixed in 3.0.0

Task:
1. Search the dependency manifests and lockfiles (for example package.json, package-lock.json, requirements.txt, poetry.lock, uv.lock, pom.xml, build.gradle, go.mod, Cargo.lock, Gemfile.lock) and any Dockerfiles for the affected packages, including transitive dependencies.
2. If an affected version is in use, upgrade it to the fixed version for its release line with the project's package manager, so the lockfile is regenerated. Prefer the smallest upgrade that fixes it.
3. If there is no fix, or the upgrade would break the build, do not guess: explain the risk and the safest workaround instead.
4. Run the tests and summarise what changed and why.
5. If nothing in the project is affected, say so and change nothing.

Reference: https://insights.sbomify.com/GHSA-r587-7jh2-4qr3/ (Markdown: https://insights.sbomify.com/GHSA-r587-7jh2-4qr3/index.md)
```

## Sources

- OSV: https://osv.dev/vulnerability/GHSA-r587-7jh2-4qr3

---
From sbomify Insights: https://insights.sbomify.com/GHSA-r587-7jh2-4qr3/
Summaries are generated and may contain mistakes; the official description above is the record.