https://vulnerability.circl.lu Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Thu, 01 Oct 2026 01:51:18 +0000 https://vulnerability.circl.lu/vuln/cve-2026-2673 <p><strong>Affected:</strong> OpenSSL, Siemens SIMATIC CN 4100</p> <p>Issue summary: An OpenSSL TLS 1.3 server may fail to negotiate the expected preferred key exchange group when its key exchange group configuration includes the default by using the &#39;DEFAULT&#39; keyword.</p> <p>Impact summary: A less preferred key exchange may be used even when a more preferred group is supported by both client and server, if the group was not included among the client&#39;s initial predicated keyshares. This will sometimes be the case with the new hybrid post-quantum groups, if the client chooses to defer their use until specifically requested by the server.</p> <p>If an OpenSSL TLS 1.3 server&#39;s configuration uses the &#39;DEFAULT&#39; keyword to interpolate the built-in default group list into its own configuration, perhaps adding or removing specific elements, then an implementation defect causes the &#39;DEFAULT&#39; list to lose its &#39;tuple&#39; structure, and all server-supported groups were treated as a single sufficiently secure &#39;tuple&#39;, with the server not sending a Hello Retry Request (HRR) even when a group in a more preferred tuple was mutually supported.</p> <p>As a result, the client and server might fail to negotiate a mutually supported post-quantum key agreement group, such as &#39;X25519MLKEM768&#39;, if the client&#39;s configuration results in only &#39;classical&#39; groups (such as &#39;X25519&#39; being the only ones in the client&#39;s initial keyshare prediction).</p> <p>OpenSSL 3.5 and later support a new syntax for selecting the most preferred TLS 1.3 key agreement group on TLS servers. The old syntax had a single…</p> <p><strong>Affected:</strong> OpenSSL, Siemens SIMATIC CN 4100</p> <p>Issue summary: An OpenSSL TLS 1.3 server may fail to negotiate the expected preferred key exchange group when its key exchange group configuration includes the default by using the &#39;DEFAULT&#39; keyword.</p> <p>Impact summary: A less preferred key exchange may be used even when a more preferred group is supported by both client and server, if the group was not included among the client&#39;s initial predicated keyshares. This will sometimes be the case with the new hybrid post-quantum groups, if the client chooses to defer their use until specifically requested by the server.</p> <p>If an OpenSSL TLS 1.3 server&#39;s configuration uses the &#39;DEFAULT&#39; keyword to interpolate the built-in default group list into its own configuration, perhaps adding or removing specific elements, then an implementation defect causes the &#39;DEFAULT&#39; list to lose its &#39;tuple&#39; structure, and all server-supported groups were treated as a single sufficiently secure &#39;tuple&#39;, with the server not sending a Hello Retry Request (HRR) even when a group in a more preferred tuple was mutually supported.</p> <p>As a result, the client and server might fail to negotiate a mutually supported post-quantum key agreement group, such as &#39;X25519MLKEM768&#39;, if the client&#39;s configuration results in only &#39;classical&#39; groups (such as &#39;X25519&#39; being the only ones in the client&#39;s initial keyshare prediction).</p> <p>OpenSSL 3.5 and later support a new syntax for selecting the most preferred TLS 1.3 key agreement group on TLS servers. The old syntax had a single…</p> https://vulnerability.circl.lu/vuln/cve-2026-2673