Nginx Version Vulnerabilities: CVE Guide from 1.10 to 1.24

The most-searched nginx 1.18.0 vulnerability set consists of CVE-2021-23017, a one-byte heap overwrite in the DNS resolver, plus the two 2022 mp4 module flaws — and every older nginx line adds further CVEs on top of that baseline. Nginx has a genuinely small CVE history for software of its ubiquity, but the project only patches its current stable and mainline branches, so the version you run determines exactly which advisories apply. This guide walks the widely deployed lines — 1.10, 1.14, 1.16, 1.18, and 1.24 — and maps each to its real exposure, because "outdated" and "exploitable in your config" are different findings.

The CVE baseline, newest to oldest

Working from the official nginx security advisories, these are the flaws that matter across this version span:

• CVE-2022-41741 / CVE-2022-41742 — memory corruption and memory disclosure in ngx_http_mp4_module. Affected: 1.1.3 through 1.23.1. Fixed: 1.23.2 and 1.22.1. Requires the mp4 module to be active and, practically, untrusted video files being served.
• CVE-2021-23017 — off-by-one heap write in the built-in resolver. Affected: 0.6.18 through 1.20.0. Fixed: 1.21.0 and 1.20.1. Requires the resolver directive in your config and an attacker who can spoof UDP DNS responses to it. This is the most serious bug in the range, with published exploitation research.
• CVE-2019-9511 and CVE-2019-9513 — HTTP/2 CPU-exhaustion attacks ("data dribble" and "priority storm" from the 2019 Netflix HTTP/2 research). Affected: 1.9.5 through 1.17.2. Fixed: 1.17.3 and 1.16.1. Requires http2 enabled.
• CVE-2017-7529 — integer overflow in the range filter enabling cache memory disclosure. Affected: 0.5.6 through 1.13.2. Fixed: 1.13.3 and 1.12.1. Trivially testable and the classic reason 1.10.x findings deserve urgency.

Version-by-version exposure

nginx 1.10.3 — the old Debian stretch / Ubuntu 16.04 workhorse. Vulnerable to everything above: the range filter disclosure, the HTTP/2 DoS pair if http2 is on, the resolver overwrite if resolver is set, and the mp4 CVEs. When people search for an nginx 1.10.3 exploit, CVE-2017-7529 is the one with easy public proof-of-concept traffic — a crafted Range header — which makes any internet-facing 1.10.3 with caching enabled a genuine incident-response question, not a backlog item.

nginx 1.14.0 — ships past the 1.13.3 fix, so the range filter bug is closed. Still exposed to the 2019 HTTP/2 pair, CVE-2021-23017, and the mp4 CVEs.

nginx 1.16.1 — this release was the security release: it shipped in August 2019 specifically carrying the HTTP/2 fixes for the stable branch. So an "nginx 1.16.1 exploit" search has a narrower answer than most assume — the version is not vulnerable to CVE-2019-9511/9513, but it remains exposed to CVE-2021-23017 and the mp4 module CVEs, both disclosed after the 1.16 branch left support.

nginx 1.18.0 — the Ubuntu 20.04 default and the version string most scanners report from legacy fleets. The nginx 1.18 vulnerabilities that matter are CVE-2021-23017 and the mp4 pair. Neither is unconditionally reachable: no resolver directive and no mp4 directive means the headline CVEs have no path into your deployment. That is an argument for accurate triage while you schedule the upgrade, not for keeping the version.

nginx 1.24.0 — a 2023 stable release that postdates all the fixes above. Its remaining story is CVE-2023-44487, the HTTP/2 Rapid Reset attack exploited in the wild in late 2023: nginx's default keepalive and stream limits already blunt the attack, and 1.25.3 added further mitigations for configurations with unusually high limits. Seeing nginx/1.24.0 in a banner is therefore not a vulnerability finding in itself — it is an end-of-support finding, since the branch no longer receives fixes.

The banner problem: distro backports lie in both directions

Version-based scanning against nginx produces systematic false positives because distributions freeze the version number and backport fixes. Ubuntu 20.04's 1.18.0-0ubuntu1.x packages received the CVE-2021-23017 fix while still announcing nginx/1.18.0. Meanwhile a hand-compiled vanilla 1.18.0 announces the identical string and has nothing. Resolve it with package metadata rather than banners:

# Debian/Ubuntu
apt changelog nginx | grep -i cve
# RHEL family
rpm -q --changelog nginx | grep -i cve

And check whether the vulnerable code paths are even configured:

nginx -V 2>&1 | tr ' ' '\n' | grep -E "http_mp4|http_v2"
grep -rE "^\s*(resolver|mp4)\b" /etc/nginx/

Record the conclusion against the finding. Otherwise the same flag returns every scan cycle, and a vulnerability management workflow that can carry that suppression context — the way Safeguard pairs version detection with reachability notes — saves the re-litigation.

Upgrade targets and how to move

As of late 2025 the supported branches are the 1.28 stable line and the 1.29 mainline; anything older gets no upstream fixes. Practical guidance:

1. Prefer your distro's maintained package if it tracks security backports for your OS lifetime — that is what you are paying the LTS subscription or using the distro for.
2. Use the official nginx.org repositories when you need the current stable on an older OS.
3. Config compatibility across 1.18 → 1.2x is good. The common migration snags are third-party dynamic modules compiled against the old binary (rebuild them) and deprecated directive warnings (listen ... http2 becoming the http2 on; directive style in newer lines). Run nginx -t against the new binary before cutover and stage a reload, not a restart, where possible.
4. Re-test HTTP/2 limits after upgrading if you previously raised keepalive_requests or stream concurrency for performance — Rapid Reset showed those knobs are security-relevant.

Prioritizing across a fleet

If you inherit a mixed estate — some 1.10, some 1.18, some 1.24 — sequence by exploitability, not version age alone: internet-facing 1.10–1.13 builds with caching (CVE-2017-7529) first; anything with a configured resolver on a pre-1.20.1 build next (CVE-2021-23017); mp4-serving hosts on pre-1.22.1 after that; then the general end-of-support upgrades. Pair the version findings with your web-layer testing so configuration exposure (TLS settings, header hardening, admin endpoints) rides along in the same change window — a DAST pass against the upgraded hosts confirms nothing regressed.

FAQ

Is nginx 1.18.0 still vulnerable if I never configured a resolver?

CVE-2021-23017 requires the resolver directive, so without it that bug is unreachable. The mp4 CVEs likewise need the mp4 module active. The version still belongs on an upgrade plan because it receives no fixes for whatever is disclosed next.

What is the actual nginx 1.10.3 exploit risk?

CVE-2017-7529 — a crafted Range request that can leak cache memory — is the practical one, with public PoCs. Combined with the later resolver and mp4 CVEs, 1.10.3 should be treated as urgent on any internet-facing host.

Does nginx/1.24.0 in a banner mean the server is vulnerable?

Not by itself. 1.24.0 postdates the CVEs covered here, and default configs substantially mitigate HTTP/2 Rapid Reset (CVE-2023-44487). It does mean the branch is out of support, so plan the move to the current stable line.

Why does my scanner flag a patched Ubuntu nginx?

Because Ubuntu backports fixes without changing the 1.18.0 banner. Verify with apt changelog nginx | grep -i cve and record the backport evidence against the finding.