NginxProxyManager Nginx Proxy Manager improper authorization enables Nginx directive injection

Nginx Proxy Manager through 2.16.0 fails to restrict the advanced_config field to administrators, allowing non-admin users with manage permissions to inject arbitrary nginx directives. Attackers can inject malicious nginx configuration such as alias directives to serve arbitrary files or control routing for their assigned hosts.

NginxProxyManager Nginx Proxy Manager:

• Versions from 0 through 2.16.0 are affected when a non-admin user has manage permission for a host.
• The relevant scope includes Proxy Host, Redirection Host, and 404 Host configurations.
• The normalized record gives the product a default status of unaffected outside the stated affected version boundary.
• No exact fixed release is confirmed. The referenced change describes restricting advanced_config editing to administrators, but it is not evidence that a stable release containing the change has been published.

This is a CWE-863 authorization flaw in which access checks for the advanced_config field do not enforce administrator-only editing. An authenticated non-admin user with manage permission for a host can provide arbitrary Nginx directives. The issue report and the proposed hardening change cover Proxy Host, Redirection Host, and 404 Host configurations. In the Nginx Proxy Manager template, advanced_config is inserted directly into the generated server block before the location configuration, so user-controlled content is processed as Nginx configuration rather than inert data. As a result, malicious directives such as alias can cause assigned hosts to serve unintended files or alter request routing. The available evidence does not establish the specific API route, detailed input-validation behavior, or separate limits imposed on individual Nginx directives.

The flaw is remotely reachable through the network-accessible management interface or API. An attacker needs an authenticated account, but does not need administrator status; the account must have manage permission for the target hosts. The normalized record describes no additional user interaction and low exploitation complexity. The supplied record marks public exploit as false and does not establish known exploitation; those statuses do not prove that an undisclosed exploit cannot exist.

When the authorization boundary is bypassed, advanced_config content can be placed into the Nginx configuration for a target host. The documented technical outcomes include serving arbitrary files accessible to Nginx and controlling routing for assigned hosts. Realistic consequences include data exposure or application-traffic manipulation within those hosts. The available evidence does not confirm code execution, escalation to administrator privileges, control of hosts outside the assigned scope, or a system-wide availability impact.

The flaw weakens the boundary between host-management permission and low-level Nginx configuration authority. A non-admin account may expose files reachable by Nginx or change request routing for the hosts assigned to that account. This can create data-exposure risk, misroute application traffic, weaken tenant isolation, and require configuration or access review. The available evidence does not show that the flaw alone grants system-wide administrator access or control over hosts outside the attacker's assigned scope.

1. Apply an NginxProxyManager release that explicitly confirms this issue is fixed as soon as a confirmed release is available. Do not treat a development build or test image as a stable fix when release status is unconfirmed.
2. Until a fixed release is confirmed, remove unnecessary manage permission from non-admin accounts for Proxy Host, Redirection Host, and 404 Host objects. Enforce least privilege.
3. Ensure that the API permits administrators only to create or update advanced_config on every host type. Hiding the Advanced tab in the frontend is insufficient if the API still accepts the field.
4. Review and sanitize existing advanced_config values, and inspect generated Nginx configuration for hosts previously manageable by non-admin accounts.
5. After upgrading or applying the fix, test create and update authorization separately for administrator and non-admin accounts across each affected host type.

1. Inventory every Nginx Proxy Manager deployment and identify installations whose versions fall within the affected boundary in affected_summary.
2. Enumerate non-admin accounts with manage permission for Proxy Host, Redirection Host, or 404 Host objects.
3. Review current and recently changed advanced_config values for directives inconsistent with the intended service, especially changes affecting file serving or request routing.
4. Compare generated Nginx configurations for affected hosts with approved configurations, because this field is inserted into the generated server block.
5. Review available audit logs and change history for host updates performed by non-admin accounts. Absence of suspicious log entries does not prove that the deployment is safe.
6. Additional monitoring of host-configuration changes is a precaution, not a known indicator, because the available evidence does not define specific IOCs or log signatures.