Hopper runs arbitrary code (Minecraft servers and their plugins), exposes a filesystem over HTTP and SFTP, and drives the host machine's Docker daemon. A flaw here is not limited to one game server: it can give root access to the host.

Do not open a public issue.

Use the repository's Security → Report a vulnerability tab (GitHub Security Advisories), or write to security@hopperpanel.io.

Please include:

• a description of the flaw and its impact;
• the steps to reproduce it, or a proof of concept;
• the Hopper version, the OS and the Docker version concerned.

Our commitments:

Whoever reports a flaw is credited in the security advisory, unless they ask otherwise.

In scope:

• Path escape in the file manager or over SFTP (traversal, symlinks, zip slip);
• Container escape or privilege escalation towards the host;
• Authentication or authorisation bypass, including between subusers;
• Command injection through startup variables or templates;
• Token forgery: node tokens, console JWTs, signed download URLs;
• SSRF from the panel towards a daemon or an internal address;
• Exposure of secrets in the logs, the API responses or the interface.

Out of scope:

• issues that require administrator access to the panel one already legitimately holds;
• an operator denying service to their own instance;
• vulnerabilities in the Minecraft servers or the plugins themselves;
• misconfigurations documented as such (for instance exposing the daemon over plain HTTP).

Hopper assumes a server's user is hostile. A server operator can upload any plugin, run any command in their console and write any file into their volume. The following guardrails are therefore not negotiable:

1. Path jail. Every file operation goes through a single abstraction that resolves the real path and refuses anything leaving the server's volume, symlinks included.
2. Container hardening. Never --privileged, capabilities dropped, no-new-privileges, a PID limit, and the Docker socket is never mounted into a server container.
3. Two-part tokens. API keys are stored hashed; only the public identifier is in the clear. Node tokens are two-part and revocable in the same way, but encrypted rather than hashed — they are a shared secret the panel presents to the daemon as well as one the daemon presents to the panel, and a hash cannot be presented. The key that encrypts them is in .env, never in the database. See docs/security.md.
4. Short-lived console JWTs, carrying the permissions, verified by the daemon on every connection.
5. No shell. Startup commands are templates with validated variables, never a concatenation of strings handed to an interpreter.

While the project is pre-alpha, only the main branch receives security fixes. This section will be updated when 1.0 ships.