From mdounin at mdounin.ru Tue May 5 13:06:30 2026 From: mdounin at mdounin.ru (Maxim Dounin) Date: Tue, 5 May 2026 16:06:30 +0300 Subject: freenginx-1.31.0 Message-ID: Changes with freenginx 1.31.0 05 May 2026 *) Change: now the "try_files" directive can be used with arguments starting with the request URI inside a location given by a regular expression, along with the "alias" directive. *) Bugfix: the "try_files" directive might work incorrectly when used with the "alias" directive. *) Bugfix: a segmentation fault might occur in a worker process if the "try_files" and "proxy_pass" directives were used together. *) Bugfix: the "proxy_pass" directive without a URI part might use the original request URI after the URI was changed by the "try_files" directive. *) Change: the logging level of the "invalid ccs message", "not on record boundary", "required compression algorithm missing", and some "record layer failure" SSL errors has been lowered from "crit" to "info". -- Maxim Dounin http://freenginx.org/ From paul at stormy.ca Mon May 11 15:44:57 2026 From: paul at stormy.ca (Paul) Date: Mon, 11 May 2026 11:44:57 -0400 Subject: Setting headers Message-ID: I'm looking for some advice. Using nginx/1.18.0 (Ubuntu) in production (~400k+ connections/day) across multiple domains (some nginx => apache2), I am considering for top-level server block the following: add_header X-XSS-Protection "1; mode=block" always; add_header X-Frame-Options "SAMEORIGIN"; add_header X-Content-Type-Options nosniff; add_header 'Referrer-Policy' 'origin'; I have no other "header' directives except for multiple "proxy_set_header" Are there any pitfalls or caveats? And is the code above correct as I have noticed double quotes, single quotes and nosniff not quoted? Thanks in advance, Paul From nick at nickrickard.co.uk Tue May 12 07:23:45 2026 From: nick at nickrickard.co.uk (Nick Rickard) Date: Tue, 12 May 2026 08:23:45 +0100 Subject: Setting headers In-Reply-To: References: Message-ID: >I am considering for top-level server block the following: > > add_header X-XSS-Protection "1; mode=block" always; I understood [citation needed] that this was now obsolete and not required for any reasonably modern browsers and is better mitigated by Content-Security-Policy (see below). I've removed it. > add_header X-Frame-Options "SAMEORIGIN"; add_header X-Frame-Options "SAMEORIGIN" always; adding 'always' will enforce it across all responses (eg 404) > add_header X-Content-Type-Options nosniff; add_header X-Content-Type-Options "nosniff" always; as before with 'always'. Mine has quotes around "nosniff". > add_header 'Referrer-Policy' 'origin'; add_header Referrer-Policy "no-referrer" always; Personally I remove all referrer information, but personal choice Additionally, you probably want add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always; if you use HTTPS And probably add_header Content-Security-Policy ... for which https://scotthelme.co.uk/csp-cheat-sheet is a good reference and https://docs.report-uri.com/setup/wizard/ can help to generate it for you From bayberry.uninspired694 at aceecat.org Thu May 14 21:15:35 2026 From: bayberry.uninspired694 at aceecat.org (bayberry.uninspired694 at aceecat.org) Date: Thu, 14 May 2026 14:15:35 -0700 Subject: CVE status Message-ID: Hi, does CVE-2026-42945 apply to freenginx? And if yes, will there be a point release to fix it? Here's the reference: https://nvd.nist.gov/vuln/detail/CVE-2026-42945 -- Ian From mdounin at mdounin.ru Fri May 15 00:07:42 2026 From: mdounin at mdounin.ru (Maxim Dounin) Date: Fri, 15 May 2026 03:07:42 +0300 Subject: CVE status In-Reply-To: References: Message-ID: Hello! On Thu, May 14, 2026 at 02:15:35PM -0700, bayberry.uninspired694 at aceecat.org wrote: > Hi, > > does CVE-2026-42945 apply to freenginx? And if yes, will there be a point > release to fix it? > > Here's the reference: > > https://nvd.nist.gov/vuln/detail/CVE-2026-42945 It does apply. Note though that triggering this bug requires rather specific configuration (a matched "rewrite" which changes request arguments but continues rewrite processing, that is, without "break" or any other flags, followed by a "set" or "if" which uses positional captures or another matched rewrite which uses positional captures and additional variables or duplicate positional captures), and therefore most configurations won't be affected at all. As a reference point, none of the examples provided in the rewrite documentation are affected. I'm currently looking into this, as well as other issues published by F5, and will provide appropriate patches shortly. Once patches are ready, there will be a release. -- Maxim Dounin http://mdounin.ru/ From teward at thomas-ward.net Fri May 15 00:38:09 2026 From: teward at thomas-ward.net (Thomas Ward) Date: Fri, 15 May 2026 00:38:09 +0000 Subject: CVE status In-Reply-To: References: Message-ID: FYI Maxim the fix for the buffer overrun in rewrite is a one line patch. Sent from my Galaxy -------- Original message -------- From: Maxim Dounin Date: 5/14/26 20:09 (GMT-05:00) To: nginx at freenginx.org Subject: Re: CVE status Hello! On Thu, May 14, 2026 at 02:15:35PM -0700, bayberry.uninspired694 at aceecat.org wrote: > Hi, > > does CVE-2026-42945 apply to freenginx? And if yes, will there be a point > release to fix it? > > Here's the reference: > > https://nvd.nist.gov/vuln/detail/CVE-2026-42945 It does apply. Note though that triggering this bug requires rather specific configuration (a matched "rewrite" which changes request arguments but continues rewrite processing, that is, without "break" or any other flags, followed by a "set" or "if" which uses positional captures or another matched rewrite which uses positional captures and additional variables or duplicate positional captures), and therefore most configurations won't be affected at all. As a reference point, none of the examples provided in the rewrite documentation are affected. I'm currently looking into this, as well as other issues published by F5, and will provide appropriate patches shortly. Once patches are ready, there will be a release. -- Maxim Dounin http://mdounin.ru/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From mdounin at mdounin.ru Fri May 15 03:44:06 2026 From: mdounin at mdounin.ru (Maxim Dounin) Date: Fri, 15 May 2026 06:44:06 +0300 Subject: CVE status In-Reply-To: References: Message-ID: Hello! On Fri, May 15, 2026 at 12:38:09AM +0000, Thomas Ward via nginx wrote: > FYI Maxim the fix for the buffer overrun in rewrite is a one line patch. Sure, except it might not be the best solution. Based on my analysis I tend to prefer at least three lines. Also, I see at least one additional case of obviously incorrect escaping applied by the related rewrite code, though without a buffer overrun. > > > > Sent from my Galaxy > > > > -------- Original message -------- > From: Maxim Dounin > Date: 5/14/26 20:09 (GMT-05:00) > To: nginx at freenginx.org > Subject: Re: CVE status > > Hello! > > On Thu, May 14, 2026 at 02:15:35PM -0700, bayberry.uninspired694 at aceecat.org wrote: > > > Hi, > > > > does CVE-2026-42945 apply to freenginx? And if yes, will there be a point > > release to fix it? > > > > Here's the reference: > > > > https://nvd.nist.gov/vuln/detail/CVE-2026-42945 > > It does apply. > > Note though that triggering this bug requires rather specific > configuration (a matched "rewrite" which changes request arguments > but continues rewrite processing, that is, without "break" or any > other flags, followed by a "set" or "if" which uses positional > captures or another matched rewrite which uses positional captures and > additional variables or duplicate positional captures), and > therefore most configurations won't be affected at all. As a > reference point, none of the examples provided in the rewrite > documentation are affected. > > I'm currently looking into this, as well as other issues published > by F5, and will provide appropriate patches shortly. Once patches > are ready, there will be a release. > > -- > Maxim Dounin > http://mdounin.ru/ -- Maxim Dounin http://mdounin.ru/ From teward at thomas-ward.net Fri May 15 03:46:16 2026 From: teward at thomas-ward.net (Thomas Ward) Date: Thu, 14 May 2026 23:46:16 -0400 Subject: CVE status In-Reply-To: References: Message-ID: <9d624a02-ebf8-4090-8800-c9edcf7a8bf7@thomas-ward.net> Yeah, I believe those are other bugs and Security fixes patched in NGINX OSS 1.31.0 and 1.30.1.? Just thought I'd make a note.? (the one-line for the rewrite buffer overrun is, however, a fix for the specific CVE referenced in this thread. Other CVEs were also patched independently as other commits.) On 2026-05-14 23:44, Maxim Dounin wrote: > Hello! > > On Fri, May 15, 2026 at 12:38:09AM +0000, Thomas Ward via nginx wrote: > >> FYI Maxim the fix for the buffer overrun in rewrite is a one line patch. > Sure, except it might not be the best solution. Based on my > analysis I tend to prefer at least three lines. > > Also, I see at least one additional case of obviously incorrect > escaping applied by the related rewrite code, though without a > buffer overrun. > >> >> >> Sent from my Galaxy >> >> >> >> -------- Original message -------- >> From: Maxim Dounin >> Date: 5/14/26 20:09 (GMT-05:00) >> To:nginx at freenginx.org >> Subject: Re: CVE status >> >> Hello! >> >> On Thu, May 14, 2026 at 02:15:35PM -0700,bayberry.uninspired694 at aceecat.org wrote: >> >>> Hi, >>> >>> does CVE-2026-42945 apply to freenginx? And if yes, will there be a point >>> release to fix it? >>> >>> Here's the reference: >>> >>> https://nvd.nist.gov/vuln/detail/CVE-2026-42945 >> It does apply. >> >> Note though that triggering this bug requires rather specific >> configuration (a matched "rewrite" which changes request arguments >> but continues rewrite processing, that is, without "break" or any >> other flags, followed by a "set" or "if" which uses positional >> captures or another matched rewrite which uses positional captures and >> additional variables or duplicate positional captures), and >> therefore most configurations won't be affected at all. As a >> reference point, none of the examples provided in the rewrite >> documentation are affected. >> >> I'm currently looking into this, as well as other issues published >> by F5, and will provide appropriate patches shortly. Once patches >> are ready, there will be a release. >> >> -- >> Maxim Dounin >> http://mdounin.ru/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From mureninc at gmail.com Sun May 17 16:21:15 2026 From: mureninc at gmail.com (Constantine A. Murenin) Date: Sun, 17 May 2026 11:21:15 -0500 Subject: avoid limit_req / limit_conn limits for proxy_cache cached content Message-ID: Hello, My optimised and heavily-cached OpenGrok-based dev web site has finally succumbed to the DDoS from the supposed AI abuse, so, I'm, reevaluating resource usage and the applicable limits. My objective is to serve everyone as long as there is available capacity. Instead of doing a cat and mouse game on blocking any specific identifier, like User-Agent or IP or netblock or region, I want to block excessive usage IFF the content isn't already cached. For example, the search results page on my OpenGrok may take 10ms to 50ms to generate when the Lucene index is stored on an mfs, but once generated, the page is basically "free" to serve, and I want keep serving the cached entry even during what may look like a DDoS attack on my instance. Otherwise, a Slashdot-like event could result in the most popular combination of identifiers being promptly blocked, and legitimate users being denied access, even when the content was actually "free" and wouldn't have required any excessive resources to generate and serve. I've re-looked at http://freenginx.org/r/limit_req and http://freenginx.org/r/limit_conn, but I don't see any way to exclude cached content from still getting subjected to the limits. I think the standard route here may be to use an http://freenginx.org/r/error_page exception handler, to automatically handle the 503 errors thrown by limit_req and limit_conn, and continue serving the content if cached, but I'm not quite certain how to integrate it with http://freenginx.org/r/proxy_cache. Any suggestions? One option may be to use http://freenginx.org/r/proxy_store instead of proxy_cache, but I'm not sure that'll work properly when I'm also caching the search result pages, too, to account for the Slashdot-like events (they're currently referred to as "When many people access the same link simultaneously -- such as when a GitLab link is shared in a chat room"), without creating new restrictions on the input for the search query string, for example, not to mention having to do manual purges of the cached data and missing all the other nice features of the standard proxy_cache. Best regards, Constantine. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mdounin at mdounin.ru Mon May 18 00:19:35 2026 From: mdounin at mdounin.ru (Maxim Dounin) Date: Mon, 18 May 2026 03:19:35 +0300 Subject: avoid limit_req / limit_conn limits for proxy_cache cached content In-Reply-To: References: Message-ID: Hello! On Sun, May 17, 2026 at 11:21:15AM -0500, Constantine A. Murenin wrote: > My optimised and heavily-cached OpenGrok-based dev web site has finally > succumbed to the DDoS from the supposed AI abuse, so, I'm, reevaluating > resource usage and the applicable limits. > > My objective is to serve everyone as long as there is available capacity. > Instead of doing a cat and mouse game on blocking any specific identifier, > like User-Agent or IP or netblock or region, I want to block excessive > usage IFF the content isn't already cached. > > For example, the search results page on my OpenGrok may take 10ms to 50ms > to generate when the Lucene index is stored on an mfs, but once generated, > the page is basically "free" to serve, and I want keep serving the cached > entry even during what may look like a DDoS attack on my instance. > Otherwise, a Slashdot-like event could result in the most popular > combination of identifiers being promptly blocked, and legitimate users > being denied access, even when the content was actually "free" and wouldn't > have required any excessive resources to generate and serve. > > I've re-looked at http://freenginx.org/r/limit_req and > http://freenginx.org/r/limit_conn, but I don't see any way to exclude > cached content from still getting subjected to the limits. > > I think the standard route here may be to use an > http://freenginx.org/r/error_page exception handler, to automatically > handle the 503 errors thrown by limit_req and limit_conn, and continue > serving the content if cached, but I'm not quite certain how to integrate > it with http://freenginx.org/r/proxy_cache. Any suggestions? I don't think there is a good way to check if the particular request is going to be served from the cache or not. An obvious solution would be to introduce additional proxy layer after the cache, and apply limits there. Another possible solution might be to use proxy_cache with proxy_pass to a backend which always returns an error, and error_page to handle errors in a different location with limits, the same proxy_cache and proxy_pass to the real backend. > One option may be to use http://freenginx.org/r/proxy_store instead of > proxy_cache, but I'm not sure that'll work properly when I'm also caching > the search result pages, too, to account for the Slashdot-like events > (they're currently referred to as "When many people access the same link > simultaneously -- such as when a GitLab link is shared in a chat room"), > without creating new restrictions on the input for the search query string, > for example, not to mention having to do manual purges of the cached data > and missing all the other nice features of the standard proxy_cache. Using proxy_store with non-trivial URIs might be problematic, as well as using it for content which might change. Basically, it is a mechanism to mirror static files which never change. While using it as a cache is certainly possible, it is going to be non-trivial and error-prone solution. Additional proxy layer is probably much easier. Also, not directly related to the question, but rather about AI-scrapers in general: - For Mercurial repositories on freenginx.org, which effectively provide infinite number of distinct resources, I observe that AI-scrapers started to use large botnets with multiple IP addresses from different netblocks (millions of unique IP addresses identified as abusive AI-scrapers in just a couple of days). Limiting them with limit_req / limit_conn with traditional IP-based or netblock-based limits become ineffective. - Using userid session cookies (http:/freenginx.org/r/userid) and limiting users without $uid_got seems to be effective last-resort measure: abusive bots don't seem to try to use cookies at all. It can block legitimate users (if all the limits are already consumed by bots), but for legitimate users with real browsers it's just a matter of refreshing the page. I initially though I would have to implement some proof-of-work mechanism to stop them, similarly to what Anubis does, but trivial cookies seem to be quote effective as well. - Some AI-labyrinth solutions might be also effective here. Since AI-scrapers ignore "nofollow" (and that's why they try to scrape Mercurial repositories on freenginx.org in the first place), they basically can index any infinite resources. Which gives an opportunity to keep them indexing something really cheap to generate rather than real resources, without any negative effects on legitimate users or robots. Hope this helps. -- Maxim Dounin http://mdounin.ru/ From mdounin at mdounin.ru Tue May 19 15:20:21 2026 From: mdounin at mdounin.ru (Maxim Dounin) Date: Tue, 19 May 2026 18:20:21 +0300 Subject: freenginx-1.31.1 Message-ID: Changes with freenginx 1.31.1 19 May 2026 *) Feature: the "off" parameter of the "index" directive. Thanks to Fabiano Furtado. *) Bugfix: a segmentation fault might occur in a worker process if the "rewrite" directive was used to change request arguments and other directives of the ngx_http_rewrite_module were executed afterwards. *) Bugfix: in the "set" directive. *) Bugfix: a segmentation fault might occur in a worker process if the ngx_http_charset_module was used to convert responses from UTF-8. *) Bugfix: in the ngx_http_charset_module. *) Bugfix: a segmentation fault might occur in a worker process if the "ssl_ocsp" directive was used. *) Bugfix: a segmentation fault might occur in a worker process if the "scgi_pass" or "uwsgi_pass" directives were used. *) Bugfix: in the "scgi_request_buffering" directive. *) Bugfix: in HTTP/3. -- Maxim Dounin http://freenginx.org/