CVE-2026-82026 in Radar
Summary
by MITRE • 10/14/2026
Radar before 1.12.2 contains a missing authorization vulnerability in the handleLocalTerminal WebSocket endpoint (/api/local-terminal) that allows authenticated or unauthenticated attackers to spawn a privileged shell by relying only on a runtime-mode check instead of role-based access control. Attackers can connect to the endpoint to execute /bin/bash -l on the Radar host with Radar's own kubeconfig and process credentials injected into the shell environment, achieving remote code execution with Radar's privileges even when the --disable-local-terminal flag is set.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 10/14/2026
The vulnerability identified in Radar versions prior to 1.12.2 represents a critical failure in access control mechanisms within its WebSocket-based local terminal interface. Specifically, the handleLocalTerminal endpoint located at /api/local-terminal suffers from a missing authorization flaw that permits unauthorized or insufficiently privileged users to execute commands with elevated privileges on the host system. This issue stems from an architectural decision where security enforcement relies predominantly on verifying whether the application is running in runtime mode rather than implementing robust role-based access control checks. Consequently, any user capable of establishing a WebSocket connection to this endpoint can bypass intended restrictions and interact directly with the underlying operating system shell.
From a technical perspective, the core deficiency lies in the authentication logic governing the terminal session initialization. Instead of validating that the connecting entity possesses specific administrative roles or permissions required for local terminal access, the application merely checks if the service is active. This oversight allows attackers to exploit the endpoint regardless of their actual user privileges within the Radar platform. By leveraging this gap, an attacker can spawn a privileged shell environment on the host machine running Radar. The severity of this flaw is significantly amplified by the fact that it remains exploitable even when the --disable-local-terminal configuration flag is enabled, indicating that the runtime mode check overrides or ignores administrative safeguards designed to restrict such access paths.
The operational impact of this vulnerability is severe, as it effectively grants remote code execution capabilities with the full privileges of the Radar process. Upon successful exploitation, attackers gain access to a shell environment where critical credentials are automatically injected into the session context. These include the kubeconfig file and other process-specific credentials necessary for interacting with Kubernetes clusters managed by or integrated with Radar. This exposure allows adversaries not only to execute arbitrary commands on the host but also to pivot further into associated containerized environments, potentially leading to complete compromise of the infrastructure. The ability to bypass security flags suggests a fundamental design flaw that undermines trust in configuration-based restrictions.
This vulnerability aligns closely with CWE-285 Improper Authorization and CVE classification patterns for broken access control issues where authentication checks are insufficient or incorrectly implemented. In terms of threat modeling, this behavior corresponds to ATT&CK techniques involving Command and Scripting Interpreter execution as well as Credential Access through harvesting credentials from local system processes. The exploitation path demonstrates how improper validation of user roles can lead to privilege escalation scenarios that bypass explicit security configurations.
To mitigate this risk, organizations running Radar versions earlier than 1.12.2 should upgrade immediately to the patched version which addresses these authorization checks by enforcing strict role-based access control on the local terminal endpoint. Until an upgrade is feasible, administrators should consider network-level restrictions such as firewall rules or reverse proxy configurations that limit access to the /api/local-terminal WebSocket path exclusively to trusted internal sources if possible. Additionally, auditing logs for unusual WebSocket connections and monitoring for unexpected shell activity can help detect potential exploitation attempts in real-time. It is also advisable to review other endpoints within the application to ensure similar authorization gaps do not exist elsewhere in the codebase.