Описание
The HTTP/2 server can refund connection-level flow control twice for the same data: Once when a client resets a stream (refunding data for any sent-but-unread portion of the stream), and again when a request handler reads the buffered data. A malicious client can exploit this to bypass the configured connection-level flow control limit (MaxReceiveBufferPerConnection). Total buffered data is still limited by the concurrent stream limit and stream-level flow control.
A flaw was found in Go's HTTP/2 server implementation. A remote attacker can bypass connection-level flow control limits—mechanisms that regulate incoming network data—potentially causing excessive memory consumption and a Denial of Service (DoS). This issue occurs because the server improperly refunds flow control credits twice for the same data: once when a client resets a stream, and again when the application reads the buffered data. Consequently, a malicious client can exceed configured connection buffer limits.
Отчет
Red Hat has evaluated this vulnerability as having a Moderate security impact because, while remote unauthenticated clients can bypass configured connection receive buffer thresholds on affected HTTP/2 servers, overall resource exhaustion remains bounded. Exploitation is constrained by stream-level flow controls and limits on concurrent streams, which prevents an attacker from causing unbounded memory consumption or a complete denial of service. Go-based network services handling untrusted HTTP/2 traffic may experience elevated memory usage under sustained reset attacks, but typical deployments remain operational without catastrophic service disruption.
Меры по смягчению последствий
Mitigation for this issue is either not available or the currently available options do not meet the Red Hat Product Security criteria comprising ease of use and deployment, applicability to widespread installation base, or stability.
Затронутые пакеты
| Платформа | Пакет | Состояние | Рекомендация | Релиз |
|---|---|---|---|---|
| OpenShift Developer Tools and Services | helm | Out of support scope | ||
| OpenShift Pipelines | openshift-pipelines-client | Fix deferred | ||
| OpenShift Serverless | kn-workflow-plugin | Fix deferred | ||
| OpenShift Serverless | openshift-serverless-clients | Fix deferred | ||
| OpenShift Service Mesh 3 | istio-proxy | Fix deferred | ||
| OpenShift Service Mesh 3 | openshift-golang-builder-container | Affected | ||
| Red Hat Ansible Automation Platform 2 | automation-gateway-proxy | Fix deferred | ||
| Red Hat Ansible Automation Platform 2 | automation-gateway-proxy-openssl30 | Out of support scope | ||
| Red Hat Ansible Automation Platform 2 | automation-gateway-proxy-openssl32 | Out of support scope | ||
| Red Hat Ansible Automation Platform 2 | receptor | Fix deferred |
Показывать по
Ссылки на источники
Дополнительная информация
Статус:
EPSS
5.3 Medium
CVSS3
Связанные уязвимости
The HTTP/2 server can refund connection-level flow control twice for the same data: Once when a client resets a stream (refunding data for any sent-but-unread portion of the stream), and again when a request handler reads the buffered data. A malicious client can exploit this to bypass the configured connection-level flow control limit (MaxReceiveBufferPerConnection). Total buffered data is still limited by the concurrent stream limit and stream-level flow control.
The HTTP/2 server can refund connection-level flow control twice for the same data: Once when a client resets a stream (refunding data for any sent-but-unread portion of the stream), and again when a request handler reads the buffered data. A malicious client can exploit this to bypass the configured connection-level flow control limit (MaxReceiveBufferPerConnection). Total buffered data is still limited by the concurrent stream limit and stream-level flow control.
Double flow control refund on HTTP/2 server streams in net/http
The HTTP/2 server can refund connection-level flow control twice for t ...
EPSS
5.3 Medium
CVSS3