NginxProxyManager Nginx Proxy Manager: authenticated OS command injection enables remote code execution

Nginx Proxy Manager versions 2.9.14 through 2.15.1, fixed in commit a5db5ed, contain an authenticated remote code execution vulnerability via OS command injection in the setupCertbotPlugins() function in backend/setup.js, allowing attackers with certificates:manage permission to execute arbitrary commands by storing a malicious payload in the dns_provider_credentials field. The user-controlled dns_provider_credentials value is interpolated directly into a shell command executed via child_process.exec() without sanitization or escaping, causing the injected command to execute upon backend restart.

• NginxProxyManager nginx-proxy-manager is affected from 2.9.14 through 2.15.1, inclusive, under semantic versioning.
• Commit a5db5ed is identified by the record and the project source as the fixing state. It replaces shell-based credential-file creation with direct file operations.
• The project's v2.16.0 release notes list the related RCE fix involving escape handling. This is a tagged release verified in the consulted source to contain the related change.
• v2.15.1 was released before the fixing commit was merged and should not be treated as fixed.

NginxProxyManager Nginx Proxy Manager processes DNS credential data in the setupCertbotPlugins() function in backend/setup.js. The user-controlled dns_provider_credentials field is inserted into a shell command and executed through child_process.exec() without safe neutralization or escaping. Shell metacharacters can therefore alter the command structure and cause arbitrary commands to run when the backend restarts and processes the stored value. The attack requires network reachability, an authenticated account with certificates:manage, the ability to store a value in the field, and a backend restart or equivalent initialization trigger; the record does not establish the exact API or persistence path used to store the value. The fix removes shell command construction for this operation and uses direct Node.js file operations instead. The actual runtime user still needs to be verified because the backend process privileges determine the practical scope of impact.

The vulnerability can be reached remotely through the application's interface or API, but it requires an authenticated account with certificates:manage. No separate victim interaction is required for execution, although the backend must restart or enter the relevant initialization path to process the stored data. The supplied record characterizes the attack complexity as low and identifies a triggering condition associated with backend restart. The record does not identify a specific public exploit; the returned enrichment also records Exploitation: none within the scope of its assessment. This does not prove that exploitation is impossible or absent elsewhere.

Successful exploitation results in arbitrary command execution in the security context of the backend process. This can affect the confidentiality, integrity, and availability of the Nginx Proxy Manager instance, including exposure of secrets, unauthorized data changes, or service disruption where the process has the required access. Because the flaw requires authentication and certificates:manage, an ordinary account without that permission does not meet the complete exploitation precondition described by the record. If the backend runs as root in a container, the impact inside that container may be extensive; the record does not establish host compromise or container escape. The practical outcome depends on runtime privileges, secret storage, and deployment isolation.

A successful exploit can allow command execution with the privileges of the backend process, enabling unauthorized changes to data or configuration accessible to that process.

• Secrets, TLS keys, or database contents may be exposed if the runtime user can access them.
• The service may be disrupted or its configuration altered, and persistence may be possible if the compromised process has sufficient privileges.
• In Docker deployments where the backend runs as root, the impact inside the container may be broader. Host compromise or container escape should not be assumed.

1. Upgrade affected deployments to v2.16.0, whose release notes list the related RCE fix. If deploying from source, move to commit a5db5ed or verify that another commit applies the same direct-file-operation change instead of shell construction.
2. Do not treat v2.15.1 as fixed. Check the actual image version, release tag, and source commit because an image or source build may not match the version displayed by the application.
3. Until the upgrade is complete, tightly restrict certificates:manage to trusted accounts and prevent untrusted data from being stored in dns_provider_credentials. This reduces exposure but does not replace the fix.
4. If a malicious value may have been stored or a command may have executed, handle the system as potentially compromised: preserve evidence, review restart activity, and rotate secrets, TLS keys, or credentials that the backend could access.
5. After upgrading, verify that the deployed code uses fs.mkdir and fs.writeFile for credential-file handling rather than continuing to construct a shell command from user-controlled data.

1. Inventory Nginx Proxy Manager deployments and identify the exact running version or commit, especially for instances in the affected range.
2. Enumerate accounts and roles with certificates:manage, and review recent certificate configuration changes and updates to dns_provider_credentials.
3. Review stored values for unexpected shell syntax or command-control characters. This is a precautionary heuristic, not a confirmed IOC.
4. Review audit logs, container logs, and process telemetry around backend restarts for unexpected shells or child processes created by the backend. Absence of suspicious log evidence does not prove that the system is safe.
5. Verify that the running code writes credential files through direct fs operations rather than constructing a shell command through child_process.exec().