Advisories for Golang/Github.com/Spectolabs/Hoverfly package

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.

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.

Hoverfly’s admin WebSocket endpoint /api/v2/ws/logs is not protected by the same authentication middleware that guards the REST admin API. Consequently, an unauthenticated remote attacker can: Stream real-time application logs (information disclosure). Gain insight into internal file paths, request/response bodies, and other potentially sensitive data emitted in logs.

It has been discovered that the middleware functionality in Hoverfly is vulnerable to command injection through its /api/v2/hoverfly/middleware endpoint due to insufficient validation and sanitization in user input.

This issue may lead to Information Disclosure.