https://cve.radiocsirt.org/rss/recent/all/10 Most recent entries from all 2026-10-03T08:00:26.383162+00:00 Vulnerability-Lookup csirt@opendfir.org python-feedgen Contains only the most 10 recent entries. https://cve.radiocsirt.org/vuln/brew-duplicity-cve-2020-26263 BREW-duplicity-CVE-2020-26263 — RSA weakness in tslite-ng 2026-10-03T08:00:26.437174+00:00

Affected: Homebrew: duplicity

### Impact The code that performs decryption and padding check in RSA PKCS#1 v1.5 decryption is data dependant. In particular, code in current (as of 0.8.0-alpha38) master https://github.com/tlsfuzzer/tlslite-ng/blob/0812ed60860fa61a6573b2c0e18771414958f46d/tlslite/utils/rsakey.py#L407-L441 and code in 0.7.5 branch https://github.com/tlsfuzzer/tlslite-ng/blob/acdde3161124d6ae37c506b3476aea9996d12e97/tlslite/utils/rsakey.py#L394-L425 has multiple ways in which it leaks information (for one, it aborts as soon as the plaintext doesn't start with 0x00, 0x02) about the decrypted ciphertext (both the bit length of the decrypted message as well as where the first unexpected byte lays).

All TLS servers that enable RSA key exchange as well as applications that use the RSA decryption API directly are vulnerable.

All previous versions of tlslite-ng are vulnerable.

### Patches The patches to fix it are proposed in https://github.com/tlsfuzzer/tlslite-ng/pull/438 https://github.com/tlsfuzzer/tlslite-ng/pull/439

Note: the patches depend on Python processing the individual bytes in side-channel free manner, this is known to not be the case: https://securitypitfalls.wordpress.com/2018/08/03/constant-time-compare-in-python/ As such, users that require side-channel resistance are recommended to use different TLS implementations, as stated in the [security policy](https://github.com/tlsfuzzer/tlslite-ng/blob/master/SECURITY.md) of tlslite-ng.

### Workarounds There is no way to workaround…

 https://cve.radiocsirt.org/vuln/cve-2020-26263 CVE-2020-26263 — RSA vulnerability in tslite-ng 2026-10-03T08:00:26.437249+00:00

Affected: tlsfuzzer tlslite-ng

tlslite-ng is an open source python library that implements SSL and TLS cryptographic protocols. In tlslite-ng before versions 0.7.6 and 0.8.0-alpha39, the code that performs decryption and padding check in RSA PKCS#1 v1.5 decryption is data dependant. In particular, the code has multiple ways in which it leaks information about the decrypted ciphertext. It aborts as soon as the plaintext doesn't start with 0x00, 0x02. All TLS servers that enable RSA key exchange as well as applications that use the RSA decryption API directly are vulnerable. This is patched in versions 0.7.6 and 0.8.0-alpha39. Note: the patches depend on Python processing the individual bytes in side-channel free manner, this is known to not the case (see reference). As such, users that require side-channel resistance are recommended to use different TLS implementations, as stated in the security policy of tlslite-ng.

 https://cve.radiocsirt.org/vuln/ghsa-wvcv-832q-fjg7 GHSA-wvcv-832q-fjg7 — RSA weakness in tslite-ng 2026-10-03T08:00:26.437307+00:00

Affected: PyPI: tlslite-ng

### Impact The code that performs decryption and padding check in RSA PKCS#1 v1.5 decryption is data dependant. In particular, code in current (as of 0.8.0-alpha38) master https://github.com/tlsfuzzer/tlslite-ng/blob/0812ed60860fa61a6573b2c0e18771414958f46d/tlslite/utils/rsakey.py#L407-L441 and code in 0.7.5 branch https://github.com/tlsfuzzer/tlslite-ng/blob/acdde3161124d6ae37c506b3476aea9996d12e97/tlslite/utils/rsakey.py#L394-L425 has multiple ways in which it leaks information (for one, it aborts as soon as the plaintext doesn't start with 0x00, 0x02) about the decrypted ciphertext (both the bit length of the decrypted message as well as where the first unexpected byte lays).

All TLS servers that enable RSA key exchange as well as applications that use the RSA decryption API directly are vulnerable.

All previous versions of tlslite-ng are vulnerable.

### Patches The patches to fix it are proposed in https://github.com/tlsfuzzer/tlslite-ng/pull/438 https://github.com/tlsfuzzer/tlslite-ng/pull/439

Note: the patches depend on Python processing the individual bytes in side-channel free manner, this is known to not be the case: https://securitypitfalls.wordpress.com/2018/08/03/constant-time-compare-in-python/ As such, users that require side-channel resistance are recommended to use different TLS implementations, as stated in the [security policy](https://github.com/tlsfuzzer/tlslite-ng/blob/master/SECURITY.md) of tlslite-ng.

### Workarounds There is no way to workaround…