CVE-2026-50018 in Hoverfly
Summary
by MITRE • 09/11/2026
Hoverfly is an open source API simulation tool. Prior to version 1.12.8, remote post-serve actions use `http.DefaultClient` without any timeout configuration. When the remote endpoint is unreachable or intentionally slow (accepts TCP connection but never responds), each triggered proxy request spawns a goroutine that blocks indefinitely on `http.DefaultClient.Do()`. An attacker can cause unbounded goroutine accumulation leading to memory exhaustion and process crash (OOM kill). Unlike local post-serve action execution, this requires no binary execution, only a URL pointing to a non-responsive endpoint. Version 1.12.8 patches the issue.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 09/11/2026
Hoverfly is an open-source API simulation tool designed for testing and development purposes by simulating HTTP APIs. In versions prior to 1.12.8, the application contains a critical resource management flaw within its post-serve action mechanism. This feature allows users to configure actions that are triggered after specific proxy requests are served, such as sending notifications or triggering external workflows. The vulnerability arises because these remote post-serve actions utilize Go's default HTTP client without any timeout configuration. When the configured remote endpoint is unreachable or intentionally slow, specifically in scenarios where it accepts TCP connections but never sends a response, each triggered proxy request causes the system to spawn a new goroutine that blocks indefinitely on the http.DefaultClient.Do() call.
This lack of timeout configuration leads directly to unbounded goroutine accumulation within the Hoverfly process. Since HTTP clients typically allocate resources for every active connection and pending request, an attacker who can trigger these post-serve actions against non-responsive endpoints will cause a steady increase in memory consumption as more goroutines are created but never completed or garbage collected. This behavior constitutes a classic resource exhaustion vulnerability that degrades system performance over time. Eventually, the continuous allocation of memory for blocked goroutines leads to severe memory pressure on the host machine.
The operational impact of this flaw is significant, particularly in environments where Hoverfly is used as part of an automated testing pipeline or CI/CD infrastructure. An attacker with the ability to control or influence the proxy traffic can exploit this condition by directing requests toward endpoints that delay responses indefinitely. This results in a Denial of Service (DoS) against the Hoverfly instance itself, causing it to consume excessive memory until it is terminated by the operating system's Out-Of-Memory killer mechanism. The process crash disrupts any dependent testing or simulation workflows, leading to service unavailability and potential data loss if stateful operations were in progress.
From a classification perspective, this vulnerability aligns with CWE-400: Uncontrolled Resource Consumption, as the application fails to limit the amount of resources consumed by an external entity. It also relates to CWE-787: Out-of-bounds Write or CWE-125: Out-of-bounds Read in broader terms of memory safety issues leading to crashes, though specifically it is a resource leak due to blocking I/O operations without timeouts. In the context of the MITRE ATT&CK framework, this exploit technique falls under T1499: Endpoint Denial of Service, as the attacker leverages application logic flaws to exhaust system resources and disrupt service availability rather than exploiting code execution vulnerabilities directly.
The severity of this issue is compounded by its ease of exploitation compared to other attack vectors on similar tools. Unlike local post-serve action executions which might require binary execution privileges or more complex setup, remote actions only require a URL pointing to a non-responsive endpoint. This lowers the barrier for entry significantly, allowing any user with access to configure Hoverfly's simulation rules to trigger this condition remotely without needing shell access or code injection capabilities on the target host.
To mitigate this vulnerability and prevent future occurrences of similar issues, it is imperative that all HTTP client instances used in network-facing applications are configured with explicit timeouts for both dialing connections and reading responses. The patch released in version 1.12.8 addresses this by implementing appropriate timeout configurations within the http.DefaultClient usage or by replacing it with a custom-configured client instance. Organizations using Hoverfly should immediately upgrade to version 1.12.8 or later. Additionally, defensive measures such as setting resource limits at the container or process level can provide an additional layer of protection against unbounded goroutine accumulation in case similar flaws are discovered in other components of the stack.