Skip to content

Security: XiLuovo/minecraft-mod-studio

Security

SECURITY.md

Security Policy

Supported boundary

The current release line is 0.1.x and supports the platform pinned in docs/phase-0-freeze.md. Security fixes may be applied only to the current development branch until a stable release policy is established.

Threat model

Minecraft Mod Studio treats model output as untrusted input. Host-side code enforces exact path authority, protected files, fixed verification commands, staging, current checker identity, workspace revisions, and explicit review decisions.

The first release does not treat imported Gradle projects as hostile. Users must run only projects they own and whose Gradle wrapper, build scripts, plugins, and dependencies they trust. Staging prevents Agent file edits from directly touching the imported workspace; it is not an operating-system sandbox for build execution.

The release HTTP interface binds to 127.0.0.1, validates Host and Origin, uses a one-time launch token, and stores the resulting browser-session token in same-origin sessionStorage. The launch URL and session token are local credentials and must not be published in logs, screenshots, or bug reports.

Credential handling

  • Keep real Provider credentials in the Git-ignored .env.local file or the process environment.
  • Never place a real credential in .env.example, fixtures, traces, or test data.
  • Provider-backed evidence must be redacted before publication.
  • mod-studio doctor --json is designed for support and automation: it reports readiness categories without configured paths, Provider endpoints, model names, or credential values. Review any diagnostic artifact before publishing it together with unrelated terminal output.
  • Gradle subprocesses receive a least-privilege environment. Additional non-sensitive variables must be named explicitly with MOD_STUDIO_GRADLE_ENV_ALLOWLIST; credential-like and Host-owned names are rejected before execution.
  • If a credential is exposed, revoke it before reporting the issue.

Reporting a vulnerability

Prefer GitHub private vulnerability reporting when it is enabled for the repository. Otherwise, open a minimal public issue that describes the affected component and impact without including credentials, one-time launch URLs, private Provider endpoints, absolute user paths, or exploit details that would put users at immediate risk.

Useful reports include:

  • the affected commit or release;
  • operating system and Python version;
  • a minimal reproduction using synthetic paths and credentials;
  • whether the imported workspace, staging data, task journal, or Provider data boundary was crossed;
  • the expected and observed safety invariant.

Do not attach a real .env.local, .modstudio directory, Gradle cache, or private mod project.

There aren't any published security advisories