Matthias EndlerApr 23
Thomas Zahner

Just woke up to 5 vulnerability alerts (4 high severity) of the openSSL Rust crate. Now I'm even more thankful we've made the switch to rustls in lychee. I've only seen advantages so far. The transition was totally smooth, and now we have faster, more stable and apparently more secure TLS.

Thank you @djc, @ctz et al. for this amazing piece of software!

#rust #openssl #rustls

Apr 23 at 6:51amWeb
Show threadThomas ZahnerApr 23

Here we switched before the last release in February: https://github.com/lycheeverse/lychee/pull/1928

It resolved multiple inconsistencies as lychee behaved differently on each target platform as the target platform's openSSL implementation was used. Switching to rustls has resolved multiple long-standing issues and we haven't received any related bug reports since.

Replace OpenSSL with rustls by thomas-zahner · Pull Request #1928 · lycheeverse/lychee

Closes #1721 Closes #1970 Closes #1920 Hopefully closes #2024 Background Using Rustls instead of openSSL should simplify many things. Depending on platform specific external openSSL libraries seems...

GitHub
Show threadFabio ValentiniApr 23
@thomas_zahner it looks like they were now all downgraded to "medium" or "low" severity? (still bad, but I guess *less* bad?)
Show threadThomas ZahnerApr 27

@decathorpe Hmm I still see them as high severity, but not sure how easy it is to exploit them in the real world.

As far as I understand many of the vulnerabilities are caused by FFI and incorrect pointer logic, after all the library is just bindings for OpenSSL. rustls in contrast is a full Rust implementation reducing the need for unsafe code and raw pointers, which reduces the probability of such bugs greatly.

Show threadFabio ValentiniApr 29

@thomas_zahner by "downgraded from high to medium" I meant that the original screenshot you included from the GitHub UI shows them as "high" but now that same page lists them as "medium":

https://github.com/rust-openssl/rust-openssl/security

Build software better, together

GitHub is where people build software. More than 150 million people use GitHub to discover, fork, and contribute to over 420 million projects.

GitHub
Show threadThomas ZahnerApr 29
@decathorpe huh interesting. They might weigh the criteria differently? Until now I thought they would use plain CVSS
Show threadFabio ValentiniApr 29

@thomas_zahner I'm not sure what you mean?

they were classified as "high" initially but are "medium" now. so it looks like the severity for those GHSAs was just adjusted down after you made your screenshot.

Show threadThomas ZahnerApr 29
@decathorpe ah yes, I see, thank you. I just pointed out that I thought GitHub would simply show the CVSS criticality until now. But that's not the case. So I learned something today :)
Show threadThomas ZahnerApr 27

@decathorpe

https://app.opencve.io/cve/CVE-2026-41676
https://app.opencve.io/cve/CVE-2026-41677
https://app.opencve.io/cve/CVE-2026-41678
https://app.opencve.io/cve/CVE-2026-41681

CVE-2026-41676 - Vulnerability Details - OpenCVE

rust-openssl provides OpenSSL bindings for the Rust programming language. From 0.9.27 to before 0.10.78, Deriver::derive (and PkeyCtxRef::derive) sets len = buf.len() and passes it as the in/out length to EVP_PKEY_derive, relying on OpenSSL to honor it. On OpenSSL 1.1.x, X25519, X448, DH and HKDF-extract ignore the incoming *keylen, unconditionally writing the full shared secret (32/56/prime-size bytes). A caller passing a short slice gets a heap/stack overflow from safe code. OpenSSL 3.x providers do check, so this only impacts older OpenSSL. This vulnerability is fixed in 0.10.78.