CVE-2026-23918 — the mod_http2 double-free in Apache 2.4.66, in operator terms

TL;DR — 90 seconds

A trivial crash pattern, a documented RCE path on Debian default, and eight days since disclosure with a public PoC.

Affected?

Apache HTTP Server 2.4.66 with mod_http2 enabled and a multi-threaded MPM (event, worker). In practice all TYPO3 and Sylius hosting in the German Mittelstand that enabled HTTP/2 for performance. Earlier 2.4 lines are, per Apache, not affected.

Risk?

DoS trivial — one TCP connection, two HTTP/2 frames. RCE remote on Debian/Ubuntu default with APR mmap allocator. CVSS 8.8.

Immediate action?

Upgrade to Apache 2.4.67. If the maintenance window will not open within the next 24 hours: set Protocols http/1.1, disable mod_http2 temporarily.

Recommendation?

Mittelstand: distribution patch in the current maintenance window, HTTP/1.1 stopgap fallback until then. Enterprise: curated image promotion onto patched base images, WAF rule on the HEADERS → RST_STREAM with non-zero error code frame sequence.

Criticality?

See hero badge — high.

What is the problem?

The flaw sits in the stream cleanup path of mod_http2, technically in h2_mplx.c. The trigger sequence is sober: a client sends an HTTP/2 HEADERS frame, immediately followed by an RST_STREAM frame with a non-zero error code, on the same stream, before the multiplexer has even registered the stream. Two nghttp2 callbacks fire in sequence: on_frame_recv_cb for the RST and on_stream_close_cb for the close. Both then call h2_mplx_c1_client_rst → m_stream_cleanup, which pushes the same h2_stream pointer onto the spurge cleanup array twice. When c1_purge_streams later iterates spurge and calls h2_stream_destroy, the second call hits already-freed memory. That is the classical double-free condition.

The DoS path is therefore trivial. A single attacking client can crash a worker with one TCP connection and two frames. Apache restarts the worker by default, but if the attacker runs this in a loop, effective availability of the HTTPS frontline drops to zero.

The RCE path is the structurally heavy part. The Apache Portable Runtime knows two allocators for its pool mechanism: a private heap allocator and an mmap-based allocator. On Debian, Ubuntu and all derived distributions the mmap allocator is the default. An attacker can occupy the freed virtual address via mmap reuse with a crafted, fake h2_stream struct whose pool cleanup function points to system(), and use Apache scoreboard memory as a stable container to make exploitation deterministic.

Who is affected?

A compact overview of affected and unaffected configurations:

If you exposed Apache 2.4.66 with mod_http2 on a Debian/Ubuntu base on the public internet in the last eight days, you ran a pre-auth RCE path for eight days. We treat the inventory operationally as “exploitable until proven otherwise” — not as “compromised”, but no longer at the trust state of 4 May either.

Impact

CVSS 8.8 (High); Apache classifies the advisory as Critical due to the combination of a trivial DoS path and a documented RCE path on Debian default. In the German Mittelstand the affected configuration is the standard form: Apache 2.4 is the default web server in Plesk, cPanel, ISPConfig, and the standard container image for PHP workloads. HTTP/2 has been enabled on most Mittelstand client hosts since around 2018.

A compromised webserver frontline on a TYPO3 or Sylius client host means operational access to local cleartext source code, the running PHP-FPM pools with all active backend user sessions, the database connection via credentials stored in configuration, the cloud provider token from systemd unit or container init, and the backup path with all historical content. On Sylius hosting, direct access to the Stripe / Mollie / Adyen API credential is added if it lives as an environment variable.

Mitigation and immediate actions

Three paths, depending on maintenance window and distribution discipline.

Path 1 — distribution patch (recommended)

# Debian / Ubuntu
sudo apt-get update
sudo apt-get install --only-upgrade apache2

# RHEL / Rocky / AlmaLinux
sudo dnf upgrade httpd

# Check version
apache2 -v   # or httpd -v
# Expected: Apache/2.4.67 or higher

