CVE-2026-50013 in Hoverfly
Summary
by MITRE • 09/11/2026
Hoverfly is an open source API simulation tool. Prior to version 1.12.8, when Hoverfly is running in Diff mode, the `AddDiff()` function writes to the shared `responsesDiff` map without any synchronization (no mutex). When multiple proxy requests are processed concurrently (the normal case for any proxy), the concurrent map writes trigger Go's built-in race detector which causes a `fatal error: concurrent map read and map write`, immediately killing the entire Hoverfly process. This is trivially exploitable by sending multiple simultaneous requests. Version 1.12.8 patches the issue.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 09/12/2026
Hoverfly serves as an open-source API simulation tool designed to facilitate testing and development by mimicking external service behaviors. In its operational lifecycle, particularly when deployed in Diff mode for comparing actual versus expected responses, the application relies on internal data structures to manage state across concurrent proxy requests. Prior to version 1.12.8, a critical concurrency flaw existed within the `AddDiff()` function responsible for recording discrepancies between simulated and real API calls. This specific component attempted to write to a shared map object named `responsesDiff` without implementing any form of synchronization mechanism, such as mutex locks or atomic operations. In Go programming language environments, maps are not safe for concurrent access by multiple goroutines unless explicitly protected against race conditions.
The technical flaw stems from the lack of mutual exclusion when accessing the shared state during high-concurrency scenarios. When Hoverfly operates in its typical capacity as a proxy handling multiple simultaneous requests, each request may trigger logic that updates the `responsesDiff` map. Without synchronization primitives to serialize access to this resource, two or more goroutines can attempt to read and write to the same memory locations simultaneously. This race condition triggers Go's built-in runtime panic mechanism, resulting in a fatal error indicating concurrent map read and map write operations. The immediate consequence of this vulnerability is the abrupt termination of the entire Hoverfly process due to an unrecoverable runtime exception.
From an operational impact perspective, this vulnerability effectively renders the service unavailable under normal load conditions that involve parallel request processing. Since proxy tools are inherently designed to handle multiple concurrent connections, triggering a race condition through simultaneous requests is trivial and does not require complex exploitation techniques or authentication bypasses. An attacker or even automated testing scripts sending rapid successive requests can cause denial of service by crashing the application repeatedly. This instability undermines the reliability of Hoverfly in continuous integration pipelines or load-testing environments where consistent uptime and state management are critical for accurate simulation results.
This vulnerability aligns with CWE-362, which describes concurrent execution using shared resources with improper synchronization. It also relates to ATT&CK technique T1499, Endpoint Denial of Service, as the exploitation leads to service unavailability through resource exhaustion via crash induction rather than traditional resource consumption attacks like memory leaks or CPU spikes. The absence of proper locking mechanisms represents a fundamental violation of safe concurrency practices in multi-threaded applications.
To mitigate this issue, organizations must ensure that Hoverfly is upgraded to version 1.12.8 or later, where the developers have implemented appropriate synchronization controls around the shared map access. For environments unable to upgrade immediately, deploying the proxy behind a reverse proxy with rate limiting can reduce the likelihood of concurrent requests hitting the vulnerable code path simultaneously, though this does not eliminate the underlying flaw. Long-term remediation should include integrating static analysis tools that detect race conditions in Go projects and enforcing strict concurrency guidelines during development to prevent similar synchronization errors in future releases.