nghttp2/nghttpx: an HTTP/1.1 flaw can bring down the proxy

Ubuntu security notice USN-8495-1 reports a vulnerability in nghttp2, and more specifically an exploitable impact on nghttpx, the reverse proxy component of the nghttp2 ecosystem. The issue concerns the handling of certain HTTP/1.1 requests using the Upgrade mechanism, combined with a Content-Length header and a request body. In deployments exposing nghttpx at the front end, a remote attacker can cause a denial of service and interrupt application traffic passing through the proxy.

The important point, for operations teams as well as CISOs, is that this is not a theoretical bug limited to a marginal use of HTTP/2. nghttpx is used as a termination layer, reverse proxy, or gateway between clients and applications. When a front end of this type goes down, the impact extends far beyond the component itself: published sites and APIs become unavailable, monitoring errors cascade, restart mechanisms may become saturated, and service degrades for all applications behind the proxy.

The Ubuntu notice does not present this flaw as code execution or a confidentiality compromise, but a remote DoS on an edge component remains critical in production. For many environments, especially at hosting providers or on exposed VMs at OVHcloud, Scaleway or o2switch, the reverse proxy is the main entry point. An interruption of this link is enough to make a service unavailable, even if the application backends remain intact.

The reference source is the official Ubuntu notice USN-8495-1: nghttp2 vulnerability, which states that a security update fixes the issue in the affected Ubuntu packages. When a CVSS score or a CVE identifier is required by your internal processes, you should refer directly to the Ubuntu notice and the associated metadata in the distribution’s security repositories, as well as any upstream references possibly mentioned by the vendor. In the absence of a detail explicitly confirmed in the source notice provided here, it is better not to extrapolate.

Affected versions

The affected systems are deployments using the nghttp2 and/or nghttpx packages provided by Ubuntu before applying the fix published in notice USN-8495-1. The essential information to remember is therefore the following: if your Ubuntu instance is running a version of nghttp2 from the distribution repositories and security updates have not yet been applied, it should be considered potentially vulnerable.

The Ubuntu notice provides the exact list of releases and fixed package versions. In an operations context, two things must be checked:

• the installed version of the nghttp2 package on the host;
• the actual use of nghttpx as a reverse proxy or HTTP front end.

On Ubuntu, the simplest check is to query the package manager:

apt-cache policy nghttp2

Depending on how the package is named on your Ubuntu version, it may be useful to list installed packages related to nghttp2:

dpkg -l | grep nghttp2

To get details of installed and candidate versions from the repositories, you can also use:

apt list --installed | grep nghttp2

In environments where nghttpx was installed as a separate component or dependency of an HTTP exposure chain, you must check the service actually running on the machine:

systemctl status nghttpx

Or, if the service is supervised differently:

ps aux | grep nghttpx

In practice, the affected versions are therefore versions earlier than the fixed version published by Ubuntu for each supported release. The exact fixed version depends on the Ubuntu branch in use. Since notice USN-8495-1 is the normative source, it should be consulted for the precise mapping between Ubuntu release and fixed package version number.

This point is particularly important in mixed infrastructures:

• Ubuntu VMs exposed directly to the Internet;
• nodes behind a load balancer but running nghttpx themselves;
• containers built from Ubuntu images not rebuilt since the notice was published;
• internal appliances or golden images containing a package frozen before the fix.

In other words, the risk does not concern only manually administered servers. It also affects image pipelines, cloud templates, and automated deployments that continue to reproduce a vulnerable base.

Attack vector

The vector described by Ubuntu relies on HTTP/1.1 requests of the Upgrade type, accompanied by a Content-Length header and a request body. This combination is important because it falls outside the simplest use case of a reverse proxy receiving standard HTTP requests without a protocol transition.

Technically, the Upgrade mechanism in HTTP/1.1 allows a client to request a protocol change on the existing connection. In the modern web ecosystem, this mechanism is known notably for certain transition or negotiation scenarios, even if not all front ends use it in the same way. When a component like nghttpx processes this type of request, it must properly handle several states:

• parsing the request line and headers;
• the presence of a Content-Length declaring a body size;
• the actual receipt of the body;
• whether or not to switch to the protocol requested by Upgrade;
• coordination between the HTTP/1.1 parsing layer and the proxy logic.

