Harvester Installer: Unauthenticated Root Access via Default Credentials Exposure

SUSE Harvester is a modern hyperconverged infrastructure (HCI) solution built on Kubernetes and Longhorn. When deploying Harvester via the interactive ISO installer, the system guides the administrator through a series of configuration steps (network setup, disk selection, cluster tokens, and password configuration). Ideally, a system should remain secure at every stage of this bootstrapping process.

CVE-2025-62877 represents a logical flaw in the ordering of these installation steps. In affected versions (1.5.x and 1.6.x), the installer activates the network stack to facilitate cluster discovery or remote resource fetching. Crucially, this activation starts the sshd service. At this specific point in the installation wizard, the underlying operating system user—rancher—is still configured with a vendor-supplied default password. This results in the exposure of a fully privileged account over the network before the administrator has been given the opportunity to secure it.

The vulnerability is classified as CWE-1188: Initialization of a Resource with an Insecure Default. The root cause lies in the sequential dependency graph of the installer's finite state machine. The installer requires network connectivity to validate VIPs (Virtual IPs) or join existing clusters. Consequently, it brings up the network interface and starts the OpenSSH Server daemon early in the process.

However, the step that creates the definitive system configuration—specifically the cloud-config or user data that overwrites the default rancher password—is applied later in the sequence. Between the moment the network interface acquires an IP address (via DHCP or static assignment) and the moment the user completes the 'Configure Password' step, the system is exposed.

Because the rancher user typically possesses passwordless sudo privileges to facilitate system management, valid SSH authentication immediately translates to full root compromise. The vulnerability is deterministic: if the network is active and the password has not yet been changed, the system is vulnerable.

The remediation for CVE-2025-62877 involved re-architecting the installer's workflow to enforce a 'Secure-First' approach. Below is a logical comparison of the installation flow before and after the fix in version 1.7.0.

Vulnerable Workflow (v1.5.x - v1.6.x)

In the vulnerable flow, the attack surface (Network/SSH) opens while the credential state is still 'Default'.

1. Boot ISO: System loads into memory.
2. Prompt: Choose Installation Mode.
3. Prompt: Configure Network Interface.
4. Action: Enable Network & Start SSHD.
   • > [!WARNING] VULNERABILITY WINDOW OPENS
   • Attacker can SSH as rancher with default password.
5. Prompt: Configure Cluster/VIP.
6. Prompt: Configure Admin Password.
   • > [!WARNING] VULNERABILITY WINDOW CLOSES
7. Action: Apply Configuration & Install.

Fixed Workflow (v1.7.0+)

In the fixed version, the dependency chain is inverted. The credential reset is a prerequisite for network activation.

1. Boot ISO: System loads into memory.
2. Prompt: Choose Installation Mode.
3. Prompt: Configure Admin Password.
   • User MUST set a custom password here.
4. Prompt: Configure Network Interface.
5. Action: Enable Network & Start SSHD.
   • > [!NOTE] SSH is now exposed, but the rancher user is already secured with the custom password.
6. Prompt: Configure Cluster/VIP.
7. Action: Apply Configuration & Install.

Exploitation of this vulnerability is trivial and requires no specialized exploit code, only standard network tools. An attacker positioned on the same network segment (or a routable network segment) as the bare-metal server being provisioned can automate the attack.

Attack Scenario:

1. Reconnaissance: The attacker runs a loop scanning for new hosts exposing port 22 (SSH). Since the installer requests an IP via DHCP, the attacker can monitor DHCP leases or ARP tables.
2. Access: As soon as port 22 becomes reachable, the attacker attempts to log in using the default credential set (User: rancher, Password: rancher or similar vendor default).
3. Persistence: Upon successful login, the attacker executes sudo -i to gain root privileges. They can then plant a persistent backdoor (e.g., adding an authorized key to /root/.ssh/authorized_keys, creating a new user, or modifying the installation scripts) that will survive the installation process and persist into the final production environment.

This attack vector is particularly dangerous in automated or semi-automated deployment environments where administrators may not be actively monitoring the console of every node being provisioned.

The impact of CVE-2025-62877 is critical, reflected in its CVSS 9.8 score. The vulnerability allows for complete system compromise at the infrastructure level.

• Confidentiality (High): An attacker can access sensitive data present on the install media or fetched during the install process (e.g., cluster join tokens, cloud-init secrets).
• Integrity (High): The attacker can modify the operating system before it is even installed to disk. This allows for supply-chain-style attacks where the underlying node is compromised before it joins the Kubernetes cluster.
• Availability (High): The attacker can halt the installation, wipe disks, or disrupt the node's ability to join the cluster.

Since Harvester nodes are hypervisors hosting virtual machines and container workloads, compromising the host node provides a pathway to compromise all workloads running on that node.

The primary remediation is to upgrade the installation media.

Official Patch

Users must download and use Harvester ISO v1.7.0 or later for all new installations. This version enforces the password reset prior to network initialization.

Workarounds for Older Media

If utilizing v1.5.x or v1.6.x media is unavoidable, strict network isolation is required:

1. Air-Gapped Install: Perform the installation on a disconnected network switch. Connect the uplink only after the installation is complete and the system has rebooted.
2. VLAN Isolation: Place the provisioning ports in a quarantined VLAN with no routing to the wider network and no unauthorized devices present.
3. PXE Boot: If available, use PXE boot automation instead of the interactive ISO. PXE installations typically inject the configuration (including the secure password hash) via a config-yaml file at boot time, bypassing the interactive wizard's vulnerable sequence.