This document describes how to report security vulnerabilities in fleet-router and the security properties you should assume when deploying it.

Security fixes are provided for the latest 0.2.x release line. Older pre-release versions are not maintained; please upgrade to the latest 0.2.x release before reporting an issue.

Please do not open a public GitHub issue for security vulnerabilities. Public issues disclose the problem before a fix is available and put other users at risk.

Report vulnerabilities privately using GitHub's Private Vulnerability Reporting for this repository. This is the primary and preferred channel:

1. Go to the repository's Security tab: https://github.com/eosrio/fleet-router/security
2. Click Report a vulnerability.
3. Fill in the advisory form with as much detail as you can.

A helpful report typically includes:

• A description of the vulnerability and its potential impact.
• The affected version(s) and platform.
• Steps to reproduce, or a proof of concept.
• The relevant configuration (with any secrets redacted).
• Any suggested remediation, if you have one.

We handle reports on a best-effort basis. We aim to acknowledge new reports within a few business days and will keep you updated on our assessment and any fix as it progresses. We may contact you through the advisory thread for additional details. Please give us a reasonable opportunity to investigate and release a fix before any public disclosure.

fleet-router is designed to run inside a trusted network boundary. Before deploying, you should understand the following known properties. These are documented design limitations, not vulnerabilities, and reports about them will be treated as such.

• Unauthenticated listener. The client-facing WebSocket listener performs no authentication or authorization. Anyone able to reach the listen address can open connections.
• Client TLS is opt-in. The client-facing WebSocket listener defaults to plaintext ws://. Configure tls to terminate wss:// connections with PEM certificates, SNI selection, and automatic certificate reloads. TLS encrypts the connection but does not authenticate or authorize clients.
• Upstream TLS is opt-in. A bare host:port (and an explicit ws:// URL) is still plaintext. wss:// encrypts that upstream hop and verifies the server certificate with rustls against the OS trust store. It does not authenticate the client listener.
• Optional metrics endpoint is unauthenticated. When enabled (metrics_port), the HTTP /health, /ready, /coverage, and /metrics endpoints are served over plaintext HTTP with no authentication.
• Optional chain API is unauthenticated. When a listener sets chain_api, its port answers nodeos-style chain API requests over HTTP by default, or HTTPS when its effective tls configuration is set, with no authentication, like a nodeos HTTP port. Transaction push ("push" in chain_api.allow) and read-only transaction execution ("exec") are off by default. With "push" allowed, anyone who can reach the port can relay transactions through your live nodes; the router writes each push to one node at most once and never resends it. The router logs a warning at startup when push is allowed or the port listens on every interface.

Because of the above, fleet-router must not be exposed directly to the public internet. Deploy it on a trusted/internal network and/or place it behind a reverse proxy (for example nginx, Caddy, or Envoy) that provides access control and terminates TLS when it is not configured in fleet-router.

Upstream SHiP nodes are part of the trust boundary. fleet-router parses bytes received from upstreams via rs_abieos (pure-Rust backend). Only point fleet-router at upstream nodes you operate or otherwise trust. The same holds for frozen range servers and for upstream chain APIs (api_endpoint), which are dialed over plain http://: the router passes their data on to clients.

Reports that demonstrate behavior outside the documented design above are in scope, including (non-exhaustively):

• Memory safety issues, crashes, or panics triggered by client or upstream input that is within the documented protocol.
• Resource-exhaustion vectors that bypass the configured safeguards (max_connections, handshake_timeout_ms, idle_timeout_ms, max_message_bytes, max_client_message_bytes, the 64 KiB per-session failover buffer, and the chain API's max_connections, max_in_flight, max_body_bytes and request timeouts).
• A chain API request that makes the router send a transaction push twice, or send a push or exec request when its class is not in chain_api.allow.
• Logic flaws in failover, de-duplication, or shutdown that lead to data corruption or unexpected disclosure between client connections.

• Plaintext transport when client TLS is not configured, plaintext metrics, and the absence of client authentication or authorization on the listener, the chain API port, and the metrics endpoint (see the design limitations above).
• Issues that require a malicious or compromised upstream that you have explicitly configured and trusted, beyond the memory-safety expectations noted above.
• Vulnerabilities in third-party dependencies that are already tracked upstream; please report those to the relevant project (we monitor advisories via cargo-deny in CI).

• docs/operations.md for deployment and security guidance, docs/configuration.md for the configuration reference, and docs/chain-api.md for the chain API.
• CONTRIBUTING.md for development and pull-request workflow.
• CODE_OF_CONDUCT.md for community expectations.
• CHANGELOG.md for release history.
• LICENSE for licensing terms (MIT).