Raw vector
CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:H/A:HSummary
CVE-2025-30095 is a critical-severity Use of Hard-coded Cryptographic Key (CWE-321) vulnerability in Vyos (inferred from references). Its CVSS base score is 9.0 (Critical).
Operationally, exploitation aligns with the MITRE ATT&CK technique Private Keys (T1552.004); ranked at the 39th percentile by exploit likelihood (below the median); it is not currently listed in the CISA KEV catalog.
The strongest mitigations our analysis identified map to SC-12 (Cryptographic Key Establishment and Management) — see the control section below for these in your framework.
Deeper analysis AI-assisted summary
Synthesised by an AI model from the NVD description and linked references — a reading aid, not an authoritative source.
CVE-2025-30095 affects VyOS versions 1.3 through 1.5, with a fix available in 1.4.2, as well as any Debian-based Linux distribution using Dropbear in combination with live-build. The vulnerability stems from identical Dropbear private host keys being generated across different installations, enabling active man-in-the-middle (MITM) attacks on SSH connections when Dropbear serves as the SSH daemon. In VyOS, Dropbear is not the default system SSH daemon but is enabled by default for the console service. This issue, tied to CWE-321 (use of hard-coded cryptographic keys), carries a CVSS v3.1 base score of 9.0 (AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:H/A:H).
A network-based attacker with no privileges can exploit this vulnerability by positioning themselves to intercept SSH traffic to affected systems running Dropbear. The high attack complexity arises from the need for active network manipulation, but successful exploitation allows full MITM control, enabling the attacker to eavesdrop on sessions, inject malicious commands, or impersonate the server, resulting in high confidentiality, integrity, and availability impacts due to the cross-scope effects.
VyOS advisories recommend mitigating by removing default keys with commands such as "rm -f /etc/dropbear/*key*" and "rm -f /etc/dropbear-initramfs/*key*", then generating a new RSA host key using "dropbearkey -t rsa -s 4096 -f /etc/dropbear_rsa_host_key", followed by reloading the service or rebooting. Updating to the latest VyOS 1.4 or 1.5 releases also resolves the issue. Additional details are available in VyOS blog posts and the issue tracker at vyos.dev/T7217. Note that OpenSSH includes safeguards against this behavior, but Dropbear lacks an equivalent in live-build environments.
OWASP Top 10 for Web (2025)
EU & UK References
- 🇪🇺 ENISA EUVD: EUVD-2025-8773
Vulnerability Data
VyOS 1.3 through 1.5 (fixed in 1.4.2) or any Debian-based system using dropbear in combination with live-build has the same Dropbear private host keys across different installations. Thus, an attacker can conduct active man-in-the-middle attacks against SSH connections if Dropbear…
more
is enabled as the SSH daemon. I n VyOS, this is not the default configuration for the system SSH daemon, but is for the console service. To mitigate this, one can run "rm -f /etc/dropbear/*key*" and/or "rm -f /etc/dropbear-initramfs/*key*" and then dropbearkey -t rsa -s 4096 -f /etc/dropbear_rsa_host_key and reload the service or reboot the system before using Dropbear as the SSH daemon (this clears out all keys mistakenly built into the release image) or update to the latest version of VyOS 1.4 or 1.5. Note that this vulnerability is not unique to VyOS and may appear in any Debian-based Linux distribution that uses Dropbear in combination with live-build, which has a safeguard against this behavior in OpenSSH but no equivalent one for Dropbear.
- CWE(s)
Related Threats
MITRE ATT&CK Enterprise Techniques
CVEs Like This One
Affected Assets
Mitigating Controls
Mitigating Controls (NIST 800-53 r5) AI
Requiring cryptographic keys to be established and managed according to defined requirements prevents developers from embedding static unchangeable keys.
Mitigating Controls (NIST CSF 2.0) AI
Derived directly from the weakness types (CWEs) cited in the NVD entry via our AI-authored CWE→CSF cross-walk (authority under review) — links open the control.
Secure-SDLC activities such as code review and secret scanning directly prevent embedding static keys.
Data-at-rest protection policies require proper key management and therefore discourage hard-coded keys.
Data-in-transit protection similarly depends on non-hard-coded keys for encryption.
Configuration baselines and reviews can prohibit hard-coded keys in deployed artifacts.
Mitigating Controls (ISO/IEC 27001:2022 Annex A) AI
Derived directly from the weakness types (CWEs) cited in the NVD entry via our AI-authored CWE→ISO cross-walk (authority under review) — links open the control.
Key-management controls that govern generation, rotation and protection of keys make the use of embedded hard-coded cryptographic keys less likely and easier to detect.