CVE-2026-119618: Critical RCE in Apache HTTP Server

On 11 November 2026, the Apache Software Foundation released a security update addressing CVE-2026-119618, a critical vulnerability in Apache HTTP Server's mod_http2 module. The flaw can cause heap memory corruption and potentially lead to remote code execution (RCE) without authentication. According to Apache's advisory, versions 2.4.55 through 2.4.70 are affected, and the issue is fixed in Apache HTTP Server 2.4.71.

What makes this vulnerability particularly significant is where it originates. It is not caused by an insecure web application, an exposed administrative interface, or a conventional authentication bypass. Instead, the weakness lies inside the HTTP/2 request-processing machinery, where concurrent operations can modify memory belonging to a different execution context. The defect illustrates how a seemingly ordinary operation on HTTP headers can become a serious security problem when shared data structures and thread synchronization are handled incorrectly.

Apache's official patch changes just one line of code, replacing a modification to a shared header table with an operation on the copy owned by the request currently being processed. Understanding why that small change matters requires looking at HTTP/2 multiplexing, the relationship between connection threads and worker threads, and Apache's memory-allocation model. It also requires distinguishing the general upstream advisory from the behavior of distribution-specific builds, which may include different memory-allocation characteristics or security backports.

What is CVE-2026-119618, and why is it critical?

CVE-2026-119618 is classified under CWE-362, Concurrent Execution using Shared Resource with Improper Synchronization. The vulnerable operation occurs in assign_headers(), a function implemented in modules/http2/h2_request.c. A race condition arises when multiple execution paths access shared resources without sufficient synchronization to ensure that operations take place safely. Under the wrong circumstances, the behavior of one thread can interfere with the assumptions made by another thread, potentially leaving internal state inconsistent.

In this case, a worker processing an HTTP/2 request can modify a header table associated with the original HTTP/2 request rather than the separate table prepared for the worker's own request context. That distinction matters because the original table and its underlying allocation resources may be associated with the connection-processing context. Concurrent modifications can therefore affect shared, insufficiently synchronized memory structures and potentially corrupt the heap.

The Apache Software Foundation labels the vulnerability critical and explicitly states that it can lead to RCE. Red Hat assigns a general CVSS v3.1 score of 9.8 and reports that reliable exploitation has been demonstrated against a default-configured server with the vulnerable module enabled. These assessments justify urgent attention, although the practical exploitability of a particular deployment can depend on its HTTP/2 configuration, memory allocator behavior, package build, and network exposure.

How HTTP/2 works and the role of mod_http2

HTTP/2 introduced request and response multiplexing over a single connection, allowing multiple communication streams to progress concurrently without requiring a separate TCP connection for every resource. This improves network efficiency and reduces some limitations of traditional HTTP/1.1 usage, but it also means that a web server must maintain both connection-wide state and information specific to each active stream.

In Apache HTTP Server, mod_http2 is responsible for implementing the protocol, handling its frames, coordinating streams, and integrating HTTP/2 traffic with Apache's request-processing infrastructure. That integration is more complicated than simply accepting a different network protocol, because individual streams may be processed by workers while other parts of the system continue managing the underlying connection.

The complication arises when these activities take place in separate threads. Some objects belong to the connection context, whereas others belong to an individual request that has been handed to a worker. Headers, status information, and allocation resources must not be treated as interchangeable merely because they contain similar data. Every component needs clearly defined ownership rules, and modifications to shared objects must respect the synchronization guarantees of the context in which those objects were created.

For that reason, making a local copy of request headers can serve as more than a convenient implementation detail. It establishes a boundary between data maintained by the connection and data that a worker may safely modify while processing its own request. CVE-2026-119618 demonstrates what can happen when code crosses that boundary even though a suitable copy has already been created.

The flaw in assign_headers(): modifying the wrong header table

The assign_headers() function prepares the headers that Apache uses for an internal request. Two of the relevant objects are h2_request, which represents information maintained within the HTTP/2 subsystem, and request_rec, which is used by the conventional Apache request-processing pipeline. During this preparation, the code clones the original header table using apr_table_clone(), producing a copy associated with the internal request's memory context.

