Command injection in jc21 Nginx Proxy Manager enables remote code execution

A Command injection vulnerability in requestLetsEncryptSsl in NginxProxyManager 2.11.3 allows an attacker to RCE via Add Let's Encrypt Certificate.

• jc21 Nginx Proxy Manager 2.11.3: affected according to the normalized record.
• v2.12.0: release containing the fix commit linked by the project to this issue; the fix adds domain-name validation and tests for the PoC cases.
• The status of parallel release branches or other releases is not established by the evidence reviewed. Do not assume that every branch after v2.12.0 has been independently verified.

The affected component is requestLetsEncryptSsl in backend/internal/certificate.js. The affected code builds a shell command for certbot, places certificate.domain_names into that command, and passes the assembled command to utils.exec. This flow allows data controlled through Add Let's Encrypt Certificate to reach a command executed by the Nginx Proxy Manager process. The project's fix commit adds schema validation for domain names that rejects shell special characters and adds integration coverage for PoC examples. The available evidence does not fully establish the exact HTTP route, authorization conditions for every deployment, or whether the process runs inside a container or directly on the host. If execution succeeds, the command runs with the permissions of the Nginx Proxy Manager service.

The vulnerability is network reachable, and the normalized record describes low attack complexity with no required privileges and no user interaction. The record also confirms that a public exploit exists, while the public PoC README documents a flow that enters credentials and obtains a token, so the practical authentication requirement should be checked for each deployment. The supplied evidence does not establish observed exploitation, a specific campaign, a named victim, or indicators of compromise. Payloads and operational exploitation steps are intentionally not reproduced here.

The technical outcome is command execution in the Nginx Proxy Manager service context, with potentially high confidentiality, integrity, and availability impact over resources accessible to that service. The normalized assessment describes the scope as unchanged, but real-world impact still depends on process permissions, container isolation, and mounted files or secrets. A compromised instance could be used to change reverse proxy configuration, access certificate data, or disrupt service. Escape beyond the host or container boundary is not established by the available evidence.

Successful exploitation could compromise the Nginx Proxy Manager process and allow changes to data or configuration available to that service. Depending on service permissions and isolation, an attacker could expose certificate material, secrets, reverse proxy configuration, or data belonging to upstream services. Changes to proxy configuration or certificate workflows could cause service disruption, incorrect routing, or certificate replacement work. The available evidence does not establish a specific breach, so actual impact depends on the service permissions and deployment telemetry.

1. Upgrade Nginx Proxy Manager from 2.11.3 to v2.12.0, the release associated by the repository with the fix for this issue.
2. After upgrading, verify that the deployment is using the code containing the domain-name validation and related regression coverage, rather than an unintended image or package.
3. If an immediate upgrade is not possible, restrict management interface and API access to trusted administrative networks. This is a temporary exposure-reduction measure, not a confirmed patch.
4. Review recent certificate requests. If unauthorized activity is found, treat credentials, tokens, certificate private keys, and secrets accessible to the service as potentially exposed and rotate them through the incident-response process.
5. Do not infer that other release branches are safe solely because v2.12.0 contains a fix.

1. Inventory every Nginx Proxy Manager instance and compare each release with the affected and fixed boundaries in affected_summary.
2. Review audit logs for unexpected certificate creation, especially requests that do not match an approved administrator or automation workflow.
3. Inspect application logs around Requesting Let'sEncrypt certificates and Command: for certificate activity that was not expected. This is precautionary telemetry, not a confirmed IOC.
4. Correlate certbot executions, requested domains, and certificate creation times with approved changes, tickets, and operators.
5. Verify that the deployment runs a release containing the fix. The absence of suspicious log evidence does not prove that an instance is safe.