CVE-2026-119618: Patch Apache or Disable HTTP/2

A critical Apache HTTP/2 vulnerability, CVE-2026-119618, lets a remote attacker with no login run code on Apache HTTP Server 2.4.55 through 2.4.70 when HTTP/2 is enabled. The upstream fix is 2.4.71, released 11 November 2026. The Hacker News reported the flaw the next day. The server in front of your WordPress or Joomla site is the target. Check whether h2 or h2c is on, and whether you or your host can turn it off today.

What is the Apache HTTP/2 vulnerability CVE-2026-119618?

CVE-2026-119618 is a critical remote code execution flaw in Apache HTTP Server’s HTTP/2 module, mod_http2, the process in front of WordPress and Joomla. The Hacker News account does not describe the root cause. It says a remote attacker can run code. The Apache advisory, as that reporting summarizes it, names 2.4.71 as the fix and offers no workaround.

Red Hat’s impact statement, as The Hacker News paraphrased it: an attacker who can reach the server needs no authentication and could take full control of the server process. There is no CMS login on that path. On a public virtual host, the listener is already reachable. Treat files Apache can read as in scope for rotation if the host was exposed: database passwords, WordPress salts, and the Joomla secret. That is operational caution, not a claim that a named breach already happened.

The flaw was reported on 26 October 2026 by Anthropic’s OSS Scanner, a free scanning service for open-source projects that uses the company’s AI models. The reporting does not say the Apache advisory itself prints that credit. Anthony Weems and Simon Scannell of Google Cloud Vulnerability Research reported the flaw separately last week, relative to the 12 November article. The piece does not pin a calendar day or explain how the two reports were combined.

Red Hat scores CVE-2026-119618 at 9.8 out of 10. The reporting does not print the CVSS vector. On Red Hat Enterprise Linux 9 and 10, Red Hat’s severity word is Important, not Critical. Those mod_http2 packages give each HTTP/2 stream its own memory allocator, and Red Hat says that design makes an attack much harder. A scanner label of Critical and a Red Hat page that says Important can both describe CVE-2026-119618 on different builds.

HTTP/2 keeps per-stream state inside the server before PHP runs. Red Hat’s exploit note assumes a default configuration that already has mod_http2 enabled. The reporting does not say every Apache build turns h2 on with no admin change.

Which Apache versions are affected by the HTTP/2 flaw?

The vulnerable upstream range is Apache HTTP Server 2.4.55 through 2.4.70, fixed in 2.4.71 on 11 November 2026. Versions older than 2.4.55 fall outside the range the reporting gives for this bug. That is not a reason to keep an ancient httpd online.

A May 2026 patch does not clear this CVE. An earlier HTTP/2 flaw, CVE-2026-23918, was fixed in Apache HTTP Server 2.4.67 on 4 May 2026. Releases 2.4.67 through 2.4.70 stay inside the affected range for CVE-2026-119618.

Release 2.4.71 also fixes a crash in mod_md, rated important, and a one-byte overwrite of stack memory in mod_vhost_alias, rated low. If you build from the Apache HTTP Server project’s own source, take the whole 2.4.71 release. The advisory lists no workaround inside the server.

Standalone mod_h2, the GitHub build of the same module, is affected from 2.0.8 through 2.0.42. No fixed release exists. The Hacker News notes that the GitHub release list ends at 2.0.42. The repository has been read-only since it was archived on 9 June. The article does not state the year. People who compiled mod_h2 outside a distribution package need a maintained httpd, or HTTP/2 switched off.

Distributions that backport security fixes often leave the banner from httpd -v on an older 2.4.x string. Red Hat shipped the correction as a module package without requiring that banner to read 2.4.71. Seeing 2.4.62 does not prove the host is still vulnerable. Match the installed package to the vendor advisory, or read the package changelog for CVE-2026-119618.

