https://cve.radiocsirt.org Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Sat, 03 Oct 2026 01:18:31 +0000 https://cve.radiocsirt.org/vuln/alsa-2023:2523 <p><strong>Affected:</strong> AlmaLinux:9: openssl, AlmaLinux:9: openssl-devel, AlmaLinux:9: openssl-libs, AlmaLinux:9: openssl-perl</p> <p>OpenSSL is a toolkit that implements the Secure Sockets Layer (SSL) and Transport Layer Security (TLS) protocols, as well as a full-strength general-purpose cryptography library.</p> <p>Security Fix(es):</p> <p>* openssl: Using a Custom Cipher with NID_undef may lead to NULL encryption (CVE-2022-3358)</p> <p>For more details about the security issue(s), including the impact, a CVSS score, acknowledgments, and other related information, refer to the CVE page(s) listed in the References section.</p> <p>Additional Changes:</p> <p>For detailed information on changes in this release, see the AlmaLinux Release Notes linked from the References section.</p> <p><strong>Affected:</strong> AlmaLinux:9: openssl, AlmaLinux:9: openssl-devel, AlmaLinux:9: openssl-libs, AlmaLinux:9: openssl-perl</p> <p>OpenSSL is a toolkit that implements the Secure Sockets Layer (SSL) and Transport Layer Security (TLS) protocols, as well as a full-strength general-purpose cryptography library.</p> <p>Security Fix(es):</p> <p>* openssl: Using a Custom Cipher with NID_undef may lead to NULL encryption (CVE-2022-3358)</p> <p>For more details about the security issue(s), including the impact, a CVSS score, acknowledgments, and other related information, refer to the CVE page(s) listed in the References section.</p> <p>Additional Changes:</p> <p>For detailed information on changes in this release, see the AlmaLinux Release Notes linked from the References section.</p> https://cve.radiocsirt.org/vuln/alsa-2023:2523 https://cve.radiocsirt.org/vuln/bdu:2023-00229 bdu:2023-00229 https://cve.radiocsirt.org/vuln/bdu:2023-00229 https://cve.radiocsirt.org/vuln/bell-cve-2022-3358 <p><strong>Withdrawn by the publisher.</strong></p> <p><strong>Withdrawn by the publisher.</strong></p> https://cve.radiocsirt.org/vuln/bell-cve-2022-3358 https://cve.radiocsirt.org/vuln/certfr-2022-avi-911 certfr-2022-avi-911 https://cve.radiocsirt.org/vuln/certfr-2022-avi-911 https://cve.radiocsirt.org/vuln/cleanstart-2026-gk72927 <p><strong>Withdrawn by the publisher.</strong></p> <p><strong>Affected:</strong> CleanStart: openssl</p> <p>Multiple security vulnerabilities affect the openssl package. Issue summary: PBMAC1 parameters in PKCS#12 files are missing validation which can trigger a stack-based buffer overflow, invalid pointer or NULL pointer dereference during MAC verification. See references for individual vulnerability details.</p> <p><strong>Withdrawn by the publisher.</strong></p> <p><strong>Affected:</strong> CleanStart: openssl</p> <p>Multiple security vulnerabilities affect the openssl package. Issue summary: PBMAC1 parameters in PKCS#12 files are missing validation which can trigger a stack-based buffer overflow, invalid pointer or NULL pointer dereference during MAC verification. See references for individual vulnerability details.</p> https://cve.radiocsirt.org/vuln/cleanstart-2026-gk72927 https://cve.radiocsirt.org/vuln/euvd-2026-164214 EUVD-2026-164214 https://cve.radiocsirt.org/vuln/euvd-2026-164214 https://cve.radiocsirt.org/vuln/fkie_cve-2022-3358 <p>OpenSSL supports creating a custom cipher via the legacy EVP_CIPHER_meth_new() function and associated function calls. This function was deprecated in OpenSSL 3.0 and application authors are instead encouraged to use the new provider mechanism in order to implement custom ciphers. OpenSSL versions 3.0.0 to 3.0.5 incorrectly handle legacy custom ciphers passed to the EVP_EncryptInit_ex2(), EVP_DecryptInit_ex2() and EVP_CipherInit_ex2() functions (as well as other similarly named encryption and decryption initialisation functions). Instead of using the custom cipher directly it incorrectly tries to fetch an equivalent cipher from the available providers. An equivalent cipher is found based on the NID passed to EVP_CIPHER_meth_new(). This NID is supposed to represent the unique NID for a given cipher. However it is possible for an application to incorrectly pass NID_undef as this value in the call to EVP_CIPHER_meth_new(). When NID_undef is used in this way the OpenSSL encryption/decryption initialisation function will match the NULL cipher as being equivalent and will fetch this from the available providers. This will succeed if the default provider has been loaded (or if a third party provider has been loaded that offers this cipher). Using the NULL cipher means that the plaintext is emitted as the ciphertext. Applications are only affected by this issue if they call EVP_CIPHER_meth_new() using NID_undef and subsequently use it in a call to an encryption/decryption initialisa…</p> <p>OpenSSL supports creating a custom cipher via the legacy EVP_CIPHER_meth_new() function and associated function calls. This function was deprecated in OpenSSL 3.0 and application authors are instead encouraged to use the new provider mechanism in order to implement custom ciphers. OpenSSL versions 3.0.0 to 3.0.5 incorrectly handle legacy custom ciphers passed to the EVP_EncryptInit_ex2(), EVP_DecryptInit_ex2() and EVP_CipherInit_ex2() functions (as well as other similarly named encryption and decryption initialisation functions). Instead of using the custom cipher directly it incorrectly tries to fetch an equivalent cipher from the available providers. An equivalent cipher is found based on the NID passed to EVP_CIPHER_meth_new(). This NID is supposed to represent the unique NID for a given cipher. However it is possible for an application to incorrectly pass NID_undef as this value in the call to EVP_CIPHER_meth_new(). When NID_undef is used in this way the OpenSSL encryption/decryption initialisation function will match the NULL cipher as being equivalent and will fetch this from the available providers. This will succeed if the default provider has been loaded (or if a third party provider has been loaded that offers this cipher). Using the NULL cipher means that the plaintext is emitted as the ciphertext. Applications are only affected by this issue if they call EVP_CIPHER_meth_new() using NID_undef and subsequently use it in a call to an encryption/decryption initialisa…</p> https://cve.radiocsirt.org/vuln/fkie_cve-2022-3358 https://cve.radiocsirt.org/vuln/ghsa-4f63-89w9-3jjv <p><strong>Affected:</strong> crates.io: openssl-src</p> <p>OpenSSL supports creating a custom cipher via the legacy EVP_CIPHER_meth_new() function and associated function calls. This function was deprecated in OpenSSL 3.0 and application authors are instead encouraged to use the new provider mechanism in order to implement custom ciphers. OpenSSL versions 3.0.0 to 3.0.5 incorrectly handle legacy custom ciphers passed to the EVP_EncryptInit_ex2(), EVP_DecryptInit_ex2() and EVP_CipherInit_ex2() functions (as well as other similarly named encryption and decryption initialisation functions). Instead of using the custom cipher directly it incorrectly tries to fetch an equivalent cipher from the available providers. An equivalent cipher is found based on the NID passed to EVP_CIPHER_meth_new(). This NID is supposed to represent the unique NID for a given cipher. However it is possible for an application to incorrectly pass NID_undef as this value in the call to EVP_CIPHER_meth_new(). When NID_undef is used in this way the OpenSSL encryption/decryption initialisation function will match the NULL cipher as being equivalent and will fetch this from the available providers. This will succeed if the default provider has been loaded (or if a third party provider has been loaded that offers this cipher). Using the NULL cipher means that the plaintext is emitted as the ciphertext. Applications are only affected by this issue if they call EVP_CIPHER_meth_new() using NID_undef and subsequently use it in a call to an encryption/decryption initialisa…</p> <p><strong>Affected:</strong> crates.io: openssl-src</p> <p>OpenSSL supports creating a custom cipher via the legacy EVP_CIPHER_meth_new() function and associated function calls. This function was deprecated in OpenSSL 3.0 and application authors are instead encouraged to use the new provider mechanism in order to implement custom ciphers. OpenSSL versions 3.0.0 to 3.0.5 incorrectly handle legacy custom ciphers passed to the EVP_EncryptInit_ex2(), EVP_DecryptInit_ex2() and EVP_CipherInit_ex2() functions (as well as other similarly named encryption and decryption initialisation functions). Instead of using the custom cipher directly it incorrectly tries to fetch an equivalent cipher from the available providers. An equivalent cipher is found based on the NID passed to EVP_CIPHER_meth_new(). This NID is supposed to represent the unique NID for a given cipher. However it is possible for an application to incorrectly pass NID_undef as this value in the call to EVP_CIPHER_meth_new(). When NID_undef is used in this way the OpenSSL encryption/decryption initialisation function will match the NULL cipher as being equivalent and will fetch this from the available providers. This will succeed if the default provider has been loaded (or if a third party provider has been loaded that offers this cipher). Using the NULL cipher means that the plaintext is emitted as the ciphertext. Applications are only affected by this issue if they call EVP_CIPHER_meth_new() using NID_undef and subsequently use it in a call to an encryption/decryption initialisa…</p> https://cve.radiocsirt.org/vuln/ghsa-4f63-89w9-3jjv https://cve.radiocsirt.org/vuln/gsd-2022-3358 gsd-2022-3358 https://cve.radiocsirt.org/vuln/gsd-2022-3358 https://cve.radiocsirt.org/vuln/opensuse-su-2024:12475-1 <p>libopenssl-3-devel-3.0.7-1.1 on GA media</p> <p>libopenssl-3-devel-3.0.7-1.1 on GA media</p> https://cve.radiocsirt.org/vuln/opensuse-su-2024:12475-1 https://cve.radiocsirt.org/vuln/rustsec-2022-0059 <p><strong>Affected:</strong> crates.io: openssl-src</p> <p>OpenSSL supports creating a custom cipher via the legacy `EVP_CIPHER_meth_new()` function and associated function calls. This function was deprecated in OpenSSL 3.0 and application authors are instead encouraged to use the new provider mechanism in order to implement custom ciphers.</p> <p>OpenSSL versions 3.0.0 to 3.0.5 incorrectly handle legacy custom ciphers passed to the `EVP_EncryptInit_ex2()`, `EVP_DecryptInit_ex2()` and `EVP_CipherInit_ex2()` functions (as well as other similarly named encryption and decryption initialisation functions). Instead of using the custom cipher directly it incorrectly tries to fetch an equivalent cipher from the available providers. An equivalent cipher is found based on the NID passed to `EVP_CIPHER_meth_new()`. This NID is supposed to represent the unique NID for a given cipher. However it is possible for an application to incorrectly pass `NID_undef` as this value in the call to `EVP_CIPHER_meth_new()`. When `NID_undef` is used in this way the OpenSSL encryption/decryption initialisation function will match the NULL cipher as being equivalent and will fetch this from the available providers. This will succeed if the default provider has been loaded (or if a third party provider has been loaded that offers this cipher). Using the NULL cipher means that the plaintext is emitted as the ciphertext.</p> <p>Applications are only affected by this issue if they call `EVP_CIPHER_meth_new()` using `NID_undef` and subsequently use it in a call to an encryption…</p> <p><strong>Affected:</strong> crates.io: openssl-src</p> <p>OpenSSL supports creating a custom cipher via the legacy `EVP_CIPHER_meth_new()` function and associated function calls. This function was deprecated in OpenSSL 3.0 and application authors are instead encouraged to use the new provider mechanism in order to implement custom ciphers.</p> <p>OpenSSL versions 3.0.0 to 3.0.5 incorrectly handle legacy custom ciphers passed to the `EVP_EncryptInit_ex2()`, `EVP_DecryptInit_ex2()` and `EVP_CipherInit_ex2()` functions (as well as other similarly named encryption and decryption initialisation functions). Instead of using the custom cipher directly it incorrectly tries to fetch an equivalent cipher from the available providers. An equivalent cipher is found based on the NID passed to `EVP_CIPHER_meth_new()`. This NID is supposed to represent the unique NID for a given cipher. However it is possible for an application to incorrectly pass `NID_undef` as this value in the call to `EVP_CIPHER_meth_new()`. When `NID_undef` is used in this way the OpenSSL encryption/decryption initialisation function will match the NULL cipher as being equivalent and will fetch this from the available providers. This will succeed if the default provider has been loaded (or if a third party provider has been loaded that offers this cipher). Using the NULL cipher means that the plaintext is emitted as the ciphertext.</p> <p>Applications are only affected by this issue if they call `EVP_CIPHER_meth_new()` using `NID_undef` and subsequently use it in a call to an encryption…</p> https://cve.radiocsirt.org/vuln/rustsec-2022-0059 https://cve.radiocsirt.org/vuln/ubuntu-cve-2022-3358 <p><strong>Affected:</strong> Ubuntu:Pro:16.04:LTS: edk2, Ubuntu:22.04:LTS: openssl</p> <p>OpenSSL supports creating a custom cipher via the legacy EVP_CIPHER_meth_new() function and associated function calls. This function was deprecated in OpenSSL 3.0 and application authors are instead encouraged to use the new provider mechanism in order to implement custom ciphers. OpenSSL versions 3.0.0 to 3.0.5 incorrectly handle legacy custom ciphers passed to the EVP_EncryptInit_ex2(), EVP_DecryptInit_ex2() and EVP_CipherInit_ex2() functions (as well as other similarly named encryption and decryption initialisation functions). Instead of using the custom cipher directly it incorrectly tries to fetch an equivalent cipher from the available providers. An equivalent cipher is found based on the NID passed to EVP_CIPHER_meth_new(). This NID is supposed to represent the unique NID for a given cipher. However it is possible for an application to incorrectly pass NID_undef as this value in the call to EVP_CIPHER_meth_new(). When NID_undef is used in this way the OpenSSL encryption/decryption initialisation function will match the NULL cipher as being equivalent and will fetch this from the available providers. This will succeed if the default provider has been loaded (or if a third party provider has been loaded that offers this cipher). Using the NULL cipher means that the plaintext is emitted as the ciphertext. Applications are only affected by this issue if they call EVP_CIPHER_meth_new() using NID_undef and subsequently use it in a call to an encryption/decryption initialisa…</p> <p><strong>Affected:</strong> Ubuntu:Pro:16.04:LTS: edk2, Ubuntu:22.04:LTS: openssl</p> <p>OpenSSL supports creating a custom cipher via the legacy EVP_CIPHER_meth_new() function and associated function calls. This function was deprecated in OpenSSL 3.0 and application authors are instead encouraged to use the new provider mechanism in order to implement custom ciphers. OpenSSL versions 3.0.0 to 3.0.5 incorrectly handle legacy custom ciphers passed to the EVP_EncryptInit_ex2(), EVP_DecryptInit_ex2() and EVP_CipherInit_ex2() functions (as well as other similarly named encryption and decryption initialisation functions). Instead of using the custom cipher directly it incorrectly tries to fetch an equivalent cipher from the available providers. An equivalent cipher is found based on the NID passed to EVP_CIPHER_meth_new(). This NID is supposed to represent the unique NID for a given cipher. However it is possible for an application to incorrectly pass NID_undef as this value in the call to EVP_CIPHER_meth_new(). When NID_undef is used in this way the OpenSSL encryption/decryption initialisation function will match the NULL cipher as being equivalent and will fetch this from the available providers. This will succeed if the default provider has been loaded (or if a third party provider has been loaded that offers this cipher). Using the NULL cipher means that the plaintext is emitted as the ciphertext. Applications are only affected by this issue if they call EVP_CIPHER_meth_new() using NID_undef and subsequently use it in a call to an encryption/decryption initialisa…</p> https://cve.radiocsirt.org/vuln/ubuntu-cve-2022-3358 https://cve.radiocsirt.org/vuln/wid-sec-w-2022-1690 <p>Ein entfernter, anonymer Angreifer kann eine Schwachstelle in OpenSSL ausnutzen, um Informationen offenzulegen.</p> <p>Ein entfernter, anonymer Angreifer kann eine Schwachstelle in OpenSSL ausnutzen, um Informationen offenzulegen.</p> https://cve.radiocsirt.org/vuln/wid-sec-w-2022-1690