OpenSSL 3.3.6 version showing critical vulnerability (CVE-2025-15467)

[Raghu Chidambaram]

Hi Team,

our application we are using OpenSSL 3.3.6 version, recently we upgraded from 3.3.5 to 3.3.6.

our blackduck tool is reporting one critical issue in this version for libssl library.

CVE - CVE-2025-15467

Till now when ever we take the OpenSSL version say x, both libssl and libcryto were showing same versions. but from OpenSSL 3.3.x onwards i m not sure why libssl shows different version and libcrypto shows different version. Why this discrepancy in the same OpenSSL code. Now because of this blackduck tool is showing critical issue in libssl.

so can you please provide some inputs on this on how to handle this case 

onefs-49-1# strings libcrypto.so.3 | grep "3.3.6"
OpenSSL 3.3.6 27 Jan 2026
3.3.6
onefs-49-1# strings libssl.so.3 | grep "3.3.0"
OPENSSL_3.3.0

 onefs-49-1# openssl version

OpenSSL 3.3.6 27 Jan 2026 (Library: OpenSSL 3.3.6 27 Jan 2026)

CVE-2025-15467 critical

Thanks,

Raghavendra

[Tomas Mraz]

Hello Raghu,

There are multiple problems with your tool.

1. It is misidentifying the version of libssl. Please note that the
presence of OPENSSL_3.3.0 in the version table of libssl.so.3 does NOT
indicate that libssl is from the 3.3.0 release.

2. (This is less of a problem of the tool as the tool might have hard
time to know.) The fix for CVE-2026-15467 is solely applying to
libcrypto.so.3, there is no change in libssl.so.3 in regards to this
issue.

I do not think this has ever changed. libssl AFAIK never contained a
full OpenSSL version string. If you want, you can suggest an
enhancement in our public GitHub repository that we should include a
full version string not just in libcrypto but also in libssl.

Kind regards,

Tomas Mraz, CTO, OpenSSL Foundation

> --
> You received this message because you are subscribed to the Google
> Groups "openssl-users" group.
> To unsubscribe from this group and stop receiving emails from it,
> send an email to openssl-user...@openssl.org.
> To view this discussion visit
> https://groups.google.com/a/openssl.org/d/msgid/openssl-users/5c6a2e7c-dbf7-438f-b68a-979474e88ef6n%40openssl.org
> .

--
Tomáš Mráz, Chief Technology Officer, OpenSSL Foundation
We need your support! Help us protect digital privacy… everywhere.
https://openssl.foundation/donate/ways-to-give

[Raghu Chidambaram]

Thanks a lot for the information Tomas,  then i m not very sure why our tool was showing two versions from 3.3.x versions onwards

previously when we were in 3.1.x there were no issues.

it will show as shown below so then we got confused and searching the libssl.so with strings command. Then we found this version as 3.3.0

so if you say that libssl doesn't have any affect then we will update manually in the tool .

The fix for CVE-2026-15467 is solely applying to
libcrypto.so.3 

so for the above issue we need to migrate to 3.3.7 or something? or it is already fixed in 3.3.6?

Thanks

[Tomas Mraz]

As mentioned in
https://openssl-library.org/news/vulnerabilities/#CVE-2025-15467
and
https://openssl-library.org/news/secadv/20260127.txt

The issue is fixed in version 3.3.6.

You need to report a bug by the vendor of the security scanner tool.

Tomas Mraz, CTO, OpenSSL Foundation

[Raghu Chidambaram]

ok sure Tomaz thanks a lot 

just for your information why it is showing in 3.3.x and not in the veriosn 3.5.x

as we use both version of OpenSSL

[Raghu Chidambaram]

You need to report a bug by the vendor of the security scanner tool.

--- sure will check once with the BD tool as well 

thanks

[Michael Wojcik]

From: openss...@openssl.org <openss...@openssl.org> On Behalf Of Raghu Chidambaram
Sent: Friday, 20 March, 2026 08:34

> just for your information why it is showing in 3.3.x and not in the veriosn 3.5.x
> as we use both version of OpenSSL

Software Composition Analysis is a hard problem. Black Duck uses multiple scanners to attempt to identify components and their versions, including package-manager configuration parsers, source scanners, binary scanners, and snippet scanners. It's well-known that BD often gets things wrong; that's why it has a UI and API for reconciling what the scanners think they've identified with what the development team actually knows (or finds out after researching, since modern developers tend to include dependencies with wild abandon) is present.

This is not an OpenSSL problem. It's not even really a Black Duck problem, in many cases (though there are certainly bugs and other issues with BD; I've lost track of how many cases I've raised with them over the past year). It's a problem for organizations using Black Duck. SCA tooling is still in its infancy and for typical native-code applications, SCA will always require a lot of manual intervention.

On the whole, BD is actually fairly capable, if irritating at times. But it's capable in much the way a complex machine tool is: it requires skilled operators. It is very much not turn-on-and-walk-away.

--
Michael Wojcik
================================
Rocket Software, Inc. and subsidiaries ■ 77 Fourth Avenue, Waltham MA 02451 ■ Main Office Toll Free Number: +1 855.577.4323
Contact Customer Support: https://my.rocketsoftware.com/RocketCommunity/RCEmailSupport
Unsubscribe from Marketing Messages/Manage Your Subscription Preferences - http://www.rocketsoftware.com/manage-your-email-preferences
Privacy Policy - http://www.rocketsoftware.com/company/legal/privacy-policy
================================

This communication and any attachments may contain confidential information of Rocket Software, Inc. All unauthorized use, disclosure or distribution is prohibited. If you are not the intended recipient, please notify Rocket Software immediately and destroy all copies of this communication. Thank you.

[Raghu Chidambaram]

Thanks Wojcik for detailed information on the BD.

That helps :)