Outdated OpenSSL Version on nextcloud desktop (windows)

It looks like nextcloud desktop 4.0.4 (latest version) is still coming with an outdated OpenSSL (libcrypto-3-x64.dll) on Windows, which is vulnerable to a known CVE. Our Vulnerability scanner actually is altering on this finding, is there a update for nextcloud desktop in the pipeline with a updated OpenSSL version like 3.4.3 included?

Hi @benken,

I checked this on Windows with Nextcloud Desktop 4.0.4 and inspected the shipped OpenSSL DLL directly.

The bundled libcrypto-3-x64.dll is OpenSSL 3.4.1 (x64) and is Authenticode-signed (valid) by Nextcloud GmbH. Relevant output from my local scan:

File Version Info (from PE metadata)
FileVersion      : 3.4.1
ProductVersion   : 3.4.1
FileDescription  : OpenSSL library
ProductName      : The OpenSSL Toolkit
CompanyName      : The OpenSSL Project, https://www.openssl.org/

PE Header
Architecture       : x64
PeType             : PE32+ (64-bit)

Embedded OpenSSL Strings
 - OpenSSL 3.4.1
 - OpenSSL 3.4.1 11 Feb 2025

Authenticode Signature
Status  : Valid
Subject : CN=Nextcloud GmbH, O=Nextcloud GmbH, C=DE

To interpret the scanner finding correctly: which exact CVE ID(s) does your scanner report (e.g. CVE-2025-xxxx), and what file path/version line is it matching on? OpenSSL CVEs can be feature/path dependent (and sometimes architecture-specific), so the CVE number matters for a proper risk assessment.

Also: does your scanner flag libssl-3-x64.dll as well (and if so, which version), or only libcrypto-3-x64.dll?


ernolf

Hi @ernolf,

many thanks for the fast reply.

The scanner identifies manly CVE-2025-9230, CVE-2025-9231 and CVE-2025-9232 for
c:\program files\nextcloud\libcrypto-3-x64.dll and c:\program files\nextcloud\libssl-3-x64.dll. Both files are version 3.4.1

Regards,

Benken

Nextcloud Desktop 4.0.4 on Windows bundles OpenSSL 3.4.1 in both libcrypto-3-x64.dll and libssl-3-x64.dll. Your scanner is therefore correct to flag CVE-2025-9230/9231/9232, because these are fixed in OpenSSL 3.4.3 and later. OpenSSL Library and OpenSSL Library

Practical impact depends heavily on code paths / platform:

  • CVE-2025-9231 (NVD: CVE-2025-9231) (SM2 timing side-channel, Moderate): This is 64-bit ARM only and also not relevant to most TLS contexts (OpenSSL doesn’t directly support SM2 certs in TLS unless you add it via a custom provider). On Windows x64 this is effectively not applicable. OpenSSL Library,

  • CVE-2025-9232 (NVD: CVE-2025-9232) (HTTP client no_proxy + IPv6, Low): This is an out-of-bounds read that can only cause a crash (DoS). It requires (1) the application to use OpenSSL’s HTTP client API (directly or via OCSP/CMP client code), (2) the user/system to have no_proxy set, and (3) an attacker-controlled URL with an IPv6 host passed into that API. That’s a fairly specific set of prerequisites, so the real-world risk for a typical sync client is usually low, but it is still a valid version-based finding.

  • CVE-2025-9230 (NVD: CVE-2025-9230) (CMS/PWRI decryption, Moderate): This is an out-of-bounds read + write that can lead to memory corruption (up to potential code execution in the worst case), but it requires an application to decrypt certain CMS messages using password-based encryption (PWRI).
    I searched the Nextcloud Desktop source tree specifically for PWRI/CMS password-recipient usage (e.g. PWRI, CMS_add0_recipient_password, PasswordRecipientInfo, and related CMS_RecipientInfo* password-recipient patterns) and did not find any indication that the client performs CMS PWRI decryption.
    While there are CMS-related references, they appear in the client-side encryption implementation only (e.g. src/libsync/clientsideencryption.cpp and src/libsync/clientsideencryptionprimitives.cpp), which is used for the optional End-to-End Encryption (E2EE) feature rather than the normal sync/TLS workflow. Based on this, if E2EE is not used, CVE-2025-9230 should not be reachable in the day-to-day sync path — although scanners will still flag it purely based on the bundled OpenSSL version.

So these are my conclusions:

  1. From a security/compliance standpoint it would be best if the Windows build simply shipped OpenSSL 3.4.3+ to clear these findings.

  2. From a “realistic exploitability in a standard desktop sync client on Windows x64” standpoint, 9231 is irrelevant (ARM64-only), 9232 is a constrained DoS scenario, and 9230 requires CMS PWRI decryption — for which I could not find any evidence in the Desktop client codebase, and the CMS-related code that does exist is confined to the E2EE/client-side-encryption implementation (src/libsync/clientsideencryption*.cpp). Therefore, without E2EE enabled/used, CVE-2025-9230 is likely not an issue for the normal sync client workflow.

h.t.h.

ernolf

1 Like

Hi @ernolf,

many thanks for the detailed analysis and your conclusion. This actally helps a lot. I guess we can currently ignore the vulnerabilities discovered realted to the outdated OpenSSL version that comes with nextcloud desktop. Anyway I will keep an eye on the new versions of nextcloud desktop and hope there is gong to be an update published including OpenSSL version 3.4.3+ to clear the findings.

Regards,

Benni

1 Like

Well, if you report it on the bug tracker GitHub · Where software is built you can be sure the developers are aware of it, and you’ll see when the issue is solved, and you don’t need to hope.

Hi @benken thanks for the report, we were aware and are working on an update. In the future, for your security and that of others, please report security-related issues through our Hackerone Program, see https://nextcloud.com/security/

@ernolf thank you for the detailed analysis. I agree with your view, this should not impact a typical user. We will still update the library and do a release with this update soon.

@tflidd you are right about reporting bugs to us developers directly, though for security issues always use hackerone.

happy (bug free) holidays!

2 Likes