Question CVE-2026-23918, CVE-2026-24072 and update to Apache 2.4.67

[iainh]

Server operating system version

AlmaLinux 9.7 (Moss Jungle Cat)

Plesk version and microupdate number

Plesk Obsidian 18.0.77 Update #2

Is there any advice on updating from Apache/2.4.62 (AlmaLinux) to 2.4.67 to mitigate CVE-2026-23918 and CVE-2026-24072?

Would using:

sudo dnf clean all
sudo dnf makecache
sudo dnf -y update httpd

break all manner of things, or will Plesk magically bring along an emergency update to mitigate these CVE and make the issue go away (as is so often the case?)

Thanks for any advice

 

[iainh]

Is there any advice on updating from Apache/2.4.62 (AlmaLinux) to 2.4.67 to mitigate CVE-2026-23918 and CVE-2026-24072?

As a little further info...

CVE-2026-23918 (CVSS score: 8.8) only applies to 2.4.66 and is in http/2 support, so I presume 2.4.62 and not enabling http/2 mean this shouldn't be an issue.

And CVE-2026-24072 (also CVSS score: 8.8) permits local .htaccess authors to read files with the privileges of the httpd user, so it all depends on whether a box has numerous users with the ability to save/update .htaccess files as to whether this is a realistic threat?

 

[flow5]

Hey there,
I'm on Ubuntu where Plesk uses the distribution-provided Apache packages, and Ubuntu applies security fixes via backported patches rather than upgrading to the latest upstream version (e.g. 2.4.67).

Even though the version shows 2.4.58-1ubuntu8.12, the relevant CVEs (e.g. CVE-2026-23918, CVE-2026-24072) are already fixed, which you can verify via:

apt changelog apache2

So there is no need to manually upgrade Apache. Doing so outside the package manager could break Plesk compatibility.

Although I'm not an AlmaLinux user, I asked AI how to test this:
The situation is conceptually similar on AlmaLinux 9 (and other RHEL-based systems) but handled differently to Ubuntu.

AlmaLinux also does not necessarily upgrade Apache to the latest upstream version (e.g. 2.4.67). Instead, it maintains a stable version (e.g. 2.4.57) and applies security patches via backporting, tracked through the RPM changelog.
You can verify this with:

rpm -q --changelog httpd | grep -i cve

or check advisories via:

dnf updateinfo list security | grep httpd

If the relevant CVEs (e.g. CVE-2026-23918, CVE-2026-24072) are listed as fixed, then the system is not vulnerable, even if the version number appears outdated.

I hope this helps.

 

[iainh]

Thanks for this.

I see:

# rpm -q --changelog httpd | grep -i cve
  via AllowOverride FileInfo (CVE-2025-66200)
  override (CVE-2025-65082)
  query string to #exec cmd=... (CVE-2025-58098)
  to avoid unnecessary 421 errors after CVE-2025-23048 fix
  upgrade (CVE-2025-49812)
  clients is possible using TLS 1.3 session resumption (CVE-2025-23048)
  data in mod_ssl (CVE-2024-47252)
- Resolves: RHEL-52724 - Regression introduced by CVE-2024-38474 fix
  (CVE-2023-38709)
  modules (CVE-2024-24795)
  vulnerability (CVE-2023-31122)
#
# dnf updateinfo list security | grep httpd
#

So no joy here. But, I'm not running http/2 and there are no other users on the box, so I think I'm in a reasonable position. But it would be interesting to know what is coming to 'officially' mitigate these two CVE, and yes, ploughing into a manual update brings fears of trowing a very large spanner into the Plesk machine, hence my caution of considering any such move

 

[iainh]

And now we have CVE-2026-43284

 

[Bitpalast]

And now we have CVE-2026-43284

The on-the-fly solution shown in Dirty Frag (CVE-2026-43284, CVE-2026-43500) vulnerability fix is ready for testing is sufficient for it. No reboot required (at least not now). Not linked to the Apache issue discussed in this thread, though.

 

[iainh]

The on-the-fly solution shown in Dirty Frag (CVE-2026-43284, CVE-2026-43500) vulnerability fix is ready for testing is sufficient for it. No reboot required (at least not now). Not linked to the Apache issue discussed in this thread, though.

Many thanks @Bitpalast. I have reviewed that and noted it was a patch form a test repo, but it sounds like you have confidecne in it. Thank you

 

[Bitpalast]

That's partly right. The page still talks about the test repo, but see the solution on disabling the module by creating a .conf file in the description. This will do (unless these modules are not modules, but built into the kernel, which however will be extremely rare for this). So what you want to do is apply the sudo sh -c "printf 'install esp4 /bin/false\ninstall esp6 /bin/false\ninstall rxrpc /bin/false\n' > /etc/modprobe.d/dirtyfrag.conf; rmmod esp4 esp6 rxrpc 2>/dev/null; true" line. This will give enough protection if you don't want to update the kernel yet.

 

[iainh]

That's partly right. The page still talks about the test repo, but see the solution on disabling the module by creating a .conf file in the description. This will do (unless these modules are not modules, but built into the kernel, which however will be extremely rare for this). So what you want to do is apply the
sudo sh -c "printf 'install esp4 /bin/false\ninstall esp6 /bin/false\ninstall rxrpc /bin/false\n' > /etc/modprobe.d/dirtyfrag.conf; rmmod esp4 esp6 rxrpc 2>/dev/null; true" line. This will give enough protection if you don't want to update the kernel yet.

Perfect. Thank you again. I have done this, just not applied the (test) kernal patch.

I see I'm back on kernel-5.14.0-611.54.3.el9_7 (for AlmaLinux 9), so maybe I need to look into doing a more comprehensive update via sudo dnf update

 

[iainh]

Perfect. Thank you again. I have done this, just not applied the (test) kernal patch.

I see I'm back on kernel-5.14.0-611.54.3.el9_7 (for AlmaLinux 9), so maybe I need to look into doing a more comprehensive update via sudo dnf update

dnf update run and looking better now:

# dnf update
Last metadata expiration check: 2:17:08 ago on Fri 08 May 2026 18:17:10 BST.
Dependencies resolved.
Nothing to do.
Complete!

 

[iainh]

Thanks for your help and advice @Bitpalast