Vulnerability-Lookup

BDU:2026-10550 (CVE-2026-2673)

Vulnerability from fstec – Published: 2026-07-27 – Updated: 2026-07-27 – View on bdu.fstec.ru Fixed

Title

Уязвимость инструмента для создания воспроизводимых и перемещаемых окружений Python relenv, связанная с выбором менее безопасного алгоритма в процессе согласования, позволяющая нарушителю выполнить атаку типа «человек посередине»

Summary

Уязвимость инструмента для создания воспроизводимых и перемещаемых окружений Python relenv связана с выбором менее безопасного алгоритма в процессе согласования. Эксплуатация уязвимости может позволить нарушителю, действующему удалённо, выполнить атаку типа «человек посередине»

Severity

6.4 (Medium) CVSS 2.0


                      
                        AV:N/AC:L/Au:N/C:N/I:P/A:P

6.5 (Medium) CVSS 3.1


                      
                        CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:L

Class

Architecture vulnerability

Status

Confirmed by the vendor

Exploitation

Анализ целевого объекта

Incidents

Being clarified

Remediation

Software update

CWE

CWE-757 - Выбор менее безопасного алгоритма в процессе согласования («Algorithm Downgrade»)

Aliases

CVE-2026-2673

References

8 references

URL
http://www.openwall.com/lists/oss-security/2026/03/13/3
https://cert-portal.siemens.com/productcert/html/ssa-032379.html
https://github.com/advisories/GHSA-wj64-gh9j-xm82
https://github.com/openssl/openssl/commit/2157c9d81f7b0bd7dfa25b960e928ec28e8dd63f
https://github.com/openssl/openssl/commit/85977e013f32ceb96aa034c0e741adddc1a05e34
https://nvd.nist.gov/vuln/detail/CVE-2026-2673
https://openssl-library.org/news/secadv/20260313.txt
https://redos.red-soft.ru/search/?iblock_id=24&q=CVE-2026-2673

Impacted products

9 products from 6 vendors

Vendors

ООО «Ред Софт», Red Hat, Inc., Сообщество свободного программного обеспечения, Siemens AG, OpenSSL Software Foundation

Products

РЕД ОС (запись в едином реестре российских программ №3751), Red Hat Enterprise Linux, Debian GNU/Linux, Red Hat Hardened Images, SIMATIC CN 4100, relenv, OpenSSL, Red Hat JBoss Web Server, Red Hat JBoss Core Services

Versions

7.3 (РЕД ОС), 9 (Red Hat Enterprise Linux), 13 (Debian GNU/Linux), 8.0 (РЕД ОС), - (Red Hat Hardened Images), до 5.0 (SIMATIC CN 4100), до 0.22.14 (relenv), до 3.6.2 (OpenSSL), до 3.5.6 (OpenSSL), 7.0.0 (Red Hat JBoss Web Server), 6.2.4 (Red Hat JBoss Web Server), 2.4.62.SP4 (Red Hat JBoss Core Services)

Product types

Operating system, Application software, ПО программно-аппаратного средства АСУ ТП, Security software, Network device, Network software, Микропрограммный код аппаратных компонентов компьютера

Platforms

ООО «Ред Софт» РЕД ОС 7.3 (запись в едином реестре российских программ №3751), Red Hat, Inc. Red Hat Enterprise Linux 9, Сообщество свободного программного обеспечения Debian GNU/Linux 13, ООО «Ред Софт» РЕД ОС 8.0 (запись в едином реестре российских программ №3751)

Mitigations

Использование рекомендаций: https://github.com/advisories/GHSA-wj64-gh9j-xm82 Для Ред ОС: https://redos.red-soft.ru/search/?iblock_id=24&q=CVE-2026-2673 Для OpenSSL: https://openssl-library.org/news/secadv/20260313.txt Для Siemens AG: https://cert-portal.siemens.com/productcert/html/ssa-032379.html

JSON

To clipboard