An error in this sequence can lead to an unexpected process state, abnormal resource consumption, abrupt termination, or service blockage. The Ubuntu notice summarizes this as a remote denial-of-service impact. For defenders, this means an attacker does not need authenticated access or an internal foothold: they only need to reach the vulnerable front end and send requests crafted according to this pattern.

A minimal example request illustrating the elements mentioned in the notice looks like this:

POST / HTTP/1.1 Host: cible.example Connection: Upgrade Upgrade: h2c Content-Length: 8 ABCDEFGH

This block is not a validated exploitation PoC, but an illustration of the protocol components cited by the source: an HTTP/1.1 request, an Upgrade header, a Content-Length header, and a body. The key point is not the requested resource, but how the proxy handles the entire transaction.

In a real-world scenario, an attacker can automate the repeated sending of such requests against a public IP or domain name exposing nghttpx. If the bug causes the process to terminate, visible symptoms may be immediate:

• 502, 503 errors or a complete lack of response on the client side;
• successive service restarts if a supervisor attempts to relaunch it;
• error spikes in availability probes;
• degradation across all applications published behind the front end.

In a cluster or redundant architecture, the impact depends on the topology. If several vulnerable nodes are exposed behind a load balancer, an attacker can target each instance in turn. If the front end is unique, the service can become unavailable from the first interruption. Even with redundancy, an application-layer DoS targeting the proxy can severely degrade overall capacity if the nodes are homogeneous and vulnerable.

It should also be emphasized that a point often underestimated is this: an availability flaw on a reverse proxy is not just an operational convenience issue. For a business API, a customer portal, an administration interface, or a B2B service, unavailability can have contractual, financial, or security consequences. A front-end outage can prevent access to authentication mechanisms, block legitimate incoming flows, disrupt automated tasks, and complicate incident response.

Impact

The impact confirmed by the Ubuntu notice is a remote denial of service on nghttpx. It is important to clearly distinguish what this means and what it does not mean.

• What is confirmed: a remote attacker can bring down the proxy or disrupt its operation via specific HTTP/1.1 Upgrade requests.
• What is not stated here: no code execution, no privilege escalation, and no data leakage are indicated in the summary provided by the Ubuntu source.

Even so, a DoS on an edge component remains a serious incident. In many web stacks, nghttpx performs one of the following functions:

• TLS termination;
• reverse proxying to HTTP applications;
• gateway between HTTP/2 clients and backend services;
• control point for headers, routing, or connection policies.

If this component becomes unavailable, downstream applications may be perfectly healthy while still becoming inaccessible. This is why DoS flaws in front-end building blocks must be treated with the same seriousness as a defect in a load balancer, a WAF, or a TLS proxy.

Several impact scenarios are plausible in production:

Front-end interruption of a site or API

The most direct case is the nghttpx process stopping or becoming unable to continue handling connections. Users then get connection errors, gateway error responses, or timeouts.

Instability under automatic restart

With systemd or another supervisor, a service that crashes can be restarted automatically. This limits the duration of each interruption, but can produce an unstable state if the attacker continues sending malicious requests. Logs then show alternating starts and stops, sometimes accompanied by increased load related to the restart cycle.

Cascading effect on monitoring and operations

A flapping front end disrupts metrics, triggers repeated alerts, and can mask other events. NOC/SRE teams lose visibility at the very moment when the incident requires rapid analysis. In highly automated environments, remediation mechanisms may even worsen the situation by unnecessarily recycling healthy but unpatched instances.

Multi-tenant degradation

If the same nghttpx publishes several applications or several vhosts, a single flaw at this entry point potentially affects the entire portfolio of services hosted on the instance. This is a classic issue for providers, shared platforms, or the ingress nodes of internal clusters.

This vulnerability is a reminder of an operational reality: protocol-oriented components, often perceived as simple “pipes,” are in fact critical assets. Their attack surface is constantly exposed to untrusted input. A parsing or state-management weakness in a proxy can therefore have a disproportionate effect compared with the apparent simplicity of the bug.

How to patch

The fix is available through the Ubuntu security updates published in notice USN-8495-1. The priority remediation is to update the affected packages from the official Ubuntu security repositories, then restart the service using nghttpx if necessary.

