Nginx 1.18.0 Vulnerabilities: Audit and Upgrade Path

The honest audit result first: nginx 1.18.0 vulnerabilities are real but narrower than raw scanner output suggests. The release stopped receiving upstream fixes in 2021, and two disclosure sets genuinely matter — the CVE-2021-23017 DNS resolver flaw and the 2022 mp4 module CVEs — but each requires specific configuration to be exploitable, and distribution packages that report version 1.18.0 often already carry backported fixes. Here is how to work out what you actually run, which findings are live, and how to get onto a supported line without breaking your config.

Is nginx 1.18.0 still supported?

No. Nginx 1.18.0 shipped in April 2020 as the stable branch of its day, and the project maintains only the current stable and mainline branches. When the 1.20 line became stable in 2021, the 1.18 branch stopped receiving fixes of any kind. The consequence compounds every year: any nginx vulnerabilities disclosed since then have never produced an official 1.18 patch, and never will. If you are running a vanilla 1.18.0 binary from nginx.org today, you are running a build frozen before every advisory discussed below.

The important nuance is that "reports version 1.18.0" and "vanilla 1.18.0" are different claims — Linux distributions froze on this version and patched it themselves, which we will come back to.

Which nginx 1.18.0 vulnerabilities are actually exploitable?

Two disclosure sets deserve attention, and both are configuration-gated:

• CVE-2021-23017 — DNS resolver off-by-one. A one-byte heap overwrite in nginx's built-in DNS resolver, affecting versions from 0.6.18 through 1.20.0 and fixed in 1.20.1. Exploitation requires the resolver directive to be configured — used for re-resolving upstream hostnames, OCSP stapling lookups, and similar — and an attacker able to spoof DNS responses to it. Under those conditions this is a serious, memory-corrupting bug with published exploitation research; if grep -r resolver /etc/nginx/ returns hits on an unpatched build, treat it as a priority.
• CVE-2022-41741 and CVE-2022-41742 — mp4 module memory corruption and disclosure. Both live in ngx_http_mp4_module and were fixed in 1.23.2 and 1.22.1. They only matter if the module is compiled in and an mp4 directive is active, and the practical risk concentrates where untrusted or user-uploaded video files get served through it.

If your build has neither the resolver directive nor active mp4 handling, 1.18.0's headline CVEs are not reachable in your deployment — which is an argument for accurate triage, not for staying on an unsupported branch.

Why does your scanner flag patched builds?

Because most detections are version-based, and versions lie in both directions. Ubuntu 20.04 ships nginx as 1.18.0-0ubuntu1.x for its entire lifecycle and backports security fixes into it — its packages received the CVE-2021-23017 fix while still reporting 1.18.0 in the server banner. A banner-grabbing scanner flags the fixed build; a naive reading of the flag wastes a patching cycle. The reverse failure also exists: a hand-compiled vanilla binary reports the same string and has none of the fixes.

The way to resolve it is package metadata, not banners: apt changelog nginx | grep CVE on Debian/Ubuntu, or rpm -q --changelog nginx | grep CVE on RHEL-family systems, tells you which advisories the installed build actually contains. Record the answer in your findings, because this same false positive will resurface at every rescan and every audit until the upgrade lands.

What is the upgrade path from nginx 1.18.0?

The destination is the current stable line (the 1.26-and-newer stable branches, as of 2025) via your distro's maintained package or the official nginx.org repository. The migration itself is usually undramatic — nginx config compatibility across these versions is good — but do it deliberately:

1. Inventory what you built. nginx -V lists compile-time modules and flags; anything third-party (Lua, RTMP, ModSecurity) must be available for the target version before you switch.
2. Stage the config. Load your existing configuration against the new binary with nginx -t in a staging environment and clear the deprecation warnings.
3. Canary the rollout. Move one node behind the load balancer, watch error rates and latency, then proceed.
4. Containers: rebuild, don't patch. If 1.18.0 is inside an image, change the base tag to a current one and rebuild — patching binaries in place inside images recreates the problem with worse auditability.

While you are at it, set server_tokens off so the version stops advertising itself in headers and error pages.

How do you verify after the upgrade?

Confirm the binary (nginx -v), confirm the fleet — this is where continuous scanning earns its keep, because the third forgotten instance is the one that stays vulnerable. An external DAST scan validates what the server exposes in practice, and component-level scanning catches nginx copies embedded in images and appliances that host-based inventory misses. Then leave the monitoring on: the point of moving to a supported branch is that the next advisory arrives with a patch you can actually apply.

FAQ

Is nginx 1.18.0 safe if it only serves internal traffic?

Safer, not safe. The resolver flaw depends on DNS spoofing rather than direct client requests, so network position matters less than you might hope, and internal networks are exactly where attackers pivot. Unsupported software on internal systems is deferred risk, not avoided risk.

Does CVE-2021-23017 affect every nginx 1.18.0 install?

No — only configurations using the resolver directive, and only vanilla or unpatched builds. Distro packages from Ubuntu and others backported the fix while keeping the 1.18.0 version string. Check your package changelog before scheduling emergency work.

Which version should I upgrade to in 2025?

The newest stable release your platform supports — the 1.26 stable line or newer. Avoid landing on another already-EOL intermediate branch like 1.20 or 1.22; the goal is a branch that still receives fixes.

Does upgrading to 1.22.1 fully resolve nginx 1.22.1 vulnerabilities?

Only for the mp4-module CVEs it was released to fix. 1.22.1 itself is now an EOL intermediate branch, not a current stable line, so treat it as a stopgap rather than a destination — any nginx vulnerabilities disclosed after that release never received a 1.22.x patch, the same trap this whole guide is about avoiding.

Do these nginx vulnerabilities affect OpenResty?

OpenResty bundles the nginx core, so core CVEs like CVE-2021-23017 applied to it as well; the OpenResty project shipped its own patched releases. If you run OpenResty, map advisories through its release notes rather than raw nginx version numbers.