Description

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.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "7.5",
  "pubDate": "2026-09-11T22:16:37.813Z",
  "pubdate": "2026-09-11T22:16:37.813Z",
  "executiveSummary": "The Hoverfly API simulation tool contains a critical concurrency vulnerability stemming from improper synchronization when handling shared data structures in Diff mode.\nThe vulnerability is classified as a race condition leading to a fatal runtime exception, which causes an immediate service disruption.\nAffected versions prior to 1.12.8 are susceptible to this flaw, which allows unauthenticated remote attackers to trigger a denial-of-service (DoS) state.\nBy sending multiple concurrent requests to the Hoverfly proxy while operating in Diff mode, an attacker can force a fatal error due to unsynchronized map writes.\nBecause the Go runtime detects concurrent map access and terminates the process to prevent memory corruption, the impact is a complete loss of service availability for the proxy instance.\nNo special privileges are required to exploit this vulnerability, as it is triggered by standard protocol interactions that the application is designed to process, making it a highly trivial yet effective vector for service exhaustion.",
  "technicalDetails": "The vulnerability resides within the AddDiff() function of the Hoverfly API simulation component. In Go, maps are not safe for concurrent use by default; modifications to a map structure during concurrent read or write operations must be protected by synchronization primitives, such as sync.Mutex or sync.RWMutex.\nIn the vulnerable versions prior to 1.12.8, the AddDiff() function performs write operations on the shared responsesDiff map without any locking mechanism. When the Hoverfly proxy is configured to run in Diff mode, it is expected to handle high volumes of concurrent requests. Under these operational conditions, multiple goroutines attempt to modify the responsesDiff map simultaneously.\nThe exploitation flow is straightforward: an attacker identifies an instance of Hoverfly operating in Diff mode. The attacker then initiates multiple simultaneous HTTP requests directed at the proxy. As the proxy processes these requests, the Go runtime environment encounters a concurrent map read and map write scenario. The Go runtime's race detector identifies this prohibited memory access pattern and issues a 'fatal error: concurrent map read and map write'.\nThis fatal error is designed by the language runtime to prevent non-deterministic behavior and potential memory corruption. Consequently, the entire Hoverfly process is terminated immediately. Because this occurs at the runtime level, there is no way for the application to catch or recover from the panic, resulting in an unrecoverable crash.\nThe vulnerability is inherent to the lack of thread-safe access to the shared resource. Since the proxy is designed to be a network-facing utility, it is exposed to arbitrary remote requests, fulfilling the requirements for remote exploitation. No authentication or elevated privileges are necessary, as the crash is triggered by the standard logic flow intended to record differences during simulation. The post-exploitation impact is a denial-of-service, rendering the API simulation tool unresponsive and requiring manual intervention or process monitoring to restart the service, which may then be immediately re-exploited."
}