<?xml version='1.0' encoding='UTF-8'?>
<?xml-stylesheet href="/static/style.xsl" type="text/xsl"?>
<rss xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/" version="2.0">
  <channel>
    <title>Most recent entries from all</title>
    <link>https://vulnerability.circl.lu</link>
    <description>Contains only the most 10 recent entries.</description>
    <docs>http://www.rssboard.org/rss-specification</docs>
    <generator>python-feedgen</generator>
    <language>en</language>
    <lastBuildDate>Tue, 29 Sep 2026 10:28:20 +0000</lastBuildDate>
    <item>
      <title>CVE-2022-3358 — Using a Custom Cipher with NID_undef may lead to NULL encryption</title>
      <link>https://vulnerability.circl.lu/vuln/cve-2022-3358</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; OpenSSL&lt;/p&gt;
&lt;p&gt;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…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; OpenSSL&lt;/p&gt;
&lt;p&gt;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…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://vulnerability.circl.lu/vuln/cve-2022-3358</guid>
    </item>
    <item>
      <title>USN-5710-1 — openssl vulnerabilities</title>
      <link>https://vulnerability.circl.lu/vuln/usn-5710-1</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Ubuntu:22.04:LTS: openssl&lt;/p&gt;
&lt;p&gt;It was discovered that OpenSSL incorrectly handled certain X.509 Email
Addresses. If a certificate authority were tricked into signing a
specially-crafted certificate, a remote attacker could possibly use this
issue to cause OpenSSL to crash, resulting in a denial of service. The
default compiler options for affected releases reduce the vulnerability to
a denial of service. (CVE-2022-3602, CVE-2022-3786)&lt;/p&gt;
&lt;p&gt;It was discovered that OpenSSL incorrectly handled applications creating
custom ciphers via the legacy EVP_CIPHER_meth_new() function. This issue
could cause certain applications that mishandled values to the function to
possibly end up with a NULL cipher and messages in plaintext.
(CVE-2022-3358)&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Ubuntu:22.04:LTS: openssl&lt;/p&gt;
&lt;p&gt;It was discovered that OpenSSL incorrectly handled certain X.509 Email
Addresses. If a certificate authority were tricked into signing a
specially-crafted certificate, a remote attacker could possibly use this
issue to cause OpenSSL to crash, resulting in a denial of service. The
default compiler options for affected releases reduce the vulnerability to
a denial of service. (CVE-2022-3602, CVE-2022-3786)&lt;/p&gt;
&lt;p&gt;It was discovered that OpenSSL incorrectly handled applications creating
custom ciphers via the legacy EVP_CIPHER_meth_new() function. This issue
could cause certain applications that mishandled values to the function to
possibly end up with a NULL cipher and messages in plaintext.
(CVE-2022-3358)&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://vulnerability.circl.lu/vuln/usn-5710-1</guid>
    </item>
  </channel>
</rss>
