Is github.com/uozi-tech/cosy safe?

GHSA-m468-xcm6-fxg4

The nginx-ui application is vulnerable to a Race Condition. Due to the complete absence of synchronization mechanisms (Mutex) and non-atomic file writes, concurrent requests lead to the severe corruption of the primary configuration file (app.ini). This vulnerability results in a persistent Denial of Service (DoS) and introduces a non-deterministic path for Remote Code Execution (RCE) through configuration cross-contamination.

The vulnerability exists because the settings update pipeline does not implement any synchronization primitives. When multiple requests reach the handler simultaneously:

• Memory Corruption: ProtectedFill() modifies shared global singleton pointers without thread-safety, leading to inconsistent states in memory.
• File Corruption: The underlying library (gopkg.in/ini.v1) performs direct overwrites. Concurrent write operations interleave at the OS level, resulting in app.ini files with empty leading lines, truncated fields, or partially overwritten configuration keys.
• State Persistent Failure: Depending on which bytes are corrupted, the application either fails its "is-installed" check (redirecting to /install) or encounters a fatal error during boot/runtime that prevents the process from responding to any further requests.

Environment:

• OS: Kali Linux 6.17.10-1kali1 (6.17.10+kali-amd64)
• Application Version: nginx-ui v2.3.3 (513) e5da6dd (go1.26.0)
• Deployment: Docker Container

• Check original app.ini file valid state:

• Log in to the nginx-ui dashboard.
• Navigate to Preferences and update settings. Capture a POST /api/settings request and send it to Burp Suite Intruder.
• Configure the attack with Null payloads (to test basic concurrency) or a Fuzzing list (to test data-driven corruption).
• Set the Resource Pool to 20-50 concurrent requests.

• Observation (In-flight corruption): Monitor the app.ini file. You will observe the file being written with empty leading lines or incomplete key-value pairs.

- ------------------------------------------------

-

• Observation (Recovery Failure): If the service redirects to /install, attempting to complete the setup again often fails because the underlying configuration state is too corrupted to be reconciled by the installer logic.
• Observation (Total Service Collapse): When the corruption in app.ini becomes so severe, the Go runtime or the INI parser encounters a fatal error, causing the Nginx-UI service to stop responding entirely (Hard DoS).

• Observation (Cross-Section Contamination): During testing, it was observed that sometimes INI sections become interleaved. For example, fields belonging to the [nginx] section (like ConfigDir or ReloadCmd) were erroneously written under the [webauthn] section.

Example of corrupted output observed:

[webauthn]
RPDisplayName  = 
RPID           = 
RPOrigins      = 
gDirWhiteList  = 
ConfigDir      = /etc/nginx
ConfigPath     = 
PIDPath        = /run/nginx.pid
SbinPath       = 
TestConfigCmd  = 
ReloadCmd      = nginx -s reload
RestartCmd     = nginx -s stop
StubStatusPort = 51820
ContainerName  = 

This is a High security risk (CWE-362: Race Condition).

• Integrity: Permanent corruption of application settings and system-level configuration.
• Availability: High. The attack results in a persistent Denial of Service that cannot be recovered via the web UI.
• Remote Code Execution (RCE) Risk: Since the application allows updating certain fields (like Node Name) and uses others as shell commands (like ReloadCmd or RestartCmd), the observed "cross-contamination" of INI values means an attacker could potentially force a user-controlled string into a command execution field. If ReloadCmd is overwritten with a malicious payload provided in another field, the next nginx reload will execute that payload. While highly impactful, this specific exploit path is non-deterministic and depends on the precise interleaving of thread execution, making targeted exploitation difficult.

• Implement Mutex Locking: Wrap the ProtectedFill and settings.Save() calls in a sync.Mutex to serialize access to global settings.
• Atomic File Writes: Implement a "write-then-rename" strategy. Write the new configuration to app.ini.tmp and use os.Rename() to replace the original file atomically, ensuring the configuration file is always in a valid state.

A patched version of nginx-ui is available at https://github.com/0xJacky/nginx-ui/releases/tag/v2.3.4.