# OpenSSL ssleay32.dll, libeay32.dll vulnerability **URL:** \ **Category:** questions\ **Tags:** ssl\ **Created:** [June 14, 2026, 3:18pm UTC](https://clarionhub.com/t/openssl-ssleay32-dll-libeay32-dll-vulnerability/9168 "2026-06-14T15:18:43Z")\ **Posts on this page:** 13\ **Page:** 1
**Author:** ![Bjarne\_Havnen](https://clarionhub.com/user_avatar/clarionhub.com/bjarne_havnen/32/1350_2.png) [@Bjarne\_Havnen](https://clarionhub.com/u/Bjarne_Havnen)\ **Post date:** [June 14, 2026, 3:18pm UTC](https://clarionhub.com/t/openssl-ssleay32-dll-libeay32-dll-vulnerability/9168/1 "2026-06-14T15:18:43Z")
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. Anyone want to enlighten me? > **[NVD - Home](https://nvd.nist.gov/vuln/detail/cve-2026-45447)** Solution [https://openssl-library.org/news/secadv/20260609.txt](https://openssl-library.org/news/secadv/20260609.txt) ---
**Author:** ![Bruce](https://clarionhub.com/letter_avatar_proxy/v4/letter/b/ccd318/32.png) [@Bruce](https://clarionhub.com/u/Bruce)\ **Post date:** [June 14, 2026, 6:31pm UTC](https://clarionhub.com/t/openssl-ssleay32-dll-libeay32-dll-vulnerability/9168/2 "2026-06-14T18:31:27Z")
Yes, probably NetTalk. Which build are you using? Its unlikely that Clarion programs are using thd affected functions, but you can update your OpenSSL Dlls to be sure. Official NetTalk updates with the new DLLs will follow this week. ---
**Author:** ![Bjarne\_Havnen](https://clarionhub.com/user_avatar/clarionhub.com/bjarne_havnen/32/1350_2.png) [@Bjarne\_Havnen](https://clarionhub.com/u/Bjarne_Havnen)\ **Post date:** [June 14, 2026, 8:18pm UTC](https://clarionhub.com/t/openssl-ssleay32-dll-libeay32-dll-vulnerability/9168/3 "2026-06-14T20:18:12Z")
Thank you. Still using old version, 9 or something. ---
**Author:** ![RchdR](https://clarionhub.com/letter_avatar_proxy/v4/letter/r/d78d45/32.png) [@RchdR](https://clarionhub.com/u/RchdR)\ **Post date:** [June 14, 2026, 10:44pm UTC](https://clarionhub.com/t/openssl-ssleay32-dll-libeay32-dll-vulnerability/9168/4 "2026-06-14T22:44:15Z")
**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](https://access.redhat.com/security/cve/cve-2026-45447), [2](https://www.securityweek.com/openssl-patches-high-severity-vulnerability-found-with-ai/)] How the Vulnerability Happens The issue stems from incorrect memory handling in the `PKCS7_verify()` function when processing ASN.1-formatted data. [[1](https://access.redhat.com/security/cve/cve-2026-45447), [2](https://www.securityweek.com/openssl-patches-high-severity-vulnerability-found-with-ai/)] 1. **The Trigger:** A malicious PKCS#7 or S/MIME message is constructed with a `SignedData` `digestAlgorithms` field represented as an empty ASN.1 SET. [[1](https://access.redhat.com/security/cve/cve-2026-45447), [2](https://www.securityweek.com/openssl-patches-high-severity-vulnerability-found-with-ai/)] 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](https://www.suse.com/security/cve/CVE-2026-45447.html), [2](https://www.securityweek.com/openssl-patches-high-severity-vulnerability-found-with-ai/)] 3. **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](https://vulmon.com/vulnerabilitydetails?qid=CVE-2026-45447), [2](https://meterian.io/vulns/?id=f3a2b1c0-d4e5-4f67-8901-234567890abc&date=2026/06/11), [3](https://www.suse.com/security/cve/CVE-2026-45447.html)] 4. **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](https://www.suse.com/security/cve/CVE-2026-45447.html), [2](https://access.redhat.com/security/cve/cve-2026-45447)] 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](https://www.securityweek.com/openssl-patches-high-severity-vulnerability-found-with-ai/), [2](https://meterian.io/vulns/?id=f3a2b1c0-d4e5-4f67-8901-234567890abc&date=2026/06/11), [3](https://access.redhat.com/security/cve/cve-2026-45447)] - **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](https://www.securityweek.com/openssl-patches-high-severity-vulnerability-found-with-ai/), [2](https://access.redhat.com/security/cve/cve-2026-45447)] - **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](https://www.securityweek.com/openssl-patches-high-severity-vulnerability-found-with-ai/), [2](https://access.redhat.com/security/cve/cve-2026-45447)] - **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](https://www.suse.com/security/cve/CVE-2026-45447.html), [2](https://www.securityweek.com/openssl-patches-high-severity-vulnerability-found-with-ai/), [3](https://access.redhat.com/security/cve/cve-2026-45447)] 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](https://www.suse.com/security/cve/CVE-2026-45447.html), [2](https://access.redhat.com/security/cve/cve-2026-45447), [3](https://meterian.io/vulns/?id=f3a2b1c0-d4e5-4f67-8901-234567890abc&date=2026/06/11), [4](https://www.securityweek.com/openssl-patches-high-severity-vulnerability-found-with-ai/)] - **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](https://bugzilla.redhat.com/show_bug.cgi?id=2481898)] 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? ---
**Author:** ![Bruce](https://clarionhub.com/letter_avatar_proxy/v4/letter/b/ccd318/32.png) [@Bruce](https://clarionhub.com/u/Bruce)\ **Post date:** [June 15, 2026, 3:37am UTC](https://clarionhub.com/t/openssl-ssleay32-dll-libeay32-dll-vulnerability/9168/5 "2026-06-15T03:37:33Z")
Aah. Well then you need to update the DLLs yourself. There wont be another NT9 build. And its worth doing. There have been a lot of OpenSSL updates since the last NT9 release. ---
**Author:** ![Bruce](https://clarionhub.com/letter_avatar_proxy/v4/letter/b/ccd318/32.png) [@Bruce](https://clarionhub.com/u/Bruce)\ **Post date:** [June 15, 2026, 3:44am UTC](https://clarionhub.com/t/openssl-ssleay32-dll-libeay32-dll-vulnerability/9168/6 "2026-06-15T03:44:59Z")
Hi Richard, 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.) Thanks Bruce ---
**Author:** ![RchdR](https://clarionhub.com/letter_avatar_proxy/v4/letter/r/d78d45/32.png) [@RchdR](https://clarionhub.com/u/RchdR)\ **Post date:** [June 15, 2026, 4:10am UTC](https://clarionhub.com/t/openssl-ssleay32-dll-libeay32-dll-vulnerability/9168/7 "2026-06-15T04:10:03Z")
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. I can delete the post if you want? ---
**Author:** ![Bruce](https://clarionhub.com/letter_avatar_proxy/v4/letter/b/ccd318/32.png) [@Bruce](https://clarionhub.com/u/Bruce)\ **Post date:** [June 15, 2026, 4:08pm UTC](https://clarionhub.com/t/openssl-ssleay32-dll-libeay32-dll-vulnerability/9168/8 "2026-06-15T16:08:35Z")
you don’t need to delete the post. And you’re free to ask your AI anything you like 🙂 Just please don’t post future AI responses here. ---
**Author:** ![RchdR](https://clarionhub.com/letter_avatar_proxy/v4/letter/r/d78d45/32.png) [@RchdR](https://clarionhub.com/u/RchdR)\ **Post date:** [June 15, 2026, 9:14pm UTC](https://clarionhub.com/t/openssl-ssleay32-dll-libeay32-dll-vulnerability/9168/9 "2026-06-15T21:14:45Z")
I thought the specifics of the hack were interesting, because it didnt involve any effort. Cant believe that sort of thing passed through moderation/approval/got pulled into production. ---
**Author:** ![Bruce](https://clarionhub.com/letter_avatar_proxy/v4/letter/b/ccd318/32.png) [@Bruce](https://clarionhub.com/u/Bruce)\ **Post date:** [June 16, 2026, 2:36am UTC](https://clarionhub.com/t/openssl-ssleay32-dll-libeay32-dll-vulnerability/9168/10 "2026-06-16T02:36:37Z")
Yes, but all the information was in the links Bjarne posted. The AI was just a rehash of that. ---
**Author:** ![RchdR](https://clarionhub.com/letter_avatar_proxy/v4/letter/r/d78d45/32.png) [@RchdR](https://clarionhub.com/u/RchdR)\ **Post date:** [June 16, 2026, 12:38pm UTC](https://clarionhub.com/t/openssl-ssleay32-dll-libeay32-dll-vulnerability/9168/11 "2026-06-16T12:38:25Z")
> [@Bruce](#): > > all the information was in the links Bjarne posted TLDR. I wanted a synopsis. ---
**Author:** ![Bruce](https://clarionhub.com/letter_avatar_proxy/v4/letter/b/ccd318/32.png) [@Bruce](https://clarionhub.com/u/Bruce)\ **Post date:** [June 17, 2026, 11:03am UTC](https://clarionhub.com/t/openssl-ssleay32-dll-libeay32-dll-vulnerability/9168/12 "2026-06-17T11:03:26Z")
Which is fine. You are welcome to do that of course. There was just no need to repost its answer here… ---
**Author:** ![RchdR](https://clarionhub.com/letter_avatar_proxy/v4/letter/r/d78d45/32.png) [@RchdR](https://clarionhub.com/u/RchdR)\ **Post date:** [June 17, 2026, 8:28pm UTC](https://clarionhub.com/t/openssl-ssleay32-dll-libeay32-dll-vulnerability/9168/13 "2026-06-17T20:28:24Z")
> [@OpenSSL ssleay32.dll, libeay32.dll vulnerability](https://clarionhub.com/t/openssl-ssleay32-dll-libeay32-dll-vulnerability/9168/11): > > TLDR. I wanted a synopsis.