Description

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.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "6.5",
  "pubDate": "2026-09-11T22:16:37.950Z",
  "pubdate": "2026-09-11T22:16:37.950Z",
  "executiveSummary": "Hoverfly versions prior to 1.12.8 are susceptible to a Denial of Service (DoS) vulnerability caused by improper configuration of HTTP client timeouts during remote post-serve actions.\nThe vulnerability arises from the use of 'http.DefaultClient', which lacks an explicit timeout, allowing external entities to manipulate resource allocation.\nAn unauthenticated attacker can trigger a process crash (OOM kill) by sending requests that utilize a malicious or non-responsive remote post-serve endpoint.\nBy intentionally inducing indefinitely blocking goroutines, an attacker can exhaust system memory through unbounded goroutine accumulation.\nThe exploitation requires no binary execution capabilities, only the ability to configure or influence a URL pointing to a controlled, unresponsive endpoint.\nThis represents a significant availability risk for services relying on Hoverfly for API simulation, as the process can be rendered unresponsive by a low-effort attack vector.\nThe vulnerability is resolved in version 1.12.8, which mandates the implementation of appropriate timeout configurations for remote requests.",
  "technicalDetails": "The root cause of this vulnerability lies in the implementation of remote post-serve actions within Hoverfly, which utilizes the Go standard library's 'http.DefaultClient'. In Go, 'http.DefaultClient' provides a default 'http.Client' instance with no defined timeout value, meaning requests initiated via this client will block indefinitely until the underlying TCP connection or server response times out at the OS level, or forever if the connection is never closed.\nThe exploitation process is triggered when a user or attacker configures a post-serve action to target a URL under their control. When Hoverfly processes a proxy request that triggers this post-serve action, it spawns a new goroutine to execute the network call. Because the 'http.DefaultClient.Do()' method lacks a configured deadline or timeout, any endpoint that performs a 'tarpit' style attack—accepting a TCP handshake but subsequently ceasing all packet transmission or holding the connection open without sending response data—will cause the goroutine to hang.\nBecause each proxy request triggers this blocking behavior independently, a stream of concurrent requests to the affected post-serve configuration leads to the accumulation of an unbounded number of goroutines. Each active goroutine consumes stack memory and system resources. In a resource-constrained environment, this rapid accumulation triggers an Out-Of-Memory (OOM) condition, resulting in the kernel invoking the OOM killer to terminate the Hoverfly process to preserve system stability.\nUnlike local post-serve execution, which may involve binary execution and higher security barriers, this vulnerability is strictly network-based. No authentication is required to submit a proxy request, provided the attacker can influence the Hoverfly configuration or target existing hooks. The network exposure is broad, as the attacker simply needs the ability to trigger the proxy functionality against an endpoint they control.\nThe post-exploitation impact is a total loss of service availability. Once the memory ceiling is reached and the process is killed, Hoverfly ceases to function as an API simulation server, disrupting all downstream dependencies or development workflows relying on it. The vulnerability is effectively patched in version 1.12.8, where the application logic has been updated to move away from 'http.DefaultClient' in favor of a custom 'http.Client' configuration that includes strictly enforced timeouts, preventing goroutine saturation."
}