Ubuntu: nginx CVE-2026-42533—Patch Older LTS, Fix Regressions

I saw Ubuntu notices dated 5 Nov 2026 adding nginx patches for older LTS releases and fixing HAProxy and FRR regressions, so I have collected the additions here. Anyone who installed the previous patches should follow up, especially with FRR, where the process may still be running but no longer processing subsequent RPKI data.

What this round adds to the previous notices

The earlier details are in nginx security advisories for 2026 and the Ubuntu Server security update roundup for Nov 2026. This round focuses on the additions in the table.

nginx: CVE-2026-42533 patches added for older LTS releases

USN-8955-2 adds patches for older LTS releases, including CVE-2026-42533. This issue involves map using regex and capture variables in certain configurations. nginx classifies it as a buffer overflow of major severity, while Ubuntu states that a remote attacker could crash the service or execute code.

The CVE information from F5 states that code execution requires a system with ASLR disabled or an attacker able to bypass ASLR. Having map in the config alone does not mean the system is affected; check how regex and variables are used as well.

The revisions in the table apply to nginx, nginx-core, nginx-extras, nginx-full and nginx-light; 14.04 also includes nginx-naxsi. Compare them against the packages actually installed. Do not rely solely on nginx -v, because it does not show the full Ubuntu revision. A package may already have backported patches even though its upstream version number remains unchanged.

This USN notice provides no CVSS score or vector and does not mention exploitation in the wild. CVE-2026-42533 is not yet listed in CISA's KEV dated 4 Nov 2026. Absence from KEV does not mean there is no exploitation. I therefore recommend considering affected configurations and exposure to external requests together, then checking whether patches are available to the system.

HAProxy: chunked request fix on 22.04

USN-8972-2 fixes a regression introduced by USN-8972-1 that caused certain chunked requests to be processed incorrectly. This notice covers Ubuntu 22.04 LTS, and the fixed version is 2.4.30-0ubuntu0.22.04.4. If normal application requests started behaving incorrectly after the previous update, check against this revision before rolling back the patches.

CVE-2026-110353 and CVE-2026-110354 on the same page are vulnerabilities from the original notice. Both can cause excessive CPU usage that disrupts the service. This notice does not assign a new CVE to the regression and does not state that any particular log entry or HTTP status must always appear.

After updating, test normal application requests that send a chunked body through the proxy to the backend. There is no need to use malformed requests or exploit test code.

FRR: RPKI must receive data after the first batch

USN-7230-3 states that the CVE-2024-55553 patches in USN-7230-2 caused FRR to stop processing RPKI updates after the first batch. When RPKI data changes, FRR therefore does not revalidate routes. On Ubuntu 20.04, the BGP daemon also fails to start when the RPKI module is enabled. CVE-2024-44070 is a vulnerability from the original notice; this notice does not identify it as the cause of the regression.

Test that FRR can receive the next batch of data and revalidate routes. The commands from the FRR documentation below can show status, but checking the output once is not enough; capture output for comparison when the cache data changes as well.

sudo vtysh -c 'show bgp summary'
sudo vtysh -c 'show rpki cache-connection'
sudo vtysh -c 'show rpki prefix-table'

Capture output before and after the cache data changes, including route status under the existing policy. Do not change ROAs or advertise real routes to test in production.

Update the relevant packages and verify the results

Back up the config and record revisions before starting, then check candidate versions in APT. The USN tables are for comparing Ubuntu packages. If the binary comes from another repository or was compiled locally, check patches with that source.

cat /etc/os-release
dpkg-query -W -f='${Package}\t${Version}\n' nginx haproxy frr frr-rpki-rtrlib
apt-cache policy nginx nginx-core nginx-full nginx-extras nginx-light haproxy frr frr-rpki-rtrlib

Packages that are not installed may produce a message saying they were not found. If using Pro Client, check pro status to confirm entitlement and that the services are enabled. FRR on 20.04 requires ESM Apps. If APT still cannot find a fixed version, check the subscription and repositories. For releases requiring the Legacy Support add-on, check that entitlement too.

1. Prepare for rollback Back up the config and capture service status before making changes
2. Check entitlement and candidates Match the release, package revision and Ubuntu source against the tables
3. Update only what is in use Read the changes and test the config before restarting services
4. Check behavior Test the web service, chunked requests and the next RPKI batch according to the machine's role

Choose commands only for packages that are installed. The nginx example below uses nginx-core. If using nginx-full, nginx-extras, nginx-light or nginx-naxsi, change the package name in the command accordingly. Do not switch flavors merely to match a version number in the table.

sudo apt update
# เลือกเฉพาะกลุ่มแพ็กเกจที่ติดตั้งอยู่
sudo apt install --only-upgrade nginx nginx-core
sudo apt install --only-upgrade haproxy
sudo apt install --only-upgrade frr frr-rpki-rtrlib

APT may restart services during installation, so schedule a maintenance window beforehand, especially for FRR because restarting affects BGP sessions.

After updating nginx, check the config with sudo nginx -t, then run sudo service nginx restart during the planned window. For HAProxy, check with sudo haproxy -c -f /etc/haproxy/haproxy.cfg, using the config and arguments that match the actual service, then run sudo service haproxy restart. A reload alone is not enough to confirm that the process is using the new binary.

Check symptoms and prioritize the work

If using systemd, check both the service and journal as shown in the example. On Ubuntu 14.04, use sudo service nginx status and check the error log specified in the actual config. Do not copy systemd commands to every release.

sudo systemctl status nginx haproxy frr --no-pager
sudo journalctl -u nginx -u haproxy -u frr --since '2026-11-05 00:00:00' --no-pager
dpkg-query -W -f='${Package}\t${Version}\n' nginx haproxy frr frr-rpki-rtrlib

Select the services actually installed, then inspect logs from before and after the update. For nginx, compare worker crashes with request logs. For HAProxy, test the application's chunked requests. For FRR, check both bgpd and the next batch of RPKI data.

None of the three notices provides IOCs for identifying compromised machines. The symptoms above alone cannot confirm an attack, and the absence of errors does not mean the system is safe.

I recommend treating externally exposed nginx instances with affected configurations as urgent work and choosing the earliest feasible maintenance window. For FRR with RPKI enabled or HAProxy experiencing problems after the previous patches, update further and test actual workloads. Even without symptoms, check all revisions. Do not close the task simply because the installation command finished without errors.

Sources: Ubuntu USN-8955-2 (https://ubuntu.com/security/notices/USN-8955-2), Ubuntu USN-8972-2 (https://ubuntu.com/security/notices/USN-8972-2), Ubuntu USN-7230-3 (https://ubuntu.com/security/notices/USN-7230-3), nginx security advisories (https://nginx.org/en/security_advisories.html), Ubuntu Pro Client: ESM (https://ubuntu.com/pro-client/docs/en/latest/howtoguides/enable_esm_infra/), FRR: Displaying RPKI (https://docs.frrouting.org/en/stable-8.4/bgp.html#displaying-rpki)

Ubuntu notice information is current through 5 Nov 2026, and the KEV checked was dated 4 Nov 2026. If the sources add more details, I will return to update this article.