Apache HTTP/2 CVE-2026-23918: a double-free in the protocol everyone runs. The patch order, detection, and why CVSS 8.8 understates the risk.

# Apache HTTP/2 CVE-2026-23918: a double-free in the protocol everyone runs. The patch order, the detection, and why this one matters more than the score suggests.

Apache pushed an HTTP Server security release yesterday (May 5, 2026) that patches CVE-2026-23918, a double-free vulnerability in the HTTP/2 protocol handler that the Apache Software Foundation describes as "double free and possible RCE." CVSS 8.8. The Hacker News covered it; most of the rest of the security press is going to follow this week. This is the bug everyone wants to dismiss because the CVSS isn't a 9.x and the description hedges with "possible RCE." Don't. The Apache HTTP Server runs on something between 22% and 31% of all internet-reachable web servers depending on which census you trust, and HTTP/2 has been the default negotiation since Apache 2.4.17. The exposure surface is the entire web.

Most of the public conversation is treating this as "the Apache people are being conservative with the wording, RCE is probably possible but unproven." That is a generous reading of "double free and possible RCE" when the reporters haven't yet published a working exploit. The honest reading is: the bug class is reliable RCE in the right hands; the question is whether public exploitation arrives in days, weeks, or months. The patch is out. Run it.

I wrote this for sysadmins and DevOps engineers who run a fleet of Apache HTTP Server boxes — from the 3-VM hobby cluster to the 30,000-host commercial CDN. The detection commands and patch order below are what I'd hand to a junior on my team if I had to spin them up tonight.

#What CVE-2026-23918 actually is (in plain terms)

The Apache HTTP Server's HTTP/2 module, mod_http2, is responsible for parsing HTTP/2 frames as they arrive over a single TLS connection. HTTP/2 multiplexes many logical streams over one TCP connection; each stream has its own state machine and its own buffers. When a stream is reset or closed mid-flight, the buffers associated with that stream get freed.

The bug is in the path that handles a stream-reset arriving while the stream's body buffer is still being processed by another concurrent thread. Under specific timing, the buffer is freed once by the reset path, then again by the body-processing path when it tries to clean up the now-already-freed structure. Two free() calls on the same heap chunk. Classic double-free.

In modern glibc and on most modern Apache deployments, the heap allocator detects the second free and aborts the process — this is the "DoS" half of the vulnerability description. But under specific allocator state (specifically, when the freed chunk has been reused for an attacker-controlled allocation between the two free() calls), the second free corrupts the heap freelist in a way that can be exploited for arbitrary write primitives. From an arbitrary write to RCE is a few-hour walk for someone with the bug.

The trigger conditions:

• HTTP/2 enabled (default on Apache 2.4.17+).
• An attacker who can open a TLS connection to the server. Authentication is not required — the bug is in the HTTP/2 parser, before any application-level auth.
• The ability to send a specific sequence of HTTP/2 frames (HEADERS, then partial DATA, then RST_STREAM, then more DATA on a different stream that triggers heap reuse).
• A multi-threaded MPM (worker, event) — the prefork MPM is harder to hit because the work is single-threaded per process, but is not immune.

If your Apache config has Protocols h2 h2c http/1.1 or Protocols h2 http/1.1 (the modern default), you are exposed. If you've explicitly disabled HTTP/2 with Protocols http/1.1, you are not exposed to this specific bug — but you should still patch because the fix bundle includes other less-severe fixes too.

#Versions affected and the patch matrix

Apache's advisory:

• Apache HTTP Server 2.4.49 through 2.4.65 are affected.
• Patched in 2.4.66. Released May 5, 2026.
• Apache 2.2.x is end-of-life and is not receiving a backport. Migrate to 2.4.66.
• Apache mod_http2 shipped externally (e.g., in mod_h2 packages on older RHEL/CentOS 7) is also affected; see your distro's security tracker.

Distro-side patches at time of writing:

• Debian 12 (Bookworm): apache2 2.4.62-1~deb12u3 includes the backport. Released 2026-05-05.
• Ubuntu 22.04 LTS: apache2 2.4.52-1ubuntu4.10 available 2026-05-06.
• Ubuntu 24.04 LTS: apache2 2.4.59-2ubuntu1.5 available 2026-05-06.
• RHEL 9 / Rocky / Alma: httpd-2.4.62-2.el9_5.1 released via EUS channels.
• RHEL 8 / Rocky / Alma: httpd-2.4.37-65.el8_10.1 released.
• Amazon Linux 2023: patched via dnf update httpd. The advisory ID is ALAS2023-2026-952.
• Debian 11 (Bullseye, LTS): patch lagging at time of writing; check the security tracker.

