CVE-2026-107809: Nginx UI CSRF Vulnerability

CVE-2026-107809 Overview

CVE-2026-107809 is a Cross-Site Request Forgery (CSRF) vulnerability in Nginx UI, a web user interface for the Nginx web server. The flaw affects versions 2.0.0 through 2.4.x and is fixed in version 2.5.0. The AuthRequired middleware accepts a browser-managed token cookie as an API credential after the front end stores the JWT in that cookie. Management endpoints do not universally require a CSRF token or perform Origin or Referer validation. A remote attacker can induce a logged-in administrator's browser to submit authenticated cross-site state-changing requests, including POST /api/configs.

Critical Impact
An attacker can modify Nginx configuration, trigger reloads, or invoke other management operations reachable with the victim's authenticated session, enabling full compromise of web server configuration.

Affected Products

Nginx UI versions 2.0.0 through 2.4.x
Deployments where administrator accounts do not have OTP or Passkey enabled
Management endpoints that do not require secure-session proof

Discovery Timeline

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

Technical Details for CVE-2026-107809

Vulnerability Analysis

The vulnerability [CWE-352] stems from treating a browser-managed cookie as a valid API credential without binding state-changing requests to anti-CSRF protections. When an administrator authenticates to Nginx UI, the front end stores the JWT inside a cookie. The AuthRequired middleware then accepts that cookie as proof of identity on subsequent requests. Because the browser automatically attaches cookies to cross-origin requests, any site the administrator visits can trigger authenticated API calls.

Management endpoints such as POST /api/configs do not validate Origin or Referer headers, and they do not require a dedicated anti-CSRF token. An attacker hosting a malicious page can submit a crafted form or fetch call that reaches the Nginx UI instance using the victim's session.

While the attacker cannot read the cross-origin response due to the Same-Origin Policy, the write-side impact is sufficient to alter Nginx configuration, trigger reloads, or invoke other administrative operations.

Root Cause

The root cause is missing CSRF protection on authenticated state-changing endpoints combined with cookie-based credential acceptance. Session binding relies solely on the automatically transmitted JWT cookie, without a second factor such as an Authorization header carrying the same token or a per-request CSRF nonce.

Attack Vector

Exploitation requires a logged-in administrator to visit an attacker-controlled page while an active session exists. The attack targets accounts that do not have OTP or Passkey enforced, or endpoints that do not require secure-session proof. User interaction is required, but no privileges or credentials are needed by the attacker.

// Patch excerpt: api/audit/middleware.go
// feat: add signed node authentication and mark sensitive requests
package audit

import (
	"encoding/json"

	"github.com/0xJacky/Nginx-UI/model"
	"github.com/gin-gonic/gin"
	"github.com/spf13/cast"
	"github.com/uozi-tech/cosy/logger"
)

const (
	sensitiveRequestAuditKey  = "SensitiveRequestAudit"
	sensitiveResponseAuditKey = "SensitiveResponseAudit"
)

// MarkSensitiveRequest prevents one-time or legacy credentials in a request
// from being copied into audit storage.
func MarkSensitiveRequest(c *gin.Context) {
	c.Set(sensitiveRequestAuditKey, true)
}

// MarkSensitiveResponse prevents one-time credentials in a response from
// being copied into audit storage.
func MarkSensitiveResponse(c *gin.Context) {
	c.Set(sensitiveResponseAuditKey, true)
}

Source: GitHub commit a3999bd

The patch introduces signed node authentication and markers that prevent one-time credentials from leaking into audit storage. It is part of the broader fix that hardens cross-origin request validation in version 2.5.0.

Detection Methods for CVE-2026-107809

Indicators of Compromise

Unexpected POST /api/configs requests in Nginx UI access logs with Referer or Origin headers from unrelated external domains
Unplanned Nginx configuration changes or reload events correlated with administrator browsing activity
New or modified configuration files on disk without a corresponding change-management entry

Detection Strategies

Correlate authenticated management API calls with Origin and Referer headers to flag cross-site submissions
Audit configuration file hashes before and after administrator sessions to detect unauthorized changes
Review Nginx UI audit logs for state-changing operations performed outside maintenance windows

Monitoring Recommendations

Forward Nginx UI access logs and audit logs to a central log pipeline for correlation
Alert on reload operations triggered within seconds of a browser request originating from an external referer
Track administrator session activity, including source IP, user agent, and endpoint usage patterns

How to Mitigate CVE-2026-107809

Immediate Actions Required

Upgrade Nginx UI to version 2.5.0 or later, which contains the fix
Enforce OTP or Passkey multi-factor authentication on every administrator account
Restrict access to the Nginx UI management interface to trusted networks or VPN-only ingress

Patch Information

The fix is included in Nginx UI release v2.5.0. See the GitHub Release v2.5.0, the GitHub Security Advisory GHSA-33rr-wq23-g6gg, and the patch commit a3999bd.

Workarounds

Place Nginx UI behind a reverse proxy that enforces strict Origin and Referer validation for state-changing routes
Require administrators to log out of Nginx UI when not actively administering the server
Use a dedicated browser profile for Nginx UI administration to reduce exposure to malicious cross-origin pages

bash

# Example reverse proxy snippet enforcing Origin validation for /api/
location /api/ {
    if ($request_method ~ ^(POST|PUT|PATCH|DELETE)$) {
        set $csrf_block "1";
    }
    if ($http_origin ~* ^https://nginx-ui\.example\.com$) {
        set $csrf_block "0";
    }
    if ($csrf_block = "1") {
        return 403;
    }
    proxy_pass http://nginx_ui_backend;
}