Overview
This blog post examines CVE-2025-55109, a critical authentication bypass vulnerability in the out-of-support Control-M/Agent versions 9.0.18 to 9.0.20 and potentially earlier unsupported versions. This vulnerability presents a significant risk to organizations that use this software, as it allows an attacker with access to a signed third-party or demo certificate for client authentication to bypass the need for a certificate signed by the certificate authority of the organization during authentication on the Control-M/Agent. This can potentially lead to unauthorized access, system compromise, or data leakage.
Vulnerability Summary
CVE ID: CVE-2025-55109
Severity: Critical (CVSS: 9.0)
Attack Vector: Network
Privileges Required: None
User Interaction: None
Impact: Potential system compromise or 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
Control-M/Agent | 9.0.18 to 9.0.20
How the Exploit Works
The vulnerability lies in the way the Control-M/Agent handles certificates for client authentication. The software contains hardcoded certificates which are only trusted as fallback if an empty kdb keystore is used. If a PKCS#12 keystore is used, these certificates are never trusted. However, all of these certificates are now expired.
Furthermore, the Control-M/Agent default kdb and PKCS#12 keystores contain trusted third-party certificates (external recognized CAs and default self-signed demo certificates) which are trusted for client authentication. An attacker can exploit this vulnerability by presenting a signed third-party or demo certificate to bypass the need for a certificate signed by the certificate authority of the organization during authentication on the Control-M/Agent.
Conceptual Example Code
The following is a conceptual example of how the vulnerability might be exploited. It is a simplified version of an authentication request where a malicious actor uses a signed third-party or demo certificate instead of a certificate signed by the organization’s certificate authority.
POST /ControlM/AgentAuthentication HTTP/1.1
Host: target.example.com
Content-Type: application/json
{
"ClientCertificate": "SignedThirdPartyOrDemoCertificate",
"AuthenticationPayload": "..."
}
In this example, `SignedThirdPartyOrDemoCertificate` represents the signed third-party or demo certificate used by the attacker to bypass authentication, and `AuthenticationPayload` is a placeholder for the actual authentication payload.
