Seeing nginx/1.21.5 in a Server header means you are running a mainline release from late 2021 that predates several fixed CVEs, most notably the ngx_http_mp4_module memory issues, so it should be upgraded. The version itself is not catastrophically broken, but it sits inside vulnerable ranges for issues patched later, and running a three-year-old web server is a finding in any audit. This guide separates what actually affects nginx/1.21.5 from what does not.
What nginx/1.21.5 actually is
nginx ships two branches: mainline (odd minor numbers like 1.21.x, 1.23.x) and stable (even minors like 1.20.x, 1.22.x). 1.21.5 is a mainline release from December 2021. Mainline gets features and fixes first, so being on mainline is not inherently wrong, but a specific pinned build like this one stops receiving anything the moment a newer release lands. You may also see build-specific header strings such as nginx-reuseport/1.21.1 from downstream or patched builds; the underlying advisory math is the same, driven by the base nginx version.
You can confirm the running version without trusting the header, which is often spoofed or stripped:
nginx -v
# nginx version: nginx/1.21.5
What does NOT affect this version
It is worth clearing up a common false positive first. The DNS resolver off-by-one memory overwrite, CVE-2021-23017, affected nginx from 0.6.18 through 1.20.0 and was fixed in 1.21.0. Because 1.21.5 is newer than 1.21.0, it already contains that fix. Scanners keyed only on "nginx, old" sometimes flag this incorrectly, so verify version ranges before you panic.
What DOES affect nginx/1.21.5
The relevant exposure is the pair of ngx_http_mp4_module issues disclosed in October 2022:
- CVE-2022-41741 — memory corruption in
ngx_http_mp4_module. - CVE-2022-41742 — memory disclosure in the same module.
Both affect nginx from 1.1.3 through 1.23.1, and 1.21.5 is squarely inside that range. They are fixed in 1.23.2 (mainline) and 1.22.1 (stable). Apache-style caveat applies: these only matter if nginx was built with ngx_http_mp4_module and the mp4 directive is actually used in your configuration to serve progressive-download media. Both are rated medium severity; a specially crafted mp4 file can crash a worker process or disclose worker memory.
Check whether the module is even compiled in before you treat this as urgent:
nginx -V 2>&1 | tr ' ' '\n' | grep -i mp4
If that returns nothing and you have no mp4; directive, the practical risk from these two CVEs is low. If it does, the crafted-file path is reachable and you should move to a fixed version.
The safe upgrade targets
Do not upgrade to another random mainline pin. Pick a version that is at or past the fix line:
- For the stable branch: 1.22.1 or later (1.24.x and 1.26.x are later stable lines).
- For mainline: 1.23.2 or later.
Later releases also close subsequent issues, including the HTTP/3 QUIC problems in the experimental ngx_http_v3_module that appeared in 2023 and 2024. If you enabled HTTP/3, that is a separate reason to stay current rather than pinning any single old build.
Upgrading safely without breaking config
The upgrade itself is low-drama if you test the config first:
# On Debian/Ubuntu with the official nginx repo
sudo apt-get update && sudo apt-get install --only-upgrade nginx
nginx -t # validate configuration
sudo systemctl reload nginx
nginx -t parses the config and fails loudly on a bad directive before you reload, so a broken config never takes traffic. For containers, rebuild from a current tag rather than patching in place:
FROM nginx:1.27-alpine
Rebuilding from a maintained tag is the container equivalent of apt upgrade, and it also picks up base-image OS patches that an in-place binary swap would miss.
Do not stop at the nginx binary
The version string is one line item. A hardening pass on a public nginx should also confirm you are not leaking the version at all, since header disclosure hands attackers a free version-to-CVE lookup:
http {
server_tokens off;
}
Beyond that, treat the web server like any other dependency: know what OS packages and modules are compiled into your image, and scan the image, not just the app. Continuous image scanning is exactly the gap that a container-aware SCA workflow is meant to close, because a "clean" application can still ship on a base image full of old libraries.
For a broader look at keeping runtime dependencies current, the patch management fundamentals material covers how to prioritize when you have dozens of these version findings at once.
FAQ
Is nginx/1.21.5 vulnerable to the DNS resolver CVE-2021-23017?
No. That resolver vulnerability was fixed in nginx 1.21.0, and 1.21.5 is newer, so it already includes the fix. Scanners sometimes flag it incorrectly based on age alone.
Which CVEs actually affect nginx/1.21.5?
The ngx_http_mp4_module issues CVE-2022-41741 and CVE-2022-41742 affect versions 1.1.3 through 1.23.1, which includes 1.21.5. They are only exploitable if nginx serves media through the mp4 module.
What version should I upgrade nginx/1.21.5 to?
Move to at least 1.23.2 on mainline or 1.22.1 on the stable branch. In practice, jumping to a current stable line such as 1.26.x is better because it also closes later HTTP/3 issues.
How do I stop nginx from advertising its version?
Set server_tokens off; in the http block. This removes the version from the Server header and error pages so attackers cannot map your build straight to known CVEs.