P4: Standalone web API can read past its request buffer on a large request body

Open Beginner friendly
  • Is something wrong?
#7,965 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

@dustinspace217 is already working on this.

Since Oct 31, 2026.

  • #7975 by @dustinspace217 — open

Assessment

Difficulty
2/5
Estimated time
1-3 hours
Newbie friendliness
65/100
Issue type
Bug
Clarity
Clearly specified
Activity status
Active
Tech stack
cpp
Domain
backend, security

Research direction

Start by inspecting code/network/stand_gui-unix.cpp around lines 650–656, where mg_read fills entityBuffer and json_loads parses it. Check how the returned byte count can be used to keep parsing within the buffer, and how oversized bodies should be handled. Done when a request body at or above 1,024 bytes cannot make the parser read past the buffer and the server handles it safely.

Written by the indexing model from the issue text.

Description

Low priority: it needs the web panel login, only affects Linux and Mac dedicated servers, and I found it by reading the code, not by running it.

Problem

On a Linux or Mac dedicated server, the web API reads a request body into a 1,024-byte buffer and then parses it as text. When the body is 1,024 bytes or longer, the buffer is filled completely and has no zero byte at the end, so the parser keeps reading past the buffer until it happens to hit one. That can produce garbage input or crash the server.

The code is in code/network/stand_gui-unix.cpp on master (8afa31842), lines 650-656: mg_read fills entityBuffer with up to sizeof(entityBuffer) bytes, then json_loads reads it as a zero-terminated string. The byte count mg_read returns is commented out and unused.

Steps to reproduce (not run; from reading the code)

  1. Start a dedicated server on Linux: fs2_open -standalone with any mod, so the web panel starts on its port (8080 by default).
  2. Send an authenticated PUT /api/1/server or POST /api/1/chat with a body of 1,024 bytes or more.
  3. The JSON parser reads past the end of the 1,024-byte buffer.

Expected vs. actual behavior

Expected: an oversized body is cut off or rejected, and the server keeps running.
Actual (from the code): the parser reads memory past the buffer, which may give a parse error, wrong input, or a crash.

Proposed fixes

  1. Read one byte less so the zero byte from the memset always stays at the end: mg_read(conn, entityBuffer, sizeof(entityBuffer) - 1).
  2. Keep the byte count mg_read returns and parse with json_loadb, which takes a length and never looks for a zero byte.
  3. Read the whole body (up to a sane cap) into an SCP_string and reply with an error when it is too large, so long chat messages are not silently cut off either.
Dominant language
C++
Stars
488
Forks
184
Avg merge
1d 19h
Merged PRs (30d)
32

Getting set up

We have not checked this project's setup files yet. Start from its README, and see our first-contribution guide for the general steps.

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from scp-fs2open/fs2open.github.com

All issues in scp-fs2open/fs2open.github.com

Similar issues

More C++ issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.