GHSA-qrh4-p6v4-mrfg

Summary:

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.

Details:

1. Unsynchronized map access in AddDiff() (core/hoverfly_service.go:417-421):

func (hf *Hoverfly) AddDiff(requestView v2.SimpleRequestDefinitionView, diffReport v2.DiffReport) {
    if len(diffReport.DiffEntries) > 0 {
        diffs := hf.responsesDiff[requestView]                    // UNSYNCHRONIZED READ
        hf.responsesDiff[requestView] = append(diffs, diffReport) // UNSYNCHRONIZED WRITE
    }
}

2. This function is called from Diff mode processing, which runs concurrently per request (core/modes/diff_mode.go):

Each incoming proxy request is handled in its own goroutine by Go's net/http server. In Diff mode, each request calls AddDiff() after comparing the simulated and actual responses. With multiple concurrent requests, multiple goroutines write to the same map simultaneously.

3. Go's runtime detects concurrent map access and terminates the process:

Unlike data races on simple values (which produce undefined behavior silently), Go's map implementation includes a built-in concurrent access check. When two goroutines access the same map and at least one is writing, the runtime calls fatal() which is unrecoverable, it cannot be caught by recover().

4. No mutex protection exists on responsesDiff:

The field is declared as a plain map[v2.SimpleRequestDefinitionView][]v2.DiffReport with no associated sync.RWMutex. Compare with hf.state which properly uses sync.RWMutex for its map access.

Environment:...