Cloud-managed services (AWS Elastic Beanstalk, Azure App Service for Linux, Google App Engine flex with custom Apache, all the various managed-WordPress hosts) need to coordinate with the provider. AWS Elastic Beanstalk specifically rolled their patched AMIs the morning of May 6.

#Detection commands — find your exposed Apache fleet first

The real challenge for a typical organization is not "patch one Apache box" but "find every Apache box you forgot you had." Embedded admin interfaces, dev environments, that one old VM, container images that haven't been rebuilt in a year, the staging server somebody spun up two CTOs ago. The patch is easy; the inventory is hard.

Find every Apache box on your network with HTTP/2 advertised:

# Targets a /16 - adjust to your scope
nmap -p 80,443,8000,8080,8443 --open --script http-headers \
     -oG apache-fleet.gnmap 10.0.0.0/16

# Filter for Apache servers advertising HTTP/2
grep -E 'Server: (Apache|httpd)' apache-fleet.gnmap | \
    awk -F'[/:]' '{print $1}'

Check h2 advertisement on each:

curl -sI --http2 https://<host>/ | grep -iE '^(server|alt-svc):'

If alt-svc: h2=... is present or you see the HTTP/2 negotiation succeed, the host is exposed.

Identify your installed Apache version on each box:

httpd -v          # RHEL/CentOS/Fedora
apache2 -v        # Debian/Ubuntu

If the output shows < 2.4.66 (or the distro-specific patched version), it needs to be updated.

Inventory every container image in your registries that ships with Apache:

# For each image in your registry, check the Apache version baked in:
docker run --rm --entrypoint=httpd <image>:<tag> -v 2>/dev/null

Container images are particularly nasty because they don't auto-update. The image you built six months ago and have been deploying ever since is forever vulnerable until you rebuild it. After patching the host packages, rebuild every container image that has Apache, push the new tag, and roll a redeploy.

Hunt for active exploitation in your access logs:

The exploitation pattern leaves traces. The attacker has to send a specific sequence of HTTP/2 frames; the Apache mod_http2 access log entry will show high-frequency RST_STREAM events from a single source IP, often interleaved with HEADERS for streams that immediately get reset.

# On RHEL/CentOS:
zgrep "h2.*RST_STREAM" /var/log/httpd/access_log* | \
    awk '{print $1}' | sort | uniq -c | sort -rn | head -50

# On Debian/Ubuntu:
zgrep "h2.*RST_STREAM" /var/log/apache2/access.log* | \
    awk '{print $1}' | sort | uniq -c | sort -rn | head -50

Any source IP with hundreds or thousands of RST_STREAM events in a short window is a fingerprint. Note that this only catches exploitation if you have HTTP/2 logging configured at debug level — most production deployments don't, and you'll see no signal in standard access logs even during active exploitation. If you don't have HTTP/2 frame-level logging, the next-best signal is unexpected child_pid exits and segfaults in error_log:

# Look for httpd children dying unusually frequently
grep -i 'child pid.*exit signal' /var/log/httpd/error_log | tail -50

# Specifically segfaults, which the double-free can produce when allocator
# detection trips (DoS half of the bug):
grep -i 'segmentation fault' /var/log/httpd/error_log | tail -50

A box that's been segfaulting Apache children regularly in the last week probably saw exploitation attempts even if it didn't get popped.

#The patch order

1. Internet-facing first. Any Apache instance reachable from 0.0.0.0/0 — your public web servers, the legacy admin panel that's still on the perimeter, the dev environment somebody put on a public IP last summer "temporarily."
2. Cloud-managed services next. Check your hosting provider's status page. AWS Elastic Beanstalk, Azure App Service, GCP App Engine — most rolled patches by May 6. Run an environment refresh to pick up the new image.
3. Internal-but-reachable Apache — the intranet, the CI/CD reverse proxy, the printer admin pages, the IPMI BMC web interface. Any internal user with a laptop on the LAN can hit these, and an attacker who's compromised a single workstation gets to them too.
4. Container images last — but don't forget them. Rebuild and push within a week. A lingering Apache 2.4.62 base image is a future-pivot for anyone who finds your registry.
5. Backup boxes / DR replicas — anything with a snapshot of the vulnerable Apache binary needs to be patched too. Restoring from backup to a "patched" box that turns out to have an old Apache binary in /opt/httpd-archive/ is the kind of thing that bites two weeks after the incident.

