CVE-2026-119618: Apache HTTP/2 RCE Detection

Q: How do I check if my Apache server is vulnerable to CVE-2026-119618?

Two things must both be true: the build must be between 2.4.55 and 2.4.70 inclusive, and HTTP/2 must be enabled. Check the version with httpd -v or dpkg -l apache2 locally, or run the Nuclei template above across an estate. Check HTTP/2 with grep -rniE '^\s*Protocols' over your config, or remotely with the h2c template and the ALPN script in this post. Do not try to trigger the race to confirm it, because a failed attempt can crash worker processes.

Q: Does CVE-2026-119618 affect me if HTTP/2 is disabled?

No. Red Hat states that servers configured to serve only HTTP/1.1 are not vulnerable, because the flaw is in the concurrent stream handling that only HTTP/2 exercises. You should still upgrade to 2.4.71, because the same release fixes CVE-2026-106023 in mod_md, which is reached through ordinary request processing and affects a wider range, 2.4.30 through 2.4.70.

Q: How do I disable HTTP/2 in Apache as a temporary mitigation?

Set Protocols http/1.1 on every virtual host, unload the module with a2dismod http2 on Debian and Ubuntu or by commenting the LoadModule http2_module line on RHEL, then reload Apache. Check every vhost, since the directive is per-vhost and a TLS vhost can still negotiate h2 through ALPN. This removes the attack path rather than fixing the bug, and it costs real performance, so treat it as a holding action until you can install 2.4.71.

Q: Are Debian, Ubuntu and RHEL Apache packages affected, and how do backports change the version check?

They differ, and the difference breaks naive scanning in both directions. Debian shipped the real upstream version number, 2.4.71-1~deb13u1 and 2.4.71-1~deb12u1 in the security suites, so a banner check works there. Red Hat ships mod_http2 as a separately versioned package, 2.0.26 on RHEL 9 and 2.0.29 on RHEL 10, so patching never changes the httpd version in the banner and a fixed host keeps matching a version scan; RHEL 8 and earlier are not affected at all. Ubuntu is the dangerous one: its security team states that newer versions of the module were backported into stable releases, so the apache2 source version does not bound the mod_http2 version, and Ubuntu marks every release from 14.04 to 26.10 as Needs evaluation rather than unaffected. That means Ubuntu 22.04 at apache2 2.4.52 can still be affected even though it sits below the upstream 2.4.55 floor, and a version-range scanner will be silent on it. Always confirm with rpm or dpkg and by checking the loaded module, never with the banner alone.

Q: Is there a public exploit for CVE-2026-119618?

No verified public exploit exists, and the CVE is not in the CISA KEV catalog as of version 2026.11.10. Coverage on disclosure day reported no available exploit, though Red Hat's own statement says public research has demonstrated a reliable exploit against a default configuration. Several GitHub repositories claiming proof-of-concept code appeared within hours of disclosure and are indexed by exploit aggregators. They have not been reviewed and should not be run, because fake proof-of-concept repositories for fresh critical CVEs are a common malware-delivery channel.

On 11 November 2026 the Apache Software Foundation released httpd 2.4.71 and published CVE-2026-119618, a race condition in mod_http2 that corrupts heap memory and can lead to unauthenticated remote code execution. The ASF rates it Critical. Red Hat scores it 9.8. Apache httpd runs on a very large share of the internet-facing web, so within a day the CVE ID was already a search entity.

Most of the coverage published so far repeats the same five lines from the advisory. This post covers the parts that actually decide what you do on Monday morning: the precondition that separates an emergency from a patch-gap, the three different ways your distribution will lie to a version scanner about whether you are patched, the second CVE in the same release that hits a much wider version range, and two free Nuclei templates that find affected hosts without ever touching the bug.

One rule before anything else: do not try to trigger this. It is a concurrency flaw that corrupts the heap. A failed attempt can crash worker processes on a live server, and a successful one is an intrusion. Every check in this post is a banner read or an ordinary protocol negotiation.

