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.
67 vulnerabilities reference this CWE, most recent first.
GHSA-RQF5-2WXV-RJF4
Vulnerability from github – Published: 2026-10-08 16:23 – Updated: 2026-10-08 16:23Impact
A Digest challenge that does not yield a usable nonce is treated as a Basic challenge. The client then answers it with Authorization: Basic, which carries the username and password base64 encoded and so recoverable by anyone who sees the request.
Any of these is enough, sent by whoever writes the 401 or 407:
WWW-Authenticate: Digest realm="protected"
WWW-Authenticate: Digest realm="protected", nonce=""
The challenge announces itself as Digest, so it passes the check that would otherwise reject a non-Digest challenge for a Digest realm. It then fails to produce a nonce, and the absence of a nonce is what selected Basic. A server offering plain Basic to a Digest realm gets nothing, so labelling the challenge Digest and leaving the nonce out is what makes the difference.
This is reachable by anyone who can write the challenge: a malicious or compromised origin, a proxy, or an attacker on a plaintext hop. Digest exists precisely to keep the password off those hops. A server that stores only HA1, and anyone impersonating the real origin, does not otherwise learn the password itself, so the disclosure enables reuse against other services.
Both the target and the proxy paths are affected, through parseWWWAuthenticateHeader and parseProxyAuthenticateHeader.
Affected versions
- 3.x: up to and including 3.0.12
- 2.x: up to and including 2.16.0
This is long-standing behaviour on both lines, not a recent regression. On 3.0.12 there is one additional way to reach it: a quoted parameter ending in an unescaped backslash, such as realm="C:\", makes the closing quote read as escaped so the nonce is never found. That trigger is specific to 3.0.12. The downgrade it led to is fixed, but the nonce is still lost on such a challenge: every conformant reader treats the closing quote as escaped. The exchange now fails instead of falling back to Basic.
Patches
Fixed in 3.0.13 on the 3.x line and in 2.16.1 on the 2.x line. The scheme now comes from the challenge itself instead of being inferred from whether a nonce was found, so a Digest challenge stays Digest even when it cannot be read. With no nonce it produces no Authorization header at all, which fails the exchange rather than downgrading it.
The 3.x fix also corrects quoted-pair handling so that a backslash before any character other than a quote or another backslash is kept as written, matching Apache HttpComponents. That repairs a 3.0.12 regression where an unescaped realm such as DOMAIN\Users was corrupted to DOMAINUsers and failed every digest comparison. This is a deliberate deviation from a strict reading of RFC 9110 Section 5.6.4, under which a backslash before any character is a quoted-pair. Reading it strictly is what corrupts the unescaped spelling that servers actually send, and the decoding is not reversible either way, so the client follows the same rule as Apache HttpComponents.
Workarounds
No configuration prevents this. Until you can upgrade, do not use Digest authentication against a server you do not control, and do not use it over plaintext HTTP.
Details
Realm.Builder.parseWWWAuthenticateHeader and parseProxyAuthenticateHeader selected the scheme with isNonEmpty(nonce) ? AuthScheme.DIGEST : AuthScheme.BASIC, so any challenge that produced no nonce became a Basic challenge and Unauthorized401Interceptor resent the request using computeBasicAuthentication.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 3.0.12"
},
"package": {
"ecosystem": "Maven",
"name": "org.asynchttpclient:async-http-client"
},
"ranges": [
{
"events": [
{
"introduced": "3.0.0.Beta1"
},
{
"fixed": "3.0.13"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 2.16.0"
},
"package": {
"ecosystem": "Maven",
"name": "org.asynchttpclient:async-http-client"
},
"ranges": [
{
"events": [
{
"introduced": "2.0.0"
},
{
"fixed": "2.16.1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-107231"
],
"database_specific": {
"cwe_ids": [
"CWE-319",
"CWE-522",
"CWE-757"
],
"github_reviewed": true,
"github_reviewed_at": "2026-10-08T16:23:36Z",
"nvd_published_at": "2026-10-07T22:17:03Z",
"severity": "HIGH"
},
"details": "### Impact\nA Digest challenge that does not yield a usable nonce is treated as a Basic challenge. The client then answers it with `Authorization: Basic`, which carries the username and password base64 encoded and so recoverable by anyone who sees the request.\n\nAny of these is enough, sent by whoever writes the 401 or 407:\n\n```\nWWW-Authenticate: Digest realm=\"protected\"\nWWW-Authenticate: Digest realm=\"protected\", nonce=\"\"\n```\n\nThe challenge announces itself as Digest, so it passes the check that would otherwise reject a non-Digest challenge for a Digest realm. It then fails to produce a nonce, and the absence of a nonce is what selected Basic. A server offering plain `Basic` to a Digest realm gets nothing, so labelling the challenge Digest and leaving the nonce out is what makes the difference.\n\nThis is reachable by anyone who can write the challenge: a malicious or compromised origin, a proxy, or an attacker on a plaintext hop. Digest exists precisely to keep the password off those hops. A server that stores only HA1, and anyone impersonating the real origin, does not otherwise learn the password itself, so the disclosure enables reuse against other services.\n\nBoth the target and the proxy paths are affected, through `parseWWWAuthenticateHeader` and `parseProxyAuthenticateHeader`.\n\n### Affected versions\n* 3.x: up to and including 3.0.12\n* 2.x: up to and including 2.16.0\n\nThis is long-standing behaviour on both lines, not a recent regression. On 3.0.12 there is one additional way to reach it: a quoted parameter ending in an unescaped backslash, such as `realm=\"C:\\\"`, makes the closing quote read as escaped so the nonce is never found. That trigger is specific to 3.0.12. The downgrade it led to is fixed, but the nonce is still lost on such a challenge: every conformant reader treats the closing quote as escaped. The exchange now fails instead of falling back to Basic.\n\n### Patches\nFixed in 3.0.13 on the 3.x line and in 2.16.1 on the 2.x line. The scheme now comes from the challenge itself instead of being inferred from whether a nonce was found, so a Digest challenge stays Digest even when it cannot be read. With no nonce it produces no Authorization header at all, which fails the exchange rather than downgrading it.\n\nThe 3.x fix also corrects quoted-pair handling so that a backslash before any character other than a quote or another backslash is kept as written, matching Apache HttpComponents. That repairs a 3.0.12 regression where an unescaped realm such as `DOMAIN\\Users` was corrupted to `DOMAINUsers` and failed every digest comparison. This is a deliberate deviation from a strict reading of RFC 9110 Section 5.6.4, under which a backslash before any character is a quoted-pair. Reading it strictly is what corrupts the unescaped spelling that servers actually send, and the decoding is not reversible either way, so the client follows the same rule as Apache HttpComponents.\n\n### Workarounds\nNo configuration prevents this. Until you can upgrade, do not use Digest authentication against a server you do not control, and do not use it over plaintext HTTP.\n\n### Details\n`Realm.Builder.parseWWWAuthenticateHeader` and `parseProxyAuthenticateHeader` selected the scheme with `isNonEmpty(nonce) ? AuthScheme.DIGEST : AuthScheme.BASIC`, so any challenge that produced no nonce became a Basic challenge and `Unauthorized401Interceptor` resent the request using `computeBasicAuthentication`.",
"id": "GHSA-rqf5-2wxv-rjf4",
"modified": "2026-10-08T16:23:36Z",
"published": "2026-10-08T16:23:36Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/AsyncHttpClient/async-http-client/security/advisories/GHSA-rqf5-2wxv-rjf4"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-107231"
},
{
"type": "WEB",
"url": "https://github.com/AsyncHttpClient/async-http-client/commit/8376866aa9b5a7653ad19db9d472692f875caa83"
},
{
"type": "WEB",
"url": "https://github.com/AsyncHttpClient/async-http-client/commit/c8d639bf6ac341d377d610a93570bcd15565f1a6"
},
{
"type": "PACKAGE",
"url": "https://github.com/AsyncHttpClient/async-http-client"
},
{
"type": "WEB",
"url": "https://github.com/AsyncHttpClient/async-http-client/releases/tag/async-http-client-project-2.16.1"
},
{
"type": "WEB",
"url": "https://github.com/AsyncHttpClient/async-http-client/releases/tag/async-http-client-project-3.0.13"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "AsyncHttpClient: Digest challenge without a usable nonce downgrades to Basic and sends the password in cleartext"
}
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.