On a standard Ubuntu host, the update sequence is as follows:

sudo apt update sudo apt install --only-upgrade nghttp2 sudo systemctl restart nghttpx

Depending on the exact packaging of your Ubuntu release, it may be necessary to update all packages related to nghttp2 rather than a single name. To identify available packages and their candidate versions:

apt-cache policy nghttp2 apt search nghttp2

If your operations policy prefers applying all available security updates at once:

sudo apt update sudo apt upgrade

In automated or immutable-image environments, the image must be rebuilt from an Ubuntu base that already includes the security notice, then the instances must be redeployed. On a container or CI/CD image, a simple one-off update on a live node is not enough if the pipeline continues producing artifacts from a vulnerable layer.

To verify that a fixed version has indeed been installed:

dpkg -l | grep nghttp2 apt-cache policy nghttp2

You must compare the installed version with the fixed version indicated for your Ubuntu release in notice USN-8495-1. It is this mapping, and not a generic version found elsewhere, that is authoritative in an Ubuntu-supported environment.

After updating, several operational checks are recommended:

• check the status of the nghttpx service;
• review system and application logs;
• test the endpoints exposed over HTTP and HTTPS;
• monitor availability and restart metrics for a few hours.

Examples of useful commands:

systemctl status nghttpx journalctl -u nghttpx --since "2 hours ago" ss -ltnp | grep nghttpx

In a high-availability environment, the patch should ideally be deployed by rotation: remove a node from the pool, update, restart, verify, then reintegrate it before handling the next one. This approach reduces the risk of a global interruption and makes it possible to confirm corrected behavior on one instance before generalizing.

For teams with compliance or vulnerability-management obligations, it is useful to record in the remediation ticket:

• the source reference USN-8495-1;
• the affected hosts or images;
• the version installed before the fix;
• the fixed version deployed;
• the service restart date;
• post-patch validation evidence.

Mitigation

When the patch cannot be applied immediately, surface reduction should target the specific vector mentioned in the notice: HTTP/1.1 requests using Upgrade, with Content-Length and a body. No mitigation replaces the fix, but several measures can temporarily reduce exposure.

Filter or restrict uses of Upgrade upstream

If nghttpx is placed behind another front end, a CDN, a WAF, or an application load balancer, it may be possible to block or log requests containing the Upgrade header when this mechanism is not necessary for the service provided.

The defensive principle is simple: if your application has no legitimate need for negotiation via Upgrade at this entry point, rejecting these requests immediately reduces the attack surface. This measure must nevertheless be validated functionally, because some specific uses or network intermediaries may depend on particular behaviors.

On an intermediate front end capable of filtering HTTP headers, rules of the following type should be considered:

• block requests containing Connection: Upgrade to services that do not use it;
• block Upgrade + Content-Length combinations on routes not concerned;
• log these requests to identify possible scans or repeated attempts.

The exact syntax depends on the product used upstream. Since the source notice is Ubuntu and not a configuration guide for a particular WAF, these rules must be adapted to your actual stack without improvising production configuration.

Limit network exposure

If nghttpx is not intended to be directly accessible from the Internet, the most effective mitigation is often to reduce network access:

• restriction by ACL or security group;
• exposure only behind a better-controlled front-end component;
• limitation to certain partner or internal networks;
• disabling unnecessary listening interfaces.

On cloud infrastructures, this step involves reviewing the security rules attached to VMs or load balancers. A publicly exposed Ubuntu instance at OVHcloud or Scaleway with an application port open “by default” may end up reachable far beyond the actual business need.

Enable limiting and resilience mechanisms

Rate-limiting protections do not fix the vulnerability, but they can slow opportunistic exploitation or make automated flooding more costly. Depending on the architecture, this may include:

• limiting the number of connections per source;
• requests-per-second thresholds on the upstream front end;
• strict timeouts on incomplete connections;
• monitoring of abnormal errors and restarts.

However, it is important to remain realistic: if a single properly formed request is enough to bring down the service, rate limiting does not prevent targeted exploitation. It remains useful mainly against large-scale scans and repeated attempts.

Strengthen supervised restart without relying on it as a remedy

