GHSA-j3hg-9rp3-5hw9: High severity go/github.com/0xJacky/Nginx-UI vulnerability
Summary
In Nginx UI versions 2.5.0 through 2.5.x, the node-signature authentication path staged an attacker-controlled request body in a temporary file and synchronized it to disk before validating the body digest and cryptographic signature. An unauthenticated remote client that can reach the API can provide syntactically valid signature metadata and cause storage and I/O consumption before the request is rejected.
Impact
Concurrent malicious requests can consume temporary filesystem capacity, disk I/O, and request-processing resources, potentially disrupting Nginx UI and other services that share the filesystem. The issue affects availability only; it does not bypass authentication and does not provide confidentiality or integrity impact. Deployment-specific reverse-proxy body limits, filesystem quotas, and concurrency limits may reduce practical impact.
Remediation
Upgrade to Nginx UI 2.6.0 or later. The fix authenticates signed request metadata before staging the body and enforces an application-level streaming size limit with cleanup for rejected requests.
Fix commit: https://github.com/0xJacky/nginx-ui/commit/8c9b9a1aff218ee6c980d047b750e49da3c46796
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
go/github.com/0xJacky/Nginx-UIto a version that resolves this vulnerability.Fixed in 1.9.10-0.20260901043436-8c9b9a1aff21 - Upgrade
Upgrade
Nginx UIto a version that resolves this vulnerability.Fixed in 2.6.0 - Compensating control
Apply deployment-specific reverse-proxy request-body limits, filesystem quotas, and concurrency limits to reduce temporary filesystem, disk I/O, and request-processing resource consumption.
Event History
Frequently Asked Questions
Which deployments are exposed to this issue?
Nginx UI versions 2.5.0 through 2.5.x are affected when an unauthenticated remote client can reach the API and invoke the node-signature authentication path. Practical impact may be reduced by reverse-proxy body limits, filesystem quotas, or concurrency limits.
What does an attacker need to do to cause impact?
The attacker does not need authentication. They need network access to the API and must submit syntactically valid signature metadata with an attacker-controlled request body, causing the body to be staged and synced before digest and signature validation rejects it.
What is the impact if exploitation succeeds?
Concurrent requests can consume temporary filesystem space, disk I/O, and request-processing resources, potentially disrupting Nginx UI and other services sharing that filesystem. The issue affects availability only and does not bypass authentication or expose or modify data.
What should be done if an immediate upgrade is not possible?
Restrict unauthenticated access to the API where possible, and use reverse-proxy body limits, filesystem quotas, and concurrency limits to reduce resource consumption. Upgrade to Nginx UI 2.6.0 or later when possible.