CWE-757
AllowedSelection of Less-Secure Algorithm During Negotiation ('Algorithm Downgrade')
Abstraction: Base · Status: Incomplete
A protocol or its implementation supports interaction between multiple actors and allows those actors to negotiate which algorithm should be used as a protection mechanism such as encryption or authentication, but it does not select the strongest algorithm that is available to both parties.
48 vulnerabilities reference this CWE, most recent first.
GHSA-P9JG-FCR6-3MHF
Vulnerability from github – Published: 2026-07-01 21:51 – Updated: 2026-07-01 21:51Summary
A flaw in com.ongres.scram:scram-client allows an attacker capable of performing a TLS man-in-the-middle (MITM) attack to silently downgrade a connection from SCRAM-SHA-256-PLUS (with channel binding) to standard SCRAM-SHA-256 (without channel binding), bypassing strict client-side enforcement policies.
Component Breakdown
This occurs due to a two-part failure in TlsServerEndpoint when a server presents an X.509 certificate using a modern signature algorithm that lacks traditional WITH naming structures (such as Ed25519 or post-quantum algorithms):
- The internal hash derivation method fails to parse the algorithm name, swallows the resulting
NoSuchAlgorithmException, and silently returns an empty byte array via the deprecatedgetChannelBindingData()` API. - The client builder mistakenly interprets this empty byte array as an environmental absence of channel binding data rather than a cryptographic failure, falling back to non-channel-bound authentication.
Impact & Scope
This issue only impacts deployments where the downstream application layer explicitly enforces strict channel binding enforcement (e.g., channelBinding=require in pgJDBC).
Drivers operating under a "prefer" or "allow" policy (used by default) are structurally insulated from an unhandled exception since a fallback to standard SCRAM is within their expected configuration.
Remediation
Update your project configuration to pull in version 3.3 or later of the SCRAM library, which introduces strict exception propagation and explicit policy controls.
If you are interacting with the ScramClient builder API directly (e.g., writing a custom driver or database extension):
- Migrate Deprecated APIs: Stop using
TlsServerEndpoint.getChannelBindingData(). Transition immediately toTlsServerEndpoint.getChannelBindingHash(), which correctly propagatesNoSuchAlgorithmExceptionup the stack. - Adopt Explicit Policies: Leverage the newly introduced
ChannelBindingPolicyAPI during client construction. Do not rely on implicit parameter presence to dictate your security boundaries.
ScramClient client = ScramClient.builder()
.advertisedMechanisms(serverMechanisms)
.username(user)
.password(pass)
// Explicitly enforce strict boundaries if needed.
.channelBindingPolicy(ChannelBindingPolicy.REQUIRE)
.channelBinding(TlsServerEndpoint.TLS_SERVER_END_POINT, certHash)
.build();
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 3.2"
},
"package": {
"ecosystem": "Maven",
"name": "com.ongres.scram:scram-client"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "3.3"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 3.2"
},
"package": {
"ecosystem": "Maven",
"name": "com.ongres.scram:scram-common"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "3.3"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-53712"
],
"database_specific": {
"cwe_ids": [
"CWE-636",
"CWE-757"
],
"github_reviewed": true,
"github_reviewed_at": "2026-07-01T21:51:17Z",
"nvd_published_at": null,
"severity": "HIGH"
},
"details": "## Summary\n\nA flaw in `com.ongres.scram:scram-client` allows an attacker capable of performing a TLS man-in-the-middle (MITM) attack to silently downgrade a connection from `SCRAM-SHA-256-PLUS` (with channel binding) to standard `SCRAM-SHA-256` (without channel binding), bypassing strict client-side enforcement policies.\n\n## Component Breakdown\n\nThis occurs due to a two-part failure in `TlsServerEndpoint` when a server presents an `X.509` certificate using a modern signature algorithm that lacks traditional `WITH` naming structures (such as `Ed25519` or post-quantum algorithms):\n\n1. The internal hash derivation method fails to parse the algorithm name, swallows the resulting `NoSuchAlgorithmException, and silently returns an empty byte array via the deprecated `getChannelBindingData()` API.\n2. The client builder mistakenly interprets this empty byte array as an environmental absence of channel binding data rather than a cryptographic failure, falling back to non-channel-bound authentication.\n\n## Impact \u0026 Scope\n\nThis issue only impacts deployments where the downstream application layer explicitly enforces strict channel binding enforcement (e.g., channelBinding=require in pgJDBC).\n\nDrivers operating under a \"prefer\" or \"allow\" policy (used by default) are structurally insulated from an unhandled exception since a fallback to standard SCRAM is within their expected configuration.\n\n## Remediation\n\nUpdate your project configuration to pull in version 3.3 or later of the SCRAM library, which introduces strict exception propagation and explicit policy controls.\n\nIf you are interacting with the `ScramClient` builder API directly (e.g., writing a custom driver or database extension):\n\n- Migrate Deprecated APIs: Stop using `TlsServerEndpoint.getChannelBindingData()`. Transition immediately to `TlsServerEndpoint.getChannelBindingHash()`, which correctly propagates `NoSuchAlgorithmException` up the stack.\n- Adopt Explicit Policies: Leverage the newly introduced `ChannelBindingPolicy` API during client construction. Do not rely on implicit parameter presence to dictate your security boundaries.\n\n```java\nScramClient client = ScramClient.builder()\n .advertisedMechanisms(serverMechanisms)\n .username(user)\n .password(pass)\n // Explicitly enforce strict boundaries if needed.\n .channelBindingPolicy(ChannelBindingPolicy.REQUIRE) \n .channelBinding(TlsServerEndpoint.TLS_SERVER_END_POINT, certHash)\n .build();\n```",
"id": "GHSA-p9jg-fcr6-3mhf",
"modified": "2026-07-01T21:51:17Z",
"published": "2026-07-01T21:51:17Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/ongres/scram/security/advisories/GHSA-p9jg-fcr6-3mhf"
},
{
"type": "PACKAGE",
"url": "https://github.com/ongres/scram"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:H/AT:N/PR:N/UI:N/VC:N/VI:H/VA:N/SC:N/SI:L/SA:N",
"type": "CVSS_V4"
}
],
"summary": "OnGres SCRAM silent channel-binding authentication downgrade via unsupported certificate algorithms"
}
GHSA-Q6PR-MGHJ-3FJX
Vulnerability from github – Published: 2026-04-17 21:31 – Updated: 2026-04-17 21:31Anviz CrossChex Standard is vulnerable when an attacker manipulates the TDS7 PreLogin to disable encryption, causing database credentials to be sent in plaintext and enabling unauthorized database access.
{
"affected": [],
"aliases": [
"CVE-2026-32650"
],
"database_specific": {
"cwe_ids": [
"CWE-757"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-04-17T20:16:34Z",
"severity": "HIGH"
},
"details": "Anviz CrossChex Standard\u00a0is vulnerable when an attacker manipulates the TDS7 PreLogin to disable \nencryption, causing database credentials to be sent in plaintext and \nenabling unauthorized database access.",
"id": "GHSA-q6pr-mghj-3fjx",
"modified": "2026-04-17T21:31:46Z",
"published": "2026-04-17T21:31:46Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-32650"
},
{
"type": "WEB",
"url": "https://github.com/cisagov/CSAF/blob/develop/csaf_files/OT/white/2026/icsa-26-106-03.json"
},
{
"type": "WEB",
"url": "https://www.anviz.com/contact-us.html"
},
{
"type": "WEB",
"url": "https://www.cisa.gov/news-events/ics-advisories/icsa-26-106-03"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-RRJ9-5Q2J-4GVR
Vulnerability from github – Published: 2026-06-15 17:32 – Updated: 2026-06-15 17:32Description
Symfony\Component\Mailer\Bridge\Mailomat\Webhook\MailomatRequestParser::validateSignature() parses the X-MOM-Webhook-Signature request header as algo=signature and passes the wire-supplied $algo directly to hash_hmac() when verifying the request against the configured webhook secret. The request therefore selects the HMAC primitive used to authenticate it.
PHP's hash_hmac() enforces only that the chosen algorithm is HMAC-compatible. That set still includes primitives with known cryptanalysis (md4, md5, ripemd128, tiger128,3, … — e.g. existential forgery of HMAC-MD4, Contini & Yin, ASIACRYPT 2006). This is the canonical algorithm-confusion shape, analogous to JWT alg=none / alg=HS256 downgrades: any future cryptographic weakness in any HMAC primitive PHP exposes becomes immediately exploitable against a Mailomat webhook receiver, the moment an attacker is in a position to compute a signature for that primitive, without a code change on the Symfony side.
Mailomat's documented webhook security pins SHA-256; the parser did not.
Resolution
MailomatRequestParser::validateSignature() now requires the signature header to be of the form sha256=<hex> and verifies the signature with HMAC-SHA256 keyed by the configured secret using a constant-time comparison. Any other algorithm declared on the wire (including the HMAC primitives PHP would otherwise accept) is rejected.
The patch for this issue is available here for branch 7.4 (and forward-ported to 8.0 and 8.1).
Credits
Symfony would like to thank Omar Alshammari, Essam Alanazi and Alwaleed Alshammari for reporting the issue and Nicolas Grekas for providing the fix.
{
"affected": [
{
"package": {
"ecosystem": "Packagist",
"name": "symfony/mailomat-mailer"
},
"ranges": [
{
"events": [
{
"introduced": "7.2.0"
},
{
"fixed": "7.4.13"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Packagist",
"name": "symfony/mailomat-mailer"
},
"ranges": [
{
"events": [
{
"introduced": "8.0.0"
},
{
"fixed": "8.0.13"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Packagist",
"name": "symfony/symfony"
},
"ranges": [
{
"events": [
{
"introduced": "7.2.0"
},
{
"fixed": "7.4.13"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Packagist",
"name": "symfony/symfony"
},
"ranges": [
{
"events": [
{
"introduced": "8.0.0"
},
{
"fixed": "8.0.13"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-48747"
],
"database_specific": {
"cwe_ids": [
"CWE-347",
"CWE-757"
],
"github_reviewed": true,
"github_reviewed_at": "2026-06-15T17:32:28Z",
"nvd_published_at": null,
"severity": "MODERATE"
},
"details": "### Description\n\n`Symfony\\Component\\Mailer\\Bridge\\Mailomat\\Webhook\\MailomatRequestParser::validateSignature()` parses the `X-MOM-Webhook-Signature` request header as `algo=signature` and passes the wire-supplied `$algo` directly to `hash_hmac()` when verifying the request against the configured webhook secret. The request therefore selects the HMAC primitive used to authenticate it.\n\nPHP\u0027s `hash_hmac()` enforces only that the chosen algorithm is HMAC-compatible. That set still includes primitives with known cryptanalysis (`md4`, `md5`, `ripemd128`, `tiger128,3`, \u2026 \u2014 e.g. existential forgery of HMAC-MD4, Contini \u0026 Yin, ASIACRYPT 2006). This is the canonical algorithm-confusion shape, analogous to JWT `alg=none` / `alg=HS256` downgrades: any future cryptographic weakness in any HMAC primitive PHP exposes becomes immediately exploitable against a Mailomat webhook receiver, the moment an attacker is in a position to compute a signature for that primitive, without a code change on the Symfony side.\n\nMailomat\u0027s [documented webhook security](https://api.mailomat.swiss/docs/#tag/webhook-security) pins SHA-256; the parser did not.\n\n### Resolution\n\n`MailomatRequestParser::validateSignature()` now requires the signature header to be of the form `sha256=\u003chex\u003e` and verifies the signature with HMAC-SHA256 keyed by the configured secret using a constant-time comparison. Any other algorithm declared on the wire (including the HMAC primitives PHP would otherwise accept) is rejected.\n\nThe patch for this issue is available [here](https://github.com/symfony/symfony/commit/bdfe9fe0d94d33dfaca0bc2fe0b00b54767b0c88) for branch 7.4 (and forward-ported to 8.0 and 8.1).\n\n### Credits\n\nSymfony would like to thank Omar Alshammari, Essam Alanazi and Alwaleed Alshammari for reporting the issue and Nicolas Grekas for providing the fix.",
"id": "GHSA-rrj9-5q2j-4gvr",
"modified": "2026-06-15T17:32:28Z",
"published": "2026-06-15T17:32:28Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/symfony/symfony/security/advisories/GHSA-rrj9-5q2j-4gvr"
},
{
"type": "WEB",
"url": "https://github.com/symfony/symfony/commit/bdfe9fe0d94d33dfaca0bc2fe0b00b54767b0c88"
},
{
"type": "WEB",
"url": "https://github.com/FriendsOfPHP/security-advisories/blob/master/symfony/mailomat-mailer/CVE-2026-48747.yaml"
},
{
"type": "WEB",
"url": "https://github.com/FriendsOfPHP/security-advisories/blob/master/symfony/symfony/CVE-2026-48747.yaml"
},
{
"type": "PACKAGE",
"url": "https://github.com/symfony/symfony"
},
{
"type": "WEB",
"url": "https://symfony.com/cve-2026-48747"
}
],
"schema_version": "1.4.0",
"severity": [],
"summary": "Symfony: Mailomat Mailer Webhook Parser Reads the HMAC Algorithm from the Request: Signature Algorithm Downgrade"
}
GHSA-RVXX-GX2M-H7RC
Vulnerability from github – Published: 2022-02-15 01:38 – Updated: 2022-02-15 01:38A flaw was found when an OpenSSL security provider is used with Wildfly, the 'enabled-protocols' value in the Wildfly configuration isn't honored. An attacker could target the traffic sent from Wildfly and downgrade the connection to a weaker version of TLS, potentially breaking the encryption. This could lead to a leak of the data being passed over the network. Wildfly version 7.2.0.GA, 7.2.3.GA and 7.2.5.CR2 are believed to be vulnerable.
{
"affected": [],
"aliases": [
"CVE-2019-14887"
],
"database_specific": {
"cwe_ids": [
"CWE-326",
"CWE-757"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2020-03-16T15:15:00Z",
"severity": "MODERATE"
},
"details": "A flaw was found when an OpenSSL security provider is used with Wildfly, the \u0027enabled-protocols\u0027 value in the Wildfly configuration isn\u0027t honored. An attacker could target the traffic sent from Wildfly and downgrade the connection to a weaker version of TLS, potentially breaking the encryption. This could lead to a leak of the data being passed over the network. Wildfly version 7.2.0.GA, 7.2.3.GA and 7.2.5.CR2 are believed to be vulnerable.",
"id": "GHSA-rvxx-gx2m-h7rc",
"modified": "2022-02-15T01:38:58Z",
"published": "2022-02-15T01:38:58Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2019-14887"
},
{
"type": "WEB",
"url": "https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2019-14887"
},
{
"type": "WEB",
"url": "https://issues.redhat.com/browse/JBEAP-17965"
},
{
"type": "WEB",
"url": "https://security.netapp.com/advisory/ntap-20200327-0007"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N",
"type": "CVSS_V3"
}
],
"summary": "Inadequate Encryption Strength and Algorithm Downgrade in Wildfly"
}
GHSA-V638-38FC-RHFV
Vulnerability from github – Published: 2026-04-24 15:59 – Updated: 2026-04-24 15:59Summary
AWS Encryption SDK (ESDK) for Python is a client-side encryption library. An issue exists where, under certain circumstances, a specific cryptographic algorithm downgrade in the caching layer might allow an authenticated local threat actor to bypass key commitment policy enforcement via a shared key cache, resulting in ciphertext that can be decrypted to multiple different plaintexts.
Impact
This issue requires all of the following conditions to be true: (1) Two ESDK for Python clients with different commitment policies share a single CachingCryptoMaterialsManager instance within the same process. (2) The client with the weaker commitment policy encrypts first, warming the cache. (3) Both clients use matching encryption contexts. (4) Both clients use the pre-configured default algorithm suite.
These conditions may occur during a migration from ESDK for Python v1 to newer versions, as v1 did not support key commitment.
When the weaker-policy client encrypts first, the cache stores encryption materials that do not enforce key commitment. Subsequent callers — including those configured to require key commitment — are served these cached materials instead of generating new ones that satisfy their policy. This results in encryption without key commitment, meaning the same ciphertext can be validly decrypted to different plaintexts under different keys (the "Invisible Salamanders" issue; see https://github.com/google/security-research/security/advisories/GHSA-wqgp-vphw-hphf). A threat actor who controls ciphertext can cause a recipient to decrypt a message different from what the sender encrypted, breaking message integrity.
Impacted versions
- From 2.0 to 2.5.1
- From 3.0 to 3.3.0
- From 4.0 to 4.0.4
Patches
This issue has been addressed in ESDK for Python versions 3.3.1 and 4.0.5. We recommend upgrading to the latest version and ensuring any forked or derivative code is patched to incorporate the new fixes.
Workarounds
If a customer requires operating multiple instances of the Python ESDK each with differently configured key commitment policies, they must not share a key cache.
References If there are any questions or comments about this advisory, contact AWS Security through the vulnerability reporting page or directly via email to aws-security@amazon.com. Please do not create a public GitHub issue.
Acknowledgement
Thanks to 1seal.org for collaborating on this issue through the coordinated vulnerability disclosure process.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c 3.3.0"
},
"package": {
"ecosystem": "PyPI",
"name": "aws-encryption-sdk"
},
"ranges": [
{
"events": [
{
"introduced": "2.0.0"
},
{
"fixed": "3.3.1"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c 4.0.4"
},
"package": {
"ecosystem": "PyPI",
"name": "aws-encryption-sdk"
},
"ranges": [
{
"events": [
{
"introduced": "4.0.0"
},
{
"fixed": "4.0.5"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-6550"
],
"database_specific": {
"cwe_ids": [
"CWE-757"
],
"github_reviewed": true,
"github_reviewed_at": "2026-04-24T15:59:17Z",
"nvd_published_at": "2026-04-20T20:16:49Z",
"severity": "MODERATE"
},
"details": "## Summary\nAWS Encryption SDK (ESDK) for Python is a client-side encryption library. An issue exists where, under certain circumstances, a specific cryptographic algorithm downgrade in the caching layer might allow an authenticated local threat actor to bypass key commitment policy enforcement via a shared key cache, resulting in ciphertext that can be decrypted to multiple different plaintexts.\n\n## Impact\nThis issue requires all of the following conditions to be true: (1) Two ESDK for Python clients with different commitment policies share a single CachingCryptoMaterialsManager instance within the same process. (2) The client with the weaker commitment policy encrypts first, warming the cache. (3) Both clients use matching encryption contexts. (4) Both clients use the pre-configured default algorithm suite.\n\nThese conditions may occur during a migration from ESDK for Python v1 to newer versions, as v1 did not support key commitment.\n\nWhen the weaker-policy client encrypts first, the cache stores encryption materials that do not enforce key commitment. Subsequent callers \u2014 including those configured to require key commitment \u2014 are served these cached materials instead of generating new ones that satisfy their policy. This results in encryption without key commitment, meaning the same ciphertext can be validly decrypted to different plaintexts under different keys (the \"Invisible Salamanders\" issue; see https://github.com/google/security-research/security/advisories/GHSA-wqgp-vphw-hphf). A threat actor who controls ciphertext can cause a recipient to decrypt a message different from what the sender encrypted, breaking message integrity.\n\n## Impacted versions\n- From 2.0 to 2.5.1\n- From 3.0 to 3.3.0\n- From 4.0 to 4.0.4\n\n## Patches\nThis issue has been addressed in ESDK for Python versions 3.3.1 and 4.0.5. We recommend upgrading to the latest version and ensuring any forked or derivative code is patched to incorporate the new fixes.\n\n## Workarounds\nIf a customer requires operating multiple instances of the Python ESDK each with differently configured key commitment policies, they must not share a key cache.\n\nReferences\nIf there are any questions or comments about this advisory, contact AWS Security through the [vulnerability reporting page](https://aws.amazon.com/security/vulnerability-reporting) or directly via email to [aws-security@amazon.com](mailto:aws-security@amazon.com). Please do not create a public GitHub issue.\n\n## Acknowledgement\nThanks to [1seal.org](http://1seal.org/) for collaborating on this issue through the coordinated vulnerability disclosure process.",
"id": "GHSA-v638-38fc-rhfv",
"modified": "2026-04-24T15:59:17Z",
"published": "2026-04-24T15:59:17Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/aws/aws-encryption-sdk-python/security/advisories/GHSA-v638-38fc-rhfv"
},
{
"type": "WEB",
"url": "https://github.com/google/security-research/security/advisories/GHSA-wqgp-vphw-hphf"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-6550"
},
{
"type": "WEB",
"url": "https://aws.amazon.com/security/security-bulletins/2026-017-aws"
},
{
"type": "PACKAGE",
"url": "https://github.com/aws/aws-encryption-sdk-python"
},
{
"type": "WEB",
"url": "https://github.com/aws/aws-encryption-sdk-python/releases/tag/v3.3.1"
},
{
"type": "WEB",
"url": "https://github.com/aws/aws-encryption-sdk-python/releases/tag/v4.0.5"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:H/A:N",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:L/AC:H/AT:P/PR:L/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "AWS Encryption SDK for Python: Key commitment policy bypass via shared key cache"
}
GHSA-V97F-7X7P-G6CQ
Vulnerability from github – Published: 2025-10-31 21:31 – Updated: 2025-10-31 21:31When SmartStart Inclusion fails during the onboarding of a Z-Wave PIR sensor, the sensor will join the network as a non-secure device. This vulnerability exists in Silicon Labs' Z-Wave PIR Sensor Reference design delivered as part of SiSDK v2025.6.0 and v2025.6.1.
{
"affected": [],
"aliases": [
"CVE-2025-10693"
],
"database_specific": {
"cwe_ids": [
"CWE-757"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-10-31T20:15:41Z",
"severity": "HIGH"
},
"details": "When SmartStart Inclusion fails during the onboarding of a Z-Wave PIR sensor, the sensor will join the network as a non-secure device. This vulnerability exists in Silicon Labs\u0027 Z-Wave PIR Sensor Reference design delivered as part of SiSDK v2025.6.0 and v2025.6.1.",
"id": "GHSA-v97f-7x7p-g6cq",
"modified": "2025-10-31T21:31:03Z",
"published": "2025-10-31T21:31:03Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-10693"
},
{
"type": "WEB",
"url": "https://community.silabs.com/068Vm00000WN3J0"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:P/VC:H/VI:H/VA:L/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
"type": "CVSS_V4"
}
]
}
GHSA-VQ75-425F-VQ6R
Vulnerability from github – Published: 2022-05-24 17:28 – Updated: 2025-06-05 00:31Philips Clinical Collaboration Platform, Versions 12.2.1 and prior. The software does not properly control the allocation and maintenance of a limited resource, thereby enabling an attacker to influence the amount of resources consumed, eventually leading to the exhaustion of available resources.
{
"affected": [],
"aliases": [
"CVE-2020-16200"
],
"database_specific": {
"cwe_ids": [
"CWE-757"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2020-09-18T18:15:00Z",
"severity": "MODERATE"
},
"details": "Philips Clinical Collaboration Platform, Versions 12.2.1 and prior. The software does not properly control the allocation and maintenance of a limited resource, thereby enabling an attacker to influence the amount of resources consumed, eventually leading to the exhaustion of available resources.",
"id": "GHSA-vq75-425f-vq6r",
"modified": "2025-06-05T00:31:18Z",
"published": "2022-05-24T17:28:58Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2020-16200"
},
{
"type": "WEB",
"url": "https://us-cert.cisa.gov/ics/advisories/icsma-20-261-01"
},
{
"type": "WEB",
"url": "https://www.philips.com/a-w/security/security-advisories/product-security-2020.html#2020_archive"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-WJ64-GH9J-XM82
Vulnerability from github – Published: 2026-03-13 21:31 – Updated: 2026-03-17 18:30Issue 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.
{
"affected": [],
"aliases": [
"CVE-2026-2673"
],
"database_specific": {
"cwe_ids": [
"CWE-757"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-03-13T19:54:34Z",
"severity": "HIGH"
},
"details": "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.",
"id": "GHSA-wj64-gh9j-xm82",
"modified": "2026-03-17T18:30:32Z",
"published": "2026-03-13T21:31:46Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-2673"
},
{
"type": "WEB",
"url": "https://github.com/openssl/openssl/commit/2157c9d81f7b0bd7dfa25b960e928ec28e8dd63f"
},
{
"type": "WEB",
"url": "https://github.com/openssl/openssl/commit/85977e013f32ceb96aa034c0e741adddc1a05e34"
},
{
"type": "WEB",
"url": "https://openssl-library.org/news/secadv/20260313.txt"
},
{
"type": "WEB",
"url": "http://www.openwall.com/lists/oss-security/2026/03/13/3"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
}
]
}
No mitigation information available for this CWE.
CAPEC-220: Client-Server Protocol Manipulation
An adversary takes advantage of weaknesses in the protocol by which a client and server are communicating to perform unexpected actions. Communication protocols are necessary to transfer messages between client and server applications. Moreover, different protocols may be used for different types of interactions.
CAPEC-606: Weakening of Cellular Encryption
An attacker, with control of a Cellular Rogue Base Station or through cooperation with a Malicious Mobile Network Operator can force the mobile device (e.g., the retransmission device) to use no encryption (A5/0 mode) or to use easily breakable encryption (A5/1 or A5/2 mode).
CAPEC-620: Drop Encryption Level
An attacker forces the encryption level to be lowered, thus enabling a successful attack against the encrypted data.