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 haveno_proxyset, 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 relatedCMS_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.cppandsrc/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:
-
From a security/compliance standpoint it would be best if the Windows build simply shipped OpenSSL 3.4.3+ to clear these findings.
-
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
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
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!