KB Article #192922
SECURITY: SecureTransport and CVE-2025-15467 OpenSSL vulnerability
Problem
CVE-2025-15467 vulnerability has been discovered affecting OpenSSL 3.0.18 and 3.5.4.
SecureTransport includes a few libraries from the OpenSSL package as part of it's embedded internal PostgreSQL database and the Cygwin emulation on Windows.
Resolution
Axway R&D analyzed the issue with the following result:
• SecureTransport current version and all supported previous versions are NOT vulnerable to CVE-2025-15467.
• Nevertheless, SecureTransport will include the latest OpenSSL version once a fix is released, so customers are advised to plan for updating their SecureTransport installations.
Detailed analysis
The attack is described as:
Applications and services that parse untrusted CMS or PKCS#7 content using AEAD ciphers (e.g., S/MIME AuthEnvelopedData with AES-GCM) are vulnerable. Because the overflow occurs prior to authentication, no valid key material is required to trigger it. While exploitability to remote code execution depends on platform and toolchain mitigations, the stack-based write primitive represents a severe risk.
Although SecureTransport ships OpenSSL libraries it is not vulnerable to CVE-2025-15467. These libraries are used only by the internal PostgreSQL database internal TLS communication. The vulnerability applies only to applications that explicitly parse CMS / PKCS#7 AuthEnvelopedData structures, which PostgreSQL does not do. The vulnerable code path is not used by TLS and not exercised by PostgreSQL.
CVE-2025-15467 is a stack-based buffer overflow in OpenSSL’s handling of CMS (Cryptographic Message Syntax) AuthEnvelopedData when AEAD ciphers (e.g., AES-GCM) are used. The flaw occurs while parsing CMS objects, specifically CMS_AuthEnvelopedData. It is triggered by a maliciously crafted CMS message containing an oversized Initialization Vector (IV). The vulnerable logic executes before authentication, making it exploitable only if CMS data is parsed. This vulnerability is not a general AEAD or AES-GCM issue, and it is not a TLS parsing issue.
PostgreSQL uses OpenSSL strictly for TLS transport security, including:
• TLS handshake processing
• Certificate validation
• Session key establishment
• Encryption and decryption of network traffic
PostgreSQL does not:
• Parse CMS / PKCS#7 data
• Use OpenSSL’s CMS_* APIs
• Accept or process CMS blobs from clients
• Perform CMS encryption or decryption as part of TLS
• TLS and CMS are distinct OpenSSL subsystems with separate code paths.
TLS:
• Uses fixed, protocol-defined structures
• Validates record and handshake message sizes
• Does not expose arbitrary IV-length parsing from untrusted CMS input
• Does not invoke CMS_AuthEnvelopedData logic at any point
Even though TLS may use AES-GCM, that alone is not sufficient to reach the vulnerable code. The issue is in CMS parsing, not in the cipher implementation itself.
Conclusion
ST use of OpenSSL is limited to PostgreSQL TLS communication, which does not exercise the vulnerable CMS code path described in CVE-2025-15467. As a result:
• There is no exploitable attack surface
• The vulnerability cannot be triggered remotely
• No configuration changes or emergency mitigations are required