CVE-2024-45388

What it actually does

CVE-2024-45388 is an information disclosure flaw in spectolabs/hoverfly that can allow a network-accessible attacker to obtain data that should not be exposed. Hoverfly is commonly used as a service virtualization and proxy tool, so disclosed data may include captured HTTP requests and responses, simulation payloads, headers, tokens, cookies, API keys, internal service URLs, or other sensitive test and integration traffic depending on how the instance is used. The CVSS 7.5 rating and weaponized exploit maturity indicate a remotely exploitable confidentiality issue with practical exploitation value when Hoverfly is reachable by untrusted users or networks.

Why it matters to the business

Successful exploitation can expose credentials, session material, API payloads, customer-like test data, internal endpoint details, and integration secrets processed or stored by Hoverfly. This can lead to follow-on compromise of upstream or downstream services, leakage of confidential business data, regulatory exposure, and loss of trust. Although it is not currently listed in CISA KEV and is not marked as ransomware-associated, the high EPSS score of 0.5585 and weaponized status make internet-exposed or broadly reachable Hoverfly deployments a high-priority remediation target.

How an attack unfolds

An attacker first identifies a running Hoverfly instance, commonly by scanning for exposed Hoverfly proxy or administration services. If the vulnerable version is reachable, the attacker sends crafted or unauthenticated requests that trigger the information disclosure condition. The attacker then retrieves sensitive Hoverfly-held data such as captured request journals, simulations, headers, response bodies, configuration details, or internal service metadata, depending on the deployment and data present. The stolen data may be reviewed for credentials, bearer tokens, cookies, API keys, internal hostnames, and business logic details. Those findings can then be used for credential replay, targeted access to internal APIs, phishing, lateral movement, or additional attacks against services whose traffic was captured by Hoverfly.

How to fix it

Upgrade spectolabs/hoverfly to a build that includes commit 158a75d992b2d3d26b4e5417b331d12d9be2d6af or a later official release containing that fix. Rebuild and redeploy all Hoverfly binaries, containers, CI images, developer toolchains, and test environments that may include older builds. If immediate upgrade is not possible, restrict Hoverfly management and proxy interfaces to trusted networks only, place them behind authenticated access controls, disable public exposure, block access from untrusted source ranges, and avoid storing sensitive traffic in simulations or journals. Rotate any credentials, API keys, tokens, cookies, or certificates that may have passed through vulnerable Hoverfly instances. Remove unnecessary captured traffic and simulation artifacts that contain sensitive data.

How to confirm the fix worked

Confirm the deployed Hoverfly binary or container image was built from commit 158a75d992b2d3d26b4e5417b331d12d9be2d6af or a later fixed release. Inventory running instances, container images, CI/CD images, developer workstations, and test infrastructure for spectolabs/hoverfly. From an untrusted network position, verify that Hoverfly administration and proxy interfaces are not reachable unless explicitly intended and protected. Review reverse proxy, firewall, and service mesh policy to ensure only authorized users and systems can access Hoverfly. Perform a controlled benign access test against sensitive Hoverfly API surfaces and confirm unauthenticated users cannot retrieve journals, simulations, captured traffic, configuration, or other sensitive data. Validate that secrets formerly present in Hoverfly captures have been rotated or invalidated.

Typical attack path

1. Discover exposed Hoverfly services through internet scanning, internal reconnaissance, container metadata, repository references, or known default ports.
2. Fingerprint the service as Hoverfly using HTTP banners, API behavior, default paths, or response content.
3. Send requests to vulnerable Hoverfly interfaces that cause unintended disclosure of stored or proxied data.
4. Download exposed journals, simulations, request/response bodies, headers, or configuration-like data.
5. Search the disclosed data for secrets, tokens, cookies, API keys, internal URLs, and sensitive payloads.
6. Use recovered secrets or endpoint knowledge to access other services or plan follow-on attacks.

How to detect it

Investigate whether Hoverfly services were reachable by untrusted networks before remediation. Review application logs, container stdout/stderr, reverse proxy logs, load balancer logs, web access logs, firewall logs, WAF logs, service mesh telemetry, EDR network telemetry, and cloud flow logs for inbound access to Hoverfly proxy or administration interfaces. Pay particular attention to requests for API, journal, simulation, capture, export, or configuration-related endpoints; large successful HTTP 200 responses; repeated enumeration of API paths; requests from internet scanners; and automated tooling user agents such as curl, wget, Python requests, Go-http-client, masscan, zgrab, or nuclei. Compare source IPs against expected developer, CI/CD, and test automation ranges. Inspect Hoverfly working directories, simulation files, and journal artifacts for access times or modifications that align with suspicious requests. If sensitive headers or payloads were stored, search for subsequent authentication attempts using exposed tokens or credentials against related systems. Because the flaw is an information disclosure issue, exploitation may leave only normal-looking read requests, so absence of a crash or error does not rule out compromise.

• GET /api/v2/simulation
• GET /api/v2/journal
• GET /api/v2/hoverfly
• GET /api/v2/configuration
• GET /api/v2/destination
• GET /api/v2/captures
• POST /api/v2/simulation
• POST /api/v2/journal
• /api/v2/simulation
• /api/v2/journal
• /api/v2/hoverfly
• /api/v2/configuration
• /api/v2/destination
• /api/v2/captures
• User-Agent: curl
• User-Agent: Wget
• User-Agent: python-requests
• User-Agent: Go-http-client
• User-Agent: masscan
• User-Agent: zgrab
• User-Agent: nuclei
• hoverfly
• hoverctl
• hoverfly.db
• simulation.json

What your security team should do

• Prioritize remediation for any Hoverfly instance exposed to the internet, shared developer networks, CI/CD infrastructure, or untrusted users because exploitation is weaponized and EPSS is high.
• Upgrade all spectolabs/hoverfly deployments to a fixed build containing commit 158a75d992b2d3d26b4e5417b331d12d9be2d6af or later.
• Restrict Hoverfly administration and proxy ports using firewall rules, security groups, service mesh policy, VPN-only access, or reverse proxy authentication.
• Search stored Hoverfly simulations, journals, and logs for credentials, tokens, cookies, API keys, and sensitive request or response payloads; rotate anything exposed.
• Review access logs for suspicious requests to Hoverfly API, simulation, journal, capture, or export functionality, especially from unfamiliar IP addresses or automated user agents.
• Remove stale Hoverfly captures and simulations that are no longer operationally required, particularly those containing production-like data.
• Add Hoverfly exposure checks to asset discovery, container image scanning, CI/CD dependency review, and external attack surface management.
• Treat any confirmed unauthorized access as a data exposure incident and perform downstream credential replay and access review.