Apache HTTP/2 RCE patched, many servers still exposed

A critical vulnerability in Apache HTTP Server's HTTP/2 module can let an unauthenticated attacker run code with the web server process's privileges, and the Apache Software Foundation has issued fixes, according to BleepingComputer. The bug is a race condition in mod_http2 that can corrupt heap memory and is tracked as CVE-2026-119618.

What happened and where the risk is

BleepingComputer reports that teams at Anthropic and Google Cloud discovered a race condition in the mod_http2 module that can cause heap corruption. Successful exploitation could allow remote code execution on affected software builds. The report lists the affected releases as Apache HTTP Server versions 2.4.55 through 2.4.70, and standalone mod_h2 versions 2.0.8 through 2.0.42. Apache has released updates that address the flaw.

According to telemetry cited by BleepingComputer from cloud security company Wiz, a large share of cloud environments contain vulnerable resources, and roughly half of those appear to be publicly reachable. The same reporting notes that the default Apache configuration does not enable HTTP/2, so the vulnerability only applies when HTTP/2 is turned on for a server.

BleepingComputer also notes that watchTowr researchers confirmed the exploitability of the condition and advise administrators to "patch now or drop h2 until you can." Wiz said it is not currently aware of public exploits targeting the flaw, but that situation could change.

Why Apache HTTP/2 RCE matters for small sites and public sector teams

If your site uses Apache with HTTP/2 enabled, this is not just a developer concern: a successful exploit runs with the web server process's privileges, which can let an attacker execute commands or install backdoors on the host. Publicly reachable instances are higher risk because they can be contacted by anyone on the internet. BleepingComputer emphasizes both the scope reported by Wiz and the prerequisite that HTTP/2 be active.

Even if your host manages the server for you, you should confirm whether they have applied the update. BleepingComputer reports that the Apache Foundation has published fixes, but the presence of patched code in the wild depends on operators applying those updates.

Practical steps you can take now

• Apply the Apache updates as soon as you can, or confirm with your managed host that the patch has been applied.
• If you cannot patch immediately, disable HTTP/2 for affected Apache builds or block external access to the service until patched. This follows watchTowr's advice to "patch now or drop h2 until you can."
• Check whether your public-facing servers are running one of the affected versions (2.4.55 through 2.4.70 for Apache, or mod_h2 2.0.8 through 2.0.42) and whether HTTP/2 is enabled in the server configuration.
• Restrict network exposure where possible: place web servers behind firewalls or reverse proxies that can limit access to trusted sources while you patch.
• Monitor logs and endpoint alerts for unusual behavior, and scan hosts for signs of compromise if you suspect exposure.
• If you rely on a hosted or managed service, confirm whether they have applied the patches on your behalf and document the verification.

Detection, monitoring, and follow-up

BleepingComputer notes that there were no confirmed public exploits at the time of reporting, but telemetry shows many vulnerable instances exist. After patching or disabling HTTP/2, keep an eye on server and intrusion detection logs for unexpected command execution, new accounts, or web shells. If you see indicators of compromise, follow your incident response plan and consider isolating the host.

For managed environments, ask your vendor for written confirmation that the specific Apache builds or mod_h2 releases have been updated. For self-hosted systems, schedule the update into your maintenance window, and test in staging before applying to production.

How we can help and next steps

If you want a quick external check to see how exposed your site is, start with a free external scan on our site at /security.html. The scan can tell you whether a public endpoint is reachable and whether HTTP/2 is enabled, which are the immediate determinants of risk reported by BleepingComputer.

Summary: a race condition in mod_http2 can lead to remote code execution, Apache has released fixes, and telemetry suggests many cloud-hosted instances are vulnerable if HTTP/2 is enabled. Patch promptly, or disable HTTP/2 and limit public access until you can, and verify with your host if you use managed services.