CVE-2026-119618 applies to the server process only when HTTP/2 is enabled. A host on 2.4.70 that never set h2 or h2c is not exposed to this CVE. HTTP/1.1-only hosts can schedule 2.4.71 with less urgency, because that release also carries the mod_md fix.

How do you check whether HTTP/2 is turned on?

Only servers with HTTP/2 enabled are vulnerable to this Apache HTTP/2 vulnerability. The first check is the Protocols directive, not the version banner. The token h2 turns on HTTP/2 over TLS. The token h2c turns on HTTP/2 over plain TCP. Either token can be set for the whole server or for one virtual host. A server-wide Protocols http/1.1 line does not protect a virtual host that sets Protocols h2. Read the global config, every virtual host, and any conf.d snippet or configuration-management template that writes h2 back on the next deploy.

apachectl -S, plus a search across the include directories for h2 and h2c, is more reliable than httpd -v for this CVE. From any computer that can reach the site, this shows what the public listener negotiates. You do not need a shell on the host:

curl -sI --http2 -o /dev/null -w '%{http_version}n' https://your-site.example

A result of 2 means HTTP/2 was negotiated. A result of 1.1 means this URL did not speak HTTP/2. A cleartext h2c listener will not show up on an HTTPS URL, so the config search still matters. h2c usually comes from a reverse proxy, a load balancer, or an internal service aimed at Apache on plain TCP. Container base images and appliance firmware often bundle httpd with HTTP/2 enabled. An inventory of host OS packages misses those copies. Some builds load mod_http2 and still leave the protocol off until Protocols names it. Red Hat’s phrase about a default configuration refers to a server that already has mod_http2 enabled.

Apache’s advisory offers no workaround. The interim control published by Wiz is to remove h2 and h2c from the Protocols directive and leave Protocols http/1.1. The same change covers standalone mod_h2 2.0.8 through 2.0.42, where no fixed release exists. WordPress and Joomla keep serving pages, logins, and forms over HTTP/1.1. Put the change in the main server config, in every virtual host, and in the template that configuration management will copy back. A panel switch labeled as a performance tweak can turn h2 on again. After the edit, reload Apache and confirm the curl result is 1.1 on each public hostname. Then schedule upstream 2.4.71, or the vendor package that names CVE-2026-119618.

A package install does not update a worker that is already running. After the install, confirm the new package version, then confirm the Apache process start time is later than that install. On a host where you have a shell:

ps -o lstart= -C apache2 || ps -o lstart= -C httpd

If your service name differs, check the process your panel actually runs. An old mod_http2 still mapped in a live process keeps the bug in memory until the reload or restart.

On shared hosting the account owner cannot replace httpd and often cannot edit Protocols either. That limit matches what shared-hosting owners can and cannot patch: the web server package belongs to the host. The curl check from your laptop still works. The process-start command does not. Open a ticket and ask three things in writing. Is h2 or h2c enabled on this account? Which apache2 or httpd package is installed, and does its changelog name CVE-2026-119618? When will 2.4.71 or a backport be installed?

If the virtual host was reachable with HTTP/2 on while the package was still in 2.4.55 through 2.4.70, rotate the database password, WordPress salts, the Joomla secret, and API tokens stored in files the web server could read. No public campaign was confirmed in the 12 November reporting. Then scan the files you do control. Antivirus website protection looks for dropped PHP, altered core files, and unknown admin users after the host owns the Apache binary.

What has each Linux vendor actually shipped?

Upstream Apache 2.4.71 does not mean your distribution package is fixed. That gap is the same lesson as why patching the OS is not always enough: an HTTP-layer component can lag until the right package ships.

Red Hat shipped fixes for Enterprise Linux 9 and 10 on the same day as 2.4.71. RHEL 9 is mod_http2-2.0.26-7.el9_9.1 via RHSA-2026:98981. RHEL 10 is mod_http2-2.0.29-5.el10_3.1 via RHSA-2026:98978. Extended-support channels received RHSA-2026:98968, RHSA-2026:98954, RHSA-2026:98982, RHSA-2026:98953, and RHSA-2026:98979. Those cover RHEL 9.4 Update Services for SAP Solutions, plus 9.6, 9.8, 10.0, and 10.2 Extended Update Support. Match the advisory to the channel you run.