{
  "CVSS 2.0": "AV:N/AC:L/Au:N/C:N/I:P/A:P",
  "CVSS 3.0": "AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:L",
  "CVSS 4.0": null,
  "remediation_\u0418\u0434\u0435\u043d\u0442\u0438\u0444\u0438\u043a\u0430\u0442\u043e\u0440": null,
  "remediation_\u041d\u0430\u0438\u043c\u0435\u043d\u043e\u0432\u0430\u043d\u0438\u0435": null,
  "\u0412\u0435\u043d\u0434\u043e\u0440 \u041f\u041e": "\u041e\u041e\u041e \u00ab\u0420\u0435\u0434 \u0421\u043e\u0444\u0442\u00bb, Red Hat, Inc., \u0421\u043e\u043e\u0431\u0449\u0435\u0441\u0442\u0432\u043e \u0441\u0432\u043e\u0431\u043e\u0434\u043d\u043e\u0433\u043e \u043f\u0440\u043e\u0433\u0440\u0430\u043c\u043c\u043d\u043e\u0433\u043e \u043e\u0431\u0435\u0441\u043f\u0435\u0447\u0435\u043d\u0438\u044f, Siemens AG, OpenSSL Software Foundation",
  "\u0412\u0435\u0440\u0441\u0438\u044f \u041f\u041e": "7.3 (\u0420\u0415\u0414 \u041e\u0421), 9 (Red Hat Enterprise Linux), 13 (Debian GNU/Linux), 8.0 (\u0420\u0415\u0414 \u041e\u0421), - (Red Hat Hardened Images), \u0434\u043e 5.0 (SIMATIC CN 4100), \u0434\u043e 0.22.14 (relenv), \u0434\u043e 3.6.2 (OpenSSL), \u0434\u043e 3.5.6 (OpenSSL), 7.0.0 (Red Hat JBoss Web Server), 6.2.4 (Red Hat JBoss Web Server), 2.4.62.SP4 (Red Hat JBoss Core Services)",
  "\u0412\u043e\u0437\u043c\u043e\u0436\u043d\u044b\u0435 \u043c\u0435\u0440\u044b \u043f\u043e \u0443\u0441\u0442\u0440\u0430\u043d\u0435\u043d\u0438\u044e": "\u0418\u0441\u043f\u043e\u043b\u044c\u0437\u043e\u0432\u0430\u043d\u0438\u0435 \u0440\u0435\u043a\u043e\u043c\u0435\u043d\u0434\u0430\u0446\u0438\u0439:\nhttps://github.com/advisories/GHSA-wj64-gh9j-xm82\n\n\u0414\u043b\u044f \u0420\u0435\u0434 \u041e\u0421:\nhttps://redos.red-soft.ru/search/?iblock_id=24\u0026q=CVE-2026-2673\n\n\u0414\u043b\u044f OpenSSL:\nhttps://openssl-library.org/news/secadv/20260313.txt\n\n\u0414\u043b\u044f Siemens AG:\nhttps://cert-portal.siemens.com/productcert/html/ssa-032379.html",
  "\u0414\u0430\u0442\u0430 \u0432\u044b\u044f\u0432\u043b\u0435\u043d\u0438\u044f": "13.03.2026",
  "\u0414\u0430\u0442\u0430 \u043f\u043e\u0441\u043b\u0435\u0434\u043d\u0435\u0433\u043e \u043e\u0431\u043d\u043e\u0432\u043b\u0435\u043d\u0438\u044f": "27.07.2026",
  "\u0414\u0430\u0442\u0430 \u043f\u0443\u0431\u043b\u0438\u043a\u0430\u0446\u0438\u0438": "27.07.2026",
  "\u0418\u0434\u0435\u043d\u0442\u0438\u0444\u0438\u043a\u0430\u0442\u043e\u0440": "BDU:2026-10550",
  "\u0418\u0434\u0435\u043d\u0442\u0438\u0444\u0438\u043a\u0430\u0442\u043e\u0440\u044b \u0434\u0440\u0443\u0433\u0438\u0445 \u0441\u0438\u0441\u0442\u0435\u043c \u043e\u043f\u0438\u0441\u0430\u043d\u0438\u0439 \u0443\u044f\u0437\u0432\u0438\u043c\u043e\u0441\u0442\u0438": "CVE-2026-2673",
  "\u0418\u043d\u0444\u043e\u0440\u043c\u0430\u0446\u0438\u044f \u043e\u0431 \u0443\u0441\u0442\u0440\u0430\u043d\u0435\u043d\u0438\u0438": "\u0423\u044f\u0437\u0432\u0438\u043c\u043e\u0441\u0442\u044c \u0443\u0441\u0442\u0440\u0430\u043d\u0435\u043d\u0430",
  "\u041a\u043b\u0430\u0441\u0441 \u0443\u044f\u0437\u0432\u0438\u043c\u043e\u0441\u0442\u0438": "\u0423\u044f\u0437\u0432\u0438\u043c\u043e\u0441\u0442\u044c \u0430\u0440\u0445\u0438\u0442\u0435\u043a\u0442\u0443\u0440\u044b",
  "\u041d\u0430\u0437\u0432\u0430\u043d\u0438\u0435 \u041f\u041e": "\u0420\u0415\u0414 \u041e\u0421 (\u0437\u0430\u043f\u0438\u0441\u044c \u0432 \u0435\u0434\u0438\u043d\u043e\u043c \u0440\u0435\u0435\u0441\u0442\u0440\u0435 \u0440\u043e\u0441\u0441\u0438\u0439\u0441\u043a\u0438\u0445 \u043f\u0440\u043e\u0433\u0440\u0430\u043c\u043c \u21163751), Red Hat Enterprise Linux, Debian GNU/Linux, Red Hat Hardened Images, SIMATIC CN 4100, relenv, OpenSSL, Red Hat JBoss Web Server, Red Hat JBoss Core Services",
  "\u041d\u0430\u0438\u043c\u0435\u043d\u043e\u0432\u0430\u043d\u0438\u0435 \u041e\u0421 \u0438 \u0442\u0438\u043f \u0430\u043f\u043f\u0430\u0440\u0430\u0442\u043d\u043e\u0439 \u043f\u043b\u0430\u0442\u0444\u043e\u0440\u043c\u044b": "\u041e\u041e\u041e \u00ab\u0420\u0435\u0434 \u0421\u043e\u0444\u0442\u00bb \u0420\u0415\u0414 \u041e\u0421 7.3  (\u0437\u0430\u043f\u0438\u0441\u044c \u0432 \u0435\u0434\u0438\u043d\u043e\u043c \u0440\u0435\u0435\u0441\u0442\u0440\u0435 \u0440\u043e\u0441\u0441\u0438\u0439\u0441\u043a\u0438\u0445 \u043f\u0440\u043e\u0433\u0440\u0430\u043c\u043c \u21163751), Red Hat, Inc. Red Hat Enterprise Linux 9 , \u0421\u043e\u043e\u0431\u0449\u0435\u0441\u0442\u0432\u043e \u0441\u0432\u043e\u0431\u043e\u0434\u043d\u043e\u0433\u043e \u043f\u0440\u043e\u0433\u0440\u0430\u043c\u043c\u043d\u043e\u0433\u043e \u043e\u0431\u0435\u0441\u043f\u0435\u0447\u0435\u043d\u0438\u044f Debian GNU/Linux 13 , \u041e\u041e\u041e \u00ab\u0420\u0435\u0434 \u0421\u043e\u0444\u0442\u00bb \u0420\u0415\u0414 \u041e\u0421 8.0  (\u0437\u0430\u043f\u0438\u0441\u044c \u0432 \u0435\u0434\u0438\u043d\u043e\u043c \u0440\u0435\u0435\u0441\u0442\u0440\u0435 \u0440\u043e\u0441\u0441\u0438\u0439\u0441\u043a\u0438\u0445 \u043f\u0440\u043e\u0433\u0440\u0430\u043c\u043c \u21163751)",
  "\u041d\u0430\u0438\u043c\u0435\u043d\u043e\u0432\u0430\u043d\u0438\u0435 \u0443\u044f\u0437\u0432\u0438\u043c\u043e\u0441\u0442\u0438": "\u0423\u044f\u0437\u0432\u0438\u043c\u043e\u0441\u0442\u044c \u0438\u043d\u0441\u0442\u0440\u0443\u043c\u0435\u043d\u0442\u0430 \u0434\u043b\u044f \u0441\u043e\u0437\u0434\u0430\u043d\u0438\u044f \u0432\u043e\u0441\u043f\u0440\u043e\u0438\u0437\u0432\u043e\u0434\u0438\u043c\u044b\u0445 \u0438 \u043f\u0435\u0440\u0435\u043c\u0435\u0449\u0430\u0435\u043c\u044b\u0445 \u043e\u043a\u0440\u0443\u0436\u0435\u043d\u0438\u0439 Python relenv, \u0441\u0432\u044f\u0437\u0430\u043d\u043d\u0430\u044f \u0441 \u0432\u044b\u0431\u043e\u0440\u043e\u043c \u043c\u0435\u043d\u0435\u0435 \u0431\u0435\u0437\u043e\u043f\u0430\u0441\u043d\u043e\u0433\u043e \u0430\u043b\u0433\u043e\u0440\u0438\u0442\u043c\u0430 \u0432 \u043f\u0440\u043e\u0446\u0435\u0441\u0441\u0435 \u0441\u043e\u0433\u043b\u0430\u0441\u043e\u0432\u0430\u043d\u0438\u044f, \u043f\u043e\u0437\u0432\u043e\u043b\u044f\u044e\u0449\u0430\u044f \u043d\u0430\u0440\u0443\u0448\u0438\u0442\u0435\u043b\u044e \u0432\u044b\u043f\u043e\u043b\u043d\u0438\u0442\u044c \u0430\u0442\u0430\u043a\u0443 \u0442\u0438\u043f\u0430 \u00ab\u0447\u0435\u043b\u043e\u0432\u0435\u043a \u043f\u043e\u0441\u0435\u0440\u0435\u0434\u0438\u043d\u0435\u00bb",
  "\u041d\u0430\u043b\u0438\u0447\u0438\u0435 \u044d\u043a\u0441\u043f\u043b\u043e\u0439\u0442\u0430": "\u0414\u0430\u043d\u043d\u044b\u0435 \u0443\u0442\u043e\u0447\u043d\u044f\u044e\u0442\u0441\u044f",
  "\u041e\u043f\u0438\u0441\u0430\u043d\u0438\u0435 \u043e\u0448\u0438\u0431\u043a\u0438 CWE": "\u0412\u044b\u0431\u043e\u0440 \u043c\u0435\u043d\u0435\u0435 \u0431\u0435\u0437\u043e\u043f\u0430\u0441\u043d\u043e\u0433\u043e \u0430\u043b\u0433\u043e\u0440\u0438\u0442\u043c\u0430 \u0432 \u043f\u0440\u043e\u0446\u0435\u0441\u0441\u0435 \u0441\u043e\u0433\u043b\u0430\u0441\u043e\u0432\u0430\u043d\u0438\u044f (\u00abAlgorithm Downgrade\u00bb) (CWE-757)",
  "\u041e\u043f\u0438\u0441\u0430\u043d\u0438\u0435 \u0443\u044f\u0437\u0432\u0438\u043c\u043e\u0441\u0442\u0438": "\u0423\u044f\u0437\u0432\u0438\u043c\u043e\u0441\u0442\u044c \u0438\u043d\u0441\u0442\u0440\u0443\u043c\u0435\u043d\u0442\u0430 \u0434\u043b\u044f \u0441\u043e\u0437\u0434\u0430\u043d\u0438\u044f \u0432\u043e\u0441\u043f\u0440\u043e\u0438\u0437\u0432\u043e\u0434\u0438\u043c\u044b\u0445 \u0438 \u043f\u0435\u0440\u0435\u043c\u0435\u0449\u0430\u0435\u043c\u044b\u0445 \u043e\u043a\u0440\u0443\u0436\u0435\u043d\u0438\u0439 Python relenv \u0441\u0432\u044f\u0437\u0430\u043d\u0430 \u0441 \u0432\u044b\u0431\u043e\u0440\u043e\u043c \u043c\u0435\u043d\u0435\u0435 \u0431\u0435\u0437\u043e\u043f\u0430\u0441\u043d\u043e\u0433\u043e \u0430\u043b\u0433\u043e\u0440\u0438\u0442\u043c\u0430 \u0432 \u043f\u0440\u043e\u0446\u0435\u0441\u0441\u0435 \u0441\u043e\u0433\u043b\u0430\u0441\u043e\u0432\u0430\u043d\u0438\u044f. \u042d\u043a\u0441\u043f\u043b\u0443\u0430\u0442\u0430\u0446\u0438\u044f \u0443\u044f\u0437\u0432\u0438\u043c\u043e\u0441\u0442\u0438 \u043c\u043e\u0436\u0435\u0442 \u043f\u043e\u0437\u0432\u043e\u043b\u0438\u0442\u044c \u043d\u0430\u0440\u0443\u0448\u0438\u0442\u0435\u043b\u044e, \u0434\u0435\u0439\u0441\u0442\u0432\u0443\u044e\u0449\u0435\u043c\u0443 \u0443\u0434\u0430\u043b\u0451\u043d\u043d\u043e, \u0432\u044b\u043f\u043e\u043b\u043d\u0438\u0442\u044c \u0430\u0442\u0430\u043a\u0443 \u0442\u0438\u043f\u0430 \u00ab\u0447\u0435\u043b\u043e\u0432\u0435\u043a \u043f\u043e\u0441\u0435\u0440\u0435\u0434\u0438\u043d\u0435\u00bb",
  "\u041f\u043e\u0441\u043b\u0435\u0434\u0441\u0442\u0432\u0438\u044f \u044d\u043a\u0441\u043f\u043b\u0443\u0430\u0442\u0430\u0446\u0438\u0438 \u0443\u044f\u0437\u0432\u0438\u043c\u043e\u0441\u0442\u0438": null,
  "\u041f\u0440\u043e\u0447\u0430\u044f \u0438\u043d\u0444\u043e\u0440\u043c\u0430\u0446\u0438\u044f": null,
  "\u0421\u0432\u044f\u0437\u044c \u0441 \u0438\u043d\u0446\u0438\u0434\u0435\u043d\u0442\u0430\u043c\u0438 \u0418\u0411": "\u0414\u0430\u043d\u043d\u044b\u0435 \u0443\u0442\u043e\u0447\u043d\u044f\u044e\u0442\u0441\u044f",
  "\u0421\u043e\u0441\u0442\u043e\u044f\u043d\u0438\u0435 \u0443\u044f\u0437\u0432\u0438\u043c\u043e\u0441\u0442\u0438": "\u041e\u043f\u0443\u0431\u043b\u0438\u043a\u043e\u0432\u0430\u043d\u0430",
  "\u0421\u043f\u043e\u0441\u043e\u0431 \u0443\u0441\u0442\u0440\u0430\u043d\u0435\u043d\u0438\u044f": "\u041e\u0431\u043d\u043e\u0432\u043b\u0435\u043d\u0438\u0435 \u043f\u0440\u043e\u0433\u0440\u0430\u043c\u043c\u043d\u043e\u0433\u043e \u043e\u0431\u0435\u0441\u043f\u0435\u0447\u0435\u043d\u0438\u044f",
  "\u0421\u043f\u043e\u0441\u043e\u0431 \u044d\u043a\u0441\u043f\u043b\u0443\u0430\u0442\u0430\u0446\u0438\u0438": "\u0410\u043d\u0430\u043b\u0438\u0437 \u0446\u0435\u043b\u0435\u0432\u043e\u0433\u043e \u043e\u0431\u044a\u0435\u043a\u0442\u0430",
  "\u0421\u0441\u044b\u043b\u043a\u0438 \u043d\u0430 \u0438\u0441\u0442\u043e\u0447\u043d\u0438\u043a\u0438": "http://www.openwall.com/lists/oss-security/2026/03/13/3\nhttps://cert-portal.siemens.com/productcert/html/ssa-032379.html\nhttps://github.com/advisories/GHSA-wj64-gh9j-xm82\nhttps://github.com/openssl/openssl/commit/2157c9d81f7b0bd7dfa25b960e928ec28e8dd63f\nhttps://github.com/openssl/openssl/commit/85977e013f32ceb96aa034c0e741adddc1a05e34\nhttps://nvd.nist.gov/vuln/detail/CVE-2026-2673\nhttps://openssl-library.org/news/secadv/20260313.txt\nhttps://redos.red-soft.ru/search/?iblock_id=24\u0026q=CVE-2026-2673",
  "\u0421\u0442\u0430\u0442\u0443\u0441 \u0443\u044f\u0437\u0432\u0438\u043c\u043e\u0441\u0442\u0438": "\u041f\u043e\u0434\u0442\u0432\u0435\u0440\u0436\u0434\u0435\u043d\u0430 \u043f\u0440\u043e\u0438\u0437\u0432\u043e\u0434\u0438\u0442\u0435\u043b\u0435\u043c",
  "\u0422\u0438\u043f \u041f\u041e": "\u041e\u043f\u0435\u0440\u0430\u0446\u0438\u043e\u043d\u043d\u0430\u044f \u0441\u0438\u0441\u0442\u0435\u043c\u0430, \u041f\u0440\u0438\u043a\u043b\u0430\u0434\u043d\u043e\u0435 \u041f\u041e \u0438\u043d\u0444\u043e\u0440\u043c\u0430\u0446\u0438\u043e\u043d\u043d\u044b\u0445 \u0441\u0438\u0441\u0442\u0435\u043c, \u041f\u041e \u043f\u0440\u043e\u0433\u0440\u0430\u043c\u043c\u043d\u043e-\u0430\u043f\u043f\u0430\u0440\u0430\u0442\u043d\u043e\u0433\u043e \u0441\u0440\u0435\u0434\u0441\u0442\u0432\u0430 \u0410\u0421\u0423 \u0422\u041f, \u041f\u0440\u043e\u0433\u0440\u0430\u043c\u043c\u043d\u043e\u0435 \u0441\u0440\u0435\u0434\u0441\u0442\u0432\u043e \u0437\u0430\u0449\u0438\u0442\u044b, \u0421\u0435\u0442\u0435\u0432\u043e\u0435 \u0441\u0440\u0435\u0434\u0441\u0442\u0432\u043e, \u0421\u0435\u0442\u0435\u0432\u043e\u0435 \u043f\u0440\u043e\u0433\u0440\u0430\u043c\u043c\u043d\u043e\u0435 \u0441\u0440\u0435\u0434\u0441\u0442\u0432\u043e, \u041c\u0438\u043a\u0440\u043e\u043f\u0440\u043e\u0433\u0440\u0430\u043c\u043c\u043d\u044b\u0439 \u043a\u043e\u0434 \u0430\u043f\u043f\u0430\u0440\u0430\u0442\u043d\u044b\u0445 \u043a\u043e\u043c\u043f\u043e\u043d\u0435\u043d\u0442\u043e\u0432 \u043a\u043e\u043c\u043f\u044c\u044e\u0442\u0435\u0440\u0430",
  "\u0422\u0438\u043f \u043e\u0448\u0438\u0431\u043a\u0438 CWE": "CWE-757",
  "\u0423\u0440\u043e\u0432\u0435\u043d\u044c \u043e\u043f\u0430\u0441\u043d\u043e\u0441\u0442\u0438 \u0443\u044f\u0437\u0432\u0438\u043c\u043e\u0441\u0442\u0438": "\u0421\u0440\u0435\u0434\u043d\u0438\u0439 \u0443\u0440\u043e\u0432\u0435\u043d\u044c \u043e\u043f\u0430\u0441\u043d\u043e\u0441\u0442\u0438 (\u0431\u0430\u0437\u043e\u0432\u0430\u044f \u043e\u0446\u0435\u043d\u043a\u0430 CVSS 2.0 \u0441\u043e\u0441\u0442\u0430\u0432\u043b\u044f\u0435\u0442 6,4)\n\u0421\u0440\u0435\u0434\u043d\u0438\u0439 \u0443\u0440\u043e\u0432\u0435\u043d\u044c \u043e\u043f\u0430\u0441\u043d\u043e\u0441\u0442\u0438 (\u0431\u0430\u0437\u043e\u0432\u0430\u044f \u043e\u0446\u0435\u043d\u043a\u0430 CVSS 3.1 \u0441\u043e\u0441\u0442\u0430\u0432\u043b\u044f\u0435\u0442 6,5)"
}

