Missing authentication in NginxProxyManager nginx-proxy-manager certificate validation

A vulnerability was detected in NginxProxyManager nginx-proxy-manager up to 2.15.1. This impacts the function internalCertificate.validate of the file backend/internal/certificate.js of the component Validate Route. The manipulation results in missing authentication. The attack can be launched remotely. The exploit is now public and may be used. Endpoint only processes and echoes back the certificate the caller submits (no stored data leaked); the real risk is unauthenticated openssl processing of attacker input. The project was informed of the problem early through an issue report but has not responded yet.

• The CNA description identifies NginxProxyManager nginx-proxy-manager as affected up to and including 2.15.1.
• The structured affected facts explicitly mark 2.0, 2.1, 2.1.0, 2.1.1, 2.1.2, 2.2, 2.2.0, 2.2.1, 2.2.2, 2.2.3, 2.2.4, 2.3, 2.3.0, 2.3.1, 2.4, 2.4.0, 2.5, 2.5.0, 2.6, and 2.6.0 as affected.
• The structured list does not enumerate every release between 2.6.0 and 2.15.1; that span is supported by the CNA's broader wording rather than by a complete per-version list.
• No fixed release or confirmed patch boundary is identified, and patch availability remains unknown.

The flaw is in internalCertificate.validate in backend/internal/certificate.js, within the Validate Route component. The application does not require authentication before accepting and processing caller-supplied certificate data. The available evidence describes attacker-controlled certificate input being sent through OpenSSL processing, after which the endpoint processes and echoes that submitted certificate. The attack is remotely reachable, requires no authentication or user interaction, and the normalized record describes low complexity. The exact endpoint URL, request schema, OpenSSL invocation, and behavior for malformed certificates are not documented. Consequences beyond unauthenticated certificate processing, such as service disruption or a library-level failure, remain possible but unconfirmed.

• Reachability: The attack can be launched remotely over the network.
• Authentication: No account or authentication is required.
• User interaction: No user action is required.
• Complexity: The normalized record describes low attack complexity.
• Exploitation status: VulDB reports that an exploit or proof of concept is publicly available. The GitHub issue returned during research shows that the reporter notified the project and does not contain technical exploitation steps.
• The available evidence does not identify a specific campaign, victim, or threat actor, so it does not establish in-the-wild exploitation.

The confirmed technical outcome is that an unauthenticated caller can bypass access control for certificate validation and submit attacker-controlled data to OpenSSL processing. The documented scope is limited to processing and echoing the submitted certificate; there is no confirmed access to stored certificates, private keys, or database contents. Crafted input could consume resources or cause instability in the library or service, but the exact behavior is unknown. Organisationally, the issue may require reducing network exposure, reviewing telemetry, and preparing service recovery if instability occurs; no breach, victim, or specific threat actor is identified.

The issue allows an unauthenticated caller to use the service's certificate-processing function, increasing exposure for deployments reachable from untrusted networks. Processing attacker-supplied certificate input through OpenSSL could increase CPU or memory use and may destabilize the service, but denial of service and code execution are not confirmed. The source description specifically states that the endpoint processes and echoes the certificate submitted by the caller and does not leak stored data. The confirmed impact is therefore centered on bypassing the authentication boundary and forcing the service to process attacker-controlled input.

1. Apply an official vendor fix as soon as one is released. The supplied record and consulted CNA material do not identify a fixed release, so do not treat an unverified later or parallel branch as remediated.
2. Until a fix is confirmed, remove Validate Route or the administrative interface from untrusted network exposure where operationally possible. Place access behind a trusted network boundary or an additional authentication and allowlisting layer at a reverse proxy or gateway.
3. Review reverse-proxy and application controls to prevent unauthenticated requests from reaching certificate-validation processing. This is a compensating control, not a confirmed code-level fix.
4. Keep the host and OpenSSL packages current as defense in depth, but do not consider library updates alone a correction for the missing application authentication.
5. After applying a confirmed fix, re-inventory image and package versions and review logs for suspicious unauthenticated requests and resource anomalies.

1. Inventory every NginxProxyManager deployment, including container image tags and package versions, and compare them with the CNA's affected boundary. Because the supplied data contains both a broad CNA statement and a narrower enumerated list, do not infer safety for an unlisted branch.
2. Determine whether Validate Route and its certificate-validation operation are reachable from untrusted networks, directly or through a reverse proxy.
3. Review application and reverse-proxy logs for requests to the certificate-validation operation without an authenticated session, especially certificate payloads submitted by unauthenticated clients. The exact URL and log field names are not provided, so do not assume a specific path or event signature.
4. Correlate such requests with CPU or memory spikes, worker restarts, and OpenSSL errors as a precaution. These are generic review signals, not confirmed indicators of exploitation.
5. Do not treat a normal echoed certificate or the absence of a stored-data read as proof that the endpoint is safe. The documented risk is unauthenticated processing of attacker input.