The intended behavior is straightforward: subsequent header adjustments should be performed on the copied table, rather than on the original structure that remains associated with the HTTP/2 connection. The vulnerable path concerns a specific situation in which Apache needs to set the content length to zero when the stream has ended without a request body and certain header conditions are met. This adjustment is legitimate from the standpoint of HTTP message processing, but its destination was incorrect.

Before the patch, the operation updated req->headers, the original HTTP/2 request's header table, instead of r->headers_in, the header table belonging to the internal request. As a result, the worker could perform a write into data owned by a different context. The vulnerability does not require a client to inject executable instructions directly into a header; the risk emerges because routine parsing and normalization can trigger a memory modification that violates the intended ownership and synchronization model.

Understanding the official patch: one line with major consequences

Apache fixed the problem in commit 824beab9b9424d6cfb29595248fdbf6c3dddeab1, modifying modules/http2/h2_request.c. The change replaces an apr_table_setn() operation targeting req->headers with the equivalent operation targeting r->headers_in. The purpose of the operation remains the same: record a Content-Length value of zero in the particular request-processing case. What changes is the object being modified.

That distinction is the essence of the fix. Rather than altering the table retained by the HTTP/2 request context, Apache now updates the copied headers used by the worker. This preserves the separation between connection-owned state and request-owned state, removing the unsafe write from the vulnerable execution path.

It is tempting to assume that a one-line patch corresponds to a simple vulnerability, but the size of a correction says little about the difficulty of finding the underlying flaw. Both structures contain header data, both references are valid C expressions, and the operation may appear harmless when viewed in isolation. Identifying the security consequences requires understanding the relationship between request lifetimes, thread ownership, memory pools, and concurrent execution in a mature web server.

From a race condition to heap corruption

Apache relies on the Apache Portable Runtime, or APR, for reusable infrastructure such as memory management and data structures. APR memory pools group allocations according to the lifecycle of an object or execution context, which can simplify cleanup and reduce overhead. However, a memory pool or allocator that is appropriate for one thread's operations is not necessarily safe for concurrent modifications from another thread without additional synchronization.

When an operation modifies a shared table through the wrong execution context, the allocator's internal assumptions can be violated. Under particular interleavings of concurrent operations, one thread may alter memory-management state while another thread is using related structures, leaving the heap inconsistent. The exact outcome depends on timing, allocator design, process state, and the affected build.

Heap corruption does not have a single predictable manifestation. It can produce intermittent crashes, invalid memory accesses, or unexpected changes to internal program state. In more serious cases, an attacker who can influence the conditions sufficiently may be able to turn memory corruption into control over the server process's execution flow.

This does not mean that any individual HTTP/2 request automatically results in arbitrary code execution. Race conditions are often sensitive to workload and scheduling, and a successful exploit may depend on details of the runtime environment. Nevertheless, the upstream advisory explicitly recognizes the possibility of RCE, while Red Hat states that a reliable exploit has been demonstrated against a default-configured system with mod_http2 enabled.

Affected Apache versions and configurations

Apache's advisory identifies HTTP Server 2.4.55 through 2.4.70 as affected. It also includes independently distributed mod_h2 releases 2.0.8 through 2.0.42. Apache HTTP Server 2.4.71, released on 11 November 2026, contains the upstream fix. These ranges are useful for an initial inventory, but determining exposure requires more than checking whether a version string falls within them.

The vulnerable processing path concerns servers that actually use the affected HTTP/2 module. Apache may negotiate h2 over TLS or h2c without TLS, depending on its Protocols settings. A deployment configured to serve only HTTP/1.1 is not exposed to this particular HTTP/2 processing flaw, even if its Apache version appears in the upstream affected range.

Virtual hosts and the network path also matter. One domain may support HTTP/2 while another virtual host on the same installation does not. In a reverse-proxy architecture, a client might use HTTP/2 to communicate with a CDN or load balancer while the proxy communicates with Apache over HTTP/1.1. Conversely, internal services or alternate access paths may still use HTTP/2 to reach the origin.

Consequently, observing HTTP/2 in a browser does not prove that the origin's mod_http2 module is handling those requests, and deploying a reverse proxy does not automatically eliminate the risk. Administrators need to establish which component terminates each HTTP/2 connection and whether any reachable route still exposes the affected code.

Why the level of risk varies across Linux distributions

