CVE-2026-111617 in WHartTest
Summary
by MITRE • 10/16/2026
WHartTest through 2.8.1 contains a missing authentication vulnerability that allows unauthenticated attackers to connect to the /ws/ui/web/ and /ws/ui/actuator/ WebSocket endpoints because UiAutomationConsumer accepts every connection. Attackers can register an actuator with a client-supplied id to intercept other users' test-case payloads, receive broadcast step results, and spoof results and screen frames into victim sessions.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 10/16/2026
The vulnerability identified in WHartTest versions through 2.8.1 represents a critical failure in access control mechanisms within the application's WebSocket infrastructure. Specifically, the UiAutomationConsumer component fails to enforce authentication requirements for incoming connections targeting the /ws/ui/web/ and /ws/ui/actuator/ endpoints. This architectural flaw allows any network actor, without valid credentials or session tokens, to establish persistent communication channels with the server. By accepting every connection indiscriminately, the application exposes sensitive operational interfaces that are intended to be restricted to authorized administrators or active test participants. The absence of a handshake verification process means that the integrity and confidentiality of real-time data streams are completely compromised from the moment a TCP connection is established.
The technical exploitation of this flaw enables attackers to register an actuator using a client-supplied identifier, effectively hijacking the identity context within the WebSocket session management logic. Once registered, the attacker gains the ability to intercept test-case payloads intended for other legitimate users. This interception capability allows for deep inspection of data in transit, potentially revealing sensitive business logic or proprietary testing methodologies. Furthermore, because the system broadcasts step results and screen frames to connected clients, an unauthenticated actor can inject maliciously crafted responses into these streams. By spoofing results and manipulating screen frame data, the attacker can deceive victims into believing that specific test steps have passed when they may have failed, or vice versa, thereby corrupting the integrity of automated testing workflows.
The operational impact of this vulnerability is severe, particularly in environments where WHartTest is used for continuous integration pipelines or quality assurance processes involving sensitive intellectual property. The ability to spoof results undermines trust in the test outcomes, potentially leading to the deployment of defective software if false positives are accepted as valid pass criteria. Additionally, the interception of payloads poses a significant data exfiltration risk, allowing attackers to harvest configuration details, user interactions, and application state information. This scenario aligns with CWE-306, which describes missing authentication for critical function, and maps directly to MITRE ATT&CK technique T1592, involving gathering victim host information through active reconnaissance of exposed services. The manipulation of broadcast data also relates to CWE-841, improper enforcement of behavioral restrictions, as the system fails to validate that the sender is authorized to modify or inject state changes into existing sessions.
Mitigation strategies must prioritize immediate remediation by upgrading WHartTest to a version where this authentication gap has been addressed. In the interim, network-level controls should be implemented to restrict access to WebSocket endpoints only from trusted IP ranges or internal subnets that do not expose these services directly to untrusted networks. Implementing mutual TLS (mTLS) for WebSocket connections can provide an additional layer of verification by requiring client certificates before accepting any data exchange. Application-layer fixes must ensure that the UiAutomationConsumer strictly validates authentication tokens and session identifiers upon connection initiation, rejecting all requests from unauthenticated sources. Regular security audits focusing on real-time communication channels are recommended to detect similar misconfigurations in other parts of the application architecture.