Checking the systemd restart policy can improve availability during the risk window:

systemctl cat nghttpx

Options such as Restart=on-failure can help bring the service back online after a crash, but they must not be considered a fix. If the malicious request remains possible, the attacker can simply reproduce the outage. This measure is about service continuity, not removing the cause.

Detection

Detection should rely on two axes: network/application traces and system symptoms. Since the vector is relatively specific, it is relevant to look for HTTP/1.1 requests simultaneously containing certain headers.

Indicators of compromise or exploitation

In this case, these are more IoCs of malicious activity or exploitation attempts than indicators of persistent compromise. The following elements warrant investigation:

• repeated presence of Connection: Upgrade headers in access logs;
• presence of an Upgrade header on endpoints that do not normally use it;
• HTTP/1.1 requests containing Upgrade, Content-Length, and a body at the same time;
• unexpected restarts of the nghttpx service correlated with these requests;
• spikes in 502, 503, or timeout errors on the front end.

Depending on your logging level, it may be useful to search for the following strings:

Upgrade: Connection: Upgrade Content-Length:

Examples of searches on the system side:

journalctl -u nghttpx --since "24 hours ago" grep -R "Upgrade" /var/log

If front-end access logs are centralized, correlation by source address, frequency, and presence of the cited headers is recommended. A single source repeatedly sending requests with Upgrade to a service that never uses it is a weak but useful signal. A temporal correlation with service outages strongly increases suspicion.

System symptoms to monitor

• stops or restarts of the nghttpx process;
• an increase in the number of restarted systemd units;
• sudden availability degradation on external probes;
• an increase in gateway errors on downstream applications.

On monitoring platforms, it is relevant to temporarily set up specific alerts on:

• the number of service restarts;
• the rates of non-2xx/3xx responses from the front end;
• loss of connectivity on ports exposed by nghttpx.

Validation after remediation

Once the fix has been applied, targeted monitoring should be maintained for a reasonable operations cycle. The goal is not only to verify the update, but also to confirm the absence of residual instability and detect any exploitation attempts still present on the Internet.

In highly exposed environments, it is not uncommon for automated scanning to continue after patching. If suspicious requests persist but the service remains stable, this is a good indicator of effective remediation, while also underscoring the usefulness of additional upstream filtering.

Ecosystem perspective

This vulnerability illustrates a recurring issue in web infrastructure security: protocol translation or termination components concentrate significant complexity. Between HTTP/1.1, HTTP/2, handling of Upgrade, request bodies, persistent headers, and connection states, the robustness of a proxy depends on a large number of edge cases.

The fact that a flaw is triggered via HTTP/1.1 in a component associated with HTTP/2 is therefore not anecdotal. On the contrary, it is typical of building blocks that interface between several protocol versions or several processing modes. The more input variations a component accepts, the more important patching discipline and surface reduction become.

For French organizations, this matter also fits into a technical governance logic:

• maintain a precise inventory of the reverse proxies actually exposed;
• distinguish installed packages from services that are actually active;
• track vendor and distribution notices, including Ubuntu and, depending on the case, relays from CERT-FR when a topic has broader scope;
• avoid frozen images remaining too long without rebuilding.

Many availability incidents do not stem from a total absence of patching, but from a patch applied to “visible” servers while less obvious nodes remain vulnerable: standby instance, exposed preproduction environment, autoscaling image, administration node, or secondary front end. An alert like USN-8495-1 should therefore trigger not only an update, but also an alignment check across the entire fleet.

The official source to cite for this vulnerability remains the Ubuntu notice USN-8495-1: nghttp2 vulnerability. It is the reference document for the affected Ubuntu packages, the fixed versions by release, and update instructions via the security repositories. In monitoring processes, it is wise to link this notice to internal inventories of exposed services in order to quickly identify whether nghttpx is used as a front end for critical applications.

In practice, the priority is clear: immediately update the affected Ubuntu packages, restart services exposing nghttpx, then check logs and availability. If the update must be scheduled, reduce the attack surface without delay by filtering unnecessary uses of Upgrade and limiting network exposure. To go further on hardening front ends, proxies, and exposed web services, also see the recommendations in the /categorie/pratiques category.