This case below says libeay32.dll and ssleay32.dll that are in my application folder have a vulnerability. I do not remember which purchase added this to my build, but could be nettalk? If it processes PKCS#7, S/MIME, signed files, certificates, or XML signatures, then I should take actions, but if I only use it for TLS, then it isn’t necessary.
Problem is: I do not know what it is used for. We have enabled certificate use at some point, using CARootFile, but how this is validated, I do not know.
CVE-2026-45447 is a critical vulnerability in OpenSSL. The mechanics of how this happens and the effort required to exploit it are detailed below. [1, 2]
How the Vulnerability Happens
The issue stems from incorrect memory handling in the PKCS7_verify() function when processing ASN.1-formatted data. [1, 2]
The Trigger: A malicious PKCS#7 or S/MIME message is constructed with a SignedDatadigestAlgorithms field represented as an empty ASN.1 SET. [1, 2]
Incorrect Memory Deallocation: When OpenSSL encounters this specific empty field, it incorrectly assumes control of the caller-owned BIO (Basic Input/Output streams) and deallocates it. [1, 2]
The Use-After-Free: The memory location of the BIO is freed, but the calling application is unaware and still holds a reference to it. When the application later attempts to use the BIO (e.g., by calling BIO_free()), it accesses already-released memory. [1, 2, 3]
Impact: This memory corruption often leads to immediate process crashes, but in specific application environments, it can be exploited to achieve arbitrary Remote Code Execution (RCE). [1, 2]
Difficulty of Crafting the Message
Creating a specially crafted PKCS#7 or S/MIME message to trigger the bug is relatively straightforward, especially for someone familiar with ASN.1 structures and cryptography libraries. [1, 2, 3]
Low Barrier to Entry: Because the vulnerability is triggered by a structural flaw (an empty SET in a specific field) rather than complex cryptographic bypasses or encryption cracking, the message doesn’t need to be cryptographically valid or signed with a real key to trigger the parsing error. [1, 2]
Accessibility: Attackers can modify existing S/MIME or PKCS#7 messages using standard ASN.1 manipulation tools, or generate one from scratch using scripting languages with cryptography extensions. [1, 2]
Exploitation Difficulty: While triggering the crash is easy, turning this into reliable RCE is highly complex. Doing so requires bypassing modern heap protections, understanding the specific application’s memory allocation patterns, and orchestrating precise heap layouts. [1, 2, 3]
Action Required
If your environment relies on OpenSSL’s PKCS#7 APIs to process untrusted messages (note: those using the CMS APIs are not affected), you must apply the latest patches or updates: [1, 2, 3, 4]
OpenSSL 3.0 should be updated to 3.0.21
OpenSSL 3.4 to 3.4.6
OpenSSL 3.5 to 3.5.7
OpenSSL 3.6 to 3.6.3 (Supported older branches also have patches, such as 1.1.1zh and 1.0.2zq) [1]
Would you like help checking the OpenSSL version running on your local systems, or assistance in configuring your environment to block or reject malformed S/MIME structures at the gateway level?
Please don’t post AI generated content (or sumaries) here. Especially as this is from the original link posted.
Firstly because anyone interested in an AI summary can just ask their AI (so it adds no value.)
Secondly because it often contains errors. (The one you poted seems ok, but increasingly I’m getting support requests about things the AI has told a person which is just nonsense. )
Discussion about AI is fair game (ideally on the AI thread), but personally i dont think AI responses on other threads is helpful. (Remember, these threads will be here decades from now, so nonsense just propogates.)
I was kind of interested in how this vuln worked. I know there’s some code included in one of the SV supplied clarion classes which had a vuln a few years back, but it didnt affect Clarion per se.
