Table of contents of the article:
On June 9, 2026, Nebula Security published a message on X that was destined to spark discussion in the entire system and security community: according to the team, a new vulnerability had been reported to F5 Remote Code Execution in NGINX, also accompanied by a proposed patch, but after about two weeks no official response has yet arrived.
The post, available at this address: https://x.com/nebusecurity/status/2064209727538745734, is particularly relevant because it comes at an already very delicate time for NGINX. In the previous weeks, in fact, the project had already had to deal with significant vulnerabilities in the module ngx_http_rewrite_module, among which CVE-2026-42945, publicly known as NGINX Rift, and CVE-2026-9256, nicknamed nginx-poolslip.
https://x.com/nebusecurity/status/2064209727538745734
This new report, however, should be treated differently than the CVEs already known: There is currently no CVE assigned, there is no public F5/NGINX advisory, and there is no official patch available.This means that we still don't have enough information to talk about certainly vulnerable versions, specific exploitation conditions, affected configurations, or vendor-validated workarounds.
In other words, we're in an awkward, intermediate stage: enough information to worry about, but not enough to technically close the case with a simple update command.
What Nebula Security said
In the message posted to X, Nebula Security states that it had reported another RCE in NGINX to F5 about two weeks earlier, along with a proposed patch. The critical point in the communication is the lack of response from the vendor, at least according to what the research team has publicly stated.
Nebula also adds that the vulnerability would not depend on an "unusual" configuration.This detail is important: often, when a vulnerability requires a specific combination of directives or parameters, people tend to downplay the risk by arguing that it's a rare or unrealistic configuration. Nebula disputes this very assumption, pointing out that in the real world, NGINX configurations are extremely varied, often layered over time, and rarely public.
Below is the Italian translation:
According to their preliminary analysis, a significant number of real-world deployments are affected, including Fortune Global 500 companies. This statement should also be interpreted with caution: since a complete technical advisory is not yet available, we cannot independently verify the details. However, the mere fact that a research group has decided to publicly disclose its pressure on the vendor indicates that the issue is considered serious.
Why an RCE in NGINX is critical news
NGINX isn't a fringe software. It's one of the world's most widely used web servers and reverse proxies, present on bare metal servers, VPS, containers, appliances, Kubernetes ingress controllers, application loaders, Plesk environments, cPanel, custom stacks, and cloud infrastructures. In many cases, it's the first component to receive HTTP and HTTPS traffic from outside.
An RCE vulnerability in a frontier component like NGINX has a very different risk profile than a local vulnerability or a bug in an internal service. If exploitable without authentication and reachable via HTTP, it could theoretically allow a remote attacker to execute code in the context of the NGINX worker process.
It should be clarified that running code as the NGINX user does not necessarily equate to gaining root. NGINX, when configured correctly, runs workers as a non-privileged user, such as nginx, www-data or similar. However, from that point on, an attacker could still read files accessible to the process, interact with internal backends, move laterally, attempt local escalations, or abuse sockets, credentials, configurations, or secrets present on the system.
In a hosting or reverse proxy scenario, even a limited compromise can have significant consequences, especially if the server manages multiple virtual hosts, forwards traffic to private backends, or contains configurations with sensitive information.
Context: NGINX Rift and nginx-poolslip
To understand the sensitivity of the moment, we must consider the context. In May 2026, NGINX released updates for several vulnerabilities, including CVE-2026-42945, a heap buffer overflow in the module ngx_http_rewrite_moduleThe official NGINX advisory page indicates that non-vulnerable builds for CVE-2026-42945 are 1.31.0+ e 1.30.1+, while the versions from are vulnerable 0.6.27 to 1.30.0.
She arrived soon after CVE-2026-9256, another buffer overflow in the rewrite module. In this case, the official NGINX page indicates that the following versions are not vulnerable: 1.31.1+ e 1.30.2+, while versions up to are vulnerable 1.31.0The NGINX 1.30.2 release notes explicitly mention a heap memory buffer overflow in the worker process when using a configuration with overlapping captures in the rewrite module, potentially leading to arbitrary code execution.
These two cases have already been tracked, documented, and patched. Nebula Security's new report, however, appears to be a separate case: we still don't have an official name, CVE identifier, or F5 page that would allow us to determine precisely whether and how it's related to the previous bugs.
The problem of the lack of CVE and advisory
When a vulnerability doesn't yet have a CVE assigned and there's no official advisory, administrators find themselves in a difficult situation. On the one hand, they can't ignore the report, especially if it comes from a researcher or a team with product experience. On the other, they can't apply a patch that doesn't exist, nor can they confirm the exposure with a reliable scanner.
It is important not to confuse three different levels:
- the CVEs already known and patched, such as CVE-2026-42945 and CVE-2026-9256;
- the new public reporting from Nebula Security, which currently has no CVE or official advisory;
- the operational hypotheses that an administrator can take to reduce risk while awaiting details.
A common mistake would be to say, “I upgraded to NGINX 1.30.2 or 1.31.1, so I’m definitely protected against this new RCE.” We can’t say that. Those versions fix known and published vulnerabilities, but they may not necessarily fix the new vulnerability reported by Nebula, unless F5/NGINX confirms it in the future.
What to do now: NGINX version inventory
The first step is to know exactly which NGINX instances are present in your infrastructure. In many environments, the issue isn't just the main server, but also container images, ingress controllers, internal reverse proxies, appliances, legacy systems, and hand-built installations.
nginx -v 2>&1
nginx -V 2>&1
On RPM-based systems such as AlmaLinux, Rocky Linux, RHEL and CentOS:
rpm -qa | grep -E '^nginx|nginx-' | sort
dnf list installed | grep nginx
On Debian and Ubuntu:
dpkg -l | grep nginx
apt-cache policy nginx
In containerized environments:
docker ps --format 'table {{.Names}}t{{.Image}}t{{.Ports}}' | grep -i nginx
podman ps --format 'table {{.Names}}t{{.Image}}t{{.Ports}}' | grep -i nginx
kubectl get pods -A | grep -i nginx
kubectl get ingressclass -A
This inventory is critical because many organizations update their NGINX OS package but forget about Docker images, Helm charts, ingress controllers, or custom builds.
Please update any known vulnerabilities anyway.
Even if the new RCE reported by Nebula doesn't yet have a public patch, that's no reason to fall behind. On the contrary, you should make sure you've already fixed the known vulnerabilities.
For NGINX Open Source compiled or installed from official NGINX repositories, the minimum goal for the May 2026 known CVEs is to get to at least a release that includes fixes for CVE-2026-42945 and CVE-2026-9256, then 1.30.2 on the stable branch or 1.31.1 on the mainline branch, unless otherwise indicated by your vendor.
On AlmaLinux, Rocky Linux, RHEL, and derivatives, however, you need to be careful about backporting: the package version number may appear old, but it contains security patches backported by the maintainer. For this reason, in the Enterprise Linux environment, it's best to rely on the distribution's advisories and packages rather than naively comparing only the upstream version.
dnf clean all
dnf update -y nginx*
systemctl restart nginx
nginx -v
On Debian and Ubuntu:
apt update
apt full-upgrade -y
systemctl restart nginx
nginx -v
These commands should not be interpreted as patches for the new, unpublished vulnerability, but as a necessary measure to at least close the already known flaws.
Verify modules and custom builds
Another often overlooked area is the presence of dynamic modules or custom builds. NGINX is frequently compiled with third-party modules, WAF modules, Brotli modules, headers-more, Lua, NJS, streams, QUIC, HTTP/3, or components provided by external vendors. A core vulnerability can be aggravated by complex configurations, but a non-standard build can also make patching more difficult.
nginx -V 2>&1 | tr ' ' 'n' | grep -E 'configure|with-|add-module|modules-path|conf-path'
If NGINX was compiled by hand, you need to locate the path to the actual running binary:
which nginx
readlink -f $(which nginx)
ps -eo pid,user,comm,args | grep '[n]ginx'
In many real incidents it turns out that the operating system package is up to date, but the systemd service points to a manually compiled binary in /usr/local/nginx, /opt/nginx or similar directories.
Reduce the exposed surface area
While waiting for official information, it's a good idea to reduce anything unnecessary. If you have temporary virtual hosts, public staging environments, unused nameservers, or legacy locations no longer in use, now is the time to disable them.
It's also useful to look for complex and dated configurations, especially those related to rewrites, regex, and redirects:
grep -RInE 'rewrite|if (|set $|return 30|proxy_pass|try_files' /etc/nginx /usr/local/nginx/conf 2>/dev/null
Warning: This check doesn't identify the new Nebula vulnerability, as we don't know the trigger. However, it helps map the most sensitive configuration areas and reduce unnecessarily complex logic. Recent vulnerabilities in NGINX have shown how seemingly ordinary directives can become dangerous in specific combinations.
Whenever possible, it's a good idea to move complex rules to the application layer or simplify them. A reverse proxy should do the bare minimum: TLS termination, proxying, caching, compression, rate limiting, security headers, and a few clear rules. Every regex maintained for years without review increases technical debt.
Monitor worker crashes, segfaults, and anomalies
A memory corruption-based RCE often manifests as crashes, worker restarts, segfaults, or log anomalies. These signs don't always indicate exploitation, but in times of uncertainty, they become significant.
journalctl -u nginx --since "24 hours ago" | grep -Ei 'segfault|signal|core|worker|exited'
dmesg -T | grep -Ei 'nginx|segfault|general protection|core dumped'
grep -R "signal 11|segmentation fault|core dumped" /var/log/nginx /var/log/messages /var/log/syslog 2>/dev/null
It's a good idea to send these events to your centralized monitoring system, SIEM, or log management system. A single worker crash could be a nuisance; repeated crashes on anomalous HTTP requests warrant investigation.
Plesk, cPanel, hosting and managed environments
In hosting environments, the issue is even more delicate. Plesk, cPanel, EasyApache, vendor repositories, custom NGINX packages, and integrated reverse proxies may have different update cycles than the distribution's NGINX package. It's not enough to check dnf update o apt upgrade: You need to understand where the running NGINX binary actually comes from.
On servers with control panels it is recommended:
- check the panel vendor's advisories;
- update the panel and web stack components;
- check for any additional repositories;
- restart NGINX after the upgrade;
- Verify that there are no custom binaries outside the control of the package manager.
For a hosting provider, the correct approach is to treat NGINX as a critical frontier component, on par with the kernel, OpenSSL, PHP-FPM, and the database. Its public exposure makes any potential RCE an operational priority.
Conclusion
Nebula Security's new report is not yet a CVE and is not yet an official advisory. This must be made clear to avoid technically incorrect alarmism. At the same time, ignoring the issue would be reckless: NGINX is a central component of modern web infrastructure, and recent vulnerabilities in the rewrite module have already demonstrated that historical bugs can remain hidden for years.
In the absence of a public patch, the best response is pragmatic: inventory all NGINX instances, immediately update known vulnerabilities, verify builds and modules, reduce the exposed surface area, ensure workers are running with minimum privileges, keep ASLR enabled, and monitor for crashes or anomalies. When F5 or NGINX publishes an official advisory, it will then be necessary to promptly apply the patch and restart the affected services.
For now the most correct sentence is this: There is no public patch or assigned CVE yet for the new RCE cited by Nebula Security, but administrators should prepare as if the advisory could arrive at any moment..