CVE-2026-2673 (GCVE-0-2026-2673)

Vulnerability from cvelistv5 – Published: 2026-03-13 13:23 – Updated: 2026-05-18 19:23

Title

OpenSSL TLS 1.3 server may choose unexpected key agreement group

Summary

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 'DEFAULT' keyword. 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'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. If an OpenSSL TLS 1.3 server's configuration uses the 'DEFAULT' 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 'DEFAULT' list to lose its 'tuple' structure, and all server-supported groups were treated as a single sufficiently secure 'tuple', with the server not sending a Hello Retry Request (HRR) even when a group in a more preferred tuple was mutually supported. As a result, the client and server might fail to negotiate a mutually supported post-quantum key agreement group, such as 'X25519MLKEM768', if the client's configuration results in only 'classical' groups (such as 'X25519' being the only ones in the client's initial keyshare prediction). 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 'flat' list of groups, and treated all the supported groups as sufficiently secure. If any of the keyshares predicted by the client were supported by the server the most preferred among these was selected, even if other groups supported by the client, but not included in the list of predicted keyshares would have been more preferred, if included. The new syntax partitions the groups into distinct 'tuples' of roughly equivalent security. Within each tuple the most preferred group included among the client's predicted keyshares is chosen, but if the client supports a group from a more preferred tuple, but did not predict any corresponding keyshares, the server will ask the client to retry the ClientHello (by issuing a Hello Retry Request or HRR) with the most preferred mutually supported group. The above works as expected when the server's configuration uses the built-in default group list, or explicitly defines its own list by directly defining the various desired groups and group 'tuples'. No OpenSSL FIPS modules are affected by this issue, the code in question lies outside the FIPS boundary. OpenSSL 3.6 and 3.5 are vulnerable to this issue. OpenSSL 3.6 users should upgrade to OpenSSL 3.6.2 once it is released. OpenSSL 3.5 users should upgrade to OpenSSL 3.5.6 once it is released. OpenSSL 3.4, 3.3, 3.0, 1.0.2 and 1.1.1 are not affected by this issue.