Path 2 — pull container image fresh

# Standard Docker image
docker pull httpd:2.4
docker pull httpd:2.4-alpine

# In Compose setups
docker compose pull
docker compose up -d --force-recreate webserver

# In Helm charts
helm upgrade <release> <chart> \
  --set image.tag=2.4.67 \
  --reuse-values

Path 3 — stopgap, if no maintenance window in the next 24 hours

# /etc/apache2/conf-available/disable-http2.conf
# Apache falls back to HTTP/1.1, mod_http2 is not addressed
Protocols http/1.1

# Linux: enable configuration and reload Apache
sudo a2enconf disable-http2
sudo systemctl reload apache2

# RHEL line
echo "Protocols http/1.1" | sudo tee /etc/httpd/conf.d/disable-http2.conf
sudo systemctl reload httpd

Verify HTTP/2 is actually off:

curl --http2 -I tenant.example.com 2>&1 | head -5
# Expected: HTTP/1.1 200 OK (not HTTP/2 200)

ModSecurity will not detect the trigger sequence at the TCP layer directly. A WAF rule is primarily useful for catching repeated trigger attempts, not as sole mitigation. The patch remains the only complete fix.

Detection and validation

Three complementary detection paths we run in parallel.

Path 1: Access log pattern for unrealistic HEADERS / RST sequences

Check the last 7–10 days. Apache does not log RST_STREAM frames in detail through the normal mod_http2 logging path; the indicator is indirect — short connection lifetime with immediate stream reset and HTTP status 400/499.

# Check Apache error log for mod_http2 crash hints
sudo grep -E "h2_(stream|mplx)|child pid .* exit signal|Segmentation fault" \
  /var/log/apache2/error.log* | tail -50

Path 2: Falco rule for Apache worker crashes with an unusual process tree

# /etc/falco/rules.d/apache-h2-crash.yaml
- rule: Apache worker unexpected exit with mod_http2
  desc: Apache worker died abnormally while serving mod_http2 — possible CVE-2026-23918 exploitation
  condition: >
    proc_exit and
    proc.name in (apache2, httpd) and
    proc.exitcode != 0 and
    proc.aname[1] in (apache2, httpd)
  output: >
    Apache worker exited abnormally: pid=%proc.pid exitcode=%proc.exitcode cmdline=%proc.cmdline
  priority: WARNING
  tags: [apache, mod_http2, cve-2026-23918]

Path 3: Tetragon TracingPolicy as an eBPF alternative

apiVersion: cilium.io/v1alpha1
kind: TracingPolicy
metadata:
  name: apache-mod-http2-anomaly
spec:
  kprobes:
    - call: "sys_munmap"
      syscall: true
      args:
        - index: 0
          type: "uint64"
        - index: 1
          type: "size_t"
      selectors:
        - matchBinaries:
            - operator: "In"
              values:
                - "/usr/sbin/apache2"
                - "/usr/sbin/httpd"
          matchActions:
            - action: "Audit"

PoC validation in your own client inventory

If you have a staging environment with Apache 2.4.66, you can use one of the public PoCs to validate the detection rule in passive mode — the xeloxa PoC supports a --detection-only mode that does not run the crash trigger but only sends the fingerprint sequence. Do not run it against production hosts.

Operator recommendation

The operational question is not “patch or not?”, but “when does the next maintenance window open?” and “who carries the risk for the eight days between disclosure and your own patch?”.

Operational decision block — patch window now vs. stopgap fallback

• Patch immediately if the host carries a TYPO3 or Sylius client frontline, is publicly reachable on 443, and runs Apache 2.4.66 with mod_http2 from the Debian/Ubuntu repo.
• Use the HTTP/1.1 stopgap fallback if the maintenance window does not open within 24 hours but the host is publicly reachable. The performance impact from forgoing HTTP/2 is measurable but tolerable.
• Standard maintenance cycle is fine if the host sits behind an HTTP/1.1 downstream reverse proxy and the mod_http2 path is not reachable.
• Awareness only if no Apache 2.4.66 instance is reachable in the client inventory (nginx-only stack).

