Skip to content

Security: executable archives downloaded over plain HTTP with hash verification disabled (nohash) - MITM code execution #4954

Description

@Pajt9whauht283as

Security report (responsible disclosure)

Executable archives fetched over plain HTTP with hash verification disabled (nohash) — MITM code execution

Affected files:

  • lgsm/modules/core_steamcmd.sh:17-19
  • lgsm/modules/update_mta.sh:12-13
  • lgsm/modules/command_install_resources_mta.sh:17-18
fn_fetch_file "http://media.steampowered.com/client/steamcmd_linux.tar.gz" "" "" "" "${tmpdir}" "steamcmd_linux.tar.gz" "nochmodx" "norun" "noforce" "nohash"
fn_dl_extract "${tmpdir}" "steamcmd_linux.tar.gz" "${steamcmddir}"
chmod +x "${steamcmddir}/steamcmd.sh"
fn_fetch_file "http://linux.mtasa.com/dl/multitheftauto_linux_x64.tar.gz" ... "force" "nohash"

Chain

curl -L over plain HTTP (core_dl.sh:445) on first steamcmd install and on MTA updates → nohash bypasses fn_dl_hash entirely (core_dl.sh:217) → archive extracted into ${steamcmddir} / ${serverfiles} → steamcmd.sh is chmod +x'd and executed by every subsequent update/start; MTA binaries run at server start, and MTA resources execute as Lua inside the game server.

Any network attacker on path (or DNS hijack — no TLS involved) replaces the payload and gets shell execution as the LinuxGSM user, re-triggered automatically by update crons.

Severity

High — unauthenticated network position → persistent code execution.

Suggested fix

Serve both URLs over HTTPS (both hosts support it), and pin sha256 checksums the way install_server_files.sh already does for its tarballs. The existing MD5 pinning there is better than nothing but sha256 would be the modern baseline.

Activity

  1. added this to the v26.4.0 milestone on Oct 16, 2026
  2. added a commit that references this issue on Oct 16, 2026
    c5297b7
  3. dgibbs64 commented on Oct 16, 2026

    @dgibbs64
    Member

    Fixed in #5054, merged into develop. SteamCMD, the MTA server binaries (download and build check) and the MTA default resources now download over HTTPS. Downloads that start on HTTPS can no longer be redirected to HTTP. Neither upstream publishes checksums or signatures for these rolling archives, so nothing is pinned. This ships in v26.4.0.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

      Milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions