The OpenSSL Project has announced several new versions of their open source SSL/TLS toolkit, with a focus on addressing 3 vulnerabilities, including 1 assigned a high CVSS score and 2 assigned medium.

Given the risks and availability of fixes for these CVEs, we encourage organizations that have control over their containers to patch or upgrade ASAP. Additionally, Seal Security users have access to patched versions of this package and RHEL 6, RHEL 7 and CentOS 7 containers, protecting them from these attacks.

The Vulnerabilities

The 3 CVEs that opened up the potential for private key recovery, code execution, and DoS attacks are as follows:

• CVE-2025-9230:
  
  • Issue: An application trying to decrypt CMS messages encrypted using password based encryption can trigger an out-of-bounds read and write. 
  • Impact: The out-of-bounds write can cause a memory corruption which can have various consequences including a Denial of Service or Execution of attacker-supplied code.
  • 7.5 (High) Base Score (CISA-ADP, Vector: CVSS 3.1)

• CVE-2025-9231:
  
  • Issue: A timing side-channel which could potentially allow remote recovery of the private key exists in the SM2 algorithm implementation on 64 bit ARM platforms. 
  • Impact: A timing side-channel in SM2 signature computations on 64 bit ARM platforms could allow recovering the private key by an attacker.
  • 6.5 (Medium) Base Score (CISA-ADP, Vector: CVSS 3.1)

• CVE-2025-9232:
  
  • Issue: An application using the OpenSSL HTTP client API functions may trigger an out-of-bounds read if the 'no_proxy' environment variable is set and the host portion of the authority component of the HTTP URL is an IPv6 address. 
  • Impact: An out-of-bounds read can trigger a crash which leads to Denial of Service for an application.
  • 5.9 (Medium) Base Score (CISA-ADP, Vector: CVSS 3.1)

The Problem With Security Updates

While it is positive that these vulnerabilities have publicly available fixes, there is currently a protection gap for many teams that use OpenSSL, which might leave them open to targeted attacks. 

Let’s walk through the steps of the update process: 

• Step 1: OpenSSL maintainers release a patch.

Most often when the maintainer or a researcher reports a security issue as part of a responsible disclosure process, the patch is released at the same time as the technical details are publicly disclosed. However, often a potential risk might be publicly reported as a technical issue, only later on classified as a security issue (Half-Day Vulnerabilities), leaving the users exposed for longer periods. 

Moreover, sometimes the vulnerability is eventually fixed in a later version, there is also no guarantee that you can make it work in your code. The update could introduce breaking changes, while your version of the library might not have the fix available.

For example, the updates for the popular 1.0.2 and 1.1.1 versions are only available for premium support members. This means no public fix, unless your team has the means to pay.

• Step 2: Your Linux distribution (e.g., RHEL, Ubuntu, Alpine) picks it up and rebuilds it.

While this part of the process can happen as quickly as a few days for small updates, there is no guarantee that the process will go this smoothly. Major updates can take much longer if there are compatibility issues, multiplying your risk as time goes on.

When OpenSSL 3.0 released in 2021, it was estimated to have taken 6 to 9 months to bring to RHEL and Fedora (RedHat, 2022).

• Step 3: The container image maintainer updates the image.

If you’re using a container with OpenSSL that wasn’t written by your team, for example a third party product like nginx, there are even more reasons that you might be at risk during this transition.

Once this fix is eventually released, container users must wait for their maintainers of the container to clear the way to use the latest version. Until someone updates the container, you will have CVEs and not be able to update.

Things can also get especially complicated if you’re using an old distro such as RHEL 6 or CentOS 7. Without maintainer support, you’re stuck forever and will continue to accrue security debt from these CVEs until you go through a tedious migration process.

• Step 4: You rebuild and redeploy your container image.

This can take weeks (if not months) for some teams to complete, and hackers have a window where they are now aware of this vulnerability, but app security teams may not have been able to remediate it yet.

For high- and medium-severity vulnerabilities this process can be expected to take anywhere from 150 to over 500 days (Sonatype, 2024), possibly leaving you vulnerable for over a year. This can put you at risk of compliance or SLA issues, which can lead to lost revenue or costly fines.

Take Control of Your Containers

With all of the challenges that open source updates can bring, organizations that need the highest security standards or are looking to improve their open source CVE remediation may be looking for a new approach.

It’s no secret: relying on upstream maintainers to patch your systems is like outsourcing your locks and hoping they show up after the break-in.

Seal gives you the ability to patch critical vulnerabilities like these OpenSSL flaws at the OS package and base image level, even in legacy or unsupported environments where upstream fixes are no longer available. And for compliance frameworks like FedRAMP, PCI DSS 4.0, and DORA, that means the difference between a passed audit and a failed one.

Reach out to our team to see how we do it in action today, and stand tall against attacks with CVE-free versions of the libraries, containers, and operating systems.