Version in base suite: 1.26.3-3+deb13u2 Version in overlay suite: 1.26.3-3+deb13u3 Base version: nginx_1.26.3-3+deb13u3 Target version: nginx_1.26.3-3+deb13u4 Base file: /srv/ftp-master.debian.org/ftp/pool/main/n/nginx/nginx_1.26.3-3+deb13u3.dsc Target file: /srv/ftp-master.debian.org/policy/pool/main/n/nginx/nginx_1.26.3-3+deb13u4.dsc changelog | 16 ++++++++++++++++ conf/fastcgi_params | 31 +++++++++++++++++++++++++++++++ conf/proxy_params | 31 ++++++++++++++++++++++++++++++- conf/scgi_params | 31 +++++++++++++++++++++++++++++++ conf/uwsgi_params | 31 +++++++++++++++++++++++++++++++ nginx-common.NEWS | 16 ++++++++++++++++ 6 files changed, 155 insertions(+), 1 deletion(-) dpkg-source: warning: cannot verify inline signature for /srv/release.debian.org/tmp/tmpqsmthts9/nginx_1.26.3-3+deb13u3.dsc: no acceptable signature found dpkg-source: warning: cannot verify inline signature for /srv/release.debian.org/tmp/tmpqsmthts9/nginx_1.26.3-3+deb13u4.dsc: no acceptable signature found diff -Nru nginx-1.26.3/debian/changelog nginx-1.26.3/debian/changelog --- nginx-1.26.3/debian/changelog 2026-03-30 17:41:51.000000000 +0000 +++ nginx-1.26.3/debian/changelog 2026-04-20 17:52:06.000000000 +0000 @@ -1,3 +1,19 @@ +nginx (1.26.3-3+deb13u4) trixie; urgency=medium + + * d/conf/*_params: use "$host" instead of "$http_host" + * "$http_host" forwards the Host header exactly as supplied by the client + and may not match the effective request target (e.g. absolute-form + requests with a conflicting Host header) + this can expose inconsistent or attacker-controlled host values to + backend applications (uwsgi, fastcgi, scgi, proxy) + * switch to "$host" as a safer, normalized alternative + * note: this changes behaviour, as "$host" does not preserve the + client-supplied port; deployments relying on "$http_host" including + a port number may be affected + * it is workaround for Debian bug #1126960 for stable/oldstable release + + -- Jan Mojžíš Mon, 20 Apr 2026 17:52:06 +0000 + nginx (1.26.3-3+deb13u3) trixie; urgency=medium * backport changes from upstream nginx, fixes for buffer overflow diff -Nru nginx-1.26.3/debian/conf/fastcgi_params nginx-1.26.3/debian/conf/fastcgi_params --- nginx-1.26.3/debian/conf/fastcgi_params 2026-03-30 17:41:51.000000000 +0000 +++ nginx-1.26.3/debian/conf/fastcgi_params 2026-04-20 17:52:06.000000000 +0000 @@ -24,3 +24,34 @@ # PHP only, required if PHP was built with --enable-force-cgi-redirect fastcgi_param REDIRECT_STATUS 200; + +# !!! Security workaround !!! +# Do not use HTTP_HOST as "$http_host". +# +# "$http_host" is the Host header exactly as supplied by the client. +# This is unsafe when a client sends an absolute-form request target together +# with a different Host header, for example: +# +# GET https://example.com/ HTTP/1.1 +# Host: malformedhost +# +# In such a case, passing "$http_host" upstream exposes the raw client-supplied +# Host value ("malformedhost") to the backend application, even though it does +# not match the effective request target. Applications often use HTTP_HOST for +# redirects, absolute URL generation, virtual host routing, or security checks; +# forwarding the raw Host header can therefore lead to incorrect or unsafe +# behaviour. +# +# Newer nginx versions (since 1.30.0) introduce variables "$is_request_port" and +# "$request_port", allowing HTTP_HOST to be constructed as: +# $host$is_request_port$request_port +# +# In stable/oldstable packages we use "$host" as a security workaround. +# It avoids forwarding an untrusted raw Host header to the backend. +# +# Note: this changes behaviour compared to previous versions, because "$host" +# does not preserve the client-supplied port, while "$http_host" typically +# does. Existing deployments that rely on "$http_host" containing a port number +# may therefore break or behave differently after this change. + +fastcgi_param HTTP_HOST $host; diff -Nru nginx-1.26.3/debian/conf/proxy_params nginx-1.26.3/debian/conf/proxy_params --- nginx-1.26.3/debian/conf/proxy_params 2026-03-30 17:41:51.000000000 +0000 +++ nginx-1.26.3/debian/conf/proxy_params 2026-04-20 17:52:06.000000000 +0000 @@ -1,4 +1,33 @@ -proxy_set_header Host $http_host; +# !!! Security workaround !!! +# Do not set the `Host` header as "$http_host". +# +# "$http_host" is the Host header exactly as supplied by the client. +# This is unsafe when a client sends an absolute-form request target together +# with a different Host header, for example: +# +# GET https://example.com/ HTTP/1.1 +# Host: malformedhost +# +# In such a case, passing "$http_host" upstream exposes the raw client-supplied +# Host value ("malformedhost") to the backend application, even though it does +# not match the effective request target. Applications often use HTTP_HOST for +# redirects, absolute URL generation, virtual host routing, or security checks; +# forwarding the raw Host header can therefore lead to incorrect or unsafe +# behaviour. +# +# Newer nginx versions (since 1.30.0) introduce variables "$is_request_port" and +# "$request_port", allowing `Host` to be constructed as: +# $host$is_request_port$request_port +# +# In stable/oldstable packages we use "$host" as a security workaround. +# It avoids forwarding an untrusted raw Host header to the backend. +# +# Note: this changes behaviour compared to previous versions, because "$host" +# does not preserve the client-supplied port, while "$http_host" typically +# does. Existing deployments that rely on "$http_host" containing a port number +# may therefore break or behave differently after this change. + +proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; diff -Nru nginx-1.26.3/debian/conf/scgi_params nginx-1.26.3/debian/conf/scgi_params --- nginx-1.26.3/debian/conf/scgi_params 2026-03-30 17:41:51.000000000 +0000 +++ nginx-1.26.3/debian/conf/scgi_params 2026-04-20 17:52:06.000000000 +0000 @@ -15,3 +15,34 @@ scgi_param REMOTE_PORT $remote_port; scgi_param SERVER_PORT $server_port; scgi_param SERVER_NAME $server_name; + +# !!! Security workaround !!! +# Do not use HTTP_HOST as "$http_host". +# +# "$http_host" is the Host header exactly as supplied by the client. +# This is unsafe when a client sends an absolute-form request target together +# with a different Host header, for example: +# +# GET https://example.com/ HTTP/1.1 +# Host: malformedhost +# +# In such a case, passing "$http_host" upstream exposes the raw client-supplied +# Host value ("malformedhost") to the backend application, even though it does +# not match the effective request target. Applications often use HTTP_HOST for +# redirects, absolute URL generation, virtual host routing, or security checks; +# forwarding the raw Host header can therefore lead to incorrect or unsafe +# behaviour. +# +# Newer nginx versions (since 1.30.0) introduce variables "$is_request_port" and +# "$request_port", allowing HTTP_HOST to be constructed as: +# $host$is_request_port$request_port +# +# In stable/oldstable packages we use "$host" as a security workaround. +# It avoids forwarding an untrusted raw Host header to the backend. +# +# Note: this changes behaviour compared to previous versions, because "$host" +# does not preserve the client-supplied port, while "$http_host" typically +# does. Existing deployments that rely on "$http_host" containing a port number +# may therefore break or behave differently after this change. + +scgi_param HTTP_HOST $host; diff -Nru nginx-1.26.3/debian/conf/uwsgi_params nginx-1.26.3/debian/conf/uwsgi_params --- nginx-1.26.3/debian/conf/uwsgi_params 2026-03-30 17:41:51.000000000 +0000 +++ nginx-1.26.3/debian/conf/uwsgi_params 2026-04-20 17:52:06.000000000 +0000 @@ -15,3 +15,34 @@ uwsgi_param REMOTE_PORT $remote_port; uwsgi_param SERVER_PORT $server_port; uwsgi_param SERVER_NAME $server_name; + +# !!! Security workaround !!! +# Do not use HTTP_HOST as "$http_host". +# +# "$http_host" is the Host header exactly as supplied by the client. +# This is unsafe when a client sends an absolute-form request target together +# with a different Host header, for example: +# +# GET https://example.com/ HTTP/1.1 +# Host: malformedhost +# +# In such a case, passing "$http_host" upstream exposes the raw client-supplied +# Host value ("malformedhost") to the backend application, even though it does +# not match the effective request target. Applications often use HTTP_HOST for +# redirects, absolute URL generation, virtual host routing, or security checks; +# forwarding the raw Host header can therefore lead to incorrect or unsafe +# behaviour. +# +# Newer nginx versions (since 1.30.0) introduce variables "$is_request_port" and +# "$request_port", allowing HTTP_HOST to be constructed as: +# $host$is_request_port$request_port +# +# In stable/oldstable packages we use "$host" as a security workaround. +# It avoids forwarding an untrusted raw Host header to the backend. +# +# Note: this changes behaviour compared to previous versions, because "$host" +# does not preserve the client-supplied port, while "$http_host" typically +# does. Existing deployments that rely on "$http_host" containing a port number +# may therefore break or behave differently after this change. + +uwsgi_param HTTP_HOST $host; diff -Nru nginx-1.26.3/debian/nginx-common.NEWS nginx-1.26.3/debian/nginx-common.NEWS --- nginx-1.26.3/debian/nginx-common.NEWS 2026-03-30 17:41:51.000000000 +0000 +++ nginx-1.26.3/debian/nginx-common.NEWS 2026-04-20 17:52:06.000000000 +0000 @@ -1,3 +1,19 @@ +nginx (1.26.3-3+deb13u4) UNRELEASED; urgency=medium + + * d/conf/*_params: use "$host" instead of "$http_host" + * "$http_host" forwards the Host header exactly as supplied by the client + and may not match the effective request target (e.g. absolute-form + requests with a conflicting Host header) + this can expose inconsistent or attacker-controlled host values to + backend applications (uwsgi, fastcgi, scgi, proxy) + * switch to "$host" as a safer, normalized alternative + * note: this changes behaviour, as "$host" does not preserve the + client-supplied port; deployments relying on "$http_host" including + a port number may be affected + * it is workaround for Debian bug #1126960 for stable/oldstable release + + -- Jan Mojžíš Mon, 20 Apr 2026 17:52:06 +0000 + nginx-common (1.10.2-4) unstable; urgency=medium Since nginx 1.9.14 Debian has gradually switched to dynamic loadable modules