Safeguard
Security

nginx 1.22.1 Vulnerabilities: What Actually Affects You

Worried about nginx 1.22.1 vulnerabilities? Here is what genuinely affects this release, what does not, and how to decide whether you need to upgrade.

Marcus Chen
DevSecOps Engineer
5 min read

The main confirmed vulnerability that affects nginx 1.22.1 is CVE-2024-7347, a buffer overread in the ngx_http_mp4_module, and it only matters if you have that module enabled and serve mp4 files, so most nginx 1.22.1 vulnerabilities scanners flag are either not applicable or fixed in this release. If a scanner is throwing a wall of CVEs at your nginx/1.22.1 deployment, the useful work is separating the ones that touch your configuration from the historical noise. This post does that.

Version 1.22.1 was released on 19 October 2022 as a stable-branch update. It shipped as a hardening release, which is part of why the picture is less alarming than a raw CVE list suggests.

What nginx 1.22.1 already fixed

Understanding what this version fixed explains why many CVE lookups return "not affected." The 1.22.1 stable release backported security fixes, so a scanner keyed only on "is the version old" will report issues that this build does not actually carry.

In particular, nginx 1.22.1 is not affected by the HTTP/2 issues from the 1.17.x era or by CVE-2021-23017, the one-byte resolver overwrite, both of which were addressed in earlier releases. Treating 1.22.1 as if it were an ancient unpatched build overstates the risk. The version is old by calendar, not unmaintained-old.

The one that actually affects 1.22.1: CVE-2024-7347

The vulnerability you should care about is CVE-2024-7347. It is a buffer overread in ngx_http_mp4_module. A specially crafted mp4 file, processed by the module, can cause a worker process to overread memory and crash, or potentially disclose worker process memory.

The affected range is nginx 1.5.13 through 1.27.0, which includes 1.22.1. It was fixed in 1.27.1 on the mainline and backported to 1.26.2 on the stable branch.

The critical qualifier is exposure. This module is not compiled into every build, and even when present it only processes files you serve through it. If your nginx/1.22.1 instance is a reverse proxy or serves only HTML, CSS, and JavaScript, ngx_http_mp4_module is likely not in the request path at all, and CVE-2024-7347 does not apply to how you run it.

Check whether the mp4 module is even in play

Do not guess. Confirm whether your build includes the module and whether your config uses it.

# Is the mp4 module compiled in?
nginx -V 2>&1 | tr ' ' '\n' | grep -i mp4

# Is the mp4 directive actually used anywhere in your config?
grep -rin "mp4" /etc/nginx/

If nginx -V shows no mp4 module, or if grep finds no mp4; directive inside a location block that serves attacker-reachable files, then CVE-2024-7347 is not exploitable in your deployment. That turns a "critical" scanner finding into an informational one you can document and move past.

If you do serve mp4 through the module, treat it as actionable and plan an upgrade to a fixed release.

Reading scanner output without panic

Container and dependency scanners often report against the version string alone. A report titled "nginx 1.22.1 vulnerabilities" can list a dozen CVEs, and the honest triage is that most fall into one of three buckets: already fixed in 1.22.1, not applicable because the relevant module or feature is disabled, or genuinely applicable and worth patching.

The one you must not dismiss by reflex is CVE-2024-7347, and only after you have confirmed the mp4 module is not exposed. Everything else deserves the same two-question test: does my build include the affected code, and does my config route attacker-controlled input to it. If the answer to either is no, the finding is not a real risk for you, though you should still record why you closed it.

This is also where dependency-scanning tooling earns its place. An SCA tool such as Safeguard can tie a CVE to the actual component and version in your image rather than a loose version-string match, which cuts down the false positives that make CVE triage exhausting.

Should you upgrade off 1.22.1?

Yes, on principle, even setting the mp4 issue aside. The 1.22.x branch is superseded, and staying on a superseded stable branch means you stop receiving new backported fixes. The practical path is to move to a current stable release such as the 1.26.x line, where CVE-2024-7347 is fixed in 1.26.2 and later, or to the current mainline.

If an immediate upgrade is not possible, the interim mitigation is to disable the mp4 module or ensure no location serves mp4 files through it, which removes the one confirmed exposure while you schedule the version bump. Our security academy covers how to build a repeatable patching cadence so you are not doing this analysis reactively every quarter.

FAQ

Is nginx 1.22.1 vulnerable?

It is affected by CVE-2024-7347, a buffer overread in the ngx_http_mp4_module, but only if that module is enabled and serving mp4 files. Many other CVEs reported against the version string were already fixed in 1.22.1 or do not apply to typical configurations.

What is CVE-2024-7347 in nginx?

It is a buffer overread in ngx_http_mp4_module triggered by a crafted mp4 file, which can crash a worker or disclose worker memory. It affects nginx 1.5.13 through 1.27.0 and was fixed in 1.27.1 and backported to 1.26.2.

Do I need to patch nginx 1.22.1 if I do not serve mp4 files?

CVE-2024-7347 specifically requires the mp4 module to be enabled and serving files, so if it is not in your build or config, that issue is not exploitable for you. You should still plan to move off the superseded 1.22.x branch to keep receiving fixes.

How do I check which nginx CVEs affect my build?

Run nginx -V to see which modules are compiled in, grep your config for the relevant directives, and match findings against the official nginx security advisories. Confirm both that the affected code is present and that your config routes untrusted input to it before treating a CVE as applicable.

Never miss an update

Weekly insights on software supply chain security, delivered to your inbox.