RHEL 6, 7, and 8 are not affected. They do not contain the vulnerable code. The Important rating on RHEL 9 and 10 is Red Hat’s judgment about exploitation difficulty on that build, tied to per-stream memory allocators. It does not replace the 9.8 score. Install the RHSA if HTTP/2 is in use. Red Hat JBoss Core Services and Red Hat Hardened Images were listed as affected with no fix named when The Hacker News published. On those images, removing h2 and h2c is the control that exists today. Turn HTTP/2 back on only after a later advisory names a fixed image.

Debian’s security tracker, as cited in the reporting, is split. Unstable (sid) is fixed at apache2 2.4.71-1. bookworm, trixie, and forky were listed as vulnerable, with no fix named. A production host on bookworm does not pick up the sid package by itself. Amazon Linux 2 (Core), Amazon Linux 2023, and Amazon Linux 2027 Preview were pending a fix on the Amazon Linux tracker. Ubuntu had no CVE tracker page when the reporting was checked. A missing tracker page is an unknown, not a statement that Ubuntu builds lack the code.

As of the 12 November 2026 reporting, public sources had not settled whether a working exploit is in general circulation. Red Hat and Wiz disagreed in the same news cycle. Red Hat’s phrase, quoted by The Hacker News, is that public research has demonstrated a reliable exploit on a server in its default configuration with mod_http2 enabled. Red Hat did not name the research, the author, or a link. The reporting does not say that default means HTTP/2 is on for every Apache product. Later the same day, Wiz said no exploit was available and that no exploitation in the wild had been reported. The Hacker News declines to settle the dispute. A claim of demonstrated research is not proof your host was breached. A statement that no exploit is public is a snapshot from that day.

CISA’s Known Exploited Vulnerabilities catalog is not cited for CVE-2026-119618 in this reporting. Absence from that list, the day after a patch, is a timing fact. If h2 or h2c is on and the package is in the affected range, disable the protocol or install the fixed build today. Hosts that already serve only HTTP/1.1 stay outside the precondition the vendors described. The curl result, the package changelog, and the process start time are the checks you can run without picking a side. If any of those checks fails, assume the server process was reachable in a vulnerable state, rotate the secrets Apache could read, and keep HTTP/2 off until the fixed package is installed and running.

For owners who cannot patch the web server and still need the site watched, website protection covers file changes and malware on the part of the stack the account can see while the host’s Apache package catches up.

FAQ

What is CVE-2026-119618 in Apache HTTP Server?

It is a critical flaw in mod_http2: a remote attacker who can reach a vulnerable server needs no login and could take control of the server process. The public write-up does not describe the root cause, the named fix is Apache HTTP Server 2.4.71, and the advisory offers no workaround.

Does turning off HTTP/2 break my WordPress or Joomla site?

No. With Protocols set to http/1.1, Apache still serves pages, logins, and checkout. You pause HTTP/2 multiplexing until a fixed package is installed and you choose to enable h2 again.

How do I turn off h2 and h2c in Apache?

Remove h2 and h2c from Protocols in the main server config and in every virtual host, and set Protocols http/1.1. Update the panel or configuration-management template so the next deploy does not put the tokens back, then reload Apache.

Has CVE-2026-119618 been exploited in the wild?

The 12 November reporting did not settle it: Red Hat said public research demonstrated a reliable exploit on a default configuration with mod_http2 enabled and did not name that research, while Wiz said the same day that no exploit was available and no in-the-wild exploitation had been reported.

If your host still has not shipped a build that names CVE-2026-119618, SiteGuarding website protection watches the files and admin users you can still control while HTTP/2 stays off.