CVE-2026-50018 Overview
CVE-2026-50018 affects Hoverfly, an open source API simulation tool used for service virtualization and testing. Versions prior to 1.12.8 issue remote post-serve action requests using Go's http.DefaultClient without configuring any timeout. When a remote endpoint accepts the TCP connection but never responds, each triggered proxy request spawns a goroutine that blocks indefinitely on http.DefaultClient.Do(). Continuous proxy traffic causes unbounded goroutine accumulation, memory exhaustion, and eventual out-of-memory (OOM) termination of the Hoverfly process. The issue is classified under [CWE-400: Uncontrolled Resource Consumption]. Version 1.12.8 remediates the flaw.
Critical Impact
An attacker who can influence the remote post-serve action URL can crash the Hoverfly process through goroutine leakage and memory exhaustion, disrupting all simulated API services.
Affected Products
- Hoverfly versions prior to 1.12.8
- Deployments configured with remote post-serve actions
- Environments relying on Hoverfly for API simulation and service virtualization
Discovery Timeline
- 2026-09-11 - CVE-2026-50018 published to NVD
- 2026-09-14 - Last updated in NVD database
Technical Details for CVE-2026-50018
Vulnerability Analysis
Hoverfly supports post-serve actions, which are callbacks executed after a proxied request completes. Remote post-serve actions send an HTTP request to a configured URL. The implementation used Go's package-level http.DefaultClient, which has no default timeout for connection establishment, response headers, or body reads.
When the remote endpoint completes the TCP handshake but never returns response data (a slowloris-style condition), the calling goroutine blocks in http.DefaultClient.Do() indefinitely. Because Hoverfly spawns a new goroutine per triggered action, sustained proxy traffic causes the goroutine count and associated memory allocations to grow without bound until the operating system OOM-kills the process.
Unlike local post-serve action execution, exploitation does not require the ability to execute a binary on the host. It requires only a reachable URL that fails to respond, which broadens the attack surface significantly.
Root Cause
The root cause is missing timeout configuration on the HTTP client used for remote post-serve callbacks. http.DefaultClient in Go has Timeout: 0, meaning no upper bound on request duration. Combined with per-request goroutine dispatch and no concurrency limiter, this yields an uncontrolled resource consumption pattern.
Attack Vector
An attacker configures or influences the remote post-serve action URL to point at an endpoint they control that accepts TCP connections but never sends an HTTP response. Any proxy traffic through Hoverfly that triggers the action then leaks a goroutine. Repeated requests drive memory usage until the process crashes. See the GitHub Security Advisory GHSA-42j2-w334-qxw7 for additional details.
No verified exploit code is published. The vulnerability mechanism is described in the vendor advisory and the corresponding GitHub Pull Request.
Detection Methods for CVE-2026-50018
Indicators of Compromise
- Sustained growth in the Hoverfly process resident set size (RSS) that does not plateau under steady request load.
- Rapidly increasing goroutine counts visible via Go runtime metrics or pprof endpoints.
- Repeated OOM-kill events for the Hoverfly process in kernel logs (dmesg, journalctl).
- Outbound TCP connections from Hoverfly to a post-serve action endpoint that remain in ESTABLISHED state with no data returned.
Detection Strategies
- Inventory all Hoverfly deployments and identify instances running versions prior to 1.12.8.
- Review Hoverfly configuration for remote post-serve action URLs and validate that endpoints are trusted and responsive.
- Instrument Hoverfly with runtime profiling (/debug/pprof/goroutine) to alert on abnormal goroutine growth.
Monitoring Recommendations
- Alert on Hoverfly memory usage exceeding a defined baseline threshold for sustained periods.
- Monitor for long-lived outbound connections from Hoverfly hosts where no bytes are received.
- Track process restart frequency and correlate with OOM events reported by the kernel.
How to Mitigate CVE-2026-50018
Immediate Actions Required
- Upgrade Hoverfly to version 1.12.8 or later, which sets an explicit timeout on the remote post-serve HTTP client.
- Audit all configured remote post-serve action URLs and remove any that reference untrusted or unreachable endpoints.
- Restrict egress network traffic from Hoverfly hosts to a known allowlist of post-serve callback destinations.
Patch Information
The fix is available in Hoverfly release v1.12.8. The change, implemented in pull request #1228, replaces http.DefaultClient with a dedicated http.Client instance that enforces a request timeout, preventing indefinite blocking on unresponsive endpoints.
Workarounds
- Disable remote post-serve actions if the feature is not required for the deployment.
- Place a network egress proxy in front of Hoverfly that enforces connection and response timeouts on outbound HTTP requests.
- Run Hoverfly under a process supervisor with memory limits and automated restart to reduce the impact of OOM termination while patching is scheduled.
# Upgrade Hoverfly to the patched version
# Verify installed version
hoverfly -version
# Pull the patched container image
docker pull spectolabs/hoverfly:v1.12.8
# Or download the release binary from GitHub
# https://github.com/SpectoLabs/hoverfly/releases/tag/v1.12.8
Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.
