CVE-2026-107805: Nginx UI DOS Vulnerability

CVE-2026-107805 Overview

Nginx UI, a web user interface for the Nginx web server, contains a resource exhaustion vulnerability in its node-signature authentication path. From version 2.5.0 until 2.6.0, the authentication path stages attacker-controlled request bodies to temporary files and synchronizes them before validating the body digest or cryptographic signature. An unauthenticated remote client reachable at the API can supply syntactically valid signature metadata to consume temporary filesystem capacity, disk I/O, and request-processing resources. The issue is tracked as [CWE-400] Uncontrolled Resource Consumption. The vulnerability affects availability only and does not bypass authentication or impact confidentiality or integrity. The issue is fixed in version 2.6.0.

Critical Impact
Unauthenticated remote attackers can exhaust disk space, I/O capacity, and request-processing resources on affected Nginx UI nodes, resulting in denial of service.

Affected Products

Nginx UI version 2.5.0
Nginx UI versions above 2.5.0 and below 2.6.0
Fixed in Nginx UI version 2.6.0

Discovery Timeline

2026-10-09 - CVE-2026-107805 published to NVD
2026-10-13 - Last updated in NVD database

Technical Details for CVE-2026-107805

Vulnerability Analysis

The flaw resides in the node-signature authentication logic implemented in internal/nodeauth/. When the API receives a signed node request, the handler writes the full request body to a temporary file on disk and calls sync before computing the SHA-256 digest and validating the cryptographic signature. This ordering lets any network-reachable, unauthenticated client stream arbitrary payload sizes to disk before the server has an opportunity to reject the request. Repeated or concurrent requests can exhaust temporary filesystem capacity, saturate disk I/O, and tie up request handlers.

Root Cause

The root cause is the absence of an upper bound on the staged request body size prior to signature verification. The patch in commit 8c9b9a1 introduces maxStagedRequestBodySize of 128 MiB and rejects requests whose ContentLength exceeds that threshold before any disk staging occurs. The weakness is categorized as [CWE-400] Uncontrolled Resource Consumption.

Attack Vector

The vulnerability is reachable over the network without authentication or user interaction. An attacker only needs the ability to send HTTP requests to the Nginx UI API endpoint that handles node-signature authentication. The attacker provides a request with syntactically valid signature metadata and a large body. The body is written to a temporary file and fsynced before validation fails, consuming resources regardless of whether the signature ultimately verifies.

// Patch excerpt - internal/nodeauth/body.go
import (
    "crypto/sha256"
    "encoding/base64"
    "errors"
    "fmt"
    "hash"
    "io"
    "net/http"
    "os"
)

// Keep signed node traffic within the bundled reverse proxy's upload limit,
// including deployments that expose the application server directly.
const maxStagedRequestBodySize int64 = 128 << 20

var errRequestBodyTooLarge = errors.New("node request body is too large")

type temporaryRequestBody struct {
    *os.File
    path string

// Patch excerpt - internal/nodeauth/signature.go
if request == nil || database == nil {
    return nil, errors.New("node signature verifier is unavailable")
}
if request.ContentLength > maxStagedRequestBodySize {
    return nil, requestBodyTooLargeError(maxStagedRequestBodySize)
}
if request.URL.Query().Has("node_secret") {
    return nil, errors.New("node credentials are not accepted in query parameters")
}

Source: GitHub Commit 8c9b9a1

Detection Methods for CVE-2026-107805

Indicators of Compromise

Rapid growth of the temporary directory used by the Nginx UI process, with files appearing and disappearing around node-signature authentication requests.
HTTP requests to Nginx UI node authentication endpoints containing large Content-Length headers from unauthenticated or unexpected source addresses.
Repeated signature verification failures in Nginx UI logs correlated with disk I/O spikes.

Detection Strategies

Monitor disk space, inode usage, and I/O latency on hosts running Nginx UI versions 2.5.0 through pre-2.6.0 builds.
Alert on bursts of HTTP requests to node-signature authentication paths that terminate in verification failures.
Review reverse proxy access logs for anomalous request body sizes directed at Nginx UI API endpoints.

Monitoring Recommendations

Set thresholds on temporary filesystem utilization and page requests when sustained growth is observed on Nginx UI hosts.
Instrument the Nginx UI process to track request handler saturation and queue depth.
Forward Nginx UI and upstream reverse proxy logs to a centralized analytics platform for correlation of request rates, body sizes, and verification failures.

How to Mitigate CVE-2026-107805

Immediate Actions Required

Upgrade Nginx UI to version 2.6.0 or later, which enforces the 128 MiB bound on staged request bodies.
Restrict network reachability of the Nginx UI API to trusted management networks until the upgrade is applied.
Enforce an upstream request body size limit at the reverse proxy fronting Nginx UI.

Patch Information

The fix is included in Nginx UI v2.6.0. The relevant change is commit 8c9b9a1aff218ee6c980d047b750e49da3c46796, which adds a maxStagedRequestBodySize constant of 128 MiB and rejects requests whose ContentLength exceeds the bound before any disk staging occurs. See the GitHub Security Advisory GHSA-j3hg-9rp3-5hw9 and the GitHub Release v2.6.0 for release notes.

Workarounds

Place Nginx UI behind a reverse proxy that enforces client_max_body_size at or below 128 MiB on the node authentication endpoints.
Apply network-level access control lists so that only authorized nodes can reach the Nginx UI API.
Monitor temporary filesystem utilization and configure alerts to detect sustained growth tied to signature verification failures.

bash

# Example Nginx reverse proxy configuration to bound request bodies
server {
    listen 443 ssl;
    server_name nginx-ui.example.com;

    location / {
        client_max_body_size 128m;
        proxy_pass http://127.0.0.1:9000;
        proxy_read_timeout 30s;
        proxy_send_timeout 30s;
    }

    # Restrict to trusted management network
    allow 10.0.0.0/24;
    deny all;
}