Question CVE-2026-119618: Apache HTTP Server

[bravuralion]

Server operating system version

Ubuntu

Plesk version and microupdate number

Plesk Obsidian 18.0.81 Update 7

I just found out about this new CVE in Apache HTTP Server.

Is Plesk affected from that? released today... Apache HTTP Server 2.4 vulnerabilities - The Apache HTTP Server Project

 

[Kaspar]

It likely is, however since http2 traffic is handled by Nginx, which sits in front of apache as a proxy by default, the impact might be less severe. This is just my assumption, I have not a done full security analysis on this.

Any way, Apache is installed from the OS vendor repository. Keep an eye out for release notes from the OS vendors for the release of a patch (likely a backport). If you have automatic updates enabled, the patch will installed automatically. You might need to restart Apache manual afterwards for the new version to take effect (not 100% sure on this).

 

[trialotto]

I just found out about this new CVE in Apache HTTP Server.

Is Plesk affected from that? released today... Apache HTTP Server 2.4 vulnerabilities - The Apache HTTP Server Project

Sure, it probably is ......... with a (minor) mitigation if you have Nginx functioning as a proxy ....... and the degree of mitigation is, in addition, depending on the other security measures taken : WAF (at Apache level), Fail2Ban (yes, even that), Imunify360 etc.

This particular CVE is related to a "race condition" that allows for RCE (Remote Code Execution).

As stated on the Apache CVE pages, it concerns "Concurrent Execution using Shared Resource", implying that you are more vulnerable when using PHP-FPM and less vulnerable when you use a dedicated PHP-FPM pool.

Mitigation can be achieved to some extent by switching to dedicated PHP-FPM per domain / subscription - always recommended.

However, a dedicated PHP-FPM pool still allows for (simultaneous) code execution within the pool - it is not server-wide, but restricted to a pool and this can still overload the entire server (hence the word "mitigation", it is only part of the story).

Further mitigation can be achieved by setting pm.max_children lower ... in such a way that it matches the database and memory capacities.

Nevertheless, mitigation of any vulnerability is not a solution..... it simply helps and, more importantly, prevents.

In general, a good WAF (like the paid-for Atomicorp one, called Atomic Advanced in Plesk, and/or the strict variant of OWASP) is the way to go.

These WAFs (or their rulesets, to be more precise) will - mostly - intercept the malicious traffic attempting (simultaneous) code execution, with the advantage that the origin IPs (from which the malicious traffic came from) can be logged and blocked by means of Fail2Ban or the Plesk Firewall extension.

In summary, if you have a decent combination of Nginx (as a proxy) + WAF + Fail2Ban / Firewall + Apache2 + dedicated PHP-FPM, then you can safely wait for the Ubuntu update of Apache packages and, if necessary, switch hosting of specific domains completely off if these domains are causing havoc.

Kind regards.....

PS I think that Ubuntu will not patch this (and other) CVEs quickly in their Apache related packages, so please take some other countermeasures to be sure.

 

[learning_curve]

As per previous posts (relating to this CVE and Ubuntu), Ubuntu Pro Client (pro) can be used to inspect and resolve Common Vulnerabilities and Exposures (CVE) and Ubuntu Security Notices (USN) - See this page for guidance if you're unfamiliar with this.

Example of a very recent CVE that was posted here on this forum

:~# pro fix CVE-2026-98432 --dry-run
WARNING: The option --dry-run is being used.
No packages will be installed when running this command.
CVE-2026-98432: Linux kernel vulnerabilities
 - https://ubuntu.com/security/CVE-2026-98432

1 affected source package is installed: linux
(1/1) linux:
A fix is available in Ubuntu standard updates.
The update is already installed.

✔ CVE-2026-98432 is resolved.
:~#

Then for comparison, the OP's CVE which is so new (at the / time date of this post) that it's not yet been processed:

:~# pro fix CVE-2026-119618 --dry-run
WARNING: The option --dry-run is being used.
No packages will be installed when running this command.
Error: CVE-2026-119618 not found.
:~#

 

[trialotto]

@learning_curve

Excellent addition!

There is the Ubuntu Pro "free" (personal) subscription for 5 machines ............ and it can and will add value in terms of security.

The process of getting the subscription is quite simple :

1 - sign up for the free subscription, preferably with an Ubuntu One account (or by creating one),

2 - run the command : pro attach <token> ......... with <token> being the token found in your Ubuntu Pro dashboard

3 - check the status, run the command : pro status ........ and it should show packages enabled/disabled and the account correctly assigned

4 - check the server security status, run the command : pro security-status ........ and it gives you some additional information



In addition, Ubuntu Pro includes Ubuntu Livepatch - Livepatch patches high and critical Linux kernel vulnerabilities without requiring a system reboot.

Livepatch is enable automatically, with livepatch client installed as a snap package.

Livepatch has or might have a downside : it installs snapd package (otherwise not required) and .... the machine is used for beta testing of kernel updates!

One can disable livepatch with the command : pro disable livepatch

If necessary, livepatch client can be re-enabled with the command : pro enable livepatch

It is - in general - recommended to disable livepatch on a production server .... and test the kernel updates first on a development / test server.

@learning_curve, did you encounter any issues with livepatch? I did not encounter them yet.....

Kind regards....

 

[learning_curve]

~~
@learning_curve, did you encounter any issues with livepatch? I did not encounter them yet.....
~~

With previous Ubuntu releases, yes, we did use Livepatch and, as you have experienced, had no issues or problems. However, from Ubuntu 24.04 LTS onward, we've invoked more and more customization, so we disabled Livepatch, to fall in line with our policy of manual upgrades only, on everything (including Plesk).