CVE-2026-82641 in Keploy
Summary
by MITRE • 08/30/2026
keploy versions 3.1.0 through 3.6.25 bind the agent control-plane HTTP server to all interfaces without authentication, exposing endpoints that stream TLS session keys and traffic data. Attackers can access the /agent/pcap/keylog endpoint to retrieve NSS keylog lines and decrypt recorded TLS traffic, or invoke /agent/stop and /agent/storemocks to manipulate recording sessions.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 08/30/2026
The vulnerability identified in Keploy versions 3.1.0 through 3.6.25 represents a critical misconfiguration of the agent control-plane HTTP server that results in unauthorized access to sensitive telemetry data and system controls. The core technical flaw lies in the binding mechanism of the HTTP server, which is configured by default to listen on all network interfaces without implementing any form of authentication or authorization checks. This architectural decision exposes internal management endpoints to any entity capable of reaching the host machine over the network, effectively treating administrative functions as public resources. In a typical deployment scenario where Keploy agents are installed across multiple hosts within an enterprise environment, this lack of binding restriction means that if one agent is compromised or accessible via lateral movement, the entire control plane for recording and mocking operations becomes exposed to potential adversaries.
The operational impact of this vulnerability is severe due to the nature of the data streamed through these unauthenticated endpoints. Specifically, the /agent/pcap/keylog endpoint serves as a critical attack vector by providing access to NSS keylog lines. These logs contain the master secrets used for TLS encryption sessions recorded during testing or production monitoring. By retrieving these keys, an attacker can perform passive decryption of all captured network traffic associated with those sessions using standard tools like Wireshark. This capability effectively nullifies the confidentiality guarantees provided by Transport Layer Security, allowing the exfiltration of plaintext credentials, session tokens, and sensitive business logic embedded in API requests or responses that were previously encrypted at rest within packet captures.
Beyond data exposure, the vulnerability also permits active manipulation of the testing infrastructure through endpoints such as /agent/stop and /agent/storemocks. The ability to invoke these commands allows an attacker to abruptly terminate recording sessions, leading to a denial of service for development teams relying on accurate traffic capture for regression testing or debugging. Furthermore, the capability to store mocks enables an adversary to inject fake responses into the system's mock database. This can lead to data integrity issues where subsequent test runs utilize manipulated response data rather than genuine application behavior, potentially masking bugs in production code or causing failures when those flawed mocks are inadvertently deployed. Such manipulation undermines the reliability of automated testing pipelines and CI/CD processes that depend on Keploy for consistent environment simulation.
From a classification perspective, this vulnerability aligns with CWE-284 Improper Access Control, as it involves unauthorized access to functional components due to insufficient restrictions on information retrieval or resource consumption. It also maps directly to MITRE ATT&CK technique T1506 Post-exploitation: Capture Client Credentials, specifically the sub-technique of capturing TLS session keys for decryption purposes. The exposure of management interfaces without authentication is a common pattern in development and testing tools that are often mistakenly deployed with default configurations intended only for local loopback access.
Mitigation strategies must prioritize immediate network segmentation and configuration hardening. Organizations should restrict access to the Keploy agent ports using firewall rules or security groups, ensuring that these services are bound exclusively to localhost (127.0.0.1) unless remote management is explicitly required and secured via mutual TLS or token-based authentication mechanisms provided by newer versions of the software. Upgrading to a patched version where default binding addresses are restricted to local interfaces is essential for long-term remediation. Additionally, security teams should audit their CI/CD pipelines and development environments to ensure that no other services with similar misconfigurations exist, as this pattern often indicates broader gaps in infrastructure-as-code security policies regarding the exposure of internal management APIs.