What CVE-2026-119618 actually is

The ASF description is short:

Concurrent Execution using Shared Resource with Improper Synchronization vulnerability in Apache HTTP Server’s mod_http2 in assign_headers() can lead to RCE.

Red Hat’s analysis adds the mechanism. HTTP/2 lets one client multiplex many requests over a single connection, and mod_http2 services those concurrent streams with multiple threads. Because of a thread-safety flaw, a worker thread can write into memory owned by the connection thread through a shared, lock-free allocator. That is the corruption primitive. No credentials are required to reach it.

Field	Value
CVE	CVE-2026-119618
Component	`mod_http2`, function `assign_headers()`
Class	CWE-362, race condition (Red Hat files it as CWE-20)
Affected	Apache HTTP Server 2.4.55 through 2.4.70, inclusive
Also affected	Standalone `mod_h2` from GitHub, 2.0.8 through 2.0.42
Fixed in	Apache HTTP Server 2.4.71, commit `824beab`, released 2026-11-11
Precondition	HTTP/2 enabled – `Protocols h2` or `h2c`
Reported	2026-10-26 (Anthropic), 2026-11-03 (Google Cloud Vulnerability Research)
In CISA KEV	No, as of catalog 2026.11.10

The credit line is worth reading twice. The ASF names Anthropic’s OSS Scanner, as internal vulnerability ID ANT-2026-MAPKT6MZ, reporting on 26 October, and Anthony Weems and Simon Scannell of Google Cloud Vulnerability Research reporting independently on 3 November. An automated AI code scanner found a critical pre-auth RCE in one of the most heavily reviewed C codebases on the internet, eight days before a top-tier human research team found the same bug. That is the real story of this CVE, and almost nobody is telling it.

2.4.71 is a three-CVE release, and the second one has a wider range

Every article so far treats 2.4.71 as the CVE-2026-119618 release. It is not. The ASF shipped three fixes:

CVE	Severity (ASF)	Component	Affected range
CVE-2026-119618	Critical	`mod_http2` heap corruption and RCE	2.4.55 – 2.4.70
CVE-2026-106023	Important	`mod_md` NULL pointer dereference, child crash	2.4.30 – 2.4.70
CVE-2026-109163	Low	`mod_vhost_alias` 1 byte stack overwrite	2.4.69 – 2.4.70

Look at the mod_md range. It starts at 2.4.30, twenty-five releases earlier than the mod_http2 bug. This matters because of the single most common reaction to this advisory, which goes: we only serve HTTP/1.1, so we are not affected, so we can defer the upgrade. That reasoning is correct for CVE-2026-119618 and wrong for the release. A 2.4.52 host with HTTP/2 switched off is out of range for the RCE and squarely inside the range for the mod_md crash.

mod_md is Apache’s built-in ACME client, the one that issues and renews Let’s Encrypt certificates through the MDomain directive. If you use it, a remote request can dereference a NULL pointer and take down a child process. If you do not use it, unload it.

We ship a template for this one too, precisely because it catches the hosts the headline template is designed to ignore.

The scoring is a mess, and you should know why

There is no authoritative number for CVE-2026-119618. At the time of writing:

NVD has no score. The record moved from Received to Awaiting Analysis on 12 November and still carries an empty metrics object. There is no CVSS vector from NIST.
The ASF publishes no numeric score. Its advisory says Severity: critical and stops. That is the ASF’s house style; it rates, it does not score.
Red Hat scores it 9.8 with CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H, marked verified. This is the only vendor number in circulation, which is why every article you have read quotes 9.8 and attributes it to nobody in particular.

Then Red Hat does something that no aggregator has picked up: it downgrades its own products. The company rates the flaw Critical overall, but assigns Important to Red Hat Enterprise Linux 9 and 10, because the mod_http2 packages shipped there allocate each HTTP/2 stream from a separate allocator, which Red Hat says “substantially increases the complexity of exploiting the flaw”. The shared allocator is the whole exploitation path, and on RHEL 9 and 10 it is not shared.