An upstream software version and a distribution's security status are not always the same thing. Linux vendors may apply a security patch to an older release through a backport, retaining a version number that appears vulnerable when compared mechanically against the upstream advisory. This is why vulnerability management should not rely solely on the version shown in a service banner or a simple string comparison.

A reliable assessment must consider the installed package revision, the distribution's advisory, the relevant build configuration, and any locally maintained modules. Custom containers and third-party appliances deserve particular attention because the actual server components running inside them may differ from those installed on the host operating system.

Red Hat documents an important implementation detail for this CVE. Its mod_http2 packages for Red Hat Enterprise Linux 9 and 10 use separate allocators for HTTP/2 streams, substantially increasing the difficulty of exploiting the race condition described in the general advisory. Red Hat therefore rates some of these product-specific packages as Important, even though the overarching vulnerability is classified as critical.

Red Hat also states that RHEL 8 and earlier are not affected because the vulnerable code is absent. These differences should inform prioritization rather than become an excuse to defer security updates indefinitely. The relevant question is whether the actual deployed implementation contains the flaw and whether an official correction has been applied.

Potential impact: what could an attacker achieve?

The most serious outcome acknowledged by Apache is remote code execution within the web server process. In practical terms, successful exploitation could allow an unauthenticated attacker to execute instructions with the privileges available to that process. Depending on the deployment, those privileges may provide access to served content, configuration files, application integrations, internal network services, or sensitive data used by the applications running alongside the server.

As a result, the incident should not be viewed purely as a fault affecting an HTTP listener. A compromised front-end process may become a foothold for reaching other systems that trust it, especially in poorly segmented environments or where application credentials are unnecessarily exposed to the web server's execution context.

The ultimate scope depends on the service account, operating-system isolation, container restrictions, network controls, and accessible secrets. Code execution as the web server user does not automatically confer administrator or root privileges, but permissive access controls and weak segregation can greatly amplify the damage. Availability is another concern: even when the attacker cannot achieve controlled execution, heap corruption may cause worker processes to crash or services to become unstable.

Severity, CVSS score, and evidence of exploitation

The Apache Software Foundation describes CVE-2026-119618 as critical. Red Hat publishes a general CVSS v3.1 base score of 9.8, with the vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H. This corresponds to a network-reachable attack requiring no prior privileges or user interaction, with potentially high impact on confidentiality, integrity, and availability.

The attribution of that score matters: Apache supplies the critical severity classification, whereas the numeric CVSS assessment comes from Red Hat and other vendors. Specific builds may receive different product-level severity ratings because their implementation details affect exploitability.

As of 12 November 2026, Red Hat states that reliable exploitation has been demonstrated against a default-configured server with the module enabled. However, the official advisories reviewed do not establish that a widespread active exploitation campaign has been confirmed, nor do they verify the availability of a universal public exploit tool. Those are distinct questions: a vulnerability may support RCE, researchers may demonstrate an exploit, and attacks may later be observed in real-world environments, but one fact does not automatically prove the others.

The absence of confirmed widespread attacks should not delay patching. HTTP server modules are often reachable from untrusted networks, and the publication of a precise patch provides useful information to both defenders and vulnerability researchers. Exposure and business impact should guide the response, without waiting for an attacker campaign to become publicly documented.

How to identify servers that require attention

The investigation should begin with an inventory of every service that incorporates Apache HTTP Server, including traditional servers, virtual machines, container images, appliances, and embedded or bundled components. Administrators should establish the actual httpd version and package revision, verify whether mod_http2 is loaded, and review the effective Protocols settings globally and for each virtual host.

These checks are only the beginning. A complete assessment must account for the topology between clients, CDNs, reverse proxies, load balancers, and origin servers, because HTTP/2 may be terminated at one point and re-established elsewhere. It is also necessary to compare the installed packages against the security advisories issued by the relevant vendor, particularly where patches may have been backported without changing the upstream version number.

Container-based deployments deserve an additional review: updating the host operating system does not automatically replace vulnerable Apache binaries packaged inside application images. Security teams should therefore evaluate image provenance, build pipelines, deployment inventories, and any environments that may continue running older artifacts after the main production service has been updated.

Finally, administrators should record their findings in the asset inventory and validate the post-update state. A banner alone cannot prove that a system remains vulnerable, and the presence of an apparently corrected version does not by itself guarantee that every running worker has loaded the patched code.

