Blog Cybersecurity

Apache HTTP/2 Flaw CVE-2026-119618, Update to 2.4.71 Now

Written by Alfina Putri

November 13, 2026 8 min read

Apache HTTP/2 Flaw CVE-2026-119618, Update to 2.4.71 Now

On this page· 7 sections

1How CVE-2026-119618 works in mod_http2
2Affected and fixed versions
3Exploitation status and exposure
4What this means for web server administrators
5Frequently asked questions
6Closing thoughts
7Sources

The Apache Software Foundation fixed Apache HTTP/2 flaw CVE-2026-119618 in Apache HTTP Server 2.4.71, released on November 11, 2026. The critical bug in the mod_http2 module can lead to remote code execution. Versions 2.4.55 through 2.4.70 are affected when HTTP/2 is enabled, and a public proof of concept appeared a day later.

How CVE-2026-119618 works in mod_http2

Apache HTTP Server, often called httpd, is one of the oldest and most widely deployed web servers. Government agencies, universities, online stores, and hosting companies in Indonesia and elsewhere still run it, either directly or behind a hosting control panel.

HTTP/2 is the version of the web protocol that lets a single connection carry many requests at once. Each request travels on its own channel, called a stream. In Apache, the mod_http2 module provides this capability, and it only runs when HTTP/2 is switched on through the Protocols directive in the server configuration.

According to the official Apache HTTP Server 2.4 vulnerability list, CVE-2026-119618 is a synchronization problem in the assign_headers() function of mod_http2. Two parts of the program can use the same shared resource at the same time without proper coordination, a situation known as a race condition. The result can be heap corruption, damage to the memory a program uses while it runs, which opens the door to code execution.

Red Hat gives more detail on its CVE-2026-119618 page. A worker thread writes into memory owned by the connection thread through a shared allocator that has no lock. An attack needs no account and no user interaction, and Red Hat scores the flaw 9.8 out of 10 under CVSS 3.1. Apache rates it critical without publishing a score.

Two teams found the bug independently. Anthropic’s OSS Scanner, a tool that scans open source code, reported it on October 26, 2026. Anthony Weems and Simon Scannell of Google Cloud Vulnerability Research reported it on November 3, 2026. The fix shipped 16 days after the first report.

Affected and fixed versions

Apache says the flaw affects Apache HTTP Server 2.4.55 through 2.4.70. Standalone mod_h2 releases from GitHub, versions 2.0.8 through 2.0.42, are also affected. The fix is in Apache HTTP Server 2.4.71.

The 2.4.71 release closes two more bugs. CVE-2026-106023, rated important, can crash an Apache child process through the mod_md module and affects versions 2.4.30 through 2.4.70. CVE-2026-109163, rated low, sits in mod_vhost_alias in versions 2.4.69 and 2.4.70.

Most servers do not build Apache from source. Linux servers usually run packages from their distribution, and that is where administrators need to look closely. Distributions often add fixes to older releases without raising the main version number, a practice called backporting.

The Ubuntu CVE page shows why this matters. Ubuntu 22.04 LTS ships Apache 2.4.52, which is numerically below 2.4.55. Ubuntu notes, however, that newer mod_http2 code has been backported to its stable releases, so that package is affected too and is fixed in version 2.4.52-1ubuntu4.27. Ubuntu published security notice USN-9090-1 on November 12, 2026.

Table of Apache package versions that include the CVE-2026-119618 fix: Apache 2.4.71, Debian 12 and 13, and Ubuntu 24.04 and 22.04 LTS

On Debian, the Debian security tracker lists the fix in package 2.4.71-1~~deb12u1 for Debian 12 and 2.4.71-1~~deb13u1 for Debian 13. Ubuntu 24.04 LTS gets the fix in version 2.4.58-1ubuntu8.19, while Ubuntu 20.04 receives it only through Ubuntu Pro.

Red Hat says Red Hat Enterprise Linux (RHEL) 8 and earlier are not affected. RHEL 9 and 10 are affected but rated important, because each HTTP/2 stream there gets its own memory allocator, which makes exploitation harder. A Cloud Security Alliance research note dated November 12, 2026 found no fixed packages listed on Red Hat’s CVE page at the time of review, so RHEL users should keep watching that page.

Exploitation status and exposure

As of November 12, 2026, there were no reports of attacks using this flaw. Horizon3.ai notes that a third-party proof of concept (PoC), test code showing the bug can be triggered, was published on November 12, 2026. It reproduces the memory corruption on 2.4.70, comes back clean on 2.4.71, and does not demonstrate code execution.

