Summary
Radar contains a missing authorization vulnerability in the /api/local-terminal WebSocket endpoint. An unauthenticated or authenticated attacker may use the endpoint to spawn a privileged shell and execute commands with Radar's process credentials, including its kubeconfig, when the endpoint is reachable.
Radar contains a missing authorization vulnerability in the /api/local-terminal WebSocket endpoint. An unauthenticated or authenticated attacker may use the endpoint to spawn a privileged shell and execute commands with Radar's process credentials, including its kubeconfig, when the endpoint is reachable.
Affected context
The issue occurs in Radar deployments exposing the /api/local-terminal WebSocket endpoint. Risk is present when endpoint access is governed only by a runtime-mode check rather than authenticated, role-based authorization. The local-terminal disable setting may not provide effective protection if the handler does not enforce the setting consistently before creating a shell.
The issue occurs in Radar deployments exposing the /api/local-terminal WebSocket endpoint. Risk is present when endpoint access is governed only by a runtime-mode check rather than authenticated, role-based authorization. The local-terminal disable setting may not provide effective protection if the handler does not enforce the setting consistently before creating a shell.
Exploit preconditions
- Attack surface: The
/api/local-terminalWebSocket endpoint - Required access: Network reachability; the vulnerable behavior may permit unauthenticated access
- Trigger point: A WebSocket connection to the local-terminal handler
- Why exploitation is possible: The handler relies on runtime-mode logic without enforcing an appropriate authorization decision before spawning a shell
- Execution context: The shell inherits Radar's process privileges, environment, and potentially its kubeconfig
- Attack surface: The
/api/local-terminalWebSocket endpoint - Required access: Network reachability; the vulnerable behavior may permit unauthenticated access
- Trigger point: A WebSocket connection to the local-terminal handler
- Why exploitation is possible: The handler relies on runtime-mode logic without enforcing an appropriate authorization decision before spawning a shell
- Execution context: The shell inherits Radar's process privileges, environment, and potentially its kubeconfig
Why this happens
The underlying flaw is an authorization decision that checks whether a runtime mode permits terminal functionality but does not verify whether the requesting principal has the required role or permission. This maps to CWE-862, Missing Authorization, because a sensitive administrative operation is reachable without an effective access-control check. Treating a configuration or operational-mode check as a substitute for per-request authorization creates an insecure pattern for privileged WebSocket actions.
The underlying flaw is an authorization decision that checks whether a runtime mode permits terminal functionality but does not verify whether the requesting principal has the required role or permission. This maps to CWE-862, Missing Authorization, because a sensitive administrative operation is reachable without an effective access-control check. Treating a configuration or operational-mode check as a substitute for per-request authorization creates an insecure pattern for privileged WebSocket actions.
Potential impact
- An attacker may execute arbitrary commands on the Radar host
- An attacker could access data available to Radar's process
- The exposed shell may use Radar's kubeconfig and enable Kubernetes API access
- An attacker may modify workloads, secrets, or cluster resources allowed by those credentials
- The incident could result in data loss, service disruption, or lateral movement
- An attacker may execute arbitrary commands on the Radar host
- An attacker could access data available to Radar's process
- The exposed shell may use Radar's kubeconfig and enable Kubernetes API access
- An attacker may modify workloads, secrets, or cluster resources allowed by those credentials
- The incident could result in data loss, service disruption, or lateral movement
General mitigation guidance
Mitigation generally focuses on enforcing authorization at the sensitive
endpoint and reducing the privileges available to the service.
Common defensive patterns include:
- Require authentication and explicit role- or permission-based authorization before establishing a terminal session
- Enforce authorization independently of runtime-mode checks and configuration flags
- Deny access by default when authorization context is missing, invalid, or ambiguous
- Remove or disable administrative terminal functionality in deployments that do not require it
- Run Radar with a dedicated, least-privileged identity and narrowly scoped Kubernetes permissions
- Avoid injecting unnecessary kubeconfig files, tokens, or process credentials into shell environments
- Apply network policies and gateway controls that limit access to administrative WebSocket endpoints
Mitigation generally focuses on enforcing authorization at the sensitive
endpoint and reducing the privileges available to the service.
Common defensive patterns include:
- Require authentication and explicit role- or permission-based authorization before establishing a terminal session
- Enforce authorization independently of runtime-mode checks and configuration flags
- Deny access by default when authorization context is missing, invalid, or ambiguous
- Remove or disable administrative terminal functionality in deployments that do not require it
- Run Radar with a dedicated, least-privileged identity and narrowly scoped Kubernetes permissions
- Avoid injecting unnecessary kubeconfig files, tokens, or process credentials into shell environments
- Apply network policies and gateway controls that limit access to administrative WebSocket endpoints
How teams detect issues like this
Organizations can look for:
- Static-analysis findings where WebSocket handlers invoke shell or process-spawn APIs without nearby authorization checks
- Code review signals showing runtime flags or mode checks used in place of identity and role validation
- Tests that exercise sensitive endpoints with anonymous, low-privilege, and unauthorized identities
- Access logs showing unexpected WebSocket connections to
/api/local-terminalor shell-session creation - Policy checks requiring authentication, authorization, and least-privilege service identities for administrative endpoints
- Automated security review tools configured to identify missing access-control enforcement on high-impact handlers
Organizations can look for:
- Static-analysis findings where WebSocket handlers invoke shell or process-spawn APIs without nearby authorization checks
- Code review signals showing runtime flags or mode checks used in place of identity and role validation
- Tests that exercise sensitive endpoints with anonymous, low-privilege, and unauthorized identities
- Access logs showing unexpected WebSocket connections to
/api/local-terminalor shell-session creation - Policy checks requiring authentication, authorization, and least-privilege service identities for administrative endpoints
- Automated security review tools configured to identify missing access-control enforcement on high-impact handlers
Sources
| Source | Link |
|---|---|
| github. | github.com/ |
| github. | github.com/ |
| github. | github.com/ |
| vulncheck. | vulncheck.com/ |
