CVE-2026-119618 is a critical vulnerability in Apache HTTP Server that could allow an attacker to run code on an affected server without authenticating. Apache released a fix on Nov. 11. For security teams, the priority is knowing which workloads to address first. An affected version of Apache doesn't always mean an exposed server, and runtime context is what separates the two.

This post explains the vulnerability and how Sweet shows you which of your servers an attacker could actually reach.

What Happened

Apache HTTP Server is software that receives requests from web browsers and sends back web pages. The vulnerability is in mod_http2, the component that lets Apache use HTTP/2, a newer and faster way for browsers and servers to communicate. A timing bug in that component corrupts the server's memory, and an attacker can use it to run their own code on the server. Apache HTTP Server versions 2.4.55 through 2.4.70 are affected. Anthropic and Google Cloud Vulnerability Research each reported the bug to Apache. Red Hat rates the vulnerability 9.8 out of 10 on the CVSS severity scale.

As of this writing, there are no confirmed reports of exploitation in real attacks, but public code that crashes vulnerable servers already exists.

Not every server running an affected version can be attacked. All three of these conditions have to be true:

• The server runs an affected version of Apache (2.4.55 through 2.4.70) or of the standalone mod_h2 module (2.0.8 through 2.0.42).
• The mod_http2 component is installed and loaded.
• HTTP/2 is turned on in the server's settings.
  
  

HTTP/2 is off by default, but commonly enabled on HTTPS sites, and Red Hat states that servers using only the older HTTP/1.1 aren't vulnerable. Red Hat also says Red Hat Enterprise Linux (RHEL) 8 and earlier aren't affected, while RHEL 9 and RHEL 10 are. The fix is Apache HTTP Server 2.4.71 or mod_h2 2.0.43, or your Linux vendor's patched package. If you can't upgrade right away, Red Hat says turning off HTTP/2 can prevent exploitation until you can.

The Runtime Difference

Having an affected Apache package installed isn't the same as being at risk. A container built from a base image that includes Apache can carry the vulnerable package even though the application it runs never starts a web server. Runtime context answers three questions:

1. Which workloads are actually affected? A package that is installed but never executes can't be exploited over HTTP/2. The workloads that matter are the ones running Apache.
   
   
2. What is their exposure? Some running Apache servers accept traffic from the internet, while others only serve internal services.
   
   
3. Could an external attacker exploit it? That requires Apache to be running, HTTP/2 to be enabled and the server to be reachable from the internet. Internal-only servers still need the fix, but an attacker would first need a foothold inside your environment.

See Your Exposure With Sweet's Threat Intel Feed

CVE-2026-119618 is in Sweet's Threat Intel feed on the Sweet platform’s home dashboard. If Sweet finds a vulnerable version of Apache in your environment, the threat shows “Package Detected” and lists every affected workload. Sweet looks for Apache binaries as well as packages, so copies installed outside a package manager are found as well. For each affected workload, Sweet shows whether Apache is loaded in memory and running. Sweet’s Runtime Ingress indicator shows whether the workload has received real traffic from the internet, not just whether it's configured to accept it. From there, your team only needs to check whether HTTP/2 is turned on for the running, internet-facing servers, not for every server where Apache is installed.

Focus on the Servers Attackers Can Reach

Critical vulnerabilities like CVE-2026-119618 will keep coming, and each one raises the same two questions: which servers are actually at risk, and how do you protect them until they’re patched? Sweet answers the first with runtime context from the moment a threat is published.

The second is where most teams are left waiting on a patch. Sweet’s RCE blocking acts as a virtual patch, so an attacker who reaches a vulnerable server can’t use it to run their own commands. In our next post, we’ll show how it works and why stopping the attack at runtime closes the gap traditional patching leaves open.

To see how Sweet's runtime platform works in your environment, request a demo.