Описание
undici's retry handler can leave an already-exposed response body pending forever. When a server returns a successful response that declares a Content-Length, sends only part of the body, and closes the connection, the retry handler retries the request. If the retry returns a non-retryable status such as 400, the handler forwards that new response downstream and replaces its internal response stream, but the original response body that the application still holds is never ended or destroyed. As a result calls that read that body never settle, and the configured body timeout does not fire because its timer is tied to the connection parser rather than the orphaned body. An attacker-controlled server can trigger this with two short responses without keeping a connection open, and repeated requests accumulate pending promises and streams that can exhaust application concurrency or memory. This affects undici versions from 7.11.0 up to 7.29.1 and from 8.0.0 up to 8.10.2. Users should upgrade to undici 7.29.1 or 8.10.2.
A flaw was found in undici. A remote attacker, by controlling a server, could exploit a vulnerability in undici's retry handler. When a server sends an incomplete response body and then a non-retryable status, the original response body can become orphaned and never properly closed. This leads to pending promises and streams accumulating, which can exhaust application resources and result in a Denial of Service (DoS).
Отчет
An attacker-controlled server can trigger a denial of service in applications using undici's retry handler. This vulnerability allows for resource exhaustion by leaving response bodies orphaned, which can lead to a degradation of service availability.
Меры по смягчению последствий
Applications utilizing undici should implement an independent request deadline and ensure the response body is explicitly destroyed upon expiration. The bodyTimeout mechanism alone is insufficient to prevent resource exhaustion in this scenario.
Затронутые пакеты
| Платформа | Пакет | Состояние | Рекомендация | Релиз |
|---|---|---|---|---|
| Exploit Intelligence | exploit-intelligence/vulnerability-analysis-rhel9 | Not affected | ||
| OpenShift Pipelines | openshift-pipelines/pipelines-console-plugin-pf5-rhel9 | Fix deferred | ||
| OpenShift Pipelines | openshift-pipelines/pipelines-console-plugin-rhel9 | Fix deferred | ||
| Red Hat AMQ Broker 7 | amq-broker-bin.zip | Not affected | ||
| Red Hat AMQ Broker 7 | amq-broker-maven-repository.zip | Not affected | ||
| Red Hat Ansible Automation Platform 2 | automation-platform-ui | Not affected | ||
| Red Hat Build of Podman Desktop | rh-podman-desktop.git | Fix deferred | ||
| Red Hat Developer Hub | rhdh/red-hat-developer-hub-backstage-plugin-lightspeed-backend | Fix deferred | ||
| Red Hat Developer Hub | rhdh/red-hat-developer-hub-backstage-plugin-orchestrator-backend | Fix deferred | ||
| Red Hat Developer Hub | rhdh/red-hat-developer-hub-backstage-plugin-orchestrator-backend-module-loki | Fix deferred |
Показывать по
Дополнительная информация
Статус:
5.9 Medium
CVSS3
Связанные уязвимости
undici's retry handler can leave an already-exposed response body pending forever. When a server returns a successful response that declares a Content-Length, sends only part of the body, and closes the connection, the retry handler retries the request. If the retry returns a non-retryable status such as 400, the handler forwards that new response downstream and replaces its internal response stream, but the original response body that the application still holds is never ended or destroyed. As a result calls that read that body never settle, and the configured body timeout does not fire because its timer is tied to the connection parser rather than the orphaned body. An attacker-controlled server can trigger this with two short responses without keeping a connection open, and repeated requests accumulate pending promises and streams that can exhaust application concurrency or memory. This affects undici versions from 7.11.0 up to 7.29.1 and from 8.0.0 up to 8.10.2. Users should upg...
undici's retry handler can leave an already-exposed response body pending forever. When a server returns a successful response that declares a Content-Length, sends only part of the body, and closes the connection, the retry handler retries the request. If the retry returns a non-retryable status such as 400, the handler forwards that new response downstream and replaces its internal response stream, but the original response body that the application still holds is never ended or destroyed. As a result calls that read that body never settle, and the configured body timeout does not fire because its timer is tied to the connection parser rather than the orphaned body. An attacker-controlled server can trigger this with two short responses without keeping a connection open, and repeated requests accumulate pending promises and streams that can exhaust application concurrency or memory. This affects undici versions from 7.11.0 up to 7.29.1 and from 8.0.0 up to 8.10.2. Users should upgrad
undici vulnerable to Denial of Service via orphaned RetryHandler response body
undici's retry handler can leave an already-exposed response body pend ...
5.9 Medium
CVSS3