Severity

6.5 (Medium)


                        
                          CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:L

SSVC

Exploitation: none Automatable: yes Technical Impact: partial

CISA Coordinator · CISA-ADP (v2.0.3)

Decision recorded 2026-03-17 17:17 UTC

CWE

CWE-757 - Selection of Less-Secure Algorithm During Negotiation ('Algorithm Downgrade')

Assigner

openssl CNA under the mitre root

CNA scorecard B 78/100 over 48 records in the last 180 days details

References

5 references

URL	Tags
https://openssl-library.org/news/secadv/20260313.txt	vendor-advisory
https://github.com/openssl/openssl/commit/2157c9d…	patch
https://github.com/openssl/openssl/commit/85977e0…	patch
http://www.openwall.com/lists/oss-security/2026/03/13/3
https://cert-portal.siemens.com/productcert/html/…

Impacted products

2 products

Vendor	Product	Version
OpenSSL	OpenSSL	Affected: 3.6.0 , < 3.6.2 (semver) Affected: 3.5.0 , < 3.5.6 (semver)
Siemens	SIMATIC CN 4100	Affected: 0 , < V5.0 (custom)

Date Public

2026-03-13 14:00

Credits

Viktor Dukhovni Viktor Dukhovni

Show details on NVD website

JSON

To clipboard