Red Hat also states that RHEL 8 and earlier are not affected at all, because mod_http2 versions before 2.0.8 do not contain the affected code.

So: one vendor’s 9.8 is being reported as the score of record, and that same vendor says its own current enterprise platforms are a notch below that. Both facts are true. Use the 9.8 for triage urgency and the per-platform rating for sequencing.

Is it being exploited?

This is where the published record contradicts itself, and the contradiction is worth stating plainly rather than picking a side.

Coverage published on 11 November reported that no exploit was available and that there were no reports of exploitation in the wild. Red Hat’s own vulnerability statement says something different: that “public research has demonstrated a reliable exploit against a default-configured server with the mod_http2 module enabled”.

Those are reconcilable. A demonstrated exploit in research hands is not a public exploit, and neither is evidence of attacks against real estates. But the gap between “no exploit exists” and “a reliable exploit has been demonstrated against a default configuration” is the gap between a routine patch cycle and a short one. Plan for the second.

What is not in dispute:

Not in CISA KEV. Catalog 2026.11.10 contains no Apache HTTP Server entries for this CVE, and none for 106023 or 109163.
No confirmed in-the-wild exploitation from any vendor.
Several GitHub repositories claiming proof-of-concept code for this CVE appeared within hours and are already indexed by exploit aggregators. We did not review them and you should not run them. Fake proof-of-concept repositories for fresh critical CVEs are a reliable malware-delivery channel, and the people most likely to run one are administrators under pressure on patch day. If you want to know whether you are affected, read your package manifest, do not run a stranger’s exploit against your own server.

The precondition that decides your priority

Red Hat states it without hedging:

Only servers that have HTTP/2 enabled are affected; servers configured to serve only HTTP/1.1 are not vulnerable.

HTTP/2 is controlled by the Protocols directive, and it is not on by default in a stock Apache build. It is on in a great many real deployments, because it is a one-line performance win and most distribution and control-panel configurations enable it.

# HTTP/2 over TLS (the common production case, negotiated by ALPN)
Protocols h2 http/1.1

# HTTP/2 cleartext (h2c), negotiated by an HTTP/1.1 Upgrade
Protocols h2c http/1.1

So your triage has two axes, not one:

Version in 2.4.55 – 2.4.70	HTTP/2 reachable	What it means
Yes	Yes	Prioritise. Patch now.
Yes	No	Patch gap. Still fix it, but it is not an exposed pre-auth RCE today.
No	Yes	Not affected by this CVE. Check the mod_md range.
No	No	Not affected by this CVE. Check the mod_md range.

The second row is where most estates actually sit, and it is the row that the version-only scanners everyone is running this week cannot distinguish from the first.

This is the part no one else has written, and it is the part that will waste your week.

Version-based detection of a distribution-packaged service is a lead, not a finding. Here the lie runs in both directions, and differently per distribution.

Platform	Ships	Does the banner tell the truth?
RHEL 9 / 10	httpd 2.4.x, `mod_http2` as a separate package (2.0.26 on 9, 2.0.29 on 10)	No. Patching installs a new `mod_http2` RPM. The httpd version in the banner never changes, so a fully patched host keeps matching a version scan forever.
RHEL 8 and earlier	`mod_http2` below 2.0.8, or none	No. Banner may sit in range; Red Hat says not affected.
Debian trixie / bookworm	`2.4.71-1~deb13u1` and `2.4.71-1~deb12u1` in the security suites	Yes. Debian carried the upstream version number through, so the banner moves when you patch.
Debian forky	`2.4.69-1`, still open	Yes, and it says vulnerable, because it is.
Ubuntu 22.04 LTS	apache2 2.4.52, but see below	No, and not the way you expect. The source version is below the 2.4.55 floor, yet Ubuntu backported a newer `mod_http2` into it. Ubuntu marks it `Needs evaluation`, not “not affected”.
Ubuntu 24.04 LTS	apache2 2.4.58-1ubuntu8.18	In range, `Needs evaluation`, no USN yet.
Ubuntu 25.10	apache2 2.4.64-1ubuntu3.5	In range, `Needs evaluation`, no USN yet.
Docker `httpd:2.4`	2.4.71, built 2026-11-11	Yes. The official image was rebuilt on disclosure day. Pull it.