Recommended updates and temporary mitigations

The preferred remediation is to upgrade to Apache HTTP Server 2.4.71 or install an equivalent vendor-maintained package that includes the fix. The change should follow normal production procedures, including configuration backups, compatibility checks, controlled deployment, and verification that all relevant processes are using the updated module. Organizations also need to consider secondary installations, container base images, and services that fall outside their standard patch-management cycle.

When an immediate update is not possible, temporarily disabling HTTP/2 and allowing only HTTP/1.1 can reduce exposure to this specific vulnerable path, provided that the change is effective across every relevant entry point. This requires assessing both h2 and h2c and understanding the scope of Protocols settings at the server and virtual-host levels.

Such a change is a short-term mitigation, not a substitute for installing the correction. Protocol changes can affect performance and compatibility, so they should be validated against application requirements before production rollout. Least-privilege service accounts, network segmentation, restrictive access to secrets, and effective monitoring can further limit the consequences of a compromise, but none of those controls fixes the underlying synchronization defect.

Other vulnerabilities addressed in Apache HTTP Server 2.4.71

Apache HTTP Server 2.4.71 also includes security fixes for CVE-2026-106023 and CVE-2026-109163. The former is an important-severity null-pointer dereference in mod_md that can crash a child process while handling an HTTP request. The latter is a lower-severity one-byte stack overwrite in mod_vhost_alias, associated with an earlier correction.

Although these findings do not share the same severity assessment as CVE-2026-119618, their inclusion in the same release illustrates why web server maintenance should be driven by a consistent vulnerability-management process rather than a reaction to individual headlines. Tracking upstream changes, vendor advisories, dependency versions, and actual deployment status is essential for keeping widely exposed infrastructure secure.

Discovery and coordinated disclosure timeline

According to Apache's published timeline, Anthropic's OSS Scanner reported the issue to the project's security team on 26 October 2026, using the identifier ANT-2026-MAPKT6MZ. On 3 November 2026, Anthony Weems and Simon Scannell of Google Cloud Vulnerability Research independently reported the same vulnerability. Apache incorporated the fix into its 2.4 maintenance branch and released version 2.4.71 on 11 November 2026, when the public security advisory was also issued.

These independent discoveries underline the difficulty of identifying concurrency flaws in mature, heavily deployed software. They also demonstrate the value of combining automated analysis, source-code review, and focused security research. Coordinated disclosure gave maintainers an opportunity to address the defect before public release, while the published patch now enables defenders to verify whether their own packages and builds contain the relevant change.

From a secure-engineering perspective, the broader lesson is clear: memory-safety analysis is not limited to buffer boundaries and invalid pointers. Software that operates across multiple threads must also ensure that the correct thread modifies the correct object, and that every shared resource is used with the synchronization guarantees its implementation requires.

Conclusion

CVE-2026-119618 shows how a small mistake in HTTP header processing can produce a critical vulnerability when it violates memory ownership and synchronization rules. The flaw affects mod_http2 in Apache HTTP Server 2.4.55–2.4.70 and can lead to heap corruption with the potential for unauthenticated remote code execution. Apache's correction in 2.4.71 changes a write to the original header table into a write to the copy belonging to the request being processed.

For infrastructure and security teams, the immediate priorities are to identify deployments that actually accept HTTP/2 through the vulnerable module, check distribution-specific security advisories, and apply the appropriate fixed packages. Where patching must be delayed, carefully disabling HTTP/2 may provide temporary risk reduction, but only after verifying the full network path and all relevant virtual-host configurations.

Beyond the immediate update, this vulnerability is a reminder that even well-established infrastructure software can contain serious defects at the boundaries between connection state, request state, and worker execution. In concurrent systems, respecting those boundaries is not merely a design preference; it is a fundamental requirement for reliability and security.

Official references and technical documentation

• Apache Software Foundation: official CVE-2026-119618 advisory.
• Apache HTTP Server: commit fixing assign_headers().
• Red Hat: impact analysis, CVSS assessment, and distribution-specific considerations.
• oss-security: Apache's public security announcement.
• CVE Program: CVE-2026-119618 record.
• Apache: mod_http2 module documentation.