From mdounin at mdounin.ru Tue Jul 7 15:11:33 2026 From: mdounin at mdounin.ru (Maxim Dounin) Date: Tue, 7 Jul 2026 18:11:33 +0300 Subject: freenginx-1.31.3 Message-ID: Changes with freenginx 1.31.3 07 Jul 2026 *) Feature: additional checks are now used during variable substitution, including during execution of the ngx_http_rewrite_module directives, to prevent buffer overruns in case of errors in the code. *) Bugfix: if the "auth_request_set" directive or regular expression named captures were used to change prefix variables, such as "$http_...", corresponding variables became empty in other parts of the configuration. *) Bugfix: changing the $limit_rate and $args variables with the "auth_request_set" directive or regular expression named captures worked incorrectly. *) Bugfix: in error handling in the mail proxy module. Thanks to Evan Hellman, Trail of Bits. *) Bugfix: in error handling when using gzipping. Thanks to Evan Hellman, Trail of Bits. *) Bugfix: in HTTP/3. *) Bugfix: a segmentation fault might occur in a worker process when sending very long request header lines to a gRPC backend. Thanks to Evan Hellman, Trail of Bits. *) 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_perl_module. Thanks to Evan Hellman, Trail of Bits and Axel Mierczuk, Keith Hoodlet, 1Password's Off-by-1 Labs. *) Bugfix: in error handling when using the proxy_no_cache directive. Thanks to Valentin Bartenev. -- Maxim Dounin http://freenginx.org/ From dshiell at netflix.com Wed Jul 22 22:24:05 2026 From: dshiell at netflix.com (Derek Shiell) Date: Wed, 22 Jul 2026 15:24:05 -0700 Subject: CVE status check Message-ID: Hello, Has FreeNGINX assessed the following NGINX security issues, and do they affect the current FreeNGINX release? - CVE-2026-42533 ? regex captures and map - CVE-2026-60005 ? ngx_http_slice_module - CVE-2026-56434 ? ngx_http_ssi_module Our downstream build is based on FreeNGINX 1.31.1 and enable and configure the slice module, so CVE-2026-60005 is particularly relevant. Are fixes planned for a FreeNGINX point release? If so, is there an expected version or timeline? Otherwise, are there recommended commits for downstreams to backport? References: - https://nvd.nist.gov/vuln/detail/CVE-2026-42533 - https://nvd.nist.gov/vuln/detail/CVE-2026-60005 - https://nvd.nist.gov/vuln/detail/CVE-2026-56434 -------------- next part -------------- An HTML attachment was scrubbed... URL: From mdounin at mdounin.ru Thu Jul 23 01:31:40 2026 From: mdounin at mdounin.ru (Maxim Dounin) Date: Thu, 23 Jul 2026 04:31:40 +0300 Subject: CVE status check In-Reply-To: References: Message-ID: Hello! On Wed, Jul 22, 2026 at 03:24:05PM -0700, Derek Shiell via nginx wrote: > Hello, > > Has FreeNGINX assessed the following NGINX security issues, and do > they affect the current FreeNGINX release? > > - CVE-2026-42533 ? regex captures and map > - CVE-2026-60005 ? ngx_http_slice_module > - CVE-2026-56434 ? ngx_http_ssi_module > > Our downstream build is based on FreeNGINX 1.31.1 and enable and > configure the slice module, so CVE-2026-60005 is particularly > relevant. > > Are fixes planned for a FreeNGINX point release? If so, is there an > expected version or timeline? > Otherwise, are there recommended commits for downstreams to backport? > > References: > - https://nvd.nist.gov/vuln/detail/CVE-2026-42533 > - https://nvd.nist.gov/vuln/detail/CVE-2026-60005 > - https://nvd.nist.gov/vuln/detail/CVE-2026-56434 CVE-2026-42533 (regex captures and map) is a bug (a well-known one, actually), which was mitigated in freenginx 1.31.3 (and the real fix is expected in freenginx 1.31.4, patches are already in the nginx-devel@ mailing list). See here for additional details: https://github.com/freenginx/nginx/issues/27 The mitigation patches were imported by F5 with the claim that it's a "major" security vulnerability. However, this bug requires a specially crafted configuration, which is mostly meaningless and cannot be reasonably used without noticing the bug. By no means it is a security vulnerability. CVE-2026-60005 (ngx_http_slice_module) is a bug which affects subrequests created by the slice module, yet it also requires a quite special configuration (and I very much doubt such a configuration can be reasonably used without noticing the issue). See this commit for more details: https://github.com/nginx/nginx/commit/0cca8e055a2d909f1a00c2071665b502ec2fe94c CVE-2026-56434 (ngx_http_ssi_module) is a bug in SSI handling which can cause duplicate subrequest finalization with certain timing conditions, yet it can only by triggered by your own backend server. Not sure about "limited modification of memory" which F5 advisory claims as I haven't looked into details yet, but the DoS impact is certainly meaningless as it is implied by SSI and backend control required to trigger the bug. See this commit for more details: https://github.com/nginx/nginx/commit/700dc9e0e750e3f63587f9d0f9f36bae5ec47202 Summing the above, none of the issues looks like a security vulnerability to me. Hope this helps. -- Maxim Dounin http://mdounin.ru/ From paul at stormy.ca Wed Jul 29 15:40:39 2026 From: paul at stormy.ca (Paul) Date: Wed, 29 Jul 2026 11:40:39 -0400 Subject: ipv 4 and 6 Message-ID: <4f93f13a-a3ff-48ed-8192-dd4c91cc8123@stormy.ca> nginx/1.18.0 (Ubuntu). For decades we have never explicitly "listened" for 1pv6, using only "listen 443 ssl;" on a couple of dozen websites. As of two days ago, W3C (world wide web consortium) html, css, etc verification tools are no longer functional -- our websites "time out" "500 Can't connect to mysite.com:443 (Connection timed out)" W3C have nslookup showing ipv4 and ipv6 addresses. There is nothing in our firewalls "denying" them, there is nothing in the nginx logs. I'm reticent to just add trillions of ipv6 possibilities of abuse (we're experiencing om/off ddos attacks from ai/automated/bots to the tune of 56^6/day). Any thoughts? Thanks -- Paul From teward at thomas-ward.net Wed Jul 29 17:12:49 2026 From: teward at thomas-ward.net (Thomas Ward) Date: Wed, 29 Jul 2026 13:12:49 -0400 Subject: ipv 4 and 6 In-Reply-To: <4f93f13a-a3ff-48ed-8192-dd4c91cc8123@stormy.ca> References: <4f93f13a-a3ff-48ed-8192-dd4c91cc8123@stormy.ca> Message-ID: <3468b432-618e-4b4f-9d19-5337376f5221@thomas-ward.net> Just an FYI, but nginx and freenginx are **completely independent products**.? If you are looking for support/questions with regards to the NGINX in ubuntu, you should be reaching out to nginx.org mailing lists or support mechanisms from Ubuntu. On 2026-07-29 11:40, Paul wrote: > nginx/1.18.0 (Ubuntu).?? For decades we have never explicitly > "listened" for 1pv6, using only "listen 443 ssl;" on a couple of dozen > websites. > > As of two days ago, W3C (world wide web consortium) html, css, etc > verification tools are no longer functional -- our websites "time out" > "500 Can't connect to mysite.com:443 (Connection timed out)" > > W3C have nslookup showing ipv4 and ipv6 addresses.? There is nothing > in our firewalls "denying" them, there is nothing in the nginx logs. > > I'm reticent to just add trillions of ipv6 possibilities of abuse > (we're experiencing om/off ddos attacks from ai/automated/bots to the > tune of 56^6/day). > > Any thoughts? > > Thanks -- Paul > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mdounin at mdounin.ru Wed Jul 29 20:08:56 2026 From: mdounin at mdounin.ru (Maxim Dounin) Date: Wed, 29 Jul 2026 23:08:56 +0300 Subject: ipv 4 and 6 In-Reply-To: <4f93f13a-a3ff-48ed-8192-dd4c91cc8123@stormy.ca> References: <4f93f13a-a3ff-48ed-8192-dd4c91cc8123@stormy.ca> Message-ID: Hello! On Wed, Jul 29, 2026 at 11:40:39AM -0400, Paul wrote: > nginx/1.18.0 (Ubuntu). For decades we have never explicitly "listened" for > 1pv6, using only "listen 443 ssl;" on a couple of dozen websites. > > As of two days ago, W3C (world wide web consortium) html, css, etc > verification tools are no longer functional -- our websites "time out" "500 > Can't connect to mysite.com:443 (Connection timed out)" > > W3C have nslookup showing ipv4 and ipv6 addresses. There is nothing in our > firewalls "denying" them, there is nothing in the nginx logs. > > I'm reticent to just add trillions of ipv6 possibilities of abuse (we're > experiencing om/off ddos attacks from ai/automated/bots to the tune of > 56^6/day). > > Any thoughts? So, your website names resolves to both IPv4 and IPv6 addresses, but you don't have any IPv6 listens, correct? This looks like a configuration error to me, and the fact that W3C tools fail isn't surprising. There are two obvious solutions: either add relevant IPv6 listen directives, or remove the IPv6 addresses from the website names. -- Maxim Dounin http://mdounin.ru/ From mdounin at mdounin.ru Wed Jul 29 20:10:59 2026 From: mdounin at mdounin.ru (Maxim Dounin) Date: Wed, 29 Jul 2026 23:10:59 +0300 Subject: ipv 4 and 6 In-Reply-To: <3468b432-618e-4b4f-9d19-5337376f5221@thomas-ward.net> References: <4f93f13a-a3ff-48ed-8192-dd4c91cc8123@stormy.ca> <3468b432-618e-4b4f-9d19-5337376f5221@thomas-ward.net> Message-ID: Hello! On Wed, Jul 29, 2026 at 01:12:49PM -0400, Thomas Ward via nginx wrote: > Just an FYI, but nginx and freenginx are **completely independent > products**.? If you are looking for support/questions with regards to the > NGINX in ubuntu, you should be reaching out to nginx.org mailing lists or > support mechanisms from Ubuntu. There is no such thing as "nginx.org mailing lists" anymore. -- Maxim Dounin http://mdounin.ru/ From stormy at stormy.ca Thu Jul 30 00:26:18 2026 From: stormy at stormy.ca (Stormy Weather) Date: Wed, 29 Jul 2026 20:26:18 -0400 Subject: ipv 4 and 6 In-Reply-To: References: <4f93f13a-a3ff-48ed-8192-dd4c91cc8123@stormy.ca> Message-ID: <909522a8-de58-4d3c-a23e-5ef351777036@stormy.ca> On 2026-07-29 16:08, Maxim Dounin wrote: > Hello! > > On Wed, Jul 29, 2026 at 11:40:39AM -0400, Paul wrote: > >> nginx/1.18.0 (Ubuntu). For decades we have never explicitly "listened" for >> 1pv6, using only "listen 443 ssl;" on a couple of dozen websites. >> >> As of two days ago, W3C (world wide web consortium) html, css, etc >> verification tools are no longer functional -- our websites "time out" "500 >> Can't connect to mysite.com:443 (Connection timed out)" >> >> W3C have nslookup showing ipv4 and ipv6 addresses. There is nothing in our >> firewalls "denying" them, there is nothing in the nginx logs. >> >> I'm reticent to just add trillions of ipv6 possibilities of abuse (we're >> experiencing om/off ddos attacks from ai/automated/bots to the tune of >> 56^6/day). >> >> Any thoughts? > > So, your website names resolves to both IPv4 and IPv6 addresses, > but you don't have any IPv6 listens, correct? Maxim, many thanks. This might, or not, be IPv6 related Our names only resolve to IPv4 (static 70.52.195.238 for nearly thirty years.) For example: CLI curl https://ultramarine.ca is functional through nginx proxied to apache2 But returns "500 Can't connect to ultramarine.ca:443 (Connection timed out)" and if I do a curl ultramarine.ca:443 on that same exact url I get