Two findings in that table deserve to be called out, and the Ubuntu one is the most dangerous assumption in this whole advisory.

On Ubuntu, the apache2 version does not bound the mod_http2 version. The obvious reading is that Ubuntu 22.04, which ships apache2 2.4.52, sits three releases below the 2.4.55 floor and is therefore out of scope. Ubuntu’s own security team says otherwise. The note on their tracker entry reads:

Upstream advisory says httpd from 2.4.55 through 2.4.70 and mod_h2 from GitHub: from 2.0.8 through 2.0.42 but newer versions of the module have been backported to stable releases in Ubuntu.

The vulnerable code lives in the module, and the module was backported independently of the server version. A 2.4.52 host can therefore be carrying a mod_http2 well inside 2.0.8 to 2.0.42. Ubuntu lists every release from 14.04 to 26.10 as Needs evaluation, and does not mark a single one as unaffected.

That is a false negative in every version-range scanner on the internet right now, ours included. A banner check gated on 2.4.55 to 2.4.70 is silent on Ubuntu 22.04 by design, and on Ubuntu that silence does not mean safe. If you run jammy, check the module directly with apache2ctl -M | grep http2 and dpkg -l 'apache2*', and watch the Ubuntu tracker rather than your scanner. This is the clearest example we have ever published of why a version banner is a lead and not a finding.

Ubuntu published on 12 November, rated it High, and has shipped nothing. The tracker entry appeared more than a day after disclosure, with priority High for the stated reason “This is a remote RCE”, and every release at Needs evaluation with no USN. There is currently no apt upgrade that fixes this on any Ubuntu release. Your options are to disable HTTP/2, build 2.4.71 yourself, or wait.

Finally, ServerTokens Prod removes the version from the banner entirely. That is good hygiene and it is not remediation. It blinds your scanner and nothing else, and we demonstrate exactly that below.

Detecting it safely with Nuclei

There is no official Nuclei template for CVE-2026-119618. We checked the upstream nuclei-templates repository on main for both http/cves/2026/CVE-2026-119618.yaml and CVE-2026-106023.yaml and both return 404. So here are ours. They are free, and they are passive.

Template 1: version in range

id: CVE-2026-119618

info:
  name: Apache HTTP Server 2.4.55-2.4.70 - mod_http2 assign_headers Race Condition
  author: sn1persecurity
  severity: high
  classification:
    cve-id: CVE-2026-119618
    cwe-id: CWE-362
    cvss-metrics: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
    cvss-score: 9.8
  tags: cve,cve2026,apache,httpd,http2,mod-http2,rce,race-condition,detect

http:
  - method: GET
    path:
      - "{{BaseURL}}"
    redirects: true
    max-redirects: 2

    matchers-condition: and
    matchers:
      - type: word
        part: header
        words:
          - "Apache/2.4."
        case-insensitive: true

      - type: dsl
        dsl:
          - 'compare_versions(version, ">= 2.4.55", "<= 2.4.70")'

    extractors:
      - type: regex
        name: version
        part: header
        group: 1
        internal: true
        regex:
          - '(?im)^Server:[ \t]*Apache/(2\.4\.[0-9]+)'

The line anchor in that extractor is not decoration. Nuclei’s regex extractor returns a set, and when a pattern matches more than once with different values the variable binds to a list. compare_versions() against a list silently evaluates false. You get no error and no finding, just a quiet false negative on exactly the reverse-proxied hosts you most wanted to see. (?im)^Server: pins the match to the start of a real header line so it can only ever bind one version. We have been bitten by this before and wrote it up in our php2shell advisory.

