The critical vulnerability CVE-2026-42945 in NGINX Plus and NGINX Open, which allows an attacker to cause denial of service or, under certain conditions, execute arbitrary code, is, according to VulnCheck, already being exploited by attackers — just days after it was publicly disclosed. At the same time, attacks have been recorded against three critical vulnerabilities in openDCIM, which are combined into a chain to achieve remote code execution. Organizations using these products must immediately assess their exposure and apply available fixes.

CVE-2026-42945: buffer overflow in NGINX

The vulnerability CVE-2026-42945 is a heap buffer overflow in the ngx_http_rewrite_module. Reportedly, versions of NGINX from 0.6.27 through 1.30.0 are affected. Successful exploitation allows an unauthenticated attacker, using specially crafted HTTP requests, to crash worker processes, resulting in denial of service.

The possibility of remote code execution (RCE) exists but requires several conditions to be met simultaneously. Security researcher Kevin Beaumont noted that exploitation requires a specific NGINX configuration that the attacker must know or discover, and that ASLR (Address Space Layout Randomization) must be disabled on the target system to achieve RCE.

Realistic threat assessment

AlmaLinux maintainers, in their analysis, provided a balanced assessment: turning a heap overflow into reliable code execution is non-trivial under the standard configuration, and on systems with ASLR enabled (which is the default setting for all supported AlmaLinux releases), creating a universal and reliable exploit appears extremely difficult. Nevertheless, as the maintainers emphasized, “non-trivial” does not mean “impossible,” and the denial-of-service scenario via worker process crashes is realistic enough on its own to treat this vulnerability as urgent.

This assessment is fundamentally important for correct prioritization. Organizations that have ASLR disabled for any reason (legacy systems, specific compatibility requirements) are at significantly higher risk. For everyone else, the primary threat is a DoS attack, which can still cause serious damage when NGINX is used as a reverse proxy or load balancer in front of critical services.

According to VulnCheck, exploitation attempts have already been observed on their honeypot network. The targets and nature of the malicious activity are not yet established.

openDCIM vulnerability chain: from SQL injection to reverse shell

In parallel, VulnCheck reported exploitation of two critical vulnerabilities in openDCIM, an open source data center infrastructure management application:

• CVE-2026-28515 (CVSS 9.3) — lack of authorization checks, allowing an authenticated user to access LDAP configuration functionality regardless of assigned privileges. In Docker-based deployments where the REMOTE_USER variable is set without enforced authentication, the endpoint may be accessible without credentials, opening the door to unauthorized modification of the application configuration.
• CVE-2026-28517 (CVSS 9.3) — operating system command injection in the report_network_map.php component. The dot parameter is passed into a shell command without sanitization, enabling arbitrary code execution.
• CVE-2026-28516 (CVSS 9.3) — SQL injection in openDCIM.

All three vulnerabilities were discovered by VulnCheck security researcher Valentin Lobstein in February 2026. According to his technical write-up, the three vulnerabilities can be chained to achieve remote code execution in five HTTP requests, followed by launching a reverse shell. This makes the attack chain almost fully automatable.

Impact assessment

The potential impact of the NGINX vulnerability is defined by the ubiquity of this web server: it is used by millions of sites and services worldwide as a web server, reverse proxy, and load balancer. Even if the RCE scenario is hard to achieve, a DoS attack against NGINX worker processes can cause cascading failures of the services behind it. Organizations with non-standard rewrite module configurations and legacy systems without ASLR are particularly exposed.

For openDCIM, the risk is concentrated in the data center management sector. Compromise of a data center infrastructure management system can give an attacker detailed information about the physical and logical network topology, equipment locations, and configurations, creating a foothold for further attacks on critical infrastructure. The presence of a fully automatable exploitation chain made up of three vulnerabilities significantly lowers the bar for attackers.

Security recommendations

For NGINX

• Install the latest updates from F5 for NGINX Plus and NGINX Open that address CVE-2026-42945.
• Ensure ASLR is enabled on all servers running NGINX — this significantly complicates exploitation of the RCE scenario.
• Audit your ngx_http_rewrite_module configurations — the vulnerability requires a specific configuration to be exploitable.
• Consider deploying WAF rules to detect abnormally crafted HTTP requests targeting the rewrite module.
• Monitor NGINX worker process crashes as a potential indicator of exploitation attempts.

For openDCIM

• Check for openDCIM updates that address CVE-2026-28515, CVE-2026-28516, and CVE-2026-28517.
• In Docker deployments, ensure the REMOTE_USER variable is not set without an appropriate authentication mechanism.
• Restrict network access to openDCIM — the application should not be exposed to the internet.
• Inspect servers for unusual PHP files that could be web shells planted during a compromise.

Both sets of vulnerabilities require immediate action: for NGINX — prioritizing updates and verifying ASLR configuration; for openDCIM — updating and isolating the application from external access. Given the confirmed active exploitation of both products and the availability of automated attack tools, the window for safe patching is rapidly closing.