On 11 November, cloud security firm Wiz published a write-up of CVE-2026-119618, a critical flaw in Apache HTTP Server, the software that sits underneath a very large number of business websites. There is a patched version. Someone needs to install it on the machine your site runs on.
That last sentence is the whole story for an owner. The interesting question this week is not what the bug does. It is whether you can name the person whose job it was to fix it, and whether they have already done it without you asking.
What the flaw is, as much as you need to know
Apache is the program that listens for visitors and hands back your web pages. The flaw sits in the part of Apache that speaks HTTP/2, the newer, faster way browsers talk to servers.
According to Wiz, the bug is a timing fault in how Apache handles simultaneous requests, and a remote attacker who has not logged in to anything could use it to run commands on the server with the web server's own permissions. In practice that means reading files, planting things, and using your box as a foothold. Wiz notes that at the time of publication there was no public exploit and no reports of attacks in the wild.
The versions affected are 2.4.55 through 2.4.70. The fix is 2.4.71 or newer. If patching has to wait, Wiz says turning off HTTP/2 removes the attack path entirely, at a small cost to page speed. That is a two-line configuration change for whoever manages the server.
You do not need to retain any of that. You need to be able to forward it.
The number worth noting is how ordinary this is
Wiz reports that 64% of cloud environments it sees have resources running a vulnerable version, and 51% have vulnerable instances exposed to the public internet. Wiz sells cloud security software, so treat the figures as a vendor's telemetry rather than a census. The direction is still right. This is not an exotic piece of infrastructure. It is the default web server on a huge number of Linux boxes, and plenty of them have been running quietly since the day they were set up.
That is exactly why it matters more than a scarier-sounding bug in something you chose deliberately. Nobody decided to run Apache 2.4.62. It came with the server image, it worked, and it never came up again.
The experts are arguing about severity, and it does not change your to-do list
The Hacker News thread on the vulnerability is less unanimous than the advisory. One commenter questioned the leap from memory corruption to confirmed remote code execution, pointing out that not every crashable bug turns into a working exploit. Others picked at the write-up itself: one asked why GitHub was listed as the "vendor" for an open source module, and another spotted two different CVE numbers in the same post. Another commenter claimed to have reproduced a race condition in a vulnerable build within minutes using an AI model, and said disabling HTTP/2 stopped it. These are claims from a comment section, not verified findings.
Here is the thing. Whether the real-world exploitability is a 9 or a 6, the action for your business is identical: install the patched version, or turn off HTTP/2 until you can. The debate is a technical one for people who maintain server software. If the people who maintain yours are having that debate this week, good. If nobody is having it at all, that is your actual finding.
Most businesses discover the gap during the incident, not before it
The pattern is familiar and it has nothing to do with Apache. A site gets built. It gets deployed to a server someone configured well, at the time. The maintenance retainer runs for twelve months and then quietly lapses, or the agency closes, or the one developer who had the credentials moves on. The site keeps working, because websites do keep working, right up until they do not.
Then a critical advisory lands and three things become clear at once. Nobody has logged into that server in two years. Nobody knows which version of anything is on it. And the person asking the questions is the owner, at 9pm, with a site that may or may not already be compromised.
Patching is not a skill problem. It is an ownership problem. It needs a named owner, a schedule, a way to verify the work was done, and a path for someone to raise the alarm when a critical advisory lands between scheduled windows. Any build we would hand over has to answer those four questions in writing, because an unanswered maintenance question is a dated time bomb regardless of how good the code is.
Work out which kind of hosting you actually have
There are broadly two situations, and the difference decides who is responsible.
If your site runs on a fully managed platform, such as hosted eCommerce or a managed WordPress plan, the provider operates the web server and patching the underlying software is their job. You should still confirm it, but you are not the one doing it.
If your site runs on a virtual server, a cloud instance, or anything where your developer can log in with SSH and change settings, the operating system and the web server are yours. "The hosting company" is renting you a machine, not maintaining your software. Plenty of owners believe they are in the first group and are actually in the second.
If you are not sure which one you are, that uncertainty is itself the answer, and it is worth resolving this week rather than during an outage.
The email to send today
Send this to whoever maintains your site. Hosting provider, developer, internal IT, whoever picks up the phone.
- Which web server software and version does our site run on, and is it patched against CVE-2026-119618?
- Who applies security patches to that server, on what schedule, and who checks that they were applied?
- How would we be told if a critical patch applied to us, if we had not asked?
- If the answer is "the host does it," which part exactly: the operating system, the web server, or just the hardware?
Judge the reply on two things: speed and specificity. A same-day answer naming a version number and a patch date is a maintenance arrangement that works. A slow answer, or one that is confident but vague, tells you the job does not currently have an owner. That is worth more to you than any CVE. Fix the ownership gap and the next advisory is a routine Tuesday instead of an emergency.
