The Apache Software Foundation released a critical security update on May 4, 2026, patching five vulnerabilities in Apache HTTP Server version 2.4.67. The most severe is CVE-2026-23918, a double-free memory corruption vulnerability in the HTTP/2 protocol implementation that enables remote code execution.

The vulnerability is rated High with a CVSS score of 8.8. It affects only version 2.4.66 and was discovered through an internal code review process initiated by Bartlomiej Dmitruk and Stanislaw Strzalkowski, who reported the flaw on December 10, 2025. A patch was committed within 24 hours and shipped in the 2.4.67 release nearly five months later.

Technical overview

• Vulnerability: Double-free memory corruption in HTTP/2 stream reset handling
• CVE: CVE-2026-23918
• Severity: CVSS 8.8 High
• Vulnerability profile: CWE-415 Double Free; CVSS 8.8 High
• Impact: Remote code execution via memory heap corruption and execution flow redirection
• Affected versions: Apache HTTP Server 2.4.66 only
• Fix: Upgrade to 2.4.67; no workaround exists

‍Timeline

• December 10, 2025: Vulnerability reported to Apache Security Team
• December 11, 2025: Fix committed in revision r1930444
• May 4, 2026: Patch shipped in Apache HTTP Server 2.4.67
• May 5, 2026: Public advisory released

Vulnerability mechanism

A double-free vulnerability occurs when a program attempts to release (free) the same memory region twice. The first free() operation marks the memory as available for reallocation. The second free() operation on the same pointer corrupts heap metadata. This corruption can allow an attacker to redirect subsequent memory allocations and potentially achieve arbitrary code execution.

In CVE-2026-23918, the double-free is triggered in Apache's HTTP/2 stream handling code in mod_http2, specifically in the stream cleanup path of h2_mplx.c. The vulnerability is triggered during an "early stream reset" sequence when a client sends an HTTP/2 HEADERS frame immediately followed by RST_STREAM with a non-zero error code on the same stream, before the multiplexer has registered the stream.

The specific trigger involves two nghttp2 callbacks firing in sequence: on_frame_recv_cb for the RST and on_stream_close_cb for the close. Both end up calling h2_mplx_c1_client_rst, which calls m_stream_cleanup. This causes the same h2_stream pointer to be pushed onto the spurge cleanup array twice. When c1_purge_streams later iterates spurge and calls h2_stream_destroy on each entry, the second call operates on memory that has already been freed.

Exploitation path

Denial-of-service is trivial and works on any default deployment with mod_http2 and a multi-threaded MPM. An attacker simply sends the triggering frame sequence to crash the server.

Remote code execution requires additional conditions: the Apache Portable Runtime (APR) must use the mmap allocator, which is the default on Debian-derived systems and on official Apache builds. With the mmap allocator, an attacker can place a fake h2_stream struct at the freed virtual address via mmap reuse, point its pool cleanup function to system(), and use Apache's scoreboard memory as a stable container for the fake structures and command strings. The scoreboard sits at a fixed address for the lifetime of the server, even with ASLR, making this RCE path practical. Proof-of-concept exploitation has been demonstrated in laboratory conditions and completes within minutes.

Triggering conditions

The vulnerability requires:

• HTTP/2 must be enabled (enabled by default in 2.4.66)
• A network client that can send HTTP/2 frames to the server
• No authentication required

MPM prefork is not affected by this vulnerability. The vulnerability requires a multi-threaded MPM (worker, event, or similar).

Scope and affected deployments

CVE-2026-23918 affects only Apache HTTP Server version 2.4.66. Version 2.4.67 patches the vulnerability. All other versions (2.4.65 and earlier, 2.4.67 and later) are not affected.

Deployment prevalence

Apache HTTP Server is deployed across millions of web servers globally, including:

• Public-facing web servers
• Internal API servers
• Load balancers and reverse proxies
• Development and testing environments

