[Pkg-nginx-maintainers] Bug#1134654: trixie-pu: package nginx/1.26.3-3+deb13u4
Jan Mojzis
janmojzis at debian.org
Wed Apr 22 20:51:11 BST 2026
Package: release.debian.org
Severity: normal
Tags: trixie
X-Debbugs-Cc: nginx at packages.debian.org
Control: affects -1 + src:nginx
User: release.debian.org at packages.debian.org
Usertags: pu
Hi,
the Debian nginx package currently uses "$http_host" in the default
*_params configuration files (proxy_params, fastcgi_params, scgi_params,
uwsgi_params) when setting HTTP_HOST / 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.
[ Impact ]
Without fix, this can lead to attacker-controlled
HTTP_HOST/Host values and may affect 'host' handling.
In particular, configuration relying on host-based logic may be bypassed,
e.g. exposing internal endpoints.
[ Tests ]
Autopkgtests have been added in unstable to cover this behaviour and
prevent regressions in the future. These tests were also used to verify
the fix for the stable/oldstable versions.
[ Risks ]
The change replaces "$http_host" with "$host", which does not preserve
the client-supplied port. Deployments relying on HTTP_HOST including a
port number may observe behavioural changes and should be used
carefully.
[ Checklist ]
[x] *all* changes are documented in the d/changelog
[x] I reviewed all changes and I approve them
[x] attach debdiff against the package in (old)stable
[x] the issue is verified as fixed in unstable
[ Changes ]
The fix contains only configuration changes.
Updates d/conf/*_params to use "$host" instead of "$http_host" when
setting HTTP_HOST / Host
[ Other info ]
The change also includes a NEWS entry describing
this behaviour change.
diff -Nru nginx-1.26.3/debian/changelog nginx-1.26.3/debian/changelog
--- nginx-1.26.3/debian/changelog 2026-03-30 19:41:51.000000000 +0200
+++ nginx-1.26.3/debian/changelog 2026-04-20 19:52:06.000000000 +0200
@@ -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žÃÅ¡ <janmojzis at debian.org> 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 19:41:51.000000000 +0200
+++ nginx-1.26.3/debian/conf/fastcgi_params 2026-04-20 19:52:06.000000000 +0200
@@ -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 19:41:51.000000000 +0200
+++ nginx-1.26.3/debian/conf/proxy_params 2026-04-20 19:52:06.000000000 +0200
@@ -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 19:41:51.000000000 +0200
+++ nginx-1.26.3/debian/conf/scgi_params 2026-04-20 19:52:06.000000000 +0200
@@ -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 19:41:51.000000000 +0200
+++ nginx-1.26.3/debian/conf/uwsgi_params 2026-04-20 19:52:06.000000000 +0200
@@ -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 19:41:51.000000000 +0200
+++ nginx-1.26.3/debian/nginx-common.NEWS 2026-04-20 19:52:06.000000000 +0200
@@ -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žÃÅ¡ <janmojzis at debian.org> 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
More information about the Pkg-nginx-maintainers
mailing list