{
  "containers": {
    "adp": [
      {
        "providerMetadata": {
          "dateUpdated": "2026-03-13T15:15:21.059Z",
          "orgId": "af854a3a-2127-422b-91ae-364da2661108",
          "shortName": "CVE"
        },
        "references": [
          {
            "url": "http://www.openwall.com/lists/oss-security/2026/03/13/3"
          }
        ],
        "title": "CVE Program Container"
      },
      {
        "metrics": [
          {
            "cvssV3_1": {
              "attackComplexity": "LOW",
              "attackVector": "NETWORK",
              "availabilityImpact": "LOW",
              "baseScore": 6.5,
              "baseSeverity": "MEDIUM",
              "confidentialityImpact": "NONE",
              "integrityImpact": "LOW",
              "privilegesRequired": "NONE",
              "scope": "UNCHANGED",
              "userInteraction": "NONE",
              "vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:L",
              "version": "3.1"
            }
          },
          {
            "other": {
              "content": {
                "id": "CVE-2026-2673",
                "options": [
                  {
                    "Exploitation": "none"
                  },
                  {
                    "Automatable": "yes"
                  },
                  {
                    "Technical Impact": "partial"
                  }
                ],
                "role": "CISA Coordinator",
                "timestamp": "2026-03-17T17:17:17.444679Z",
                "version": "2.0.3"
              },
              "type": "ssvc"
            }
          }
        ],
        "providerMetadata": {
          "dateUpdated": "2026-05-18T19:23:37.078Z",
          "orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
          "shortName": "CISA-ADP"
        },
        "title": "CISA ADP Vulnrichment"
      },
      {
        "affected": [
          {
            "defaultStatus": "unknown",
            "product": "SIMATIC CN 4100",
            "vendor": "Siemens",
            "versions": [
              {
                "lessThan": "V5.0",
                "status": "affected",
                "version": "0",
                "versionType": "custom"
              }
            ]
          }
        ],
        "providerMetadata": {
          "dateUpdated": "2026-05-12T12:08:46.771Z",
          "orgId": "0b142b55-0307-4c5a-b3c9-f314f3fb7c5e",
          "shortName": "siemens-SADP"
        },
        "references": [
          {
            "url": "https://cert-portal.siemens.com/productcert/html/ssa-032379.html"
          }
        ],
        "x_adpType": "supplier"
      }
    ],
    "cna": {
      "affected": [
        {
          "defaultStatus": "unaffected",
          "product": "OpenSSL",
          "vendor": "OpenSSL",
          "versions": [
            {
              "lessThan": "3.6.2",
              "status": "affected",
              "version": "3.6.0",
              "versionType": "semver"
            },
            {
              "lessThan": "3.5.6",
              "status": "affected",
              "version": "3.5.0",
              "versionType": "semver"
            }
          ]
        }
      ],
      "credits": [
        {
          "lang": "en",
          "type": "reporter",
          "value": "Viktor Dukhovni"
        },
        {
          "lang": "en",
          "type": "remediation developer",
          "value": "Viktor Dukhovni"
        }
      ],
      "datePublic": "2026-03-13T14:00:00.000Z",
      "descriptions": [
        {
          "lang": "en",
          "supportingMedia": [
            {
              "base64": false,
              "type": "text/html",
              "value": "Issue summary: An OpenSSL TLS 1.3 server may fail to negotiate the expected\u003cbr\u003epreferred key exchange group when its key exchange group configuration includes\u003cbr\u003ethe default by using the \u0027DEFAULT\u0027 keyword.\u003cbr\u003e\u003cbr\u003eImpact summary: A less preferred key exchange may be used even when a more\u003cbr\u003epreferred group is supported by both client and server, if the group\u003cbr\u003ewas not included among the client\u0027s initial predicated keyshares.\u003cbr\u003eThis will sometimes be the case with the new hybrid post-quantum groups,\u003cbr\u003eif the client chooses to defer their use until specifically requested by\u003cbr\u003ethe server.\u003cbr\u003e\u003cbr\u003eIf an OpenSSL TLS 1.3 server\u0027s configuration uses the \u0027DEFAULT\u0027 keyword to\u003cbr\u003einterpolate the built-in default group list into its own configuration, perhaps\u003cbr\u003eadding or removing specific elements, then an implementation defect causes the\u003cbr\u003e\u0027DEFAULT\u0027 list to lose its \u0027tuple\u0027 structure, and all server-supported groups\u003cbr\u003ewere treated as a single sufficiently secure \u0027tuple\u0027, with the server not\u003cbr\u003esending a Hello Retry Request (HRR) even when a group in a more preferred tuple\u003cbr\u003ewas mutually supported.\u003cbr\u003e\u003cbr\u003eAs a result, the client and server might fail to negotiate a mutually supported\u003cbr\u003epost-quantum key agreement group, such as \u0027X25519MLKEM768\u0027, if the client\u0027s\u003cbr\u003econfiguration results in only \u0027classical\u0027 groups (such as \u0027X25519\u0027 being the\u003cbr\u003eonly ones in the client\u0027s initial keyshare prediction).\u003cbr\u003e\u003cbr\u003eOpenSSL 3.5 and later support a new syntax for selecting the most preferred TLS\u003cbr\u003e1.3 key agreement group on TLS servers.  The old syntax had a single \u0027flat\u0027\u003cbr\u003elist of groups, and treated all the supported groups as sufficiently secure.\u003cbr\u003eIf any of the keyshares predicted by the client were supported by the server\u003cbr\u003ethe most preferred among these was selected, even if other groups supported by\u003cbr\u003ethe client, but not included in the list of predicted keyshares would have been\u003cbr\u003emore preferred, if included.\u003cbr\u003e\u003cbr\u003eThe new syntax partitions the groups into distinct \u0027tuples\u0027 of roughly\u003cbr\u003eequivalent security.  Within each tuple the most preferred group included among\u003cbr\u003ethe client\u0027s predicted keyshares is chosen, but if the client supports a group\u003cbr\u003efrom a more preferred tuple, but did not predict any corresponding keyshares,\u003cbr\u003ethe server will ask the client to retry the ClientHello (by issuing a Hello\u003cbr\u003eRetry Request or HRR) with the most preferred mutually supported group.\u003cbr\u003e\u003cbr\u003eThe above works as expected when the server\u0027s configuration uses the built-in\u003cbr\u003edefault group list, or explicitly defines its own list by directly defining the\u003cbr\u003evarious desired groups and group \u0027tuples\u0027.\u003cbr\u003e\u003cbr\u003eNo OpenSSL FIPS modules are affected by this issue, the code in question lies\u003cbr\u003eoutside the FIPS boundary.\u003cbr\u003e\u003cbr\u003eOpenSSL 3.6 and 3.5 are vulnerable to this issue.\u003cbr\u003e\u003cbr\u003eOpenSSL 3.6 users should upgrade to OpenSSL 3.6.2 once it is released.\u003cbr\u003eOpenSSL 3.5 users should upgrade to OpenSSL 3.5.6 once it is released.\u003cbr\u003e\u003cbr\u003eOpenSSL 3.4, 3.3, 3.0, 1.0.2 and 1.1.1 are not affected by this issue."
            }
          ],
          "value": "Issue summary: An OpenSSL TLS 1.3 server may fail to negotiate the expected\npreferred key exchange group when its key exchange group configuration includes\nthe default by using the \u0027DEFAULT\u0027 keyword.\n\nImpact summary: A less preferred key exchange may be used even when a more\npreferred group is supported by both client and server, if the group\nwas not included among the client\u0027s initial predicated keyshares.\nThis will sometimes be the case with the new hybrid post-quantum groups,\nif the client chooses to defer their use until specifically requested by\nthe server.\n\nIf an OpenSSL TLS 1.3 server\u0027s configuration uses the \u0027DEFAULT\u0027 keyword to\ninterpolate the built-in default group list into its own configuration, perhaps\nadding or removing specific elements, then an implementation defect causes the\n\u0027DEFAULT\u0027 list to lose its \u0027tuple\u0027 structure, and all server-supported groups\nwere treated as a single sufficiently secure \u0027tuple\u0027, with the server not\nsending a Hello Retry Request (HRR) even when a group in a more preferred tuple\nwas mutually supported.\n\nAs a result, the client and server might fail to negotiate a mutually supported\npost-quantum key agreement group, such as \u0027X25519MLKEM768\u0027, if the client\u0027s\nconfiguration results in only \u0027classical\u0027 groups (such as \u0027X25519\u0027 being the\nonly ones in the client\u0027s initial keyshare prediction).\n\nOpenSSL 3.5 and later support a new syntax for selecting the most preferred TLS\n1.3 key agreement group on TLS servers.  The old syntax had a single \u0027flat\u0027\nlist of groups, and treated all the supported groups as sufficiently secure.\nIf any of the keyshares predicted by the client were supported by the server\nthe most preferred among these was selected, even if other groups supported by\nthe client, but not included in the list of predicted keyshares would have been\nmore preferred, if included.\n\nThe new syntax partitions the groups into distinct \u0027tuples\u0027 of roughly\nequivalent security.  Within each tuple the most preferred group included among\nthe client\u0027s predicted keyshares is chosen, but if the client supports a group\nfrom a more preferred tuple, but did not predict any corresponding keyshares,\nthe server will ask the client to retry the ClientHello (by issuing a Hello\nRetry Request or HRR) with the most preferred mutually supported group.\n\nThe above works as expected when the server\u0027s configuration uses the built-in\ndefault group list, or explicitly defines its own list by directly defining the\nvarious desired groups and group \u0027tuples\u0027.\n\nNo OpenSSL FIPS modules are affected by this issue, the code in question lies\noutside the FIPS boundary.\n\nOpenSSL 3.6 and 3.5 are vulnerable to this issue.\n\nOpenSSL 3.6 users should upgrade to OpenSSL 3.6.2 once it is released.\nOpenSSL 3.5 users should upgrade to OpenSSL 3.5.6 once it is released.\n\nOpenSSL 3.4, 3.3, 3.0, 1.0.2 and 1.1.1 are not affected by this issue."
        }
      ],
      "metrics": [
        {
          "format": "other",
          "other": {
            "content": {
              "text": "Low"
            },
            "type": "https://openssl-library.org/policies/general/security-policy/"
          }
        }
      ],
      "problemTypes": [
        {
          "descriptions": [
            {
              "cweId": "CWE-757",
              "description": "CWE-757 Selection of Less-Secure Algorithm During Negotiation (\u0027Algorithm Downgrade\u0027)",
              "lang": "en",
              "type": "CWE"
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-03-13T13:23:00.376Z",
        "orgId": "3a12439a-ef3a-4c79-92e6-6081a721f1e5",
        "shortName": "openssl"
      },
      "references": [
        {
          "name": "OpenSSL Advisory",
          "tags": [
            "vendor-advisory"
          ],
          "url": "https://openssl-library.org/news/secadv/20260313.txt"
        },
        {
          "name": "3.6.2 git commit",
          "tags": [
            "patch"
          ],
          "url": "https://github.com/openssl/openssl/commit/2157c9d81f7b0bd7dfa25b960e928ec28e8dd63f"
        },
        {
          "name": "3.5.6 git commit",
          "tags": [
            "patch"
          ],
          "url": "https://github.com/openssl/openssl/commit/85977e013f32ceb96aa034c0e741adddc1a05e34"
        }
      ],
      "source": {
        "discovery": "UNKNOWN"
      },
      "title": "OpenSSL TLS 1.3 server may choose unexpected key agreement group",
      "x_generator": {
        "engine": "Vulnogram 0.2.0"
      }
    }
  },
  "cveMetadata": {
    "assignerOrgId": "3a12439a-ef3a-4c79-92e6-6081a721f1e5",
    "assignerShortName": "openssl",
    "cveId": "CVE-2026-2673",
    "datePublished": "2026-03-13T13:23:00.376Z",
    "dateReserved": "2026-02-18T09:41:04.155Z",
    "dateUpdated": "2026-05-18T19:23:37.078Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2"
}

Sightings

Author	Source	Type	Date	Other

Nomenclature

Seen: The vulnerability was mentioned, discussed, or observed by the user.
Confirmed: The vulnerability has been validated from an analyst's perspective.
Published Proof of Concept: A public proof of concept is available for this vulnerability.
Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
Not confirmed: The user expressed doubt about the validity of the vulnerability.
Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.

Vulnerability timeline

Sightings and recorded dates, grouped by day · UTC

Order JSON

How durations are calculated

Following the VTEM framework (Black Hat USA 2015), time to patch starts when the vendor or a coordinator was informed, total time to patch at discovery, and disclosure to patch at public disclosure; vendor response time runs from the report to its acknowledgement. Time to exploit and time unpatched start at the earliest discovery or report, falling back to public disclosure. Unpatched time ends at the first recorded patch, or the calculation time when no patch is recorded. Exploitation to patch shows the interval between those two events; a published proof of concept is a public exploit, not exploitation.

Each result shows its source dates. A negative interval means the end event came first; when date-only inputs leave the order open, the result says so. Date-only inputs are approximate. The earliest evidence wins: KEV report dates and sightings are labelled as such. Records describing another vulnerability are listed but never calculated from, and a PoC alone does not establish exploitation. Missing patch evidence does not prove that no patch exists. Filters below change the event list only.

Publication & reservation Sightings KEV catalogs Other timestamps

Loading timeline…

The MITRE ATT&CK techniques below are AI-generated suggestions, inferred from the description of the vulnerability by the CIRCL/vulnerability-attack-technique-classification-roberta-base model, served locally by ML-Gateway. They have not been verified by an analyst and are provided for guidance only.
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Browse all ATT&CK techniques and the vulnerabilities related to each.

Related by attack behaviour

Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.

Action not permitted