Your RSA-2048 keys break in 2030. Find every one of them before attackers do.
🐹 Go

GHSA-m468-xcm6-fxg4

GHSA-m468-xcm6-fxg4 is a CWE-362 vulnerability in github.com/0xJacky/Nginx-UI. O3 Security confirms whether GHSA-m468-xcm6-fxg4 is actually reachable in your code before you act, and blocks exploitation at runtime until you patch.

nginx-ui has Race Condition that Leads to Persistent Data Corruption and Service Collapse

Also known asCVE-2026-33028GO-2026-4906
Published
Mar 30, 2026
Updated
Apr 2, 2026
Affected
2 pkgs
Patched
1 / 2
Exploits
None indexed

Blast Radius

2 pkgs affected
🐹github.com/0xJacky/Nginx-UI🐹github.com/uozi-tech/cosy

Real-time download stats are indexed for npm and PyPI packages. This vulnerability affects Go packages — download data is not available via public APIs for these ecosystems.

Description

Summary

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.

Details

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

  1. Memory Corruption: ProtectedFill() modifies shared global singleton pointers without thread-safety, leading to inconsistent states in memory.
  2. 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.
  3. 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

PoC

  1. Check original app.ini file valid state:

    <img width="524" height="367" alt="image" src="https://github.com/user-attachments/assets/d9688f76-7fe7-46ea-9eb9-c55bf40918a6" />
  2. Log in to the nginx-ui dashboard.

  3. Navigate to Preferences and update settings. Capture a POST /api/settings request and send it to Burp Suite Intruder.

  4. Configure the attack with Null payloads (to test basic concurrency) or a Fuzzing list (to test data-driven corruption).

  5. Set the Resource Pool to 20-50 concurrent requests.

    <img width="1188" height="776" alt="image" src="https://github.com/user-attachments/assets/403eef43-2bc6-4651-8802-15ddcb4f7631" />
  6. 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.

  • <img width="1316" height="390" alt="image" src="https://github.com/user-attachments/assets/d99553f7-d253-4525-9b45-f59994e69180" />

  • <img width="1368" height="709" alt="image" src="https://github.com/user-attachments/assets/7522ba29-39f1-4c22-88f2-8e859cdb1984" />
  1. 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.
  2. 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).
<img width="1344" height="542" alt="image" src="https://github.com/user-attachments/assets/da4b99dc-ddce-4b79-b0bb-2d634bdd3bf7" />
  1. 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  = 

Impact

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.

Recommended Mitigation

  1. Implement Mutex Locking: Wrap the ProtectedFill and settings.Save() calls in a sync.Mutex to serialize access to global settings.
  2. 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.

Affected Packages

2 total 1 fixed
EcosystemPackageVulnerable rangeFix
🐹Gogithub.com/0xJacky/Nginx-UIall versionsNo fix
🐹Gogithub.com/uozi-tech/cosyall versions1.30.1

Detection & mitigation playbook

Open-source dependency
  1. Detect

    Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for github.com/0xJacky/Nginx-UI. O3's reachability analysis confirms whether the vulnerable code path is actually invoked in your application, so you act on real exposure instead of every transitive match.

  2. Fix

    No patched version of github.com/0xJacky/Nginx-UI has shipped for GHSA-m468-xcm6-fxg4 yet. Where your build allows, override or pin the dependency away from the vulnerable range, and apply any maintainer-recommended mitigation.

  3. Workarounds

    If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.

  4. How O3 protects you

    O3 pinpoints whether GHSA-m468-xcm6-fxg4 is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.

Tailored to GHSA-m468-xcm6-fxg4. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.

Frequently Asked Questions

### Summary 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. ### Details The vulnerability exists because the settings update pipeline does not implement any synchronization primitives. When multiple reque
O3 Security · Impact-Aware SCA

Is GHSA-m468-xcm6-fxg4 in your dependencies?

O3 detects GHSA-m468-xcm6-fxg4 across Go dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.