Apache released version 2.4.71 yesterday, and the reason is CVE-2026-119618, a critical flaw in the HTTP/2 module that allows a remote attacker to run code on the server.

The affected range is 2.4.55 through 2.4.70. Only servers with HTTP/2 enabled are exposed.

An attacker who can reach the server needs no authentication. Red Hat's assessment states that successful exploitation could give full control of the server process. It rates the flaw 9.8 out of 10.

Where the Two Assessments Diverge

This is the part worth reading carefully, because two reputable sources said different things on the same day.

Red Hat's advisory, published yesterday, says "public research has demonstrated a reliable exploit" against a server in its default configuration with mod_http2 enabled. It does not name or link that research.

Wiz said later that same day that no exploit was available, and that no exploitation in the wild had been reported.

Those statements are not necessarily contradictory. A demonstrated exploit in research and a publicly available exploit are different things. But the gap between them matters for anyone deciding how fast to move.

The honest read is that a working exploit exists in some form, has been demonstrated to some audience, and has not been released publicly. Treat that as a window, not a reprieve.

How to Tell If You Are Exposed

HTTP/2 runs only where the Protocols directive turns it on. The module documentation is explicit about this.

• h2 enables HTTP/2 over TLS
• h2c enables HTTP/2 over plain TCP

The directive can be set server-wide or per virtual host. That distinction matters more than it usually does, because a server-wide check can miss a virtual host that enables HTTP/2 on its own.

Check both. Every virtual host, not just the main configuration.

The Patch Status by Platform

The Ubuntu row is the notable gap. Its CVE tracker had no page for the flaw when The Hacker News checked it today.

Why Red Hat Rates It Important, Not Critical

This detail is worth understanding, because it explains why the severity number and the vendor rating do not match.

Red Hat shipped fixes for RHEL 9 and 10 yesterday and rated the flaw Important rather than Critical on those releases. The reason is specific. Their mod_http2 packages give each HTTP/2 stream its own memory allocator, which makes an attack substantially harder.

That is a mitigation baked into the packaging, not into the upstream code. It is also why RHEL operators can move with slightly less urgency than someone running a stock Apache build.

RHEL 8 and earlier do not contain the vulnerable code at all.

The Standalone mod_h2 Problem

The module is also released separately on GitHub as mod_h2, and that project has a problem.

Affected versions run from 2.0.8 through 2.0.42. The release list ends at 2.0.42, which is the last affected version. The repository has been read-only since it was archived on June 9.

There is no fixed release. If you build against standalone mod_h2, the only path is the workaround below.

The Workaround

The Apache HTTP Server advisory offers none. Wiz's vulnerability analysis does.

Remove h2 and h2c from the Protocols directive, leaving only Protocols http/1.1.

That closes the exposure completely, because the vulnerable code path is only reachable through HTTP/2. The cost is that you lose HTTP/2 performance benefits until you can patch.

For standalone mod_h2 servers, the same directive change applies.

Who Found It

The flaw was reported on October 26 by Anthropic's OSS Scanner, a free scanning service for open-source projects that uses the company's AI models. Anthony Weems and Simon Scannell of Google Cloud Vulnerability Research reported it last week.

That is the second data point this month where an AI scanning tool surfaced a critical flaw in widely deployed infrastructure. It is becoming a pattern rather than an anomaly.

The Update Trap

There is a specific trap here worth calling out.

An earlier HTTP/2 flaw, CVE-2026-23918, was fixed in version 2.4.67, released on May 4. If you updated to that release, or to any later one up to 2.4.70, you are patched against the old flaw and still exposed to this one.

The affected range starts at 2.4.55 and runs through 2.4.70. Being on a recent version is not the same as being patched.

What Admins Should Do

• Check your Protocols directive server-wide and in every virtual host. Note whether h2, h2c, or both are enabled.
• Upgrade to 2.4.71 if you run the Apache HTTP Server project's own releases.
• Apply your distribution's package if you run a vendor build. On RHEL 9, that is mod_http2-2.0.26-7.el9_9.1.
• Use the workaround if you cannot patch. Remove h2 and h2c from Protocols, leaving Protocols http/1.1.
• Check standalone mod_h2 builds separately. There is no fixed release, and the repository is archived.
• Verify after patching. Restart the service and confirm the loaded module version. A downloaded package that never restarted the service has not fixed anything.
• Watch for the other fixes in 2.4.71. The release also addresses a crash in mod_md rated important, and a one-byte stack memory overwrite in mod_vhost_alias rated low.

FAQ

What is CVE-2026-119618?

A critical flaw in Apache HTTP Server's mod_http2 module that allows an unauthenticated remote attacker to run code on the server. It is rated 9.8 on the CVSS scale.

Which versions are affected?

Apache HTTP Server 2.4.55 through 2.4.70, and standalone mod_h2 versions 2.0.8 through 2.0.42.

Does this affect servers without HTTP/2 enabled?

No. The vulnerable code path is only reachable when HTTP/2 is turned on through the Protocols directive, using either h2 or h2c.

Which version fixes it?

Apache HTTP Server 2.4.71. Distribution packages vary, so check your vendor's advisory for the specific package version.

Is there a workaround?

Wiz recommends removing h2 and h2c from the Protocols directive, leaving Protocols http/1.1. The Apache advisory itself offers no workaround.

Is a working exploit available?

The sources disagree. Red Hat's advisory states that public research has demonstrated a reliable exploit against a default-configuration server. Wiz said later the same day that no exploit was available and no in-the-wild exploitation had been reported.

Why does Red Hat rate it Important instead of Critical?

Because Red Hat's mod_http2 packages give each HTTP/2 stream its own memory allocator, which makes exploitation substantially harder. That mitigation is in the packaging, not the upstream code.

Is standalone mod_h2 getting a fix?

No fixed release has been published. The repository has been read-only since it was archived on June 9, and the release list ends at 2.0.42, which is the last affected version.

I updated to 2.4.67 earlier this year. Am I safe?

No. That release fixed a different HTTP/2 flaw, CVE-2026-23918. Version 2.4.67 through 2.4.70 are all in the affected range for this one.

Who reported the flaw?

Anthropic's OSS Scanner on October 26, and Anthony Weems and Simon Scannell of Google Cloud Vulnerability Research last week.

My distribution has no fix listed. What do I do?

Apply the Protocols workaround. Remove h2 and h2c, leaving Protocols http/1.1, and monitor your vendor's advisory for the package update.

Source: The Hacker News