Apache fixes unauthenticated code execution flaw in version 2.4.71

If Apache serves your website or API over HTTP/2, your infrastructure team has an urgent task: check the version and install the fix. A flaw in the module that handles this protocol allows an unauthenticated attacker to execute code. For example, the server sitting in front of your application could be at risk: an attacker does not need the admin password.

Apache released the fix on November 11 in version 2.4.71. The vulnerability was assigned CVE-2026-119618 and rated critical. According to the official Apache advisory, versions 2.4.55–2.4.70 are affected. That is a concrete reason to review your server inventory, identify where HTTP/2 is used, and assign someone to handle the update.

What went wrong inside the server

The flaw is in mod_http2, in the assign_headers() function. Multiple threads access shared resources without proper synchronization. As a result, the server can corrupt its own memory, and an attacker can exploit that corruption to execute code.

Imagine two employees editing the same order line at the same time. One changes its contents while the other continues working with the old state. For a web server, this kind of inconsistency is dangerous: it involves the memory of a running process. This is a simplified analogy for the cause of the flaw, not a description of a ready-to-use attack.

A practical example is Apache sitting in front of a subscription service. Even if account access is protected by multifactor authentication, network protocol processing happens before the application authenticates the user. Stronger passwords therefore do not resolve this particular problem. The team needs to patch the component that accepts requests.

What Anthropic and Google contributed

Apache credited Anthropic OSS Scanner, along with Anthony Weems and Simon Scannell of Google Cloud Vulnerability Research, with discovering the vulnerability. Anthropic's report arrived on October 26, and Google's on November 3. These details confirm that Anthropic's scanner helped discover a serious flaw in widely used server software.

But the phrase “AI found a vulnerability” obscures an important detail: the official entry names a specific scanner and specific researchers. It does not establish that both discoveries were fully autonomous or that people are no longer needed to verify results. For security tool developers, the result itself is noteworthy: automated discovery uncovered a thread interaction flaw that could lead to code execution.

The scale needs to be interpreted carefully. According to Wiz, 64% of observed cloud environments contain resources running vulnerable versions, and 51% contain publicly accessible instances. The company explicitly notes that these estimates do not account for configuration. The number of installations therefore does not establish how many servers can actually be attacked over HTTP/2.

At the time Wiz published its report on November 11, there was no public exploit and no reported exploitation. This is a snapshot at a specific date: it neither guarantees that attacks were absent nor describes the situation a week later.

What your team should check

Start with internet-facing servers: identify the Apache version, whether mod_http2 is present, and whether HTTP/2 is actually used. If another proxy sits in front of the application, determine which protocol reaches Apache. The mere presence of an intermediary service does not answer that question.

Next, install the Apache 2.4.71 fix or the appropriate package update from your system vendor. For packages with backported fixes, follow the vendor's advisory: the base version number alone may not indicate whether the patch is present. After updating, check that the server starts, validate the configuration, and test core user workflows.

If the update must be delayed, Wiz suggests temporarily disabling HTTP/2. After making the change, verify that clients can still access the service and that the affected protocol is actually disabled. This is a temporary measure until the fix is installed.

For product managers and founders, the task is practical: give the team time to update and obtain confirmation of which servers have been checked. That outcome is more useful than a general assurance that “security is under control.”