Summary
A critical command-injection vulnerability in Cockpit's remote login feature allows attacker-controlled hostnames and usernames to influence SSH client invocation. An attacker with network access to the Cockpit web service may execute commands on the Cockpit host through a crafted login request, without valid credentials, before authentication completes.
Affected context
The vulnerability occurs in Cockpit deployments that expose the remote login feature and pass web-supplied hostnames or usernames into an SSH client without adequate validation, sanitization, or argument isolation. Risk is highest when the Cockpit service is reachable by untrusted networks and the host process has meaningful operating-system privileges.
Exploit preconditions
- Attack surface: Cockpit's remotely accessible web login endpoint
- Required access: Network access to the Cockpit web service; valid credentials are not required
- Trigger point: Processing of user-supplied hostname or username values during the SSH-based authentication flow
- Why exploitation is possible: Untrusted values are incorporated into SSH client execution without reliably separating data from options or shell-controlled command content
Why this happens
The underlying flaw is OS command injection, mapped to CWE-78. The application treats values received from the web interface as trusted process or command parameters instead of enforcing a strict input contract and preserving argument boundaries. As a result, specially crafted data may alter SSH client behavior or cause additional commands to be interpreted by the Cockpit host before authentication succeeds.
Potential impact
- An attacker may execute arbitrary commands on the Cockpit host
- The Cockpit service account or its accessible resources could be compromised
- Local data may be read, modified, or destroyed
- The host could be used for lateral movement or persistence
- Connected systems and administrative credentials could be exposed
General mitigation guidance
Mitigation generally focuses on eliminating command interpretation and reducing trust in web-provided connection parameters.
Common defensive patterns include:
- Invoke SSH through a process API that passes a fixed argument array rather than a shell command
- Apply strict allowlists and canonical validation to hostnames, usernames, and connection options
- Reject unexpected option prefixes, control characters, separators, and shell metacharacters
- Keep user-controlled values isolated from fixed client options and executable content
- Run the Cockpit service with least privilege and restrict its access to sensitive host resources
- Apply network segmentation and access controls to the Cockpit web service
How teams detect issues like this
Organizations can look for command-injection exposure through:
- Static analysis rules identifying shell construction, string concatenation, or interpolation involving request parameters
- Code review checks for subprocess calls that accept untrusted values without argument arrays or explicit escaping
- Tests using boundary-focused input validation cases, including option-like values and command-control characters
- Runtime monitoring for unexpected SSH client arguments, child processes, or shell descendants spawned by Cockpit
- Policy enforcement requiring approved process-execution wrappers and allowlisted remote connection parameters
Neutral automated code-review and software-composition tools may help identify unsafe process invocation patterns.
