Nginx CVE-2026-42945

[acenomad]

From cve.org and maintainer disclosure

NGINX Plus and NGINX Open Source have a vulnerability in the ngx_http_rewrite_module module. This vulnerability exists when the rewrite directive is followed by a rewrite, if, or set directive and an unnamed Perl-Compatible Regular Expression (PCRE) capture (for example, $1, $2) with a replacement string that includes a question mark (?). An unauthenticated attacker along with conditions beyond its control can exploit this vulnerability by sending crafted HTTP requests. This may cause a heap buffer overflow in the NGINX worker process leading to a restart. Additionally, for systems with Address Space Layout Randomization (ASLR ) disabled, code execution is possible.

OpenResty have apparently already committed the necessary patches to their public repo, but have not yet formally released a new version according to their relevant issue.

Edit: there's a technical write-up with more details from the security researcher who discovered the vulnerability.

In the meantime until patches reach downstream, F5 recommends the following mitigation per their aforementioned disclosure:

To mitigate this vulnerability, use named captures instead of unnamed captures in rewrite definitions.

For example, the following rewrite directive uses unnamed PCRE capture groups, $1 and $2:

rewrite ^/users/([0-9]+)/profile/(.*)$ /profile.php?id=$1&tab=$2 last;

To mitigate this vulnerability for this example, replace $1 and $2 with the appropriate named captures, $user_id and $section:

rewrite ^/users/(?<user_id>[0-9]+)/profile/(?<section>.*)$ /profile.php?id=$user_id&tab=$section last;

[JoelAzaria]

Thanks for the write up. Given that I've only ever used the gui to forward some simple proxy hosts I have no idea how to identify IF I'm using unnamed PCRE capture groups let alone how to apply these mitigations.

Is possible for someone to give us a somewhat more dumbed down, gui focused interpretation (or point to one)?

Thanks to all the volunteers and contributors for what you do and good luck with the tidal wave of s**t coming from the AI bug hunters!

[davidlang42]

The supply chain here is that Nginx Proxy Manager v2.14.0 (this repo) uses OpenResty v1.27.1.2, which uses nginx core 1.27.1 (which is affected by this vulnerability).

My understanding is that in order to be exploitable you must be running an affected version AND use the rewrite keyword in the nginx configuration. I agree with @JoelAzaria that its hard for users of the Nginx Proxy Manager GUI to know what it puts in the underlying nginx configuration, but by looking at the source code:

• Nginx Proxy Manager source code does not contain the word rewrite
• OpenResty source code only contains rewrite within references to --without-http_rewrite_module (which is CLI argument used to enable or disable the rewrite module, but does not constitute a use of the rewrite keyword

So this should mean there is no way that Nginx Proxy Manager can be affected unless you've manually written "advanced configuration" containing the rewrite keyword (which you'd know if you had).

Can anyone with a better understanding of how Nginx Proxy Manager works under the hood please confirm if my logic is correct?

[acenomad]

You have the right idea @davidlang42. Generally rewriting a URL is not nearly as common of a scenario compared to just returning one instead; out of the box you will see lots of return but no rewrite directives with NPM. Returning is the simpler of the two directives while rewriting is a fair amount more flexible and is often used to craft complicated routing logic or shift resources around without disturbing already-existing client expectations.

So this should mean there is no way that Nginx Proxy Manager can be affected unless you've manually written "advanced configuration" containing the rewrite keyword (which you'd know if you had).

Indeed. For most users I would agree this is the key takeaway.

its hard for users of the Nginx Proxy Manager GUI to know what it puts in the underlying nginx configuration

You can view all the config files that NPM generates wherever you have set your host bind mount. For proxy hosts they are in data/nginx/proxy_host/ listed by the corresponding number in the UI. You may need elevated privileges to view them, but a simple cat * | grep rewrite will immediately show which, if any, are at risk.

Note that you shouldn't manually edit sites directly from the bind mount because they will get overwritten by NPM's internal state in the future. However, I've found it useful when debugging more advanced configurations to be able to see the entire config file in one place.

[davidlang42]

Thanks @acenomad, I obviously believe you and that matches with my search of the source code, but just to triple check I did grep every conf file under /data/nginx, and those in /etc/nginx/conf.d which get included and there are definitely no rewrites!

If anyone wants to confirm on their own container, you can use this command (inside the container):

find / -type f -name "*.conf" -exec grep -l "rewrite" {} +

You may get a few "permission denied" errors under the /proc system folder, but as long as it doesn't list any other files, then you're safe.

---

Safe:

find: '/proc/345/task/345/fdinfo': Permission denied
find: '/proc/345/map_files': Permission denied
find: '/proc/345/fdinfo': Permission denied
...

Not safe:

...
/data/nginx/default_host/site.conf
/data/nginx/proxy_host/1.conf

[acenomad]

Always better to be safe than sorry :) frankly I don't think there's such as thing as 'too paranoid' in this day and age when it comes to application security...

Also, OpenResty have released a new tag as of this morning to address the CVE.

[gnoling]

I personally use advanced configs in a few hosts, although none using rewrite. I could imagine others doing so though, even if not common. IMHO I'd consider NPM "vulnerable" even if it likely wouldn't affect many. It would be good to see the openresty bump acenomad mentioned.