Check the policy
Read the current repository security guidance before submitting a vulnerability report.
SECURITY
Protect the player.
Protect the platform.
Leviathan’s security model separates authentication secrets, user support data, public bug reports, telemetry and release infrastructure so one surface does not expose more than it needs.
Security Boundary
Secrets stay behind the boundary.
Architecture preview
PROTECTED DATATokens · credentials · private support
Never exposed in public diagnostics or profile surfaces
AUTHIsolated
LOGSRedacted
REPORTSPrivate
REPORTING
Send sensitive findings through the right path.
Security issues should not be posted as ordinary public bugs when doing so could expose an exploit, secret, user information or sensitive reproduction details.
Keep secrets out
Do not paste passwords, access tokens, refresh tokens, XSTS tokens or private account data into public issues.
Provide useful evidence
Include affected version, platform, impact, reproduction conditions and sanitized logs where safe.
Coordinate disclosure
Allow time for triage and remediation before publishing details that could put users at risk.
TRUST BOUNDARIES
Not every subsystem needs every secret.
Authentication, launcher updates, diagnostics, web profiles, support and analytics should use the minimum information required for their job.
✓AuthenticationTokens stay in protected flows and are never placed in Discord messages or public pages.
✓DiagnosticsCollect privacy-safe context with consent and redact known secret patterns.
✓SupportUser-specific cases remain private while reproducible defects can link to public bug IDs.
Boundary mapLeast privilege
A
AuthenticationCredentials and service tokens
ProtectedD
DiagnosticsSanitized technical context
ScopedP
ProfilesSelected public identity
PublicS
SupportPrivate user context
PrivateRELEASE SAFETY
Security also means shipping carefully.
Release integrity should cover source review, dependency awareness, signed or verifiable artifacts where practical, checksums, staged rollout and rollback planning.
Build gates
Automated checks should stop clearly broken or unreviewed changes before release.
Checksums
Published downloads should expose hashes so users and tooling can verify artifact integrity.
Rollback
Updates should have a safe fallback path when a release causes unexpected compatibility problems.
Auditability
Security-sensitive actions and release transitions should leave useful internal audit trails.
Found a security issue?
Use the repository security policy rather than a public support thread for sensitive findings.