Ubuntu reverts CVE-2026-42533 nginx fix again

Ubuntu shipped two nginx notices on August 19, 2026 that are easy to misread if you only scan for “fixed.” First, USN-8563-3 said Ubuntu had a better fix for CVE-2026-42533 after an earlier regression. Later the same day, USN-8563-4 said that update introduced a regression too, and Ubuntu reverted the CVE-2026-42533 fix again while investigation continues.

For teams running nginx from Ubuntu’s standard packages on 22.04 LTS, 24.04 LTS, or 26.04 LTS, this is not a routine “apt upgrade and forget it” notice. The practical job is to confirm which package build is on each host, test the rollback in environments that use third-party nginx modules, and decide whether your nginx configuration actually exercises the vulnerable pattern.

What happened

The affected Ubuntu line is the USN-8563 series. USN-8563-1, published July 20, covered three nginx issues: CVE-2026-42533, CVE-2026-56434, and CVE-2026-60005. The one that matters most for this update is CVE-2026-42533, described as a buffer overflow involving map directives with regex matching and capture variables.

Ubuntu’s first follow-up, USN-8563-2, backed out the CVE-2026-42533 fix because the patch could cause a regression. On August 19, USN-8563-3 said Ubuntu had a better fix for that CVE and listed new package versions for 26.04 LTS, 24.04 LTS, and 22.04 LTS.

Then USN-8563-4 landed later on August 19. That notice says USN-8563-3 introduced a regression in certain environments and that the update reverts the fix for CVE-2026-42533 pending further investigation. The package versions in USN-8563-4 are newer than the USN-8563-3 builds: 1.28.3-2ubuntu1.10 for Ubuntu 26.04 LTS, 1.24.0-2ubuntu7.17 for Ubuntu 24.04 LTS, and 1.18.0-6ubuntu14.20 for Ubuntu 22.04 LTS.

That version movement is the trap. A newer package number does not mean the CVE-2026-42533 mitigation is present. In this case, Ubuntu’s own notice says the newer update reverts that specific fix.

The vulnerable shape

The upstream nginx security advisory lists CVE-2026-42533 as “Buffer overflow when using map and regex,” with severity marked major. Upstream marks nginx Open Source 1.31.3+ and 1.30.4+ as not vulnerable, and versions from 0.9.6 through 1.31.2 as vulnerable.

Ubuntu’s CVE page gives the operationally useful condition: the issue involves a map directive using regex matching where a string expression references the map’s regex capture variables before referencing the map output variable. It also notes an alternative path involving a non-cacheable variable in a string expression under certain conditions. The described impact is a worker-process heap buffer overflow that can lead to restart, with possible code execution when ASLR is disabled or bypassed.

That does not mean every Ubuntu nginx host is equally exposed. A static file server with no relevant map regex use is different from a complex edge proxy full of generated config, third-party modules, and templated variables. But it does mean “we run Ubuntu’s nginx package” is not enough of an answer.

Why this is worth your time

This is the kind of patch cycle that breaks normal dashboards. Your vulnerability scanner may see a newer Ubuntu package and assume progress. Your change-management system may see “security update applied.” Your service owner may see nginx still running and assume the job is done.

The real state is more nuanced: Ubuntu is prioritizing a regression rollback over keeping this particular CVE fix in place, at least temporarily. That may be the correct vendor trade-off for the archive, but it pushes risk assessment back to the operator.

If you use only stock nginx modules and have simple configuration, the regression may never have affected you. If you use nginx-extras, dynamic modules, custom modules, or vendor-supplied modules built against Ubuntu’s nginx ABI, the regression history matters more. Ubuntu’s CVE notes specifically mention that earlier patches changed ABI and could break third-party modules.

What this changes in practice

Start by inventorying package versions, not just CVE status. On affected hosts, run:

apt-cache policy nginx nginx-core nginx-full nginx-extras nginx-light
nginx -V

If you see the USN-8563-4 builds, treat CVE-2026-42533 as reverted by Ubuntu’s current notice. If you see the USN-8563-3 builds, test carefully for the regression that caused the later rollback. If you run upstream nginx rather than Ubuntu packages, compare against upstream’s non-vulnerable versions instead of Ubuntu’s package versioning.

Next, search configuration for the feature shape that matters:

grep -R "map .*~" /etc/nginx /usr/share/nginx 2>/dev/null
grep -R "\$[0-9]" /etc/nginx /usr/share/nginx 2>/dev/null
grep -R "map" /etc/nginx/sites-enabled /etc/nginx/conf.d 2>/dev/null

Those commands are intentionally broad. They do not prove exposure. They give you a shortlist of places where regex map usage and capture variables may deserve review.

Then validate reload and module behavior before broad rollout:

nginx -t
systemctl reload nginx
journalctl -u nginx --since "30 minutes ago"

For production proxies, add a small synthetic test that hits representative hostnames, paths, headers, and upstream routes that depend on map. The bad failure mode here is not just “nginx won’t start.” It is a config path that works in staging until a rarely used variable expansion or third-party module path is exercised.

If you cannot wait for Ubuntu’s next fix and the affected config pattern is present, consider mitigations that reduce reliance on the risky map form. That may mean rewriting a regex map into explicit keys, avoiding capture-variable reuse in string expressions, or moving the logic upstream into application routing where it can be tested with normal unit and integration coverage. I would not rush into source-building nginx on every server unless you already have a controlled packaging path; that often creates a worse maintenance problem.

Watch the next notice, not just the scanner

This story is a reminder that distro security notices are state machines, not single events. USN-8563-3 and USN-8563-4 were both published on August 19, and the second one changes the practical meaning of the first.

For now, I would pin this as a targeted nginx follow-up for Ubuntu LTS fleets. Confirm versions. Review map regex usage. Exercise reloads and module paths. Keep an eye on the next Ubuntu notice for CVE-2026-42533 before closing the ticket as fully remediated.

Sources

• Ubuntu Security Notice USN-8563-4: nginx regression
• Ubuntu Security Notice USN-8563-3: nginx vulnerability
• Ubuntu CVE-2026-42533 tracker
• nginx security advisories
• LWN: Ubuntu alert USN-8563-4
• LWN: Security updates for Thursday
• Vulners: USN-8563-4 nginx regression