Red Hat states that public research has demonstrated a reliable exploit against a default-configured server with mod_http2 enabled. Horizon3.ai and the Cloud Security Alliance both point out that Red Hat does not name or link that research, so the claim has not been independently verified.

Timeline of CVE-2026-119618 from Anthropic's report on October 26 and Google's report on November 3 to the Apache 2.4.71 release on November 11 and the public PoC on November 12, 2026

On exposure, BleepingComputer cites telemetry from cloud security company Wiz. According to Wiz, 64% of cloud environments contain vulnerable resources, and roughly half of those have publicly exposed instances. Those figures do not account for configuration, and HTTP/2 is off by default in Apache. Researchers at watchTowr confirmed that condition and advised administrators to “patch now or drop h2 until you can.”

In practice, a server that has never enabled HTTP/2 does not run the vulnerable code. Many administrators, however, turned on HTTP/2 years ago to speed up their sites and no longer remember doing so. Hosting panels and configuration templates can also enable it without anyone noticing.

What this means for web server administrators

The flaw matters most to IT teams at agencies, universities, hosting providers, and online retailers that manage their own servers. Customers on shared hosting usually depend on their provider, but it is still worth asking about the Apache update status on their servers.

Check the package version from your distribution

Run apachectl -v (on the Red Hat family, httpd -v) to see the Apache version. Because of backporting, the version number alone is not enough. On Debian and Ubuntu, compare the apache2 package version with the table above, for example with apt policy apache2, or look for CVE-2026-119618 in the package changelog. Include servers running in containers, since older images stay vulnerable until they are rebuilt.

Confirm whether HTTP/2 is actually on

Run apachectl -M | grep http2 to see whether mod_http2 is loaded. Then review every Protocols directive in the main configuration and in each virtual host, because per-host settings can differ. The Cloud Security Alliance also recommends checking from the outside, for example with curl -sI --http2 https://your-domain -o /dev/null -w '%{http_version}\n'. A result of 2 means the server is speaking HTTP/2.

Install the update and restart Apache

If a fixed package is available for your distribution, install it right away and restart Apache so the new code is loaded. Servers running Apache compiled from source need to move to 2.4.71. Users of the standalone mod_h2 module should move to Apache 2.4.71, since the Cloud Security Alliance could not find a standalone mod_h2 release that includes the fix.

Turn off HTTP/2 temporarily if the update is delayed

According to the Cloud Security Alliance, Apache has not published an official workaround. As a stopgap, the CSA suggests setting Protocols to http/1.1 only, removing h2 and h2c, or unloading mod_http2 until the update is in place. First make sure nothing depends on HTTP/2, such as gRPC back ends proxied through Apache. If the site sits behind a CDN or load balancer, visitors can keep using HTTP/2 up to the CDN while the connection to the Apache origin uses HTTP/1.1.

Four steps to close the Apache HTTP/2 flaw: check the version, find HTTP/2, update, and set Protocols to http/1.1 if the update is delayed

The pattern is similar to the PHP flaws we covered in our piece on PHP2Shell and safe PHP versions: the version number on screen is not always the code that actually serves visitors. Agencies cleaning up older servers can also refer to our steps following Komdigi’s cyber alert. For organizations that want to organize their server inventory, update schedule, and configuration monitoring, Merakit’s cybersecurity services can help set up the process.

Frequently asked questions

Is my server safe if HTTP/2 is off?

According to Red Hat and Horizon3.ai, the vulnerable code only runs when mod_http2 is loaded and HTTP/2 is enabled through the Protocols directive. A server that serves only HTTP/1.1 does not reach that code path. Updating is still recommended, since 2.4.71 also fixes two other bugs.

My Ubuntu server runs Apache 2.4.52. Why is it affected?

Ubuntu backported newer mod_http2 code into its stable releases. As a result, Ubuntu 22.04 LTS with Apache 2.4.52 is affected and is fixed in package 2.4.52-1ubuntu4.27. The reference point is the distribution’s package version, and the Apache version number by itself can mislead.

Has the flaw been used in attacks?

As of November 12, 2026, there were no reports of exploitation in the wild. A public PoC is available and triggers memory corruption, but it does not show code execution. That can change quickly, so the update should not wait.

Closing thoughts

CVE-2026-119618 can be closed with package updates that are already available on most major distributions. The harder part is verification: making sure every server, virtual host, and container that serves HTTP/2 is on the right package. If your team is tidying up this kind of process or rebuilding web applications on a cleaner configuration, Merakit’s web development team is ready to talk.