The most significant CVE tied to nginx 1.18.0 is CVE-2021-23017, a one-byte heap overwrite in the DNS resolver, but the bigger issue is that the entire nginx 1.18 branch is end-of-life and no longer receives official fixes for anything disclosed since 2021. A single CVE you can reason about; an unmaintained branch quietly accumulates every future flaw without a patch ever arriving. If you are running nginx 1.18.0 today, treat the version itself as the finding.
Let's separate the specific vulnerability from the maintenance problem, because they call for different responses.
CVE-2021-23017: The DNS Resolver Off-by-One
CVE-2021-23017 is an off-by-one heap write in nginx's built-in DNS resolver. When nginx processes a crafted DNS response, a one-byte overwrite can occur, which can lead to worker-process crashes and, in the worst case, has been discussed as potentially exploitable for remote code execution. It affected nginx versions from 0.6.18 up to and including 1.20.0, and was fixed in 1.20.1 and 1.21.0.
The important nuance: the bug only matters if your configuration actually uses the resolver directive. Many deployments never enable dynamic DNS resolution, in which case the vulnerable code path is not reachable. Check your config for a resolver line before you panic, but do not treat its absence as a reason to stay on an old build.
Why 1.18.0 Being End-of-Life Is the Real Problem
nginx 1.18.0 shipped in April 2020 as the stable branch of its era. When the 1.20 line became the new stable branch in 2021, the 1.18 branch stopped receiving fixes of any kind. That is how nginx has always worked: only the current stable and mainline branches get security backports.
The consequence is that any nginx vulnerability disclosed after the 1.18 branch was retired never produced, and never will produce, an official 1.18 patch. Your version string stays frozen at 1.18.0 while the list of unpatched known issues silently grows. A scanner that flags "nginx 1.18.0" is not really flagging one CVE; it is flagging "this software will never get another security fix from upstream."
The Distro-Patched Version Trap
Here is where version-based scanning gets tricky. Linux distributions such as Debian and Ubuntu package their own nginx builds and backport security fixes into them while keeping the upstream version number. So a package reporting 1.18.0-0ubuntu1.x may already contain the fix for CVE-2021-23017 even though the version string still says 1.18.0.
This means two systems both reporting "nginx 1.18.0" can have completely different real exposure: a vanilla build from source is genuinely unpatched, while a distro package may be fully current for its support window. To know which you have, check the distribution's changelog for your exact package version rather than trusting the nginx -v banner alone. A tool that reads the full package metadata, not just the marketing version, gives a truer answer than banner-grabbing does.
How to Check What You're Actually Running
Start with the basics:
# upstream version and build details
nginx -V 2>&1 | head -1
# on Debian/Ubuntu, the real package version and its changelog
dpkg -l | grep nginx
apt-get changelog nginx | grep -i cve | head
# is the resolver directive even in use?
nginx -T 2>/dev/null | grep -n "resolver"
If nginx -V shows a plain upstream 1.18.0 with no distro suffix, assume it is unpatched. If it is a distro package, confirm against that distro's security tracker for your package version.
The Fix: Upgrade Off the Dead Branch
The durable answer is not to chase individual backports; it is to get onto a supported branch. Move to a current stable release, which is maintained and receives security fixes. If you rely on your distribution's packaging, upgrade to a release whose nginx package is still within its support window. For containerized deployments, pin to a maintained tag and rebuild rather than freezing an image on nginx:1.18.0 forever.
Whatever path you choose, test configuration compatibility in staging first. Directive behavior and defaults have shifted across major nginx versions, so an upgrade is a change to validate, not a drop-in swap.
Keeping This From Recurring
The 1.18.0 situation is a symptom of a general pattern: infrastructure components drift onto unsupported versions because nothing forces the question. Continuous monitoring of the versions you run against advisory data catches an end-of-life component before it becomes an audit finding or an incident. Software composition analysis such as Safeguard's SCA can track the components in your images and flag both the specific CVEs and the end-of-life status. Our broader take on version hygiene lives in the common software vulnerabilities guide.
FAQ
Is nginx 1.18.0 safe to run in production?
Not as a vanilla upstream build. The 1.18 branch is end-of-life and receives no upstream security fixes, so it accumulates unpatched issues over time. A distribution-patched 1.18.0 package may be acceptable within its support window, but the safest posture is to upgrade to a currently maintained branch.
Does CVE-2021-23017 affect me if I don't use the resolver directive?
The vulnerable code path lives in nginx's DNS resolver, which is only active when your configuration includes the resolver directive. If you do not use dynamic DNS resolution, that specific bug is not reachable, though the end-of-life status of the whole branch remains a reason to upgrade.
Why does my scanner flag 1.18.0 when my distro says it's patched?
Many scanners match on the upstream version string, which distributions keep unchanged even after backporting fixes. Confirm against your distribution's changelog or security tracker for your exact package version; tooling that reads full package metadata rather than the version banner gives a more accurate result.
What version should I upgrade to?
Move to a currently maintained nginx stable branch, or to a distribution release whose nginx package is still supported. Avoid pinning permanently to any single old version; instead, adopt a process that keeps you on a branch that still receives security fixes.