This document describes the SolarFlare fork's security posture, supported versions, vulnerability reporting process, and threat model. For upstream Sunshine security policy and advisories, see LizardByte/Sunshine and LizardByte's organization security policy.

SolarFlare does not maintain long-term support (LTS) branches. Security fixes land on master and are included in the next tagged release.

Release artifacts carry two version strings:

When verifying whether a host is patched, check both the installed package version and the version field from GET /api/health.

1. Pull the latest master from this repository.
2. Rebuild or run ./scripts/linux-install.sh.
3. Confirm GET /api/health reports the expected version.

There is no separate security-only branch or hotfix channel.

Report security issues specific to SolarFlare privately via GitHub Security Advisories.

Do not open a public GitHub issue with vulnerability details, proof-of-concept exploits, or credential material.

If private advisory creation is unavailable, open a public issue that asks for a private contact channel only - include no technical details or reproducer in that public thread.

Vulnerabilities that affect stock LizardByte/Sunshine should be reported to upstream security advisories. The fork cherry-picks upstream fixes once they ship; see the changelog for the pick log.

Report privately to this fork first. Maintainers will coordinate with upstream when the issue spans inherited code.

1. Acknowledgement within ~7 days (single-maintainer project; times vary).
2. Reproducer request if one was not provided.
3. Fix on master, cherry-picked from upstream when applicable.
4. Changelog entry in /docs/changelog.
5. Advisory publication when impact warrants coordinated disclosure.

The fork does not ship backports to older release branches. Whether a fork-specific report becomes a published GitHub Security Advisory depends on impact and the coordinated-disclosure process.

Inherited upstream code may interact with fork-specific changes. Treat the combined deployment as in scope when assessing risk.

SolarFlare is designed as a self-hosted game-streaming server for trusted local networks. The baseline assumption is that the LAN is more trustworthy than the public Internet, but not that every device on the LAN is benign.

┌─────────────────────────────────────────────────────────────┐
│  Internet (untrusted)                                       │
└───────────────────────────┬─────────────────────────────────┘
                            │  origin_web_ui_allowed = wan (discouraged)
┌───────────────────────────▼─────────────────────────────────┐
│  LAN / home network (semi-trusted)                          │
│  ┌─────────────┐  ┌──────────────┐  ┌──────────────────┐   │
│  │ Moonlight   │  │ Web browser  │  │ Automation/script│   │
│  │ clients     │  │ (Web UI)     │  │ (curl + token)   │   │
│  └──────┬──────┘  └──────┬───────┘  └────────┬─────────┘   │
│         │ GameStream      │ /api/* + CSRF     │ Bearer       │
│         ▼                 ▼                   ▼              │
│  ┌──────────────────────────────────────────────────────┐  │
│  │              SolarFlare host process                  │  │
│  │  nvhttp (47989)  │  confighttp (47990)  │  stream   │  │
│  └──────────────────────────────────────────────────────┘  │
└───────────────────────────┬─────────────────────────────────┘
                            │  webhook POST (optional)
┌───────────────────────────▼─────────────────────────────────┐
│  User-configured webhook endpoints                          │
└─────────────────────────────────────────────────────────────┘

The Web UI enforces a network-class gate before authentication:

Clients outside the allowed class receive HTTP 403 with no JSON body. This is a coarse network ACL, not a substitute for strong credentials.

Recommendation: Keep the default lan. Use pc on multi-user hosts where only local administrators should reach the UI. Avoid wan unless the UI is behind a separate reverse proxy with its own access controls.

Configuration: origin_web_ui_allowed.

Both listeners use the configured X.509 certificate. Moonlight clients pin the server certificate at pairing time. Browsers will warn on the self-signed default until a trusted cert is installed.

Threats mitigated: passive eavesdropping on the control plane and stream setup when TLS is used end-to-end.

Residual risk: A LAN attacker who obtains the private key or mounts a successful MITM before pairing can impersonate the host to new clients. Already-paired clients reject certificate changes unless re-paired.

Security headers on JSON API responses include Strict-Transport-Security (HSTS) and X-Frame-Options: DENY.

Token hygiene:

• Mint tokens with the minimum scopes required (POST /api/tokens).
• Persist api_tokens lines from the log immediately; plaintext cannot be recovered.
• Rotate tokens by deleting (DELETE /api/tokens/{name}) and minting anew.
• Prefer Bearer tokens over embedding the admin password in scripts.

Scope enforcement: Authenticated requests missing the required scope receive HTTP 403 with "Token does not have the required scope for this endpoint".

See api for the full scope-to-endpoint matrix.

State-changing /api/* endpoints validate CSRF tokens when the request looks like a cross-origin browser call (Origin / Referer present and not on the allow list). Non-browser clients without those headers are exempt.

Allowed origins include localhost variants plus csrf_allowed_origins. Misconfiguration can weaken CSRF defenses - only add origins you fully trust.

When trusted_subnet_auto_pairing is enabled, Moonlight clients whose source IP falls within trusted_subnets (CIDR list) are paired without a PIN.

Recommendation: Disable auto-pairing unless you control every device on the listed subnets. Prefer explicit PIN pairing for guest networks and IoT VLANs.

Configuration: trusted_subnet_auto_pairing, trusted_subnets.

On stream start/end, SolarFlare POSTs JSON to every webhook_url_* entry (fire-and-forget, short timeout, up to 2 retries per URL).

Receiver obligations: Verify the HMAC before acting on webhook payloads. Treat webhook endpoints as authenticated callbacks, not public APIs.

Payload fields: event (stream.start / stream.end), session timing, client address, codec, resolution, bitrate/RTT averages, error end reason. Same shape as /api/sessions records.

Threats: A network observer who learns an unsigned webhook URL could spoof events. Use webhook_secret and TLS on the receiver.

Pairing, app launch, and streaming use nvhttp routes (/pair, /launch, …) on the main HTTPS port, not /api/*. Compromise of a paired client certificate allows session initiation subject to host app configuration.

TLS handshake concurrency on the GameStream HTTPS server is capped (64 concurrent handshakes) to reduce DoS via slow handshakes.

Linux self-update (/api/update/*) downloads release artifacts from GitHub, verifies SHA-256 checksums, and stages before apply. Protect admin credentials

• POST /api/update/apply with when_idle: false can replace the running binary immediately.

GET /api/browse lists directories accessible to the SolarFlare process. Combine strong auth, origin_web_ui_allowed = pc or lan, and OS-level permissions to limit readable paths.

Critical security fixes from upstream Sunshine are cherry-picked onto this fork as soon as upstream ships them. Monitor both repositories for security advisories affecting inherited components (OpenSSL, FFmpeg, libcurl, etc. are bundled or linked per platform).

Release notes: changelog.

Security research conducted in good faith on software you own or have permission to test is welcome. Do not access systems or networks without authorization. See legal for licensing and trademark notices.