Skip to main content
CVE-2026-54617VulnerabilityPublished

Pro.gravit.launcher:launchserver api: LaunchServer FileServerHandler has an unauthenticated path traversal issue

Affects pro.gravit.launcher:launchserver-apiSource GCVE Database

0
Compare
Authoritative record:CVE-2026-54617· Critical 9.8

Not known to be exploited · public detection template (Nuclei) · CVSS 9.8 Critical · fixed in 5.7.12 : patch pro.gravit.launcher:launchserver-api as a priority.

Data as of 29 Oct 2026, 19:04 UTC

CVSS 3.1 base score
9.8Critical
How severe the flaw is on the 0–10 CVSS scale.
EPSS
3.4% chance of exploitation in 30 days – higher than 89% of CVEsExploit Prediction Scoring System: the likelihood attackers will use this flaw soon.
Patch
Available – fixed in 5.7.12
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H

Exploitation evidence

  1. Disclosed: evidence found.

    CVE published 17 Sep 2026

  2. Weaponized: no evidence on record.

    No public exploit code indexed in Metasploit or Exploit-DB

  3. Exploited in the wild: no evidence on record.

    Not in CISA KEV and no source reports exploitation

  4. Observed by OffSeq Mirage: no evidence on record.

    No attack traffic recorded by OffSeq Mirage sensors

A missing step is not evidence of safety. Sources: cve.org (opens in a new tab), the Metasploit, Exploit-DB and nuclei-templates index as of 29 Oct 2026.

What to do

Affected software

ProductAffectedFixed in
Mavenpro.gravit.launcher:launchserver-apiAffected
  • <=5.7.11
Fixed in–

Check your own hosts for these packages with threat-finder (opens in a new tab), our free open-source scanner.

Description

### Summary An unauthenticated path traversal in the LaunchServer HTTP file server (`FileServerHandler`) lets any remote actor read **any file** readable by the LaunchServer process (e.g. `../../../../etc/passwd`). This is a generic arbitrary-file-read primitive, so the fix must address the traversal itself, not any specific file. The readable files include the server's own secrets, which turns this from information disclosure into full compromise: the ECDSA private key that signs access JWTs (`.keys/ecdsa_id`), the refresh-token salt (`.keys/legacySalt`), and `LaunchServer.json` (database credentials). With the signing key an attacker mints a valid access token for any account, including admins. That is a full authentication bypass. Pre-auth, default config, port 9274. **Affected:** GravitLauncher LaunchServer ≤ 5.7.11 (the LaunchServer application; the published `pro.gravit.launcher:*-api` Maven artifacts do not contain the vulnerable code). ### Details In `FileServerHandler.channelRead0`: ```java path = Paths.get(IOHelper.getPathFromUrlFragment(uri)).normalize().toString().substring(1); // line 194 File file = base.resolve(path).toFile(); // line 200 - no second normalize() ``` `substring(1)` blindly strips a leading slash, assuming the request-target always starts with `/`. Netty's `HttpServerCodec` accepts a request-target **without** a leading slash verbatim (`decoderResult().isSuccess() == true`). For such a target, `normalize()` cannot collapse the leading `..`, `substring(1)` turns `../` into `./` (leaving the remaining `..`), and `base.resolve(path)`, which is not re-normalized, resolves **outside** `updatesDir`. `file.isHidden()` (line 201) is checked only on the final path component, so targets that don't start with a dot (`ecdsa_id`, `rsa_id`, `legacySalt`, `LaunchServer.json`) are served even with `showHiddenFiles=false`. The file server is enabled by default (`netty.fileServerEnabled=true`) and bound to `0.0.0.0:9274`. No auth handler precedes `FileServerHandler`; `WebSocketServerProtocolHandler("/api")` forwards non-WebSocket / non-`/api` requests down to it, so the attack is a plain HTTP GET (no WebSocket). ### PoC Reproduced on a from-source build of v5.7.11 (Netty 4.2.12). **Must use a raw socket.** curl/browsers/HTTP libraries normalize the path and prepend `/`, hitting the safe branch (false "not reproducible"). ``` printf 'GET ../../.keys/ecdsa_id HTTP/1.1\r\nHost: x\r\n\r\n' | nc <host> 9274 ``` Returns the raw ECDSA private-key bytes. Same for `../../.keys/rsa_id`, `../../.keys/legacySalt`, `../../LaunchServer.json`. `%2e%2e/...` (no leading slash) also works. Depth-robust arbitrary read: `../../../../../../etc/passwd`. Control (confirms the root cause): `GET /../../.keys/ecdsa_id` (WITH leading slash) → 404. Only the no-leading-slash form escapes. ### Impact Unauthenticated remote read of any file the process can access. What that exposes: - `.keys/ecdsa_id`: the key that signs access JWTs. With it, an attacker mints a valid token for any account, including admins, so this is a full authentication bypass. - `.keys/legacySalt`: lets an attacker forge refresh tokens. - `LaunchServer.json`: database credentials. - Any other file readable by the process (config, logs, system files). Deployment note: a normalizing L7 reverse proxy (stock nginx `location / { proxy_pass ...; }`) rejects the no-leading-slash request (400) and collapses leading-slash traversal, blocking the primary vector. But the default bind is `0.0.0.0:9274`, so protection relies on firewalling the backend port; L4/TCP proxies (HAProxy TCP, nginx `stream`, CF Spectrum) and direct exposure remain exploitable. ### Suggested fix 1. Re-`normalize()` after `base.resolve(path)` and verify `resolved.startsWith(base)`. 2. Reject request-targets that don't start with `/` (400). 3. Default-bind to `127.0.0.1`; store `.keys` outside `updatesDir`.

References

Community reviews

Loading reviews…