If you're scanning old container base images or legacy servers and find nginx 1.20.0 or earlier still running, the nginx 1.20.1 vulnerabilities fix is one worth prioritizing. The headline issue was a resolver off-by-one heap write (tracked as CVE-2021-23017) that could allow an attacker who controls DNS responses to corrupt worker process memory — a real memory-safety bug, not a theoretical one, patched in the 1.20.1 and 1.21.0 releases.
What Was the Actual Vulnerability in Nginx Before 1.20.1?
The resolver bug affected nginx's internal DNS resolver, used when nginx is configured to resolve upstream hostnames dynamically (common in reverse proxy setups pointing at services behind a load balancer or service discovery layer). A specially crafted DNS response could trigger a one-byte memory write past the end of a buffer, corrupting worker process memory in a way that could lead to a crash or, in principle, further exploitation.
The catch is that exploitation requires nginx to be configured to use the resolver directive and for an attacker to be in a position to influence DNS responses reaching the nginx process — either by compromising a DNS server in the resolution path or through a man-in-the-middle position. That's a meaningful precondition, but it's also a realistic one in cloud environments where internal DNS resolution paths aren't always as trusted as they should be.
Are You Actually Affected?
Check whether your nginx configuration uses the resolver directive at all. If nginx is only serving static configuration with hardcoded upstream addresses and never resolving hostnames dynamically, this specific bug isn't reachable, though upgrading is still good hygiene. If you do use dynamic resolution — common in Kubernetes ingress controllers and service mesh sidecars built on nginx — treat this as a priority patch.
Version-pin checks in your SCA tooling or container scanner should flag any image still running nginx/1.20.0 or earlier in the 1.20.x or 1.19.x line. Many popular base images updated quickly after the CVE was disclosed, but custom-built images and older Dockerfiles that pin a specific nginx version can linger unpatched for a long time.
What About Later Nginx CVEs?
Nginx has had additional lower-severity issues since 1.20.1, mostly around specific module configurations (mp4 module, certain HTTP/2 edge cases) rather than the core resolver. The general pattern holds: nginx's core is well-audited and vulnerabilities are relatively rare, but they do happen, and pinned versions in old Dockerfiles are the most common way teams end up running a known-vulnerable build years after a fix shipped.
How Should You Track This Going Forward?
Pinning a specific nginx version in a Dockerfile is common practice for reproducibility, but it creates exactly this kind of drift risk if nobody revisits the pin. A practical pattern is pinning to a minor version with automated dependency update tooling (like Renovate or Dependabot) opening a pull request whenever a patch release ships, so a human reviews and merges the bump rather than the version silently going stale for years.
Container and SCA scanners that check installed package versions against a CVE database will catch this class of issue automatically on every build, which is generally more reliable than manually tracking release notes for every base image in use. If your pipeline doesn't already do this, it's a low-effort, high-value gap to close — see our SCA product page for how continuous dependency scanning fits into that workflow.
FAQ
Is nginx 1.20.1 still supported?
Nginx maintains both mainline and stable branches; 1.20.x was the stable branch at the time of this fix. Check the current nginx.org release page for the actively maintained stable version, since branch numbering has moved on since 1.20.1.
Does this affect nginx used as a static file server only?
Only if the resolver directive is configured. A pure static-content server with no dynamic upstream resolution is not exposed to this specific bug, though staying current is still recommended.
How do I check my running nginx version?
Run nginx -v on the host, or check the Server response header (though many hardened configs strip or obscure this header intentionally).
Should I worry about nginx forks like OpenResty or Tengine?
Check their respective changelogs separately — forks often pull upstream nginx security fixes but on their own release schedule, so version numbers won't match directly.