What happened
Apache HTTP Server 2.4.71 was released on November 11, 2026 with the fix for CVE-2026-119618. GovCERT.HK published an urgent security alert on November 12, 2026 recommending update to Apache HTTP Server 2.4.71. Apache classifies the flaw as critical and identifies the affected component as mod_http2 in assign_headers(), where unsafe concurrent access can corrupt process memory and lead to code execution.
CVE-2026-119618 affects Apache HTTP Server 2.4.55 through 2.4.70 and standalone mod_h2 2.0.8 through 2.0.42. Only servers with HTTP/2 enabled are affected; HTTP/1.1-only servers are not vulnerable. Red Hat says public research demonstrated a reliable unauthenticated exploit against a default-configured server with mod_http2 enabled. Distribution-specific severity and package status can differ because vendors may alter allocator behaviour or backport the fix.
The cited sources did not report active exploitation of CVE-2026-119618. The cited sources did not publish exploit infrastructure, hashes or file artefacts for CVE-2026-119618. Attribution posture: No actor attribution has been established, and the cited sources do not report active exploitation of CVE-2026-119618. The current decision is therefore exposure-led emergency remediation rather than campaign-specific incident containment. The cited source did not publish the specific operational detail described as No active exploitation reported in reviewed sources.
Why this matters now
The vulnerability is remotely reachable, requires no authentication and affects a common web-server component when HTTP/2 is enabled. Public research has demonstrated a reliable exploit against a default configuration, shrinking the margin for organisations that ordinarily wait for routine web-platform maintenance windows.
Exposure cannot be determined from a product name alone. Teams must identify whether mod_http2 is loaded, whether h2 or h2c is enabled, and whether the operating-system vendor has backported a fix. Scanner findings based only on an upstream version can create both false positives and false assurance.
The operational choice is straightforward but may require coordination: deploy Apache 2.4.71 or an authoritative vendor-fixed package, or temporarily disable HTTP/2. Internet-facing services that cannot do either need a documented, time-bound exception with compensating isolation and executive ownership.
The decision for security leaders
Assign application infrastructure to produce a decision-grade exposure list that combines package provenance, upstream or distribution version, loaded modules, protocol configuration and internet reachability. A generic software inventory without HTTP/2 state cannot distinguish exposed systems from unaffected HTTP/1.1-only deployments.
Prioritise public services and shared hosting platforms first. Where upgrading requires application testing or downtime, temporary HTTP/2 disablement is an evidence-supported mitigation. The exception owner should document the business impact, compensating controls and a fixed completion date rather than leaving the service indefinitely exposed.
Use vendor errata as the authoritative closure record for distribution packages. Upstream version comparisons can be misleading when Red Hat, Ubuntu or another distributor backports fixes. External validation should confirm the listener’s negotiated protocol and package disposition after the change.
Evidence of closure
- The exposure inventory records package source, fixed status, mod_http2 state and internet reachability.
- Internet-facing servers run Apache 2.4.71 or an authoritative vendor-fixed package.
- Systems awaiting patches have HTTP/2 disabled and external validation confirms HTTP/1.1-only negotiation.
- Every exception has an approved owner, compensating control and expiry date.
The Security.io assessment
This qualifies despite no reported active exploitation because it combines unauthenticated remote code execution, a reliable public exploit and widespread internet-facing placement. The risk is configuration-dependent, which makes fast exposure verification more valuable than assigning the same urgency to every Apache installation.
The absence of published infrastructure or file indicators limits compromise hunting. Teams should monitor for unexplained child-process crashes, anomalous commands from the web-server account and unexpected network activity, but should not present those generic symptoms as campaign-specific detections. Patch or disable the vulnerable protocol path first.
Questions for the morning meeting
- Can infrastructure teams identify every Apache server with HTTP/2 enabled?
- Are distribution backports tracked separately from upstream Apache version numbers?
- Who can approve temporary HTTP/2 disablement when immediate patching is impossible?
- Can external validation confirm that internet-facing listeners no longer expose an affected build?