English
Magyar
Deutsch
Slovenščina
On November 11 the Apache HTTP Server developers released version 2.4.71, which fixes a critical security flaw in the web server’s HTTP/2 module (mod_http2). Through the flaw, tracked as CVE-2026-119618, an attacker can run code on the server without logging in, using specially crafted HTTP/2 traffic.
Our servers are already protected: the fixed Apache package (2.4.71-1~urgent) was installed in the early hours of today on all our own servers and on every client server we manage. If your hosting is with us, or we run your server, there is nothing you need to do.
What is the flaw?
HTTP/2 is a newer version of the HTTP protocol that handles several requests in parallel over a single connection, so pages load faster. We explain the difference between HTTP/1.1, HTTP/2 and HTTP/3 in our article about HTTP.
Apache’s HTTP/2 module assembles the headers of every incoming request (the assign_headers() function). In versions 2.4.55 to 2.4.70 this step is not properly synchronized: the module can change a request’s headers while another thread is using them (a race condition). According to Red Hat, a worker thread writes into memory that belongs to the connection thread, through a shared, lock-free memory allocator. The result is heap memory corruption, which can lead to remote code execution.
The key points:
- No login is needed, and no user interaction either: it is enough for the attacker to reach the web server.
- Only servers with HTTP/2 enabled are affected. An Apache that serves HTTP/1.1 only is not vulnerable.
- The code runs with the privileges of the web server process.
- According to Red Hat, public research has already demonstrated a reliable exploit against a default-configured server that uses HTTP/2. So far the sources have not reported actual attacks in the wild.
How serious is it?
Apache rates it critical. The CVSS 3.1 score published by Tenable is 9.8 (critical), vector: AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H. Red Hat gives the same base score but rates its own products only Important rather than Critical: the mod_http2 package of RHEL 9 and 10 serves every HTTP/2 stream from a separate memory allocator, which according to Red Hat makes the flaw much harder to exploit. Harder, but not impossible, so these systems need the update too.
The flaw was reported to the Apache security team from two sources: on October 26 by Anthropic’s scanner for open source software (OSS Scanner), and on November 3 by two researchers of Google Cloud Vulnerability Research, Anthony Weems and Simon Scannell.
Affected versions and fixes
| Software / system | Affected? | Fixing it |
|---|---|---|
| Apache HTTP Server 2.4.55–2.4.70 | Yes | 2.4.71 (November 11, 2026) |
Standalone mod_h2 module 2.0.8–2.0.42 |
Yes | the fix in Apache 2.4.71 |
| RHEL 8 and older, CloudLinux 7 and 8 system Apache | no | – |
| RHEL 9 and 10, and AlmaLinux, Rocky Linux and CloudLinux 9 and 10, which are built on them | Yes | the distribution’s fixed mod_http2 package (AlmaLinux: November 11) |
| cPanel EasyApache 4 (on every CloudLinux version) | Yes | ea-apache24 2.4.71 (in the stable channel since November 11) |
| Ubuntu 22.04 Apache | yes, if HTTP/2 is enabled (it is off by default) | none yet, according to CloudLinux on November 12 |
On the older systems (RHEL 8, CloudLinux 7 and 8) the system’s own Apache is not affected, because it either has no HTTP/2 module or its module predates the faulty code. cPanel servers, however, run the EasyApache 4 Apache rather than the system’s, and that was affected whatever the version of the operating system.
What have we done?
The fixed Apache package (2.4.71-1~urgent) was installed in the early hours of November 12, 2026:
- on all our own servers, that is the cPanel hosting, WordPress hosting and web hosting servers and the servers of our other services,
- on every client server we manage, such as managed VPSs.
What can you do?
If your hosting is with us, or we manage your server
There is nothing you need to do. The flaw was in the web server, not in your website, so the fix has to be installed by whoever runs the server, and we have already done that. Updating WordPress or another CMS does not affect this flaw, but an up-to-date CMS and plugins matter regardless.
If you still see suspicious signs on your site (unknown .php files, unknown administrators, unexpected redirects or foreign content), write to us, and don’t delete anything before we have talked it over.
If you run your own VPS or server
If you manage Apache yourself on your KVM VPS or dedicated server (with us or elsewhere), the update is your job.
1. Check whether the HTTP/2 module is loaded:
# AlmaLinux, Rocky Linux, CloudLinux, RHEL
httpd -M 2>/dev/null | grep -w http2_module
# Debian, Ubuntu
apache2ctl -M 2>/dev/null | grep -w http2_module
If there is no output, the module is not loaded, and the server is not vulnerable to this flaw. If there is, update.
2. Update and restart Apache:
# AlmaLinux, Rocky Linux, CloudLinux 9 and 10 (system Apache)
dnf upgrade --refresh httpd mod_http2
systemctl restart httpd
rpm -q mod_http2
# cPanel / EasyApache 4
dnf upgrade --refresh 'ea-apache24*'
/scripts/restartsrv_httpd
rpm -q ea-apache24 ea-apache24-mod_http2
On a cPanel server, the ea-apache24-mod_http2 package must show version 2.4.71 or newer. The general steps of a system update, including setting up automatic security updates, are in our article about updating with dnf and apt.
3. If there is no fixed package yet, disable HTTP/2 for the time being. The site then keeps working over HTTP/1.1, at most a little slower.
# AlmaLinux, Rocky Linux, CloudLinux 9 and 10:
# comment out the "LoadModule http2_module" line in this file:
# /etc/httpd/conf.modules.d/10-h2.conf
apachectl configtest && systemctl restart httpd
# Debian, Ubuntu
a2dismod http2
systemctl restart apache2
On a cPanel server CloudLinux recommends removing the ea-apache24-mod_http2 package (on Ubuntu with apt-get purge, because the configuration a plain remove leaves behind stops Apache from starting), but as the fixed 2.4.71 is already available, updating is simpler there. Once the fixed package is out, HTTP/2 can be switched back on.
Beware of “urgent update” emails
News like this can bring a wave of phishing emails that refer to a security update. We never ask for your password by email, and we don’t need your help to update our servers.
Timeline
| Date | Event |
|---|---|
| 2026-10-26 | Anthropic’s OSS Scanner reports the flaw to the Apache security team. |
| 2026-11-03 | Anthony Weems and Simon Scannell (Google Cloud Vulnerability Research) also report the flaw. |
| 2026-11-11 | Apache releases the fixed version 2.4.71 and publishes the description of CVE-2026-119618. |
| 2026-11-11 | AlmaLinux releases the fixed mod_http2 packages; CloudLinux’s fixed EasyApache 4 Apache (2.4.71) reaches the stable channel. |
| 2026-11-12, early morning | The fixed Apache package (2.4.71-1~urgent) is installed on our own servers and on the servers we manage. |
Frequently Asked Questions
Does it affect my website? The flaw was in the web server, not in websites, so it could affect any site served by a vulnerable Apache running HTTP/2. On our servers the fix is already installed.
Do I need to update WordPress or the plugins? Not for this flaw. The fix was made in Apache; updating the CMS does not replace it, nor is it needed for it.
Was my site down during the update? No. Apache had to be restarted after the fix, but this caused no noticeable downtime.
Do I need to change my passwords? Without a suspicious sign, it is not necessary. If you want to be on the safe side anyway, we show how to change your cPanel password in a separate article.