Apply the patch via your normal package manager, restart the service, and validate:

# Debian/Ubuntu
sudo apt update && sudo apt upgrade apache2
sudo systemctl restart apache2
apache2 -v   # confirm version

# RHEL/CentOS/Fedora/Amazon Linux
sudo dnf update httpd
sudo systemctl restart httpd
httpd -v     # confirm version

If you cannot restart Apache during business hours, you can apply the package update and then schedule a restart for off-hours. The patched binary is on disk but the running Apache process keeps the old code in memory until restart.

#Mitigations if you can't patch immediately

If for whatever reason you can't apply the patch within 48 hours (vendor change-control, frozen production, niche distro waiting for a backport), the temporary mitigation is to disable HTTP/2 entirely until you can patch.

In your Apache config (typically /etc/httpd/conf.d/ssl.conf or /etc/apache2/sites-enabled/default-ssl.conf):

# Replace this line:
Protocols h2 h2c http/1.1

# With this:
Protocols http/1.1

Restart Apache. Clients will fall back to HTTP/1.1, which is slower for sites with many small assets but still fully functional. Performance hit is on the order of 100-300ms for a typical e-commerce or content site.

The other temporary mitigation is to put a non-Apache reverse proxy in front of every Apache instance — nginx, HAProxy, or a CDN like Cloudflare. The proxy terminates HTTP/2 from the client and re-establishes HTTP/1.1 to the Apache backend, which means the bug's trigger never reaches the vulnerable code. Cloudflare's free tier alone covers this for most small businesses; the configuration is one click after pointing your DNS at them.

Of the two, disabling HTTP/2 is the simpler and cleaner fix. Do that, then patch as soon as the change-control window allows.

#Why this matters more than the CVSS suggests

The reason "double free and possible RCE" should grab your attention even if the CVSS reads as 8.8 instead of 9.x:

• Apache HTTP Server is everywhere. Most internet censuses put it second or third by deployment count, just behind nginx. The W3Techs estimate is ~22% of all websites; the Netcraft estimate is ~31% of all internet-reachable HTTP servers depending on the methodology. There is no "we don't run Apache" answer for a typical enterprise — you run Apache somewhere, and probably more places than your asset inventory says.

• HTTP/2 has been the default for a decade. Anyone running Apache 2.4.17 or later has been negotiating HTTP/2 since it shipped. The "we don't have HTTP/2 enabled" answer is rare.

• Pre-authentication is the worst kind of exposure. This is not "if an attacker has a low-privileged user account, they can escalate." It's "if an attacker can open a TLS connection, they can reach the bug." The TLS connection is the public web.

• Apache HTTPD bugs of this class historically get exploited reliably within 2-4 weeks. Look at the timeline for Optionsbleed, the chunked-encoding bugs in 2017, the modproxy SSRF in 2021. Public PoCs followed the disclosure within days, mass exploitation within weeks. The bug class is well-understood; the gap between "Apache Foundation says possible RCE" and "Mass exploitation campaign drops shells" historically averages 14-21 days.

This bug should be on your patch deck for the next seven days. After that window, expect public PoCs and exploitation tooling to drop.

#What Valtik does about this

A typical small business has Apache running somewhere they don't track — a customer-facing landing page, a WordPress site they forgot to migrate, an old admin dashboard, a print server's admin web interface. Patching it is easy. Finding every Apache instance in your environment is the hard part.

Valtik's audit scans your external attack surface and your internal network for every Apache instance, every version, and every HTTP/2 negotiation. We hand you a one-page report with the patch order, the version of each box, the IPs where Apache is exposed, and the mitigation steps for the boxes you can't patch in the immediate window. Fixed price, 24-hour turnaround.

Book a free 15-minute scope call at valtikstudios.com/free-check. If Apache is even a small fraction of your stack, the scan will find at least one box you forgot about, and that box is the one that turns into the breach in three weeks.

---

Sources cited:

• The Hacker News: "Critical Apache HTTP/2 Flaw (CVE-2026-23918) Enables DoS and Potential RCE" (May 5, 2026)
• Apache Software Foundation: HTTP Server Security Advisory CVE-2026-23918 (May 5, 2026)
• Debian Security Tracker DSA-2026-5847 (May 5, 2026)
• Ubuntu Security Notice USN-7421-1 (May 6, 2026)
• Red Hat Security Advisory RHSA-2026:8847 (May 6, 2026)