Template 2: is HTTP/2 actually on

The version template answers half the question. This one answers the other half by performing the RFC 7540 section 3.2 cleartext upgrade, which is the same negotiation curl --http2 performs against a cleartext port.

id: apache-http2-h2c-exposure

info:
  name: HTTP/2 Cleartext (h2c) Upgrade Accepted - CVE-2026-119618 Precondition
  author: sn1persecurity
  severity: info
  tags: http2,h2c,apache,httpd,protocol,exposure,detect,cve2026

http:
  - raw:
      - |
        GET / HTTP/1.1
        Host: {{Hostname}}
        Connection: Upgrade, HTTP2-Settings
        Upgrade: h2c
        HTTP2-Settings: AAMAAABkAARAAAAAAAIAAAAA
        Accept: */*

    matchers-condition: and
    matchers:
      - type: status
        status:
          - 101
      - type: word
        part: header
        words:
          - "upgrade: h2c"
        case-insensitive: true

One authoring note that cost us an hour. The obvious instinct is to set unsafe: true so the Connection / Upgrade / HTTP2-Settings header triple reaches the wire untouched. Do not. On nuclei v3.11.1, rawhttp fails this exact request against a real Apache with ReadStatusLine: EOF, while the standard client forwards the headers correctly and reads the 101. Verified against live httpd 2.4.70 and 2.4.71 containers.

This signal is one-directional. A 101 proves HTTP/2 is reachable. No 101 does not prove it is off, because the common production deployment is h2 over TLS via ALPN, which never uses the Upgrade mechanism at all. For TLS listeners, use the script in the next section.

Both templates, verified against real Apache

Mock-based tests prove a template parses. These were run against official httpd containers with Protocols h2c http/1.1:

Target	Version template	mod_md template	h2c probe
Real httpd 2.4.70	fires	fires	fires
Real httpd 2.4.71 (the fix)	silent	silent	fires
2.4.70 with `ServerTokens Prod`	silent	silent	fires

That last row is the whole argument for running both. Harden the banner and your version scanner goes blind, while the protocol probe keeps working. Twenty-one boundary cases against mocks pass alongside these, covering 2.4.54 and 2.4.55, 2.4.70 and 2.4.71, single-digit patch levels, a hypothetical 2.4.100, suppressed headers and non-Apache origins.

Checking a TLS estate with ALPN

For HTTPS listeners the question is whether the TLS handshake negotiates h2. That is an ALPN check, and it needs no HTTP request at all. Our detection script does the banner read, the range comparison for both CVEs, and the ALPN or h2c probe in one pass:

./cve-2026-119618-detect.py https://www.example.com
./cve-2026-119618-detect.py --targets hosts.txt --timeout 5

target   https://www.example.com:443
banner   Apache/2.4.58 (Ubuntu)
version  2.4.58
         CVE-2026-119618 mod_http2  IN RANGE  (affected 2.4.55 - 2.4.70)
         CVE-2026-106023 mod_md     IN RANGE  (affected 2.4.30 - 2.4.70)
http/2   YES - TLS ALPN negotiated h2
------------------------------------------------------------------------
VERDICT  POTENTIALLY VULNERABLE - version in range and HTTP/2 reachable.
         Prioritise. Confirm the package, then upgrade to 2.4.71.

Exit codes are 0 clean, 1 at least one affected version, 3 everything undetermined, so it drops into a pipeline. It never sends a payload.

Running it across your attack surface with Sn1per

Drop both templates into Sn1per’s curated set and they run against every HTTP service Sn1per discovers, with no further wiring:

sudo cp CVE-2026-119618.yaml CVE-2026-106023.yaml \
       apache-http2-h2c-exposure.yaml \
       /usr/share/sniper/templates/nuclei/server/

sudo sniper -t example.com -m web

For an estate rather than a host, the discovery modes feed the same template set:

# Sweep a range, then scan every live host that answers
sudo sniper -t 10.0.0.0/24 -m discover

# Full external surface for a domain, subdomains included
sudo sniper -t example.com -m airstrike

To run only these three templates against a known list:

nuclei -l apache-hosts.txt \
       -t /usr/share/sniper/templates/nuclei/server/CVE-2026-119618.yaml \
       -t /usr/share/sniper/templates/nuclei/server/apache-http2-h2c-exposure.yaml \
       -t /usr/share/sniper/templates/nuclei/server/CVE-2026-106023.yaml \
       -severity info,medium,high < /dev/null

That < /dev/null is not superstition. Nuclei reads targets from stdin whenever stdin is not a terminal, so a bare invocation inside a shell loop will silently eat the loop’s input.

If you are tracking an estate over time rather than running one-off scans, this is the kind of check that belongs in continuous attack surface testing rather than a spreadsheet. Sn1per Professional and Sn1per Enterprise both run the curated template set on a schedule and diff the results, so a host that drifts back into range after a rebuild shows up as a new finding instead of being quietly missed. The Community Edition runs the same templates on demand and is free.

Confirm at the package level before you file anything

No remote check can see your package manifest. On every host a scanner flagged:

# Debian / Ubuntu
dpkg -l apache2 | grep ^ii
apache2ctl -M | grep -E 'http2|md_module'
grep -rniE '^\s*Protocols' /etc/apache2/

# RHEL / Alma / Rocky
rpm -q httpd mod_http2
httpd -M | grep -E 'http2|md_module'
grep -rniE '^\s*Protocols' /etc/httpd/

# Built from source
httpd -v && httpd -M | grep http2

On RHEL the package that matters is mod_http2, not httpd. Compare the installed NEVRA against the advisory for your minor version: mod_http2-2.0.26-7.el9_9.1 or later for RHEL 9 (RHSA-2026:98981), mod_http2-2.0.29-5.el10_3.1 or later for RHEL 10 (RHSA-2026:98978).

And a reminder that catches people every release: a patched package is not a patched worker until Apache has been restarted or gracefully reloaded.

If you cannot patch today

The ASF advisory offers no workaround. Red Hat lists no mitigation. What exists is the precondition, and you can remove it:

# Serve HTTP/1.1 only. Removes the CVE-2026-119618 precondition.
Protocols http/1.1

Then unload the module and reload:

# Debian / Ubuntu
sudo a2dismod http2 && sudo systemctl reload apache2

# RHEL / Alma / Rocky - comment the LoadModule line, then
sudo systemctl reload httpd

Be honest with yourself about what this buys. Disabling HTTP/2 removes the attack path, not the bug, and it costs you real performance on a high-latency, high-asset-count site. It is a holding action for the days between disclosure and your maintenance window, not a resolution. And it does nothing for CVE-2026-106023 in mod_md, which is reached through ordinary HTTP request processing on any protocol version.

Check every virtual host, not just the default one. Protocols is per-vhost, and a TLS vhost can be negotiating h2 through ALPN while your cleartext probe comes back clean.

If you build Apache yourself, read this twice

The advisory names standalone mod_h2 from GitHub, versions 2.0.8 through 2.0.42, as affected. Here is the part that is not in the advisory:

The icing/mod_h2 repository is archived. Its final release is v2.0.42, published 2026-05-29, and the last commit, in June 2026, is literally an archive note. v2.0.42 is the top of the affected range. There is no v2.0.43 and there is not going to be one.

So if you build httpd against the standalone module, there is no drop-in module update for you. The only fixed code path is the mod_http2 bundled with httpd 2.4.71. Rebuild against it and stop sourcing the module separately.

Frequently asked questions

How do I check if my Apache server is vulnerable to CVE-2026-119618? Two things must both be true: the build must be between 2.4.55 and 2.4.70 inclusive, and HTTP/2 must be enabled. Check the version with httpd -v or dpkg -l apache2 locally, or run the Nuclei template above across an estate. Check HTTP/2 with grep -rniE '^\s*Protocols' over your config, or remotely with the h2c template and the ALPN script in this post. Do not try to trigger the race to confirm it, because a failed attempt can crash worker processes.

Does CVE-2026-119618 affect me if HTTP/2 is disabled? No. Red Hat states that servers configured to serve only HTTP/1.1 are not vulnerable, because the flaw is in the concurrent stream handling that only HTTP/2 exercises. You should still upgrade to 2.4.71, because the same release fixes CVE-2026-106023 in mod_md, which is reached through ordinary request processing and affects a wider range, 2.4.30 through 2.4.70.

How do I disable HTTP/2 in Apache as a temporary mitigation? Set Protocols http/1.1 on every virtual host, unload the module with a2dismod http2 on Debian and Ubuntu or by commenting the LoadModule http2_module line on RHEL, then reload Apache. Check every vhost, since the directive is per-vhost and a TLS vhost can still negotiate h2 through ALPN. This removes the attack path rather than fixing the bug, and it costs real performance, so treat it as a holding action until you can install 2.4.71.

Are Debian, Ubuntu and RHEL Apache packages affected, and how do backports change the version check? They differ, and the difference breaks naive scanning in both directions. Debian shipped the real upstream version number, 2.4.71-1~deb13u1 and 2.4.71-1~deb12u1 in the security suites, so a banner check works there. Red Hat ships mod_http2 as a separately versioned package, 2.0.26 on RHEL 9 and 2.0.29 on RHEL 10, so patching never changes the httpd version in the banner and a fixed host keeps matching a version scan; RHEL 8 and earlier are not affected at all. Ubuntu is the dangerous one: its security team states that newer versions of the module were backported into stable releases, so the apache2 source version does not bound the mod_http2 version, and Ubuntu marks every release from 14.04 to 26.10 as Needs evaluation rather than unaffected. That means Ubuntu 22.04 at apache2 2.4.52 can still be affected even though it sits below the upstream 2.4.55 floor, and a version-range scanner will be silent on it. Always confirm with rpm or dpkg and by checking the loaded module, never with the banner alone.

Is there a public exploit for CVE-2026-119618? No verified public exploit exists, and the CVE is not in the CISA KEV catalog as of version 2026.11.10. Coverage on disclosure day reported no available exploit, though Red Hat’s own statement says public research has demonstrated a reliable exploit against a default configuration. Several GitHub repositories claiming proof-of-concept code appeared within hours of disclosure and are indexed by exploit aggregators. They have not been reviewed and should not be run, because fake proof-of-concept repositories for fresh critical CVEs are a common malware-delivery channel.

Timeline and sources

Date	Event
2026-10-26	Reported to the Apache security team by Anthropic’s OSS Scanner, ANT-2026-MAPKT6MZ
2026-11-03	Reported independently by Anthony Weems and Simon Scannell, Google Cloud Vulnerability Research
2026-11-11	Fixed in 2.4.x by commit `824beab`; httpd 2.4.71 released
2026-11-11 12:19 UTC	Eric Covener announces CVE-2026-119618 on oss-security
2026-11-11 12:52 UTC	Red Hat publishes its record with CVSS 9.8 and the RHSA set
2026-11-11 15:17 UTC	NVD publishes the record, no score
2026-11-12	Ubuntu publishes its tracker entry, priority High, every release `Needs evaluation`

Primary sources, all read directly rather than via aggregators:

Distribution version data was read from the Debian security tracker JSON, the Ubuntu security tracker and Launchpad’s published-sources API on 2026-11-12. Template behaviour was verified against official httpd:2.4.70 and httpd:2.4 containers on nuclei v3.11.1.

If you want these checks running continuously against your external surface instead of once, that is what external attack surface management with Sn1per is for. Our previous advisories in this series cover CVE-2026-119977 in WordPress core and CVE-2026-98432 in the Linux kernel.

CVE-2026-119618: Pre-Auth RCE in Apache HTTP Server mod_http2 – Advisory + Nuclei Detection