CVE-2025-62877: Default SSH Credentials During Harvester Installation Enable Remote Host Takeover

Overview

CVE-2025-62877 is a critical security issue affecting Harvester (SUSE Virtualization) when the platform is deployed using the interactive installer.
The problem is simple in concept but serious in impact: the system becomes reachable over the network before the default administrative SSH password is changed.

That short window is enough for an attacker to gain full access to the host.

If someone can reach the management network during installation, they can log in over SSH using default credentials and immediately take control of the node. From there, the entire virtualization environment is exposed.

Key Facts at a Glance

CVE ID: CVE-2025-62877
Severity: Critical
CVSS v3.1 Score: 9.8
Affected Versions: Harvester 1.5.x and 1.6.x (interactive installer only)
Attack Vector: Network
Privileges Required: None
User Interaction: None
Exploit Complexity: Very low
Exploit Availability: No public exploit code, but no exploit is required

What Actually Goes Wrong

During an interactive installation, Harvester follows this sequence:

System boots into the installer
Network interfaces are configured and brought online
SSH service starts automatically
Default administrative credentials are still active
User is prompted later to change the password

The issue is that steps 2–4 happen before step 5.

As soon as networking is up and SSH is running, the host is reachable. If the default password has not yet been changed, anyone who knows (or guesses) it can authenticate successfully.

This is not a misconfiguration by the administrator. It is a flaw in the installer workflow itself.

Why This Is So Dangerous

This is not limited access. A successful login at this stage gives:

Administrative access to the host OS
Control over the virtualization stack
Access to cluster secrets and configuration
The ability to tamper with VM images and storage
A foothold that persists even after installation completes

Once an attacker is in at this level, there is no reliable way to “clean” the system without rebuilding it.

How an Attack Would Happen

No special tools are required.

An organization installs Harvester using the interactive installer
The installation is performed on a network that is reachable internally (or worse, externally)
An attacker scans for new SSH hosts
The attacker connects to TCP port 22
Default credentials are accepted
The attacker gains a shell as an administrative user
Persistence is established before anyone notices

This can happen in minutes.

MITRE ATT&CK Mapping

This vulnerability maps cleanly to known attacker behavior:

Initial Access:
- T1078 – Valid Accounts (default credentials)

Once access is gained, follow-on techniques commonly apply:

Privilege escalation
Account manipulation
Lateral movement using SSH
Log tampering or cleanup

Is There an Exploit or PoC?

There is no public exploit code because none is needed.

Any standard SSH client is sufficient. The vulnerability is effectively “built in” during installation. That makes it more dangerous than many memory-corruption or RCE bugs that require complex payloads.

Safe Test Payloads (For Detection and Validation Only)

These examples are intended for defensive testing, SOC validation, or purple-team exercises.

SSH Authentication Test

ssh -o PreferredAuthentications=password \
    -o PubkeyAuthentication=no \
    admin@<harvester_node_ip>

This helps verify:

SSH logging
Alerting on password-based logins
Controls during installation windows

Network-Level Detection Test

TCP SYN to port 22 during install
SSH banner exchange
Authentication attempt before installation completion

This is useful for validating firewall rules, IDS alerts, and NDR visibility.

What to Monitor and Log

Critical Log Sources

SSH authentication logs
- /var/log/auth.log
- /var/log/secure
systemd journals for sshd
Harvester installer console and system logs
Firewall and network flow logs
Kubernetes and Harvester management logs
Bastion or jump-host logs (if used)

Indicators of Compromise or Abuse

High-confidence signs include:

Successful SSH logins before installation is marked complete
Logins from IP addresses outside deployment or admin ranges
Password-based SSH authentication on fresh nodes
Commands executed shortly after login such as:
- curl, wget
- nc, bash -i
- useradd, passwd
- Changes to authorized_keys or sudoers

Any of these during installation should be treated as a serious incident.

Example Detection Logic

Plain-Language Rule

Alert if any SSH login succeeds on a Harvester node while installation is still in progress and the source IP is not a trusted deployment address.

Generic Detection Rule

IF ssh_login == success
AND host_type == "harvester"
AND install_status != "completed"
AND source_ip NOT IN trusted_networks
THEN raise critical alert

Official Fix

Primary Remediation

Upgrade to Harvester version 1.7.0 or later.

The installer logic was corrected so that the default administrative password must be changed before networking and SSH access are enabled, eliminating the exposure window entirely.

Official Patch Link (Primary)

Harvester v1.7.0 Release (Official):
https://github.com/harvester/harvester/releases/tag/v1.7.0

Official Upgrade Documentation

Harvester Upgrade Guide:
https://docs.harvesterhci.io/v1.7/upgrade/

Only official Harvester release packages and documented upgrade paths should be used.

Temporary Mitigations (If You Cannot Upgrade Immediately)

If you are stuck on an affected version:

Perform installations on a strictly isolated network
Block inbound SSH during installation
Allow SSH only from a hardened jump host
Use PXE-based installs with pre-defined secure credentials
Rotate all credentials immediately after installation

These reduce risk but do not eliminate it.

Incident Response Guidance

If there is any chance the node was exposed:

Treat the host as compromised
Remove it from the network
Preserve logs for investigation
Rotate all cluster and host credentials
Rebuild the node from a trusted image
Audit VMs and storage for persistence

Do not rely on “cleanup” alone after host-level compromise.

Final Takeaway

CVE-2025-62877 is not a complex vulnerability, but it is a severe one.
It exposes administrative access at the most sensitive moment: before the system is secured.

In environments where installation networks are not tightly controlled, this issue represents an immediate and unacceptable risk. Upgrading the installer and tightening deployment procedures should be considered mandatory.