This project is independently maintained. Security reports for this repository should concern the Dockerfile, container entrypoint and helper scripts, GitHub Actions workflows, published GHCR images, or the way those pieces integrate tModLoader.

Vulnerabilities in tModLoader, Terraria, SteamCMD, or another bundled upstream component should normally be reported to that component's maintainers. If the container makes an upstream issue exploitable in a new way, please report it here as well.

Security fixes are applied to images built from the current master branch. The release workflows refuse to reuse numbered release tags. The latest and preview aliases can move as the container changes. Pin an image digest when an immutable deployment is needed. Older image digests do not receive in-place updates.

GitHub private vulnerability reporting is not currently enabled for this repository. Open a minimal public issue that asks the maintainer to establish a private contact channel. Do not include exploit details, secrets, private server data, or other information that would make the vulnerability easier to abuse. Once a private channel is available, provide the complete report there.

Include as much of the following as possible:

• The affected image tag and digest.
• The affected file, command, or configuration.
• Reproduction steps and the expected impact.
• Whether the issue is reachable over the network or requires host access.
• A proposed mitigation or patch, if one is available.

Remove passwords, tokens, world data, player addresses, and other private data from logs before attaching them. There is no guaranteed response-time SLA, but reports will be reviewed as maintainer availability permits. Please allow time for a fix and rebuilt image before public disclosure.

• Set a unique server password, preferably through TMOD_PASS_FILE.
• Publish only the configured Terraria TCP port. Never mount the Docker socket or unrelated host directories into this container.
• Keep /data writable only by trusted host users and include it in backups.
• The published image uses root only for its ownership-repair initializer. It then changes to the dedicated tml user (1000:1000) and replaces the root process with tini; the supervisor and server retain no effective Linux capabilities. Do not override the container user or entrypoint.
• Compose drops every capability except CHOWN, DAC_OVERRIDE, FOWNER, SETGID, and SETUID, which initialization needs for /data and /backups. The UID/GID switch clears them, and no-new-privileges prevents reacquisition.
• Because the configured startup identity is root, run arbitrary interactive commands with docker compose exec --user tml:tml. The supplied healthcheck, console injector, and backup command drop privileges themselves.
• Startup recursively assigns /data and /backups to tml:tml and grants owner access on directories. Mount only dedicated persistent paths there and review the host targets before starting the container.
• Keep Docker, the host operating system, and the deployed image updated.
• Use an image digest when deployment policy requires a reviewed, immutable artifact.