However, only servers running specifically version 2.4.66 are vulnerable. Organizations that skipped the 2.4.66 release (either staying on 2.4.65 or upgrading directly to 2.4.67 when it became available) are not affected.

Configuration dependency

The vulnerability requires HTTP/2 to be enabled. HTTP/2 is enabled by default in Apache 2.4.66 if the mod_http2 module is loaded. Deployments with HTTP/2 explicitly disabled via configuration are not vulnerable.

However, organizations cannot assume that HTTP/2 is disabled without verifying their configuration. The default assumption is that HTTP/2 is enabled.

Detection and indicators

Logging

Apache error logs may contain segmentation faults or other fatal signals if exploitation occurs. However, a successful exploitation that achieves code execution may leave no traces in logs before the attacker gains control.

Practical visibility limits

Direct detection of exploitation is unreliable because:

• The attack operates within the HTTP/2 protocol layer
• Successful RCE may not generate any error logs
• The triggering frames can appear similar to normal stream reset behavior

Recommended actions

Immediate actions

• Identify all Apache HTTP Server deployments running version 2.4.66
• Upgrade to Apache HTTP Server 2.4.67 immediately
• Verify the upgrade was successful by checking the version: httpd -v
• Restart Apache services gracefully to apply the patch

Verification of patch application

After upgrading, verify that HTTP/2 stream handling is correct by:

• Confirming the installed version is 2.4.67 or later
• Testing HTTP/2 connections to the server (using curl --http2 https://target or similar)
• Monitoring for any crashes or errors during normal operation

If immediate upgrade is not feasible

As a temporary mitigation, disable HTTP/2 by removing or commenting out the mod_http2 module from the Apache configuration:

# In httpd.conf or mods-enabled/http2.conf

# LoadModule http2_module modules/mod_http2.so

This eliminates the attack surface for CVE-2026-23918 but does not address the other four vulnerabilities patched in 2.4.67. An upgrade should still be prioritized.

Post-upgrade validation

• Monitor Apache error logs for any anomalies
• Verify that client HTTP/2 connections function normally
• Test TLS renegotiation and stream reset scenarios (via automated HTTP/2 test suites)
• Audit server logs for any signs of exploitation attempts prior to patching

Network segmentation

For deployments that cannot be upgraded immediately, restrict network access to HTTP/2-enabled Apache servers:

• Limit inbound connections to known, trusted clients
• Use firewalls to block HTTP/2 traffic if possible
• Monitor for unusual HTTP/2 frame patterns at the network level

Related vulnerabilities in the same release

The 2.4.67 update also patches four additional vulnerabilities:

CVE-2026-24072: mod_rewrite privilege escalation (Moderate)

The mod_rewrite module's use of ap_expr expression evaluation allows local .htaccess authors to read arbitrary files with the privileges of the httpd user. This affects versions 2.4.66 and earlier. Reported January 20, 2026.

CVE-2026-28780: mod_proxy_ajp buffer overflow (Low)

A heap-based buffer overflow in mod_proxy_ajp via ajp_msg_check_header(). If the module connects to a malicious AJP server, the server can send crafted AJP messages causing a 4-byte write beyond a heap buffer. Affects versions 2.4.66 and earlier. Reported independently by four researchers between February and March 2026.

CVE-2026-29168: mod_md resource exhaustion (Low)

An uncapped resource allocation vulnerability in mod_md's OCSP response handler. Attackers can exhaust server resources via oversized OCSP response data. Affects versions 2.4.30 through 2.4.66. Reported March 2, 2026.

CVE-2026-29169: mod_dav_lock NULL pointer dereference (Low)

A NULL pointer dereference in mod_dav_lock that allows attackers to crash the server using a maliciously crafted request. The mod_dav_lock module is not used internally by mod_dav or mod_dav_fs. Its primary use case was with mod_dav_svn from Apache Subversion versions prior to 1.2.0. Mitigation: administrators can remove mod_dav_lock if not in active use.

‍