400 Bad Request

The plain HTTP request was sent to HTTPS port
nginx
So W3C are reporting "time out" and nginx is apparently sending "400" There is nothing in the nginx access or error logs Spaseeba ee dobrey vyecher Paul > > This looks like a configuration error to me, and the fact that W3C > tools fail isn't surprising. There are two obvious solutions: > either add relevant IPv6 listen directives, or remove the IPv6 > addresses from the website names. From mdounin at mdounin.ru Thu Jul 30 01:00:40 2026 From: mdounin at mdounin.ru (Maxim Dounin) Date: Thu, 30 Jul 2026 04:00:40 +0300 Subject: ipv 4 and 6 In-Reply-To: <909522a8-de58-4d3c-a23e-5ef351777036@stormy.ca> References: <4f93f13a-a3ff-48ed-8192-dd4c91cc8123@stormy.ca> <909522a8-de58-4d3c-a23e-5ef351777036@stormy.ca> Message-ID: Hello! On Wed, Jul 29, 2026 at 08:26:18PM -0400, Stormy Weather wrote: > On 2026-07-29 16:08, Maxim Dounin wrote: > > Hello! > > > > On Wed, Jul 29, 2026 at 11:40:39AM -0400, Paul wrote: > > > > > nginx/1.18.0 (Ubuntu). For decades we have never explicitly "listened" for > > > 1pv6, using only "listen 443 ssl;" on a couple of dozen websites. > > > > > > As of two days ago, W3C (world wide web consortium) html, css, etc > > > verification tools are no longer functional -- our websites "time out" "500 > > > Can't connect to mysite.com:443 (Connection timed out)" > > > > > > W3C have nslookup showing ipv4 and ipv6 addresses. There is nothing in our > > > firewalls "denying" them, there is nothing in the nginx logs. > > > > > > I'm reticent to just add trillions of ipv6 possibilities of abuse (we're > > > experiencing om/off ddos attacks from ai/automated/bots to the tune of > > > 56^6/day). > > > > > > Any thoughts? > > > > So, your website names resolves to both IPv4 and IPv6 addresses, > > but you don't have any IPv6 listens, correct? > > Maxim, many thanks. This might, or not, be IPv6 related > > Our names only resolve to IPv4 (static 70.52.195.238 for nearly thirty > years.) For example: > > CLI curl https://ultramarine.ca is functional through nginx proxied to > apache2 > > But > > > returns "500 Can't connect to ultramarine.ca:443 (Connection timed out)" > > and if I do a curl ultramarine.ca:443 on that same exact url I get > >

400 Bad Request

>
The plain HTTP request was sent to HTTPS port
>
nginx
> > So W3C are reporting "time out" and nginx is apparently sending "400" It looks like 400 as shown by curl is due to no HTTPS protocol specified to curl. Try "curl https://ultramarine.ca:443" instead, or just "curl https://ultramarine.ca". > There is nothing in the nginx access or error logs I suspect the "Can't connect" error as reported by validator is real, and the question is where the connection is dropped. In my tests, validator requests look like: 52.22.66.203 - - [30/Jul/2026:03:50:30 +0300] "GET /?validator HTTP/1.1" 200 1893 "-" "W3C_Validator/1.3 libwww-perl/6.78" The IP seems to be fixed, but it belongs to the AWS netblock, so might be banned at various levels due to hostile AI-scraping. As a first step I would recommend checking with tcpdump on the incoming interface if packets arrive from the IP address at all when you start validation, and then start digging either into the host configuration or into the network. > Spaseeba ee dobrey vyecher :) -- Maxim Dounin http://mdounin.ru/