If your custom software sits behind Apache, today is a good day to log in and have a look. Apache released version 2.4.71 yesterday (11 November), and it fixes a flaw the Apache project rates as critical. The bug is in mod_http2, the module that lets Apache speak HTTP/2, and Apache's own description of it is "heap corruption and RCE". RCE means remote code execution: someone on the internet getting your server to run code of their choosing.
That's the worst kind of web server bug, so it's worth ten minutes of your time even if you're fairly sure you're fine.
What we actually know
I'll stick to what the Apache project and the people who reported it have published, because there's always a lot of guessing around a big bug in its first couple of days.
- The CVE: CVE-2026-119618, rated critical by Apache.
- Affected versions: Apache HTTP Server 2.4.55 through 2.4.70. The standalone mod_h2 module from GitHub is also affected, from 2.0.8 through 2.0.42.
- The fix: Apache 2.4.71, released 11 November 2026.
- Who found it: Apache credits Anthropic's OSS Scanner and Google Cloud's vulnerability research team, who reported it separately.
- Is it being exploited? When Wiz published its write-up, it said "no exploit is available and there are no reports of exploitation in the wild".
The same Apache release also fixes two lesser bugs, one in mod_md (rated important) and one in mod_vhost_alias (rated low). If you're updating anyway, you get those too.
That last point about exploitation is the reassuring bit, but I wouldn't lean on it for long. Once a fix is public, people can compare the old and new code to see exactly what changed. I wouldn't bank on a long gap between "patched" and "someone has a working exploit", especially now that automated tools are finding bugs like this one.
Does it affect you?
Two things have to be true. You need to be running an affected Apache version, and HTTP/2 needs to be switched on. Wiz describes the risk as applying to deployments using Apache's HTTP/2 support, and its suggested workaround is turning HTTP/2 off, which tells you where the problem lives.
On a Linux server you can check both in a couple of commands. First, the version:
apachectl -v
Then whether the HTTP/2 module is loaded:
apachectl -M | grep http2
If the second command prints nothing, mod_http2 isn't loaded. It's also worth searching your config for a Protocols line, because that's where h2 gets switched on for a site.
One thing that trips people up: if you run Apache from Ubuntu or Debian packages, the version number won't simply jump to 2.4.71 when the fix lands. Distributions often backport security fixes into the version they already ship, so the number you see can stay lower even once you're patched. The honest answer to "am I fixed?" comes from your distribution's security tracker, not the version string. When I checked Debian's tracker this morning, it showed sid (unstable) fixed in 2.4.71-1 and the stable releases still listed as vulnerable. That will change over the next few days, so keep checking rather than assuming.
What to do today
If an updated package is available for your server, install it and restart Apache. Then check your sites actually come back up, because a restart that quietly fails at 4pm is how a ten-minute job becomes an evening. I wrote up a sensible routine for this when nginx had its own batch of security fixes last month: how to patch a web server without drama. Different web server, same habits.
If you can't patch yet (your distro hasn't shipped it, or the server is fragile and needs a proper maintenance window), Wiz's suggestion is to "temporarily disable HTTP/2 support to eliminate the attack vector". In practice that means setting the Protocols line to plain HTTP/1.1:
Protocols http/1.1
Then reload Apache. Browsers will fall back to HTTP/1.1 and your sites keep working, just without HTTP/2. For most business applications nobody will notice. Make a note to switch it back on once you've patched, otherwise "temporary" has a habit of becoming permanent.
And if you built Apache yourself or installed mod_h2 from GitHub, your package manager won't help you here. You'll need to rebuild against the fixed version.
The bigger question: who's watching your server?
Here's what I think matters more than this particular bug. Plenty of custom software runs on a server that someone set up once, years ago, and nobody has properly looked at since. The developer has moved on, the hosting is "just there", and the first anyone hears about a critical web server flaw is when something goes wrong.
If you read this post and thought "I genuinely don't know whether our server runs Apache, never mind which version", that's the real problem, and it's fixable. You need someone whose job it is to notice when a bug like this lands, check whether it applies to you, and patch it the same day. That's a large part of what our Look after it service does for bespoke software we built or have taken on: security updates, hosting, backups and a named person to talk to, from £355 a month + VAT.
If you'd rather start with a clear picture of where you stand, our code audit looks at the code, the server and the database together, and you get a written report for £250 + VAT. It's a sensible first step if you've inherited a system and aren't sure what's under the bonnet, which is also where our taking on existing software work starts.
If you look after your own servers and just want a quick sanity check, my two-minute server self-check is a decent place to begin.
In short
Check whether you run Apache 2.4.55 to 2.4.70 with HTTP/2 switched on. If you do, patch as soon as your distribution ships the fix, or turn HTTP/2 off until it does. Then check your sites came back up properly.
If you'd like us to check it for you, or to take the server off your plate altogether, drop us a line and we'll have a look.
Cheers, Rob
