The LaunchServer HTTP file server component (FileServerHandler) in GravitLauncher LaunchServer versions up to 5.7.11 has an unauthenticated path traversal flaw. The vulnerability is due to improper handling of request-targets that do not start with a slash, causing the path normalization logic to fail and allowing resolution of file paths outside the intended updates directory. This enables attackers to read any file readable by the LaunchServer process, including critical secrets such as the ECDSA private key (.keys/ecdsa_id), refresh-token salt (.keys/legacySalt), and database credentials (LaunchServer.json). The file server is enabled by default, bound to 0.0.0.0:9274, and does not require authentication, making exploitation straightforward via raw socket HTTP GET requests without a leading slash. Normal HTTP clients and proxies that normalize paths block this vector, but direct exposure or TCP-level proxies remain vulnerable. The flaw allows attackers to forge valid access tokens for any account, including admins, resulting in full authentication bypass and system compromise.

Unauthenticated remote attackers can read arbitrary files accessible to the LaunchServer process, including private keys used to sign JWT access tokens, refresh-token salts, and database credentials. This enables attackers to mint valid access tokens for any user, including administrators, effectively bypassing authentication. The exposure of these secrets can lead to full system compromise, unauthorized access, and data breaches. The vulnerability also allows reading other sensitive files such as configuration and system files, increasing the attack surface.

Patch status is not yet confirmed — check the vendor advisory for current remediation guidance. Suggested fixes include re-normalizing the resolved file path and verifying it remains within the intended base directory, rejecting request targets that do not start with a leading slash, and binding the file server to localhost (127.0.0.1) by default. Deployments should firewall or restrict access to port 9274 to prevent direct exposure. Use of a normalizing L7 reverse proxy (e.g., stock nginx with path normalization) can block the primary attack vector by rejecting no-leading-slash requests. Until an official fix is available, restrict network access to the vulnerable service and monitor for suspicious activity.