Hinweis: Dieser Artikel wurde ursprünglich veröffentlicht in 2014. Einige Schritte, Befehle oder Softwareversionen haben sich möglicherweise geändert. Überprüfen Sie die aktuelle Dokumentation von Nginx für die neuesten Informationen.
Einführung
Nginx 1.4.6, released on March 4, 2014, is a stable-branch maintenance update that addresses two bugs introduced in earlier 1.4.x and 1.3.x releases. While neither issue is classified as a critical security vulnerability, both can lead to unexpected behavior or service crashes in production environments. This article provides a detailed breakdown of each fix, explains the technical impact, and offers guidance on upgrading safely.
Official Changelog
The complete changelog from nginx.org/en/CHANGES for this release:
Changes with nginx 1.4.6 04 Mar 2014
*) Bugfix: the "client_max_body_size" directive might not work when
reading a request body using chunked transfer encoding; the bug had
appeared in 1.3.9.
Thanks to Lucas Molas.
*) Bugfix: a segmentation fault might occur in a worker process when
proxying WebSocket connections.
Bug Fix 1 - client_max_body_size and Chunked Transfer Encoding
What Is client_max_body_size?
The client_max_body_size directive sets the maximum allowed size of the client request body. When a request exceeds this limit, Nginx returns a 413 Request Entity Too Large error. This directive is fundamental for protecting your server from excessively large uploads:
http {
client_max_body_size 10m; # Limit request bodies to 10 megabytes
}
The Problem
Starting with Nginx 1.3.9, when a client sent a request body using chunked transfer encoding (where the Content-Length header is absent and data is sent in chunks), the client_max_body_size check was not correctly enforced. This meant that clients could potentially bypass the body size limit by using chunked encoding, sending arbitrarily large payloads to the server.
Chunked transfer encoding is commonly used by:
- HTTP clients uploading large files without knowing the total size in advance
- API clients streaming data
- Proxied requests between microservices
The Impact
Without this fix, servers relying on client_max_body_size for upload protection could be vulnerable to:
- Disk exhaustion if uploaded data was written to temporary files
- Memory exhaustion if the request body was buffered in memory
- Denial of service from clients sending extremely large payloads
How to Verify the Fix
After upgrading, you can test that the directive works correctly with chunked requests:
# This should return 413 if client_max_body_size is set to 1m
dd if=/dev/zero bs=1M count=2 | curl -X POST \
-H "Transfer-Encoding: chunked" \
--data-binary @- http://localhost/upload
Bug Fix 2 - WebSocket Proxy Segmentation Fault
What Is WebSocket Proxying?
Nginx can proxy WebSocket connections using the proxy_pass directive combined with header upgrades:
location /ws/ {
proxy_pass http://backend;
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";
proxy_read_timeout 86400;
}
The Problem
Under certain conditions, when Nginx proxied WebSocket connections, a segmentation fault (SIGSEGV) could occur in the worker process. A segfault in a worker process causes that worker to crash and restart, which means:
- All connections being handled by that worker are dropped
- Active WebSocket sessions are terminated immediately
- The master process spawns a new worker, but the interruption is already felt
The Impact
For applications relying heavily on WebSocket connections (real-time chat, live dashboards, gaming servers, collaborative editing), this bug could cause intermittent connection drops and degraded user experience. The issue was particularly problematic under high-concurrency WebSocket workloads.
Symptoms to Watch For
If you were running Nginx 1.4.1 through 1.4.5 and experienced any of the following, this fix likely addresses your issue:
- Entries in the error log such as
signal 11 (SIGSEGV)orworker process exited on signal 11 - Intermittent WebSocket disconnections with no upstream errors
- Core dump files appearing in the Nginx working directory
How to Upgrade Nginx
On Debian/Ubuntu
# Update package lists
sudo apt-get update
# Upgrade Nginx to the latest available version in your repository
sudo apt-get install --only-upgrade nginx
# Verify the new version
nginx -v
# Test the configuration
sudo nginx -t
# Reload Nginx with zero downtime
sudo nginx -s reload
On RHEL/CentOS
# Update Nginx
sudo yum update nginx
# Verify version
nginx -v
# Test and reload
sudo nginx -t && sudo nginx -s reload
From Source
# Download the 1.4.6 source
wget http://nginx.org/download/nginx-1.4.6.tar.gz
tar xzf nginx-1.4.6.tar.gz
cd nginx-1.4.6
# Configure with the same options as your current build
# (run 'nginx -V' to see current compile options)
./configure --with-existing-options-here
make
sudo make install
# Test and restart
sudo nginx -t && sudo systemctl restart nginx
Post-Upgrade Überprüfung
After upgrading, confirm everything is working correctly:
# Check version
nginx -v
# Verify config syntax
sudo nginx -t
# Check that workers are running
ps aux | grep nginx
# Review error logs for any issues
tail -50 /var/log/nginx/error.log
Zusammenfassung
Nginx 1.4.6 is a moderate but important bug-fix release for the 1.4.x stable branch. The client_max_body_size bypass with chunked encoding could allow oversized uploads, and the WebSocket proxy segfault could crash worker processes under load. If you are running any version from 1.3.9 to 1.4.5 and use either chunked uploads or WebSocket proxying, upgrading to 1.4.6 or later is strongly recommended.