# Critical Apache Flaw: Who Updates the Server Behind Your Website? > Source: > Published: 2026-11-13 19:08:17+00:00 On 11 November Apache released version 2.4.71 of its web server, one of the most widely used in the world. It fixes a critical flaw, CVE-2026-119618, that lets an attacker run their own code on the server without any password. It affects versions 2.4.55 to 2.4.70 with HTTP/2 enabled. The bug sits in the `mod_http2` module, in a function that handles request headers. Two parts of the server use it at the same time without coordinating, and with crafted requests an attacker can corrupt the process memory and get it to execute commands. Apache rates it critical, the top of its scale. It was reported twice. First on 26 October by Anthropic's automated scanner (Anthropic is the company behind Claude), an AI-based tool that reads the code of open source projects looking for bugs. Then on 3 November by two researchers at Google Cloud. The facts come from the [official Apache 2.4 vulnerabilities page](https://httpd.apache.org/security/vulnerabilities_24.html); there is also a summary in Italian on [Hardware Upgrade](https://www.hwupgrade.it/news/sicurezza-software/milioni-di-siti-a-rischio-hacking-apache-corre-a-tappare-una-falla-scoperta-per-caso-da-anthropic_162028.html). According to Hardware Upgrade, Apache serves roughly one website in five worldwide. Plenty of them belong to small businesses: a brochure site on shared hosting, a WordPress built a few years ago, a management tool reachable from outside for staff on the road. The flaw only opens up with HTTP/2 enabled, an option that makes pages load faster. Apache ships with it off, but many hosting providers and many technicians turn it on for the speed. You cannot tell by looking whether your site is exposed: someone has to check, or you have to ask. Attackers do not pick targets by name. They run programs that sweep the internet for servers with the right version, and to those programs a small site is a target like any other. A compromised server can send spam, host scam pages or hand over whatever people typed into your contact forms. The fact that one report came from an AI tool matters to you too. Tools like that find bugs in years-old code quickly. Researchers use them and attackers can use them, so the gap between a flaw being announced and the first attacks gets shorter. Updating "when we get round to it" becomes a risk. If you or your technician can log into the server, the version is one command away: ``` httpd -v apache2 -v ``` The first works on Red Hat, AlmaLinux and similar systems, the second on Debian and Ubuntu. The line that matters is `Server version: Apache/2.4.xx`. To see whether HTTP/2 is on, look for the `Protocols` directive with `h2` in the Apache configuration files. On a Linux server, though, the number alone is not enough. Debian moved its packages to 2.4.71, while Ubuntu and Red Hat patch theirs without moving to that version, so you may see a lower number with the flaw already closed. Ubuntu also had to patch packages numbered below 2.4.55, which at first glance look out of range. If the server runs a Linux distribution, the distribution's security advisory is what counts, even when the number seems out of range. Whoever runs the server knows where to find it. On shared hosting you cannot run these commands, and you do not need to: updating is the provider's job. Write to them and ask for confirmation that their servers are on 2.4.71 or carry the fix. If your site runs on a different web server, such as nginx or LiteSpeed, this flaw does not affect it; the questions below are still worth asking for the next one. If updating straight away is not possible, the temporary measure reported by the sources is to switch HTTP/2 off. The site falls back to HTTP/1.1, a little slower but out of reach of this flaw. Decide that together with whoever runs the server. Whether it is your hosting provider, the agency that built the site or a trusted technician, send them an email with these three questions. If nobody can answer one of these, that is the problem to fix, even before this particular flaw. If you do not know who runs your server, or the answer you got does not convince you, I can look at it with you: we check what the site reveals from the outside and I prepare the questions to send to your provider. For PHP sites there is also the [free PHP version check](https://gabrielepieretti.dev/php-vulnerability-check/), and on the same subject I wrote about the [two critical PHP flaws in October](https://gabrielepieretti.dev/blog-en/php-vulnerabilities-october-2026/). *Originally published at [gabrielepieretti.dev](https://gabrielepieretti.dev/blog-en/apache-http2-vulnerability-november-2026/). I write about software, security and small businesses: [more here](https://gabrielepieretti.dev/blog-en/).*