Summary
Klever-Go exposes a WebSocket log endpoint without authentication, allowing remote clients to alter process-wide logging profiles and observe live application logs. An attacker who can reach the endpoint may suppress or increase logging, distort operational visibility, and access sensitive runtime information without credentials.
Affected context
The issue occurs in Klever-Go deployments where the /log WebSocket route is enabled and reachable without an authentication control. The endpoint accepts an initial logger profile from the client, applies it globally while the connection remains open, and registers the client as a live log observer.
Exploit preconditions
- Attack surface: Network-accessible
/logWebSocket endpoint - Required access: Ability to establish a WebSocket connection; no application credentials are required when the route is exposed
- Trigger point: The first client message, which is parsed as a logger profile
- Why exploitation is possible: The route lacks authentication, and the supplied profile is applied process-wide while the connection remains active
Why this happens
The underlying defect is missing authentication on a sensitive operational endpoint, mapping primarily to CWE-306: Missing Authentication for Critical Function. The endpoint permits unauthenticated clients to invoke logging-control behavior and subscribe to process logs, crossing a trust boundary without verifying identity or authorization. Applying client-controlled settings globally also creates an insecure scope and state-management pattern.
Potential impact
- An attacker may suppress security-relevant or operational log messages.
- An attacker could increase verbosity and expose additional runtime information.
- Unauthorized clients may receive live process logs containing sensitive operational data.
- Operators may be misled by altered log formatting or visibility.
- The incident response and monitoring process can be weakened.
General mitigation guidance
Mitigation generally centers on treating log-control and log-observation interfaces as privileged administrative functions.
Common defensive patterns include:
- Require strong authentication and explicit authorization before accepting WebSocket connections.
- Prefer disabling remote log-control endpoints by default unless they are operationally necessary.
- Separate log observation from log configuration and apply narrowly scoped permissions to each function.
- Avoid applying client-provided logging profiles process-wide; use bounded, validated, and connection-scoped settings where feasible.
- Restrict network exposure through private interfaces, firewall rules, service policies, or an authenticated management plane.
- Run the service with least privilege and ensure logs are protected from unauthorized access or tampering.
How teams detect issues like this
Organizations can identify similar issues through:
- Static analysis and configuration checks for unauthenticated administrative or diagnostic routes.
- Code review signals such as WebSocket handlers that register observers or change global state before authorization.
- API inventory reviews that classify logging, tracing, and debug endpoints as privileged surfaces.
- Integration tests verifying that unauthenticated clients cannot connect, subscribe to logs, or modify runtime settings.
- Network policy checks confirming that operational endpoints are not exposed beyond trusted management networks.
- Automated security review tools and CI policies that flag default-open sensitive routes.
