CVE-2026-33028
Race Condition in Nginx-UI Causes DoS and RCE Risk
Publication date: 2026-03-30
Last updated on: 2026-04-01
Assigner: GitHub, Inc.
Description
Description
CVSS Scores
EPSS Scores
| Probability: | |
| Percentile: |
Meta Information
Affected Vendors & Products
| Vendor | Product | Version / Range |
|---|---|---|
| nginxui | nginx_ui | to 2.3.4 (exc) |
| uozi | cosy | to 1.30.1 (exc) |
Helpful Resources
Exploitability
| CWE ID | Description |
|---|---|
| CWE-362 | The product contains a concurrent code sequence that requires temporary, exclusive access to a shared resource, but a timing window exists in which the shared resource can be modified by another code sequence operating concurrently. |
Attack-Flow Graph
AI Powered Q&A
How does this vulnerability affect compliance with common standards and regulations (like GDPR, HIPAA)?:
The vulnerability in nginx-ui leads to persistent Denial of Service (DoS) and potential Remote Code Execution (RCE) through configuration corruption. This impacts the integrity and availability of the application and system configurations.
Such impacts on integrity and availability can affect compliance with standards like GDPR and HIPAA, which require ensuring the confidentiality, integrity, and availability of systems and data. Persistent DoS and risk of unauthorized code execution could lead to violations of these requirements, potentially resulting in non-compliance.
Can you explain this vulnerability to me?
CVE-2026-33028 is a high-severity race condition vulnerability in the nginx-ui application (versions up to 2.3.3). The issue occurs because the application lacks synchronization mechanisms like Mutex locks and uses non-atomic file writes when updating its primary configuration file, app.ini.
When multiple requests update the configuration concurrently, this leads to memory corruption, file corruption, and persistent failure states. Specifically, the configuration file can become corrupted with empty lines, truncated fields, or interleaved sections, causing the application to fail checks or crash.
Additionally, this corruption can cause configuration cross-contamination, where fields from one section appear in another. This can allow user-controlled input to be injected into shell command fields, creating a non-deterministic path for remote code execution (RCE).
The vulnerability has been patched in version 2.3.4 by adding synchronization and atomic file write mechanisms.
How can this vulnerability impact me? :
This vulnerability can impact you in several ways:
- Integrity: The primary configuration file can become permanently corrupted, leading to inconsistent or invalid settings.
- Availability: The application can enter a persistent Denial of Service (DoS) state, becoming unresponsive and unable to recover through the web UI.
- Remote Code Execution: Due to configuration cross-contamination, attackers may inject malicious payloads into shell command fields, potentially executing arbitrary code on the server.
Overall, this vulnerability threatens the stability and security of the nginx-ui service, potentially causing downtime and unauthorized code execution.
How can this vulnerability be detected on my network or system? Can you suggest some commands?
This vulnerability can be detected by observing corruption in the primary configuration file app.ini of the nginx-ui application. Signs include incomplete key-value pairs, empty leading lines, truncated fields, or interleaved INI sections that do not conform to expected configuration semantics.
A practical detection method involves sending multiple concurrent POST requests to the /api/settings endpoint and monitoring the app.ini file for corruption. For example, using tools like Burp Suite Intruder to send 20-50 concurrent POST requests with null or fuzzed payloads can reproduce the issue and reveal corrupted configuration files.
To check for corruption on your system, you can manually inspect the app.ini file for anomalies using commands such as:
- cat /path/to/app.ini | head -20 # Check for empty leading lines or truncated fields
- grep -E '^\[|=' /path/to/app.ini # Verify correct section headers and key-value pairs
- diff /path/to/app.ini /path/to/app.ini.bak # Compare with a known good backup to detect corruption
Additionally, monitoring the nginx-ui service logs for fatal errors during boot or runtime can indicate persistent Denial of Service caused by corrupted configuration.
What immediate steps should I take to mitigate this vulnerability?
The immediate mitigation step is to upgrade the nginx-ui application to version 2.3.4 or later, where this race condition vulnerability has been patched.
If upgrading is not immediately possible, consider the following temporary mitigations:
- Implement Mutex locking or other synchronization mechanisms to serialize access to shared global settings during configuration updates.
- Modify the configuration update process to use atomic file writes by writing updates to a temporary file (e.g., app.ini.tmp) and then atomically replacing the original app.ini using a rename operation.
These mitigations reduce the risk of concurrent writes causing configuration corruption and potential Denial of Service or Remote Code Execution.