CVE-2025-30095 is a vulnerability identified in VyOS versions 1.3 through 1.5, specifically related to the use of Dropbear SSH daemon with live-build on Debian-based systems. The core issue stems from the use of hard-coded Dropbear private host keys that are identical across different installations. This means that multiple systems running these affected versions share the same cryptographic keys for SSH authentication when Dropbear is enabled. Although VyOS does not use Dropbear as the default SSH daemon for remote connections (it uses it only for the console service by default), any deployment that enables Dropbear as the SSH daemon is vulnerable. The presence of identical private keys allows an attacker to perform active man-in-the-middle (MITM) attacks against SSH connections by impersonating the server, intercepting, and potentially manipulating data transmitted over the SSH session. This vulnerability arises because Dropbear does not have safeguards equivalent to OpenSSH that prevent the reuse of keys when using live-build, a tool used to create custom Debian-based images. The vulnerability is not unique to VyOS and may affect any Debian-based Linux distribution using Dropbear with live-build, increasing the scope of risk. Mitigation involves regenerating unique Dropbear host keys by deleting the pre-installed keys (e.g., removing /etc/dropbear/*key* and /etc/dropbear-initramfs/*key*) and generating new RSA 4096-bit keys using the dropbearkey utility, followed by restarting the Dropbear service or rebooting the system. Alternatively, upgrading to VyOS versions 1.4.2 or later resolves the issue as the vendor has addressed the key reuse problem. No known exploits are currently reported in the wild, but the vulnerability's nature makes it a significant risk if Dropbear is used for SSH access.

For European organizations, this vulnerability poses a moderate risk primarily to those using VyOS or Debian-based systems with Dropbear enabled as the SSH daemon. The impact includes potential compromise of confidentiality and integrity of SSH sessions, as attackers could intercept credentials, commands, or sensitive data via MITM attacks. This could lead to unauthorized access, lateral movement within networks, and data exfiltration. Availability impact is less direct but could result from subsequent attacks leveraging compromised SSH sessions. Organizations relying on VyOS for network routing, VPN gateways, or firewall functions could see critical operational disruptions if attackers exploit this vulnerability. The risk is heightened in environments where Dropbear is enabled for remote SSH access rather than just console access. Given the vulnerability also affects other Debian-based systems using Dropbear with live-build, organizations using custom Debian images in Europe should also assess exposure. The absence of known exploits suggests a window for proactive mitigation, but the ease of exploitation (no authentication or user interaction required for MITM if network access is available) means attackers with network positioning could exploit this vulnerability effectively.

1. Immediately audit all VyOS and Debian-based systems to identify if Dropbear is enabled as the SSH daemon, especially in remote access configurations. 2. For affected systems, delete the existing Dropbear host keys located in /etc/dropbear/ and /etc/dropbear-initramfs/ directories using commands such as 'rm -f /etc/dropbear/*key*' and 'rm -f /etc/dropbear-initramfs/*key*'. 3. Generate new unique RSA 4096-bit host keys with 'dropbearkey -t rsa -s 4096 -f /etc/dropbear_rsa_host_key'. 4. Restart the Dropbear service or reboot the system to apply new keys. 5. Where possible, replace Dropbear with OpenSSH for SSH daemon functionality, as OpenSSH includes safeguards against key reuse in live-build environments. 6. Upgrade VyOS installations to version 1.4.2 or later, where this vulnerability is fixed. 7. For custom Debian-based images using live-build, incorporate scripts or hooks to generate unique Dropbear keys during image creation to prevent key reuse. 8. Monitor network traffic for unusual SSH MITM activity and consider deploying network-based intrusion detection systems capable of detecting SSH anomalies. 9. Educate system administrators about the risks of using default or hard-coded cryptographic keys and enforce key management best practices.