Mittelstand

Distribution patch in the current maintenance window. If you have unattended-upgrades configured on Debian/Ubuntu, review the next 24 hours of runs — the 2.4.67 bump typically arrives via the apt-security line, requires no reboot, but does require an Apache reload. The HTTP/1.1 stopgap fallback is the second line of defence.

Enterprise

Curated image promotion onto patched Apache 2.4.67 base images. WAF rule on the HEADERS / RST frame sequence as an additional layer that stays useful after the patch. Add client frontline hosts to the 24-hour early-patch pool, not the 14-day standard cycle.

Kubernetes platform

Rebuild container images that contain Apache 2.4.66. Pin Helm chart values to the patched tag, run cluster-wide rollout in the standard maintenance window, with priority for client frontline hosts. Roll out the Falco rule from the detection section cluster-wide.

• Sub-scenario Kubernetes Ingress with Apache sidecar: Update sidecar image tag in the pod template spec, rolling update via kubectl rollout restart.
• Sub-scenario Helm-based TYPO3 charts: Check image.repository and image.tag in values.yaml — often pinned to older Apache tags.

Declarative stacks (NixOS / Talos / Flatcar / Wolfi)

Update NixOS modules for apacheHttpd as soon as the nixpkgs bump to 2.4.67 is merged (as of 13 May: already merged, available on most channels). Wolfi-based Apache containers close the gap via the apk index update of the current week — trigger an image rebuild on Wolfi base with apk upgrade.

What we actually did

On 13 May 2026, between 07:15 and 08:30 CEST, we ran three disciplines.

First the inventory: every client host under our operation was queried with apache2 -v or httpd -v, plus the container tags of all TYPO3 and Sylius client images with docker image ls | grep httpd. Three hosts were on 2.4.66 (all Debian 12 base, all with mod_http2 enabled), two container images on httpd:2.4.66. The remaining hosts run on nginx or are already on 2.4.67.

Then the patch: apt-get install --only-upgrade apache2 on the three affected hosts; container images repulled with docker pull httpd:2.4 && docker compose up -d --force-recreate webserver. On a Plesk-managed host the distribution patch had to be pulled via the Plesk web UI because the apt repo is overlaid by a Plesk mirror — added a note to the client onboarding guide.

Finally the detection stage: the Falco rule Apache worker unexpected exit with mod_http2 was activated on two cluster platforms. An access log pattern check over the last 10 days yielded no client log with notable clusters of short connection lifetimes with stream reset.

The structural lesson of this flaw lies in the interaction between nghttp2 callback ordering and the APR allocator choice. The error in 2.4.66 is not in nghttp2 but in mod_http2's assumption that the two callbacks will not both trigger the cleanup path for an unregistered stream. They do. The APR allocator choice is the second lever: on Debian-based distributions mmap has historically been compiled as the default. That mmap default is the lever that turns the double-free into a pre-auth RCE path. This is the direct continuation of the line we opened with CVE-2026-31431 “Copy Fail” as the “distribution is the architecture” finding.

Conclusion

CVE-2026-23918 is not the most spectacular finding of the May patch cycle — no active exploitation in the wild, no CISA KEV entry, no BSI special report. What makes the finding operationally heavy is its triviality on the trigger side combined with the structural RCE path condition on Debian default. One TCP connection, two frames, one fewer client host. And the PoCs have been public for eight days.

The question is not whether 2.4.67 is enough — it is enough for the specific code path Apache closed on 5 May. The question is whether your platform runs the HTTP front-end layer as its own patch and detection responsibility, or whether you continue to treat the front-end frontline as a “comes with the distribution update” component. The structural answer is the first variant, with its own inventory, its own early-patch cohort, and its own WAF rule discipline.

Personal background and technical details on hardening Apache frontlines in the German Mittelstand: ole-hartwig.eu.