CVE-2026-50879

Vulnerability

linx-server v2.3.8's uploadPostHandler parses incoming multipart POST requests via Go's r.FormFile("file") before the application-level Config.maxSize check is performed. During this parsing, Go's HTTP server may spool the request body (including the file part) to a temporary directory on disk. The size limit enforced by Config.maxSize is applied only after FormFile returns, meaning an attacker can submit a crafted, oversized multipart payload that consumes temporary disk space even though the upload will ultimately be rejected. This behavior was described in a security advisory detailing the root cause [1].

Exploitation

An unauthenticated remote attacker with network access to the /upload/ endpoint can send a single POST request with a file part exceeding the configured Config.maxSize. The multipart parser writes the oversized content to a temporary location on disk before linx-server rejects the upload due to size. By repeating this request or sending multiple concurrent requests, the attacker can fill the temporary storage directory, leading to a denial-of-service condition [1].

Impact

A successful exploitation results in exhaustion of temporary disk space, which prevents the server from handling subsequent uploads and can disrupt normal operations. The denial of service is achieved without the attacker needing to authenticate or bypass the application's final size limit; the effect is solely on the temporary storage during multipart parsing [1].

Mitigation

As of the available references, no official patch has been published for linx-server v2.3.8. The vendor has not released a fixed version addressing the spooling behavior before the size check. Depending on deployment, operators may mitigate the risk by limiting the size of incoming request bodies at a reverse proxy or load balancer, or by adjusting temporary file system quotas and monitoring disk usage. However, the fundamental issue remains in the v2.3.8 code base [1].